Memos From the Cube

Yet another MyUSB update. I’ve managed (after a lot of thinking, swearing and hours working last night) to seperate the descriptor definitions from the library, so that each application can manage its own descriptors. That’s a great improvement, as it now means that upgrading the MyUSB library really is just a drag-drop affair rather than having to mess with the configuration files.

The changes also means that less code is wasted if the device portion of the library is unused; no descriptors are linked in by default unless specified in the user application, and the GetDescriptor function is now a weak alias to a stub function (thus the user application can override it if needed to be able to return descriptors to the host for device operation).

That’s all neat, but it also makes my life a hell of a lot easier. Now that the library is seperate from the user application, I’m able to put in a Demos/ directory to house the TestApp and Mouse demo applications, which can both be built using the exact same MyUSB library code. No more maintenance nightmare trying to synchronize changes across the library versions used by the different demos!

I look forward to being able to include more demos in the future, now that it’s simple to keep them all updated. Hopefully Denver’s keyboard demo will be included soon.

There are now a few makefiles in the project. Each demo application has a makefile, and there’s a makefile which builds all the demos with a single “make all”. The helper apps also have a single makefile to rebuild them all, if the Java JDK is installed. I’ve also added another makefile in the root directory which can build all helper applications and all demos with a single command.

Well, I wish to officially proclaim that Compaq laptops are the shoddiest consumer items ever created.

I’ve owned two laptops in my life, both Compaqs. One was a second-hand Compaq Armada e500, which quite literally fell apart after a few months, only to be resurrected with a bit (well a LOT) of super glue and filing.

My second (and current) laptop is a Compare Presario M2000. Quite a nice laptop for the price, except it suffers from Compaq’s inability to produce anything that actually works past the warranty. Three months after the one year warranty expired, the screen developed a green vertical line in the rightmost third of the display. A few hours ago (and 20 months after the purchase date), a second red line has appeared. The laptop’s never traveled outside my house, and in both instances the faults occurred while the laptop was on and stationary on a desk.

When I can actually afford a replacement in a few years, I’ll be choosing another brand with a two year warranty, minimum.

After submitting my “atomic.h” header file (which dealt with the problem of atomic access blocks in a easy manner) to the avr-lib-c project about a year ago, It’s finally gone into the CVS repository. That gives me a nice warm feeling - I’ve now officially contributed to the project in some small way.

My new “interrupt.h” header file is also almost ready, pending any extra change requests. Having to make the header files for the project has reinforced my love for working solo on projects. The red tape to get a simple change into a public collaborative project is enormous; first any changes have to be discussed, then written, then documented, then reviewed, then any changes made before it is incorporated into the source mainline. It’s rather reminiscent of the “Vogons” and their over-the-top bureaucracy in Scott Adam’s “Hitchhiker’s Guide to the Galaxy” novel. Being the sole programmer for your own project gives you a lot of freedom to make the changes you want to make in a timely manner.

I’ve recently updated the MyUSB main source (again) as well as the Mouse Demo source to reflect the new advancements in the library. I’ve also solved the problem of being unable to easily determine which events are not hooked in the user application, by a quick Java application I wrote up this morning. That gives birth to a new “HelperApps” directory of MyUSB, which houses any Java applications I make to automate MyUSB library related tasks for building and for the end-user. Having to make a whole Java applet for a simple task is a little overkill, but is cross-platform, and gives a nice formatted list of the unhooked events by checking the MyUSB events header files, and the target application’s linker MAP file.

The helper application is yet to make it into the source on my site, while I fix up the bugs and get it suitable for general use.

SWATVAC week has now started, which is the week of holidays before my exams start. Next week I’ll be doing my exams proper, and I’m petrified.

UPDATE: My new Interrupt.h header file has now also made it into the CVS. Hurrah!

Tomorrow will be my final day at University for my first year of my EE/CS double degree, with only exams left to do. It’s quite scary - I still feel like I’ve only just walked through the doors!

Some more minor updates to the MyUSB library, with the code again updated on the project page. I’ve put off updating the mouse example while I stabilize the new changes, to avoid doing the same work twice. The latest update moves the user device routines from a seperate file in the MyUSB configuration folder out into their own hookable events. That’s quite neat - now if the events are unused, the user application can just not specify an event handler for them rather than having to compile and link files that contain empty functions. It also allows me to deprecate them in the future easily, which is also a huge plus.

