Memos From the Cube

On an awesome-ness scale of Boiled Zucchini all the way to Denise Richards, finally receiving my AVR ONE! package rates about a Lamb Kebab. This afternoon a FedEx man turned up on my front door with a rather large Atmel-branded package in hand, addressed to me! In other news, I discovered it’s really hard to sign your name when you’re excited enough to be jumping up and down.

The package is all thanks to a kind Atmel engineer named Kristian, who liked my XPLAIN work (specifically, my open source PDI programmer for XMEGA chips, part of my AVRISP-MKII clone project) so much he offered me a free AVR ONE! kit, courtesy of Atmel. I’ve received a few nice toys from Atmel in the past for my efforts – including a JTAG-MKII which I use heavily – but this one really takes the cake.

You are forgiven if you don’t know what an AVR ONE! is, since they’re expensive and rarely seen. Picture a large Atmel branded Altoids Mints tin with a Sci-Fi-esque glow, and you’ve pretty much approximated what the real deal looks like. The AVR ONE! (yes, the exclamation mark is part of the official name for this beast) is Atmel’s premiere AVR development system, which can program and debug absolutely any Atmel AVR, from the small 8 bit series to the large 32 bit series. It’s kind of like a souped up JTAG-MKII, in that it connects to standalone boards via a long cable and adapters. The main reason to get an AVR ONE! over a JTAG-MKII (or a Dragon, for that matter) is its very advanced 32-bit AVR debugging capabilities. I’m not a big 32-bit AVR user yet, but if nothing else it will serve as an awesomely fast and robust programmer/debugger.

Here’s what the outer box art looks like. Mmm, Thor. I love the new Atmel box designs – my original STK500 was just a plain white and blue box. The new designs are much more inviting.

Front of the outer AVR ONE! box art.

Back of the outer AVR ONE! box art.

What you can’t see here is the sense of scale – the box is gigantic compared to the actual AVR ONE! device, to make room for all the extras. It was shipped in a “Large” FedEx outer box. Opening it up, I find a nice sheet listing all the contents, plus a date/signature of the person who packed it and checked it. I like this – it shows attention to detail, since it means no shipped boxes with missing parts.

Opening the box.

Here’s a slightly closer look at the top layer of the box contents. The gray unit on the left is the actual AVR ONE! unit, and to the right you can see the power adapter (white box) and bottom layer contents. I removed the right insert for this shot, since it just held the power adapter box in place.

Top layer of the box contents.

Next, I pulled out the power adapter box and the AVR ONE! unit to inspect it, and so I could get a good look at the other goodies in the box.

Bottom layer of the box contents.

Let’s have a good look at all the bits, shall we? Not shown here is the included USB cable or regional power cords (no Australian, damnit – only European and American). I’ll go over the bits in a minute. This makes a nice change from the cheaper Atmel units, since everything you could possibly need is in the box. The JTAG-MKII lacks a power adapter, and the Dragon doesn’t even come with a USB cable. I got the impression that Atmel has gone all-out to make you feel you’ve really got what you paid for here.

AVR ONE! kit.

Here’s a list what you get:

• AVR ONE! Unit
• Universal 12V, 1.25A Power Adapter
• USB Cable
• Power Cords for Adapter (European and American to Figure-8)
• JTAG and ISP standoff adapters
• MICTOR-38 Port Header
• Squid Connector Cable
• Self-Test Board

That’s right, they even included a surface mount MICTOR-38 connector – an odd looking thing designed for AVR32 boards, which I believe is an industry standard – for you to mount to your own board. The squid cable converts a standard 2×5 JTAG header into 1×1 coloured female jumpers, so you can connect to boards via ISP/PDI/TPI/JTAG which lack standard headers.

The AVR ONE! unit is metal, with a blue plastic stripe sandwiched in the middle. It’s actually surprisingly heavy, and unfortunately there are no visible screws outside two odd bolts on the back, so I can’t easily open it up to show internal pictures. I’m curious as to what’s actually inside of it – my guess is an FPGA and an AVR (EDIT: Looking in the AVRStudio help file confirms this to be the case). Why a FPGA you ask? When I upgraded it, there are several .bin files for AVR32, XMEGA, ATTINY and ATMEGA programming/debugging, and the upgrade client references a “disk”. Since AVRs cannot switch firmware on the fly (and since it’s too damn fast for some sort of bytecode) that makes me think it’s writing to an internal memory disk, which is then loaded into a FPGA for the actual grunt work.

Right, so let’s look at the connector. I already love the AVR ONE! due to its soft mini-IDC cable, instead of the plastic ribbon cable of the JTAG-MKII. The latter is rather fragile, doesn’t lend well to bending, and once it’s broken it’s almost impossible to replace, since no one stocks it. Thankfully mine is still intact, but I can tell its wearing where it meets the target adapter. On the end of the cable is a translucent blue pod filled with more electronics than a Jaycar store, presumably to add level conversion and the like to the signals. The end of the pod has a MICTOR-38 connector for AVR32 boards, while the underside contains a standard 2×5 female header for JTAG and other programming protocols.

