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

[Joe Grisso]

Tom,

     I'm currently working on a sequencer which is quite timing
dependent. I'm using bare metal, meaning that I haven't chosen a
particular RTOS, and I'm using an AVR with GCC. One thing I do to
enforce soft real-time capacity is set up a timer interrupt for all of
the time critical tasks I need to do. The timer is usually firing
every 500uS or 1ms depending on the required resolution. For a synth
engine, this might not be acceptable, but it is definitely faster than
responding to MIDI. You might be able to do something like that as
well. There are other techniques you can investigate to maximize
efficiency like slimming down your interrupt routines so they only
shuttle data from the peripheral to main memory, and foist off the
heavy lifting of the ISR into user-space. This is sometimes described
as top-half/bottom-half interrupt routines.
     The decision tree in the master timer-tick interrupt is fed with
data from the main loop and its associated subroutines, which is
passed only after data has been completely updated by whatever process
is handling this. This includes front panel management, sequencer
parameter changes, and processing of ADC/DAC data for things like CV
and quantization. The main routine handles things at the high level -
manipulating data structures which are then read by the interrupt to
do the physical updating. I have a bunch of inline functions to break
up the craziness of this interrupt, and those functions are also quite
small. Using an inline keyword basically removes the function as an
independent piece of code that can be called, and inserts it into the
ISR as an 'in-line' piece of assembly code. This eliminates calling
another subroutine during an interrupt at the expense of code size -
if you call the function elsewhere then the entire code for that
function will be duplicated. So, I make sure that the ISR is the only
routine using that function. :-)
     One other thing to note about languages to write in, I personally
choose C because I move between architectures and OSes so much - AVR,
PIC, ARM, ColdFire, etc. It's easier to port when the language is
somewhat processor-neutral. Also, back when I worked at E-Mu, I
remember good swaths of EOS, the Sampler O/S for the Emulator, being
written in C++. Language is somewhat unimportant given a bare minimum
of appropriate resources and applying the proper programming
techniques. I remember many discussions about function tables,
ctor/dtor caching and other C++ ugliness the firmware guys experienced
when starting to port EOS to ColdFire from 68K.
     I always try to find open-source projects as design examples for
programming. Some of them are good, some of them not so good.
Specifically, I've looked at AVR-X, the x0xb0x project, MIDIbox,
MIDIduino and a bunch of Paul Maddox' code he's open sourced. The bits
of information that can be gleaned are very useful with respect to
program structure, handling timing and processing data in a way that
doesn't gum the processor up too bad.

Best,

-- 
Joe Grisso
Detachment 3, Ltd.

On Tue, Nov 23, 2010 at 5:46 AM, Tom Wiltshire <tom at electricdruid.net> wrote:
>
> On 11/23/10 08:46 , Carsten Toensmann wrote:
>> I don't know the real overhead using C or any other languages but it
>> might be better to use assembler instead of C.
>
>
> Don't worry, Carsten, I've seriously considered it, even for a job of this size. However, I think ultimately C is the better choice because it offers you more in the way of structure (without having to put it there yourself) and makes the conditional logic lot easier to read and debug.
>
> On 23 Nov 2010, at 12:34, Thomas Strathmann wrote:
>> Nothing stops anyone from just writing a simple program loop in just about any language. Overhead is not primarily a language issue: If you compare C and assembler (assuming reasonable C compilers) you'll notice that you can write the same algorithm in any number of moronic ways in both languages. If you know what your target architecture does best you'll be well off regardless of clinging to assembler or C instead of C++.
>
> I quite agree that you can write a simple program loop or hideous code in any language. One advantage of coming to this from assembly is that I do have a clear understanding of what the target architecture looks like since I've been dealing with nothing else for the last goodwhile. I hope that this will enable me (in time) to write C that compiles down to something neat and fast. For now I just have to get up to speed with my C.
>
> As to C++, I learned it at Uni but haven't done any since, and anyway, are there compilers for C++ and dsPIC?
>
> Thanks,
> Tom
>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
>