With that configuration file gone, the only one left is the descriptors configuration files. That’s what I wanted - now updating the library should be as simple as pasting the old over the new, with only the descriptors file needing to be preserved. Much cleaner than having to retain (and update if the new library version has modified) a whole bunch of configuration files.

On the examples front, I should be able to release a keyboard example soon, thanks to the work of Denver Gingerich (barring licensing negotiations for the keyboard descriptor he’s used from a different USB project). Once the library has become stable I hope to work on quite a few examples for it, including a CDC example (virtual serial port) and possibly even an audio example if it’s possible with the hardware.

On a final note to those who are curious, the following is an image showing the bandwidth consumed by my site on the server since it was put online early this year:

The notable sections are numbered.

1) Site uploaded and made available to the public
2) Blog started and advertised on AVRFreaks
3) Initial DB101 Review
4) High Resolution DB101 Photos

Seems there are a lot of people out there interested in the new board!

As an update to my last entry; no, it didn’t work. Specifically, the SYS assignment worked just fine, but a small algorithmic bug in the Java assignment saw me loose the greater portion of the marks. Unfortunately my marker decided that the rest of the operation, although correct in the context of the algorithmic mistake, was not valid for marks, so I’ve managed to only scrape by in the execution test. Oh well, win some, loose some, at least I know what I’m doing and I’ll pass the Java exam with no trouble at all.

Now, back to MyUSB. After toying around with the new event system I was working on, I’ve incorporated it into the main code (on the MyUSB project page) and updated the wiki documentation accordingly. It’s very nice to work with now - all event hooks are done transparently through some GCC attribute magic, which also allows for old event names to be deprecated. The new system is a lot cleaner than the old configuration header file full of hook defines, and so will make updating a project’s MyUSB library code a lot easier in the future.

An interesting side effect is that the resulting binary code decreased slightly. I haven’t analyzed why this is the case, but I would have thought adding in function calls and returns rather than inline code would have bloated rather than reduced the code size. I can only speculate that the use of proper functions freed up enough registers or gave the compiler enough room to make some better compile optimizations. Whatever the reason may be, I’m one happy chappy, so to speak.

Another advancement was the addition of switches in the makefile to enable unused function garbage collecting (found in this thread) which may prove useful in the future, as well as linker relaxations (good discussion here). The latter is a great find - it causes the linked functions to use the smaller RCALL assembly opcode rather than the larger CALL opcode where possible when calling other functions. That alone resulted in fantastic code space savings.

I’m now into the second of my five last days at University this year. Amazing - it’s been a whole year already! I really feel like I’ve only just started at this place, so it’s scary to know I’m one fifth the way to a career as an EE and CS engineer.

Both my Java and Systems (that’s C/C++) assignments have been handed in, the latter of which is due for an execution test this afternoon to validate that it does in fact do what it is supposed to do. I’ve personally no idea - the whole assignment’s been a real disaster from the start (with the lecturer posting the solutions instead of the template) and no one I’ve talked to has figured out what values to input into the given program formulas to test the output. I’ll be passing the assignment however, as the code’s good and all the tasks are done, even if the exact implementation may be a little wonky.

I’m actually rather enjoying playing the role of a teaching assistant. I’ve found no issues this year in the programming side of the course, and I’ve picked up both Java and C++ very quickly. Having people I’ve never met come up and ask me a question, and then being able to answer the question thoroughly and with the use of diagrams on a whiteboard and marker gives quite a bit of personal satisfaction. I’ve struggled with the Physics and Maths side of things this year, which is an area outside my experience, so being regareded as the come-to guy for something is a nice change. Eventually I expect to get an actual TA job at my Uni in my third or fourth years, helping out the first years in the programming labs.

Next week SWATVAC starts, which is the study break before exams. I’ve got a lot of things to study! When it’s all over I’ll be finishing off MyUSB, as I thoroughly miss working with AVRs.

Speaking of MyUSB, from the recent discussions on AVRFreaks about discarding unused functions at the linking stage, I think I might have a way of re-implementing the USB event hook system to a similar way that the ISR system works in GCC. By using the weak attribute I can create overrideable functions, something I’ve experimented with before. However I’ve had the problem of the overridden library functions still making their way into the resulting binary, even if they’re unused. But by using a few strategic GCC command line arguments I might be able to force the linker to discard the unused functions, eliminating the code cost.

Such an implementation would require the extra command line arguments to be documented, as the rest of the implementation is now in the wiki. The implementation would be along the lines of the following:

MYUSB_EVENT(USB_Connected)
{
// Event code here
}

Rather than the existing method of changing the hook #define lines in the config directory. I think this is a better idea - anyone else care to comment?

Sorry folks, nothing new to report.

That’s not to say I haven’t been busy - quite the contrary. I’ve been working from 8AM-11PM for the last week, trying to finish all my university programming assignments. They’re still not done, with my second (and last) one still unfinished with only a few days left until the deadline. It’s for this reason I’ve been neglecting posting here, as well as being less active on AVRFreaks than usual. By next week I should be back to my normal workload, and into exam revision.

Some exciting news about someone else’s efforts however - Martin Thomas, of AVRFreaks, has ported the DB101 application code over to the GCC compiler. It’s available for download from his website, here.

Looking forward to keeping sane hours again. That’s all (for now) folks!

Well, still not much to report over the last few days. I’ve just started my end-of-year Java and CSE1SYS (that’s C++) assignments, which are due in the next two weeks.

I’ve uploaded the last version of my Space AI “game”. It was a fun learning experience, but now I’m ready to move on to another project - perhaps even a proper 2-player clone of the old-but-gold Star Control 2 one-on-one action.

I’ve also uploaded a slightly tweaked version of my JRender (simple Java 3D software renderer), which I converted over to a normal JFrame application rather than an applet. Now model files can be opened by running the Engine program from the command line, rather than having to re-compile as was done previously. Having the code as a normal java application also has the added benefit of not requiring the JDK AppletViewer program to run it.

Exams will commence in only a few short weeks, and I’m currently scrambling to get everything done in time. As can be noted over the past few weeks my play-time is almost non-existent, so to those waiting for me to hurry up and finish MyUSB already (I’m sure there’s SOMEONE out there!) please accept my apologies and hang on a few more weeks. With the end of the University semester I’ll have a full three months minimum to fully devote to AVRs, Java and comp/elec. systems in general. Yee haw!

Today marks the day that my production version DB101 display board arrived at my house. Oh joy of joys!

Unfortunately it’s a short-lived euphoria, as I can’t play with it at the moment. I’m now nearing the end of my first year at University, and final exams aren’t top far off - only three or four weeks. That’s accompanied by quite a lot of work to get done, and not a whole lot of time to do it in.

However, I managed to get a few very quick photos and (short) videos showing off the production version board, including the very cool RGB backlight.

As the accompanying note from the kind Atmel engineer who sent it says, to enable the backlight functionality of the board an external VCC of at least 3.5V needs to be supplied. Voltages below that critical threshold will still work fine with the board, but all backlight functionality will be hidden and disabled.

Connecting the board up to the Target VCC lines of my STK500 shows that that backlight has some real power! The screen’s quite readable even in low light levels, but the backlight allows for full readability in total darkness as expected. What I didn’t expect was just how cool a RGB backlight looks!

Other than the above, the final board looks pretty much unchanged, and identical to the previously photographed board. It’s nice to hear that it’ll be avaliable as soon as next week for ordering through Atmel distributors, so get your credit cards ready! The new Atmel DB101 is expected to retail at US$79.

The new photos and videos are available for viewing and downloading here.

Since quite a lot of people are finding this site due to my blog post about my HL-340 USB to Serial adapter - presumably looking for the driver - I’m going to be a good Samaritan and upload it for public download. Get your HL-340 driver here! I have nothing to do with the adator or the drivers, so please don’t email me hoping I’ll be able to provide technical support; chances are I’m as totally clueless as you are.

I’ve also uploaded the latest source code to my Java Space “game”, which is available from the new site page here. I’ve been heavily reworking the backend code, which now uses a slower, but MUCH nicer ArrayList to store the game objects. I’ve been opting for ease of use over speed for the latest revisions - battles shouldn’t be more than one or two thousand ships at the extreme, and the simplified vector routines and ArrayLists make for a much more accessible and pleasant coding experience.

I’m still modifying the game code, and adding new features. New is a function to turn on or off gravity effects for bullets - so you can code some dastardly AIs that can “throw curve balls” using nearby planets.