AVR ONE! JTAG connector.

Now, back to the other contents of the box. Here we can see a weird cardboard box held together with a rubber band. What ever could it contain? In one of the static-proof bags, I also found an odd small board with both a MICTOR-38 and JTAG header.

Mystery box!

I’ll go over the board first. I was a bit confused at first (not being one to read the documentation before digging) – the board had *both* MICTOR-38 and JTAG headers, plus a small JTAG cable that was only a few centimeters long. The underside marked the board as a “Test Board”, which made me assume at first that it was a demo board for showing off the AVR ONE!’s capabilities. In actual fact, this is part of the system’s self-test functionality, which can be used from within AVRStudio to verify that the unit is working correctly once it is attached. This prevents the old “is my code broken, my board broken or my development tools broken?” question which can plague users of Atmel’s other offerings, like the thread on AVRFreaks recently when one of the buffer chips of John’s JTAG-MKII broke without his knowledge.

AVR ONE! self-test board.

The way this works is you plug both connectors into the AVR ONE!’s pod at the same time, then choose the “Self Test” option from the Tools menu. This runs a short set of checks via the test board, and returns a pass/fail result – plus error codes to send off to Atmel in the case of a failure so they can help figure out your problem remotely. I was a bit panicked at first since my unit spat out lots of errors, until I realized that the MICTOR-38 port had to be attached at the same time as the JTAG — this is the reason for the small JTAG extension cable, so that it can reach the JTAG port while the MICTOR-38 port is also attached.

AVR ONE! connected to the self-test board.

Finally, let’s go back to the mystery box. Inside is a set of four adapters, which can be inserted into the AVR ONE!’s JTAG connector on the pod. One is essentially just a non-flexible JTAG extension cable to move the pod away from the target board (otherwise it tends to get in the way) while another adapts it to the half-pitch JTAG connectors used on the Atmel Raven kits. The remaining two are ISP adapters of standard and half-pitch size – no more ^%$ing squid connector for ISP programming!

JTAG and ISP standoff-connectors.

This is the point where I connected it all up, and started AVRStudio. Unlike the JTAG-MKII, the power adapter is required for it to work – with the older kit, you could ignore the power adapter requirements if you connected it via USB into a bus host which could provide sufficient current. Not so with the amount of hardware being driven in the AVR ONE!, so I’ve now got another power cord on my desk.

Unfortunately, this is where I got frustrated – the drivers wouldn’t install no matter what I tried. After a bit of searching online, I found a post (on AVRFreaks, no less) indicating that I had to uninstall and reinstall my AVRStudio4 installation with the AVR ONE! attached for the correct drivers to be installed. This I did and suddenly all was hunky-dory, even on my 64-bit Windows 7 installation.

So far I’ve only played with it for a few minutes with my USBKEY to check that it works, so I can’t give too much information about how good it is in practice just yet. All signs point to it being fantastic however, as I can already see AVRStudio responding faster to it than it did with my JTAG-MKII.

Thanks Atmel!

One thing most people who who me well would say, is that I don’t call a lot – I prefer to email, text, instant message, facebook, twitter, or just talk in person. I have some sort of deeply rooted fear of phone calls; for some reason, I hate making and receiving them. In the last few years I’ve gotten a bit better, but I think it’s time to expand my horizons a bit — to the whole world! On that note, I’ve installed Skype, so that I can (hopefully) talk to people from around the world, and with any luck learn to relax when I’m thrown in front of a microphone.

So, with that in mind, add me to Skype! I’ve thrown a link and status information onto my contact page, so that people can instantly see if I’m around. Some times I’m at Uni or busy with other things, but if the status is green, click away! I’ve already had an interesting chat with Andrei from Russia, which marks my first international call – my original 2 minute call of garbled audio to an awesome lady named Lydiah in Africa from having not enough bandwidth several years ago doesn’t count.

Oh, and thanks for the interesting comments to my previous rant on the state of USB VID/PID pairs – seems I’m not the only one fed up with it and I was interested to see other’s solutions. I’ve got another rant in mind about the USB class codes which I’ll write up in the near future, with any luck. Some things just need to be said, whether anyone bothers to read it or not.

Most people who have worked with USB for more than a few minutes have discovered its dirty little secret; you can’t sell a USB compatible/compliant (note there is a difference, the latter requires a large payment) devices without first obtaining a unique VID/PID combination for your product. A VID, or Vendor ID, is a 16-bit value which is supposed to identify the exact manufacturer of a USB device, via a gigantonormous lookup table from the USB-IF. A PID, or Product ID, is supposed to identify a particular product manufactured by the vendor, so that when used together it forms a 32-bit unique code for each and every USB product on the market.

