1) Has anyone done this before (I'm guessing "many times" is the answer) and thus would this general approach work?
2) Is the "interference issue" really an issue or am I just being overly cautious (ahem!) and worrying about nothing?
3) Would there be any issue sending the shift register output (which I assume is either +5V/HIGH or GND/LOW) through a jumper (male header), over ribbon cable and to the input pins on the LCD's PCB, which will be placed about 3 to 5 inches away from my primary PCB?
Hi-Software engineer here with a request for any feedback the hardware types might have regarding a design to augment the base I/O capability of my design. I have a plan, but so did Custer (well actually I don't think he did, but I digress), so I thought I would pose it here for a sort-of review if you will. I'm designing a hand-held device that will have a 4x4 membrane keypad (will use the keypad library for that), a HD44780 LCD and 8 LEDs to represent system state.And as is seemingly-customary with these projects, I have exhausted the available I/O in my current design. I'm using an Amtel 1284, but despite the 32 I/O pins that are available OOTB, by the time a couple of internal components plus the general SPI and I2C pins were allocated, I only had 14 pins remaining. In summarization my needs follow:8 pins for keypad6 pins for LCD (using 4-bit data transfer, 1 for RS, 1 for EN)8 pins for the LEDsThat brought my total to 22 pins that I would need to implement the UI components. 14 - 22 = a problem. So as I mentioned, I came up with a solution that involves two shift registers (SN74HC595) that I plan on daisy-chaining together using a common latch pin. With this design, I could even use 8-bit data transfer for the LCD, so I thought 'why not?' and made that change too. This changed the allocation of the 14 remaining pins thus:8 pins for keypad (unchanged, will use direct digital pins for this)3 pins for the LCD and LEDsTotalling 11. 14 - 11 = much better story. So that's the introduction. Now a quick rundown of how I plan to implement the LCD/LED stuff. Really, the problem is made simple because I plan to put the shift registers on the SPI network and use the SPI.transfer() method to shift-in data. Thus the already-existing MOSI line is used for the data in to the first shift register and I'll chain the output of that one to the input of the second, and the SCLK line goes without mention. As for the 3 pins required from the MCU, the first will be the common latch pin that I will run in parallel to each shift register. The second will be a dedicated pin for the RS input to the LCD and similarly for the LCD EN pin. The idea being that whenever I want to send display data to the LCD, I simply pull the latch pin low, SPI.transfer() in the data, pull it high and then the data goes over SPI to the LCD. I will modify the existing LiquidCrystal library for my application to perform this type of operation in the sending function. I've looked and the mods for that are straightforward. Again, since they're available, I would just use all 8 pins from the first shift register as the data pins for 8-bit transfer to the LCD, while the RS and EN pins remained as separate, dedicated pins directly from the MCU. And I will connect the output from all of these pins to the LC'sD PCB via male headers (pins) on both my primary PCB and the LCD's PCB via ribbon cable and female ribbon cable connectors. And just for completion, the LCD I plan on using is like this one: http://www.adafruit.com/products/198And then of course for the LEDs, you simply add a second SPI.transfer() of data so that the first is the LED data and the second is the LCD stuff, no problem. I'll have a software buffer for each such that I can reload the shift registers with the old data if nothing changes for one of them. I decided on that because I'm not certain if these critters are susceptible to interference such that unwanted data could be pulled in during the period when the latch pin was pulled low, thus changing the output in an undesirable and inaccurate manner. The scenario I had in mind for that was needing to update the LCD but not the LEDs. With a common latch pin, if I only shift in 1 byte of data, that only affects the LCD output. However if interference was a possibility, then while the LED shift register was pulled low and LCD data was loaded into the LCD shift register, then bogus LED output states could be displayed. Seems improbable to me somehow, intuition-wise, but what do I as a software type know, right? Hah!A better solution seems to be to separate the latch pins for the two shift registers, but I am holding all available MCU pins in reserve for now, 'cause you never seem to have enough pins. If in the end I have one to spare, then I will indeed separate the latch pins, not worry about the "interference issue".So. The basic questions here are:1) Has anyone done this before (I'm guessing "many times" is the answer) and thus would this general approach work?2) Is the "interference issue" really an issue or am I just being overly cautious (ahem!) and worrying about nothing?3) Would there be any issue sending the shift register output (which I assume is either +5V/HIGH or GND/LOW) through a jumper (male header), over ribbon cable and to the input pins on the LCD's PCB, which will be placed about 3 to 5 inches away from my primary PCB?Thanks!
Thanks to everyone for the feedback. I decided to go with this approach, though I switched from SN74HC595s to TPIC6C595s per the advice of CrossRoads. I have it wired and routed on my board now. DRC and ERC pass cleanly, so that's something. ;-)I didn't go the I2C route, except for the RTC, with this design simply because the 1284 provides a fair amount of I/O pins, so might as well use 'em. Also, I wanted to get some experience with shift registers.Anyway, thanks again!
NO worries - when complete you should post up for others to learnCraig