Forking to customize for a specific board?

[trusktr]

Hello,

I've forked LUFA in order to modify it to work specifically with the Arduino UNO R3 (e.g. make the Board folder and the files within, modify the makefiles, etc). My intention is to keep the master branch of my fork identical to the master branch here, then do my modifications on a separate branch called arduino-uno-r3. Whenever the repo here gets updated, I'd pull into master, then merge those changes into arduino-uno-r3 and update as necessary.

How would you recommend to handle this situation? Is my fork a suitable way to develop for a specific board? Or is there some other way you'd recommend?

[abcminiuser]

That's a good approach given Git I think - since this is GitHub forking is appropriate, and you can either make your changes in your master branch (and be forced to resolve merge conflicts when you pull from my tree immediately) or use a branch for your changes to make diffing easier.

If your board drivers match the core LUFA board drivers (buttons, LEDs, etc.) and are mounted on all Uno boards, submit a pull request afterwards and I'll merge it in. I already added a LED driver for the Arduino Uno, has the new board revision changed the hardware pinouts?

[trusktr]

I totally don't even know. I'm a total newb. I haven't gotten anything even working right yet.

This is my first time ever programming a microcontroller and the Arduino UNO R3 is my first board ever. I've been a GUI/software developer (HTML5, Java, Qt, JavaScript with Node.js or PHP in the backend) since I started programming 4 years ago. Then a few weeks ago I decided to jump into a hardware project to create a scriptable keyboard, and there just happened to be an Arduino UNO R3 laying around.

I then did some research and discovered LUFA, which took me forever to figure out how to compile (i.e. getting the right tools, editing the makefiles with board-specific settings, making the drivers (Joystick.h, Dataflash.h, etc, which compile but I'm sure I've not done them properly yet)). This process has led me to learn new makefile concepts things like recursively and simply expanded variables, automatic variables, and other make stuff.

I've gotten the Keyboard demo to compile, but I don't think it works considering that I copied the template drivers from LUFA/Drivers/Board/ into LUFA/Drivers/Board/AVR8/UNO/ and simply defined the TODO items with random numbers (I know, I know). Then in the Keyboard demo I did ln -s ../../.../Board/AVR8/UNO Board to make those drivers available when making the demo. The Board.h and LEDs.h files were already there, so I copied over the other templates that make was complaining to be missing (Buttons.h, Joystick.h, Dataflash.h for the MassStorage demo) after changing the BOARD variable to UNO.

What I was originally trying to do was compile Darran's Arduino USB Keyboard HID firmware using LUFA, but it doesn't work with the latest LUFA, so I'm trying to learn how LUFA works and then I want update Darran's library to work with the latest LUFA. I've forked his old code here.

I've still got some learning to do. Any tips? :)

[trusktr]

After having gotten the Keyboard demo to compile and flashed onto the Arduino, what's supposed to happen when I plug it in?

[abcminiuser]

It should enumerate as a HID compliant device. On supported LUFA boards it should send key presses when board buttons and joysticks (if present) are moved -- otherwise (if the board is set to NONE) it'll just enumerate and sit there until you code in your own UI.

[trusktr]

I think that coding "my own UI" part is where I'm having problems. The main() of your keyboard demo and Darran's old one look similar, both essentially do the same thing.

I've got to learn why my Arduino sketch works on Darran's but not on yours. I believe that in theory it should not matter which firmware (yours or Darran's) is in the Arduino; the same sketch should just work either way, but I haven't figured out what I need to change in your version yet.

[abcminiuser]

The original LUFA demos are designed to work on standalone boards, and not in concert with a second processor (like on the Arduino platform). That's not to say you can't link up the LUFA functions to the second processor over SPI, I2C, USART or other bus, but the base demos don't work that way currently.

What Darran has done is to get my base Keyboard demo, add on the code needed to read and write the keyboard scan codes/messages from and to the USART and then recompile the demo for the ATMEGA8U2 used on the Arduino. That allows you to then tunnel your keyboard keypresses on the Arduino through the USART into the USB AVR, then through the USB AVR to the host PC.

[trusktr]

My intuition was telling me it was something along those lines. It's such a huge world in such a tiny space. Thank you very much.

/#!/JoePea On Jul 26, 2014 8:45 PM, "Dean Camera" notifications@github.com wrote:

The original LUFA demos are designed to work on standalone boards, and not in concert with a second processor (like on the Arduino platform). That's not to say you can't link up the LUFA functions to the second processor over SPI, I2C, USART or other bus, but the base demos don't work that way currently.

What Darran has done is to get my base Keyboard demo, add on the code needed to read and write the keyboard scan codes/messages from and to the USART and then recompile the demo for the ATMEGA8U2 used on the Arduino. That allows you to then tunnel your keyboard keypresses on the Arduino through the USART into the USB AVR, then through the USB AVR to the host PC.

— Reply to this email directly or view it on GitHub https://github.com/abcminiuser/lufa/issues/30#issuecomment-50254947.