Timer interrupts and SerialUSB.print()

LeafLabs Garden » Support » Maple IDE Support

Timer interrupts and SerialUSB.print()

(4 posts) (2 voices)

Started 5 years ago by StephenFromNYC
Latest reply from poslathian

StephenFromNYC
Moderator

Hello,

Recently, I have been playing around with timer interrupts.

I made a simple modification to the "LED blink" sketch listed at:

http://leaflabs.com/docs/maple/timers/

I added a single SerialUSB.println() statement.

The code compiles and uploads successfully to RAM (based on getting a complete message after the upload finishes), but the Maple seems to hang the first time handler_led() is called. I have not tried uploading to FLASH.

What functions can be called within handler_led()? I know that analogRead() calls work (ie, do not crash the board), but I have not been able to see the value returned by my call to analogRead().

I am using a Maple Rev 3 board, Maple IDE 0.6.0, Windows XP Pro SP3, Java 1.6.0 update 20 ("version 6"; yes, I know that update 21 is available), on a 1 GHz Pentium III (512 meg RAM).

Thanks!

Stephen from NYC

P.S. Here is the first time I am trying to enter code:

Here is the original UNmodified code:

#define LED_PIN 13
#define LED_RATE 500000 // in microseconds; should give 0.5Hz toggles

void handler_led(void);
int toggle = 0;

void setup()
{
// Set up the LED to blink
pinMode(LED_PIN, OUTPUT);

// Setup Timer
Timer2.setChannel1Mode(TIMER_OUTPUTCOMPARE);
Timer2.setPeriod(LED_RATE); // in microseconds
Timer2.setCompare1(1); // overflow might be small
Timer2.attachCompare1Interrupt(handler_led);
}

void loop() {
// Nothing! It's all in the interrupts
}

void handler_led(void) {
toggle ^= 1;
digitalWrite(LED_PIN, toggle);
}

Here is the modified code:

#define LED_PIN 13
#define LED_RATE 500000 // in microseconds; should give 0.5Hz toggles

void handler_led(void);
int toggle = 0;

void setup()
{
// Set up the LED to blink
pinMode(LED_PIN, OUTPUT);

// Setup Timer
Timer2.setChannel1Mode(TIMER_OUTPUTCOMPARE);
Timer2.setPeriod(LED_RATE); // in microseconds
Timer2.setCompare1(1); // overflow might be small
Timer2.attachCompare1Interrupt(handler_led);
}

void loop() {
// Nothing! It's all in the interrupts
}

void handler_led(void) {
toggle ^= 1;
digitalWrite(LED_PIN, toggle);

// this is the only line added to the sketch
SerialUSB.println("Hello at 0.5 Hz");
}

Posted 5 years ago #
poslathian
LeafLabs

Stephen, I will take a close look at your sketch when I have moment. However my first pass answer is to try disabling the USB and see if it then works. You can do this via SerialUSB.end(). Also, roughly, using timers and USB together is "expected to work" however, that isnt to say it isnt reasonable that it wouldnt.

Longer post on the way....try SerialUSB.end() in your setup and remove the SerialUSB print line in your handler. Let me know if that works (I realize its not a fix...since then you dont have serialUSB...)

Posted 5 years ago #
StephenFromNYC
Moderator

Hello,

Thanks for the input, poslathian. I am not near my development system, so I cannot try your suggestions before tomorrow.

I am not sure of the value of calling SerialUSB.end() in setup(), because as your say this will turn off SerialUSB, which is what I want to use later in the handler. Calling SerialUSB.end() is not necessary if I simply remove SerialUSB.print from the handler which would return the code to exactly as it appears in the simpler example on:

http://leaflabs.com/docs/maple/timers/

However, I had two ideas which might help someone else debug the code before I have time.

The first idea is to use the Maple with an external power supply. Will this make SerialUSB more stable if the wire is just used for communication (and not for power). So far, for all my early Maple coding I have been powering the board with the USB cord. I guess I should just make an adapter for connecting a 9V battery.

I am guessing, but is it possible the interrupt code and the handler might be more stable if the SerialUSB is momentarily inactivated in setup()?

Something which might work is to use SerialUSB.end() very early in the setup() function before setting up the timer routines, and then after the timer settings are complete to call SerialUSB.begin() and perhaps also delay(5000) before setup() ends. I am just suggesting five seconds as a guess; something long to give the SerialUSB a chance to reinitialize completely before setup() ends.

The five second delay after SerialUSB.end() might be helpful, because I read somewhere than SerialUSB.end() is pretty harsh and can confuse other code or the host system.

On the Maple I have not tried SerialN.println() instead of SerialUSB.print(). What is faster at sending characters to the host system Serial SerialUSB.print() or SerialN.print()? I prefer the USB method, because the wiring is trivial, but if I can get Serial working at a high baud (at least 115200 baud) then I will be happy.

On the Arduino platform I have not tried invoking Serial.print() from within an interrupt handler, so I do not know if the Arduino would behave any better. Of course, the Arduino requires a Serial.begin().

A separate question. In a leaflabs forum post, how do I get my "code" to appear in a separate "rectangle". I tried to use and in my last post, but it did not work. In the last sentence I was trying to use "& less than colon" and also "& greater than colon" to show < code > and also < /code >. I hope this question gets formatted correctly.

Thanks, and to all a good night!

Stephen from NYC

Posted 5 years ago #
poslathian
LeafLabs

real quickly (again, ill hack on this problem at a later time) - SerialUSB.end() is unique in that it disables the usb interrupts. Even if you dont call SerialUSB.read/print/write/println/etc, USB interrupts are still firing, because thats how USB works (its a polling based protocol...as in every 5ms the host says - do you have data? how about now? now? .... forever). A lot of time this question (do you have data) is not even intended for Maple, but some other device on the usb bus. It is all the devices on the bus responsibility to filter out requests that arnt for them, via addressing. This filtering process also uses the interrupt.

The USB interrupt *could* be conflicting with your timer interrupts in some convoluted way. Thats why i suggested running SerialUSB.end()

As you probably guessed, running SerialUSB.end() disables the auto-reset feature during programming (since thats done over USB). You will have to manually hit reset when programming.

Posted 5 years ago #

RSS feed for this topic

Reply

You must log in to post.