Memos From the Cube

A quick note; I’ve finally got around to releasing a new version of LUFA, which contains a bunch of mostly community driven (thanks guys!) bug fixes and improvements. The new Atmel Studio extension has been submitted to the Atmel Gallery for approval, so expect an upgrade pop-up in Atmel Studio 6.x – if you have extension upgrade notifications enabled, that is – once it’s approved.

It looks like I’ll be pulling 12 or more hour days at work for the next month, so if you don’t hear from me send cookies and coffee.

Changelog is located here for the new release. Release download links are located here.

Enjoy!

Oh right, this blog thing. All’s been fairly silent publicly in Camp Camera over the last few months — but fear not, for I know you’re all excited to hear that I am, in fact, still alive and kicking. The truth of the matter is that I’ve just been completely drained of both spare time and energy ever since I started work making light bulbs for a living. No jokes about Watts, Lumens, etc. please, as I assure you I’ve now heard every single possible pun in the English language on the subject.

Working at a start-up company, even a fast growing and fast growing-up one, is a very difference experience to my time at Atmel. It’s had its ups and downs, tantrums and triumphs, but overall I really think it’s been of a great personal benefit; I’ve rapidly expanded my comfort zone outside the realms of my beloved AVRs and into the wide range of horribly broken, awfully designed processors thrown up by various silicon manufacturers. All those who’ve complained about (non-UC3) AVR datasheets in the past can put a sock in it, for there are worse beasts out there.

That said, recently I’ve started taking a guilty look at my overflowing inbox — last year I averaged about three to four days before giving a response, sadly of late it’s more like two two three weeks and I’m trying to regain a little of the work/life balance I’ve been missing. Me culpa.

The downside to spending all day arms deep in third party stacks and undocumented processor bugs is that when I get home I don’t really feel like working on my personal AVR projects very often, but a week ago I decided to poke around a bit again and re-familiarize myself with my old code. And of course, as luck would have it, I managed to hit a fun “feature” of the newer versions of AVR-GCC whist trying to test a third party contributed patch to LUFA’s bootloaders.

A summary: the newer versions of AVR-GCC optimize some C switch statements into a jump table (effectively a bunch of GOTOs), using a fixed set of assembly instructions that read out the jump target locations from the table stored in flash memory, via the LPM instruction. However, while this works on most classic 8-bit AVR processors, if the jump table is located above the first 64KB of flash memory, the ELPM instruction needs to be used, or the read data will be sourced from an incorrect position in the lower 64KB of flash and the processor will jump to an unintended location. The GCC internals have safety checks to avoid this case, however it fails when the compiled code is relocated such as in my case where the application text segment is moved into the upper bootloader area.

The fix is simple, compile with the -fno-jump-tables flag to disable that optimization. I still think this should be off by default, or at least the pessimistic ELPM instruction used on the larger parts (so that the optimization works regardless of the jump table’s location) but alas, we’re stuck with what we have. In any case, as of the next LUFA release that optimization will be disabled by default in the LUFA build system and Atmel Studio templates.

On that note, I’ll be spinning a new LUFA release soon, since it’s been quite a while since the last one earlier this year. Most of the changes this time are community driven, but I think it’s a shame that they aren’t in general use so the time is about right for another full release package.

Oh, and AVRFreaks.net has finally got a new facelift after many years (and, much more importantly, a new backend that appears to actually work). Go check it out; there’s a lot of known issues like broken redirects from the old style URLs that are being worked on, but it’s great to see some movement on it after having it stagnate for so long.

UPDATE: Looks like the GCC developers have now fixed it for AVR-GCC 4.9.2. Awesome!

So, work’s been getting interesting and I’m settling in much better. Working with new vendors parts has been an interesting experience; from growing up with Atmel products to eventually working from Atmel, all my embedded experience has come courtesy of the big company with the least interesting logo. That rings true even as I moved from AVR8 to AVR32 (sorry, UC3) to ARM during my two years abroad over in the land of Vikings. Now in just two months I’ve touched two other unspecified vendors’ chips, and I suppose the old “ARM is an ARM” mantra rings true. Partially, at least.

Two important differentiators I’ve noticed; the peripheral set, and the datasheets. Here’s where vendors can win and lose out against each other, as having poor/overcomplicated hardware modules, or a poorly written datasheet can cause severe hair loss to us lowly engineers. So far I’ve found some great peripheral features I really like (a watchdog that stops during single-step debugging and breakpoints, so you can debug properly? Ingenious!) but mostly I’ve discovered why Atmel remains ever-popular. Why other manufacturers think that device characteristics should be hidden and datasheets should be written as obtusely as possible, I’ll never know. Even technically poorer silicon is a better choice if the datasheet is the written the best, as at least the silicon issues would then be well-documented. That said, branching out a bit and becoming a bit more well-rounded is really exciting for me.

In the last two weeks I’ve received two new toys, one from my former boss/co-worker (who has, incidentally, just started his own blog) in the form of a pretty purple PCB:

