ShiftPWM - problem

Status
Not open for further replies.
A

AdmiralCrunch

Well-known member
hi

I'm struggeling with this for more then 4 weeks now and can't get that managed, please help :/

I have those UTC U74HC595AG Shiftregisters of which I have wired 3 of them in a row like described in those numerous tutorials.
(the Qh-Pin of the first IC to the Data-Pin of the second.. the Qh-Pin of the second to the Data-Pin of the third) .. now I need to get shiftPWM working.

When I execute the ShiftPWM_RGB_Example.. something lights up, but I couldn't retrace why what lit up.. so I tried this:
Code: 
const int ShiftPWM_latchPin = 6;
#define SHIFTPWM_NOSPI
const int ShiftPWM_dataPin = 5;
const int ShiftPWM_clockPin = 7;
const bool ShiftPWM_invertOutputs = false;
const bool ShiftPWM_balanceLoad = true;

#include <ShiftPWM.h>

void setup() {
  Serial.begin(9600);
  ShiftPWM.SetAmountOfRegisters(3);
  ShiftPWM.SetPinGrouping(8);
  ShiftPWM.Start(75, 255);  
}

void loop() {
    ShiftPWM.SetAll(0);
    delay(500);
    
    ShiftPWM.SetRGB(0,100,0,0); 
    delay(500);
    
    ShiftPWM.SetRGB(0,0,100,0);  
    delay(500);
    
    ShiftPWM.SetRGB(0,0,0,100); 
    delay(500); 
}

this should light me up the first LED in red.. then in green... then in bue.. right?
but look what it does: https://youtu.be/8IctLHeVx6o

otherwise, when I try the NON_Blocking-example, nothing works :/

has somebody experiance with this? .. i would appreciate any help :)
 
Looks like a Teensy 3.2. I tried running your code on a 3.2 here, plugged into the old test hardware I built for Teensy 2.0. Had to use an extra pair of sockets to raise it up above the chips.

Here's a video of what it's doing here, running the code you posted. The only edit I made was for the pin numbers, since this board is designed for clock on pin 1, data on pin 2 and latch on pin 8.

 
I'm pretty sure they're not supposed to turn all white around 0:28. Something strange is going on. Maybe a bug in the library?

I don't have time to do more than this quick test at this moment, but I'll leave the hardware out as a reminder to look into this soon....
 
Hi Paul,

thank you for your time :)
Which Teensy are you using?
Click to expand...
.. yes, you are right.. it is the Teensy 3.2

Here's a video of what it's doing here, running the code you posted
Click to expand...
Oh.. now that is curious.. oO .. maybe two stupid questions on this:
1) why is it lighting up the second, fourth, sith, etc .. ? .. is my understanding, that it should light up only the first one, wrong?
2) is there a recommended IC to use with the libary? .. I use this U74HC595AG.. should I buy a other one?
 
For use with Teensy 3.2, if the chips run from 5V, then you should use 74AHCT245.

There does seem to be some sort of strange bug with this library. I'm currently working on USB EHCI, but I'll put this on my list of libraries to debug...
 
PaulStoffregen said:
For use with Teensy 3.2, if the chips run from 5V, then you should use 74AHCT245
Click to expand...

hi,

I run it all from 3.3V .. should I use a 74AHCT245 in this case, too?
I have studied the datasheet of 74AHCT245 but I don't get it, what it is for (what it does) .. is there a tutorial on this?
 
tonton81 said:
its a buffer that takes the mcu 3.3v as inputs and outputs it as a logic 5v signal
Click to expand...

Hi,

mhkay.. but why do I need that? I mean, Paul wrote "if the chips run from 5V, then you should use 74AHCT245" oO

does it the same job like I would attach a 100nF-capacitor between 3.3V and the Vcc-Pin .. and one 100nF-capacitor between GND and the GND-pin of the 595 ?
 
Oh, opps, sorry. I meant to say 74AHCT595.

The same '595 shift register this library is meant to use. The "T" in the middle of the part number means it's guaranteed to be compatible with the 3.3V logic output.
 
PaulStoffregen said:
Oh, opps, sorry. I meant to say 74AHCT595.

The same '595 shift register this library is meant to use. The "T" in the middle of the part number means it's guaranteed to be compatible with the 3.3V logic output.
Click to expand...

aaaaaaaaaaaahhh.. thanks :)) .. since you wrote that yesterday I was so confused I thought about giving up^^ .. I will get some of those and try it out :)

Edit: .. maybe one more question on this (sorry ^^):
.. there are so many models of that IC .. the most common I fould are SN 74AHCT595 PW/PWR/D .. what does that mean? can I use those?
 
Last edited:
The letters on the end indicate the package type for chip. D means SOIC (bigger surface mount) package. PW means TSSOP (smaller surface mount) package. Without the "R", they come in tubes. With the "R", they come on tape in reels, which is extremely convenient if you're using them in high volume production, but usually it means a minimum buy of 2000 or more.

If you want easy-to-prototype DIP package, get the ones with "N" on the end.

The meaning of these letters is documented in the "Packaging Information" section of the datasheet. Each manufacturer has different letters, so make sure you're looking at the datasheet from the correct company, since several of them make this chip.

And just to confirm, the library seems have a pretty serious bug (or my HC parts are really bad). I've left this running on my desk since yesterday and it's doing all sorts of crazy colors in weird patterns. At the moment I'm working on EHCI USB, and I'm waiting for those chips to arrive so I can test with the proper AHCT parts. Will look into why this isn't working in the next week or two.
 
hey Paul,

big thanks for the explanation :) .. now I see clearer :))

