Hello again.
Thanks to people on this forum I have been able to successfully scan 8 shift registers with my UNO.
Eventually I want to expand up to 20 shift registers.
From a speed point of view, is it better to break up the shift registers say into groups of 10, and scan
them with 2 'ports' (the 4 controlling wires on the UNO), or just scan all 20 from the one 'port'.
Which would result in faster scanning of the inputs?
Any help very much appreciated.
YOu should check the SPI bus so you can use the build in hardware.
Alternative is to use one of my libraries which are optimized versions of the normal shiftIN/Out
Thank you for your time to reply to my query.
I was not aware of your fast shift in or out libraries. I will take a look at these.
Thank you again for your suggestions regarding the SPI too.
Regards,
Eventually I want to expand up to 20 shift registers.
At that many it might be better to buffer the clock and latch pins into groups of 10.
As long as you don't have 2 (or more) hardware SPI ports or a software SPI which can handle shared clock and latch it makes no difference. Or you read them serial over a single line or you read those groups after each other. If you don't read them in parallel there is no gain.
Thanks for all the suggestions, I have been reading up on each option carefully.
One thing I am not totally clear on. Can I use the Uno's SPI interface at the same time I am using the TX
pin (1) on the Uno for MIDI data sending? I would be using the Arduino midi library
Best Regards
One thing I am not totally clear on. Can I use the Uno's SPI interface at the same time I am using the TX
Yes they use different hardware modules inside the processor.
pin (1) on the Uno for MIDI data sending? I would be using the Arduino midi library
Yes you could. However a libiary is not necessary, it just takes three lines to send a midi message so a library is not really necessary. You hVe to have something like hairless on the computer that receives it to make the serial signal look like a MIDI device.
Hello again.
I appreciate all your responses to this Arduino newbie!
Thank you again, Grumpy_Mike, Septillion & Rob Tillaart,
Well this morning things took a turn for the worse. Smoke!!
To fill you in on the background.
My test bed is 6 six 74hc165 shift registers in series set up with dip switches. Simple enough.
I have been running the clk, clk_enable, shift/load and data from Uno pins 8, 9, 10, 11.
The midi output was taken from pin 1, the TX pin of the Uno.
I wrote a program based around shiftIn, which scanned the switches and when moving the switches sent a note via midi (uno pin 1) to a 'midi to usb' adapter to my PC. The PC plays the corresponding note via software. The USB programming cable was disconnected from the Uno during these tests, and the board was run off a 12 regulated supply to the barrel jack. All working well. It even worked with a real midi keyboard too. Great!
As I said, all was working well and for several days no problem. My only concern was the scanning speed of the shiftIn command, especially when adding many more shift registers, so I followed the suggestion of SPI reading the shift registers.
I made the following changes.
The new version of the program was loaded (with midi disconnected) and Arduino was powered by USB via computer. All loaded fine. I pressed reset and watched the Arduino reset with all the usual lights.
I completed one more final check of wiring and then unplugged the USB cable from the Ardunio and the PC. It was placed aside.
I connected the USB to Midi cable to the PC, then connected it to the Arduino board. I plugged in the 12VDC power supply. Instantly I knew something was wrong as the TX & RX lights glowed dimly and flickered, (I thought this might be something to do with the SPI, but wasn't sure). A split second later smoke erupted from the Atmega 16u2 chip. (Insert sad face here!).
I checked, and rechecked my connections, but can't find an error. I also can't work out why the USB to serial chip failed as it was not part of what I was doing (or am I missing something?)
Post mortem on the board is the 16u2 is blown & the regulator is only putting out 1.2 volts. Ironically if I feed 5V to the Atmega 328 micro it seems to be still alive and possibly running the last code I downloaded to it. (using a scope I checked the sck and shift/load pins and there is a square wave present).
So, my questions are. What happened?
Is there anything I could possibly enter into code that could fry the 16u2 chip?
Was using SPI library and Midi library together a no, no?
Or, maybe the 12 volt supply just too much for the voltage regulator (I think I may have a clone), and it just chose that moment to fail (unrelated to code or wiring)
Any idea's or thoughts much appreciated.
Best regards to all.
Is there anything I could possibly enter into code that could fry the 16u2 chip?
Quite simply no.
You have missed telling us about a lot of detail in this thread before now. So how is the MIDI actually connected to your Arduino? If it is through pins 0&1 then they are connected to the 16u2 chip as well as anything else you connect to it so if you have a mistake in the MIDI interface or what you plug the MIDI into could cause a problem.
Thanks Grumpy_Mike.
I didn't think code alone could do this.
What I may not have said in my post was I tested the shiftIn code 10 mins prior to the SPI code. Midi connections were not changed from one to test to the other. Only the MISO, data and sck pins, so it is strange. Perhaps something touched something else without me noticing.
Once I obtain a replacement board I will regroup and try again.
Thank you Sir for your help, it has been invaluable. I do apologise if my questions have not given a bigger picture, I've just tried to keep questions simple and on-point.
Best Regards to you and your fellow forum helpers.
Perhaps something touched something else without me noticing.
I would say this is the most probable cause.
Hello again.
A quick update!
I received a replacement Uno and hooked up my project once again.
All is working fine, same wiring, same code. SPI is very fast compared to shiftIn, over 20 times faster!
One question though. It has been suggested I buffer the latch and sck pins if I am going to drive 20 shift registers. Fair enough.
I figure it has to be 5 volt compatible and a non-inverting buffer. The clock is running at 4Mhz. Do you have a suggestion which chip might be suitable?
Best Regards.
Never really measured if it's a problem but I guess better safe than sorry 
But almost every 74xx logic chip would do. Logical choices would be 7404 or 7407. Inverting isn't that problematic either. You can just use two inverters in series to end up un-inverted. You can even invert it in software. Just invert the latch states and use SPI mode 2 instead of 0 and 3 instead of 1.
Just to be clear feed the Arduino to one inverter of a 74LS04.then feed the output of this to all the other inputs of the inverters. Then the output of each inverter can feed 20 shift registers.
Thanks guys.
So your saying, for example, on a hex buffer feed the sck into one buffer, then the output of that buffer to the input of the remaining 5. Use those 5 outputs to drive the 20 shift registers in groups of 4?
This would mean 2 hex buffers are required, 1 for sck and 1 for latch.
Am I understanding that correctly?
Best Regards.
I'd suggest a part like SN74AC541, with 24mA drive current. Very quick on propagation delay.
Family type is important. (vs CD74AC541, really slow propagation delay)
https://www.digikey.com/product-detail/en/texas-instruments/SN74AC241N/296-4308-5-ND/375881
lpme126:
So your saying, for example, on a hex buffer feed the sck into one buffer, then the output of that buffer to the input of the remaining 5. Use those 5 outputs to drive the 20 shift registers in groups of 4?This would mean 2 hex buffers are required, 1 for sck and 1 for latch.
Am I understanding that correctly?
Yes.
Or just use one 74xx04 and feed one Arduino output to one buffer and the output of that to two others. That uses half the chip. Repeat for the other signal, then you have enough to drive two lots of 20 shift registers.