TheBackShed.com

Forum Index : Microcontroller and PC projects : Sharing Pins?

Author

Message

Phil23
Guru

Joined: 27/03/2016
Location: Australia
Posts: 1664

Posted: 07:16pm 03 May 2017

Copy link to clipboard

Print this post

I'm guessing the answer is no,
but thought I'd ask anyway.

Particularly pins 17 & 18, I2C, & Possibly with an RTC connected.

Can I have an RTC connected, but after reading it set the pin to either
DOUT or DOUT,OC, would not matter which if either worked.

Just want to blink a status LED to indicate the device is running & short of pins on this project.

If I used OC, I'd be essentially grounding one of the RTC's I2C lines on & off.

If I wanted to re-read the RTC I'd have to de-configure the pin etc.....

Thanks

Phil.

Edit:- 28 Pin Package.
Edited by Phil23 2017-05-05

jman

Guru

Joined: 12/06/2011
Location: New Zealand
Posts: 711

Posted: 10:01pm 03 May 2017

Copy link to clipboard

Print this post

Hi Phil

I don't see any reason why this should not work if you use OC just keep the I2C pullup resistors value as high as possible.

Regards
Jman

CaptainBoing

Guru

Joined: 07/09/2016
Location: United Kingdom
Posts: 1985

Posted: 10:36pm 03 May 2017

Copy link to clipboard

Print this post

usually, once a pin has been set to a "special" function that is it, however, the pin can be released using

SETPIN x,OFF

after which it can be re-assigned. I don't know about i2c but this definitely works with the LCD commands as I pass data to and fro on a dedicated 8 bit bus on one project. The LCD command freezes out the pins for GP use and vice-versa - using OFF after I have finished with the pin solves this. Here is the code:

SUB WriteLCD 'set the gp port for LCD use and update both lines
SETPIN D4,OFF
SETPIN D5,OFF
SETPIN D6,OFF
SETPIN D7,OFF
LCD INIT D4,D5,D6,D7,LCDRS,LCDE
LCD 1,1,Line1$
LCD 2,1,Line2$
LCD CLOSE ' release D4-D7
DBPrepRead
END SUB

SUB DBPrepRead ' prep the GP port for input (safe)
SETPIN D0,DIN
SETPIN D1,DIN
SETPIN D2,DIN
SETPIN D3,DIN
SETPIN D4,DIN
SETPIN D5,DIN
SETPIN D6,DIN
SETPIN D7,DIN
PAUSE 1
END SUB

SUB DBPrepWrite ' prep the GP port for output
SETPIN D0,DOUT
SETPIN D1,DOUT
SETPIN D2,DOUT
SETPIN D3,DOUT
SETPIN D4,DOUT
SETPIN D5,DOUT
SETPIN D6,DOUT
SETPIN D7,DOUT
PAUSE 1
END SUB

FUNCTION DBRead()
DBPrepRead
DBRead=PORT(D0,4,D4,2,D6,2) AND 255
END FUNCTION

SUB DBWrite(x)
DBPrepWrite
PORT(D0,4,D4,2,D6,2)=x AND 255
DBPrepRead
END SUB

... might give you some ideas

I can't try this on i2c at the mo but it may be what you are after.

Edited by CaptainBoing 2017-05-05

Phil23
Guru

Joined: 27/03/2016
Location: Australia
Posts: 1664

Posted: 11:53pm 03 May 2017

Copy link to clipboard

Print this post

Thanks Jman,

I really need to just plug something up & try it.
Need to organise that.

Captain,

Are you meaning the likes of 20x4 LCD's.
That's what's on this.

If I could borrow a pin or 2 from the LCD for a loop or two that would be even better... Update the display every 10 sec or so, do other stuff in the spare time...

Can't say I've seen a command like "LCD Un-init....".

Phil.

CaptainBoing

Guru

Joined: 07/09/2016
Location: United Kingdom
Posts: 1985

Posted: 12:14am 04 May 2017

Copy link to clipboard

Print this post

Phil23 said

Are you meaning the likes of 20x4 LCD's.
That's what's on this.

If I could borrow a pin or 2 from the LCD for a loop or two that would be even better... Update the display every 10 sec or so, do other stuff in the spare time...

Can't say I've seen a command like "LCD Un-init....".

Yep. It's a 1602 HD44780 in my instance, but the same meat...

One thing to be aware of is that when you re-INIT the LCD, there is a flicker on the display (probably an implicit clear-screen) I can live with it as I immediately update the entire display (the two Linex$ act as a screen buffer). This way I only manipulate the two strings and a call to WriteLCD just handles everything and leaves the data bus ready for use anywhere else.

, if you can too then you have 4 spare bits to play with.

hEdited by CaptainBoing 2017-05-05

Phil23
Guru

Joined: 27/03/2016
Location: Australia
Posts: 1664

Posted: 12:20am 04 May 2017

Copy link to clipboard

Print this post

CaptainBoing said It's a 1602 HD44780 in my instance, but the same meat...

