![]() The Arduino libraries are very poorly optimized, so it probably wouldn't be too hard to get a proper 2 Mbaud, at least for burst transmissions, if you spent a bit of time on it. As such, you will never achieve anything better then an effective 500 Kbaud, unless you write your own serial libraries. This is because the code that is placing the bytes in the serial buffer is poorly optimized. I'm using the ground-clip-lead that's part of my scope probe, and the lead-inductance is likely the cause of the majority of the overshoot.Īs you can see, the overall transmission length is the same for 0.5, 1 and 2 Mbaud. Note: The noticeable overshoot is due to poor scope probe grounding practices, and is probably not real. Performance issues! Overall packet length: While the individual bytes may be transferred very rapidly, there is likely to be lots of time when the interface is simply idle.Įach bit-time is 500 ns, which matches exactly with what is expected. ![]() Note that this baud rate only gives the MCU 64 80 clock-cycles per byte, so it would be very challenging to keep the serial interface busy. So it appears the hardware can run at 2,000,000 baud without problems. Serial.println("\r\rBaud-rate = 2000000") Īnd then looking at the relevant serial port with a serial terminal: So given the max stated baud-rate of 2 Mbps, I wrote a quick test program: void setup() Since both MCUs have the same harware and clock-rate, they'll both have the same baud-rate error in the same direction, so we can functionally ignore the baud error issue.Īnyways, the "proper" answer to this question would involve digging up the source for the ATmega16U2, and working out the possible baud-rates from there, but since I'm lazy, I figure simple, empirical testing will work.Ī quick glance at the ATmega328P datasheet produces the following table: We're also fortunate here in that both these MCUs use similar harware USARTs, as well as 16 Mhz clocks. The Uno uses a ATmega328P as the primary MCU, and a ATmega16U2 as the USB-serial interface. This way, if one end is 2.5% fast, and the other is 2.5% slow, your overall error is still only 5%.Īnyways. However, since each end can be off, a more common spec is +-2.5%. General serial interfaces are tolerant of ~5% baud-rate error. However, I have worked with specialized embedded GPS modules that were unable to handle even a 0.5% baud rate error. This can lead to potential issues, as some devices are much more sensitive to baud-rate mismatch then others.įTDI-based interfaces are quite tolerant of baud-rate mismatch, up to several percent error. If there is no integer ratio from the main clock to the bit-time of the desired baud rate, the MCU will not be able to exactly produce the desired rate. The ATmega328P uses a hardware divisor from it's clock-rate to generate the base-clock for the serial interface.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |