How to port Arduino to any given microcontroller

Arduino (i.e., the software side) at the moment is mainly implemented on the Atmega328/2560 microcontrollers.

If I would like to port the platform to a given microcontroller (not necessarily Atmel or even 8-bit), how would I get started? In other words, the end-goal being to allow the microcontroller to accept Arduino sketches, libraries, the pin assignment, and so forth.

I understand this is a very general question, given there are thousands of target uC's, however, I would like to know vaguely what the process involves, if anyone has experience with having ventured down this path before. There doesn't seem to be much written about this subject, or perhaps I'm not Googling for the right terms.

(I was inspired to ask upon learning about the RFduino project on Kickstarter, where the creator made a Nordic Semiconductor ARM Cortex-0 chip, nRF51822, Arduino-compatible.)

You would need to create a new “core” (folder structure in “hardware” folder). That would need to contain the compiler (if not installed in the system) and all the core libraries to get it working. Also, the Arduino implementation isn’t very friendly to other microcontrollers beside AVR ones. Lots of horrible things are hard coded.

It’s a lot of work.

You should check out “MPIDE” - the Multi-Platform version of Arduino. It’s used by the chipKIT, and people have also ported other controllers, like the MSP430 from Texas Instruments.

Honestly it does sound like a lot of work, indeed, but I think I am up for this challenge.
I just looked at the hardware/arduino/cores folder and found the various core libraries you mentioned (Arduino.h, Stream.h, etc.)
So, if I understand you correctly, once I rewrite the core libraries and I map the pin numbers to appropriate pins on the target microcontroller (assuming there are enough and with the same compatibility, e.g., interrupt, analog, etc.), that will do it?
What about the bootloader?

majenko:
You would need to create a new "core" (folder structure in "hardware" folder). That would need to contain the compiler (if not installed in the system) and all the core libraries to get it working. Also, the Arduino implementation isn't very friendly to other microcontrollers beside AVR ones. Lots of horrible things are hard coded.

It's a lot of work.

You should check out "MPIDE" - the Multi-Platform version of Arduino. It's used by the chipKIT, and people have also ported other controllers, like the MSP430 from Texas Instruments.

Now that's a whole other ball game.

The Arduino is hard coded to use avrdude, which is fine if you have a microcontroller with a bootloader that avrdude can work with.

If there is no bootloader, or a bootloader that works with a different uploader, then you won't be able to program it with the Arduino IDE. MPIDE has recently added a system to allow the use of other bootloader / programmer systems (I know, because I wrote that bit :wink: ), so you could use a hardware programmer (as long as there is a command-line utility for it) and not have a bootloader at all.

The other option would be to manually program the chip with the generated .hex file. Lotsa hastle.

Neat. I've just now begun to read up more about MPIDE. You guys must have put a major effort into making it cross-compatible.
Is there any "disadvantage" to switching to the the MPIDE variant, i.e., in relation to directly using existent Arduino sketches/libraries, or do they all work without modification?

majenko:
Now that's a whole other ball game.

The Arduino is hard coded to use avrdude, which is fine if you have a microcontroller with a bootloader that avrdude can work with.

If there is no bootloader, or a bootloader that works with a different uploader, then you won't be able to program it with the Arduino IDE. MPIDE has recently added a system to allow the use of other bootloader / programmer systems (I know, because I wrote that bit :wink: ), so you could use a hardware programmer (as long as there is a command-line utility for it) and not have a bootloader at all.

The other option would be to manually program the chip with the generated .hex file. Lotsa hastle.

MPIDE is based on Arduino 0023, but work is in progress to bring it up to date with Arduino 1.0.x

Most of the differences between 0023 and 1.0.x are in the core. I have had some success upgrading the AVR target by just dropping in the avr folder from 1.0.4. The PIC32 target is still lacking in 1.0.x support though.

You should really target your port direct to 1.0.x so as to avoid future complications :wink:

Out of interest, which microcontroller are you thinking of porting to?

Noted. Thanks for sharing your perspective.
As far as which uC: No one in particular, but I've been using the Digikey search/sort feature and when I included some features such as N number of UARTs, or integrated CAN, etc., I come up with some really neat, fairly inexpensive microcontrollers that exist out there (e.g., from Texas Instruments), but it's hard to directly jump into these new uC's for a coder like me with experience only on the Arduino platform (and the various libraries). So I thought I'd pick one and see if I could learn how to use them with Arduino sketches.

majenko:
You should really target your port direct to 1.0.x so as to avoid future complications :wink:
Out of interest, which microcontroller are you thinking of porting to?

Energia is already a TI Launch Pad port of the IDE...

I would create a custom abstraction layer for the programs you write. Write the bulk of your programs code independent of the actual libraries or hardware used. Whenever you need to refer to some hardware aspect you implement a level of indirection/abstraction layer for that.

That way, when you want to port over a program to another platform, you only have to worry about the things you actually use. And the new implementation can use the facilities (libraries) common to the target platform.

You do have to take care with (3rd party) software libraries - they will not be easily ported because they don't know about/use your abstraction layer.

In general a port should only involve writing a few low-level hardware drivers and these should be nicely compartmentalised. I've seen ports where you only has to write a putc() and a getc() and it was off and racing.

In the case of Arduino though I would bet that the code is riddled with hardware-specific code.

I ported a lot of the Arduino stuff to an LPC ARM chip, the process largely involved rewriting most of the standard Arduino API calls.


Rob

Graynomad:
In the case of Arduino though I would bet that the code is riddled with hardware-specific code.


Rob

Not just the core code - the contributed libraries too.