Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
|
Forum Index : Microcontroller and PC projects : Sharing Pins?
Author | Message | ||||
Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
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. |
||||
jman Guru Joined: 12/06/2011 Location: New ZealandPosts: 711 |
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 KingdomPosts: 1985 |
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. |
||||
Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
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 KingdomPosts: 1985 |
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. h |
||||
Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
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 KingdomPosts: 1985 |
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. |
||||
Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
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 KingdomPosts: 1985 |
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. |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2291 |
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 :-) |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
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 |