Memos From the Cube

Happy new year everyone!

Now is supposed to be my free time of year, in my summer break from University. A time to kick back, relax, and code up until 3AM on a Wednesday night. That’s not been the case - I’ve actually been quite busy! These last few months since University finished for the year, I’ve been busy working at a neat place called the Center For Health Innovation (thats the current website, my current assignment is to upgrade it) which has led to some nice ongoing projects. I got to say, it’s been darn nice seeing my bank balance go up regularly instead of down! Working in a real environment doing real projects has proven to be quite rewarding (and educational), much more so than my original failed plan to get a job in retail for a few months during my holidays.

On that note, thank you all who have donated. I’ve been astonished at the level of generosity of people visiting my site and using my work.

I never expected such a response to my last post! There’s been more discussion on that unrelated rant, than on any of my many previous posts about my development milestones. For the record, I do not hate Linux in general, just the level of support on my modern hardware (a Toshiba Satellite A210, for those asking, with ATI graphics, Dual 1.9GHz AMD Turion CPU, 2GB RAM). That’s not all the Linux developers fault; my point is that it is unsuitable for general use by the general non-technical populous until driver support improves. Whether than means yelling at the hardware vendors or not is up for debate, but the summary would be:

• User expects OS to work on hardware
• Windows works on hardware
• Linux does not work on hardware
• User concludes Linux is bunk

I’ve actually gone ahead and ordered a the latest Ubuntu CD from the site, in the hopes that the last release fixed the issues for me in 7.10. I’ll repost when that arrives and I have time to give the new version a go.

On another unrelated note, the past weeks have seen a few neat new gizmos arrive in on my doorstep. Over from AVROpendous.org I received the latest incarnation of the board, the AVROpendous Mini (photo stolen from the AVROpendous page):

The new board is much smaller than the old, forgoing the previous SIL header strip - allowing it to be inserted vertically into a breadboard - for tiny female DIL headers of the same size as the USBKEY headers. Unlike the USBKEY however the AVROpendous Mini has the benefit of actually having said female headers mounted, removing the head-scratching problem of how to wire the darn thing up to anything. Standard solid-core breadboard wire will fit into the headers for easy prototyping to an existing breadboard. In case that’s not your cup of tea, there’s also a new adapter board which the Mini plugs into, to make it of the same form factor (save width) as the original AVROpendous, and an adapter to make the Mini easily wireable to a HD44780 based Alphanumeric LCD display.

Second, I’ve recieved some hardware from Denver Gingerich, over as OSSGuy, shown below after being Macgyver’d  into an old box of mine by myself to protect it:

Sporting a three-track magentic card reader and a custom board based on the AT90USB1287, my new firmware for it allows it to act as a USB keyboard and type the card data to the host. Denver’s new host-side software will be able to convert this read data into (hopefully) something meaningful, but for now I’m considering making it into an esoteric security system based on train tickets, which come with magnetic stripes here in Australia.

Much work to do - Dean out.

Happy holidays, Merry Christmas and all that to you all. Have a safe and joyful week or so off from the monotonies of work.

Yesterday I received some new AVROpendous Mini boards, which I’ll post more about soon. Today’s focus is on what I’m NOT impressed with, a set which most definitely excludes the AVROpendous.

Today, the cause of my frustration: Ubuntu. I’ll extend that - Linux in general. I’m sure to raise the hackles of quite a few folk - but let me say this: Linux sucks for the most part. Specifically, its compatibility sucks, although that is more due to the fault of manufacturers than the developers, but using it one can get the feeling that the entire system is a house of cards just waiting to fall down.

Today for the second time on my new laptop, I tried to get a dual boot Ubuntu/Vista system set up. Easy enough - I repartitioned the drive in Vista, inserted the Ubuntu disk and away I went. Towards the end I deliberately disabled the installation of the GRUB bootloader, so that I could use a modified version of the Windows Vista bootloader to perform the dual boot. Big mistake.

First up, the Ubuntu live CD just doen’t play nice with my laptop. Out of the box, there’s no graphics card support, no audio, and no wireless. It also hasn’t got a clue how to manage my motherboard’s ACPI, leading to a failure to sleep, scale the CPU or CPU fan speed, or even stay on reliably. It literally would die unexpectedly occasionally with a hard power-off, despite being plugged into AC power at all times.

Next, the installer decided to remove the boot flag of my Vista partition, even though I explicitly told it not to mess with the system boot. That led to a totally unbootable system, forcing me to go back to the live CD and fire up gparted to fix the flag. God knows what less computer literate folk would have done when confronted with a “No Operating System Found” error on boot.

So, I was back to my Vista boot install. Next, I installed EasyBCD to modify the bootloader and add a modified GRUB to boot to the Ubuntu partition. No dice - I had to Google for the correct Ubuntu grub menu entries for my distribution, as there was no way to get into the Ubuntu parition and find the image name in /boot/.

Having wasted several hours thusfar, all I managed to get was a disk with 10GB less than I started with, and a broken dual boot which would give the option of booting into Vista, or booting into a totally black screen. Nice.

Attempt three: back to the Ubuntu live CD to try to install GRUB. After a LOT of fanangaling around trying to get grub-install to work, more Googling told me to first change the boot flag to the Ubuntu partition using gparted again, and then manually copy over critical GRUB files to /boot/. That required me to first mount the installed Ubuntu partition in the live CD session.

Once more, time wasted, nothing gained - same black screen as before when booting Ubuntu. I eventually decided to start over, wiped the Ubuntu partition and re-ran the Ubuntu installed - this time allowing it to install GRUB. That led to a working dual boot, although I still had the same driver issues in the installed partition as I did with the live CD version.

SOUND: Apparently this requires the installation of some backport packages, and changes to the ALSA configuration files. Gave up before I got around to trying the fixes posted on the web.

VIDEO: Ubuntu has a nice “Restricted Drivers Manager” for the installation of proprietary drivers. Try as I might, I couldn’t get the video driver to install, with the system throwing an error about a xorg-driver-fgrlx not being found. Ran sudo apt-get install xorg-driver-fgrlx, which didn’t work. Eventually gave up.

WIRELESS: First I tried using ndiswrapper and the Windows drivers to my wireless card. As far as I could tell the installation worked fine, but not a peep from iwconfig. Started to try MadWIFI, but couldn’t get the package to download and install correctly.

Eventually, I gave up, after having my laptop go into thermal shutdown from the OS not being able to manage the power features of my motherboard. Wiped the partition and moved back to my Vista install.

Linux is great to tinker with, but I’ll be damned if I can get it working. It’s the opposite problem to Windows; while Windows supports the latest hardware instead of older legacy hardware, Linux will only give a semi-satisfactory experience when installed on ancient machines. Nuts to it - Windows may be confounding to many luddites, but I’ll be damned if it isn’t simple when compared to the alternatives. I shudder to think what would happen if I gave a Ubuntu PC to a non-techie relative.

Ubuntu, and Linux, is to be kept soley as a live CD for use on my other machines, when testing out my USB deivces. While it may fail to work as a normal OS for me, at least on old machines it provides more debugging information about faulty hardware than Windows.

Bah humbug.

Wordpress is updated, and nothing’s blown up. Whee!

This evening I did something I haven’t done for quite a while, which might come as a shock to some egotists: I searched for references to myself and my past/present projects through Google. It’s quite an interesting trip down memory lane seeing how my contributions (I use that term very loosly) have spread out all over the web. More interesting is some of the more recent entries.

I am outraged to find that a guy has transformed my beautiful Simple Simon code into an abomination. It’s been ported for PICs. Good lord, strap on your helmets, because this world is going to hell in a handbasket. The Simple Simon code I wrote was actually very basic, and served to teach myself PWM and state machines — you can see the original, non PIC (bleah!) source here.

No no, I jest. I’m actually rather flattered that someone thought such simple code with such a simple purpose was worth porting to anything, and I’m a little saddend that there are no real-life pictures of the guy’s quite nice design, only drawings.

Also in my travells I found this blog entry, written by a guy experimenting with his own home-brew AVR USB boards and my LUFA (formerly MyUSB) library. According to that poor deluded fellow I’m a hero - a title shared with Smokey/Smileymicros/Joe Pardue at AVRFreaks - which is heartwarming to hear, if obviously untrue. Still, neat, and I enjoyed the semi-heart-attack I recieved from seeing delicate microcontrollers running from a breadboard sitting in a nice static-friendly plastic box.

It’s nice to see my name on the avr-libc contributors list, even for such small patches.  A while back I wrote the new ISR and Atomic block header files for avr-libc, which have been in the last few distributions. I actually think I made a mistake by making the new ISR macro backwards compatible with the old — if you haven’t seen the new functionality the extended macro offers, you really should read the header file’s documentation in the manual. Oh, and read the atomic block documentation as well, as it provides an ellegant solution to the age-long problem of atomic access.

Finally, on an unrelated topic - LUFA (formerly MyUSB) is now in Release Candidate stage - you’ve got a whole two days to alert me to any showstoppers before the next release. Essentially the code changes for the next release have been mostly wrapped up for a while, but the release has been delayed by me wanting to finish documenting each individual demo. Nuts to that I say, as the new changes are worth getting out there now, so I’ll be releasing the next version (now versioned by release date, rather than an arbitrarily increasing number) in the next few days with all the projects and demos documented, but only the device mode demos (minus the RNDIS demo) documented.

Don’t delay - grab a copy of the new version’s RC and get testing!

Cue my first heartattack of the Christmas season — University results came out today, unbenownst to me. Nothing like having a cold, feeling like death incarnate and having someone at 1AM tell you to check your emails to get the blood pumping.
Well, I’ve passed second semester in all subjects. I’ve got atrocious results in analogue electronics (brutal exam), Physics (brutally bad lecturer) and Maths (I’m dumb). On the lighter side, I’m still getting fantastic results in the computer science and digital electronics portions of the course however - so there’s still hope yet. My worst fear - repeating calculus for a third time - has passed with me scraping by, so no great derailment to next year’s course structure like this year.

I’ve got to admit that I’ve really not fallen in love with the analogue side of electronics. I do like simple analogue circuits but complex feedback systems and the like bore me to death, and I’ve found that I don’t have the mindset nor the interest in them. Thankfully, course units from next year on will start to focus more on the digital and computer science portions, which equate to my version of nerd heaven.

So all in all, not the best results, but enough to get me into next year and into the subjects I enjoy rather than the subjects I’m forced to take. No more physics (heaven!) for me, just TCP/IP, Java, C++, Digital Design, and a whole host of other awesome subjects.

Yesterday, I bought a new external drive for my laptop. This one’s a full desktop-sized driver in an external case rather than a laptop “portable” external drive like my existing external. Both coincidentally happen to be Maxtor Onetouch products, however in the external market not much matters other than the quality of the drive inside. Having a new 750GB external for my media is a great thing; it frees up the 120GB mini external for backups, and my laptop’s internal 120GB for programs.

There’s only one problem; 750GB it ‘aint.

As anyone in computer science knows, 1GB is 1024MB. This is due to everything being specified in powers of 2 rather than 10, as computers use a binary two-state storage mechanism. However, in the storage market, the more literal interpretation of the “Giga” prefix yields 1GB = 1000MB. While technically accurate due to the use of the SI prefix “Giga”, it goes against all of Computer Science and digital history, and is used for only one reason: money. By shaving a few megabytes off each gigabyte in the true capacity, the drive can be marketed as something it isn’t — for example, my new 750GB (from the box) appears to the OS as a 698GB disk, a loss of 52GB, or 7% of the stated capacity.

The situation is so bad, a new set of prefixes have been standardised to reduce confusion - enter the Gibibyte (GiB), Mibibyte (MiB) and Kibibyte (KiB). Each of these are the binary power-of-two honest-to-god real Computer Science definitions of the respective data sizes. Despite this, these prefixes are rarely used outside of the Linux and *nix realms, and thus OSes such as Windows still use the common Gigabyte, Megabyte and Kilobyte distinctions in the power-of-two sense, rather than the power-of-ten sense.

