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

[grant at musictechnologiesgroup.com]

There are so many good books and magazines about this it will make your
head spin.  Back issues of Embedded Systems Programming from the 90's
are great in this respect.  Lots of good microcontroller textbooks are
good too.  There was an article series describing MCX11 that was killer.
 Also uCOS is similar (and it has it's own books too).  But it is larger
and more generic RTOS-like. 

I ported MCX11 to the 6809 and later taught courses using both MCX11 and
"MCX09". So there must be docs on it somewhere.  Reading how that works
would be very useful and fun.

Commercial RTOS's work too of course, but the overhead can be high. 
Smaller "executives" can be very efficient.  I use a variation on the
"super loop" with both hard and soft timers. Main loop checks flags to
see what functions (tasks) need to run. Flags (similar to semaphores)
can be set by timers, hardware or other tasks.

A "timer" thing is very easy to do. Have one hardware timer that runs
every ms or 10ms or whatever. When it's ISR runs it evaluates soft
timers for tasks. Once a soft timer counts to zero then it resets the
timer to full value and sets the flag/semaphore. Note that this is
useful primarily for low priority stuff (scanning panel switches or
updating LEDs).  But once you build a framework it gets very manageable.

GB

> -------- Original Message --------
> Subject: [sdiy] Organisation of tasks in synth's main uP
> From: Tom Wiltshire <tom at electricdruid.net>
> Date: Mon, November 22, 2010 8:29 am
> To: Synth DIY <synth-diy at dropmix.xs4all.nl>
> 
> 
> 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