EEVblog Electronics Community Forum
Electronics => Beginners => Topic started by: iampoor on September 04, 2013, 02:51:13 am
-
How can yo0u get large large numbers of inputs and outputs on a microcontroller?
Is it possible to route say 20 rotary controllers and 100-200 outputs on one microcontroller?
Also, is it possible to link microcontrollers in parrallel to recall certain "scenes" in a memory? Or to feed them from one host microcontroller?
I know these are very vague and big questions, just trying to see if an idea I had in my sleep is feasable or not! haha
-
How can yo0u get large large numbers of inputs and outputs on a microcontroller?
Is it possible to route say 20 rotary controllers and 100-200 outputs on one microcontroller?
Also, is it possible to link microcontrollers in parrallel to recall certain "scenes" in a memory? Or to feed them from one host microcontroller?
I know these are very vague and big questions, just trying to see if an idea I had in my sleep is feasable or not! haha
Let's use ATMega328 (the one I know) as example.
Doing the math, assuming you keep D0/D1 for RS232, and say D13 for an LED, you are left with 10. 10 digital lines give you 1024 possible numbers. 1024/200 = 5.12. That is 5 different states for each of the 200 outputs. Not 5 digital lines, but 5 possible states. 2 digital lines gives you 4 numbers, and 3 digital line gives you 8. So, if each of your encoders gives only 2-bit resolution, you are fine - but I doubt it has only a 5 count resolution.
You can do the math and see how much you can squeeze in. If you have a 5 count encoder, you sure can squeeze it in but it will take a lot of multiplexing to integrate 400 (200x2) down to 10.
Same thing for memory. You have 32K. How much does it take to store a scene and how big is your program? Do the math and you can figure out.
-
How can yo0u get large large numbers of inputs and outputs on a microcontroller?
Is it possible to route say 20 rotary controllers and 100-200 outputs on one microcontroller?
Absolutely. There's always the good ol' 'HC595 and 'HC165, cheap and cheerful, if you don't mind somewhat slow output. Of course, if you route your PCB carefully, you can clock them well above 1 MHz with no trouble. Try to multiplex as well if you can, though sometimes it complicates things.
Also, is it possible to link microcontrollers in parrallel to recall certain "scenes" in a memory? Or to feed them from one host microcontroller?
I know these are very vague
Yes. Vague. What? Are you wondering about using the outputs from one MCU as a fraction of the lines of one bigass parallel interface? Yes, you can do that, but why would you?
-
Goto digikey and parametric search for micro by pin count:
http://www.digikey.com/product-search/en?pv157=495&pv157=388&pv157=491&pv157=470&pv157=604&pv157=421&FV=fff40027%2Cfff800cd&k=microcontroller&mnonly=0&newproducts=0&ColumnSort=0&page=1&quantity=0&ptm=0&fid=0&pageSize=25 (http://www.digikey.com/product-search/en?pv157=495&pv157=388&pv157=491&pv157=470&pv157=604&pv157=421&FV=fff40027%2Cfff800cd&k=microcontroller&mnonly=0&newproducts=0&ColumnSort=0&page=1&quantity=0&ptm=0&fid=0&pageSize=25)
Highest value was 256 I/O pins on some Freescale, Infineon, XMOS, and Toshiba parts.
Usually you'd use external I/O expansion of some type.
-
Plenty of ways to increase inputs and outputs.
I've used shift registers and multiplexing for both I and O to expand the number of IO resources available.
No idea what the "scenes in memory" thing means :-//
-
Thanks for all the speedy replies!
Im going to draw a diagram of my idea, since I dont trust myself to explain it clearly!
Also note, I am pretty experienced with electronics, very new with digital electronics...the idea I have it so over complicated and large I know its going to take years to finish! Just had a crazy idea today, and want some more knowledgeable folks to tell me if Im plain stupid or its just too complicated. ;D
Cheers!
-
Okay so here is the basic idea.
Imagine a mixing console with full digital control over analog parameters. Instead of pots, there would be rotary encoders that set values, which then control analog components. There would be 10-20 rotary encoders (single parameter per encoder) per channel for all parameters, and then would be controlled by a microcontroller through switching transistors. (Hence the large number of outputs for all the potential combinations).
The idea is that the settings for each channel could be recallable in "scenes" stored on a computer through a plugin. Hence there would be another microcontroller sending recall data to all of these in parallel and handling the presets. Maybe unneccessary?
http://imageshack.us/f/194/v4h0.png/ (http://imageshack.us/f/194/v4h0.png/)
Again, this is one of those crazy "Will probablly never manifest" itself ideas that I had today.
-
Sounds a lot like something 595s and 165s would be good enough for if you must do it that way.
-
Sounds a lot like something 595s and 165s would be good enough for if you must do it that way.
Thats definitly the impression Im getting. Not totally worried about recall speed, just would want it to not be much longer then lets say 10 seconds. Which seems very doable...
-
Aren't consoles usually very modular to begin with? Why not have a microcontroller per module reading a few encoders and communicate with the board by some kind of bus? Then you can easily interchange modules, enumerate what's installed, and solve your many inputs problem.
-
The latest issue 16 of "The MagPi" has an introduction to I2C using the MCP23008 chip.
http://ww1.microchip.com/downloads/en/DeviceDoc/21919e.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/21919e.pdf)
http://www.themagpi.com/issue/issue-16/ (http://www.themagpi.com/issue/issue-16/)
There is also a MCP23017 16bit version used in a device called a Pi Matrix.
http://w8bh.net/pi/PiMatrix1.pdf (http://w8bh.net/pi/PiMatrix1.pdf)
Naturally it is geared to the Raspberry Pi but It might give you a few ideas. It is not the scale of I/O you wanted but I think with I2C you could use several devices to get more.
Thanks! Im going to read that! The more info the better!
@Ve7xen: Yes, and the idea is for this to be very modular. Thats along the ideas of what I was thinking....One per module, and then one to send data/communicate with a PC. Or would it be possible to write a communication protocal ignoring some sort of "master controller"?
-
The old 165 workhorse will do that for sure. Like someone (Dave?) commented, you can easily get MHz+ bitrates using SPI. Reading the rotary encoders should not be an urgent business, seeing how they are human input devices. 100ms is short for a man but an age for a MCU. The 165 and 595 will go a long way. Reading in 20 8-bit encoders would take just ~200 us depending on the coding solution. Surely not a show stopper.
Or you could go fancy and use an I2C bus to let the individual units report their status and changes in it. That would of course require a processor at each node but then processors are cheap. That kind of solution would have several pros with the cost of small added complexity. Might be worth considering - i would.
Edit: ve7xen just beat me to it :)
Note that the Microchip I/O expander you mention is ~1 EUR per shot, and say ATmega328 processor is about 1.5 EUR - not too bad a difference. The 328 would let you do the prototyping using Arduino or Arduino HW and later migrate the working code to your own HW solution. Also, the node would then be fully programmable. This would mean among other things that you are not limited to periodic scanning, not limited to a pre-defined I/O configuration etc etc. I would go that way.
Edit^2: Regarding the comms architecture. I would have a separate gateway unit to communicate with a PC. That way you can abstract the low level bus HW away from the PC and use whatever is easiest for the PC to do. That would most likely be USB. Also, the gateway should virtualize the individual elements of the low level bus so that the PC has no need to know the implementation details. It can operate on purely virtualized elements. The gateway acts as a HAL layer and comms hub. If it was me, i would look into a nice ARM chip for this purpose, for the performance and I/O capability (many ARMs have a built-in USB interface, and one or more I2C for sure). Also, operating systems like ChibiOS are supported for many ARMs, making use of these interfaces much easier (ChibiOS has its own HAL layer to abstract the chip peripherals).
Edit^3: Regarding the "scenes" you mention. I guess a SW guy would use the word "configuration" in the sense of the momentary state of the system's inputs and outputs. If so, the answer is of course "yes". It can be done in several ways.
Assuming there is a comms gateway hub as outlined above, then it is the assumption that this configuration is maintained in the memory of the hub. After all, it reads all inputs and controls all outputs, right? So by a specific command the hub can store a snapshot of the configuration in permanant memory of some kind (possibly an attached SD card or internal permanent memory or something else, subject to configuration size and other requirements). Another specific command and a configuration is read and transmitted to the nodes of the system. Note that to be able to set a configuration for inputs, all of them need to be "soft", i.e. encoders or tactile switches or similar, where the state of the input is maintained in a memory of some kind. It is this memory that is reprogrammed when restoring a configuration.
The configuration can also be maintained in a PC if that makes more sense. In that case the gateway-PC communication must include message types to transmit configuration info both ways. Probably not a big deal, because data of this kind needs to be moved anyway, otherwise why have the link in the first place.
-
With large numbers of encoders, speed of response, and ability to service multiple simultanous changes is going to be an issue with shift-register solutions.
ALso, large pin counts on any chip get expensive due to the die size needed for the bond pads. You should probably look at a modular solution with multiple low-end devices doing the local encoder stuff, with a serial bus to read back the values.
Or maybe look at a CPLD, which will generally have a better pin-count to cost ratio, and be able to handle multiple encoders in parallel.
-
There are microcontrollers in easy to use packages like dip , soic, quad flat pack varieties which have 40-60 pins and about 32 i/o pins.
You can use shift registers to get more input / output pins, those are old and simple.
There are also port extenders, for example here's one that gives you 60 i/o ports in a 100qfp package : http://www.digikey.com/product-detail/en/CY8C9560A-24AXI/428-2017-ND/1640248 (http://www.digikey.com/product-detail/en/CY8C9560A-24AXI/428-2017-ND/1640248)
Microchip has easier to use port extenders in dip packages and other easier to use packages, with i2c and spi interface, easy to use, for example this one for 16 i/o ports : http://www.digikey.com/product-detail/en/MCP23017-E%2FSP/MCP23017-E%2FSP-ND/894272 (http://www.digikey.com/product-detail/en/MCP23017-E%2FSP/MCP23017-E%2FSP-ND/894272) (and since it's i2c you can chain several of them)
Anyway, here's a large selection, knock yourself out sorting and reading datasheets: http://www.digikey.com/product-search/en/integrated-circuits-ics/interface-i-o-expanders/2556690?quantity=50&ColumnSort=1000011&fid=0&pageSize=50 (http://www.digikey.com/product-search/en/integrated-circuits-ics/interface-i-o-expanders/2556690?quantity=50&ColumnSort=1000011&fid=0&pageSize=50)
-
[...]
Or maybe look at a CPLD, which will generally have a better pin-count to cost ratio, and be able to handle multiple encoders in parallel.
10-20 encoders? Surely not, or at least not very feasible. That would imply a minimum of ~160 signal inputs with no possibility for expansion. While such CPLDs may exist (haven't checked) that would probably be far from the simplest and easiest way to do it.
Also, the OP did mention a modular architecture, and this would be the exact opposite.
Like you also suggest, modular seems to be the way to go.
-
. Instead of pots, there would be rotary encoders that set values, which then control analog components. There would be 10-20 rotary encoders (single parameter per encoder) per channel for all parameters, and then would be controlled by a microcontroller through switching transistors. (Hence the large number of outputs for all the potential combinations).
Google "daisy chaining serial" - that is one proven and established way of minimizing communications hardware/interfacing. Most serially programmable devices support daisy chaining.
-
Definatley use PISO's (HC165 and similar) and SIPO's for interfacing. I'm using 7x 74HC165's to scan 49 inputs at 48KHz (3.072MHz SPI clock) on a commercial product, no problems at all.
The main advantage (apart from cost) is that you can put the SIPO/PISO's near your inputs/outputs, and it is alot easier to route a daisy-chain.