That means that the only people who insist on using the 1000MB = 1GB definition are the storage manufacturers, who have a definite advantage to doing so, since it allows them to sell products with less capacity than expected. In fact, the Seagate (owner of the Maxtor brand used on my new drive) has this to say about the subject:

Once upon a time, computer professionals noticed that 1024 or 2¹⁰ (binary) was very nearly equal to 1000 or 10³ (decimal) and started using the prefix “kilo” to mean 1024. That worked well enough for a decade or two because everybody who talked kilobytes knew that the term implied 1024 bytes. But almost overnight a much more numerous “everybody” bought computers, and the trade computer professionals needed to talk to physicists and engineers and even to ordinary people, most of whom know that a kilometre is 1000 metres and a kilogram is 1000 grams.

What utter tripe. Everyone excluding storage manufacturers use the power-of-two system, thus I say the manufacturers are breaking user expectations by representing their capacities in the “incorrect” base system. If a user sees 750GB on the box, he or she expects the computer to recognise it as 750GB, regardless of the base system. Storage manufacturers should give their capacities in the same manner as the OS, to reduce confusion. The fact that the above article is even in the Seagate knowedge-base to begin with is ample proof of this. Users don’t care how many MB are in a GB, just so long as what’s on the box is what’s shown in the OS.

I wonder what Seagate’s response will be if I ask for 7% of my money back, to cover the discrepancy.

I’ve not been completely idle these past few days, despite “being on holidays” from University until next semester starts in 2009. On Monday and Tuesday, my friends and I undertook some work from my microprocessors lecturer to design and build some low-cost educational robots for use in schools to get young students interested in the world of electronics.

We ended up with two prototypes, a submarine built by myself and my friend Luke, and a obstacle avoidance robot built by my friends Alan and Jim. Both are made from cheap components (PVC tubing, foam, film canisters, hobby motors, etc.) and are specifically designed to be educational rather than amazing feats of engineering. The submarine shown here uses three hobby motors mounted in film canisters and sealed with electrical tape, petroleum jelly and blue-tack for propulsion and dive/surface control:

Pictured without the right propellor, as we only had two at the time, and were testing the third (dive/surface) motor when the photo was taken.

The second model to come out of what can only be described as a Mythbuster’s lab was the avoidance robot, pictured below. Built using a CD as a base with small Perspex wheels lined with rubber bands for traction, it ended up working reasonably well, for a design with zero components other than batteries, micro switches and motors. Of course, I was itching to put in an ATTINY to make it somewhat intelligent, but alas that was out of the project’s complete-beginner scope.

Aside from the above, I’ve also been busy working on some more contract work over at the local Alfred hospital, continuing my work on a blood barcoding project which is progressing slowly but surely. In my downtime at night, I’ve been working on my Ray Tracer I blogged about previously, to improve its capabilities somewhat. I’ve managed to accomplish the following in the last week:

• Fixed shadowing - was accidentally taking the compliment of the shadow factor
• Fixed horrible hack for preventing secondary rays from returning a collision with the stating object - a better (and common) hack of moving the start point slightly in the ray’s direction fixes “invisible starting object” problems I was having when calculating shadows
• Added Max U/V values to the TexImage image texture object, so that the texture image can be tiled any number of times across an object
• Added correct Phong shading, moving the ambient light to a constant rather than a lighting object for speed, including correct diffusion and specular lighting
• Added in translucency support for transparent or semi-transparent objects
• Added in spot and flood lights in addition to the existing omni light lighting object
• Added refractions and corrected reflection mixing routine to give better results

The results of which are much better than the previous code’s output (click to enlarge):

EDIT: Added photo of avoidance robot - thanks Jim!

Next week I’ll be attending my final two exams for the year, first DDP (Digital Design and Programming — essentially, a beginner’s course to the VHDL language on CPLD chips) on Monday, then ALG (Algorithms) on Thursday. Neither are particularly difficult in the brains department, but both require a lot of memorizing. While I fully understand all the algorithms covered, I do think it’s a bit much to make students remember every possible case for every covered algorithm for repitition on demand — Red-Black Trees alone have a good five seperate cases for insertion. I’ve always been cursed with a poor memory, so I’m possibly doomed on that alone.

