Shift registers parrallel to serial: do I need to ungroup them ?

[jean_prieur]

Posted on May 22, 2013 at 17:23

Hello,

I'm working on an interface based on STM32F407 with 48 buttons. I use 74HC165 shift registers parrallel in/serial out to multiplex my buttons states.I need to cascading 6 registers to connect the 48 buttons.This is my question: is it preferable to cascading the 6 registers or to ''ungroup'' them and cascading them 3 by 3 ? I mean, 3 registers are chained and communicate with the microcontroller, and 3 others registers are chained and communicate with the microcontroller with another pins.What is the best way to optimize the communication speed ?

[jean_prieur]

Posted on May 23, 2013 at 16:38

Thanks for the tips, I had not thought of that! 

[jj2]

Posted on May 23, 2013 at 16:55

Above is the general scheme - keypad is driven by your 6 ''outputs'' - and 8 keypad inputs are routed both to the Nand Gate & to the MCU.   Biggest job for MCU SW is the ''read'' of the keypad - which now can be confined to, ''only when a keypress has been detected!''  (via the Nand gate generating an interrupt) All outputs must default ''low'' - so that any keypress will transfer that low onto the MCU.  The interrupt will then make a call to Keypad Scan Routine - which will drive one and only one of the keypad outputs successively low - enabling your matrix decode. You can reduce GPIO usage by using a shift register to generate those keypad outputs.  In this case I would configure the keypad for 8 outputs - 6 inputs.  Again - shift register must default w/all outputs clocked low - which enables the Nand gate's detection of any keypress.  In this case - the Keypad Scan must generate the ''walking low'' via the shift register - thru a series of outputs to the shifter.  It will likely cost 3 GPIO to transact w/the shifter - netting you 5 GPIO.  You trade ease of programming - and decode speed - for the conservation of GPIO... Should add that all input lines must be pulled ''high'' - either by external pull-up Rs or by MCU's internal - as/if present.  Keyswitch closure will then transfer the MCU's output low onto the MCU inputs and Nand Gate - enabling key detection and matrix-position solution...

[Tesla DeLorean]

Posted on May 23, 2013 at 22:10

Interesting eBay boards with LED, 7-SEGMENT and BUTTON chip

http://www.ebay.com/itm/8-Bit-LED-8-Bit-Digital-Tube-8-Bit-Key-TM1638-module-for-AVR-Arduino-ARM-STM32-/251116139165?pt=LH_DefaultDomain_0&hash=item3a77b0329d

[[this link/image has been flagged as malicious by our security scan software and has been deleted]]

[jean_prieur]

Posted on May 24, 2013 at 11:20

Hi everybody,

Thanks for all theses insteresting comments, I think for my current project I will consider the degrouped registers (2 * 3 registers for 48 inputs) and scanning them every 10ms thanks to the power of the STM32F4, but for my future designs I will experiment matrices for proper work.

[jj2]

Posted on May 24, 2013 at 17:18

Horse has likely long left this barn - but one final comment.  (from this guy)

Your decision enforces 24 clocks (same pulse) to be regularly output to each ''bank'' of 3 shifters.  And 2 GPIO must monitor the returned data upon each/every appropriate clock edge.  This does place a SW burden upon the MCU - and the expected keyboard/pad duty cycle is very low - so this burden is continuous - even during long periods of keyboardinactivity... Might there be a better way?  I'd bet that your shift registers could be clocked via non-MCU HW - and the 2 serial data shifter outputs could then trigger a MCU GPIO Interrupt - upon any keyboard activity!  In this manner - the MCU is freed from its continuous shift register transactions - becoming solely interrupt based.  You must devise a means to track the number of clocks - post shifter reset - to determine which key caused/causes the interrupt - but my initial sense is that this suggestion has merit...  (lightens the load upon the MCU)

[jean_prieur]

Posted on May 29, 2013 at 13:36

Hello jj.sprague,

The horse is still in the barn :)I don't understand how the 2 serial data shifter outputs could trigg a MCU GPIO Interrupt... Because it's serial datas and you need to scan them every time to detect a change !Otherwise, I want to know how long it will take for scanning my registers ? I mean, If have 24 bits in my registers, I need to generate 24 pulses for the clock and read the output each time. If the GPIO speed is 50MHz, can I calculate the scanning duration like this :(24 clock + 24 read) * 50MHz = 0,96 usIs my estimation correct ? Thanks !

[jj2]

Posted on May 30, 2013 at 22:21

1: ''How... 2 serial data shifter outputs could trigger a MCU GPIO Interrupt''

Yours are parallel to serial devices - thus your 48 bit, parallel data chain routes to and is reduced to just 2 serial outputs - each driving an MCU GPIO.  Assumed is that your keyboard/pad will close its active switch (to ground.) (and you will likely require 48 individual pull-up Rs.)  Now when the keyboard/pad is inactive - only logic ''high'' will appear at each serial output from the shifters.  Upon a key-press - that expected ''low'' will be propagated thru your cascade of shifters - eventually making its way to your GPIO.  If that GPIO is set to interrupt upon logic ''low'' - voila - interrupt generated.  Now there may or may not be ''glitch'' upon shifter's serial output - when shifter is clocked and no keypress occurs.  Simple R-C can ''hold-up'' the MCU's GPIO input - so that only a valid (sufficiently long) keypress will trigger your interrupt.  May depend upon the character of your PISO IC - too.  (more sophisticated ones enable the latch of your parallel data - but added MCU GPIO demands eat into your GPIO ''savings.'')   Clearly - matrix method - recommended by several here - vastly superior... Upon the clocking of the shifters - any captured ''low'' upon shifter's inputs will eventually ''bubble thru'' to the MCU's GPIO - (2 of them) and that GPIO is programmed to, ''Interrupt on high to low edge.''  The whole purpose of your shifter exercise was to save several MCU GPIO - which does occur - but at the cost of programming ease and added HW. 2: ''GPIO speed is 50MHz, can I calculate the scanning duration?'' While your MCU may yield such GPIO rates - my belief is that you are asking for/inviting trouble.  And - that 50MHz may exceed your shifter's max clock input - especially when married to an imperfect pcb or proto board.  You are limited to that speed of the slowest device in your chain!  Pardon but your drive for speed seems way premature.  We always follow KISS - get something basic working - only then attempt to optimize.  Earlier poster suggested 100Hz as scan speed - which works well for us.  (that's all 24 keys - each bank - scanned/read 100 times each second - about 400uS/key if back of napkin calc serves...)   You need not have the MCU drive shifter clock - as stated earlier - simple R-C osc. - free from the MCU - quite up to that job.  In that manner the MCU only has to perform the read upon interrupt - and bit more complex task of identifying, ''where in the clock sequence'' your ''hit/bit'' keypress occurred...  (and that's a different thread - which will not be required when you adopt far more sane 8x6 matrix approach - many times suggested) 

[jean_prieur]

Posted on May 31, 2013 at 18:04

Thanks for the explanation jj ! Again a very good solution to scan my keys, like the matrix solution.

Because I'm not limited for my current project by GPIO pins, and I have not a lot of time, I think I'm gonna choose the solution of parralleling registers (this is already working).This is why I wanted to have a duration estimation of my registers scanning...