I’m trying to debug my wixel app
thought I’d write debug strings out on the COM port so I can see what’s (not) happening
couldn’t seem to get anywhere, so tried the radio_sniffer app
I can see that (using putchar) it writes to the usb COM port
what baud rate is it using? can’t find anywhere that it sets that
further oddity - tried to install PuTTY
selected
COM10 (that’s what the wixel config utility says it is)
19200 baud (seemed a good place to start
clicked OPEN
nothing happens, I was expecting a window to open but it just sits there
tried the arduino serial monitor, again - nothing
what am I missing?
PS it’s a shame the config utility doesn’t have a serial monitor built in
would make development sooooooooo much easier!
PPS
update
I rebuilt the radio_sniffer app
and now I get serial output at 19200 baud
very interesting!?!
PPPS
more news from the front
seems I was writing to the usb COM port faster than t’other end could cope
now that I’ve slowed it down it seems to be responding
You asked what baud rate the radio_sniffer app using. From your experience with other serial connections, you probably learned that both sides of the connection must be configured to have the same baud rate ahead of time. However, this is not the case when we are talking about USB virtual com ports, such as the one implemented in the radio_sniffer app. In this context, the baud rate is just an arbitrary 32-bit integer that the USB host (PC) sends to the device. The device doesn’t actually need to do anything with that number in order to send and receive bytes on the virtual COM port. The radio_sniffer app ignores the baud rate set by the host. The bit rate used on the USB data lines is 12 Mbps regardless of the baud rate setting for the virtual COM port.
If you are having trouble opening the serial port with PuTTY then I think there might be something wrong with your code. Try loading the example_usb_com app on to the Wixel and see if that works.
The Wixel Configuration Utility is not really meant to be a tool for developing apps. It is faster to have a command prompt window open and type “make load_APPNAME” to compile and load the app. Then to the load the app again all you need to do is press Up Arrow + Enter. The only annoyance is that you need to disconnect your terminal program from the COM port before doing this, so I can see how it would be useful for you to have a Pololu terminal program that somehow knows to disconnect when it is time to program the Wixel.
USB has built-in flow control which makes it impossible for a device to send bytes faster than the host (PC) can handle them, and vice-versa. When you say “I was writing to the usb COM port faster than t’other end could cope” I suspect you were just calling usbComTxSend a bunch of times without first calling usbComTxAvailable to make sure there is buffer space available. Is that the case? It is also possible that the terminal program you are using is written badly and can’t handle high rates of data reception.
aha
I just implemented a “monkey-see-monkey-do” putchar which just, as you suggested, hurls data out without taking any account of anything!
now that you point it out I will add a usbComTxAvailable call
the terminal program I wrote was a bit sloppy but is now coping with high data rates
so progress on all fronts
still can’t get anywhere with putty though (that’s why I wrote my own!)
never mind the quality of code in thw wixel, putty doesn’t even open a monitor window!
) indigestion