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…
Posted in California | 2 Comments »
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 
Posted in Coding, Hardware | No Comments »
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.
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.
Posted in Coding, Hardware | 4 Comments »
August 23rd, 2008
Had my motorcycle here in California for a few weeks now, and it turns out to cost less than half the price of taking a combination of bicycle and train to work – in addition to being way more convenient. The Caltrain costs about $8 a day, while I only need about $6 of gas for the bike every two days!
I do have to calculate repairs into that though – one of my rear brake pads just fell apart last week, so I’m just in getting it replaced. Even with that included it still doesn’t put the cost over the train.
Anyway, I should be back on the road again shortly
Posted in California | No Comments »
August 1st, 2008
Due to some unfortunate circumstances, I’ve recently had to reinstall a few packages onto a RHEL 5 server. Specifically, some of the files provided by those packages had been accidentally deleted, and they weren’t included in any recent backup…
There is no option to tell yum to force the install of a package – if it appears in the rpm database, yum won’t install it. I was able to get around this by first removing the package from the db, using:
rpm -e --justdb --nodeps PACKAGE
Now that the package no longer appeared in the database, a simple:
yum install PACKAGE
Was enough to patch things up.
Posted in Systems | No Comments »