[sdiy] Organisation of tasks in synth's main uP

[Carsten Toensmann]

Hi Tom,

I don't know the real overhead using C or any other languages but it might 
be better to use assembler instead of C. Modern controller offer a quite 
comfortable assembler, and my experiences with an 8mhz controller 
(ATmega8535) were good. My µNet keyboard module uses an 8mhz ATmega8535 
scanning a 5 Octave keyboard, creating MIDI messages for 10 voices including 
key velocity, handling an LCD display, scans an analogue joystick (two axis) 
and two digital potentiometers, reading MIDI just with a simple scheduler, 
see also

http://www.analog-monster.de/un_kbd_en.html

Time control of MIDI input or output can be handled by USART interrupts, the 
rest of the tasks below can be handled in a simple program loop. HD44780 
compatible LCDs are not the fastest, I know, but not as slow that I needed 
an asynchronous scheduler / buffer for that.

To cut a long story short: I prefer a rather simple solution: one 
controller, language without overhead, no operating system, just a simple 
program loop.

Regards

Carsten

----- Original Message ----- 
From: "Tom Wiltshire" <tom at electricdruid.net>
To: "Synth DIY" <synth-diy at dropmix.xs4all.nl>
Sent: Monday, November 22, 2010 5:29 PM
Subject: [sdiy] Organisation of tasks in synth's main uP


> Hi all,
>
> Having got started with C, I'm thinking about what I'm trying to do with 
> it - Write code for the main uP in my synth.
> This uP has to accomplish the following tasks, which are common to many 
> synths:
>
> * Scan the keyboard and calculate velocity, note on, etc.
> * Update the LCD screens
> * Update panel LEDs
> * Scan panel buttons and controls
> * Read several ADC channels
> * Process incoming MIDI
> * Send outgoing MIDI
> * Deal with voice assignment
> * Send instructions to the voices over a serial comms link
>
> Most of these things I've done at one time or another, so I'm not too 
> worried about the nuts and bolts of each part. What I haven't done before 
> is deal with a system that does so many different things at once. It needs 
> to do each in a timely manner.
>
> Some of these tasks are quite slow and will delay other things appreciably 
> if not handled correctly. One example is the LCD. LCDs are dog slow to 
> respond, so sending a screenful of information to one will hang up my uP 
> for a considerable time. To prevent this should I buffer outgoing bytes to 
> the LCD? I could then throw LCD data into a buffer and then feed bytes 
> from there to the LCD at a slower rate.
>
> Other tasks are slow, but require fairly swift attention. For example, I 
> could buffer MIDI information coming in, and then deal with it in quite 
> large chunks (say 16 or 32 bytes), but this would entail a considerable 
> MIDI lag, which I'd like to avoid. Instead, I'd thought of calling the 
> MIDI parser each time a status byte arrives. This would mean that the 
> previous message was now complete and could be processed, or that a system 
> realtime message had just arrived, in which case it could be processed.
>
> I can see that interrupts are going to be crucial, but the question is 
> where to focus scarce resources? I know some people here have broken the 
> job down by having a separate uP doing control panel scanning. Whilst that 
> has some benefits, it also implies another set of inter-uP comms which has 
> costs.
> Your thoughts please?
>
> Thanks,
> Tom
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy