Memos From the Cube

Writing a USB host is hard, a real pain in the proverbial. The device code seems to work pretty well however, so MyUSB should be suitable for device implementations.

My Uni friend Alan has been showing me his 3D work he’s written in Flash - code capable of rendering 3D shapes and objects from a file in a simple manner - and I’ve been trying to work on my own implementation in Java. Of course, Java is poorly suited to graphics work, but you use what you have at hand! Actually, the OO nature of Java is quite handy for building a nice 3D framework, with the downside that the result is horribly slow. Still, as an academic exercise it’s fun to code in the free hours at University.

Once I get the Z-painting algorithm and back-facing triangle elimination code working, I’ll probably post the results as a mini-project on my site, for curiosity’s sake.

A few minutes ago, I managed to get a working USB Mouse out of my MyUSB library - it’s now available for download on the MyUSB page of my website. It’s only a proof-of-concept of the library but works just as well as the Atmel demonstration - but cleaner.

The MyUSB library currently ships with a test application, which shows off some of the library aspects. When powered, moving or pressing the joystick will cause the Bicolour LEDs to change state to reflect the new joystick position. Pressing the HWB for a short period starts and stops the USB interface, which in the library demo just enumerates as a “MyUSB Demo” device with no functionality.

The USB Mouse application works in an identical manner, except when activated the USB interface will enumerate as a standard USB mouse device called “MyUSB Mouse Demo”.

Now that the device portion of the project is just about done, it’s time to move on to the Host code.

Well, I’m at the end of a day of both good and bad.

Semester 2 of University started today, with little fanfare. It’s really surprising how quickly one gets back into the rhythm of school after a whole month off relaxing at home - it’s as if I never left.

As a downer, my laptop’s screen’s gone wonky, about 4 months over the 1 year warranty it came with. It’s now got a nice green vertical line running down the right-hand side, which makes working on it damn annoying.

Lifting my spirits is the climactic ending to the Harry Potter series, the final book of which I’ve almost finished. All my projects have been on hold for the last day while I finish it off - speed is the key so I can avoid the myriad of spoilers all over the ‘net!

Well, I’ve finally conjured the Wizard. The “Add new Hardware” Wizard, to be precise.

After a lot of trial and error, and not a few sacrifices to the USB gods, I’ve managed to get MyUSB to enumerate successfully as a USB device, with descriptors I set. Now when it’s plugged in it enumerates as “MyUSB DEMO” - very cool!

That’s not to say the device portion is finished yet. I still need to complete the handling of the basic Chapter 9 commands, as it’s currently missing a few. Unhandled commands are now passed to the user application through an event - see the “Event Hooks” section of the MyUSB USB Interface page on the site Wiki.

Once the Chapter 9 commands are finished, I’ll make a second TestApp which should perform the same/similar to the Atmel mouse demo. When that all works I’ll consider the device portion complete and begin work on the host portion of the MyUSB library.

I just downloaded my semester 2 timetable, and boy it’s a doozy! Looks like I’ll be attending every day still, however it’ll now be about 9-5 each day like a normal job (with the notable exception that I pay them to attend). With homework and the extra subject I won’t be having a great deal of time to work on my AVR projects, so looks like I’ll have to start making a portable toolchain so I can work during breaks at Uni.

I’ve finally got some Chapter 9 USB code in place, although only for a few commands and it’s very incomplete. I’m having real difficulties interpreting Atmel’s code - they seem to be twiddling the TXINI and RXOUTI bits a lot in the Chapter 9 commands as some sort of handshake. Needs further investigation.

I’m blessed in that the kind folks at Atmel donated a new JTAG-MKII to me for my moderation work at AVRFreaks.net a few months ago (as well as the USBKEY!) which I’m using to debug my code. Without a JTAG I’d still be on my first few lines — it’s absolutely indispensable for this sort of work. Any serious AVR engineer/hobbyist must have at least one - or a Dragon, if suitable - in their kit.

I’m out tomorrow, so no entry until Friday I’m afraid. Not that anyone’s actually reading any of this, however!

EDIT: Oh, and a postscript. To the person who found my blog via a search on Google for “jigger me timbers”, thank you. That made my day :).

I’m happy to announce more success from my MyUSB project, thanks to an extreamely helpful Raphael of the Atmel AVR support team. He was able to diagnose an endpoint issue I was having within minutes, and I’m now getting the correct control commands on the control endpoint!

The project now correctly starts the device USB mode of operation when the HWB is pressed - control data is received (and thrown away) and the system enters sleep mode after no activity for a period of time.

I’m excited by this - I can now move on to implementing the famous “Chapter 9″ of the USB specification to deal with the enumeration and negotiation of the USB device. That’s reasonably straight-forward, and is very similar to the V2Protocol Packet/AVRISP Command Interpreters I wrote for my ButtLoad project.

Once the chapter 9 stuff is in place, I should be able to make device endpoints and make my own USB mouse demonstration. After that’s completed, I’ll move on to the host/OTG operating modes.

Well, the Wiki is up and populated with the majority of the MyUSB project details. I’ve already had to make changes to the information available, and I already think it’s a great idea as a publicly viewable, easily editable information platform.

Today apart from doing a small amount of more commercial work for CC Communications, I worked hard on MyUSB. I’ve added in event hooks, which when configured can execute code in response to USB events (see the USB Interface documentation for the current list of available events). My original idea was to implement blank stub functions that had the GCC “weak” attribute, so they could be over-ridden transparently in the user-application. This worked great — but the weak stub function was included in the resulting binary.

A few wasted bytes isn’t too bad, but I thought I could do better. I then made the stub function inline, hoping the optimizer would remove the stub function entirely when a stronger function was substituted. This actually made things worse, with both inline and normal functions cluttering the binary.

I finally settled on a basic system using a control header file which defines the event names as either statements, code blocks or function names. Events that are unused get the value NO_EVENT_HOOK (an empty ASM statement) so that code such as:

if (SomeEvent)
USB_EVENT_SomeEventName();

Doesn’t cause problems by being empty.

I’ve had to contact Atmel support yet again, on the endpoints issue. I have many of the USB interrupts and events working great, however the control endpoint doesn’t seem to be recieving any control data. My JTAG shows why this is - the endpoint seems to be destroyed when the device is attached to the USB bus - but why that is is a mystery to me. I did find that I was accidentally setting a bit which was forcing the USB controller to run in Host mode, but changing that hasn’t fixed the problem.

Once the control endpoint is up and running, adding the control command interpreter should be easy - very similar to the V2Protocol work I did for my ButtLoad project.

I decided after a brainwave before to move the MyUSB documentation out of the clunky document I was manually formatting and restructuring into a new Wiki on my site. I’ve chosen a lightweight, basic Wiki that suits my needs (for now).

All the current documentation has been added for the MyUSB project, and I’ll begin documenting the current USB API tomorrow - although that will be changing very frequently as needed in the future. I think the Wiki’s a better way to get the information online sooner in an easily-editable form.

Check out the MyUSB entry - in the future I will most likely start adding in entries for past projects, adding project documentation, examples and the like.

Holy hell, I think my heart just shut down. I finally got back my first semester exam results!

Good news: I passed.

Bad news: I didn’t do so well.

Well, that’s not quite the whole truth - I did very well in two subjects, passable in one and god-awful in the last. I’ve heard of lots of horror stories about students failing the first semester due to the radically different learning environment change. I can attest to that first hand - the jump from High School to University has been one of the hardest things in my life. At university learning feels to abstracted; the lecturer plows ahead regardless of how much or little a student understands.

High School learning was easy - teacher stands up, interacts with the class and teaches subject matter at a rate that the majority can cope with. At university lectures are fast paced, with only minimal pauses

I’m going to have to really knuckle down next semester, and force myself to understand the subject matter. I’ve been coping fine with the electronics and Java subjects - it’s the maths (just plain bad understanding on my part) and physics (awful, useless lectures) that I have been having trouble with.

Without further ado, my results for better of for worse:

Actually, I am genuinely happy to see this one - it’s the Windows USB device error message:

Why am I happy about seeing this? Because it means I’m making progress. That error is now generated in response to enabling the MyUSB driver on my USBKEY board.

The error itself isn’t important just yet, as while the control endpoints for configuring the device are set up correctly, they aren’t used and so the device doesn’t do anything more than indicate that it’s attached to Windows. Later on when I get the control system working and provide some descriptors I should be able to get the driver to enumerate as any device I like.

I’m still using the original Atmel driver as a guide for how to structure the top-level of my driver. I’ve made some major changes to the last revision, with the VBUS notification now comming from the VBUS interrupt of the general USB interrupt vector.

The test app now runs as the joystick monitor on startup. Upon pressing the HWB, the USB interface is started as a device, and the joystick monitor is disabled. When in USB mode, the first Bicolor LED indicates if the USB interface is enabled (you can press HWB multiple times to start/stop the interface) while the second LED indicates the VBUS status. When waiting for the USB plug to be inserted, this LED is orange, and changes to green when the USB power is detected.

I’m investigating what I need to do for the control endpoint now - hopefully I’ll have some real, interesting progress done by the end of next week. I sure hope so - semester 2 of University begins on the 23rd which will severely limit my free time once again.

As an aside - yes, that time on the above screenshot is correct. I frequently stay up to odd hours on long holiday breaks. I can’t stop working on my AVR projects!