74HC595 object help

Dennis Ferron

Edit: I changed the name of this thread from "Obex Etiquette" to "74HC595 object help" so that if people in the future search for help about the '595, they can find the thread more easily.

Considering how much the 74HC595 is used in Basic Stamp labs, I was surprised to find out the Obex doesn't have anything for using the 74HC595 shift register with the Propeller. So, on Saturday I wrote a simple 74HC595 object and posted it to the exchange. I quickly realized that I needed some more powerful features for my own project, so on Sunday I wrote a Super Advanced Whizbang MultiPWM 74HC595 driver that can bit bang PWM on any or all of thirty-two 74HC595 outputs at once! (Gives 32 PWM channels using only 3 Propeller pins.)

Now I have a dilemma: do I post the new object as version 2.0 of the original, or do I post it as a completely separate object? It is mostly backwards compatible with the first one, but I completely changed how it works internally. I could see someone maybe wanting to use the simple version because it is easy to understand how it works (the new one is better, but no longer simple!). On the other hand, if someone downloads the simple one, I'd like them to know there is a more advanced one available. I could do that by including both versions in the zip file.

What's the protocol here? Will I annoy people if I spam the Obex with a few different but similar objects?

Also, the eventual use of this thing is that it will in turn be wrapped in another object that does PWM on 754410 motor driver chips connected via 74HC595's. I want to control a robot arm with three or four 754410 motor drivers, but that would take 18 to 24 Propeller pins (six per motor controller chip). By connecting each 754410 to the outputs of a 74HC595, you can control between one and four of them off the same serial bus, and once you have the first one connected you don't need to change your code or use more pins to add extra motors, you just continue the serial bus. So eventually I'll have a 754410_via_74HC595 object that uses the 74HC595_MultiPWM object internally. Does this wrapper rate it's own separate entry under the Motor Control category, or should I put all 3 objects in one zip?

Which leads me to my final point: The categories in the object exchange don't cover everything they need to, and there is no "Other" category. A particular problem is that there are a ton of drivers for specific peripheral chips where the chip doesn't really fit into any of the categories, so it's unclear where to put it. For instance, I chose "Communication/Protocol" for my 8255 driver under the tenuous association that it implements the 8255's "protocol" and that the 8255 can be used for communication. I put my first 74HC595 driver in the same category merely because I've established the precedent with the first driver, and I really didn't have a better idea. Ultimately I will wrap the object in one I will use for motor control, but the bare 74HC595 driver really has nothing specific in it related to motor control and could be used for other things anyway. But I don't think the "protocol" category is a very good place to be a catch-all for everything else. Either we need an "Other" category, or some more categories based on looking at what we already have and what doesn't fit well currently. I recommend establishing a "driver" category that is for drivers for specific chips.

Post Edited (Dennis Ferron) : 4/4/2009 8:26:23 PM GMT

SRLM

I have no experience really with the obex, but here's what I think you should do with your two versions: name one 'simpleXXX' and the other 'fullXXXX', and include them both in a zip. That way, users can choose, but it still maintains the integrity of the sort.

sylvie369

I vote for keeping both as well. When I use these objects, I hope to learn from them. Having a simple and an advanced version should help.

jazzed

SRLM has the right idea. One package per device per person seems reasonable.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

virtuPIC

Oh yes... This propeller stuff is really demanding it terms of etiquette. I feel demanded to write software that uses as few hardware as possible besides the prop. At least as few active parts as possible. Optimally no active parts.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys

Dennis Ferron

Good point virtuPIC. It always begs the question of why trouble with a peripheral chip when the Propeller can do the same function? For instance, instead of using four 74HC595's to get the extra pins, I could have used one extra Propeller chip, connected via a serial link to the master Propeller. I've found in previous projects, however, that having to program multiple microcontrollers in the same robot has its own pitfalls, because often you need to make changes to the software of both of them, and that doubles the time it takes to get the chips programmed for each test run because now you're reprogramming two things not just one. Not much time individually, but it adds up. With a "dumb" output device like a shift register, the device itself just works one particular way and that's it, so once you have the basic setup working you don't need to touch it again. There's trade-offs involved either way. On my current robot, I'm using a mixture of peripheral chips and extra Propellers. I decided to do the motor control using shift registers to get more outputs without adding another Propeller, but I am adding a 2nd Propeller to do GPS and compass navigation, and a third Propeller controls the sensors.

