SparkFun Forums 

Where electronics enthusiasts find answers.

Have questions about a SparkFun product or board? This is the place to be.
By busonerd
#81149
I have stock GCC building targeting pic32. I also have [a hacked] GDB working for the pic32 using [a hacked] openocd with flash write support. Programmer tool is the olimex arm-usb-ocd. That tool is hellishly slow at the moment due to USB latency. To fix requires injecting a little code stub into the pic32 to handle tasks onboard without latency. For GCC/GDB/binutils I used the mipsle target. I did not use any libc, my application didn't need one. I just rolled my own startup code. IIRC the gdb hacks were to hack how openocd presented its memory map. GDB uses a 64 bit # to hold addresses, and the mips target in GDB sign extends all addresses. OpenOCD does not sign extend said addresses when passing to GDB. This also means that a contiguous memory space going through 0x80000000 needs to be split into two chunks.

I'm on a business trip at the moment and don't have any of my hacked sources with me, nor build procedures. I'll get em up at some point.

I also have an auto-generated SFR library file / reg defs header from a microchip file that looked as if it was licensed in such a way as to allow usage without a compiler license. I also autogenerated dwarf info for the library file [just contains absolute value symbols for SFRs] so in gdb you can just go p SFR_NAME.

Also - never set the DEBUG bits in the config words if using JTAG. They make weird stuff happen. Said weird stuff is documented nowhere. Specifically, they cause the processor to reset to an as-yet undetermined address, rather than the regular reset vector. This weirdness does not occur on a jtag-initiated reset, nor one initiated via the external reset. Only power-up. That was a fun one to try and figure out [chip works perfectly under debug, never without debugger attached].

RE: all that; in summary, it works, but there is great frustration to be encountered outside the microchip libraries, as things do not work as they are documented in the datasheet. There are a few key registers actually missing from the datasheet!

Cheers,

--David Carne
By metaforest
#81151
busonerd wrote:

RE: all that; in summary, it works, but there is great frustration to be encountered outside the microchip libraries, as things do not work as they are documented in the datasheet. There are a few key registers actually missing from the datasheet!
I'd be curious to know what is missing from the datasheet, when you have time. Also what config options you used to build GCC for PIC32.

Cheers
By busonerd
#81153
Off the top of my head; the register that lets you unlock the PLL config register is mentioned only indirectly in the unlock sequence. Its not mentioned in any of the memory maps in the datasheet. This may have changed if they got a new datasheet out. Haven't checked for ~3 weeks.

My build procedure was very similar to the build script given by the open pic32 cc sources. All stock sources [had to select versions + add a few patches]. Only major script change was --target=mipsle . Again, this is all off the top of my head; don't have any of the files here with me.
By mpanetta
#81154
metaforest wrote:
Besides: Cortex-m3 based MPUs are slower and more expensive for comparable feature sets.
Slower and more expensive then what? The PIC18? Cortex-M3 is one of the fastest MIPS/Watt core you can get in this space, so what exactly is it slower then?

When I was looking at prices for Cortex-M3 chips VS PIC32 the PIC32 always seemed to be more expensive, using the prices on microchips web site. For instance I can get an STM32 based Cortex-M3 part with 128K flash and 20K ram for $6.04 in singles from Avnet express (STM32F103VBH6). The closest part from Microchip is the PIC32MX340F128L-80I/PT and its $6.11.

I will admit that things seem a little cheaper with the PIC32 now vs when I looked 8 months ago, but that's only one offering, there are many others by many other vendors that may be cheaper.

metaforest wrote:
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.
Where are you that you can't find any chips in stock? The chip I mentioned above has over 1K in stock. A quick look on some other parts shows hundreds of ARM9's in stock at various distributors and the same goes for ARM7 parts. Besides that, having something in stock is not as important as what the lead times to get parts are when the stock is exhausted.
metaforest wrote:
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.
Ahh yes! I forgot about that port! They had to do some interesting tricks, like create 32 virtual registers to get that port to work. I have used it before, its neat, but not the most efficient compiler for 68HC11.
metaforest wrote: 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.
Yes, but are they interested enough? It seems to me that they only did it to avoid a lawsuit if what you told me about making GCC generate limited code due to flags having to pay for a license etc is true. On the other hand, ARM is *PAYING* Codesourcery to maintain the Cortex-M3 port of GCC, a fully open source endeavor that produces a new updated compiler every 6 months. Can you say the same for the PIC32?
metaforest wrote: 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
Its not just ST, its ST, TI, NXP, and Atmel at the least. All of the processors by all of those vendors can use the same low level C runtime and interrupt drivers, and to some extent generic IO drivers. That's a *HUGE* number of possible CPUs that get support from one code base. That also means that if NXP or Atmel up and die, you can take your code to another vendors Cortex-M3 part and get it running with a minimum of effort, since all the tools and low level code are the same.

As for newlib, its already been done. Take a look at the eLUA project. The only thing that needs to be done (I assume??) would be to port whatever libraries the Arduino stuff depends on.
By inventore123
#81179
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. Smile
Sure, I was talking about the PIC32. The 8bit PICs banked architecture and lack of GCC support is why some years ago I moved to AVRs.
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?
Well, in fact now I'm just making the transition from ARM7 to Cortex M3. I agree, even in my opinion they are better than PIC32s, and they even already support C++ and its standard library (Just like any ARM CPU, including the ARM7).

Anyway, even if I'm not planning to move to PIC32s, knowing that they will support C++ is cool in my opinion, since nearly all other architectures already support it: AVR 8bit, AVR32, ARM, etc.
By annualoption
#200573
Fishwaldo wrote: Tue Sep 08, 2009 8:50 pm 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.
Thanks for the link.