So yeah, this blog thing. I guess in retrospect I shouldn’t have neglected it as long as I have, but in my defense, I’ve been darn busy these last few months.

Late last year our team’s responsibilities changed from ASF development (that’s the giant framework inside Atmel Studio, also available as a standalone download) to NPI work – the “N” and “P” of which stand for “New” and “Product”, and I assume the “I” means “Introduction” – and that’s caused some massive shifted gears in my brain while the rest of me tries to catch up. It’s interesting work, and fun too since I get to argue discuss nitty-gritty details with my co-workers and really make a difference. At least, that’s how it seems now, but I guess ultimately time will tell.

Customer Visit

In September last year I was put on a difficult customer support case. One of those really nasty ones: “we stopped production because of a x% failure rate in y% devices, after around Z hours of use.” Several weeks, some lab testing and a veritable ton of code inspection later I was suddenly thrown into a brand new situation; the in-person Customer Support Visit (cue dramatic music). Sometimes you need to roll up your sleeves (actually, first I needed to obtain some branded Atmel shirts, so I would had sleeves to roll up) and get on-site to diagnose the really difficult problems.

Within 24 hours of the request from the customer my travel plans were approved, my flights booked and my hotels reserved, and I was on my way over to Scotland. To say I was nervous was an understatement; while I don’t mind traveling, I’m not known for my confidence in new and scary situations. Still my boss and my co-workers did a bang-up job in keeping my spirits up and my lunch down, and before long I was settling in on-site and seeing what I could do to help.

My dad used to travel quite a bit for his work, and I always remember him saying that business trips are boring, since all you get to see are airports and factories. Boy, was he right. I can now say I’ve been to Scotland, but the only sites I really got to see were the airport, three (!) hotels and a hospital-like customer site. I did see a “Postman Pat” style mail van which was quite endearing:

But other than that it was just hotel:

After hotel:

Although in the latter case, I did get to sit on the world’s largest cushion:

And try a local drink called “Irn Bru”, which I assume is Scottish for “Flurecent Orange Creamy Soda”.

And I also tried Haggis. Worryingly, it tasted exactly like the filling of an Australian meat pie. All in all, it was a great learning experience, and I got to see how a real-world factory works from PCB production right down to final assembly and packaging.

Visit Home

Right after my customer visit I was on to more traveling; this time, back to familiar places. I was selected to be a support engineer for the Australian “Tech on Tour” training sessions held in Sydney and my home town of Melbourne in November last year. This is the first year I am aware of that Atmel’s run first-party training sessions, so it was a fantastically happy coincidence as I was then able to take a holiday off for Christmas directly afterwards.

The ToT trainings went quite well, minus a few minor hiccups like the conference room Wifi falling over in the first 10 minutes (Melbourne) and the air conditioning being unable to cope with 20 people and 20 computers (Sydney). This was another great first experience for me as I got to interact directly with customers, helping them with issues and listening to feedback for my team. While in University I toyed with the idea of becoming a lecturer rather than a engineer in the field, so this was a chance to experience a bit of that without the drastic career change.

I was thrilled to see my fellow AVRFreaks friends in Melbourne again and I finally got to meet the (in?)famous John Samperi over in the Sydney training, who was must less grouchy in person that I was expecting (kidding John!). The Sydney event was completed with one of the attendees asking me to sign his JTAG-ICE3. I guess that means I’m finally popular – take that, highschool.

While home I got to eat good food again (finally!):

Spend Christmas with family:

And ride on the largest miniature railway in the Southern Hemisphere (not pictured: me):

All of which was good fun. While at home I also spent a little time helping out a friend with his LEAP robot:

Which he was building for our old University to be used as a marketing tool. I was tasked with making an Android frontend for it, so that users could control it via Bluetooth from their mobile phone. I kinda like Android development now that I’ve had a little more exposure to it, so perhaps I’ll explore it a bit more in the future.

Back in Trondheim

I was more than a little bit sad to leave Melbourne again, not only because I was once again leaving my family behind, but this time also my girlfriend. Living alone comes with an adjustment; the largest one is trying to find a new apartment (the building I am currently renting is being sold). That comes with a set of new challenges, although so far I’m coping fairly well.

Stay tuned for an update on LUFA soon, since we’re overdue for a release. I leave you now with a sneak preview of what I’ve been working on over the last few weeks:

Just a quick update, because I know I’m going to get email on this otherwise. If you’re looking to use LUFA on the Arduino Leonardo board, here’s what you have to do.

Firstly, you need the current trunk version of LUFA – not the latest release. Not only does the latest trunk have board hardware definitions that the current release lacks, but it also contains a (preliminary) compatibility fix to the core to make it work with the Leonardo bootloader. Special thanks to Simon Inns for both his debugging help and the donation of an Arduino Leonardo board so that I can continue my development efforts with it. You can download the latest LUFA trunk here.

