Go Down

Topic: Adding a custom board to the IDE (Read 2520 times) previous topic - next topic

qwertymodo

Has anybody created a guide for adding a custom board to the Arduino IDE?  I understand a lot of what is involved from looking through the packages provided for boards like the SparkFun Pro Micro, so I'm not looking for hand-holding here, the actual code I understand well enough, I just don't know quite all of what is involved in getting the IDE to properly recognize the new board definition, so I'm looking for more of a checklist of the required components.  From what I can gather, the required files are:

[ArduinoDir]\hardware\[PackageName]\boards.txt
[ArduinoDir]\hardware\[PackageName]\cores\arduino\*** (Arduino core files, modified for the specific board)
[ArduinoDir]\hardware\[PackageName]\variants\[VariantName]\pins_arduino.h

Also, the boards.txt file seems to be pretty powerful, the Teensyduino package takes advantage of this to do things like adding custom sub-menus to the Tools menu, and using the external Teensy uploader application.  Is there a good, in-depth guide to the more advanced features of boards.txt?  All of the guides I've seen have just glossed over the basics.  I'll be using one of the USB Atmegas, is there any way to get the Arduino IDE to program them via DFU?  Does AVRDude support DFU?  Otherwise, I'll have to figure out how to get the Arduino IDE to program via the FLIP command-line app (batchisp.exe, IIRC...), in a similar fashion to how Teensyduino programs via the Teensy loader.

oric_dan

I'm not at all an expert on this, but did it for my own ATmega1284 board which has a pinout slightly different from the other 4 or 5 extant 1284 board variants. I would recommend finding a board as close as possible to your own board - ie, same cpu and general pinout - and then use that as a template to figure out how to make changes to the boards.txt and pins_arduino.h files. This shouldn't be too difficult to do. Plus you learn a lot in testing your changes.

Notice that, normally the different variants will use the same exact bootloader.hex file, and the only thing normally affected are how the chip pins are mapped to the external header Dx,Ax pins in the pins_arduino.h file. Therefore, I could compile a sketch using the "original" variant and test the pin functions, and then recompile using my own variant, and test that the correct pinout changes were made.

bombasticbob

I was looking for a thread on this very topic since I wanted to suggest to the world that THESE! THINGS! NEED! TO! BE! DOCUMENTED!

yes, 'boards.txt' was a very interesting find.  VERY interesting.  I had to look hard to find it.

But even MORE interesting was the sketchbook/libraries directory!  Even THAT had no documentation that I could find.  I ran into it one day because Adafruit suggested I place the custom motor library into "sketchbook/libraries" - and I'm like OH, I can have PRIVATE VERSIONS of the libraries???  WAY COOL!

I joined (then took over) a project recently where the original developer put everything 'custom' into the arduino library directory.  Yuk.  OK I eventually fixed all that but still.  It was the kind of mistake I made early on learning to use the IDE.  So I create a new login, and copy the appropriate libraries to THAT login's sketchbook/libraries directory.  No problem, it's isolated from other things I'm doing, and I just keep on going.

So if there's nothing ELSE out there already covering "this kind of thing", I might just start something on the Playground.

Most recently I'm working on an XMEGA-based board that started out as an Arduino with wires plugging into breakout boards.  From there it became a prototype circuit board with an ATmega328 (no 'p') chip.  Now moving to an xmega I discover just how incompatible the xmega is with the existing libraries, so I'm in the process of  a) fixing avr-gcc, avr-binutils, and avr-libc [99% done for FreeBSD, not so well on Ubuntu] because they don't have support for atxmega64d4 [which is inexpensive from places like DIgikey], b) figuring out how to flash it with avrdude [which also has a few bugs, even with the avrispmkII, like killing the bootloader area when I write to 'flash' space], and most fun of all, c) re-writing things like the Wire library.  Naturally I put the 'XmegaWire' library into sketchbook/libraries because it's my "private" version.  And that didn't include creating/adapting the 'cores/xmega' and 'variants/xmega' trees, which I'm occasionally tweeking to fix bugs.

(but KUDOS to the Arduino developers for making this POSSIBLE in the FIRST place - you saved me from having to modify the base - but you FORGOT! TO! DOCUMENT! IT!)

I'm also adapting the arduino bootloader for flashing via the PORTD serial device.  Bootloader ok, still needs "write to NVRAM" code.

Worth pointing out, the xmega's need special startup code to set up the system clock.  They boot at 2Mhz but have an internal 32Mhz clock as well.  There's a specific sequence you have to use to write certain registers, also.  I simply copied the hardware/arduino/cores/arduino directory to hardware/arduino/cores/xmega  and similarly for 'variants', and started updating things.  Everything (so far) works fine, except I'm having some difficulty porting Wire [it's just not intuitively obvious, that's all].

Anyway, all that makes it possible to use original Arduino code on this new device with an xmega.  So the IDE _CAN_ do it.  but the documentation on HOW to do it is sparse, the arduino java code has too many 'cryptic' levels in it, is non-obvious as to what files contain what info, etc. etc. etc. like it was written by a java geek for java geeks, using too much "object-orientedness" to be able to follow it [unless you REALLY LIKE jamming through multiple files just to find out what gets stored in a particular object's member thingy, and probably as a obscurely named collection, grrrrr] so yeah.  DOCUMENTATION!

it's too early/late in the AM hours to write coherently, so sorry if this seems to ramble.  porting Wire and TWI is making my brain hurt.

I'd really like to contribute what I've done, once it's in a "contributable" form.  The AVR-GCC stuff is a no-brainer, adding FULL support for all of the atxmega64d4 features (not just TWI on port C, but E as well, for example) and of course the all-important STARTUP CODE that sets up the system clock and auto-calibration feature, interrupt handling, TIMERS [works JUST LIKE the atmega including millis() and micros()], HardwareSerial (2 USART's), special pin modes like "INPUT_PULLDOWN" and the open drain OUTPUT configurations (with or without internal pullup/down) and so on.  And async interrupts for pin 2 on every port, and 'change' interrupts on every pin.  Yeah, xmega has a LOT of really cool features, if you don't mind 3.3v, and having all of the port/pins different.

I've found a few xmega boards out there.  Not many, though.  Some use the 'duino' suffix (which I think is verboten).  But support for this is still pretty light.  Maybe if I can contribute my xmega code it will change?  With the Due being 3.3v also [and a tad incompatible at this point] there may be more reason to have xmega hardware on an official Arduino board anyway.


ismael33

Hi all

somebody know how install the ino2cpp on arduino ?
I need this tool to install a board Momote developed in the company DASCOISAS
on IDE ARDUINO.

pert

Hi all

somebody know how install the ino2cpp on arduino ?
I need this tool to install a board Momote developed in the company DASCOISAS
on IDE ARDUINO.
Don't threadjack! Search for a relevant thread to post on and if none exists create a new topic. If you want help with this you should actually provide us with some information of what ino2cpp is and post links to where this tool can be found and the boards files for the "Momote".

Go Up