Note that this value is unique for a particular product, not device — each device can optionally have a unique serial number, but the VID/PID alone simply identifies to the host what the device is (e.g. “Happy Fun Technologies’ USB Webcam Model E123″). The problem with this is that for such a scheme to work, you need the USB-IF to act as a central registry for VID values, so that no two manufacturers release products to the market with the same VID/PID pair.

This is a problem only because the USB-IF charges companies out the rear for a VID value. Each VID value grants a company the ability to make a full 65,536 different USB products, which is a good thing — but it means that tiny businesses with only one or two products get shafted, since they’re stuck picking up the tab for a large keyspace that they simply don’t use. While 65,536 products is a lot for a single company, having only 65,536 different VIDs available means that most of the possible VID/PID combinations are wasted.

A few years ago, some smart businessfolk came up with a good idea; pony up the US$2000 or so per year it takes to secure a VID, and then resell the PID values to private buyers in small blocks. That was great for them and great for the buyers, since they could sell blocks of 10 or so at a reasonable price, and small companies could then use the purchased PIDs in their small line of products. Unfortunately, the USB-IF, never one to be cheated out of milking developers dry, threatened to sue all such resellers, and attempted to retroactively add in a clause to their license preventing resale.

So where does this leave us? Up the USB creek with no VID/PID. If you’re not interested in having full USB-IF endorsement (and the rights to use the USB logo on your products, etc.) you can still find people willing to resell you a PID block who bought a VID from before the license was updated. You could also bite the bullet and fork over your first-born – plus around US$2000 – to the USB-IF to buy a whole VID. Other options would be to ask your USB chip vendor, as some such as Microchip and FTDI will hand them out for free to customers requiring them. Finally, you could purchase a license to use a USB stack where the vendor has bought a VID, since in that case you’re buying the rights to use the stack, and just get the PID “for free” as part of the deal.

Do I find it ironic that people are forced to buy a license to a software USB stack implementation, just so they can bin it and just use the included VID/PID combination with the completely free LUFA stack? Yes I do. Am I grumpy about it? Yes I am. The USB-IF’s daft implementation of the VID/PID combination scheme has brought untold irritation to developers worldwide. Had they used a GUID implementation like Microsoft uses (where there is no need for a central repository, as the keys are partly time based and the key space is massive) or even a reliance on unique vendor/product descriptor strings we wouldn’t all be in this mess.

So go forth people, and source your precious VID/PID. Just make sure you tell the USB-IF how unhappy you are about the situation, regardless of how you obtain it.

Well, before I up and call LUFA essentially mature and complete, I’ve got one more class driver to implement, USB Test and Measurement Class (USBTMC). This is the class used in scientific and analytical products such as USB-enabled multimeters and power supplies, for direct control and reporting from a PC. It’s also fairly uncommon in use outside LabView and custom software, so Windows doesn’t have native drivers for it. That’s partly the reason why I’ve avoided it thus far; without drivers, I can’t test it at all. The other reason is I don’t have any USBTMC class USB devices, so I can’t write a host driver either.

Now that I have a Linux machine going with native USBTMC drivers and nothing much else to do, I want to go ahead and complete a device class driver for it. However, my last roadblock is finding some free Linux software which I can use to evaluate my class driver. I don’t care what it is – just as long as I can load it in Ubuntu, and have it connect to my custom USBTMC driver device so that I can send and receive messages to confirm that it works. Some sort of visualization would be even better, so I can report voltages from the ADC and display them to the host as a demo application. I’m at a bit of a loss as to what I can use however, so now I turn to the general community. Can someone point me in the direction of some suitable software?

University starts for a new semester tomorrow, so my holidays are now officially up for a while. Boo.

…by the web development bug. Help me, I can’t stop! Yesterday I decided to integrate Twitter into the site, so I can push up-to-the minute updates (or rather, that was my justification, but I’m kidding myself – I just wanted to see if I could). I’ve never been a fan of Twitter as-is, but perhaps as a micro-news feed on the site it will serve some purpose.
You’ll probably also note the sexy new donor information underneath the Pledgie Donate button, with the brand-new fading between donor information. That’s my first real attempt at anything jQuery-y, since I wanted to learn it. On that note, I’ve found this site to be invaluable for all your jQuery learning needs. I was a bit surprised that my initial attempt at finding a simple “fade out this box and fade it back in again every x seconds with different content” didn’t already exist for jQuery in a simple form; it seems it’s either a giant “includes the kitchen sink” plugin, or nothing. Since I don’t want to bog down the page too much, I decided to knuckle down and go the latter route.

You should also notice that the page degrades perfectly; if javascript is disabled, you just get static text of the latest donor. This is done via a server-side PHP script which caches the pledgie JSON code every 20 minutes, and which inserts the latest donor into the page when it is retrieved from the server.

Now, what else can I stuff into this thing?