What pin extenders are compatable with an LM324N op amp?
Robert Graham
Posts: 55
I am using LM324N op amps to amplify the outputs from a Propeller chip to drive 9 volt latching relays. One of the prototypes I am doing uses too many relays for the Prop chip to drive.
I found some good info on what pin extenders are compatable with the Prop chip, but which ones can drive an LM324N? If I could find one that would connect directly to the relays, that would be even better, but it's ok if I have to use the op amps. I already have that board soldered up.
Also, does anyone have any exact specs on the Prop's general puropse I/O pins? The big problem I am having is that I don't know exactly what they are; I know they will drive an LM324N, so I would like to know so I can just select a pin extender with that has the same specs for it's outputs.
I found some good info on what pin extenders are compatable with the Prop chip, but which ones can drive an LM324N? If I could find one that would connect directly to the relays, that would be even better, but it's ok if I have to use the op amps. I already have that board soldered up.
Also, does anyone have any exact specs on the Prop's general puropse I/O pins? The big problem I am having is that I don't know exactly what they are; I know they will drive an LM324N, so I would like to know so I can just select a pin extender with that has the same specs for it's outputs.
Comments
An LM324N op amp is not the best choice for driving 9 volt latching relays. The easiest thing is to use a bipolar NPN switching transistor like a 2N3904 or 2N2222A. You'd need a base resistor on the order of 150 to 270 Ohms depending on how much current the relays require. You'll also need a reverse connected diode across the relay coils, something like a 1N914 or 1N4001.
If you need more I/O pins than the Prop can handle, TI makes a device that contains a serial shift register like the 74HC595 combined with a MOSFET for each output. I think this is the TPIC6595. This uses 3 Prop I/O pins to provide 8 outputs and these can be cascaded.
Anyway, I do know the Propeller's I/O are not compatable with every logic familiy. The original version of the prototype I'm doing was based on the CD40K logic family of IC's. I hooked one of the Propeller chips I was using up to the demultiplexer I cobbled together out of logic IC's. The demux was running directly off the same 9 volt battery as the Prop's power supply was. It worked for a few minutes before the entire demux side of the test circuit began to malfunction (at that point I had replaced only the multiplexer side with a Propeller chip).
I was getting despirate to get the pin expansion done, so I tried using a CD4067 multiplexer I had to expand the pins. I thought that maybe if I ran the mux chip at 3.3 volts, it would not malfunction, as the specs put the minimum supply voltage for the chip at 3 volts. Same result though, but this time I never achieved full functionality.
I slowed the software execution down to one line per second, and connected the pins I was using to output the four bit address code to LED's to check that I had the software written correctly. It executed just fine with the one second pause (the software already had a 1/400 second pause written in, as this is about how long it takes to flip the relays).
I should be able to infer what logic families the Prop's I/O pins are compatable with by looking at what experienced persons are using. However, I then have to go online and order the devices to check compatability. So far as I have been able to find, Parallax only tells that the outputs are CMOS! But, as the apparently incompatable CD40K logic family is CMOS, this is insufficient.
I have no doubt that I will get the pin expansion accomplished, but I would perfer to only have to put in one order to get the parts I need. It's going to take much longer than I have scheduled if I have to make attempts with various chips. I also would perfer to spend little time writing new software, as I am a novice with code, and it makes my head hurt!
Thanks for the help!
edit:
I looked at the TPIC6595's data sheet. Looks like it might be very helpful. Again, I worry about compatabiliy though. Also, the Prop would have to keep track of what line the TPIC6595 is on. I do know how to do that (sort of). But, it would take time. Probably the easiest way would be to find a compatable mux chip, as I have already written software that will drive a 16 bit multiplexer with four binary control inputs.
Anyway, I do know the Propeller's I/O are not compatable with every logic familiy. The original version of the prototype I'm doing was based on the CD40K logic family of IC's. I hooked one of the Propeller chips I was using up to the demultiplexer I cobbled together out of logic IC's. The demux was running directly off the same 9 volt battery as the Prop's power supply was. It worked for a few minutes before the entire demux side of the test circuit began to malfunction (at that point I had replaced only the multiplexer side with a Propeller chip).
I was getting despirate to get the pin expansion done, so I tried using a CD4067 multiplexer I had to expand the pins. I thought that maybe if I ran the mux chip at 3.3 volts, it would not malfunction, as the specs put the minimum supply voltage for the chip at 3 volts. Same result though, but this time I never achieved full functionality.
I slowed the software execution down to one line per second, and connected the pins I was using to output the four bit address code to LED's to check that I had the software written correctly. It executed just fine with the one second pause (the software already had a 1/400 second pause written in, as this is about how long it takes to flip the relays).
I should be able to infer what logic families the Prop's I/O pins are compatable with by looking at what experienced persons are using. However, I then have to go online and order the devices to check compatability. So far as I have been able to find, Parallax only tells that the outputs are CMOS! But, as the apparently incompatable CD40K logic family is CMOS, this is insufficient.
I have no doubt that I will get the pin expansion accomplished, but I would perfer to only have to put in one order to get the parts I need. It's going to take much longer than I have scheduled if I have to make attempts with various chips. I also would perfer to spend little time writing new software, as I am a novice with code, and it makes my head hurt!
Thanks for the help!
If you want specific advice, I suggest you give as much information as possible about how you want to use the Propeller and what you want to connect it too.
That is a tried and true circuit that I use all the time. Three components to drive a relay - a resistor, a transistor and a diode. These are very cheap components - if you buy them in bulk the total cost might be 10c or less.
As for the bigger picture question about talking to other chips - do you mean the demux was running on 3.3V or 9V?
For direct interface to the propeller chip, the 4000 CMOS series should work fine. Also the 74HC series work fine too. Maybe don't use the 74HCT series though as they need a 5V supply and it is easier not to mix and match voltages too much.
I do a lot of work with the 74HC374 latch and the 74HC138 decoder and the 74HC595 serial to parallel decoder. You can mix and match 4000 and 74HC if you like - eg the 4051 is a useful analog multiplexer and demultiplexer.
Could you post your 4067 schematic - I'm sure we can get this working.
However, I think it it sufficient to say that I tried connecting it directly to the Prop's I/O pins. As for the first time I tried using it with a Propeller, I was running it on 9 volts. This was a horrible obsolete circuit so I don't want to bother with it in the future, but the outputs of the CD4067 were going to D-type flip flop IC's, which I was using for memory. The demux (IC based) worked fine for a few minutes, and then began to malfunction. When I played with the circuit the next day, the demux was totally nonfunctional.
Today, I was attempting to drive a CD4067 by connecting I/O 0 thru 3 of the Prop to the '67's binary control inputs, and I/O 4 of the Prop was connected to the common I/O of the '67. The inhibit pin of the '67 was connected to ground, and the parallel I/O's were connected to the LM324's. The power pin of the '67 was connected to the 3.3 volt rail of the Propeller's power supply. I couldn't achieve full funtionality. The relays sometimes flipped when I pushed the test circuits buttons, and sometimes they didn't. Tinkering with it only made it worse. I'm certain I simply was attempting the impossible.
I would never attemp to run a Propeller at anything other than 3.3 volts, so no worries there.
If I were unable to get these components to work in other configurations, I would not be concerned about compatability. But, the Prop works fine as long as it has the correct voltage, and nothing funny is going on at a I/O pin. The CD40 IC's played well with eachother, well enough for me to make a test circuit with a mux/demux pair! But, I can't get the Propeller to reliably drive IC's in that logic family.
I attempted to use A06 transistors to interface the Prop with the relays. For some reason, I wasn't getting much, if any voltage amplification. Maybe I forgot to put a resistor between the two. I'll try it again, but, no worries, as I already have that part figured out.
Worst case scenerio is I have to build one of the prototypes without a proper display, and the I add it later as a retrofit. There is plenty of info for more experienced coders to use I2C I/O expanders, but my pizza guy background makes writing code at that level difficult! In any case, it will get done eventually.
Another issue might be bypass capacitors and supply capacitors - a general rule of thumb is one 0.1uF per chip (two for the propeller), and I tend to put a 22uF across the propeller chip as well, and use a 470uF on the 9V supply and also on the 3.3V supply. Maybe it is overkill, but lack of bypass capacitors can cause erratic behaviour as supply voltages collapse (eg from a relay turning on). What sort of capacitors do you have on the circuit?
Also, to go back to Mike Green's comment, do you have a back EMF diode across the relay coil?
Sometimes putting leds on pins (with 220 ohm resistors) can help debugging.
As for capacitors, I did not add any, other than what is in the schematic of the Propeller Education Kit. The kit directs you to put one 1000uF cap between the 5v regulator's output pin, and another one on the 3.3v regulator's output pin.
I had some intermittent malfunctions when I was developing a previous version of the test circuit for my prototype. I had about two dozen CD40 series IC's running off the same power supply. I had one electrolytic cap across the power supply rails, but it did little good. So, I put some little ceramic caps here and there; the code on them is 104, I forget what value this is. Anyway, the little 104 ceramic caps fixed the problem. So, maybe some of these could help? I haven't gotten that far.
I do have some fresh CD4067's to play with, but I'm thinking there has to be a serious compatability problem with the Propeller. It might only take using a low value resistor to connect the Prop to the '67 to make the circuit work (or some other little simple fix). I can speculate, but I'm expecting to have to use I2C devices in the future, so I really don't want to play with the '67s too much.
Dennis Ferron wrote an object that drives up to four 74HC595 shift registers that looks promising. He explains it well, so I think I could adapt it to my project with little effort. I think I need to budget 10 hours to get this mod done. If it takes longer than that, it would be better to just give up, and put that time into learning about LCD displays. I already want to use an LCD display for the retail version of the device, so it doesn't make sense to go crazy "reinventing the wheel".
I really wish corporations weren't so tight lipped on specs. I'm sure Parallax knows exactly what the Prop is compatable with.
I did not have the output stage (the amplifier stage and relays) hooked up, but the '67 was driving some transistors that I had hooked up to LED's just fine. As a little consolation prize for my troubles, I noticed a minor bug in the software while I had a one second pause in the relay control software. I never would have noticed it had I not had this annoying little problem!
I'll figure out how to hook the '67 up to the relays tommorrow. If it doesn't play nice with the LM324's, I'll try transistors, like you guys suggested.
"104" is 0.1uF which is exactly what you want. Put one next to each chip you use, between ground and the supply pin.
Not sure why a pulldown works but sometimes those are the sorts of solutions that do work.
Just to throw a complete spanner in the works, if 4067 does not work, and we know for sure that 74HC series works, how about a hybrid of the two - the 74HC4067
LM324 will work but you will probably need to run them from a 5V supply, and you will probably need to bias the -ve inputs at 2.5V with two 10k resistors.
Personally, I'd do this with transistors and relays, and try to do the 4067 in code on the propeller.
http://www.smarthome.viviti.com/build#image;collection_114982,/files/resized/54730/700;500;23a86c59125eb7a47c19fa61f0b96bc1be72b3af.jpg is a photo of my propeller board - there are 104 capacitors next to each chip, and you can see those chips are 74HC138 and 74HC374 which work directly off the propeller pins with no pullups or pulldowns
Given that "pull down" resistors work, I wonder if your propeller code might be switching from "High" to "Open Circuit" rather than "High" to "Low". Any chance you could post your code?
Thanks for the ideas on components! I want to do a production version of the device next year, so I need to simplify it as much as possible to make it cheap. However, I was very badly wanting to find a way to get the CD4067's I have to work with the Prop, so I can complete the prototypes right away. I modified one of the units; I added several more of the latching relays, and ran out of pins to drive them and the LED display.
Here is the code for the slave device. I'll save the code for the control unit for another time.
'' I/O 26 is the clock signal
'' I/O 27 is the data signal
'' This is a final version of the Demux prototype software.
'' The output code switches all the previous preset's relays off before turning
'' the current preset's relays on
'' There is code here to ensure the two devices sync up.
'' This is version 3. It is designed to drive a 16 bit multiplexer. Accordingly, the output method
'' is written to generate addresses to drive the CD4067 chip. Version 4 will add outputs for however
'' many more I/O pins are needed to drive the additional relays and LED's.
CON
_clkmode = xtal1 + pll16x ' Feedback and PLL multiplier
_xinfreq = 5_000_000 ' External oscillator = 5 MHz
VAR
byte address[16]
byte input[11]
byte on[11]
byte off[11]
long stack[60] 'Makes memory available for the two cogs that will be running.
PUB LaunchCogs
cognew(Demux, @stack[0]) 'Launches Demux method in first available cog
cognew(Output, @stack[20])
Pub Demux | munch 'create variable
dira[26..27] := %00 'Sets I/O pins to input
dira[0..15] := %1111111111111111 'Sets I/O pins to output
repeat
waitpeq(|< 26, |< 26, 0) 'wait for I/O 16 to transition to high
waitcnt(clkfreq / 35000 + cnt)
repeat munch from 0 to 7 'repeat the following block for input variable via munch 0 thru 7
if ina[27] == 1 'data inputs is high
input[munch] := 1 'set input varable high
else
input[munch] := 0 'or set input variable low
waitcnt(clkfreq / 50000 + cnt) ' Wait 1/50000 second -> 100000 Hz
waitpne(|< 26, |< 26, 0) 'wait for I/O 16 to not match previous state
Pub Output | pin, pintwo, poop
dira[26..27] := %00 'Sets I/O pins to input
dira[0..15] := %1111111111111111 'Sets I/O pins to output
address[0] := %0000
address[1] := %1000
address[2] := %0100
address[3] := %1100
address[4] := %0010
address[5] := %1010
address[6] := %0110
address[7] := %1110
address[8] := %0001
address[9] := %1001
address[10] := %0101
address[11] := %1101
address[12] := %0011
address[13] := %1011
address[14] := %0111
address[15] := %1111
pin := 1
repeat 8 'Brief output to all relays to flip them to base state.
outa[0..3] := address[pin]
outa[4] := 1
waitcnt(clkfreq / 400 + cnt)
outa[0..3] := address[pin]
outa[4] := 0
pin += 2
repeat
poop := 0 'Set values for the variables used in this method
pin := 1
repeat 8 'Check input from the demux, and turn
'any relays from the previous preset off
if input[poop] == 0 and on[poop] == 1
outa[0..3] := address[pin]
outa[4] := 1
waitcnt(clkfreq / 400 + cnt)
outa[4] := 0
on[poop] := 0
pin += 2
poop += 1
poop := 0
pin := 0
'Check input from the demux, and turn
repeat 8 'any relays from the current preset on
if input[poop] == 1 and on[poop] == 0
outa[0..3] := address[pin]
outa[4] := 1
waitcnt(clkfreq / 400 + cnt)
outa[4] := 0
on[poop] := 1
pin += 2
poop += 1
Blame Beavis and Butthead for the silly variable names. The little bug I noticed is that this object some times turns a relay on before it tuns the relay from the previous setting off. Should be easy to fix.
'' I/O 26 is the clock signal '' I/O 27 is the data signal '' This is a final version of the Demux prototype software. '' The output code switches all the previous preset's relays off before turning '' the current preset's relays on '' There is code here to ensure the two devices sync up. '' This is version 3. It is designed to drive a 16 bit multiplexer. Accordingly, the output method '' is written to generate addresses to drive the CD4067 chip. Version 4 will add outputs for however '' many more I/O pins are needed to drive the additional relays and LED's. CON _clkmode = xtal1 + pll16x ' Feedback and PLL multiplier _xinfreq = 5_000_000 ' External oscillator = 5 MHz VAR byte address[16] byte input[11] byte on[11] byte off[11] long stack[60] 'Makes memory available for the two cogs 'that will be running. PUB LaunchCogs cognew(Demux, @stack[0]) 'Launches Demux method in first available cog cognew(Output, @stack[20]) Pub Demux | munch 'create variable dira[26..27] := %00 'Sets I/O pins to input dira[0..4] := %11111 'Sets I/O pins to output repeat waitpeq(|< 26, |< 26, 0) 'wait for I/O 26 to transition to high waitcnt(clkfreq / 35000 + cnt) repeat munch from 0 to 7 'repeat the following block for input variable via 'munch 0 thru 7 if ina[27] == 1 'data inputs is high input[munch] := 1 'set input varable high else input[munch] := 0 'or set input variable low waitcnt(clkfreq / 50000 + cnt) ' Wait 1/50000 second -> 100000 Hz waitpne(|< 26, |< 26, 0) 'wait for I/O 26 to not match previous state Pub Output | pin, pintwo, poop dira[26..27] := %00 'Sets I/O pins to input dira[0..4] := %11111 'Sets I/O pins to output address[0] := %0000 address[1] := %1000 address[2] := %0100 address[3] := %1100 address[4] := %0010 address[5] := %1010 address[6] := %0110 address[7] := %1110 address[8] := %0001 address[9] := %1001 address[10] := %0101 address[11] := %1101 address[12] := %0011 address[13] := %1011 address[14] := %0111 address[15] := %1111 pin := 1 repeat 8 'Brief output to all relays to flip them to base state. outa[0..3] := address[pin] outa[4] := 1 waitcnt(clkfreq / 400 + cnt) outa[0..3] := address[pin] outa[4] := 0 pin += 2 repeat poop := 0 'Set values for the variables used in this method pin := 1 repeat 8 'Check input from the demux, and turn 'any relays from the previous preset off if input[poop] == 0 and on[poop] == 1 outa[0..3] := address[pin] outa[4] := 1 waitcnt(clkfreq / 400 + cnt) outa[4] := 0 on[poop] := 0 pin += 2 poop += 1 poop := 0 pin := 0 'Check input from the demux, and turn repeat 8 'any relays from the current preset on if input[poop] == 1 and on[poop] == 0 outa[0..3] := address[pin] outa[4] := 1 waitcnt(clkfreq / 400 + cnt) outa[4] := 0 on[poop] := 1 pin += 2 poop += 1I still can't get the execution of the Output method to pause, and wait for the Demux method to change a variable. It's not always flipping the relay from the old setting off, before flipping the relay from the new setting on. It's not essential to do that, but it would be preferrable.I am glad you have something working for your initial testing! Could you please post a simple schematic rendition of your circuit? The CD4067 is an analog multiplexer and has varying VIL and VIH requirements based on VDD level. I believe VIH on the selects is around 7 volts for a HIGH input when VDD is 10V. The fact that it is working with pulldowns but that we don't fully understand why is dubious! I would also recommend a simple transistor based level shifter for its low cost for any production.
By the way, I'm running the CD4067 off the same 3.3 volt power rail as the Propeller.
Or use one of the many free programs around (I use Eagle, and either do a screen capture with Paint Shop Pro, or print to a .pdf)
Good grief Charlie Brown.......where do I go from here? You stepped off on the wrong foot, both of them. Because you were using multiplexers you were not able to obtain a latched signal but a simple shift register would have been the right choice. Also because they were CD4000 series that were designed for 15V supplies back in the 70's you find that you need "translators" to drive them from 3.3V, so so complicated isn't it? Secondly if you really wanted fast audio path switching speeds you wouldn't use relays would you? So a simple OptoFET or SSR is as easy to drive as a relay except they work fine from low voltage and switch in a matter of microseconds.
But you get top marks for getting stuck into though, that's refreshing!
LOL! This may be your perception right now, but I assure you that corporations aren't being tight-lipped on specs. Every device I've ever used had a data sheet full of cogent information. These corporations want you to use their devices. What makes you imagine otherwise?
I stay away from relays mostly because of their current consumption but also because of initial tests where the switching/EMI completely disqualified their usage. (Guitar pickup level signal)
I'd recommend using dual-supply 15v-18v. Works very well in my experience.