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

[Mark Rivera]

You might start with a rough calculation of how many cycles each task
will take by looking at datasheets.. e.g., the LCD's, ADC's, etc.
Usually there's enough time to do everything without breaking a
sweat... what I've done in the past (with sequencers) is use the
natural PPQN division of the MIDI clock ticks as my schedule windows.
This seems to work out fine for me at 10MHz (PIC18F). You might find
some natural division of duties like this depending on the tasks of
your synth.

The other important thing is which functions will be on interrupts
and/or timers and what levels of priority your MCU(s) have. The PIC18
only has high and low, for instance.


On Mon, Nov 22, 2010 at 10:29 AM, Tom Wiltshire <tom at electricdruid.net> wrote:
> 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
>