usb-uart example sketch and some thoughts about uart

What could be included in further releases
Post Reply
ag123
Posts: 1655
Joined: Thu Dec 19, 2019 5:30 am
Answers: 24

usb-uart example sketch and some thoughts about uart

Post by ag123 »

hi all,

i've released an 'example' sketch for usb-uart bridging with signals
https://github.com/rogerclarkmelbourne/ ... -w-signals
digging through the (libmaple) codes, i found that it is pretty much possible to handle the various low level usb requests (commands) from the host.
in particular SetControlLineState (DTR, RTS) and SetLineCoding (baud, data bits, stop bits, parity).

the commands/requests are defined in the USB-CDC-ACM device class specifications
https://www.usb.org/document-library/cl ... devices-12

These are integrated into the 'example' sketch and i think pretty much makes is work the same as the common usb-uart dongles.
there are a couple of motivations for writing this though of course usb-uart dongles these days are 'very' cheap
https://www.aliexpress.com/wholesale?ca ... ext=cp2102

one of which is that such a sketch is firmware/software, so that same bp/mm board can be repurposed as needed. kind of making it more 'efficient' as common usb-uart dongles just does that usb-uart dongles. while bp/mm warp between usb-uart to a full blown mini 'oscilloscope' etc and many different use cases. the other thing is that since stm32f103 sits 'between' as the usb-uart bridge, it isn't simply a usb-uart bridge.
my sketch implements a 'command processor' and therefore provides a means to add functionality that may otherwise not be there and isn't addressed by conventional usb-uart interfaces.

i've actually used this sketch among my trials to flash firmware on (other) stm32f103 (mm/bp) as well as esp-01 (esp8266). and that 'command processor' i basically used it as a 'shortcut command' interface while testing out esp-01 esp8266 functionality. the AT commands are rather verbose and making shortcuts for some of them makes it easier to test embryonic protocol steps from the host via a serial monitor.
Last edited by ag123 on Fri Dec 20, 2019 8:13 am, edited 4 times in total.
ag123
Posts: 1655
Joined: Thu Dec 19, 2019 5:30 am
Answers: 24

Re: usb-uart 'example' sketch and some thoughs about uart

Post by ag123 »

for flashing another stm32(f103) via uart
ST states in AN3155 that the boot loading requires even parity

Code: Select all

//AN3155: usart boot loader requires even parity
// but literally those parity stuff is not (yet) implemented in the core
// and somehow it works! ;)
//Serial1.begin(115200,SERIAL_8E1);
one of those things though as i found out is that HardwareSerial (e.g. Serial1) currently literally don't handle the line discipline flags
https://github.com/rogerclarkmelbourne/ ... al.cpp#L73
so it is literally 8N1 default. it is rather surprising as i've successfully flashed bootloaders and skeches, though AN3155 specifically states 8E1 :P

next some questions, would any one be keen for support of those 'line discipline' flags in HardwareSerial?
i'm not sure if currently the likes of those SERIAL_8N1, SERIAL_8E1, SERIAL_8O1 etc.
i found out in addition that unlike the more 'professional' usb-uart hardware stm32f103 uart bascially support only 8 and 9 bits word length. any other combinations 3,4,5,6,7, 10-16 etc isn't there. but i'd guess 8 bits is about the 'de-facto standard' in the industry.

another thing is that it may require some tweaks to those defines SERIAL_8N1, SERIAL_8E1, SERIAL_8O1 etc at least in the definition.
i'm not sure if changing the bit patterns in those defines would after all break anything else.

an issue as i found out is that the 3 different parameters bits, stop bits and parity create a lot of different combinations and permutations. so that probably isn't a good way to handle it except for the most common cases such as 8N1. the rest probably need to be done as discrete methods/functions for setting the bits, stop bits and parity separately.

note that one can still handle the line discipline flags, even without doing so in HardwareSerial just that it takes accessing the stm32 usart registers directly, and the current libmaple usart.h has those registers defined
https://github.com/rogerclarkmelbourne/ ... le/usart.h
e.g.
https://github.com/rogerclarkmelbourne/ ... s.ino#L241
ag123
Posts: 1655
Joined: Thu Dec 19, 2019 5:30 am
Answers: 24

