Memos From the Cube

Yes, I know, I’m very late in posting something new here, just like I’m late for releasing the next LUFA package. In my defence, I’m currently running full steam at University finishing up assignments as fast as the lecturers are handing them out, leaving me very little in the way of free time for fun coding.

So, today’s post comes in several geeky parts.

Part One: JTAG-ICE3 is released!

So, as some of you may have seen on the Atmel website, the new JTAG-ICE3 has finally been announced. I say “finally” here which may sound odd to most people, since there wasn’t any hint of it beforehand, but I was drooling over them when I was on my Atmel internship. This is one of the neat things I left Atmel with in my bag, and which I’ve been using the past few weeks on and off along with the new AVRStudio 5 beta. I feel a little guilty saying this, but right now I strongly prefer it over my honking great big AVR ONE! debugger, since it does nearly everything the latter can (sans a few advanced tracing capabilities) but is smaller, lighter and requires no external power source.

So far I’ve only seen two downsides; one, it only works in AVRStudio 5, and two, it still doesn’t use a stock standard IDC ribbon cable to attach to the target. The first issue really isn’t much of an issue for me since I seem to be one of the few people on AVRFreaks who see it as a good thing (and I can categorically say that without it, the AVR32 LUFA port would never have happened if I was forced to use the Eclipse based AVR32 Studio software) and the latter, well, bah. It’s a very nicely designed piece of kit, but for something which will be moved around a lot and inserted/removed from a lot of target boards, I’d much prefer a flexible ribbon cable over the irreplacable plastic ribbon of the JTAG-MKII, or the giganta-probe of the AVR ONE!. This time the Atmel roulette wheel spun and landed on “half pitch IDC ribbon with adapter boards” which is much better than the other solutions but still makes be wonder what the advantage is over a $1 widely available cable.

Included in the box is a set of adapters for standard pitch 2×5, standard pitch 2×3 and half pitch 2×3, plus a squid cable breaking out the JTAG pins to 1×1 standard pitch female jumpers for connection to a remove board without a standard programming or debug interface. Here Atmel has left the glaring omission in the above (half pitch 2×5) out as an adapter, since you can connect the ribbon cable to your board directly instead.

The debugging speed has been fantastic, and the unit has worked well for me so far under AVRStudio 5 for my development. Interestingly, the contents of the debugger itself shows that it’s based solely on an AT32UC3A3256S chip, reducing the parts count to just the main AVR32 processor and a handful of discrete components.

Part 2: New Laptop!

Last week I decided that the time was about right to upgrade my laptop – which, although only two and a bit years old and still works perfectly, is a bit long in the tooth performance-wise for my development – so that my current system could go to a better home and I could grab something capable of decoding high definition video without wheezing and/or compile the entire LUFA tree in something under 10 minutes (sidenote: it’s actually faster to compile the tree under an Ubuntu virtual machine on the same computer than it is under the Windows builds of the GCC toolchain, much to my chagrin). I have a history of buying extremely cheap budget laptops which wear out due to low build quality (I’m looking at you, Compaq) or get outdated within a reasonably short timeframe since I’m not the typical web browser and MSN wielding user.

I decided to look around and use some of my internship money to buy something nice, something new, and that wouldn’t need to be replaced so quickly in the future. Having been all geared up to blow $2000, my friend showed me a read hot smoking deal from Dell, for a business grade Latitude E6510 laptop, complete with 4GB RAM, Core i7-740, 512MB dicrete 3100M NVidia card and a half terrabyte HD, all for only $1100 shipped. Given that’s half of what I expected to pay for a system a good deal better than the units I was looking at, I immediately bought it. It arrived on Friday, so I’m now officially one happy chappy.

Part 3: LUFA AVR32 Port News

This probably deserves much more time on it than I feel like using today, but it’s important nonetheless to at least keep everyone updated with the development of LUFA. I’m now at a stage where I can start QAing the latest SVN revisions for BETA candidacy, since it’s been so freaking long since the last official package was put up for general use. Now that I’ve got the APIs modified so that they suit multiple architectures – or at least, I’m most of the way there – it should be safe to release with the AVR32 stuff slightly incomplete as a preview, since it won’t affect the AVR8s.

So how goes the AVR32s? Right now the core is at a point where it is possible to create, compile and run AVR32 LUFA demos, although the existing demos will need to be adjusted to suit multiple architectures. There’s still a bit of hacking I need to do to work out how to fit in the interrupt system and missing functions normally supplied by the AVR C standard library, but it’s getting there. Having to supply a custom interrupt scheme makes me a bit wary, as inevitably the user will want to use their own and I don’t want that to clash with the one provided by LUFA. I’m actually still not sure what to do about that, but my current thought is to provide the interrupt controller as an optional LUFA module which can be replaced with user code if desired, or linked in if not.

The other big headache is endianness; the AVR32s are big endian, while most USB related protocols are little endian. This means that suddenly the demo code needs to take care of a lot of swapping of bytes, which again uglifies the code, but alas is a neccesary evil for compatibility. This will spell an end to the nice string descriptor initialisation I’m currently using in the library demos, since there’s no way to instruct the AVR32-GCC compiler to encode the Unicode string data in little endian format without applying a macro to each individual letter of the string. Yuck.

On the plus side, that means everyone can look forward to a new beta of LUFA soon, even if the AVR32 side of things isn’t completely done. This release will have many other benefits other than just multiple architecture support, such as the new HID report descriptor templates, partial stream transactions and a boatload of bug fixes and minor enhancements.

Part 4: The new LUFA team

Ok, so for this one I have to be a bit coy, since it’s not totally set in stone, but if all goes to plan there should be now five professional engineers from an unnamed very large company working on LUFA from different parts of the world, working to add in new features and port it over to a rival vendor’s vastly popular line of chips. That’s pretty exciting news, since it means a much wider user base (and license base!) for me in the end, but also gives me an opportunity to work from a distance in synch with some more professional engineers. Suffice to say here that if you’re an ARM user looking forlornly at us AVR users enjoying an easy-to-use USB framework, you should sleep a little happier tonight.