Memos From the Cube

A quick update. I’ve just taken a few quick (and still shakey, need to find the tripod!) high resolution shots of the new Atmel DB101 board. Feel free to take a look at the pictures and bask in the increased detail:

http://www.fourwalledcubicle.com/img/Blog/DB101

Plenty of visitors to my site from AVRFreaks since I put up the link to my DB101 board review a few days ago - well more than usual anyway, with an average of about 40 unique users each day visiting some portion of my site. Actually, I’m quite frankly surprised that there hasn’t been much discussion of the DB101 board online, sans for a few posts in a single AVRFreaks thread. I hope that will increase once others start getting the boards into their sweaty palms, as it really is a great board.

A few days ago I posted my space game to a discussion board about an old game (now free and open source) called Star Control, from which I “borrowed” the basics of the gameplay from. The response was a little less interested that I had hoped for - and in several cases, downright hostile - but I’m continuing with it regardless. To make it more interesting I’ve just finished adding planets with gravity and collisions.

Also new is the playfield scaling, where in the graphics mode the arbitrarily sized playing field can be scaled to fit the chosen size of the applet. Both of these features are visible in the below screenshot:

A zip archive with the current game source is available for download here in case anyone wants a gander at it. It’s unfinished and my first working game, so go gentile with the criticism! Actually, I wouldn’t mind chatting with someone experienced with this sort of thing, so I can get some ideas on how to structure the game. While this is really just an exercise I want to do for myself, I’m nevertheless interested in knowing how the “real” games work under the hood.

Well, better late than never in reporting news. As a follow up to my earlier post about ButtLoad’s incompatibility with the popular open source AVRDude programming software, the problem is now resolved. I’d like to publicly thank AVRFreaks user Luke (lfmorrison) for his help - it was he who both debugged the problem and created a solution.

As he hypothesized, the problem was indeed in ButtLoad’s handling of the SPI_MULTI command - I had an increment in the wrong part of a loop, causing it to miss the transferring of some of the SPI data.

That’s all for today. Next week is my mid-semester break, which means time to get some of my Uni assignments done - and time to work on MyUSB. I’ll be needing someone with other USB AVR flavours than the ATUSB1287 to assist in the porting of the library to the other family members eventually, so if you’re interested please email me. Porting of the library will be done after the completion of the Host/Device modes, and after the compile-time separation of the two modes.

It also looks like the MyUSB name is here to stay - gimpy and unoriginal, but I lack any creative inspiration for a better name, and by the lack of emails I surmise that everyone else is too. If the host mode is finished before a new name is chosen, I’ll have to stick with the current codename as the official name of the project.

Yes yes, I know, I’ve been neglecting MyUSB over the past few weeks. I have in fact been working on it in a limited capacity, but no major advancements in the last week due to my horrendous University workload and schedule. I’ve got the host code up the the point of having to write the code to transmit and receive standard (”chapter 9″) USB requests, which is a good start, and I’ll be coding up the rest when I have a nice big block of free time.

However, rather than post a “nothing to report” post, I thought I’d share a small bit of MyUSB-related news. Thanks to the efforts of a Denver Gingerich, MyUSB now has a working keyboard example to compliment the existing mouse example. The code’s not finished yet, but when it is it will be posted with Denver’s permission on the MyUSB project page of my site, as a zip or a link depending on what he preferrs.

I do love hearing about other’s examples and experiences with MyUSB, so keep that feedback coming! By all means email me if you’d like to see some changes to the library, or to share your own MyUSB-powered projects

Well, today marks the day I can finally talk about my new toy, the DB101 board from Atmel. As it’s just become public today I thought I’d post a review here.

First off, a note: my board and its firmware is not the final revisions, so there may be a few slight differences in what I say and show here and what ships from Atmel. My board is missing the RGB backlight, so other than commenting that it exists on the final version there’s not much I can say about it.

The DB101 is designed to be a “human interface board”, and so despite being quite well powered it lacks a large selection of external general IO pins. This is by design - the board is supposed to be connected to a “master” board, and communicate via one of the on-board protocols such as serial or SPI. There are still seven completely free IOs for use however, available via two groups of small unfitted pads on the board shown below:

The available general IOs are F3, B5, B6, C2, D7, D6, and D5.

The board dimensions are quite small, at only 8cm x 5cm. This board however packs quite a punch, with a beefy MEGA1281 AVR microcontroller and a nice 128×64 pixel monochrome graphic display with RGB backlight. Despite the lack of a backlight on my test model, the display is still quite readable under most sane lighting conditions.