virtuPIC

When choosing hardware I am looking from the business point of view. I try to compare cost and yield. 4 x 74HC595 vs. 1 X P8X32A + 1 x XTal? Well, speaking in dollars it's simple: The prop would cost at least the five-fold amount of dollars (or euros). However, I would have to solder 42 pins instead of 64. It needs different amount and shape of area on the PCB. It can also perform other tasks like post-processing the data it spits out. It has completely bi-directional connections. And and and... Oh, there are also the options of 2 X MCP23016 or 4 x MCP23008...

Oops.. I've lifted off mentally. Let's get back to earth. Currently, I consider it demanding - at least for me - to develop applications as versatile, as strange, as powerful as possible... applications nobody would have dreamed of a few years ago to be possible with such a small, inexpensive, and a singe microcontroller. The main gain I get from the prop is fun, knowledge, and experience.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys

rjo_

Dennis,

Your documentation is really wonderful. The tone is great.

Having the simple object is essential... the more complicated functionality of the full object really obscures the basic logic. Maybe you have hit upon a new OBEX standard... an absolutely basic object and then a "gee-wiz looky what you can do with this."

I happened to have one of these chips(from Philips) and wanted to use it a while back... I read the datasheet and promptly put it away[noparse]:)[/noparse] After reading your stuff, everything seems to make sense... probably just an illusion... but an illusion I can live with for the moment.

Thanks,

Rich

rjo_

Dennis...

I finally had a chance to actually sit down and hook up the chip to take your code for a test drive ... I ran the simple version. I only modified it to leave a pin high... and then enter an endless Repeat. I tried it on a couple of different pins. My Prop is fine. But I'm getting nothing out of the chip. You have examples of the call ...

Your documentation is very clear. I am absolutely certain that I have the pin assignments right. I'm using 3.3V

I had two thoughts... I have a dead chip or there is something wrong with the released code (which I consider to be as likely as next to never) If I had another chip I would just throw this one away...but since I only have one on hand... is there anything I can do to test the chip further?

Dennis Ferron

rjo_, I recently fixed a serious bug in the pwm_mask feature on that made it still try to do PWM even if a pin was supposed to be "high" or "low". Because the initial timing values can be random, that can cause the circuit to appear not to function if it happens to try to do PWM with a long "off" time when you think you're leaving a pin high. As soon as I realized what was wrong, I uploaded a version 2.1 to the OBEX last night that has that bug fixed.

Of course, if you're using the simple version of the then that PWM bug doesn't apply.

PM me if you still have a problem, and I'll try to help you work out what might be wrong. I might be able to make a "debug version" of the object that can assist in finding the problem. Speaking of debugging, both the simple and advanced objects include a method called "What" which returns the actual value the driver is attempting to set the shift register pins to. If you'll run your code and have it output the value of "What" the Propeller serial terminal, we can find out whether the object is actually trying to set the pin high or not. It would tell us whether the problem is in what the driver wants to output or in what happens after it tries to output it. Something like:

repeat
   shift.High(some_pin)
   ser.str(cv.ibin(shift.What, 32))
   ser.tx(13)

Where shift is the 74595 object, ser is simple_serial, and cv is simple_numbers. You can also try "shift.Out($FFFF_FFFF) to force it to try to set all pins high; the .Out function also forces all PWM turned off on the advanced object.

Thanks for the compliments about the documentation, rjo_

P.S. I have a demo now that modulates the PWM frequency make 4 motors play music chords.

rjo_

I was using the simple version... I have myself found bugs, thought I corrected them, did correct them, but forgot to correct them when I went over to work on a related object. So, if I had been using your full implementation, I would have asked if you had tried to download your posted version as a sanity check.

But that's not the case, here. The simple version is really simple... so, I didn't think code confusion was a problem.

I'm going to mess around with the chip again later and will try to see if I can get it to do anything.

Any way to tell a live chip from a dead chip without running code to it?

Rich

Dennis Ferron

The shift register can operate at any speed down to DC. So in theory, if you wanted to, you could put the chip on a breadboard and connect the inputs to buttons/switches and the outputs to LEDs, and actually operate the chip by hand. I don't think you even have to clock in 8 bits; I believe you can pulse the latch register at any time to see however many of the last bits you entered, so you could do something like: make the data input low, pulse 2 clocks, make the data input high, pulse 2 clocks, and when you hit the latch enable button you should see 2 LED's on and 2 of them off.

