SparkFun Forums 

Where electronics enthusiasts find answers.

Have questions about a SparkFun product or board? This is the place to be.
By metaforest
#80528
First off this is not an outgrowth of my work on the Audio Recorder Project or the SMD Oven. This is just another idea I have been kicking around.

Recent interest in Arduino related projects and tools have been pretty hot from a hobbyist perspective. Hardware keeps changing, new chips come out, and using a familiar tool chain can save a lot of effort in bringing up a new project. In the software world re-inventing the wheel is expensive and frustrating. More often than not the end result is counter productive, and limits growth into new platforms.

I can see a time not too long from now where pretty much all the major players are going to have cheap and fast 32bit SoCs that don't require ANY high speed parallel interfaces off chip. Most of them already do. The challenge I see for FOSS is to encompass as many of these new platforms as possible with the fewest tools possible. This makes building tool chains much less of an issue than it is now. The AVR crowd has had a lot of success with the Arduino libraries and it's straight forward IDE. Interest in it has been trending up even in this sucky economy. Part of it's WIN is that it's modest in scope and provides a lot of value for very little effort.

Some time ago I stumbled on to a few usenet chat threads that discussed porting Arduino to the PIC. At the time the threads were written I don't think many people in the PIC communities realized how the Arduino system worked and why a simple port of the tool chain might be a lot harder than any one thought. All of those discussions kinda devolved into Inet noise not long after the PIC32 hit the market. I'm not sure why.

So to open the discussion I'd like to share some insights about how Arduino works for those of you who don't know, and outline a possible approach to porting the tool-chain to PIC18 and PIC32MX platforms.

Arduino under the hood/bonnet:

The core of Arduino is a GCC based cross-compiler that has been built using a custom libc, libm and crtl.0. For those that don't really know how GCC works these three libraries are critical for getting C code to run. While you can get by without much of the high-level stuff in these libraries there is some of it that is just not possible to do without. Also, a lot of higher level libraries we know and love in C are written in a way that makes them easy to recompile once libc and libm have been ported to a platform. Arduino is built on this premise.

To summarize the tool chain we have:

Arduino IDE <--> avr-gcc(avr-libc) --> Firmware Programming Tool <---> AVR Target Platform

The Arduino IDE is little more than a Java based text editor with some hooks in it to call avr-gcc and process the error messages that gcc might spit back. Porting it to Mac OS, Linux, and Windows was done a long time ago, and there's nothing in the tool chain that is host specific. Damn good job. The entire tool chain is FOSS and is distributed as binaries. Source code is easy to get, and I think a lot of people are modding this code base. Even for people who don't like the Arduino IDE, using your own IDE over the top, such as Eclipse or even XCode is not much of a stretch. The real power of Arduino is the libraries, not the IDE.

Ok so what about the compiler part?

The gcc compiler support for AVR has been mature for quite some time, and most of the variants are fully supported and optimized. On the PIC side it's not such a clear picture:

For PIC18 platforms there is SDCC which I have been using in my projects and that is mature enough to support a PICduino Port. And here the two efforts dovetail. Arduino IDE doesn't really care what compiler it calls. The build command is just a constant in the Java code, and there is a small chunk of code that monitors the compiler output for errors, and feeds that back to the editor. The real meat is the libraries.

The big question mark comes for the PIC32MX. However, there is a lot of evidence that this is largely a clerical exercise that no one has taken up yet. The PIC32MX is based on a MIPS core (M4K) and I have found that there is mature support for this instruction set in gcc. However, no one has ported any libraries suitable for embedded use yet, except the commercial compiler developers. MIPS and Microchip did port, and release a hacked up version of gcc to the PIC32MX. They deliberately hobbled the source. Building it requires proprietary chunks that you can only get from Microchip, and cannot be bundled with the FOSS portion of the compiler. However an experienced and clever monkey CAN build a personal tool chain with some pain and get a working compiler, then sell that code embedded into a PIC.... no issues there. Providing a easy to use tool-chain that you can just download and click-install is out the window, and forget trying to build an Arduino port around it .... it loses the whole point of why Arduino is so popular.... it's easy for a kid to set up and use without getting bogged in the arcane mess that is building a cross-gcc compiler. Read: Lots of ugly sheet metal cuts in that build process.