The board is an adapter for Atmel’s new(er) “Xplained Pro” series of kits, breaking out the extension headers into an Arduino “shield” form-factor. Neat, now I can use Arduino stuff with my SAM D20 board I acquired before I left. Well, I will be able to as soon as it arrives along with all my other stuff that’s being shipped back from Norway later this month. Shipping internationally: it’s not a speedy process by any means.

The second arrived tonight, so I’ve only had time to open the box and plug it in. Introducing the new Atmel ICE:

It’s basically “just” a souped up JTAG-ICE3, i.e a high-speed programmer and debugger for all AVR8, AVR32UC3 parts, but also does Atmel ARM now via a second dedicated debug connector.

Inside the box:

Initial reaction: they forgot to paint it. Cool, a prototype!

Then I read the serial number, unit 1565. Hrmph. Seems they actually all come like this — it’s certainly a change from the previous glossy silver. Here’s the two headers side-by-side, the left for ARM and the right for AVR:

Hey, whatever works. High speed switching on a single connector would mean expensive parts, and I suppose people won’t need to switch them over too often.

Up until this point other than the color nothing was a surprise – I saw prototypes before I left back in December. But then I opened the box on the right with the cables. Inside was the same squid cable as the JTAG-ICE3 (boy how I miss the rainbow squid of the obsolete JTAG-ICE MK-II) but also a weird connector cable and, well, this thing:

Instant reaction (LIFX background lighting for emphasis):

Speechless. This is the first time I’ve had absolutely no idea which end is up on a debugger, and/or how to plug it all in without consulting the manual. I’m sure it works fine, but I think I’ll stick with the adapters from my old JTAG-ICE3 on the new debugger (for AVRs, anyway), as they are compatible. The new omni-adapter PCB looks like the result of shoving a handful of connectors into a particle accelerator, setting the dial to “medium-well done” and shipping the result. It’s probably workable, but certainly not what I would have expected to be lurking in the box.

That’s all for now, more on the usability of the thing once I’ve got some hardware around to debug…

A quick one tonight; I’m ready for bed, but don’t want to forget about this.

I’ve just pushed out a new LUFA release, version 140302. This new release was sparked by Atmel’s brand new Atmel Studio 6.2 beta release, which required a manifest file update for the existing extension to work right — so I thought the time was nigh to get a new package out in the open anyway. I’ve actually been quite busy with other things the last few months (new job, moving across the world, some Atmel Studio extensions, a holiday, and not having any electronics hardware since it’s all still being shipped to me) so alas this update is a bit bland. That said, it contains some really, really great demo refactoring work by László Monda (who’s currently working on a pretty neat side project) so BIG kudos to him.

All my Atmel Studio extensions are now updated ready for 6.2, and waiting for approval in the Atmel Gallery (LUFA included). I’m actually pretty excited about the new release, as it marks the start of a move towards getting GDB debugging integrated as a backend to Atmel Studio. In laymens terms: they fixed debugging so that it should actually work now. Why that isn’t in gigantic 72-point font on the Atmel homepage I’ve no idea. You can grab non-gallery builds of my extensions here in the meantime until they go live officially.

Yesterday I grabbed a new website URL, since it was impossible to let slide: http://dean.camera. Props to Angus (of AVRFreaks fame – and a great guy as a bonus) who alerted me to the new rash of novelty Top Level Domains (TLDs) that just became recently available. I managed to be in time to snag the absolute, bestest, perfect vanity URL. Not sure what I’ll do with it yet other than confuse URL auto-linking scripts, so for now it just aliases FourWalledCubicle.

More to come soon, but not about my new workplace – they have a fairly strict policy on public media. On the bright side, plenty of other cool stuff to write about!

LUFA 140302 Changelog
LUFA 140302 Online Documentation
LUFA 140302 Project Page

Just a quick update – ever since Twitter decided they were too awesome for public RSS feeds (prompting me to remove my feed from my site, because screw having to go through their Auth-APIs for public posts) it’s been harder to put up tiny tid-bits of news between posts. It’s currently 40-something degrees Celcius and it feels like my clothing is about to catch fire, so I’ll be brief. Two things of note for today.

A week ago I released an initial version of DMBS, my GNU Make modular build system, currently targeted at AVR8, AVR32 and XMEGA sub-architectures. Eagle-eyed users will note that it’s actually just a slightly modified version of the build system in LUFA, which I’ve updated to remove all the LUFA specific functionality. Check it out on GitHub here. It’s a simple project that aims to remove all the redundancies from the common makefiles that most AVR people use (sourced from mfile/WinAVR) while adding much more functionality. I’ve released it into the public domain, so now no-one has an excuse for carting around a 100KB makefile full of cruft for each of their projects.

Also new is that Atmel threw up the video taken in my old office a month ago, which demo’s the final project I was assigned to: a SAM D20 based GPS Tracker. Video-only for now, however no doubt the code and application note will follow soon. Even if you hate the idea of locating things easily, at least check it out to see my old stomping grounds and some of my old co-workers. I’m in there too in a couple of shots, but only for a brief moment. EDIT: Tracker schematics, source code and application note are now live as AT03821.

Speaking of things throwing up, I start my new job in only a couple of days. Eek.