Memos From the Cube

Well, I’ve had some amount of success with MyUSB - I’ve managed to get the endpoint (that’s the layer which manages data transfer between the devices) configuration code written, and I can successfully create the control endpoint required to enumerate a device. I’ve also managed to get a VTARGET signal — but only after strangely enabling the OTG pad, just like in Atmel’s driver.

I’ve given up for the most part using Atmel’s driver as a reference, and am only using to compare drivers (checking the enabled and disabled register bits in AVRStudio and investigating the differences with the Datasheet). There seems to be at least a handful of macros that aren’t just faulty, they actually control registers and bits that don’t exist. The datasheet is most decidedly preliminary also, as it frequently mentions a register or bit once in a paragraph body, then never again. I’ve been emailing Atmel’s tech support in order to get clarification on what bits do and do not in fact exist on the finished USB AVR chip.

So far the demonstration application that comes with MyUSB is boring. When started it creates a psudo-task (MyUSB uses my own basic round-robbin scheduler which can start/stop/delay tasks and not much more) which looks at the joystick. When the joystick position changes, these changes are reflected on the two bi-colour LEDs as a demo of the MyUSB Joystick and LED drivers.

A second task is also created, which monitors the HWB (hardware button) on the USBKEY board. When pressed it disables the above task as well as itself while starting the USB interface and enabling a third task, which monitors the VBUS. This third task alternately flashes the bi-color LEDs when the VBUS signal is detected.

Next thing to do is to look into what I have to do to enumerate the device properly now that I can initialize the USB interface and configure the endpoints.

I really hope someone will find a use for this - it’s a fun project to work on, but the most satisfaction comes from knowing that others appreciate your labours. It’ll be open source when completed, but with the hope/request of donations from users so I can afford new toys :).

Well, I could have guessed right from the start, but my new USB-Serial cable doesn’t work. It has some life in it, identifying as a “USB SERI” device - but the driver doesn’t seem to be included on the awful mess they call a driver CD. The most annoying part is that it’s almost certainly just a standard Prolific or FTDI chip that’s been reprogrammed to identify as a proprietary adapter, and so won’t work with the standard drivers from the chip manafacturer’s website. Raaawr!

Honestly, I’m fed up with cheap Chinese electronics. Years ago I liked being able to purchase things for cheap, even if the end-result was a slightly less than perfect device. Nowadays purchasing anything from China is an invitation to a 9th rate product with no English manual and only a 2% chance of success. I’ve been sticking to decent products for a little while now and only broke down on this one because I didn’t want to pay $40 for what is $2 worth of chips, a socket and some cable. I think I’ll end up just converting one of the (working) SmileyMicros USB-BB adaptors which work perfectly well, but are unsuitable for a few of my applications due to having 0/5V logic rather than RS232 levels.

I’ve contacted the eBay seller with the naiive hope of actually getting some assistance.

Update: Well, I tried. Seems it’s Prolific-chip based like my last one, except with different custom IDs. I tried hacking the XP install driver to use the cable’s VID and device ID, but just like the last one the driver fails to install, with windows giving the very helpful “System can’t find the file specified” error message. May Prolific burn in the very fires of hell for their ridiculously defective products.

Update #2: Jigger me timbers! I asked some of the seller’s other customers who bought the cable about the XP driver. One was very helpful, and directed me to the correct driver. Seems it’s not a prolific based chip at all (like my last ones) - it’s a HL-340 model converter with it’s own driver. I can’t believe it’s actually working! No more running between rooms to test out my firmware anymore ;).

A lot of people have discovered and enjoyed my tutorials I write occasionally over at AVRFreaks (see a list here), if the comments on the threads are to be believed. I rather enjoy sharing knowledge and writing tutorials, as anyone can see if they read my posts enough. Be sure to check them all out!

I hope that my writings over at ‘Freaks help, but also inspire others to do the same. I do see a few others writing one or two short pieces, but if the bulk of the community chipped in, we’d have a great resource and a much easier workload (being able to eliminate the frequently asked questions by providing answers in the tutorials/articles).

Well, I’m back from my weekend and apart from some horrible sickness in my stomach I’m all in one piece.

I fear I’m beginning to turn into my worst fear - an eBay Addict. You know the type. I’ve already lost my brother to the eBay beast, although granted it wasn’t too much of a loss!

