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

[grant at musictechnologiesgroup.com]

> 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.

Totally. I write data to a virtual LCD buffer which takes zero time.
Then a low priority task moves the data from the buffer to the LCD
continually. Very easy and efficient. And of course the user can't tell.
Never check the LCD busy flag *after*. No spin waits. Ever. Pet Peeve of
mine. If you do this correctly you can move data and never see the busy
flag set. Therefore no lost time. 

> 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 haven't read the MIDI parser thread, but there might be some gems in
there. Serial data is SLOW. Many uS between bytes. It is an easy enough
matter to build a state machine that evaluates the data as each byte
arrives and moves the machine along until a message is completely
decoded. Then again you set a flag and/or call the routine as you see
fit. Now you also need to decide on adding another layer or not. You can
buffer the incoming midi data from the Uart into a buffer and decode the
buffer content in the main loop (ie. a task) or you can do it in the
ISR. Flame wars erupt over such things so I won't recommend one or the
other.

> 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.

I would not add a second uC unless you really have to.  Certainly not at
the stage you are talking about now.   Later on maybe.  Small micros are
cheap for sure.

GB