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

[Paul Cunningham]

You guys might go back and read the recent discussion regarding C. I didn't follow the entire thread, but there's lots of the typical arguments for using C vs assembler on an embedded circuit. Modern optimizing C compilers yield tight object code, and anything else that carries weight can be analyzed and hand-assembled inline. -pc

On Nov 23, 2010, at 2:46 AM, Carsten Toensmann wrote:

> 
> 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 
> 
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
>