ChibiOS Free Embedded RTOS

Hi,

I have an application that used to provide debugging services on an UART, but I've now converted that to use serial-over-USB/CDC .

Now when I deploy my modules into the field, they no longer work. The process gets hung up on not being able to write to the USB serial port .

Suggestions?

Hi,

Are you using sdXXXXX() functions for I/O? you should use channel functions. If the USB is not connected then write operations (without timeouts) will block because the output queue is not emptied.

Not enough info for more suggestions. Make sure to enable debug options in chconf.h, compile with -O0 etc.

Giovanni

I moved from the sdxxx functions to "BaseSerialStream" so that I could officially switch to the USB variant.

If the channel funcitons allow a timeout, that would be nice, but it doesn't help me much. Adding say a 1s timeout to all the writes will block way too many threads for way too long when doing normal stuff that it would slow down to a crawl. I just want it to continue without writing the data in the queue, or something like that, when there is no space.

Then you should check the USB driver state before writing, only write if the USB device is enumerated. Alternatively use TIME_IMMEDIATE as timeout and the write will simply fail if the queue is full.

You cannot expect the USB to behave exactly as a serial port.

Giovanni

I have now made a switch: Debugging output goes to the "console" which becomes the USB port once DTR on the virtual serial port goes high. This means I get serial output, even if it is enumerated on USB, but no program is attached yet.

Even the debugging commandline moves over to USB once the connect is made. [wait!. It took a while.. I now (while writing this) understand why. It was waiting for a serial input byte, only when I hit something on serial it comes back and reads from USB... Not perfect if serial is not hooked up. ]

I've now moved the character processing into the input routines and use a binary semaphore to signal "a line is ready to be processed".

Two threads for the separate input channels. The disadvantage is that the 128byte stack seems to overflow my RAM it works as long as I have only one thread waiting for input adding the second crashes the system....

Hi,

I introduced a fix for this issue: viewtopic.php?f=3&t=2805#p22155

Basically the SDU now recognizes disconnections and stops accepting data in the output queue.

Giovanni

Looks sensible! Thanks!