After purchasing some parts I needed for the Commercial project I’m working on last week, I spent a couple of hours looking for other things worth purchasing. I finally settled on gambling on another USB-Serial converter (I’ve tried many in the past, none worked) and on an impulse, this little gizmo, an old external serial trackpad. I’m planning on trying to reverse-engineer it’s communications so I can interface it with my AVR projects.

Help me!

No posts over the weekends as a general rule; due to “social commitments” I’m out of the house and unable to either work on any projects.

Still working very slowly to get the MyUSB library working. It’s a very tall order I’ve come to realize; even with an AVR with a dedicated USB controller, the method of establishing proper USB communications is a long and complicated one. I understand the top-level theory I believe, I just need to go over the documentation and Atmel’s driver (yes, I’ve caved somewhat on that point, however I’ve come to realise it’s about the only way it’ll get written) and knuckle down.

Atmel’s driver isn’t too bad, it’s just too complicated for my liking - designed for many different modes and many different compilers. I like being able to write things myself, as I gain understanding in its workings and control over its structure. So what if the end-result is near-identical to Atmel’s - it’s the process and knowedge gained that counts!

I’ve made more scheduler adjustments, expanding the tick counter to 16-bits and fixing up the delay logic. Now with a timer increasing the tick counter every 1mS, I can have two tasks running in the demo app; one showing the status of the joystick/HWB of the USBKey on the bi-colour LEDs, and another monitoring the VBUS. Once proper USB communication is established (a long way away, sadly, as the VBUS register bit seems to only be set once the USB device is enumerated and connected to the host when acting as a device) the second monitoring task disables the first and starts alternativley flashing the bicolour LEDs red and green.

Actually, the scheduler’s been pretty fun to write despite its simplicity. Even with only basic run/stop control and delays, I can write “tasks” in the round-robbin that can start or stop other task(s) - the simple code allows for multiple tasks to shared IDs and thus be controlled as a group - as well as only execute after a fixed number of ticks, or stop executing after a fixed number of ticks. It’s looking more and more likely like I’ll start branching out and researching RTOS kernels so I can design and create my own.

Oh, and please comment if you find and entry interesting/boring. Once I have a feel for what people like to read about, I’ll try to write more entries in those categories.

Well, I couldn’t resist. Yesterday I was in the city meeting some special people in my life (parents and girlfriend, not in any particular order!) and ended up buying the cult sci-fi film Hackers. I can’t resist with these things; I admit, one of the first DVDs I bought was another old-school hacking film called WarGames. I have an addiction to cheesy old-school computer films!

The main reason I was in the city however, was to avoid being killed. Well, that’s an odd-way of looking at it, but It’s true. I’m about to start work on an existing commercial product, for The Information Display company. I’ve done a small amount of work for them in the past, but this time it’s a little more interesting, and involves me having to have a copy of the hardware.

A problem with the hardware I had, was that I didn’t have any power supplies to suit the main board, nor the Palm PDA that came with it. The Palm charger was easy; quick trip to eBay for a charger and a US-to-AU power adapter and I was in business. The problem was the main board - I didn’t have a suitable adapter.

The system requires a nice regulated 12V 1A input, which is buffered somewhat by a rather large capacitor on the main line (see pic). This capacitor is a 4.7mF, 16V type, and so the margin for error isn’t very high: 11.5V minimum, and about 13V maximum to avoid blowing the main cap (and possibly killing myself directly from the flying contents, or indirectly when my mother saw the state of my walls and desk). It’s actually rather hard to find a decent electronics shop around here these days, so I had to find one in the city.

Now it’s all plugged in, and I’m in business. Can’t wait to work some more on this project. This is what embedded systems is all about - making flashing LED gizmos are fun, but the real satisfaction comes from making something that impacts the lives of a lot of people. Alas, my friends jokingly hate me now for my efforts in saving more American lives!

I’ve actually had quite a lot of fun with the Palm outside the project (don’t tell my employer!). After a bit of fiddling with a Palm port of the SCUMMVM engine, I’ve put a couple of my old Point-and-Click adventure games on it for some serious mobile gaming. Nothing like playing Monkey Island or Day of the Tentacle when you’re sitting on the train to the city!

Although making it comes close! I’ve been doing a few minor jobs for a new (to me) company this past week, and it’s been quite fun — nice to be actually earning rather than spending for once. I’m currently on my end-of-semester break from University, which has given me plenty of time to pursue work and have fun from a change free of stress.

