Memos From the Cube

Today marks some real progress with the Mass Storage code - it’s almost finished. With the latest code I can now format a 16MB flash disk, give it a name and drop very small files onto it (less than 64KB or so each). For some reason folders or any files larger than about 64KB aren’t reading (or writing) correctly, and have the data above the ~64KB mark all repeating garbage. I’ll have to look into that and try to suss out the source of the problem.

My previous problems with the formatting was down to a few mis-calculations in the MODE SENSE command, as well as a few bugs in the READ/WRITE command (one of which was a missing check for the endpoint recieved flag, resulting in writing and reading before the host was ready). Tests show that the host doesn’t seem to use the READ SENSE (10) command at all, so I’ve thrown all that code away in favor of just the MODE SENSE (6) command, which is definitely used and required.

With any luck the example will be finished by Friday, when I get my second semester University exam results.

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!

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.

Well, my adapters have arrived for my USBKEY. They’re so tiny - only seeing them “in the flesh” gives the full impact of just how tiny these things are.

Above is Tom’s photo of his USBKEY, with the adapters mounted. When I have some spare time I’ll be mounting them on my own board, which will make development considerably easier. Having access to a standard pin header for each port means easier interfacing with external devices, like the Trackpad I bought a few months ago (see earlier blog entries) and the as-yet unannounced new “toy” I received.

Actually, I can’t wait for the “toy” to be officially announced so I can blog about it, it really is quite neat. I’ll be writing some nice open source drivers for it in the future, that’s for sure!

I’ve managed to get a few Uni friends interested in my Space game framework, and we’re now all busy working on coding AI modules for it. Very hard, but forces some interesting new thinking patterns and coding styles.

On the projects side, two tid-bits of news worth noting. One, it seems that ButtLoad is incompatible with AVRDude’s signature check. That’s rather strange, as the signature check works fine in AVRStudio, but one of the forum members might have found a reason - the two programmers use different methods to determine the signature. Current analysis points to a bug in ButtLoad’s “SPI Multi” command handling, which is entirely possible due to me being unable to find any programming software that made use of it to test it out. Expect an update on this issue here in the future.

Second item of note is a small update on MyUSB. Development is still underway as always, if a little slow while I wrap my head around a few Host and USB related concepts. I’ve started to move around some of the device code and filenames, to make it consistent with the new Host code.

MyUSB needs a proper name about now, before it gets too embedded. If you can think of a more interesting (and unique) name for the project I’d love to hear from you.

Looks like .NET is a good candidate for extending my 3D work, although of course it’s still many, many orders of magnitude slower than using accelerated 3D hadware. Still, a quick port of my Java code over to VB.NET yields a much higher framerate for the same level of detail as the former, which opens the door for more techniques to be tried (like texturing). And that’s all without any significant optimizations to the .NET version of the code. I do like the increased simplicity of the .NET framework - it makes life a lot easier for me. Perhaps it’s time to truly retire from programming in aging VB6.

ZoomCityZoom (Tom) of Whizbangdesigns has announced on AVRFreaks his intentions to make breakout boards for the USBKEY’s tiny .5mm header pins. That’s good news for me, as it would allow me to connect up my peripherals without having to solder/desolder each time. I’ll hold off connecting up my Trackpad which I bought off eBay a few weeks ago until I have the breakouts soldered to the USBKey.

Well, for kicks I’ve started porting my Java code (which is up on my site now, by the way) over to VB.NET for kicks - and to see if I can get any speed increase out of it. Actually, I’m quite surprised just how much syntax Java and VB.NET have in common. I’ve never really got into the .NET revolution, with quick programs of mine still being knocked up (sorry, written) in aging VB6, so this is a good learning experience for me.

Another interesting point of similarity is Java’s AWT graphics library with that of .NET’s. I would assume the former was based on the latter with wrappers made for the other Java-supported systems, as the similarities are simply astounding for anyone who has worked with either.
I hope to get back into MyUSB this week and get a rudimentary host system up and running to compliment the currently working and almost finalized device mode.

Well, I’m knackered. To get to University each day by 9 I need to be up at 7, for which my tender body is taking its toll mightily. Still, soldier on!

I’ve just about hit the limits for my Java app. I’ve got my omnidirectional (and ambient) lighting working with intensities, drop-off values and colours - I can even make multiple lights and move them around in the simple 3D world. Still, Java is monsterously slow at rendering each triangle, which means I’m about at the point of diminishing returns - any enhancements now will slow down the system to far below acceptable levels (and I’m only getting about 10FPS with a 7,000 polygon model as it is).

I’d rather have a go at the thing in C, which I can optimize quite well, but I can’t get the darn GTK windowing library to work with my C code on the server. I think I’ll benchmark of all things VB.NET next and see how it does in rendering large amounts of triangle primatives.

I’ve started to get quite annoyed at Unix - so complex and so prone to blowing up in your face. It’s darn powerful, but the fact that I spent a very long time debugging my logon scripts after a minute change (which caused a cascade of unrelated errors) today makes me a little less fond of it. It’s nice to be able to pipe the output of a ls command into grep, sort and mail in sequence as one command, but when each command takes 90 pages of manual reading to get to work it seems a little less worthwhile.

Well, I have my lighting system working, although it’s incomplete. This is all good fun!

Currently I can specify an ambient light colour and intensity, which is applied uniformly to every object in the scene. I can also create new lights and position them in 3D space, each also with its own intensity and colour. As each light object contains a 3D point for its position, lights (shown as the “X” on the screenshots below) can be moved and rotated with simple method calls.

Next I’m going to add in falloff values for the lights, so that the light intensity drops off as the distance between the face and the light increases.

Java really isn’t suited to 3D, or anything graphical at all for that matter.

However, as an “academic exercise” (read: product of boredom) I’ve been playing around with making a basic 3D renderer in Java. Thank’s to my friend Alan, I’ve been able to extrapolate on his 3D point mathematics teachings and turn it into a working basic renderer.

Currently I’ve implemented double buffering to eliminate flickering, backface elimination and Z-ordering, and with all the overloading I’ve written I’ve now got a pretty neat 3D library. I’m yet to write any shading code (hence the reason why the below screenshot is ugly - I’ve had to randomly color each face to make the object visible) but I can load in objects from a basic proprietary 3D shape format of Alan’s creation and render them in 3D space. I’ve also added functions for moving/rotating points and objects, which allows the current demonstration code to display several spinning objects.

My shape class can show objects as either solid rendering (pictured), wireframe, or as a point “cloud”.

All great fun, but the performance is pretty horrible. Once more than about 7,000 faces are loaded in, the framerate slows to only a handful of frames per second - a high-quality Torus Knot of 12,000 faces only manages 3 frames per second.

The Z-Sorting for both objects and faces was originally a basic Bubble-sort of my own writing, but for performance reasons I swapped it out with a more efficient (if more complex) Merge sort algorithm. I had to “borrow” the latter from a tutorial site on the Internet — after two complete attempts of my own I gave up and left the sorting code to the experts.

I’ll try to get some more screenshots up in the next few days, and/or coax the applet into running in a webbrowser for a live demonstration.