Setting serial baud rate on ESP-IDF does nothing
31 comments
·August 23, 2025bloggie
kevin_thibedeau
The purpose of baud and other control settings for CDC devices is so that they can serve as a pass-through for a real UART that will need to know what those settings are. Those control packets can be ignored if that never happens.
bobmcnamara
And you can use esoteric settings to trigger device test modes!
jeroenhd
That's not ESP-IDF, that's the Arduino wrapper around ESP-IDF.
Setting the baud rate does actually do something (just follow the baudRate parameter here: https://github.com/espressif/arduino-esp32/blob/master/cores...), it just doesn't affect the output speed of the USB serial output.
If you specify non-default pins for the serial output (i.e. you're opening a second serial connection to talk to another piece of hardware) the begin() method does influence the data rate.
Also, there are dev boards out there that do actually use a TTL converter and USB-to-serial converter to access the standard serial port, though they're not very common as far as I can tell, so I wouldn't just assume the baud rate setting does nothing on the standard pins either.
matthews3
The baud rate is just sent to the USB device, so that if you were making a real USB-serial adapter, you'd know how fast to go :)
YesThatTom2
I always assumed this.
robjwells
I believe this is just down to USB CDC, where baudrate doesn’t affect the USB transfer speed.
raverbashing
This makes perfect sense for backward compatibility reasons
cluckindan
The author seems a bit confused about megabits (Mb, Mbit) and megabytes (MB)
fgh
The screenshot shows a software called "WebSerial Audio Studio". I couldn't find it, only https://serial-studio.com/ which also looks great (and has an open source edition). Does anyone know if it is the same? Looks pretty handy. Microchip had something not so sophisticated years ago.
whatever1
Is it common for microcontrollers to lack comprehensive documentation, or is it just espressif?
LiamPowell
I'm not sure what you mean. There's a 779 page reference manual for the ESP32 series: https://www.espressif.com/sites/default/files/documentation/...
estimator7292
Espressif has some of the most thorough documentation in the entire industry.
TI (a major American IC manufacturer) regularly shits out half baked datasheets missing important information or incomplete explanations of equations. All the American vendors have terrible documentation.
baby_souffle
> All the American vendors have terrible documentation
And half the time you don’t even find out until you’ve created an account and signed an NDA!
Nordic and espressif are some of the good ones, they’re showing up on a lot of my designs for this reason…
riedel
My experience with microcontrollers is not up to date. Most of the stuff I did was 15 years ago.I remember, Espressif really disrupted the market. Things changed already with Advent of Arduino. Before that people wrote a lot of asm code inline and MCUs particularly from microchip had really good documentations (sure some quirks and errata always appeared later, but as I remember they found their ways into data sheets and application notes). Particularly as binary blobs e.g. for network appeared the API went from well defined hardware interfaces to libraries, etc. Today it is even common for some of those domain specific IC that typically rather contain an MCU that you have to sign NDAs to get access to documentation of some parts.
Catbert59
> Most of the stuff I did was 15 years ago.I remember, Espressif really disrupted the market.
They still are.
No vendor until now was able to push out microcontrollers with a solid Wifi integration. Sometimes you can find weird 2-chip-solutions.
I still wonder why ST doesn't bring one. That device would be a multi-billion-business.
estimator7292
ST doesn't want to make one because then you can do OTA firmware updates without their special $60 usb to serial adapter that won't work for non-st parts
05
ST are overpriced, no self respecting internet of shit vendor would be caught dead using their MCUs when cheap clones exist.
MalbertKerman
> MCUs particularly from microchip had really good documentation
Oh how the mighty have fallen. I've only worked on one major project with a Microchip MCU (PIC32MK), but their documentation and support were terrible. No detailed documentation, just a driver library with vague, sketchy API docs and disgustingly bug-ridden code. Deadlocking race conditions in the CAN driver, overflow-unsafe comparisons in timers, just intern-level dumbassery that you couldn't fix without reverse engineering the undocumented hardware. Oh, and of course what documentation did exist was split into dozens of separate PDFs, individually served, many of which were 404 unless you went hunting for older versions or other chips in the product line. It certainly cured me of any desire to touch another Microchip product.
Catbert59
Espressif has stellar datasheets and a very good HAL (esp-idf) with an established community process.
This is more about the application running on that device.
ACCount37
Espressif's docs are good. You don't want to know what "really bad documentation" looks like in embedded.
publicmail
Can’t speak for others, but AVRs usually have excellent documentation IMO. I’ve even seen code snippets for peripherals.
f1shy
There are very well documented uCs. I have to admit , is not like in the good old days, but there are decent documented uCs.
One thing is happening: as uC (and ASIcs) are getting more complex and complicated, more features are added and not fully (or at all) documented.
ocdtrekkie
I was troubleshooting some code of mine that talks to a product Adafruit has been selling for ten years. It turns out the documentation was just plain wrong. Thankfully Adafruit's source code was posted and I could quite confidently see the right way to do it, and submitted feedback on the documentation bug.
But I think this is a space where due to the relative ease and cheapness of putting out a product and often fixing it after the fact, there's less eyeballs on any given aspect of a board or the software loaded on it.
And a years younger me noticed the issue! But I worked around it instead of reporting it. This time I figured out the source of the problem... but the documentation has been wrong a long time in between. ;)
Virtual com ports or USB CDC do not require a baud rate as it's not a real serial port. As mentioned ESP32 has native USB and Arduino/ESP-IDF use USB CDC over this port to communicate with a host computer. Serial.begin() is used for all kinds of serial ports including virtual serial ports. Those libraries probably require a baudrate argument for Serial.begin() which will be ignored. This is probably in the documentation for that function.
If the same function is used on a physical serial port (of which there are a few on ESP32 iirc) the baudrate argument will be used to set the baudrate setting in the peripheral by the library.