Ok so why the hacked up version of gcc from MIPS/Microchip? Is there something wrong with the FOSS MIPS M4K code generator that makes it unsuitable for use with the PIC32MX? The short answer is no, I do not believe so.

The longer answer is: I think a key reason for the hack is to delay widespread availability of competing FOSS IDE tools for the PICs without looking like it. Microchip and it's partners don't want to bite the hobbyist market, but they don't want commercial customers to bypass their tool-chain and dev platform products. Heck the Microchip IDE is free.... unless you want a C compiler. Then it gets kind of expensive (for a hobbyist)... and you are locked into their development products. Ok good show for their business model. Personally I don't like their tool chain that much, even though I use it for the back-end of mine right now.

A key element of the MIPS work on the GCC port was adding Procedural Abstraction (PA) to the pre-link and link layer of GCC, and developing a proprietary ctrl.0 library to enforce code-size limits on students and free-ware users of the MPLAB IDE C products. I don't see PA to be a show stopper at the long end of the tail that we all play in. (P.A. reduces executable/memeory footprint size by up to 30% -- not a show stopper for Hobbyists and small run solution developers) If PA becomes an important issue I am sure later versions of GCC will get PA support. I'm not gonna hold my breath. PA is only really useful for embedded platforms, and MIPS M4K support for it is not likely to show up as a priority.


Ok back to the FOSS side of the fence:

The real promise of an Arduino port to PIC is that sketches build for AVRs could run UNCHANGED on any supported platform that has a similar I/O ring.

So how might this be done?

The key, it turns out, is porting avr-libc to PIC. Most of the key chunks to do this already exist in SDCC for the PIC18. This is largely a clerical process not an engineering process. But it's still a lot of work. The next level would be porting the Arduino Core library and bootloader to the PIC, and this might involve a bit of engineering to keep the HAL functionally identical at the Sketch level. This is a lot of work as well, but not nearly as bad as starting over with a new library with no high-level user base.

For the PIC32MX it's a little more involved, since there are no machine specific FOSS header files for the PIC32MX devices yet, but this is a clerical issue of producing these header files... not many variants of the chip yet. Again looking at SDCC's PIC18 libc headers and and AVR-libc for guidance makes this much easier to do. The most difficult part will be porting ctrl.0 and the Arduino libraries to the PIC32MX, since this has to set up the machine context, and for this relatively new machine, there's not a lot of guidance on what needs to happen, since I have only just started digging into the guts of the PIC32MX. So for this part I'm hand-waving.

Building a cross-GCC for the PIC32 is not that big a deal... I'm planning to do a test build to see if I can get the linux libc to work for M4K code, and check it's output. I see no sense in messing with Microchip/MIPS poisoned sudo-FOSS implementation of C32-gcc, but for those that want a gcc based tool-chain there is a clear path to building one through that code base. If anyone here is interested I can point you to some links that outline the process. Another good candidate for non-arduino libc implementations is newlibc which would probably be relatively easy to port to PIC32MX, since it was designed to be embedded and platform agnostic.


Ok so this has gotten much longer than I expected.

Questions? comments? Discussion?

Cheers
By theatrus
#80529
GNU libc would be the wrong choice - its not targeted for embedded applications.

Take a look at newlib, which is capable of running without an OS, and is commonly used as the libc for bare-metal ARM.

I don't know the extent of machine code compatibility with PIC32 and actual M4K, but hopefully its close enough. Sadly LLVM doesn't have a MIPS backend (who uses MIPS these days? ;)) so thats not an option.
By metaforest
#80530
theatrus wrote:GNU libc would be the wrong choice - its not targeted for embedded applications.

Take a look at newlib, which is capable of running without an OS, and is commonly used as the libc for bare-metal ARM.

I don't know the extent of machine code compatibility with PIC32 and actual M4K, but hopefully its close enough. Sadly LLVM doesn't have a MIPS backend (who uses MIPS these days? ;)) so thats not an option.
The main reason for building a x-gcc with the gnulib is just seeing if it looks like it generates correct code. I don't intend to use it that way. So far I have found no indication that anyone has built the vanilla MIPs port and used it to generate M4K code. I don't even have a PIC32 dev board.... yet :)

The main point of this thread is to discuss the feasibility of building a distributable PIC port of Ardino, and that has to start with knowing that the base gcc will generate correct code. There's no point in porting newlib or anything else if mips-gcc doesn't going to support PIC32 out of the box.


