Let's Make Robots!

I think its called 8-bit parallel transfer? Maybe?

I got a hold of a nifty speech recognition unit after seeing it work here. The kit works quite well and includeds a little display consisting of a couple 7-segment LED's and some drivers. The two drivers are HCF4511BE BCS to seven segment latch/decoder/drivers. They, through a 10 pin header (8 data and power) then talk to a SN74LS373N (on the main board) which the datasheet says is a


Now it seems that I need ol' Walter to talk to this speech recognition unit via the 8 data pins that normally go to the LED display. I sorta assumed all along that a simple I/O expander would plug right in, no problem. I even etched a little PCB to do just this however, it seems I have run into a problem. It looks like the SN74LS373N is spitting out 8 bits of data, but it is not staying on ("latching" is the word?) I guess the latching is being done by the LED drivers. When I use my I/O expander, I can't seem to "catch" the change of the pins, it happens too quick. I can see this change happen when I run these same 8 output pins into the logic analyzer of my O-scope.

Simple question, how do I get 8 pin parallel data into some kinda chip and out to the robot via i2c? --or-- Is this as simple as using the interrupt pin on the i/o expander and doing a super-quick check of the pins every time we get an interrupt. I am hesitant to go with this interrupt idea --it would require a lot of wiring changes just to get that one pin, not to mention, it would probably cost me a cog just to keep an eye on it. I would much rather use a magical chip that would fix everything.

Here is the manual for the speech board

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Can you remove the two seven segment LED units from their board, and use the output of the HCF4511BE display drivers to interface to two i/o expanders that can interpret and then speak i2C to Walter?

Not familiar enough with the prop chip, but does it require polling for the interupt? A normal interrupt should be able to handle simple events like you are trying to deal with then use the handler to deal with the data? Find out if you have HW interrupts as those would be ideal for this situation.

Along the lines of what PeteH is suggesting, you could look at something like a mxp23008 io expander. It's a nice highly configurable I/O chip with int capabilities as well.

Can you montior the Latch Enable pin (pin 11) of the SN74LS373N? According to the datasheet, when Latch Enable (LE) is high, the output pins will transparently follow the state of the input pins. When LE is low, the data will be latched and held until LE is raised high again.

There is careful timing involved. The logic level presented to the input of the SN74LS373N must be present for 5 nS of setup time prior to lowering LE to latch the data. The logic level at the input must also be present for 20 nS after lowering LE to latch the data.

So I think you have some o-scope work ahead of you. How long does the data stay active on the input to the SN74LS373? What is currently controlling the LE pin? If you can control the LE pin, you can hold the data latched for as long as you need it.

Yup, I kinda figured I was going to have to screw with the interrupt pin... In terms of the prop, it doesn't. Props don't interrupt instead, you simply code-in a "watcher" within a cog. Depending on how long the "click" is on the int pin, that "watcher" may or may not be able to be added to an existing loop. Simply said, the watcher loop must be executed faster than the length of the interrupt pulse and might require its own cog (something I don't like giving up for "routine" tasks).

Mr. IG threw out a good one and one that works with my ideas... Throw more parts at it!! He is right, the led drivers are spitting out exactly what I need, why not just tie into them? The only downside (and its a tiny downside) that I would have to run (2) I/o expanders instead of one. This would suck without i2c, but with i2c, I am not wasting any pins and within the code, I just have to do 2 checks instead of one. We're only talking a couple bytes going back and forth --no real slow-down here. It does seem a bit excessive to run (4) chips and 16 bits to simply get a value (between 0 and 40) into a robot brain, but then again, I have glued pots to servos before so I am not above a good work-around.

I guess I have some PCB's to make...

Well, I missed something. Maybe it should go in the "should have known" catagory, maybe  just a good ol' miss. It's a simple 3v vs. 5v data level issue. It seems that indeed, my I/O expander latches --in that it "remembers" the last thing it got and will send it to you if you ask. The problem I was having was that there was no signal to read! I checked the output of the main board (the output that I want to tie into and the one that normally goes to the LED drivers) and it is a 3v signal (2.84v to be exact). Because the I/O expander uses it's own supply as a reference for high/low, there was never enough of a signal to trigger a high read. Simple answer? Run the I/O expander at 3.3v. Done. Finished. Works. Oh so nice, and I don't have to redesign or re-etch any more boards. Whew.

Thanks again guys, Walter can now hear me!