Archive for November, 2008

What it takes to get a motorcycle licence in California

Wednesday, November 19th, 2008

I finally went and got a California motorcycle licence. I had heard that the test was easy, but compared to what I had to do to get my licence in Ontario, it was just silly.

It was held entirely in a parking lot – there was no street driving portion. There were no speed related tests – no braking, no swerving, no cornering at speed. The whole test consisted of driving around a tiny course painted in an area of the DMV parking lot. You have to drive around it twice, once with a slalom around some cones, and once with a couple of straight portions instead. There were no points, just pass or fail. If you drove outside the lines, hit a cone or put your foot on the pavement, you failed. That was it. Crazy.

Also, while I was waiting to get plates issued for my bike, I saw a Chinese lady waiting to take the written test. She was holding what looked like some pages ripped out of a phone book – they even had some English at the top of the page that said something like “Chinese language yellow pages”. The rest of content on the pages was a copy of the DMV multiple choice tests in Chinese, with the answers marked in. What I’m wondering is if this is just an attempt to disguise these study materials, or if there actually is a section in some legitimate phone book that contains these pages…

The source of the number 13

Wednesday, November 12th, 2008

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 :)

What does Atmel have against the number 10?

Monday, November 10th, 2008

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.