One thing to be aware of is that when you re-INIT the LCD, there is a flicker on the display (probably an implicit clear-screen) I can live with it as I immediately update the entire display........

Lol,

I only look at it when I walk past....
I rarely stand and gaze at the screen.

Which pins are you grabbing back?

RS, EN, or some of the data ones?

CaptainBoing

Guru

Joined: 07/09/2016
Location: United Kingdom
Posts: 1985

Posted: 12:31am 04 May 2017

Copy link to clipboard

Print this post

Phil23 said
I only look at it when I walk past....
I rarely stand and gaze at the screen.

Which pins are you grabbing back?

RS, EN, or some of the data ones?

Ideal then - you'll rarely notice the flicker.

The LCD CLOSE releases all pins allocated so you can pick and choose. I have dedicated command pins and re-use D0-D7 for loads of other things - old school stylee...

I come from a Z80 background so I am really comfy with a generic data bus idea rather than dedicating pins to single peripherals (and going up to bigger devices when I run out of pins). Heh, I am such a dinosaur, I even have old static memories (6116, 6264 etc) and ERPOMS (2764 etc) on the bus... I use HC374's to latch the address off the data bus [which is actually more like the ALE of the 8085] and a few control bits (CSs, RD & WR) then the data just flies back and forth on the GP bus. It is not amazingly fast but un-noticeable for a few tens of bytes a time (data logging, lookup tables etc). 1Mx8 static memories are cheap and a good substitute for smaller systems that don't/can't support SDcards.

This last setup is used in a beer-barrel sterilisation monitor that travels through the auto-claves to monitor conditions inside the barrel during the process... plugs in to a pc when you take it out the other end and dumps the data. Customer is very happy and we went to MicroMite (instead of Z80s) last year - was a simple shoe-in replacement with a clearer, more sustainable upgrade path. Not a huge seller but definitely a nice project.

Edited by CaptainBoing 2017-05-05

Phil23
Guru

Joined: 27/03/2016
Location: Australia
Posts: 1664

Posted: 12:46am 04 May 2017

Copy link to clipboard

Print this post

Sounding really cool so far.

So if I'm grabbing pins again, is there any preference between DOUT & OC DOUT?
It's only extra outputs I'm looking for, relays etc.... I think...

And I gather the outputs might toggle a bit on the status change...
another issue...

Phil.

CaptainBoing

Guru

Joined: 07/09/2016
Location: United Kingdom
Posts: 1985

Posted: 01:07am 04 May 2017

Copy link to clipboard

Print this post

you might get odd pulses when the usage changes but you can easily work around that - specially if you are blinking a LED - it'll be too short to see if you do it right.

With regards to OC, it totally depends on your application of the PIC.

Open collector/OC (actually Open Drain coz PICs are MOS tech) won't "drive" HI(you have to pull them up) but they are good for dragging things LO i.e sinking current and can usually sink quite a bit of it so are good for higher loads - keep an eye on the current, but those little DIL/SIL relays etc or small tungsten bulbs can often be driven directly so long as you don't exceed the current rating for the port as a whole. Don't forget the blocking diode if needed across the relay coil, I don't think the output will stand a big spike even the 5V safe ones.

"normal" non-OC will drive HI and LO (i.e. source and sink current) - they are a bit like the old totem-pole outputs of TTL days.

so in a nutshell, OC pulls LO and you have to set them HI to turn the output effectively off and Normal will push/pull to both VDD and VSS (ish) but with smaller current capacities. There are better brains than mine here so they can probably give a better shine on my ramblings.
Edited by CaptainBoing 2017-05-05

robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2291

Posted: 02:16am 04 May 2017

Copy link to clipboard

Print this post

a useful addition to mmbasic may be to allow setting the LCD data bus pins high/low with pin(n)= or port(...)=. the limitation would be that any write to the LCD could change a previously user-set pin state, and the configuration of the pin would not be settable with setpin(n,m), being fixed as DOUT then the LCD is initialized. but the pins could still be used as a 4-bit (output only) data bus using a 5th pin as a clock output.

the same principal could be applied to pins used by a 3x4 or 4x4 keyboard, where 4 pins would be fixed as output and 4 fixed as input.

a further extenion to these ideas would then be to allow the LCD and keyboard to share the same set of 4 data pins. this would greatly enhance the versatility of the 28-pin micromites.

as far as i can see all this would require no changes in syntax, but simply involve removing a set of restriction imposed by the interpreter.

geoff: what do you think?

cheers,
rob :-)Edited by robert.rozee 2017-05-05

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3165

Posted: 04:14pm 04 May 2017

Copy link to clipboard

Print this post

The original idea behind the restrictions was to catch programming errors that could be made by a newcomer. For example, using a pin for two different tasks. This was in keeping with the style of BASIC.

BUT that impacts flexibility. It is a bit of a trade-off but I believe that you are right - most of the restrictions should go and MMBasic should only complain if the program tries to do something that is not possible (like output on an input).

I will look at it for the next version.

Geoff

Geoff Graham - http://geoffg.net

Print this page

To reply to this topic, you need to log in.