Propeller newbie question on using HC595 shift register with Spin; Ardunio code works, Spin does not
pclem
Posts: 9
in Propeller 1
I am new to the Propeller and Spin.
I have question on a simple setup with 2 chained HC595 shift registers controlling 16 LEDs.
I am trying to duplicate the behavior of some Arduino code on the Propeller; the Arduino code works just fine on my hardware setup, but the Spin version does not. The Spin works ok for the lower order 8 bits but not for the upper 8 bits of the 16 bits going out.
When I put out $0002, the first 595 shows the second bit on, all others off. Good.
When I put out $0200, the first 595 shows all LEDs off, and the second 595 shows the first and second bits on, instead of just the first bit.
The code has a commented out test counter as well, which shows the problem.
My question is what is missing/wrong in my Spin code?
(note: some code derived from Chris Savage and I am sure it is not a problem from his code).
I have attached the Arduino code which works and the Spin code which does not.
Thanks for any help.
I have question on a simple setup with 2 chained HC595 shift registers controlling 16 LEDs.
I am trying to duplicate the behavior of some Arduino code on the Propeller; the Arduino code works just fine on my hardware setup, but the Spin version does not. The Spin works ok for the lower order 8 bits but not for the upper 8 bits of the 16 bits going out.
When I put out $0002, the first 595 shows the second bit on, all others off. Good.
When I put out $0200, the first 595 shows all LEDs off, and the second 595 shows the first and second bits on, instead of just the first bit.
The code has a commented out test counter as well, which shows the problem.
My question is what is missing/wrong in my Spin code?
(note: some code derived from Chris Savage and I am sure it is not a problem from his code).
I have attached the Arduino code which works and the Spin code which does not.
Thanks for any help.
Comments
I have been struggling with whether to put everything back up on my website since I am no longer working with this stuff anymore. However, I will look at my archives and see what I can find.
Edit: See next post where I found one of my '595 tutorials in SPIN. Uses only one shift register, but could easily be modified for up to 4 with only 2 small changes.
I also tried the shift register code I found on OBEX ("Shift in out demo", 74HC595_Regular.spin) and could not get those to show the 8 MSB correctly.
So I must be doing something wrong, and would suspect my hardware setup. But like I said it shows just fine with the simple Arduino code.
How about a really good ground?
Could you post a photo?
:nerd:
Short connections and well grounded I beleive. This is the exact same setup/wires I used with the Arduino.
Photo attached.
Please try this and see if it helps.
Thanks for the post. I tried both ways and got the same result.
'high8Bits := data / 256
'low8Bits := data // 256 'modulus
high8Bits := data >> 8
low8Bits := data & $00FF
The photo attached shows the result of an output of: dataOut16Bit($0100), LEDs 1,2 on the second shift register being on instead of just LED 1.
An output of dataOut16Bit($0200) results in LEDs 3,4 being on. That may be a clue, but once again the exact same hardware/conneciton setup on the Arduino works correctly.
Edit: Are you using a 5 volt Aduino?
Yes. When the board is hooked to the Arduino, it is plugged into the 5 volts. Same with the Propeller.
Hi Larry,
Not sure I understand. The LED blink pause, is pausing correctly for 1 sec.
If pauseMS is 1000, then my Pause function would work out to be:
waitcnt(clkfreq / 1000 * 1000 + cnt)
And I seems to pause as intended.
Am I missing something that your are saying?
clkfreq / 1000 * 1000 = 1 second
A one second pause simplifies to
I swapped out the 595 chips and pulled the jumper wires on the breadboard and re-pushed them in. I did not find any thing that was wired up incorrectly, but it now works on the Propeller and oddly it still works as it did before on the Arduino. Perhaps a glitch in the breadboard? Don't know.
It is a bit of an unsolved mystery, but I won't argue with it. It now works as it should.
Thanks again.
I refer particularly to outa[SR_DATA] := bits <-=1. I get it that it left shifts after the := part, but I don't see that the data bit chosen is necessarily bit 31.
When the 'rotate left 1 bit' is completed, the MSB will now be at the LSB. Since the assignment is a bit value, the LSB appears at the I/O pin connected to DI on the 74HC595. The reason I do it this way is because we're shifting the bits from the MSB first, so this accomplishes that task in the right order.
I don't see the need for all those delays in the previous examples. I empirically tested the speeds and the SPIN language can't exceed the speed of a 74HC595. The delays are just wasted code space and complexity, not to mention, delays...something you typically want to avoid.
When I talk to shift registers in Tachyon Forth I can setup the pins with a single instruction and then all I need to do to write 16-bits over SPI is use the SPIWR16 instruction which takes 4.8us to execute. I recently interfaced to 8 shift registers connected to bar-graph LEDs so I simply used two SPIWR32 instructions to write all 64-bits from a buffer in under 20us.
So there is no need to insert any kind of delays in Spin, that's for sure.
The symptoms of no decoupling is exactly this kind of random behaviour, and its very common driving high current loads like LEDs (yes LEDs are high current loads for a logic signal).
Never use a logic IC without at least one 100nF ceramic cap for supply decoupling, unless you want things to go wrong at random!
The change from 5V to 3.3V clearly caused the behaviour to change between Arduino and Prop, again exactly the sort
of thing I'd expect without decoupling.
Peter, agreed! As of when I wrote that code every example SPIN object I saw had delays between each bit, between the latch pin toggles and between bytes going out. None were ever necessary. I haven't worked with this in over a year, but IIRC even PASM wouldn't require delays for the bits shifting when running at 80 MHz.
To JonnyMac: Thanks for the jm_595 code. I will learn from it.