Summary

Mini-update:  debugging while connected via USB CDC drives me bonkers, so I made an alternative configuration where a physical UART is used.

Deets

USB involves a lot of stuff to go on to maintain the connection between host and device.  The on-chip peripheral handles some of that, but other parts are handled in code.  Fortunately, I don't have to write most of that -- it's provided in the libraries, however it does have to be running to maintain the connection.  If it doesn't, the host gives up trying to talk to the apparently malfunctioning device.

And that's the rub:  when debugging (i.e. single stepping) the code, the servicing of the USB is concomitantly halted, and the host gives up on the connection.  Some productive debugging can continue in many cases, however you will ultimately be faced with having to disconnect/reconnect the device to the host (i.e. 're-enumerate') to get the host to recognize it.  Moreover, whatever application was using the USB will likely need to be restarted as well, because the old device handles are of no use anymore.

Because of this, I decided to spend a little time getting a physical UART running, and connecting it to a separate USB-to-serial bridge device (I keep a handful of FTDI boards on-hand for these sorts of things).  In that way, the board can reset, cycle power, whatever, and not require futzing around on the host machine, because it's connected to the external device, not the actual project.

I had already made an adapter of the STM UART library code to my stream abstraction in a separate project, so I merged that it.  At that point is was straight-forward to simply bind the UART stream to the monitor instead of the USB CDC stream.  I modded the project to switch between the two based on a preprocessor definition.  I expect that USB CDC would be what is used in 'production' and the UART would be used in 'development', but who knows?  There's probably general use for both.

Next

Back to implementing the SP0256 interface.