there seems to be a lot of confusion surrounding the status of the gcc compiler for PIC32. I'd like to see a definitive and clear statement of exactly what is and isn't "free open source" about the development environment. At some level, you have "just" a MIPS gcc compiler, which has been fully open source for years (although perhaps not this particular "embedded" MIPS core.) Then there is rumored "improved global optimization" or something. Then there are added libraries and/or include files and/or linker scripts that are pretty much "necessary" for basic access to chip registers and such; the things that allow you to refer to peripheral addresses and bitnames from the datasheet in your C programs. Then there is whatever passes for "libc support" for PIC32 (in AVR land, this is a separately maintained open source avr-libc, but it would be possible for this to be closed source or separately licensed, especially if it is extended to include functions for manipulating all of the on-chip peripherals (like the "stellarisware" ARM libraries from TI?) And then there are the various value-added stacks that come with known restrictions (TCP stack, USB stack, etc?)
I have mixed feelings. A "restrictive" license on intermediate level libraries ("you can only use the Microchip chip-register libraries for accessing registers of Microchip chips") hardly seems very limiting. But higher-level library restrictions may cause proliferation of non-portable APIs, which is not a good thing. And the compiler itself really needs clarification.
Note that it would be possible for a build environment to be "Arduino compatible" without including quite a lot of libc and higher-level functionality. I've already noticed that the uno32 libc environment is different than avr-libc, for example...
(The existing license agreement seems to say "everything is as proprietary as we can make it except for the things we can't make proprietary", while putting the onus of figuring out which is which on the would-be modifier. That's ... not really very helpful.)
(I don't see the PIC32 MIPS based architecture being THAT dissimilar from the ARM situation. Even in ARM-land there are a bunch of vendors offering proprietary or semi-proprietary "enhanced gcc" environments. The main difference is that the large number of ARM vendors helps to clarify which pieces have which licenses...)
I have a desire to see a "smart" ethernet interface, capable of replacing (for example) Wiznet modules, but having the ability to be user-programmed. A likely solution would have a microchip ethernet controller connected by SPI to a PIC24-class CPU, with another SPI interface to connect to the host system. TCP/IP implemented on the PIC24, and a sort of "sockets over SPI" software interface to the host. Ideally, this module would be SW compatible with an SPI-connected Wiznet module, but exact compatibility is less important than implementing a similar complexity of capability.
This is in fact very similar to several of your existing boards that include microchip ethernet and PIC24 chips, including several of the "stalled" projects. In fact, software-wise it could probably be prototyped on one of those boards...
However, like you I am less than enthusiastic about the restrictions imposed by the Microchip TCP stack. What is the status of alternate TCP/IP implementations for PIC24? I see there was some traffic last year about uIP on the web server board; was that actually "finished" ?
