electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » DIY Hardware and Software » Microcontrollers and Programmable Logic
Read a lot of inputs a smart way
Post new topic   Reply to topic Moderators: State Machine
Page 1 of 1 [15 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
rhdf



Joined: Jul 11, 2014
Posts: 39
Location: Sweden

PostPosted: Fri Aug 21, 2015 3:12 pm    Post subject: Read a lot of inputs a smart way Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24079
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Fri Aug 21, 2015 4:04 pm    Post subject: Reply with quote  Mark this post and the followings unread

Wild idea then Smile

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 Rolling Eyes

_________________
Jan
also .. could someone please turn down the thermostat a bit.
Posted Image, might have been reduced in size. Click Image to view fullscreen.
Back to top
View user's profile Send private message Visit poster's website
rhdf



Joined: Jul 11, 2014
Posts: 39
Location: Sweden

PostPosted: Fri Aug 21, 2015 5:44 pm    Post subject: Reply with quote  Mark this post and the followings unread

Well One uC/ "block" IS a solution..
My current idea is to have one uC handling all inputs and displays etc
Back to top
View user's profile Send private message
UA3MQJ



Joined: Dec 04, 2014
Posts: 12
Location: Russia

PostPosted: Mon Aug 24, 2015 10:13 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
rhdf



Joined: Jul 11, 2014
Posts: 39
Location: Sweden

PostPosted: Mon Aug 24, 2015 12:05 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
synaesthesia



Joined: May 27, 2014
Posts: 291
Location: Germany
Audio files: 85

PostPosted: Sat Sep 19, 2015 1:25 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
State Machine
Janitor
Janitor


Joined: Apr 17, 2006
Posts: 2809
Location: New York
Audio files: 24

PostPosted: Sat Sep 19, 2015 5:01 am    Post subject: Reply with quote  Mark this post and the followings unread

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 Smile


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
View user's profile Send private message Send e-mail
State Machine
Janitor
Janitor


Joined: Apr 17, 2006
Posts: 2809
Location: New York
Audio files: 24

PostPosted: Sat Sep 19, 2015 5:24 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Send e-mail
rhdf



Joined: Jul 11, 2014
Posts: 39
Location: Sweden

PostPosted: Sun Sep 20, 2015 12:11 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
synaesthesia



Joined: May 27, 2014
Posts: 291
Location: Germany
Audio files: 85

PostPosted: Sun Sep 20, 2015 2:57 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
rhdf



Joined: Jul 11, 2014
Posts: 39
Location: Sweden

PostPosted: Sun Sep 20, 2015 4:42 pm    Post subject: Reply with quote  Mark this post and the followings unread

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 Wink
Back to top
View user's profile Send private message
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24079
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Sun Sep 20, 2015 5:27 pm    Post subject: Reply with quote  Mark this post and the followings unread

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 Shocked

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.
Posted Image, might have been reduced in size. Click Image to view fullscreen.
Back to top
View user's profile Send private message Visit poster's website
synaesthesia



Joined: May 27, 2014
Posts: 291
Location: Germany
Audio files: 85

PostPosted: Sun Sep 20, 2015 11:48 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
rhdf



Joined: Jul 11, 2014
Posts: 39
Location: Sweden

PostPosted: Sat Sep 26, 2015 4:36 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
Electric Druid



Joined: Mar 13, 2012
Posts: 44
Location: UK

PostPosted: Mon Oct 19, 2015 5:44 pm    Post subject: Re: Read a lot of inputs a smart way Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic Moderators: State Machine
Page 1 of 1 [15 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » Microcontrollers and Programmable Logic
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use