Author |
Message |
rhdf
Joined: Jul 11, 2014 Posts: 39 Location: Sweden
|
Posted: Fri Aug 21, 2015 3:12 pm Post subject:
Read a lot of inputs a smart way |
|
|
In my project I will have a lot of digital inputs (buttons end encoders)
The simple way is to tie them to 74xx165:s and then connect all these in series. But it seems to be a bit unnecessary to read the state of all encoders and buttons as one big serial "string"
As an example: If I turn a encoder for a filter-parameter, then all the other encoders and buttons on my frontpanel have to be read and evaluated.
What comes up as an idea is some kind of multiplexing where I read a block of controls with some kind of priority where encoders has higher priority than buttons and different parts of the UI is separated (as in: tweak filters= ignore oscillators)
Also some kind of "last parameter touched" would be nice
Smart solutions anyone? |
|
Back to top
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24079 Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320
|
Posted: Fri Aug 21, 2015 4:04 pm Post subject:
|
|
|
Wild idea then
Add a micro controller (or a pico one rather .. thinking PIC10 or PIC12) to each control, and connect all of them to a single wire serial bus ... let the micro's just send on that bus at will, but do detect the situation where a message gets corrupted because of more than one trying to send at the same time, retry after a (short) random interval in that case.
You would want a high speed bus, but basically this is what Ethernet used to do in the old days .. 10 Mb/s over coax ... not suggesting you should implement it like that, it would be to expensive that way .. but as this would be a local bus it could be made much simpler with open collector drivers for instance.
Every device would monitor it's own output and when it reads back what it actually sent it can assume the message got over the bus uncorrupted - could add a checksum for better checking too.
When you'd still want prioritized controls you could consider multiple busses.
Anyway, as it would be very unlikely that that many controls would send at the same time (as you do not hands enough to accomplish that) .. it could actually work I think.
Edit: oh .. and of course modern day radio communication links work like that too _________________ Jan
also .. could someone please turn down the thermostat a bit.
|
|
Back to top
|
|
|
rhdf
Joined: Jul 11, 2014 Posts: 39 Location: Sweden
|
Posted: Fri Aug 21, 2015 5:44 pm Post subject:
|
|
|
Well One uC/ "block" IS a solution..
My current idea is to have one uC handling all inputs and displays etc |
|
Back to top
|
|
|
UA3MQJ
Joined: Dec 04, 2014 Posts: 12 Location: Russia
|
Posted: Mon Aug 24, 2015 10:13 am Post subject:
|
|
|
Use FPGA for read all encoders, buttons, and detect changes (over 40-60 input pins). When change the control, the FPGA sends a message via RS232 to your microcontroller. |
|
Back to top
|
|
|
rhdf
Joined: Jul 11, 2014 Posts: 39 Location: Sweden
|
Posted: Mon Aug 24, 2015 12:05 pm Post subject:
|
|
|
Well, the FPGA-way is a bit over my head at the moment, but something I might look at in the future. On the other hand, with a decent FPGA I can implement the micro in it as well |
|
Back to top
|
|
|
synaesthesia
Joined: May 27, 2014 Posts: 291 Location: Germany
Audio files: 85
|
Posted: Sat Sep 19, 2015 1:25 am Post subject:
|
|
|
What I typically do is use shift registers for smaller blocks and a 4051 or 4067 to multiplex the chip enable or the SDI signal. Also, take a look at port expanders like the MCP23S17. |
|
Back to top
|
|
|
State Machine
Janitor
Joined: Apr 17, 2006 Posts: 2809 Location: New York
Audio files: 24
|
Posted: Sat Sep 19, 2015 5:01 am Post subject:
|
|
|
Just another suggestion when using a microcontroller for switch arrays. A handy feature of many types of microcontrollers are that most digital I/O ports have an interrupt on change feature and do not require any sort of firmware polling to look for any inputs that change. If any button is activated on a port, an interrupt is generated and thus the MCU only services it when a change occurs into your control panel. Just enable the proper interrupt, put a blob of code at the correct ISR vector, and you would have nice compact, efficient, interface controller
Another option is to use a small bit of hardware in your design but only would make sense to use if you already had an MCU in your design. In any event, its nice to know this chip is out there. If anything, It would probably be useful in the design of a 4 octave keyboard controller
Datasheet for : 1MHz I2C-Interfaced 8 x 7
Key-Switch Controller with GPIO Ports
https://datasheets.maximintegrated.com/en/ds/MAX7365.pdf
The MAX7365 will service up to 56 switches, does all the HW debouncing. It communicates over the popular I2C bus which is easy to use.
Thanks for reading.
Bill Last edited by State Machine on Sun Sep 20, 2015 7:12 am; edited 2 times in total |
|
Back to top
|
|
|
State Machine
Janitor
Joined: Apr 17, 2006 Posts: 2809 Location: New York
Audio files: 24
|
Posted: Sat Sep 19, 2015 5:24 am Post subject:
|
|
|
Quote: | What I typically do is use shift registers for smaller blocks and a 4051 or 4067 to multiplex the chip enable or the SDI signal. Also, take a look at port expanders like the MCP23S17. |
Also, some other very good suggestions. Thanks !
Datasheet for that chip:
http://ww1.microchip.com/downloads/en/DeviceDoc/21952b.pdf
Large banks of rotary encoders are more challenging to service than single "1" or "0" type I/O and I like the solution that Jan offered. Using a cheap "pico" sort of controller (6 or 8 pin) to service each encoder.
Bill |
|
Back to top
|
|
|
rhdf
Joined: Jul 11, 2014 Posts: 39 Location: Sweden
|
Posted: Sun Sep 20, 2015 12:11 pm Post subject:
|
|
|
synaesthesia wrote: | What I typically do is use shift registers for smaller blocks and a 4051 or 4067 to multiplex the chip enable or the SDI signal. |
This is close to one of my initial ideas. Group related buttons/encoders in blocks. I imagine that I can get some kind of "last button pressed" priority that way. Or at least "last block"
Encoders is, as mentioned, a bit different. Especially if some kind of potentiometer-likeness is preferred. One solution is to check the rotation-sped. when turned "fast" you increase/decrease the parameter-value with something like 10. wich give 0 to 100% in a normal "potentiometer turn"
(I think midibox MIOS has some solution for this)
Instead of having a micro/control. what about my idea to have a dedicated micro for handling all the inputs and also the feedback as leds and displays (and maybe also handling the patch-saving) |
|
Back to top
|
|
|
synaesthesia
Joined: May 27, 2014 Posts: 291 Location: Germany
Audio files: 85
|
Posted: Sun Sep 20, 2015 2:57 pm Post subject:
|
|
|
Using a dedicated micro is the most flexible solution, but requires to program two chips and develop the inter-communication. Also, you will be limited by the number of port pins and SPI channels available as you will need one SPI on each chip for communication. The biggest advantage I see is that you can move the processing of the encoder events to another chip. I believe it depends on how much processing needs to be done in your main chip. |
|
Back to top
|
|
|
rhdf
Joined: Jul 11, 2014 Posts: 39 Location: Sweden
|
Posted: Sun Sep 20, 2015 4:42 pm Post subject:
|
|
|
synaesthesia wrote: | The biggest advantage I see is that you can move the processing of the encoder events to another chip. I believe it depends on how much processing needs to be done in your main chip. |
My main uC would in that case only generate 3 oscillators (in 2 different mixes) and data for 5 CV:s (IE feed 5 external DAC-cannels)... per voice.
1 voice + handling controls + MIDI processing is not really a problem.
The "UI controller" will eventually also handle displays and led indicators + patch-storage/editing etc.
Yes there will be 2 chips to program and I have to make them communicate.
That's a later problem;) At the moment I'm in the "napkin sketches" phase |
|
Back to top
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24079 Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320
|
Posted: Sun Sep 20, 2015 5:27 pm Post subject:
|
|
|
synaesthesia wrote: | Also, you will be limited by the number of port pins and SPI channels available as you will need one SPI on each chip for communication. |
I was not suggesting to use SPI
That would be not very suitable, I was suggesting to use an open collector bus with collision detection. But yes you would need to design that of course, _________________ Jan
also .. could someone please turn down the thermostat a bit.
|
|
Back to top
|
|
|
synaesthesia
Joined: May 27, 2014 Posts: 291 Location: Germany
Audio files: 85
|
Posted: Sun Sep 20, 2015 11:48 pm Post subject:
|
|
|
Sure, open collector is needed if the chips you connect have no chip enable input that tri-states their serial output. You could also use a single 4052 to control two signals for four channels. I usually use 74HC595 chips and connect SDO and SCLK to all four, and then LATCH (RCLK for the '595) and SDI (from Q7 of the '595) multiplexed via the 4052. |
|
Back to top
|
|
|
rhdf
Joined: Jul 11, 2014 Posts: 39 Location: Sweden
|
Posted: Sat Sep 26, 2015 4:36 pm Post subject:
|
|
|
After some poking around in other projects I realized that Sonic Potions LXR, as an example, uses a "slave" mcu for the frontpanel. It seems in some way as a smart thing to have all the input/display handling separate and just send pure parameters between the 2 processors. (yes I realize it's going to be a pain in the ass to get it running) |
|
Back to top
|
|
|
Electric Druid
Joined: Mar 13, 2012 Posts: 44 Location: UK
|
Posted: Mon Oct 19, 2015 5:44 pm Post subject:
Re: Read a lot of inputs a smart way |
|
|
rhdf wrote: | In my project I will have a lot of digital inputs (buttons end encoders)
The simple way is to tie them to 74xx165:s and then connect all these in series. But it seems to be a bit unnecessary to read the state of all encoders and buttons as one big serial "string"
|
It might be "unnecessary", but simple is good. Don't knock simple.
How about this?: Read the whole string every time. Check each byte against the last known state to see if it has changed (a simple XOR). If there's no changes in that byte, no problem, move on. If something has altered, then you can start looking at it in detail.
I'd warn against overestimating how fast humans are. Control panels can be read impossibly slowly and we don't even notice! Like 50Hz! That's a full 20 msecs between reads. Yawn! Your uP will be falling asleep!
Reading inputs too quickly makes the debouncing worse too, since you effectively see more bounces that you have to allow for.
HTH,
Tom _________________ Electric Druid Synth and Pedal DIY website |
|
Back to top
|
|
|
|