Cheers,
By Fishwaldo
#80570
Interesting topic....

I'd like to point out a few things:

the claim that Microchip are "hiding" the changes they made to GCC to support PIC32 isn't correct. The changes made are to support the tiny differences between a standard MIPS core and the Microchip core... (I think the GCC makes a assumption that the MIPS core is a fully blown core, not a embedded core)

You can get a "FOSS" copy of the PIC32 GCC at sourceforge, released, ironically, by a microchip employee (Jasonk on the microchip forums)!
http://sourceforge.net/projects/microchipopen/ & http://www.microchip.com/forums/tm.aspx?m=410342
There is no size limitations etc in this code... See this commit for proof: http://microchipopen.svn.sourceforge.ne ... evision=10

As for the glibc, I looked at it, and its way to big for PIC32, plus, its a lot of work to port it for a embedded platform where you don't have a underlying OS to run apps on!

I started work on porting newlib to PIC32, and I succeeded with a few caveats:
Some of the machine specific header files you mention need to be taken from the Microchip C32 distribution. These header files don't have any copyright or licenses attached to them, so their availability is questionable. I did contact JasonK via the Microchip boards, who put me in touch with his boss, who then went off to their legal dept to get some clarifications on the licenses (some are very similar to the MIPS-SDE (GCC Port), released, by MIPS, for the MIPS platform, under a GPL license). Unfortunately, I never got a reply on that front, but then I never followed up either

crt0.S is also required, but re-writting that is straight forward and simple, I was just lazy and wanted to test out my newlib port first!

re-writing those header files should be straight forward, and then can be bundled with the newlib port no problem (I didn't do it as I was not aware of their license. The header files I believe are really just macro's giving nice names to registers etc on the PIC32 etc. Nothing extremely complicated there)

I did some very basic testing with newlib code. It includes libc and libm, and worked, although slightly bigger code size than using the standard C32 libs.. It generally worked ok except for the exception handling code (I think my vectors are all messed up etc)

Anyway, you can checkout my newlib port via SVN at http://svn.neostats.net/svn/pic32-newlib/Trunk/ and read the readme file (outdated though, should get you going)

I'd also probably contact the JasonK from the microchips forums, and rope him in. He is very interested in building a FOSS community around the PIC32 and seems to have the blessing of his bosses at Microchip!

I'm also willing to chip in here and there, but my free time is limited, so I couldn't take up any major role in this as much as I would love too.
By metaforest
#80578
I did a little exploratory work on getting the gcc mainline up as an x-gcc for M4K but I ran into a bunch of unexpected dependancies. I might back up to an earlier version to avoid the headaches. I haven't even looked into what other release I should be looking at.

I have a bit of experience building x-gcc compilers: I built a correct x-gcc3.1 with glibc, gdb and the mcore-sim. Started getting my head around a newlib port, but I didn't get much beyond that. Mcore kinda died off in the market.... so I gave up.

I did a lot more research over the day and concur with your points about C32 vs gcc-mips-m4k. I found that someone at mchip was working to get changes into the main-line gcc late last year to support the PIC32. I don't know if those changes made it yet. The hang up appeared hinged on changes to support 'naked' exception handlers. Guess the gcc maintainers don't go to those kind of parties any more. Odd thing is the AVR port has the feature. *shrug*

What I don't know is if the rest of the proposed changes got through. From what I could tell a lot of those were instruction scheduling and register allocation changes... but to be honest I know hardly anything about that end of gcc.

What I am fairly sure of is that just building for mips-gcc and selecting m4k as the cpu type probably wont cut it... maybe it would work, but I just don't know.

On the other hand. The only issue at this point I have with the C32 code base is that it doesn't appear to have any support for c++. And the source tree for C32 doesn't look anything like gcc anymore so I don't even think the changes could be rolled back into a vanilla 3.4.4 gcc. This is kind of a show stopper for porting Arduino, since they depend on c++ support.

Anyway... I'll take a look at your port work on newlib and see if I can help out. Getting a FOSS libc running is better than nothing at all. :)


Cheers
By tz
#80688
There is one or two problems with a full port. Many sketches make use of constants and other things specific to AVR, even something simple like "PORTB".

The libraries definitely do. Things like interrupt vector interfaces (ISR(..)) also need to be ported or adapted.

