How many inputs is too many? Let's find out!

Hey all!

I've been planning my 'mega controller' for a few weeks, and just started to plan out the circuits. I asked myself a question that I didn't know the answer to... How many inputs can be hooked up to an atmega chip before things start to slow down.

It is theoretically possible to have virtually unlimited inputs, by daisy chaining multiplexers, multiplexing multiplexers, and other various methods... The bottleneck lies in the microcontroller and how fast it can process things. Too many inputs and you'll get latency, missed button presses, and other problems.

We all have dream controllers (my current one has over 200 led's, 2 lcd displays and nearly 200 controls), but since you need to hook these things up to something, it helps to know the limitations of the controller.

http://i.imgur.com/wvXfbl.jpg


I currently have 8 CD4021's (digital multiplexer) and 6 CD4051's (analogue multiplexer) hooked up to my arduino (using an Atmega328 microcontroller). This currently provides 64 digital inputs and 48 analogue inputs, using only 6 digital pins and 6 analogue pins :D

Since the atmega328's only have 6 analogue inputs, I've reached my limit on the analogue side, but the digital side has plenty of breathing room left...

But wait! There's more! I said I hit the limit on the analogue side, but I wasn't really telling the whole truth... The CD4051 provides 8 analogue inputs using 3 digital pins and one analogue pin. Normally you would hook up a bunch of pots or faders to the CD4051 and call it done. What if you connected 8 CD4051's instead? It would require 3 additional digital inputs, but still only one analogue input.

Grade 7 math tells me that 8 x 8 = 64 analogue inputs per analogue input pin on your arduino. 6 analogue inputs times 64 = 384?!?! So using a total of 54! CD4051's, 6 digital pins and 6 analogue pins gives us 384 analog inputs! My theory is that each 'level' of CD4051's would only require one additional set of select pins on the arduino... You would be using a bunch of 4051's, but you could get a few thousand pots hooked up with a few hundred of them ;)

Of course it is completely insane to take it to that level and I will likely only try a single 8x8 setup for proof of concept benchmarking. I'll have pictures and bench mark results as time goes on :)

For now though, my current tests are giving me very pleasing results.. Analogue inputs can be read at 34uS per input + 776uS, so right now I am scanning 48 analog inputs in 2408uS per iteration. BTW, uS = microsecond, one millionth of a second...

I haven't benched the digital inputs yet, since none of my button code works with 64 inputs :)

Pic: 6xCD4051 (top right); 8xCD4021 (top left/bottom)

http://i.imgur.com/7LEVdl.jpg

Can't wait to see what the outcome will be. ;)

I wish you good luck with CD4051 with analogue... they have lotsa cross talk, you'll probably need to fix it in software, and then add some extra latency.

I'm not a Atmel MCU fan, But I would use something bigger with more built-in A/D converter and more inputs to avoid those nasty multiplexers.

THere's by far better product than 4051, check out Microchip I/O expanders. There's also Cypress and NXP one who can go up to 60 I/O on a single chip. OK nothing you can fit easily on a breadboard ;)

I've been using 4051's for multiple controllers and haven't seen any cross talk issues. While I am sure there are better chips out there, I don't have any right now, and I do have a dozen spare 4051's :D

Could you explain why the 4051's are as bad as you say?

