Ardunio Fork LeoPhi- custom Arduino IDE build

Ardunio Fork LeoPhi- custom Arduino IDE build

Project description

A brief writeup on some of the pitfalls I encountered when I created a Leonardo derivative board (LeoPhi) and had to build a custom Arduino IDE. hopefully this will help those working on their own boards. In the end I needed to fork the Arduino source and create a version for my boards. see this post.

[repo path=”SparkysWidgets/WinArdBuild”] [repo path=”SparkysWidgets/OSXArdBuild”]

When word of the Leonardo broke and the first signs of the Caterina bootloader showed up I decided to look at the Atmega32u4 as a candidate to replace the atmega168 on my original pH interface with microcontroller. I had received a lot of input suggesting that people were using it for more than just a normal pH interface (Well duh that was the main driving force) but people wanted easier programming and more memory. I entertained the notion of just mounting a 328 on there and in fact did just that for a brief time. About this time I had notice the shift in Arduino to support the 32u4. This was perfect, I would shift the design to use this uC and use the support built in around it.

At first the transition to the new chip was fairly painless I adjusted some of the pins since the form factor was completely different, from a hardware standpoint there hasn’t been too many troubles (Damn you pfet, I’ll get you :). The first problems started to crop up when I needed to implement different VID and PIDs then Arduino’s. In prototyping I wasn’t too bothered by using their VID and PID, but in production I wanted to use my own. Problem number one was that I don’t have the money to pay the USB-IF for a VID, searching for various solutions popped up a few places that proved PIDs Openmoko was fortunately one of them.

Enter Openmoko, who saved the day by opening up a chunk of their PIDs for open source projects and I grabbed one for LeoPhi. Since I didn’t want to step on anyones toes this meant I needed to recompile the bootloader, and allowed me to setup up a separate Leonardo board type in Arduino without too much trouble. I found a few troubles in updating the bootloader to work with the IDE, these mainly consisted of adding in the proper strings (see this forums post). Everything was fine for the 1.0.1 build and worked really well in Linux and OSX. Besides users having to add a few files setup wasn’t too difficult.

I first started noticing problems when 1.0.2 just hit, unfortunately LeoPhi wouldn’t take uploads and in Windows it would reset and show Leonardo in device manager. When reset it would show up as LeoPhi but once again wouldn’t take uploads. I Started digging a bit more into it and discovered that the way Leonardo boards was reset, and a change in AvrDudeUploader.java was made. It took me quite a while to figure that last past out, and I was chasing ghosts in the bootloader and various aspects of how Leonardo works vs a standard UNO.

After narrowing the real root of the problem, it was just a matter of adding a few lines so that a proper reset could be passed down to LeoPhi. Days of frustration and confusion was solved with just a couple lines of code 🙂 Unfortunately this meant that I needed to fork, change, build and distribute a different version of Arduino to make it easy for users of LeoPhi to use fully.

Well after getting everything else sorted I noticed that the PWM and oversampling routines conflicted (used the same timers). One last hurdle to overcome.