There are many variants of the AVR, and all are supported (through a lot of #ifdef and such). But generally they have the same or very close definitions, so uarts, timing, pwm, etc. all work if you use the symbolic names.

But there is also the bootloader and avrdude which are a key part. The IDE doesn't just compile, it will also upload (flash, eeprom, etc. with verify using the bootloader, but avrdude can also use JTAG or ISP).

For there to be a PICudino, you would need to be able to have the rest of this infrastructure, not just be able to create the flashable images.

Also, I don't think you need newlib or even a large portion. From what I've seen, Arduino only has a few select calls (things like string, but not file pointers with fprintf/fscanf, etc.). Most are actually unique like Serial.println().
By metaforest
#80707
tz wrote:There is one or two problems with a full port. Many sketches make use of constants and other things specific to AVR, even something simple like "PORTB".

The libraries definitely do. Things like interrupt vector interfaces (ISR(..)) also need to be ported or adapted.

There are many variants of the AVR, and all are supported (through a lot of #ifdef and such). But generally they have the same or very close definitions, so uarts, timing, pwm, etc. all work if you use the symbolic names.

But there is also the bootloader and avrdude which are a key part. The IDE doesn't just compile, it will also upload (flash, eeprom, etc. with verify using the bootloader, but avrdude can also use JTAG or ISP).

For there to be a PICudino, you would need to be able to have the rest of this infrastructure, not just be able to create the flashable images.

Also, I don't think you need newlib or even a large portion. From what I've seen, Arduino only has a few select calls (things like string, but not file pointers with fprintf/fscanf, etc.). Most are actually unique like Serial.println().
Just like C or Java, any other 'portable' language, you can code things that are NOT portable. In the context of my initial comments, getting arbitrary sketches to work from one platform to another would require some kind of work on the source code to make it work.

If you take a look at any large source code suite for ANSI C that claims to be portable, you find countless examples of #ifdef and #ifndef statements bracketing platform specific code. On older project that have been around a while I doubt anyone even knows why some of those code sections are written that way... better just to leave it alone!

So my point is that portability is in the eye of the beholder. If a Arduino user writes code in ways that tends to not care which AVR variant it's running on then the sketch might not care if it's running on a different HAL that follows the same calling conventions.

At this point doing a PIC32 port or any PIC port of Arduino is not really going to work.. the AVR has c++ under gcc.... and Arduino makes use of it. While C++ is kind is quite resource intensive in a lot of cases.... it helps a lot with abstracting the underlying machine.

While some other attempts have been tried via BASIC and what not, the Arduino approach works.... Arduino, as a beginner's dev. environment is hard to beat, and it's one glaring lack at this point is that it's not target agnostic. Though that has little to do with the developers and maintainers of Arduino and it's variants.
By tz
#80710
While some other attempts have been tried via BASIC and what not, the Arduino approach works.... Arduino, as a beginner's dev. environment is hard to beat, and it's one glaring lack at this point is that it's not target agnostic. Though that has little to do with the developers and maintainers of Arduino and it's variants.
First, the "other" attempts were usually windows centric "environments" that were anything but open. So you could use a "free" C or Basic, but it had to be done from within a program that couldn't run on a mac or under Linux. For a long while I was looking at PICs v.s. AVRs v.s. other families of microcontrollers, but most didn't have even gcc or even gas, much less a way to upload code (oh, just use OUR special custom usb device that only has completely proprietary windows drivers).

But the main problem is there is no "embedded' target agnostic library. As I said, libc isn't the problem so much as Analog, Serial, Wire, and the pulse/timing libraries, and do things like enable, disable, and process interrupts, and they have to go directly to hardware or to processor specific sections to do these things. Could they be written to work on a PIC? yes. Would they share much code? no.

You can get some USB devices to do all these things, and it would still be difficult to port Arduino to ordinary PCs even though everything would be there including an OS.

Which brings me back to repeat a final point - upload and test is also part of the process, and avrdude doesn't do PIC processors, and I don't know what the PIC tool uses or requires, but you might be able to do a bootloader for self-programming which is compatible, but I'm also using avrdude over the ISP interface and I doubt that hardware or protocol is the same as PIC.
If you take a look at any large source code suite for ANSI C that claims to be portable, you find countless examples of #ifdef and #ifndef statements bracketing platform specific code. On older project that have been around a while I doubt anyone even knows why some of those code sections are written that way... better just to leave it alone!
I would generally disagree. The main case is the Linux kernel (including the drivers, filesystems, etc.) which moves all the architecture specific stuff to /arch, and includes quite a bit of assembly language, and that is all to get a certain minimum set of functions which are down at the hardware. And they aren't even #ifdef-ed as much as they are in entirely separate directories. But the lowest levels are where the entire Arduino project is, or slightly above it. The drivers and filesystems don't have many #ifdefs for portability.

Most of the "portability" problems come from MS C v.s. GCC or other compilers doing things differently. Case in point are a few things I coded for AVR - GCC and the "commercial" development system has a completely different way to say something is an ISR. They have different ways of enabling/disabling interrupts. So I have #ifdef __GCC__ in several areas.
By ttabbal
#80711
I like the idea. Not sure about Audrino as I haven't used it, but a full FOSS toolchain would be excellent. I'd love to have C++ support as well, even with its issues in embedded systems. Heck, I'd really love Java. :D

For programming, it's not really a problem. Many PICs have self-programming bootloaders available that work over USB or Serial. And the PicKit2 can program just about any PIC and it's fully open source. If you limited your stuff to even just the HID based USB bootloader, you still have devices in the PIC18, 24, and 32 families that are inexpensive and have nice dev boards available like the UBW/UBW32. The backend app might be different, but you could write a version that takes the same command line to make integration with PIC programming easier.

The PICs use similar constructs for the whole lineup for accessing peripherals and ports. So those could be abstracted out into library code without too much hassle. That's basically what MPLAB does anyway. If the library were designed properly, it should be able to talk to AVR and other micros without much hassle as well. If the programmer writes code directly to the processor, there isn't much you can do about that. But if you provide a nice library that has everything they need, you can limit how much of that happens.
By tz
#80713
That is a good point, and one I tried to make although not very well.

1. You need a full FLOSS toolchain. I need to be able to type "make" under linux, windows (cygwin/mingw if necessary), AND MacOSX and be able to get a flashable image. IDEs are nice but are only a front end to this.

2. The last link in the toolchain is programming/upload, and it sounds like that is handled if not completely solved.

3. You need the same set of functionality Arduino provides. This might involve implementing the same library, but equally providing equivalents for each function (Serial.xxx is silly if you are writing over USB which is not a serial port).
By metaforest
#80729
tz wrote:That is a good point, and one I tried to make although not very well.

1. You need a full FLOSS toolchain. I need to be able to type "make" under linux, windows (cygwin/mingw if necessary), AND MacOSX and be able to get a flashable image. IDEs are nice but are only a front end to this.

2. The last link in the toolchain is programming/upload, and it sounds like that is handled if not completely solved.

3. You need the same set of functionality Arduino provides. This might involve implementing the same library, but equally providing equivalents for each function (Serial.xxx is silly if you are writing over USB which is not a serial port).
The point is that the sketch code should not care what hardware device is mapped to Serial.xxx() or through Wire.xxx Currently each AVR platform board generally has it's own implementation of the libraries to deal with hardware dependancies anyway. So from the IDE perspective selecting UBW32 from the target menu would result in the correct version of the libraries, compiler, and programming tool being recorded in the sketch meta-data. The sketch code does not see this difference unless the sketch contains machine specific declarations. If a given board uses USB as the virtual console then Serial.xxx() would map to the USB rather than UART2, or whatever.

Obviously if you are doing something more specialized than a serial port emulation with USB then a fully supported USB OTG stack and abstraction would be required. I don't think this has happened in Arduino yet, and there are licensing issues that might limit FLOSS distribution of the stack. SD card drivers have a similar problem in that the driver level protocol is not an open standard, unless you use the lower performance SPI level interface, and even then distributing code might have legal hassles.

Realistically, there are going to be machine specific dependancies in a sketch. After all we aren't dealing with a full HAL in the SoC space... yet.
The key is to make those dependancies manageable at a high level so a sketch can be #ifdef'd to deal with them.

At the moment Arduino and it's variants are the closest thing to a target independent application execution environment the small SoC space has. I am sure better things will come along. Eventually, I expect we will see full OS kernels as these chips integrate larger RAM and flash resources, further abstracting the hardware layer from the application.
By inventore123
#81129
A C++ compiler for a PIC? I'd definitely be interested :)
By metaforest
#81135
inventore123 wrote:A C++ compiler for a PIC? I'd definitely be interested :)
Well at least for the PIC32mx... I recently traded a few emails with the maintainer of the open source C32 compiler. There are plans to support C++. No time line as of yet.

Doubt the 8 bit PICs could handle it. They barely handle ANSI compliant C. Segmented RAM is the devil. :)
By mpanetta
#81138
The only question I have is why? What would the advantage be to having Arduino code on the PIC18 or PIC32, besides just saying it can be done? The AVR is much faster then the PIC18, and there is a reason that GCC was not ported to it (GCC does not work at all well with register starved banked architectures).

As for the PIC32 chip, I don't know too much about it, so I can't say much there other then why not port to Cortex-M3 instead? Your port would target MANY MANY more chips then a PIC32 port would, esp with the release of the CMSIS docs that bring a sort of potability layer to the various manufacturers CM3 chips (So far I know of TI/Luminary, STMicro, and NXP with CM3 chips, there may be others).

Another reason to go with Cortex-M3 is that ARM supports the Cortex-M3 compiler GCC port through codesourcery, so you never have to worry about the compiler being supported by a company that has other self interests in mind...

So why waste ones time with PIC when a much larger set of 32 bit processors are available in the ARM7/9 and specifically Cortex-M3 architectures?
By metaforest
#81147
mpanetta wrote:The only question I have is why? What would the advantage be to having Arduino code on the PIC18 or PIC32, besides just saying it can be done? The AVR is much faster then the PIC18, and there is a reason that GCC was not ported to it (GCC does not work at all well with register starved banked architectures).

As for the PIC32 chip, I don't know too much about it, so I can't say much there other then why not port to Cortex-M3 instead? Your port would target MANY MANY more chips then a PIC32 port would, esp with the release of the CMSIS docs that bring a sort of potability layer to the various manufacturers CM3 chips (So far I know of TI/Luminary, STMicro, and NXP with CM3 chips, there may be others).

Another reason to go with Cortex-M3 is that ARM supports the Cortex-M3 compiler GCC port through codesourcery, so you never have to worry about the compiler being supported by a company that has other self interests in mind...

So why waste ones time with PIC when a much larger set of 32 bit processors are available in the ARM7/9 and specifically Cortex-M3 architectures?
Arduino is a nice abstraction for SoC platforms. I know a lot about the PICs so I was interested in porting it. Supporting the PIC32 was kind of an after thought, but recently I have been quite interested in developing on it.

Besides: Cortex-m3 based MPUs are slower and more expensive for comparable feature sets. The ARM7 and ARM9 devices don't seem to ever be in stock through my distributors. This is not exactly an encouraging sign for me to invest effort in developing on those platforms, as interesting as they appear. I have no problem getting any PICs of any type from any of my distributors. Yeah the 8-bit's with their segmented memory are a bit of a pain. PIC18 C is well supported on SDCC and has a decent library. There was never a notion in my mind of trying to get C++ running on PIC18 through gcc.

However, I'll note that gcc supports the 68HC11 which has only 1 ALU register and 2 index registers, and a banked 16-bit address architecture that usually had less memory than a typical PIC18 has now. I don't think register availability or address segmentation are the real the issues. I think it more likely that no one with the know-how wanted to struggle with the gcc maintainers over the gory #pragma statements that are desirable to get fine control over the PIC 8-bit architecture.


Microchip released their hacks to the gcc-3.4.4 compiler into FLOSS, and it works. The only thing holding back rolling the PIC32 into the main line gcc is the gcc maintainers. They are holding off the PIC32 specific patches until at least 4.5. The only thing missing from the gcc-3.4.4 port that MChip released is a library. The aforementioned newlib port will fix that. The maintainers of the C32 compiler already have said they'd look into doing some development on the newlib port... so they clearly are interested in a FLOSS tool chain. MIPS already rolled the M4K core changes into the general MIPS port, so it will work, but word is that there are some minor changes that still need to be addresses for MChips implementation.


As for the ST32, and other ST micros...

So port newlib and build a cross-gcc... It's not that much work. You want to use Cortex go for it. There's already generalized ARM support in newlib so most of the hardest part has been done. One only needs to write a suitable crt0.S and fill in the low level routines that would map stdio to a default serial device, and set it up.

Cheers