Trying to save IO pins using mcp23017 i2c GPIO expander.

rwgast_logicdesign

Ok so I have 5 of these sonar modules I want to hook up. They each have 2 data pins, a trigger and an echo. Once you pulse trigger line the module sends out an ultrasonic noise which is then read by measuring the amount of time the echo pin is hi. These are all 5v sonar modules, so you need resistors on the trigger and echo line when connecting directly to a prop. Some other forum members have come up with solutions for cutting the pins by using a pull down and some diodes. While this method works it isnt exactly what im looking for,

I have a bunch of mcp23017 and 23018 chips around they are 16 post gpio expanders, the 23018 can even act as a 5v tolerant buffer.I figured id use one of these chips and then have 6 extra I/O left! There is no obex object, but Johnny Mac has written some code and posted it on the forums, found here

http://forums.parallax.com/showthread.php/107967-mcp23017-(i2c)-example-code

from what I can tell this is just a very simple demo showing how to talk to the chip, im not even sure how you would use it to address single pins, not just ports. That is neither here nor there though. Looking through this code it seems like you can only read and write pits to these gpio's. So does this mean there is no way to actually measure pulse times on these pins, making it a bad choice for these sonars and things that use pulsing as a protocol?

Mike Green

You can only read and write 8-bits or 16-bits at a time and these devices are relatively slow. To write to them takes an overhead of 2 bytes. To read from them takes an overhead of 3 bytes (at 9 bits per byte). You can't access individual pins, only 8-bit ports.

Best speed is probably a 400KHz clock, so that's roughly 40K bytes of information per second. With overhead figured in, that's about 13K bytes per second for writing and 10K bytes per second reading.

I would suggest using a 74HC165 for reading the outputs of the sensors and a 74HC595 for writing the trigger pulses. These are 8-bit shift registers. You can't address individual pins, but these are cheap and you can let the software handle writing the whole 8-bits to change just one trigger. Similarly, the software can handle sorting out which sensor has an echo and for how long.

rwgast_logicdesign

I thought the point of these is that they had indavidually accessible pins. Basically if you ran 8 bit mode, set PORTA as output and sent a byte to it, it would flip 8 pins using the byte as a mask?

Being there so slow what are some common applications for these? Reading buttons, flipping LEDs?

kwinn

rwgast_logicdesign wrote: »

..........Being there so slow what are some common applications for these? Reading buttons, flipping LEDs?

You got it. These chips are used for more general I/O, not for more specialized applications like sonar that require precise timing.

rwgast_logicdesign

I noticed there is a 74xx595 driver thatbdoes can do PWM, does that mean a shift register could be used for this?

kwinn

Yes. A '595 for the outputs and a '597 or '165 for the inputs would work. You can save pins by sharing some signals with both chips.

Duane C. Johnson

Hi rwgast_logicdesign;

In this application timing is paramount!

I suspect you don't want these extra chips in the way of making these fast readings.
You need to have the Prop generate these signals directly through level translators.

Ok, the other chips can be used for slower signals without unduly using up to many Prop pins.

Duane J

JonnyMac

Using the '595 and '165 are easy, and I have written a PWM driver for the '595 for an LED animation project. That said, for critical timing you'll need to write your code in PASM -- Spin is not going to cut it when dealing with serial IO devices and critical timing.

You might consider writing a specialty object (in PASM) that will provide your trigger output via the '595 and get your echo timing via a '165. By adding a resistor in the mix you can connect with both using only four IO pins; this would let you control up to eight sonars modules.

Ron Czapala

The MCP23S17 has a maximum 10MHz SPI interface - not sure if that is fast enough for your application...
http://ww1.microchip.com/downloads/en/DeviceDoc/21952b.pdf

rwgast_logicdesign

@Ron I dont even think the speed is applicable here, the issue with the 23017 is I cant control timed pulses on the output and read timed pulses coming in.

Duane C. Johnson

Hi rwgast_logicdesign;

Question, are the 8 sonar units pulsed sequentially, i.e., 1 at a time?

Duane J

SkyFx

The 74x165 are faster (up to ~50MHz) if you can poll them fast enough, rather than reading a I²C register. But your resolution for a single input would be an 8th of the CLK.

Depending on the required sampling rate, maybe the MCP23017/18´s two programmable interrupts for their PORTA and PORTB could be what you were searching for.

In case you have a very time critical application, making use of the props builtin counter functionality for pulse width counting is an option as well as having an external counter or ADC that does the pulse width quantizing for the Prop.

Being there so slow what are some common applications for these? Reading buttons, flipping LEDs?

They support up to 1,7MHz I²C operation, but i have not found an OBEX Object fast enough for that yet, tough i haven´t tried them all.

• With shift registers the sampling rate is divided with every register added while I²C can be addressed individually
• The Props EEPROM needs I²C anyway which spares 2 pins in case you add more I²C devices.
• and of course the single pins are programmable as inputs or outputs

wbr

rwgast_logicdesign

Duane there have been a few solutions for muxing these sensors by sharing the echo line. The problem is I want to be able to pulse them all at the same time or indavidually. Tying the trigger and echo pins works with 5v mcu's, all you need to do is jump the the trigger and echo with a 1k resistor. I tried this with an Arduino earlier. The prop needs a 1k on the trigger and 10k on the echo in order to to interface with the 5v sensor. This is causing mucho problems when I try to jump the echo and trigger, i even used a 5k pot to jump the pins so I could trim the value, still no dice.

As far as using the i2c expander this just isnt a good idea at all. You would have to keep reading the port, then create a loop that looks at the indavidual bit echo is attached too and count how long it stays at 1. Im sure between the i2c speed and the code monitoring the bit the timing wont be accurate at all.

I have thought about using a 74lvc244 to do the level shifiting and just jumping echo and trigger togather, but if im going to go through all that may as well just throw in an AVR to read sensor and send the values to the prop via uart or spi.

SkyFx

rwgast_logicdesign wrote: »

then create a loop that looks at the indavidual bit echo is attached too and count how long it stays at 1. Im sure between the i2c speed and the code monitoring the bit the timing wont be accurate at all.

You could use the Propeller builtin counters to add a number to the PHSx every PLLDIV fraction of the Propeller Clock as long as it is 1 without actually running code during that time. All you´d need to do is setup the counter before the input may have logic 1 level and wait until PHSx has a different value and the pin has reached 0 level again. It would be very high resolution, although you can only have 2 counters per cog. See AN001 p.14 for examples.

Or have a look at the ΣΔ-ADC examples in the Appnote to make use of I²C ADC ICs using your echo signal as input to an ADC.

However it depends on what makes sense to you.

wbr
P.S.: i saw i slipped the point that you were talking about polling those inputs via serial data. Any idea how fast you´ll need to poll? You´ve got to make a choice anyway what to do, add more external hardware to unburden tasks from the Propeller and spare I/Os or just wire the time critical I/O directly.

Mike Green

You don't want to pulse ultrasonic distance sensors simultaneously. They will interfere with each other. You have to allow time for the echos to die down. I would allow 2 or 3 times the maximum distance time for that. For the PING))), that's 40ms to 60ms. You can still cycle through 5 sensors in 1/3 second that way.