The DB101 has many similarities with the Butterfly board, also from Atmel - I consider this to be its “bigger brother”. Like the Butterfly it has an onboard Piezo speaker (for feedback beeps and bloops), dataflash (16Mbit) and joystick. It also, like its little predecessor, sports a coin battery which can power the board via an on-board buck-boost converter.

The coin battery is a nice addition for portable use, however it’s a little misleading. The battery can power the board, but the results are that the converter drains the entire battery in only a few short hours. On the incomplete model I have, the DB101 managed to completely discharge the coin battery while in sleep mode in firmware after slightly less than two days. For this reason, when not in use the battery should be removed or the board changed over to external power to preserve its lifespan (note this is unsuitable for applications using a RTC, where the power must be applied at all times).

Thankfully, the DB101 has an external power option. This power can be any voltage between 1.8V and 5.5V, which makes it more tolerant than the Butterfly. Vext can be fed into the board via any of the Vext pads next to the communication interface pads on the front of the board. To change between the two power sources, a jumper must be changed on the back of the board to isolate a supply - see below pictures.

The board is clocked via a 7.37MHz ceramic resonator, stuck on the back near the MEGA1281 AVR chip. This value is good for a multitude of error-free serial baudrates. For RTC applications, there is the standard 32.768KHz watch crystal attached to one of the AVR’s timers.

Programming and on-chip debugging of the board is made very simple with a couple of right-angled pin headers on the back of the DB101 for JTAG and ISP. Note that due to the size of the flash in the MEGA1281 (128KB), the Atmel Dragon development board is unable to JTAG-debug the DB101, however the full JTAG MKII will of course be able to do the job.

On the sides of the board are connectors for the USART, SPI and I2C interfaces. These are all level converted automatically, via the Vext pins when running of the DB101’s coin battery. The interface connectors are also duplicated along the bottom of the board, for easy layout of matching connectors on a master board.

That’s just about it. It’s a nice board and comes with a neat set of applications (slideshow, “Snake”, “Game of Life”, a serial terminal, etc.) and sure to become a fun toy amongst AVR developers in no time.

Half the USBKEY is now soldered up with the adapter boards, which are already proving useful. Having easy access to the serial USART is fantastic, as it allows for a much higher-level debugging than the JTAG MKII allows. Both systems combined make for very easy debugging - from a technical standpoint, that is.

The other half of the boards will have to wait. I underestimated just how darn difficult - even with a fine-point iron - it is to solder the absolutely minute pads on the USBKEY. If there’s ever a petition to up the size to normal 1mm pads, I’ll be the first to sign.

Time for me at the moment is very short and very precious - plenty of homework to keep me busy until the mid-semester break in another two weeks or so. Then I’ll have a nice long week of rest before being pushed right back into the thick of things for the last term of my first year.

In other news, Atmel have just released a very interesting AVR video blog post about the history of AVRs which I highly recommend that everyone so-inclined should watch. Lots of interesting behind-the-scenes footage of the Atmel fabs and design house, which is what I’ve been craving to see ever since the AVRTV website started up a few months ago.

Last week, my latest USB memory stick died, making it the third or fourth I’ve gone through. I seem to have a bad juju about me about USB memory sticks (and packages, which is another story) with fake sticks, bad flash chips and dead controllers being the norm. My next stick will hopefully last a little longer. After the first one died, I was taught a painful lesson about keeping backups on the hard drive after loosing two weeks worth of code. This time I faired better, with only inconsequential files being lost (as I was using it as a transport between computers).

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.

Well, more work on the space game, and it’s now in a state ready for AIs. Anyone willing to give writing a simple AI a go?

Today between classes I reworked the ship and bullet list management. Previously I had written up a nice generic linked list manager, which worked quite well - and expanded as needed to fit into the available memory of the host machine. However, speedy it was not, due to all the object creation and removal required to manage the list, and as a result caused quite a drop in performance for large games (a 5,000 ship random battle took several minutes just to populate the list on my machine). Replacing it with basic, static lists reduces some of the functionality and increases the memory requirements, but results in a massive performance increase.

Above is a screenshot of the engine running a battle of initially 5000 ships (with each ship’s movement and firing being completely random).

As for my USB stack, this week I’ll finally have some time to work on it again. In the meantime, I’ve updated both the basic library zip on my site, and the USB Mouse demonstration firmware to the latest library code.