I forgot to pull the USB-cable yesterday before I went to bed, and when I woke up for work I too had some real strange patters running.. the strangest about it was, that I had only
one
ShiftPWM.SetRGB(0,100,0,0);
Click to expand...
in the loop and nothing else.

but I have connected it all to a UNO and tried the UNO-libary.. it works there.. so the ICs and the circuit are ok ..but it is useless for me anyway because i NEED to get it running on a teensy :) .. so I wait impatiently :)
 
Hi Paul,

I don't want to bother you, but I need to ask if you could find some time to take a look on the lib (?)

If not, maybe you have a hint - or at least a advice how to debug - so I could take a look by myself.
 
This one is on my issues list. Sorry, can't do anything on this until I wrap up a 1st beta for the USB host library.

I don't have any specific suggestion beyond start reading the code. This library has a somewhat complex coding style, so it's not so easy.
 
AdmiralCrunch said:
Hi Paul,

I don't want to bother you, but I need to ask if you could find some time to take a look on the lib (?)

If not, maybe you have a hint - or at least a advice how to debug - so I could take a look by myself.
Click to expand...

Here is something to try (I don't have the shift-register hardware to test): in ShiftPWM.h change all digitalWriteFast() to digitalWrite().
I know there is a conditional SHIFTPWM_USE_DIGITALWRITEFAST, but messing with that seems to stop pins on teensy 3.2
 
Last edited:
At first I did not think that would make a difference. But for the fun of it I ran the original code in the thread... I don't have the hardware, but hooked up Logic Analyzer to the three pins. And when I ran it it was sort of strange, it was only showing 3 clocks total during which the latch was low... I changed the digitalWriteFast calls to simply digitalWrite and now getting the 24 clock cycles I was execting.

So give it a shot!
 
KurtE said:
At first I did not think that would make a difference. But for the fun of it I ran the original code in the thread... I don't have the hardware, but hooked up Logic Analyzer to the three pins. And when I ran it it was sort of strange, it was only showing 3 clocks total during which the latch was low... I changed the digitalWriteFast calls to simply digitalWrite and now getting the 24 clock cycles I was execting.

So give it a shot!
Click to expand...
I observed the same thing, though i think it is due to the writeDigitalFast() being faster than my 50mhz analyzer limit. On the other hand, the fast toggling may be too fast for the shift-register IC .... or not (need to check datasheet for specific IC being used)

EDIT: also running the T3.2 @24mhz reveals the 8 clock pulses on the analyzer
 
Last edited:
Yep I am running my Analyzer at 500mhz for 3 channels. Which should hopefully be fast enough to catch most transitions.

Here is what it looks like after I made the change:
screenshot.jpg

What I was seeing before the change:
screenshot.jpg
 
Well, i did have a few 74hc595s laying around. i ran simple single pin loop
Code: 
  for (int i = 0; i < 8; i ++) {
    ShiftPWM.SetAll(0);
    ShiftPWM.SetOne(i, 255);
    delay(1000);
  }
on T3.2. The pattern was funky at 96mhz but OK @24mhz, 48, and 72mhz. So at least for 74hc595, the T3.2 digitalWriteFast() is too fast @96mhz. If you replace digitalWriteFast with digitalWrite (ShiftPWM.h) the pin loop runs properly even at 96mhz or 120mhz.

SetRGB(), SetAll(0) and SetAll(255) work as expected. Logic analyzer confirmed 75hz PWM with various duty cycles on LED


EDIT: Tested on T3.6, works @72mhz or slower, also works @180mhz and @240mhz with digitalWrite in place of digitalWriteFast
 
Last edited:
Wonder what would happen if you added a delayMicrosonds(1) before setting the clock high... and/or several NOPS or simple loop. Quick look at spec says max clock of maybe 20-30 megahertz.... Or as mentioned move to digitalWrite... Which probably slowed it down enough...
 
PaulStoffregen said:
Looks like a Teensy 3.2. I tried running your code on a 3.2 here, plugged into the old test hardware I built for Teensy 2.0. Had to use an extra pair of sockets to raise it up above the chips.

Here's a video of what it's doing here, running the code you posted. The only edit I made was for the pin numbers, since this board is designed for clock on pin 1, data on pin 2 and latch on pin 8.
Click to expand...

Paul,
can you try shiftPWM sketch again on your test harness, replacing digitalWriteFast with digitalWrite in ShiftPWM.h
 
Yes, this still on my desk, still waiting... will get to it soon.

At the moment, updating the MKL02 chips (for DIY boards) to support K64 & K66 is my top priority. Can't look in to this lib until those chips are shipping.
 
KurtE said:
Wonder what would happen if you added a delayMicrosonds(1) before setting the clock high... and/or several NOPS or simple loop. Quick look at spec says max clock of maybe 20-30 megahertz.... Or as mentioned move to digitalWrite... Which probably slowed it down enough...
Click to expand...

I did some more experiments. I tried just replacing the last digitalWriteFast (digitalWriteFast(clockBit, HIGH)) with digitalWrite(). That worked EXCEPT for T3.6 @240mhz. So probably one should replace all digitalWriteFast with digitalWrite

EDIT: Replacing the clockBit HIGH and LOW digitalWriteFast with digitalWrite seems to work on T3.6 even @240mhz. Also note that my test setup with analyzer is with breadboard, 74hc595, and jumpers.

KurtE I am still not sure why your 500mhz analyzer didn't see those digitalWriteFast clock pulses ??
 
Last edited:
My guess is that it was so fast, that maybe the Teensy hardware never had a chance to get it up to voltage before it turned it back off... I could turn on Analog reading, but I could not go that fast. I think the max it will go for analog is 50M samples per second...
 
Status
Not open for further replies.
Back
Top