Some things to check for:

1. I didn't bother to draw the power connections in the schematic; it's always good to double check: if you put a multimeter on the power pins of the IC, do you in fact read 3.3 volts? (Side note: the 74HC595 can operate from 3.3 volts, but the TTL based 74LS595 cannot!) The rated speed of the 74HC595 does go down as supply voltage is lowered. It is remotely possible that my code is just running the chip too fast to work on 3.3 volts - I'm using 5 volts to the 74HC595 in my circuit - but I don't think that's the problem because the speed I'm clocking data out the chip at is still much lower than what the datasheets say the 74HC595 can do, even at its lowest voltage. So while I don't think that's the problem, I have to mention that I didn't test it at 3.3 volts. Another power related issue is that I have a .1 uF capacitor near the power inputs of the chip; it should work without that, but you might try adding that and see if it helps.

2. Is the output enable turned on? (Needs to be grounded IIRC.) If it's not, you won't get a high or a low value from the outputs; they'll just be floating. If you have a good logic probe it will show different readings for outputs that are actually Hi-Z and not just merely low outputs; you could also make a circuit with LED's that would answer that question. If output enable is high then that was your problem; if the output enable is low and you still have neither high nor low on the outputs, then it would be a bad chip.

3. Is the 74HC595 reset pin (master clear) properly tied to Vdd? (You can't leave it floating.) If you tied it to the Propeller's reset pin that should be ok too, but if you did then try tying it to Vdd instead just in case I'm wrong. (Although make sure you disconnect it from the Propeller's reset if you tie it to Vdd, or else you wouldn't be able to reset the Propeller!)

4. Check the data line; if it's stuck low then you would output all 0's. Try setting shift.Out($FFFF_FFFF) and look to see if the data line goes high; if that works try setting shift.Out($0000_0000) and see if the data line goes low now. If you have an oscilloscope to connect to it, then if you output shift.Out($5555_5555) or shift.Out($AAAA_AAAA) you should see periodic bursts of square waves coming from the data line; if you have a second channel you can compare that to the clock line which should cycle twice as fast as the data line but in the same burst. There should be a latch pulse at the end.

Even if the Propeller is operating the 74HC595 incorrectly, you should expect to see a random mix of on and off outputs, not just all low. That makes me wonder if the output enable is not working, or if the master reset is clearing the register, or perhaps all 0's are being put on the data line. You might also check if it simply is connected to some different pins than the demo uses. Remember, the demo is just set up for the pins I'm using, so you'll have to substitute your own numbers there. (I've done that before with other people's objects; thought it didn't work and it was because I didn't change the pin constants from the defaults.)

rjo_

Dennis,

This was an incredibly detailed response. Thank you very much. I'm sure others in the future might have similar questions... now if we could just find a way to ensure that they find it easily. Somebody offered the suggestions that in the Obex each object could have a thread... this is a good example of why.

Running around today... and it is league nite for Special Olympics bowling... my team is in last place (we are the coaches[noparse]:)[/noparse] So, it looks like I'll end up trying everything else tomorrow.

Thanks again.

Rich

rjo_

Dennis,

Thanks for all your help... I had a chance to go over everything. I tried enough of what you suggested to come to the conclusion that I have a bad chip... originally I neglected to tie the 595's pin 10 to Vcc. And at one point, I had an LED on the clock line to make sure that my Prop was actually clocking...and I removed the LED without turning off the Prop. My Prop didn't like this one little bit. One or the other of these masterful strokes is probably what killed the chip. But I also don't remember where this particular chip came from... I had an engineering tech for a while... and I might have gotten it out of one his bins... so he might have killed it too.

Rich

Dennis Ferron

Thanks for mentioning that people in the future might have similar questions, rjo_; I changed the title of the thread in response. Let me know if you get things working with another chip. It might have been static electricity that killed the chip - I once was working on a 74HC595 circuit attached to a Boe-Bot and it was in a carpeted room; I built up so much static electricity just walking across the room that when I reached for the Boe-Bot, a visible spark jumped out. It actually only hit the metal chassis but it was so strong it reset the Basic Stamp THROUGH the ground plane! The Stamp actually survived but I had to replace the '595.

rjo_

As a matter of fact... I did[noparse]:)[/noparse] If I get more time to play... I'm going to make a nice video.