[sdiy] arduino timing
Paul Cunningham
paul at cometway.com
Wed Mar 16 01:32:06 CET 2011
Thanks Morgan and others!
I have not tried anything with interrupts on the Arduino yet, but your
links were very helpful in understanding what's involved. Since mine
will only need to happen every 12ms or slower, I'm not too concerned
about needing too much time, but I do have a related followup question:
Since I'm currently using the Serial API for MIDI out, will there be
any issues putting bytes into the send buffer at interrupt time? I get
the impression that receiving MIDI via Serial API could be a concern,
but that sending a byte or two should be OK.
Can anyone point me to more technical information about the Serial API
and how interrupts are handled? -pc
On Mar 15, 2011, at 12:55 AM, Morgan Redfield wrote:
> It seems like the best way to do this would be with timer interrupts.
> The Arduino has several hardware counters that you can use to set up
> what amounts to an alarm clock. When the counter rolls over, it
> triggers a small function (interrupt service routine) that interrupts
> any other code that's running. This avoids some of the problems that
> may be caused by having a lot of other code in your loop function.
>
> You can find a good explanation of how to do this here:
> http://www.uchobby.com/index.php/2007/11/24/arduino-interrupts/
>
> You're friendly lurker,
> Morgan
>
> On Mon, Mar 14, 2011 at 9:43 PM, Paul Cunningham <paul at cometway.com>
> wrote:
>> can someone with realtime embedded experience help me here?
>>
>> i've dragged out the Clock Locker Miduino project that i built last
>> year and
>> have been working on the code a little bit. if you aren't familiar
>> with it
>> from my previous post about it, here is a video i made:
>>
>> http://www.youtube.com/watch?v=MN_LT-X7l9s
>>
>> basically it's a little arduino based box that sends MIDI Clock in
>> sync with
>> analog outputs. it's got a big knob to change the tempo and a tri-
>> color LED
>> to indicate the timing. pretty simple.
>>
>> my experience with writing real-time software has never been an exact
>> science, and although i'm not expecting a timing miracle from the
>> arduino,
>> i'd like to learn more about approaches i can take to make the
>> timing more
>> accurate and controllable.
>>
>> by accurate, i'm talking about the calculations necessary on my
>> part which
>> might be necessary to lock in at 120 bpm for example. my loop()
>> looks more
>> or less like this and isn't trying to do anything fancy:
>>
>> void loop()
>> {
>> delay_ms = getDelayMS();
>>
>> delay_counter = millis();
>>
>> if (playing && ((delay_counter - prev_counter) > delay_ms))
>> {
>> prev_counter = delay_counter;
>>
>> if (clock_counter > 95)
>> {
>> clock_counter = 0;
>> }
>>
>> Serial.write((byte) MIDI_CLOCK);
>>
>> clock_counter++;
>> }
>> }
>>
>> this is the gist of what's happening, though there is more in the
>> loop (not
>> displayed here) which handles reading switches, the knob, sending
>> MIDI song
>> position, and animating the LED. obviously this represents additional
>> overhead in my loop timing, but since my getDelayMS() is just
>> reading a
>> value from the Big Knob, setting it has so far just been a "feel"
>> thing.
>>
>> instead of just reading a number from the Big Knob and using that
>> for the
>> delay, i'd like to read an actual tempo from an array so i can dial
>> in
>> specific tempos, but this requires code that needs to be more
>> realtime
>> friendly.
>>
>> what approaches do you think i should consider given the arduino
>> platform to
>> attain this level of functionality? for the time being, i'm just
>> winging it,
>> and i'm sure i can get close enough to what i need via trial-and-
>> error, but
>> it seems there's probably a more academic path i should consider.
>> i'd like
>> to avoid having to profile every line of code in the loop if
>> possible.
>>
>> i know, for example, that to get 120bpm (4/4) the delay_ms needs to
>> be
>> around 21. that's basically 60000 (milliseconds per minute) / 120
>> (beats per
>> minute) / 24 (midi clocks per beat) which works out to
>> 20.833333333333333.
>> that of course doesn't factor in my loop overhead, which isn't a
>> constant.
>>
>> thanks for your help! -pc
>>
>>
>>
>>
>>
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at dropmix.xs4all.nl
>> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
>>
>
More information about the Synth-diy
mailing list