How it works<\/h2>\n
Two wires, crossed:<\/p>\n
| Wire<\/th>\n | Means<\/th>\n | Goes to<\/th>\n<\/tr>\n<\/thead>\n | ||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
TX<\/code><\/td>\n |
<\/p>\n
The third bus, and the oldest. I2C and SPI were designed for chips on one board; a UART link is two wires between two independent devices, each with its own idea of the time.<\/p>\n
It is how the Bluetooth module, the GPS receiver and the SMS module all talk to an Arduino, and it is the same mechanism as the serial monitor you have been using since your first sketch. Those two facts collide on an Uno in a way that catches everybody once.<\/p>\n
Nothing to buy. Seeing What Your Program Is Doing<\/em> and SPI, Faster and More Wires<\/em> are the pages either side of this one.<\/p>\n Two wires, crossed:<\/p>\n That crossing is the thing to remember.<\/strong> I2C\u2019s There is no clock wire. That is the whole design and the source of everything else on this page.<\/p>\n With no clock to follow, the receiver has to know how fast bits will arrive before any arrive. It starts its own timer when the line first drops, and samples at intervals it decides.<\/p>\n So both ends must be set to the same baud rate<\/strong> \u2014 bits per second. 9600 means a bit every 104 microseconds, and the receiver counts in those.<\/p>\n Get it wrong and you do not get an error. You get plausible-looking rubbish<\/strong>, because the receiver is faithfully sampling a signal at the wrong moments. Characters like Faster is not better here. At 115200 on a long wire, or through a breadboard with poor contacts, errors appear that 9600 would not have produced. Use the rate the module wants, and raise it only when you need the throughput.<\/p>\n This is the paragraph the page exists for.<\/p>\n The consequences are immediate and confusing if you have not been told:<\/p>\n So: do not put a module on A Mega has four hardware UARTs and an ESP32 has three, which is one of the real reasons to move a project to a bigger board. Uno, Nano, Mega, Pro Mini or ESP32<\/em> covers that choice.<\/p>\n That sketch is a serial bridge<\/strong>, and it is the single most useful twenty lines in this part of the library. It lets you talk to an HC-05, a SIM800L or a GPS receiver by typing at it, before you write any logic at all. Every one of those tutorials starts by running something like it.<\/p>\n Note the argument order once, because it is the other half of the crossing: It is not reliable much above 38400.<\/strong> The bit timing is done by counting instructions, and at high rates there is not enough time between bits to be sure of anything. 9600 is solid, 38400 is usually fine, 115200 is not.<\/p>\n Only one software port can listen at a time.<\/strong> You may create several, but only the one you last called It blocks interrupts while sending or receiving.<\/strong> A byte at 9600 baud takes about a millisecond, and during it If any of those bite, the answer is a board with more hardware UARTs rather than a cleverer library.<\/p>\n A UART\u2019s idle state is the line held high<\/strong>, at whatever that device calls high. An Uno\u2019s high is 5 V; an ESP32\u2019s, a GPS module\u2019s and most SIM modules\u2019 is 3.3 V.<\/p>\n The direction that matters is Arduino So the common fix is one divider or one converter channel, on one wire. Mixing 3.3 V and 5 V Safely<\/em> has the detail, and the module pages say which of them need it.<\/p>\n Your module is on You see All text and code in this tutorial are original Siratek work.<\/p>\n Baud rates for particular modules are the usual defaults rather than measurements, and each module tutorial gives the figure for its own part. No third-party tutorial text, diagrams, photographs or code has been reproduced here.<\/p>\n <\/p>\n<\/body>","protected":false},"excerpt":{"rendered":" The third bus, and the oldest. I2C and SPI were designed for chips on one board; a UART link is two wires between two independent devices, each with its own idea of the time.<\/p>\n","protected":false},"featured_media":0,"template":"","siratek_tutorial_level":[],"class_list":["post-52378","siratek_tutorial","type-siratek_tutorial","status-publish","hentry"],"yoast_head":"\nHow it works<\/h2>\n
\n\n
\n \nWire<\/th>\n Means<\/th>\n Goes to<\/th>\n<\/tr>\n<\/thead>\n \n TX<\/code><\/td>\nTransmit<\/td>\n The other<\/strong> device\u2019s RX<\/code><\/td>\n<\/tr>\n\n RX<\/code><\/td>\nReceive<\/td>\n The other<\/strong> device\u2019s TX<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nSDA<\/code> goes to SDA<\/code>; SPI\u2019s MOSI<\/code> goes to MOSI<\/code>; UART\u2019s TX<\/code> goes to RX<\/code>. Wiring TX<\/code> to TX<\/code> connects two outputs together and nothing is ever received.<\/p>\n![\"A](\"http:\/\/siratek.net\/wp-content\/uploads\/2026\/11\/uart-and-serial-crossing.svg\")
No clock means both ends must agree in advance<\/h3>\n
\u00ff<\/code> and ?<\/code> and random punctuation are the signature, and if you see them the first thing to check is the number in Serial.begin()<\/code> against the number in the monitor\u2019s corner.<\/p>\nCommon rates, and what they are for<\/h3>\n
\n\n
\n \nRate<\/th>\n Where it turns up<\/th>\n<\/tr>\n<\/thead>\n \n 9600<\/td>\n The library\u2019s default, and most modules out of the box<\/td>\n<\/tr>\n \n 38400<\/td>\n HC-05 modules in command mode<\/td>\n<\/tr>\n \n 57600<\/td>\n Some GPS receivers<\/td>\n<\/tr>\n \n 115200<\/td>\n ESP32 and ESP8266 boot messages, fast logging<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n The Uno has exactly one UART, and the USB cable is using it<\/h2>\n
D0<\/code> and D1<\/code> are the ATmega328P\u2019s hardware serial pins. They are also<\/strong> wired to the USB chip that carries the serial monitor. One UART, two jobs.<\/p>\n\n
D0<\/code> and D1<\/code> fights the USB connection.<\/strong> Both talk at once and both are corrupted.<\/li>\navrdude<\/code> and stk500<\/code> and says nothing about your wiring.<\/li>\nD0<\/code> and D1<\/code> on an Uno.<\/strong> Use the pins for the USB cable, and give the module a software serial port instead.<\/p>\nSoftwareSerial, and what it costs<\/h2>\n
SoftwareSerial<\/code> makes any two digital pins behave like a serial port, by bit-banging the timing in software.<\/p>\n\/\/ Siratek: a module on pins 10 and 11, with the USB serial left alone.\n\n#include <SoftwareSerial.h>\n\n\/\/ SoftwareSerial(RX, TX) - named from the ARDUINO's point of view.\n\/\/ So the Arduino's RX pin goes to the module's TX pin.\nSoftwareSerial module(10, 11);\n\nvoid setup() {\n Serial.begin(9600); \/\/ the USB cable, to your screen\n module.begin(9600); \/\/ the module, on pins 10 and 11\n\n Serial.println(F(\"Siratek: anything the module says appears below.\"));\n}\n\nvoid loop() {\n \/\/ Module to screen.\n while (module.available()) {\n Serial.write(module.read());\n }\n\n \/\/ Screen to module, so you can type commands at it.\n while (Serial.available()) {\n module.write(Serial.read());\n }\n}<\/code><\/pre>\nSoftwareSerial(RX, TX)<\/code> is named from the Arduino\u2019s side, so pin 10 is the Arduino\u2019s receive pin and must be wired to the module\u2019s transmit<\/strong> pin.<\/p>\nThe three limits<\/h3>\n
.listen()<\/code> on receives. Two GPS receivers on two software ports will not both work.<\/p>\nmillis()<\/code> is not counting and your interrupts are not firing. In a sketch doing careful timing, that matters \u2014 Responding Immediately with Interrupts<\/em> is where this collides with servos and tone()<\/code>.<\/p>\n3.3 volts, again<\/h2>\n
TX<\/code> to module RX<\/code><\/strong>: 5 V going into a 3.3 V input. The other direction is usually fine, because 3.3 V is high enough for the Uno to read as HIGH.<\/p>\nCheck yourself<\/h2>\n
D0<\/code> and D1<\/code> and the upload fails. Why?<\/strong> The upload is a serial conversation on those same pins.<\/p>\n\u00ff?\u00ff<\/code> in the monitor.<\/strong> The baud rates do not match.<\/p>\nSoftwareSerial module(10, 11)<\/code> \u2014 which pin goes to the module\u2019s TX<\/code>?<\/strong> Pin 10, the Arduino\u2019s receive pin.<\/p>\nTroubleshooting<\/h2>\n
\n\n
\n \nSymptom<\/th>\n Likely cause<\/th>\n Check or fix<\/th>\n<\/tr>\n<\/thead>\n \n Nothing received at all<\/td>\n TX<\/code> to TX<\/code><\/td>\nThe two wires cross<\/td>\n<\/tr>\n \n Rubbish characters<\/td>\n Baud rates differ<\/td>\n Both ends, same number<\/td>\n<\/tr>\n \n Upload fails, avrdude<\/code> error<\/td>\nA module on D0<\/code>\/D1<\/code><\/td>\nUnplug it to upload, then move it<\/td>\n<\/tr>\n \n Monitor shows two sets of output mixed<\/td>\n Module on the USB UART<\/td>\n Use SoftwareSerial on other pins<\/td>\n<\/tr>\n \n Works at 9600, fails at 115200<\/td>\n SoftwareSerial\u2019s limit<\/td>\n Stay at or below 38400<\/td>\n<\/tr>\n \n Two software ports, only one works<\/td>\n Only the listening one receives<\/td>\n .listen()<\/code>, or a bigger board<\/td>\n<\/tr>\n\n Servo jitters while data arrives<\/td>\n SoftwareSerial blocks interrupts<\/td>\n Hardware UART, or separate the timing<\/td>\n<\/tr>\n \n Module ignores commands<\/td>\n Missing line ending<\/td>\n Many want carriage return and newline<\/td>\n<\/tr>\n \n Module responds once, then stops<\/td>\n Buffer overrun, 64 bytes<\/td>\n Read it more often than it fills<\/td>\n<\/tr>\n \n 3.3 V module behaving oddly<\/td>\n 5 V on its RX<\/code><\/td>\nA converter on that one wire<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Next steps<\/h2>\n
\n
Sources and attribution<\/h2>\n
\n
D0<\/code> and D1<\/code>, the 64-byte receive buffer and the bit timing are properties of the chip and the Arduino core described in their documentation.<\/li>\n