Powered by Anime » Hardware http://www.poweredbyanime.com Things I've discovered while doing what I do Thu, 20 Nov 2008 01:42:40 +0000 http://wordpress.org/?v=2.8.4 en hourly 1 The source of the number 13 http://www.poweredbyanime.com/index.php/2008/11/12/the-source-of-the-number-13/ http://www.poweredbyanime.com/index.php/2008/11/12/the-source-of-the-number-13/#comments Wed, 12 Nov 2008 16:56:30 +0000 Martin Williams http://www.poweredbyanime.com/?p=61 Thank you Clark for the push – I had another look around and discovered that both 0×0D (13) and 0×0A (10) were being received by the AVR.  Linux was adding the extra 0×0D in front of my 0×0A, causing all the data in the command buffer to be shifted down one, which resulted in the changed numbers, and the strange text output.  After a bit of searching, I found that the stty utility can be used to turn this feature off:

stty -F /dev/ttyS0 -onlcr

So that’s that – now I can get back to working on a utility to encode some colour bitmaps to store in the remaining 10K on the ATMEGA168 I’m using :)

]]> http://www.poweredbyanime.com/index.php/2008/11/12/the-source-of-the-number-13/feed/ 0 What does Atmel have against the number 10? http://www.poweredbyanime.com/index.php/2008/11/10/what-does-atmel-have-against-the-number-10/ http://www.poweredbyanime.com/index.php/2008/11/10/what-does-atmel-have-against-the-number-10/#comments Mon, 10 Nov 2008 23:19:13 +0000 Martin Williams http://www.poweredbyanime.com/?p=52 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.

Why won\'t it display a 10?

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.

]]> http://www.poweredbyanime.com/index.php/2008/11/10/what-does-atmel-have-against-the-number-10/feed/ 4