On a brighter note, Gary sent me a link to his own blog, detailing some of his AVR exploits, the most recent of which is MyUSB related. It’s always gratifying to see my work being used by both commercial and hobbyists - the latter was a great consern in the design of the library, since commercial outfits would use a bad library warts-and-all if no alternative was avaliable. It’s fantastic to see that people are using it for their personal projects, proving to me that it is at least somewhat accessible to the normal AVR folk out there.

During the course of our exam study the other day, myself and my techno-geek friends got to discussing absurd communication mediums. Honestly — the lot of us looked almost identical to the characters in the awesome show “The Big Bang Theory”, with a tablet PC connected to our TV, and iPhones and laptops flying every which way. That’s neither here nor there however, as the discussion moved from the mundane (TCP/IP over LEDs) to the outrageous (TCP/IP over SMS). This was my suggestion; correctly coupled with a free online SMS service, it would be theoretically possible to write a proxy which sent out TCP/IP packets over 150 byte long SMS messages.

I don’t think SMS supports much other than the basic latin alphabet, so that means that packets would be base-64 encoded. A typical TCP/IP data packet (as opposed to a non-data containing signalling packet such as an ACK, SYN or FIN) header is around 50 bytes, so there would be sufficient space for a tenth of a kilobyte or so of data to be transmitted per message. I can’t imaging the phone company being to happy about the torrents of messages it would produce, but the TCP layer would ensure data integrity on the recieving end (even for out-of-order packets) and would probably out-strip GPRS anyway ;).

I really should spend more time studying.

This afternoon I tried my hand at building an AVROpendous board from the kit sent to me by the very generous Matt from the company of the same name. The “kit” contained the bare silkscreened PCB, plus all the components I needed to build it up - essentially, it’s the same finished board that everyone else can buy, except the parts came in a bag rather than attached to the board :).

Before today, I’ve only tried surface mount soldering once, on a half-dozen resistors needed for a microcontroller development board last semester (MSP430, containing a TI based microcontroller) in a reasonably large SM size.

This was certainly a learning experience. I got out my magnifying glass, my soldering iron, fine pitch solder, tweezers, solder wick and my components, and set to work. My verdict; SM soldering is fun, but at times quite frustrating. Sneezing and literally losing a component isn’t fun, so it was a good thing I had extras of many of the components. While I don’t know what the exact packge is for the components on the AVROpendous board, I do know that they’re DAMN TINY with the resistors measuring about 1mm lengthwise. It’s a good thing I had a quick lesson with my microprocessors lecturer before I started.

After making a reasonable mess of it but enjoying myself thoroughly, I had a finished board. While I ended up with far too much solder on most of the components, the end result wasn’t too shabby, for a first timer. Holding my breath, I plugged it in, and promptly got nothing.

Ever the optimist, I started running some tests. Stupidly I put in a LED directly to the 3.3V external rails to confirm the board was getting power, which it turned out it wasn’t. Bridging the external VCC to the VBUS line of the micro-USB connector finally resulted in a lit LED, and - what’s that?! - a working board.

Once I verified that bridging the supply worked, I went to grab the LED from the rails to put it away (its purpose as a quick go/no-go tester complete) and ended up almost succeeding in welding the plastic to my finger. Lesson to the wise; 5V + LED + Timer + 200mA supply + Finger != a happy Dean. Nevertheless, I poured over the schematic once more.

I found a likely source of the problem; the only point the board and VBUS meet is via L3, a small ferrite bead inductor. Knowing that a single point of failure usually means that it is the reason for a given failure, I bridged the inductor (this is safe, the inductor is for noise suppression purposes) and head Windows happily enumerate my board.

Once I re-soldered L3, the board was up and running sans a working power LED. That turned out to be a case of reverse polarity, a silly mistake which I do not feel at all silly about, since I haven’t a clue how to tell the polarity of a surface mount LED. As far as I can see, the darn thing’s completely symmetrical, which meant that good ol’ Moore caused me to mount it backwards.

That fixed, I now have my first working surface mount board, and a new addition to my AVROpendous family!

