LUFA fills ATmega8U2's 4K of flash

Using Arduino Project Guidance
1

Hi. I have reprogrammed my Uno's ATmega8U2 to be a HID keyboard, based on LUFA:

\LUFA 100807\Demos\Device\ClassDriver\Keyboard

My makefile is Arduino's default (arduino-0022\hardware\arduino\firmwares\arduino-usbserial\makefile) but with the TARGET name changed.

It works well. It is shown in XP's Device Manager under Keyboards as a HID Keyboard Device, and my Uno posts keystrokes to apps on the PC such as Notepad.

Here's the problem: I have only added a few lines of code to LUFA's example code, but it pushes the total code size to fill the ATmega8U2's 4K of available flash. The other 4K of the ATmega8U2's 8K of flash is used for the bootloader.

I would like to make more code space available in flash so I can add more code. (My goal is to develop a USB composite device, appearing to the PC host as both a HID keyboard and a virtual serial port).

Here are the options I can see:

  1. The most promising option seems to be to replace the default 4K bootloader with a smaller bootloader, say 2K, adjusting the partitioning of flash to reserve less space for the bootloader. I am not yet clear on the details of how to do this. Perhaps suitable bootloaders may be LUFA's (\LUFA 100807\Bootloaders\DFU) or ADAboot or Teensy's.

  2. Compact LUFA. For example, re-write parts of LUFA in assembly rather than C, or somehow change LUFA's C code to optimize it for space, or use a LUFA compile switch (http://www.fourwalledcubicle.com/files/LUFA/Doc/081217/html/tokensummary.html). This may reclaim a few bytes, but I'm not optimistic that it would achieve anything significant.

  3. Eliminate part of LUFA. Perhaps I am not using part of LUFA, and this unused code can be excluded. Though my map file shows many "Discarded input sections" which I assume are unused code that the linker excludes.

  4. Change from Arduino to Teensy which uses an ATMEGA32U4 or AT90USB1286 (Teensy USB Development Board) though I imagine that changing to this alternate platform would introduce various new challenges.

Does anyone have any ideas, comments, suggestions, or advice on how I can add more code, either pursuing one of the above options, or some other approach?

As an aside, perhaps it would have been better to use an ATmega16U2 on the Uno, given that its cost difference with the 8U2 is very small.

Thanks very much,
Henry

2

Seems like we are after close to the same thing. I want a HID audio input for the DC coupled Uno ADCs (not for sound).
(I can only imagine such a HID interface would only make the space problem worse.)

Thanks for the good info and lots to think about.