Secondly (Windows only), you’ll need to have downloaded the Arduino 1.0 IDE from the Arduino website. You’ll need this for two reasons; firstly, you’ll need the driver INF file it contains in the arduino-1.0\drivers directory, and secondly, you’ll need the Windows build of the AVRDUDE application that it includes in the arduino-1.0\hardware\tools\avr\bin. You need to add the latter to your system PATH variable so that you can run it from any folder from the command line. You can download the Arduino 1.0 IDE from here.

Thirdly, you’ll need to alter the project makefile that you want to compile. The relevant makefile magic here is:

MCU          = atmega32u4 # Change this
BOARD        = LEONARDO # And this
F_CPU        = 16000000 # And finally this
 
AVRDUDE_PROGRAMMER = avr109 # Add this
AVRDUDE_PORT = COM32 # And this too (use your correct COM port)

Those are the only lines that need to be changed from the standard LUFA makefile template. Note that on my system the bootloader appears as COM32, but on your system this will no doubt be different, so alter the AVRDUDE_PORT line to suit your own environment. If you use Linux, this line will most likely be /dev/ttyACM0 or another similarly named virtual USB TTY device.

That’s it – with the small changes to the project makefiles, you can then download a new application by pressing the reset button on the board, and running make avrdude from the command line shortly afterwards (while the L LED is still fading in an out to signal the bootloader is running).

It’s been a whole two weeks, and surprisingly there weren’t any real “you’ve done screwed up” emails sent to me about any horrible show-stoppers in the beta release, so I’m now calling the latest trunk stable and tagging it today as the LUFA 120730 release as planned.

This release has been one of the more tumultuous ones, as it’s the first made while I’ve had a full time job. In it I’ve tried to incorporate some of the new techniques I’m learning towards maintaining large software projects, but it’s also been significantly hampered by my lack of enthusiasm overall towards coding after a long day of, well, coding. I’m not saying I’m giving up by any means, but I’ve had to downgrade my overly enthusiastic future timelines to reflect reality a little. Lessons learned.

So, this release seems relatively short in the changelog area, but that’s somewhat deceptive as some of the changes are either back-end that don’t need changelog entries, or covered under a single line umbrella entry. There’s a new set of build tests (still not unit tests on real hardware I’m afraid, but the current smoke tests and static analysis still help) as well as the totally revamped build system, which paves the way slowly to a mufti-architecture future. The core now “kinda” works on the XMEGA platforms — but it is still not complete nor fully tested — and for once the limiting factor is revamping the board system (a comparatively simple, yet tedious task) and not the build system, demos or core. That’s a good thing. I’ve also reorganized the documentation to put the more useful bits right in the sidebar once again, to style it a little better, and to add new important documentation like a list of known issues for each supported architecture.

With this release I’m also moving the official GIT mirror from this GitHub entry to this one instead. I will continue to maintain the old repository mirror and you can still use that if you wish, but the new entry doesn’t suffer from the wrongly imported SVN repository issue that the older one has, which means simpler forks and smaller downloads. Also, automated tags are now actually a thing.

Thank you to the LUFA community for helping out, contributing and above all putting up with my relatively slow progress as of late. I realize people deserve better, thus I will attempt to redouble my efforts as much as I can in the future.

Without further ado:
LUFA 120730 Release Download
LUFA 120730 Prebuilt Documentation Download
LUFA 120730 Online Documentation Download

Well, this evening I finally caved, and packaged up the current LUFA trunk as a new 120730-BETA release. It’s been too long since the last release darnit, and since an increasing number of support threads on the LUFA list are resolved with “download the latest trunk”, I thought now’s as good a time as any for the next release cycle. Without further ado, the appropriate links:

LUFA 120730 BETA Download
LUFA 120730 BETA Prebuilt Documentation
LUFA 120730 BETA Online Documentation
LUFA 120730 Changelog

Please download and test during the next two weeks, so that any unknown issues can be uncovered and patched before the full release is made. This release contains may bug fixes and new features, including some additional board drivers, a new “SerialToLCD” user project contributed by Simon Foster, the new LUFA build system, and fixes to the known broken demos and applications. Once again, thanks also to the great LUFA community!

Yikes, time runeth away once again. Not much has happened in the last few weeks, except my probation period ending, making me an official full-time Atmel employee now, and my reluctant starring in a new set of pilot videos:

Since it’s been so darn long since I posted about something technical that I thought I’d try doing that today.

So, I’ll admit it, I’ve been putting off proper LUFA development over the past few weeks, since the next step in my quest to refactor things to the point where multi-architecture demos can become a reality requires an awful lot of work. And not fun work either, mechanical “I would script this if it was practical” type of mechanical work. That’s not to say I’ve been sitting around idle, it just means I’ve been focusing my time learning some fun new things and performing other refactoring tasks (in addition to support and bug fixing). So here’s what I’ve been up to.

The LUFA Board System:

A problem lies in the current board driver system: currently each board has a folder full of individual hardware driver header files, with the actual driver code implemented as inline C functions for speed and size reasons. in the user application, you set your BOARD={Something} value in your project makefile, include the relevant <LUFA/Drivers/Board/XXXX.h> driver in your code and away you go. If the application is recompiled with a different BOARD setting, the driver dispatch header automatically picks the appropriate driver, or defers to a <Board/XXXX.h> header in your application directory. Wonderful.

