Can Wixel Send a Break Signal?

The Picaxe Programming Editor requires a serial adapter capable of sending a break as a prolog to the program download. The FTDI and CP2102 based USB to serial adapters have this capability and both work with the Picaxe Programming Editor. From this post,“Wixel as Wireless Programmer for BS2 or Propeller” David Grayson states, “If the Send Break command is needed then that feature would need to be added to the app” . I think this answers the question posed in the topic, but I am uncertain how to do it.


Hello, Baxter.

As far as we know, the Wixel is capable sending breaks, but we just haven’t gotten around to implementing it in our software yet. To add it, you would need to do three things:

Step 1: Make it so the Wixel can receive the Send Break command sent by the Windows usb-to-serial driver, usbser.sys. The Send Break command is defined in PSTN120.pdf, which can be downloaded from . You would need to add code to wixel-sdk/libraries/src/usb_cdc_acm.c in the usbSetupHandler() function to handle it. As a first step, just have the Wixel toggle an LED when it receives a Send Break command, so you can verify that it is working. The driver will send one parameter, which is the duration of the break in milliseconds, and we need to keep track of this parameter in subsequent steps. This should definitely be step 1, because we want to find out soon if there is some quirk of usbser.sys that makes breaking hard.

Step 2: Make it so the Wixel can send breaks on its TX line. You would want to add a function to the uart library that sends a break for the specified number of milliseconds. You might want to think carefully about what happens if there are bytes already queued up to be sent on the UART, or maybe it doesn’t matter for now. Rather than do the entire break in a single, blocking function, it would be better to do it in a non-blocking way so the Wixel can attend to its other tasks while it is sending the break. The Wixel’s UART doesn’t support breaking so you will need to temporarily reconfigure the TX line to be a general-purpose output for some time.

Step 3: Assuming you want to do wireless programming, you’ll need to add code to radio_com library for sending and receiving radio packets that represent break signals. Then, in the Wixel’s wireless serial app, you need to tie it all together: when it’s in USB-to-Radio mode it must receive break commands from the usb_cdc_acm library and pass them to the radio_com library. When it’s in Radio-to-UART mode it must receive break commands from the radio_com library and pass them to the uart library.



Thanks for your detailed explanation. I am afraid this is a bit beyond my understanding of the Wixel SDK.
I was hoping that that there might be a simple way to do this such as the following I found on the Internet:


“Method 2
An alternative means of sending a BREAK signal of shorter duration is to temporarily
change the data rate in the UART to half or 1/4 of the actual line speed and then send
a single NULL byte. This is more precise than using SetCommBreak() and ClearCommBreak(),
but it has the disadvantage of corrupting received data during the time the BREAK
signal is being sent (because the received data rate is wrong during that time).
An application can change the date rate in the UART with a call to SetCommState().
The DCB structure passed to SetCommState() specifies the new data rate.”

Maxim-IC (serial to I2C Master, DS2480B)

“The easiest way to generate this is with a serial break longer than a 9600
baud 8-bit word. If break is not available on the host UART then switching to
a slower baud rate and sending a zero byte can simulate a break. Switching to
space parity or changing to a 9-bit word length with a zero in the most
significant bit can also simulate a break.”

I think I will set this aside for a while. Perhaps the Break will show up in the next version of the App.