Memos From the Cube

Last week I decided to download the latest Atmel Toolchain beta package from their rather well hidden beta site. This new toolchain is the spiritual successor to the WinAVR project — actually, it’s the same thing, except now it’s officially endorsed by Atmel, and it’s still being produced by the same guy. The new toolchain package contains updated avr-libc, binutils and avr-gcc versions, which means lots of bugs fixed, and new features to discover. One of the big changes to the new Atmel branded toochain package over the older WinAVR package is the presence of AVR32 versions of the tools; the one package now serves both the 8-bit and more powerful AVR-32 models. This means a single download serves the entire AVR lineup, reducing developer confusion.

So far, I’ve had a few teething troubles; the new Atmel AVR Toolchain package is missing a lot of the neat *nix tools that WinAVR included, such as grep. The existing makefiles of LUFA made use of these tools to process the source code to automate some tasks, but that’s now got to change. Biting the bullet, I’ve remade all of the LUFA project makefiles, so that with one exception (the main library core makefile’s doxygen target) these special tools aren’t needed anymore.

While I was at it, I decided to finally get around to doing something I’ve been wanting to do to the makefiles for a long time; make the core library makefile includable in the project makefiles. This has the distinct advantage of being able to inject extra common targets into the project makefiles as needed (say, to check for invalid events if I find a way to re-add it without the grep dependencies) but also the advantage of being able to list the module source files in the one place.

Why is this neat? It means that no longer do you need to care about what I call the source files inside the library core. I can now move and rename them as I see fit, and the user projects will still compile, providing they use the new “module source” names I’ve added to the makefile. Here’s an example of what the makefile source list use to look like for a typical class driver demo:

# List C source files here. (C dependencies are automatically generated.)
SRC = $(TARGET).c                                                 \
      Descriptors.c                                               \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/DevChapter9.c        \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/Device.c             \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/Endpoint.c           \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/Host.c               \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/HostChapter9.c       \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/LowLevel.c           \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/Pipe.c               \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/USBInterrupt.c       \
      $(LUFA_PATH)/LUFA/Drivers/USB/HighLevel/ConfigDescriptor.c  \
      $(LUFA_PATH)/LUFA/Drivers/USB/HighLevel/Events.c            \
      $(LUFA_PATH)/LUFA/Drivers/USB/HighLevel/USBTask.c           \
      $(LUFA_PATH)/LUFA/Drivers/USB/Class/Device/CDC.c            \
      $(LUFA_PATH)/LUFA/Drivers/USB/Class/Host/CDC.c              \
      $(LUFA_PATH)/LUFA/Drivers/USB/Class/Device/HID.c            \
      $(LUFA_PATH)/LUFA/Drivers/USB/Class/Host/HID.c

Which is, let’s face it, damned ugly and hard to maintain. Instead, here’s how the new system works:

# Create the LUFA source path variables by including the LUFA root makefile
include $(LUFA_PATH)/LUFA/makefile
 
# List C source files here. (C dependencies are automatically generated.)
SRC = $(TARGET).c                                                 \
      Descriptors.c                                               \
      $(LUFA_SRC_USB)                                             \
      $(LUFA_SRC_USBCLASS)

Which is much neater – once the library core makefile is included (with the LUFA_PATH value set beforehand) the new module source names become available. In the documentation, just look for the module names rather than the source names, and add those as needed to your project makefile. Of course, you can still use your existing makefiles, but this new system means less restrictions on how I internally structure the library code.

Finished Bluetooth code or not, it’s about time I thought about releasing all the changes I’ve made to the project over the last two months, so I’ll be releasing a public beta version in a few days.