ButtLoad continues to roll out, with around 80 downloads. I’ve always wondered just how many people in the world are using it; it’s a delicious feeling to know that somewhere in the world someone completely unrelated, and who I may never meet, has been impacted by my work in some way. An even better feeling is the lack of any complaints so far, so I hope that means the code’s working for the majority.

Have been working on MyUSB. The USB protocol/interface is really interesting, although I’m yet to really scratch the surface. I’ve got a test application set up, displaying the position of the joystick onto the two USBKEY bicolour LEDs - all via the MyUSB library, of course - while looking for a successful USB device enumeration via a seperate task. I just hope my efforts pay off and I get a twin green LED indication (USB connect successful) in the next little while…

I’ve updated the MyUSB download on my site, although the version is staying at 0.0 until some real developments occur. The USB code is essentially non-existent at the moment, but downloading it will at least give an idea of the library, and the other drivers are working and documented.

Like the original Atmel driver, I’ve written my own “scheduler” for the library, to make coding easier. It’s really just a round-robbin loop, but with a few small twists. The scheduler keeps track of elapsed delays via a a tick counter (which is incremented in the test application every mS) which can then be used to delay the execution of tasks for a certain duration via the Scheduler API. Tasks can also be disabled and enabled on the fly, which makes it slightly more versatile. I’ve got no plans to make a proper RTOS at the moment, although it may be possible for the future as it’s a rather interesting project.

My my, what a quick uptake of ButtLoad 3.0! Fifty downloads in twenty four hours is not too bad for a relatively obscure project.

Now, onto my new project, Codename MyUSB - so named because I haven’t thought up a decent name for it yet. If you have any ideas, please leave a comment for this post.

MyUSB is my own library for USB communications using the AT90USB1287 AVR microcontroller - the AVR with an on-chip USB controller for device, host and OTG functionalities (see USB.org for more information about these modes). I’ve recently got a nice present from Atmel, a new AT90USBKEY board, which is based on this processor. I can’t make head nor tails of the library code that comes with it — it’s all over the place and hard to work out what connects to what.

In true re-inventing the wheel style, I’m writing my own replacement. Best way to learn is to do it yourself! That’s where MyUSB comes in, as it (will) contain my own USB driver and implementation. I’m trying not to refer to the Atmel drivers where possible, to both make the project more interesting, and allow me to rightfully claim this as my own work. When it’s done it will be released under some sort of generous open source license (possibly GPL) or another.

MyUSB also includes drivers for the USB1287’s hardware functionality (ADC, and more in the future) plus drivers for the peripherals included on the USBKEY board. I’m including decent documentation with the library, to allow for easy use in user projects.

I’ve already released the current MyUSB library to my site, although it’s just a preview of things to come. I’ve done a few of the drivers and am working on the USB code now. Remember to keep checking the MyUSB page in future for updates!

Well, ButtLoad 3.0’s finally out the door. It’s been a heck of a long ride for this project, and it’s certainly helped develop my coding, troubleshooting and design skills. I’m quite amazed that people all over the world use ButtLoad on a regular basis!

ButtLoad 3.0 took a very long time to finish, partly due to the major changes but also due to apathy and frustration at being unable to debug the thing. User’s can’t possibly fathom the amount of hair and sanity I’ve lost over the past few months getting the thing in a working and publishable state. The new non-consecutive HEX file support is actually the second generation, with the first being the reason for the delay; my original implementation was fast and clever, but too clever for me to debug it. What was that old quote again? Ah yes:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” – Brian W. Kernighan

How true, especially in the embedded world where clever code is required to fit in with the minimal resources avaliable.

In any case, it’s now done and ready for public consumption. Please do notify me of any bugs you find - which there will undoubtedly be plenty! - in the AVRFreaks thread about the project.

ButtLoad’s now pretty close to what I had in mind when I first started the project, thus I feel comfortable with stopping its development for the moment (save for bug-fixes) while I pursue other projects.

Well, I’ve decided to take the plunge into the world of blogging, at least as an experiment for a while. Quite possibly this will be abandoned to the wilds of the Internet in only a few short days, possibly longer. Or possibly, just perhaps, I’ll continue to maintain this for an extended time.

I won’t be posting here every day, I shall spare users the drudgeries of reading the ramblings of yet another soul’s life in this world. In here I’ll mainly post about my University course, my personal projects (and their development) and the like - things that interest me, but will also interest fellow technology/electronics minded geeks.

Let’s see how this pans out.