When you hit Run or Download in your development environment, the program is compiled or tokenized and shipped off to the microcontroller. There's some back-and-forth communication between the micro and the PC during this process. If a serial display is connected to the serial-output pin that's being used for this communication, it's receiving a bunch of nonsense that may include data and instructions that affect its operation.
Case in point: a GLO-416Y (set for noninverted serial, SPol jumper cut), is connected to the TX pin of an Arduino. You compile your program and hit Download. A bunch of nonsense flashes by on the GLO screen, and when the program executes the screen is dim, the font size is wrong, and the first few bytes sent to the display are dropped. Curious, you cycle the power to see what happens, and the program runs perfectly. What gives?
The issue is that during the download, among the bytes exchanged between the PC and Arduino, were the values 0x0F and 0x02, and the sequence 0x1B, 0x44, 0x33... at the end. Those values are interpreted by the display as instructions to dim the display, alter the font size and begin a download of bytes for a custom character. Cycling the power flushes this junk and all is well.
One way to cope with this is to add a startup sequence to your program that clears the screen, sets the correct font size, turns the brightness up (or backlight on), etc. But in the example above, the unlucky inclusion of a multi-byte instruction would swallow some of your remedial instructions. And there's the (admittedly remote) possibility that the random crud could include an Escape sequence that trashes your startup screen or alters other memorized settings.
None of this means that you should never use the dedicated-serial pin for a display. It's tempting—once development is over, the pin is often unused, and other I/Os may be at a premium. Just keep in mind that weird things can and will happen during downloads.
No comments:
Post a Comment