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.
usb-uart example sketch and some thoughts about uart
usb-uart example sketch and some thoughts about uart
Last edited by ag123 on Fri Dec 20, 2019 8:13 am, edited 4 times in total.
Re: usb-uart 'example' sketch and some thoughs about uart
for flashing another stm32(f103) via uart
ST states in AN3155 that the boot loading requires even parity
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![Razz :P](./images/smilies/icon_razz.gif)
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
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);
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
![Razz :P](./images/smilies/icon_razz.gif)
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
Re: usb-uart 'example' sketch and some thoughs about uart
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
Re: usb-uart 'example' sketch and some thoughs about uart
Very interesting!
Thanks for sharing.
Thanks for sharing.
-
- Posts: 633
- Joined: Thu Dec 19, 2019 1:23 am
Re: usb-uart 'example' sketch and some thoughs about uart
The rabbit hole is much deeper: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
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.
Re: usb-uart example sketch and some thoughts about uart
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'![Wink ;)](./images/smilies/icon_e_wink.gif)
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
my serial terminal is kind of 'handicapped' no macros etc, so i exploit the convenience of the sketch and did a 'command processor'
![Wink ;)](./images/smilies/icon_e_wink.gif)
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
Re: usb-uart example sketch and some thoughts about uart
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
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