Does SerialUSB.print() work during void setup() section?

LeafLabs Garden » Support » Maple IDE Support

Does SerialUSB.print() work during void setup() section?

(7 posts) (4 voices)

Started 4 years ago by rbardsley
Latest reply from mbolivar

rbardsley
Member

I am new to Maple. I have successfully ported my current Arduino code over to my new Rev 5 Maple board, but I am missing something really simple. When my program starts up, it spits out a bunch of nice user-friendly messages during the setup() section of the program. This doesn't seem to work anymore.

During the loop(), my SerialUSB.print statements work great. The same commands just don't seem to fire during setup().

Is this a limitation? Am I doing something wrong?

Thanks for your help. Loving my Maple so far!

Ryan

Posted 4 years ago #
crenn
Moderator

Unlike the Arduino, the Maple doesn't trigger a reset when you open a terminal window, so the messages are happening, just not while you have the window open. I believe this problem is still being looked at.

Posted 4 years ago #
ala42
Member

During reset, the USB connection is disabled. It might take a while, until Windows redetects the device. Add a 2 seconds delay in setup() and check if this helps.

Posted 4 years ago #

mbolivar
LeafLabs

rbardsley,

Besides adding a delay, one thing you might try is just waiting for the host PC to send a character in setup() before printing anything, like so:

void setup() {
    // wait for the user to send a character
    while (!SerialUSB.available())
        ;
    // consume the character sent
    SerialUSB.read();

    SerialUSB.println("hello world!");

    // do the rest of your setup
    ...
}

Posted 4 years ago #

rbardsley
Member

Thanks for the advice everyone. The delay seems to have helped a bit, though it isn't consistent. I haven't had time to test mbolivar's suggestion yet either. And crenn, it isn't just when I reconnect the Maple board to my USB cable. Any debug printlns I have in my setup() loop are skipped. Everything else is loaded, so I know that it has executed that code... just no Serial.print().

I'll keep trying.

Posted 4 years ago #
crenn
Moderator

rbardsley, Every time you reset the Maple, it will 'disconnect' the serial port, 'connect' the DFU, if it doesn't get a response in x time or if BUT hasn't been pressed during start up, it then goes to run program, 'reconnecting' the serial port and 'disconnecting' the DFU. I was just trying to say that every time you open the serial console, the behaviour wanted is to start the program again, however this isn't the case for the Maple.

Adding the delay shows that SerialUSB.print() is happening. Just I note, I usually put in a 5-15 second delay. It is possible to avoid the delay if you're very quick with PuTTy, that is if you have PuTTy with the setting in, upload the code, and when the Maple stops blinking, you can get PuTTy to start reading the serial port.

Posted 4 years ago #
mbolivar
LeafLabs

rbardsley,

As crenn said, the debug println()s aren't "skipped". Here's a more detailed rundown on what's going on.

When the bootloader finishes waiting, it jumps to user code. Your call to USBSerial::println() defers to USBSerial::write() behind the scenes. Here's the source for that function:

https://github.com/leaflabs/libmaple/blob/0.0.11/wirish/usb_serial.cpp#L58

As you can see, USBSerial::write() defers to the libmaple proper function usbSendBytes(), which is nonblocking. If USBSerial::write() notices that USB_TIMEOUT (currently 50) milliseconds have gone by since the last time a call to usbSendBytes() successfully transmitted anything, it aborts.

Probably we should change the return values of USBSerial::write() and the USBSerial::print() family to uint32 so you can tell that nothing was printed (or possibly add a USBSerial::blocking(bool) method which could let you disable timeout).

The reason it exists is to make sure that stray println()s don't hang your program in case the USB host isn't connected or isn't asking for data.

FWIW, I use the method I outlined earlier all the time, and it works fine.

Posted 4 years ago #

RSS feed for this topic

Reply

You must log in to post.