Or at least, wonderful if you are using a board that has the same features as the USBKEY board I develop with, since that’s how I design the UI for the demos that ship with LUFA. If you use a different board without a Joystick for example and try to compile the Keyboard demo, you’ll get an error about not being able to find a Buttons.h and Joystick.h driver. Fixing this requires manual tweaking of the demos, which isn’t very nice to newcomers.

So, the plan I’ve come up with is to replace the current board system, leading me into the gigantic ball of apathy that you’ve all seen over the last month. This requires the creation of a new per-board board.h header file to act as the new board driver header, which will be include in all user projects. This header file will in turn include all the board specific drivers, but also include a new Board_Init() function to automatically initialize all the board hardware.

Doing this will allow all the user applications to just include the one board driver header file, rather than having to pick-and-choose the individual driver headers. It will also mean cleaner initialization code, but most importantly it will mean compile time detection in the user code of the board driver features. With this new system I will be able to change the demos to detect if a joystick, buttons or other hardware is available and automatically provide some sort of demo UI to suit the board being targeted. No more compile errors.

I’m tossing up whether to press ahead with a new LUFA release in the meantime or to wait until I find enough time to undertake this – does anyone have any thoughts on this?

The LUFA Documentation:

So, with the new release of Doxygen 1.8.1 I’ve done a bit of spurcing up of the LUFA documentation. I’ve gone and re-tweaked my small customizations to the standard theme – I can’t do visual design at all, but I found something I liked a bit more than the defaults – and fixed up the documentation index. In the previous 120209 documentation a lot of the helpful pages were shoved in a “Related Pages” node due to a Doxygen bug, which is no more in the new release. To commemorate that, I’ve cleaned up the ordering and structure a bit to make things a bit easier to read. I’ve uploaded a temporary export of what the new documentation will look like, where you can see the new index page list.

In addition, I’ve added some new pages listing known issues I need to fix up, the new LUFA build system (more on that in a moment), added more information giving the prerequisites for building on both Windows and Linux platforms and showing one way that you can export the library core for importing and use in Atmel Studio 6 projects.

No groundbreaking changes, but any improvements are always a good thing, and I think this is one small step towards making the project as a whole a little more accessible to new developers.

The LUFA Build System:

I finally got completely fed up with the current build system – having a gigantic 600+ line makefile in every application directory was killing me due to the maintenance requirements, and frustrating users due to the apparent complexity. The LUFA makefiles were built from the public domain template found in the old obsolete MFile project subcomponent of the now obsolete WinAVR project with a few additional tweaks to make them useful for LUFA based projects. However, inside each of these giant makefiles was a huge amount of repeated “magic” rules that most people will never touch, and a select few variables that need to be adjusted for different build targets. Other problems were crazy error messages if things went wrong in some way, untracked dependencies causing odd build behaviours if multiple make targets were invoked at the same time, and output files generated from stale object files in some cases.

To combat this, I’ve created my own – yes, I’ll wait a moment for you to finish cringing – build system for LUFA. This is actually just a set of loosely coupled makefile modules, which can be included in the application makefile to obtain additional functionality. I think this is the best solution, as it allows me to edit the modules all in one place, and have the changes propagate automatically out to all the library applications. It also means I can fix up all the problems in the above, so the new modules have proper dependency tracking, and give sane error messages when things go wrong.

Here’s an example of what a typical project makefile looks like, contrasted to what we have in the current 120219 release. It’s a big change, and I really think it’s a great improvement. You can now get some nice build help by running make help from any makefile that uses the CORE LUFA build system module, listing all the available targets and other relevant information. There’s also the aforementioned new chapter of the manual with detailed documentation on how to use it. Of course, the manual has also been updated to give an application makefile template and explain the new makefile variables.

I’m quite proud of this, and I’ve learned an awful lot of the ins-and-outs of GNU Make while on my quest to build it. I’ve been considering opening up the build system into a separate public-domain project so that it can be adopted everywhere, rather than the crazy makefile template everyone is currently using.

New LUFA Git Mirror:

When I first made the LUFA Git repository mirror, I made a bit of a boo-boo, as I forgot the “--stdlayout” switch when creating the initial GIT-SVN import. That has resulted in the current GIT mirror containing a literal import of the LUFA SVN repository layout, with tags and branches being located in the sole master branch of the GIT tree, something I didn’t notice until it was too late to try to change it.

After a couple of different people emailed me about it over the last few months – including one very helpful one from a LUFA fan with some great insights into how best to fix it – I’ve gone ahead and made a second public Git mirror with the imported layout corrected. This new repository will be switched over to become the official mirror soon once I’m satisfied nothing has broken, with the existing mirror still being deprecated but still maintained for those who depend on it. The new GIT mirror has the tags properly added as read Git tags, and this now results in downloads of the current HEAD of LUFA being around 5mb rather than the >30mb it used to be.

So that’s the latest LUFA news.