And so ends another enlightening experience. I think I’ll grovel to my lecturer solder the MEGA2561 onto the board John so kindly sent me (more on that in a later post) however, as I really don’t want to kill such an expensive chip.

Sometimes I wish there was a working “unsubscribe” link for life. People are just too damn difficult.

On a more positive note, it looks like the complaints I made about the current Windows SideShow implementation are actually resulting in some changes for the better. A Microsoft employee has stated that there are some new changes to the SideShow platform being unveiled at the WINHEC 2008 conference (damn my age and location!) which will make the platform much easier to implement on small embedded microcontrollers. With any luck, this means that consumers will start seeing new (low capability) SideShow devices popping up in six months or so with some useful functionality. Up until now, the platform has really been geared towards high-end microprocessors (such as the ARM series), making implementations difficult for RAM-sparse tiny 8-bit microcontrollers such as the USB AVRs.

A few weeks ago I tried my hand at a SideShow implementation on the MyUSB stack, with mixed success. After a lot of playing around I managed to get my device to enumerate correctly and even recieve XML content from the host. Where I got stuck was twofold:

1) Writing an XML parser to parse the content into a compact form for storage and display is quite involved

2) The GetCapabilities request was essentially never used for its intended purpose by the host (determining the device capabilities such as content caching, screen type, display, etc.)

I do think SideShow is a fantastic idea, and I applaud Microsoft for doing some real innovation. Where it falls down is the current system expects the SideShow device to be fairly interactive — being able to display pictures, many lines of text, take user input, cache data, display many colours, etc. How I envision SideShow is a little different; I see a host being able to push data to all manner of items with different capabilities, small or large.

For example, I wanted to make my demo device take in a Media Player widget application, and display the current song information to a 16×2 alphanumeric display. That serves as something that users can build quite easily and get a feel for the USB stack and the SideShow framework. What I got was a host which expected the device to be able to handle multiple applications at a time, and be able to display complex menus. Ideally, the host should be able to fully query the device capabilities, then push data to the display in a format suitable for that device. If the device is severely limited (such as having no user input, like my proposed song title display) customization of the widget/application should be offered on the host so that the desired data can be streamed to the device.

I’m very intereted in how this will pan out and, for once, I’m optimistic that it won’t turn out to be a complete disaster.

I discovered something interesting yesterday while recieving a private surface mount soldering lesson at University; do not drink caffinated beverages beforehand. After drinking an energy drink in the morning to keep myself awake (getting up at 6:30AM is a killer!) I was probably unable to solder through hole components, so bad was my hand shaking. On a positive note, once I purchase some fine-pitch solder and some solderwick, I’ll be able to complete the AVROpendous kit sent to me by Matt. A few days ago Matt finished a beta version of some new firmware for his board, turning it into a USB AVRDude-compatible AVR programmer. Since the firmware is MyUSB based, it is also compatible with any other USB AVR based board, so it’s useful to everyone rather than just AVROpendous board owners.

Today someone posted an interesting question to the MyUSB discussion board, asking if I plan on writing a USB Printer class demo for the AVRs. The USB printer class is simular to the Mass Storage class, in that it is essentially just a wrapper for an already established standard printer protocol (Postscript, or a few other alternatives). To be honest, I can’t see anyone implementing a complete PostScript parser on a small AVR, so I don’t see a pressing need for such a demo.

However, that caused me to download the PostScript specification and take a look, out of curiosity. I’m astonished; while I knew that PostScript was a scripting language capable of describing printable documents in a standard and defined manner, I never realised the language was Turing Complete - able to be programmed like other regular Turing complete languages such as BASIC or C. Why hasn’t anyone taken this a step further? Someone needs to make a LOGO to PostScript tool, so that entered LOGO programs could be not only printed to paper — but actually executed on the printer! Previews could be done with the regular print preview dialogs in most applications.

I love the idea of a printer co-processor, no matter how slow it might be. I need to device a postscript document which prints out the digits of Pi as they are computed. The sky’s the limit!

Some days I think I’m going crazy. Now, how does one send raw PostScript to a printer? Must find out…