Fast serial communication with Arduino
Vložit
- čas přidán 28. 03. 2021
- In this video I explain how to send data from your Arduino (or STM32) to you computer via the serial port at higher speeds. There are two ways of sending data: one is to send data by using the Serial.println() function which sends the data in “human-readable” format. And the other is by using the Serial.write() function which sends binary data to the serial port. The latter is way more faster but special attention is required when we send the data from the microcontroller and receive it on the computer. The data (typically a number) has to be divided into 1-byte (8-bit) parts then after receiving it on the computer it has to be reconstructed into the original number. Also, the serial port has to be polled by the computer and buffers are needed to read, process and write the data.
As an example, while the Serial.println() function transfers nearly 93000 24-bit numbers to the computer in 5 seconds, the Serial.write() function is capable of transferring about 550000 (nearly 6x more) 24-bit numbers within the same 5-second time period.
Source codes:
curiousscientist.tech/blog/fa...
If you want to support my work, please consider buying the parts using my affiliate links:
curiousscientist.tech/tools - Věda a technologie
Excellent explanation! Thank You!
Hi and welcome! I am glad that you liked it.
That is just from microcontroller to computer. Standard buffering and using hardware. What about fast transmit of data from computer to micro?
I haven't encountered the need of sending data to the MCU yet. It would be probably similar.
Hello! I am wondering how this can be true, cause if you use a baud rate of 2 mil, which means 2 mil bits per second, which further means 10 mil bits for 5 seconds that you tested on, and if you divide 10 mil bits by 24 bits, this gives 416 666 numbers, and you get 550000
Hi! I think you haven't watched the video carefully enough. The answer is there at @2:50.
@@CuriousScientist Okay, but if it doesn't matter how can we know the speed of transmission? Isn't the baud rate something that defines the speed?
@@draganbabic6078 Not in my case, since I used an stm32 microcontroller. It uses handshake-based communication and the baud rate becomes irrelevant.
Cheating… you receive 91k 32bit numbers PLUS the linebreak which is at least one additional byte (two commonly) soooo you receive at least 465845 bytes, I think it‘s actually 580k bytes (two byte linebreak 0x0d0a); and yes write is faster than print especially with larger numbers, since print sends one byte per digit (10000 becomes 0x3130303030 which is actually five bytes… again plus linebreak) so after the tenth iteration you send one character more in decimal, after the 100th two and so on… the actual conversion (which is what makes print slower than write) cuts the speed in half alright, but a factor of six is simply cheated by adding that linebreak and not using the fourth byte of your 32bit number, I bet that if you send a constant 9999 with print instead of println and four bytes 0x09090909 instead of just three the difference will be MUCH smaller
Cheating or not, it was not intentional. I was not aware that line break can have such influence. And thank you for going into such details!
If I use serial.print(), I would need a line break, otherwise I would not know if a new number is received on the client side. Or I could insert a separator character, a letter for example but I don't know how that would affect the speed. With the serial.write() I know the length, it is fixed. So I can easily receive and reconstruct the number on the client side. I believe that most of the people who would use serial.print() would anyway add a line break or an extra character which would probably make a noticeable difference between the speed of the 2 methods. I will try these to learn more.
@@CuriousScientist Sorry that came out harsher than intended.. non native myself; anyways… while I agree that a human needs a linebreak every now and again, I doubt a human would be able to read 100k datapoints per second by eye ;) a computer does well w/o a linebreak either by fixed packetsizes (say six bytes for your example, zerofilling the small values ) or - to not have the 0x00 taking up bandwidth - by having an internal counter in your terminal tool that checks incoming bytes for the next number to know where the packet ends, this isn‘t helping in production code since one seldomly needs such simple counter but for the test it‘d make a fairer comparision IMHO.
I like your idea of showcasing the speedbenefit of write over print (hence me watching your video in the first place) I was just a bit dissapointed because of the reasons I mentioned earlier… it‘s really apples vs watermelons this way, not the apples/oranges I was hoping for ;)
No worries, no offense was taken. I really like these discussions when someone comes and tells that something is wrong or incorrect and also tells why. I am happy that you explained all these things because I could learn from it. When I have a little extra time, I will definitely look at this issue and use your suggestions to see if I can push the performance of the serial.print() further. Thank you!
Usually the delimiter one uses when sending strings is 0xFF. So if you send a collection of strings you place 0xFF at the end of each of them. This is also the way you would find them stored in memory since strings are not fixed length