Re: usb-uart 'example' sketch and some thoughs about uart

Post by ag123 »

it is interesting that the 'ancient' uart is still relevant today, simply because for one thing, framing and parity checks is there. and it literally makes that comms channel clean as noise (just press reset on target, without framing checks, it generates 'extra' bytes) and corrupted bytes are simply discarded
User avatar
Just4Fun
Posts: 28
Joined: Thu Dec 19, 2019 10:45 am
Answers: 1

Re: usb-uart 'example' sketch and some thoughs about uart

Post by Just4Fun »

Very interesting!

Thanks for sharing.
mrburnette
Posts: 633
Joined: Thu Dec 19, 2019 1:23 am
Answers: 7

Re: usb-uart 'example' sketch and some thoughs about uart

Post by mrburnette »

ag123 wrote: Fri Dec 20, 2019 7:18 am it is interesting that the 'ancient' uart is still relevant today, simply because for one thing, framing and parity checks is there. and it literally makes that comms channel clean as noise (just press reset on target, without framing checks, it generates 'extra' bytes) and corrupted bytes are simply discarded
The rabbit hole is much deeper:
https://en.wikipedia.org/wiki/Teleprinter

Ray

PS: I not too keen on using a uC for mucking around with inline serial protocols (store-manipulate-forward)... unless extreme care is taken in programming, different software branching and logic will result in the output signal having positional "jitter" and non-uniform periods. It can be done, but dedicated h/w is inexpensive.
ag123
Posts: 1655
Joined: Thu Dec 19, 2019 5:30 am
Answers: 24

Re: usb-uart example sketch and some thoughts about uart

Post by ag123 »

thanks ray, in the case of my sketch, it is just a convenience feature i used while i'm testing out the features of esp8266 AT rom.
my serial terminal is kind of 'handicapped' no macros etc, so i exploit the convenience of the sketch and did a 'command processor' ;)

btw i still think the usb macrocell h/w and uart are cool little things on the stm32f103 that makes it matters. just doing this could have been very difficult without those h/w on stm32f103. the usb macrocell is complex / elaborate, it literally handles the usb data down to endpoints which are basically logical channels. it is as if there is an 'ethernet' controller there but just that it is actually usb

And of course libmaple core and the libraries made a difference
ag123
Posts: 1655
Joined: Thu Dec 19, 2019 5:30 am
Answers: 24

Re: usb-uart example sketch and some thoughts about uart

Post by ag123 »

i thought a little about this usb-uart sketch, apart from it being basically a sketch, so the cool little thing is the same 'pill' board can be repurposed for something else when not used as usb-uart. this is a nice 'value add' here. what other 'value add' could there possibly be?

as i meddled in the sketch, it become quite apparent that the sketch connects the usb-serial signals to the actual uart signals.
there are some usb-uart dongles the implements the protocols a little differently, but that is good enough to cause incompatibilities when one tries to do things like flashing a firmware. e.g. the dtr, rts signals need to be inverted between usb signals to the rs232 signals. some dongles i'd guess implement a 'straight thru' for the dtr/rts signals and that would mess up things like reset etc.

in this sketch the dtr/rts signals are literally inverted in code so that it would actually work. i stumbled into a bummer trying to flash a esp8266 using the esptool utility. as it turns out, inverting the dtr/rts signals made all the difference. esptool works 'out of the box' once the sketch appropriately implements the signals as do a usb-uart dongle. for conventional usb-uart dongle, this fix is 'impossible' as the usb-uart dongle is made to work a particular way.
stories of those troubles are after all quite real, part of the reason for implementing the 'command processor' is also that esp8266 requires a particular baud rate 74880 while one is flashing a rom on esp8266. with the baud controlled in codes, i've been able to make the esp8266 boot into 'program' mode (74880 baud) with legible prompts, prior to switching from serial monitor to esptool to flash the rom
https://github.com/esp8266/Arduino/issues/1207
https://github.com/espressif/esptool/issues/19
Post Reply

Return to “Ideas & suggestions”