I haven't had a whole lot of experience with the atmega's, but I am starting to reach the limitations... Notably the 10bit adc's and only one uart... I've been researching the maple (http://leaflabs.com/devices/maple/) and so far it seems to be quite the chip... I just wonder about how easy it would be to build my own board.... I've never hand soldered a QFN, and it worries me a little bit ;)

Other than the atmel line, what mcu would you recommend? In a perfect world it would have at least two hardware uart's 8+ 12bit adc's, direct usb functionality (ala the teensy)... The most important is the language... I know C/C++, but I don't know assembly, nor do I have the interest in learning :)

I use Microchip's one, Check the PIC18 & PIC24 line. They have C compiler Demo & student version for those. Check out the USB framework, they have a MIDI example in it.

CD4051 have crosstalk, problem is ... crosstalk :D However, for steady DC voltage such as MIDI controller, I'm not that sure it will be that much of a problem. At least nothing you can't monitor with MIDI-OX.

Yeah, I haven't seen much in the way of cross talk at all... The only time I've seen it was with floating inputs. Neighboring inputs would affect the floating one... but in the setup I'm building I am adding 560k pull-down's on all inputs, which seems to take care of things...

My intent is to build my own 'midi brain' that is as modular as possible. I want a good foundation to be able to easily play with various controller layouts..

What specifically do you not like about the atmel line?

No specific reason, Atmel are good, TI's are good, Zilog are good, They're all good. I just begun with Microchip and stick with them for most of my design.

Yup pull-down/up is always a safe bet, add a 0.1uF on the line and you're safe. Could still do some software filter, but it add some extra unwanted delays.

BTW, keep us posted, that seems to be a really nice project here.

When you mention the cap, are you talking about power decoupling or should they be on the inputs (as well as decoupling of course)? If they're on the inputs, wouldn't they add slight (probably imperceivable) delay to the readings? Would that completely eliminate any software side smoothing?

As for the power decoupling, where should I put the caps? I know at least one should be on the daughter boards, but should I add an electrolytic as well, or should they just be on the motherboard?

As far as software filtering, I'm using an approach I found while traveling on the net one night.. It uses a combination of a threshold and timing. The initial movement is by threshold, then it switches to a timer based logic; sending all values until the timer stops, or more movement is detected. This gives me full range of values (which being midi is small enough already) along with solid 'debouncing' to eliminate any jitter.

Quote:

---

Originally Posted by DjNecro

When you mention the cap, are you talking about power decoupling or should they be on the inputs (as well as decoupling of course)? If they're on the inputs, wouldn't they add slight (probably imperceivable) delay to the readings? Would that completely eliminate any software side smoothing?

---

The advantage of the 0.1 uf on the analog line is to remove the noise on the line and smooth the results hence you can also reduce the ADC acquisition time. Noise may come from various places, you want to avoid it and get false ADC reading. You can skip this and do some ADC averaging with 16 or more adc reading... but obviously averaging need more time per input, then add unwanted delays.

Quote:

---

As for the power decoupling, where should I put the caps? I know at least one should be on the daughter boards, but should I add an electrolytic as well, or should they just be on the motherboard?

---

lot of them. One chip... one 0.1uF decoupling, that's the usual decoupling rule, + few low esr cap here and there. Tantalum do decent job and less problematic than yeaaaaaaaaars before ;)

Once you got a schematic I could have a look at and suggest few things.

Quote:

---

As far as software filtering, I'm using an approach I found while traveling on the net one night.. It uses a combination of a threshold and timing. The initial movement is by threshold, then it switches to a timer based logic; sending all values until the timer stops, or more movement is detected. This gives me full range of values (which being midi is small enough already) along with solid 'debouncing' to eliminate any jitter.

---

What I would do is loop the ADC reading, check if some Analog reading changed, if so, output their results. You need the previous and actual value of them, nothing an arrays variable can't solve ;)

For the buttons, then yes a software timer based interrupt could be used. MIDI fighter use this and seems to works pretty well. Same thing goes here, keep a previous reading and compare with the actual. If there's a mismatch output the result.

What I would use is a hardware interrupt. Look at MCP23017 by example, once an input have changed, it send an interrupt signal. From there, you just need to read the chip and process the output and debouncing duties. This is actually faster than timer based, and your MCU can do better thing in meantime...like keeping the USB connection alive and process ADC reading & so on.

Hope it's clear (kind of French to English language barrier here), case not just ask.

I just placed an order for some mcp3008's and 3208's... I assume those are the ones you would use for analogue inputs (if i'm wrong, feel free to correct me).. We will see how they fare...