Propeller IO Expansion - What Is The Best Solution?
idbruce
Posts: 6,197
I know there are a lot of solutions out there, but I want to hear some opinions. I also know that there are a variety of things to consider, such as pin usage, speed, ease of use, external components required, communication, additional IOs gained, etc...
State your case
Convince your peers
State your case
Convince your peers
Comments
Expand your processing power at the same time you expand your I/O.
But really, what manner of I/O do you mean?
Funny thing that heater mentioned to use another Prop because that's what I did once or twice where I was driving a lot of solenoids and reading contacts amongst other things. Without too much ado it is easy enough to talk to the extra Prop serially on a single line plus the I/O Prop can do a lot of smart I/O and filter inputs, time outputs etc.
However I normally just use I2C for I/O expansion or if necessary SPI but in the case of the latter I just borrow the SCL and SDA lines from I2C (EEPROM) and use a CS so I am not using up more and more Prop I/O to "expand", because that kind of defeats the purpose when you see multiple I2C and SPI buses in some designs. How to convince you? Because that's what I do
The other solution is like the first except I just use a cheap little micro though I do prefer the easy to use Silabs 8051 parts as they are very fast and simple, combine A/D and D/A, easy to flash via the Prop, plus 8051 assembly is a breeze.
Well Peter....
It really depends on what you are using the extra I/O for.
-Phil
To ask us to convince our peers is really asking that we convince you because you are asking, not our peers. However in so doing if there is consensus from most then I guess you will be convinced. Of course all of us could be wrong but at least you'd be convinced
Now that you shout "BEST way" I will have to say that would have to be to use the Prop's internal address/data bus, if you could, well, that would be the BEST. When all you have are I/O pins and only 32 of them you normally would talk to other I/O serially and the methods have been covered, that is, asynch, I2C, and SPI. Of course you could create an 8-bit bus plus other lines for address and control BUT you only have 32 Prop I/O max! These I/O are precious, they are the only ones the cog can access in a single cycle, I wouldn't waste them unless that turned out to be the expedient and practical thing to do. "BEST" also depends upon what you are doing with them but most of the time these only need to be simple on/off or switch sensing.
EDIT: @Phil - you only need one I/O as the load signal for the 595s as there is no reason why you can't use clock and data from the I2C EEPROM lines.
Okay, then let's simplify the selection process.
There is no intended purpose for the additional pins and the only goal is add additional IO pins. Although the 5V thing throws a wrench into the scene....
Okay so BEST 5V solution and BEST 3.3V solution
For many normal human beings who are beginner or casual MCU programmers having to deal with another HLL or assembly language is a bit to much to ask. Having to be familiar with multiple IDE's and programming hardwares is out of the question.
Whilst you are working in Spin/PASM how much easier it is just to use all that skill on your expansion hardware as well. If nothing else it's a lot less fiddly details of different systems you have to remember when you get back to your project after a long break.
After that I'm with the sentiment that cheap, dumb, physically small port expanders and shift registers is a way to go.
And yep, without a specific I/O requirement statement the can be no "best".
Damn it! Every time I think I have an original ... someone has beet me to it.
... Tim
I agree that it is much easier development-wise to use a Prop as I/O but that is not always the best hardware solution. Sure, you could share the clock, you could even boot the I/O Prop serially so that you could do away with a crystal and EEPROM, but that is still more complicated than communicating via I2C with one of these tiny little micros that are packed with precision oscillator, analog subsystems, 5V operation options etc, and I only need one extra Prop I/O to control the reset/programming of it.
BTW, most 8-bit assembly is very simple although I would much prefer 6502 rather than 8051 but in terms of the different architectures I do dislike AVR register based assembly, and PIC is primitive but okay. ARM code and IDEs start to get a bit complicated but I am tempted to write a Forth that fits onto one of these little dollar chips so that I can then load "scripts" into them from the Prop
There are now two great resident FORTHs for the LPC1114. One (as mentioned before) is Fish from Clyde W. Phillips. The new one is Mecrisp from Matthias Koch. Both are great FORTHs and both are great guys. I think it would be outstanding for Peter to add his considerable skills to this same worthwhile pursuit.
BTW, I always have specific reasons for extending μC I/O and so I always employ specific solutions. Shift registers are generally the best bang for the buck, but they aren't even close to a universal solution. I don't believe in universal solutions.
Fixed Input and Output designation?, or selected by software (i2c expanders pretty much the only choice then)
A DIP version should be available?
Simplest one is to turn 8 input pins in to output pins using a latch, 74HC573 (74HCT573 for 5V operation)
Put 1K resistor on the input traces and when you want it to be a output, turn the Props port around and write the value and do a LE pulse and then go back to input.
Best part is that waitpne etc still works
So 9 pins turns in to 16 I/O pins.
The answers to those questions, are up to the person responding.
How does waitpne fit into the scheme?
A system with parallel to serial inputs would of course not work with Props waitpne/peq
the cog that uses it as input will need to be the same cog that uses as output preferably, as to know when waitpne or inputs are "real" inputs
A cog input only, could work if you read port twice and if any LE pins was high at the same time then disregard the value.
using two 74HC573, will give you 8in and 16out with the use of 10 prop pins, pretty good for most uses and HCT version gives you free translation to 5V if wanted
At first glance the digitals don't sink/source much, but you can also use the pins in DAC mode where they'll happily source/sink 20mA, limited at 25mA, so this means you can interface to any arbitrary voltage chip, eg 2.5v, 1.8v etc.
You can load the SPI version at least at 20 MHz, and there's a I2C version too (5593R)
As well as the Silabs parts Peter mentioned (great if you want ADC & are ok with SMD), there is also AT89LP52, which is ~70c for 32io.
Comes in DIP/PLCC44/TQFP44 and works 2.5V/3.3V/5V with TTL thresholds.
That's cheaper than PCF8xx IO expanders on a cents per io pin, and I think the over-priced PCF8xx are due for a shakeup from the growing number of sub 70c small MCUs
There are still lowly parts like HEF4021 (great for keypad IO) and xC595 (op only), but they are fixed-use.
If you pop over to Digikey and Search for micro-controllers, cheapest @ 1000 you find they start at 31c (!)
I think this link does that
http://www.digikey.com/product-search/en?FV=fff40027%2Cfff800cd&mnonly=0&newproducts=0&ColumnSort=1000011&page=1&stock=0&pbfree=0&rohs=0&quantity=1000&ptm=0&fid=0&pageSize=25
I'm working on pushing one of those little micros along at 3MBd, for highly flexible slave IO and I think it can hit 4MBd (which is apparently where RaspPi tops out )
I see $1.52 ~ $2.11 for 36
Is that the specific chip you are using now?
I use the LP52 as IO,yes, but it is not the one I try to push to 3MBd/4MBd
I am looking at a wired-or TTL.232 with a 5 bit address field, to allow 32 slaves and only one echos, using the Quasi-Bidirectional IO, - not sure how that would cope as the area grows. I suspect more serious drivers would be needed to hit 3MBd, but i want to avoid half-duplex of RS485
SX1508/SX1509 GPIO Expanders
This part seems to be hard to get although Digikey have good stocks of the 8 channel part and the price is certainly better than all those standard I2C I/O expanders. However it's only available in QFN and it basically smells like a preprogrammed micro anyway. I'd rather have the analog subsystem on my expander than fancy keypad scanning etc. Besides, the micros are cheaper still, if only there were a way to convince a chip manufacturer to preload some of their micros so that they could be used off the shelf as is but of course since they are flash you can still just load them up as you do normally. Perhaps if a really robust I2C expansion solution were made available then there might be a chip maker interested enough to take this idea up. Imagine Digikey/Mouser having tens of thousands of a particular micro in stock at really good prices, and they come preloaded as an I2C expansion port!
Admittedly, I have a very hard time reading and comprehending the datasheets, so I have no idea if this would work well or not. But let's say there is a cog with a solitary task of repeatedly polling a 165, just how fast could this cog read the 8 bits and store it to a global variable?
The Teacup firmware drives all the steppers with one timer, however in the future, I would like to explore the possibility of controlling four steppers, with four different timers, to see if there is any performance gain.
If you want to manage Limit switches, where you expect only one at a time to fire, then look at Priority encoders.
They have aflag for any-valid, and an encoded 3 bits for the highest one valid
I think many i2c slave devices also have Pin change interrupts, so you set a OK pattern, and get a signal on Not-OK.
Thanks for the input, I will definitely look into that! Although I have never heard of them.
If reading inputs is all this particular chip was doing then I would just have a micro with umpteen inputs that are then filtered perhaps and output continuously at high speed (up to 10Mbits/sec) to a single pin on the Prop. A cog would just read in the stream and update not just 8-bits but perhaps a long at a time. Achieving an update rate of 100k per second is easy and all it takes is a single pin. Of course for switches you only need a more leisurely update rate of 1,000/sec and the baud rates could just be well within 115.2k baud even.
re: However it's only available in QFN
You could always use a SparkFun 16 Output I/O Expander Breakout - SX1509 if it's for experimenting or a one time thing. It may be expensive for a commercial product though. They should have stock as well.
SparkFun 16 Output I/O Expander Breakout : https://www.sparkfun.com/products/11502
Considering the application that I specified, do you have any particular micro that you might suggest that would be well suited for the application. Please keep in mind that a very small footprint would be of high priorty, perhaps even a breakout board.
What is "very-small" ?
3mm x 3mm QFN20 ? or an easier to handle SO16N ?
@Beau Schwabes HS serial concept fits right into the Propeller Mailbox schema. OK 2 cogs per Prop and two pins per prop. But you can chain a lot of them. The concept here is a common hub buffer, shared by circling around with fast serial thru all props.
The size of the buffer and the meaning of the content is up to your software. Think of common hub shared between props. Easy to use. Easy to extend. Just one prop more into the ring.
One prop could provide clock for all others. I would give each prop a EEPROM and prop plug header.
2 cogs per prop sounds like overkill, but you gain 6 cogs and 26 pins per prop. Not bad.
Enjoy!
Mike
I meant to be specific, but then I forgot. Looking at the board and some photos, I believe it would have to be a breakout board. I have included one photo and the red rectangle represents my work area.
Ah, ok, you want a small breakout board. ( Both 3mm QFN20 and SO16N are much smaller than that space, but not so easy to drop-in-there ).
Cheapest complete system (both halves) is the SiLabs TOOLSTICK850-B-SK, buy this first, and get the Debug block.
( I have no idea why their F850 daughter card has so much waste space... )
A more compact daughter card is the TOOLSTICK381DC, but that final device does not come in sub $1 packages, so I'd avoid that and try to fit the F850 - for a final PCB revision, you could use a sibling device. (QFN20 / SO16N / QSOP24)