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.
Just a random guess, but 0×0A in ASCII land represents a Line Feed which is a special character. It is possible the display function calls handle the 0×0A uniquely as a Line Feed operation which would explain the Blank screen. Perhaps even morphing it into a Carriage Return(0×0D) + Line Feed(0×0A).
Nifty use of the Cell Phone displays from SparkFun.
I had thought of that, but it doesn’t match what I’m seeing. The problem happens regardless of any text processing. Those large numbers, for instance, are blitted out pixel-by-pixel from an array I have stored in ROM…
OK, on further investigation, it looks like the computer on the other end is actually adding a 0×0D before the 0×0A, so both get received, but the 0×0A gets pushed down one place in the buffer, and is thus never seen…
So now I need to find out how to stop Linux from adding that extra byte…
[...] you Clark for the push – I had another look around and discovered that both 0×0D (13) and 0×0A (10) [...]