As per my comment, you have specified UNO board, but it doesn't have Keyboard/Joystick required definitions for the board (I'm not sure if UNO has any buttons to be defined there, it only has Leds, and leds are defined in Led.h - check out \LUFA-111009\LUFA\Drivers\Board\AVR8\UNO)
So what you could do is to create Board folder under your KeyboardMouse and make empty files Joystick.h and Buttons.h there. This should get you going further. Errors you are seeing are due to the following code in \LUFA\Drivers\Board\Buttons.h
#if (BOARD == BOARD_NONE)
#error The Board Buttons driver cannot be used if the makefile BOARD option is not set.
#elif (BOARD == BOARD_USBKEY)
#include "AVR8/USBKEY/Buttons.h"
....
#else
#include "Board/Buttons.h" <------ THIS IS EXECUTED SINCE UNO DOES NOT HAVE BUTTONS
#endif
So your error
../../../../LUFA/Drivers/Board/Joystick.h:119:31: error:
Board/Joystick.h: No such file or directory
means that your folder structure and your LUFA configuration is correct, but you're missing file Buttons.h in your KeyboardMouse/Board/ folder. Got it?
Try what I've suggested and see how far you get. You can see how to define buttons in other Board's folders, for example in LUFA\Drivers\Board\AVR8\USBKEY\
EDIT
Btw, I forgot to mention, error about common.h should go away hopefully after fixing this since that ........\ is coming from a file in a different location in folder structure thus confusion.
EDIT
OK, so here's the link on how to build custom board drivers:
http://www.fourwalledcubicle.com/files/LUFA/Doc/111009/html/page_writing_board_drivers.html
What you need to do is to copy files Buttons.h and Joystick.h LUFA\CodeTemplates\DriverStubs\ (or try copying Buttons.h and Joystick.h from USBKEY better, I think you still would need to specify a value for each definition otherwise) This should get rid of undefined errors. You have TODO sections in the files that you need to update.
OK, so I think I should also mention how this is supposed to be used before going further. These drivers/definitions are meant to be used in a specific manner in your code, and LUFA is unifying the approach for you. As far as I can tell, buttons are used in a following manner:
if (Buttons_GetStatus() & BUTTONS_BUTTON1){ ... do something when button 1 pressed....
This way, if you have several boards with at least one button, your code should theoretically stay the same across the boards.
Similar stands for LEDs, you can use them like:
LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
....
LEDs_SetAllLEDs(LEDMASK_USB_ENUMERATING);
I hope you get the picture. In order to use these library functions you have to define buttons/joystick/led specifics in their respective header files. So for example - in buttons.h you need to specify any custom header files you need, add port masks for buttons (on which pin of which port they are connected), specify port initialization and how to read the status of the buttons. You can find all of that in the USBKEY's buttons.h - e.g. it's importing common.h, defines BUTTONS_BUTTON1 like pin 2 of a port, initializes PortE with this button (so button is pin 2 on port E), and in Buttons_GetStatus it reads the status of the button.
I could go on and on in the same manner for joystick as well, but I hope you get the picture. Joystick is more involved but it's like having 4 buttons of which 0, 1 or 2 can be active at any time.
BTW, this is only useful if you have any buttons on your board. For example, I made keyboard driver without any buttons (I had to remove buttons specific code though). I used Ir Diode to read remote control codes and make the board act as keyboard. So you don't really need the buttons, nor the joystick (of course, it completely depends on what you're doing).
libc, included with gcc and avr-gcc, has a function that's used to count leading zeros when converting from an int
or uint
into a float
or a double
. This function uses a 256 byte table to speed up the zero counting operation, which is fine for computers with lots of memory, but not so great for microcontrollers where 256 bytes is 1/4 or 1/8 of the total ram available.
avr-gcc includes a library, libm.o
which has alternate definitions for some functions, including the function that requires __clz_tab
. This definition requires less memory, and so you need to instruct the linker to link against libm.
This is done by adding -lm
to the linker command line.
However, the position of this command parameter matters - it will only resolve links to symbols before this parameter, so to make the most of it the -lm
parameter should be as close to the end of the command line as possible.
In my Makefile
it looks like this:
CXX=avr-gcc
CFLAGS=$(MCU) $(CPU_SPEED) -g -Os -w -Wl,--gc-sections -ffunction-sections -fdata-sections
LFLAGS= -Wl,--section-start=.text=0x0000,-Map=program.map
INCLUDE=-I ../include/arduino/
LIBS=-L ../lib -larduino -lm
default: program.hex
program.hex: program.elf
avr-objcopy -O ihex $< $@
program.elf: bcu_usb.cpp main.cpp programmer.cpp
$(CXX) $(CFLAGS) $(LFLAGS) $(INCLUDE) $^ -o $@ $(LIBS)
Note that the last item on the compiler command line is $(LIBS)
and the last item in LIBS
is the -lm
which ensures that the compiler gives precedence to the definitions in libm when there are multiple definitions available.
Recent versions of avr-gcc have resolved this issue so this doesn't happen even without the -lm
, however the arduino IDE is still installing and using the older versions of avr-gcc, and winavr hasn't been updated since this bug was fixed.
You can read the bug report here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524
Best Answer
Okay, problem found. The Vendor ID and the Product ID of the firmware was changed in subsequent non-factory firmware releases which prevented the Arduino drivers from recognizing it. The solution is to use either the drivers in the LUFA project folders, or change these lines in
Descriptors.c
to this
Hope this helps someone in the future.