Or maybe avr-gcc is the culprit? Anyway, here’s the story: I’ve been working on building an embedded computer for my motorcycle for some time now. Recently I’ve been prototyping a display module for it. I’ve got a couple of cell phone screens from SparkFun, and some code to drive them from an AVR. So far, so good. I’ve since added a MAX3232 to the mix to allow the actual computer to communicate with the screens. I devised a simple serial protocol that allows me to have some fonts and simple drawing commands stored on the AVR so that I don’t need to send each pixel over the serial line.
It works great – except – that whenever I send a command containing the byte 0×0A, the command gets misinterpreted somehow. If I ask for a large 3 digit display showing the number 10, it displays the number 13. Every time. Every other number from 0×00 to 0xFF is unaffected. If I send a command asking for some text at 10 pixels across, n pixels down, the text appears only as blank spaces, and in a different position.
I’ve confirmed that the byte is being received by the AVR correctly. I store it in a buffer, waiting for the whole command to complete, and I’ve confirmed that it is still stored in the buffer when I go to execute the selected command. The problem appears when I actually unpack the buffer into the arguments needed for the display function calls. Inside the function body, the value that should have been 10 is changed. This happens even if I just pass in the whole command buffer as a uint8_t *.
This makes no sense to me. Especially since I can hard-code a 10 and have everything work without issue. The only thing I can think of is that this is somehow related to the call being made from an interrupt handler, although this hardly explains why only calls involving the number 10 are affected…
I’m going to try moving the main switch into the main loop and see if that changes anything.
