PIC32 evolution

[asgard20032]

First, I assume the PIC32MX work fine right? I don't remember to read anything bad about the PIC32MX. Also, yeah, I agree that going arm cortex is a better choice because to the ecosystem. So not the time to start to talk about arm, I already embrace the arm idea. But it can happen some project where I am forced to go with PIC because of the other people on the project knowing nothing else, and don't wanna switch.

But well, lets get back on the main topic. I am trying to figure out how the PIC32 evolved, and when it became stable. For example, wikipedia say : "In September 2015, Microchip updated the MIPS core of the PIC32MZ to the MIPS M5150 Warrior M-class processor." When did that happen (which generation of PIC32MZ)? When I go to the microchip website, I see many different generation of PIC32MZ : PIC32MZ....EFE, PIC32MZ....EFK, PIC32MZ....EFF, PIC32MZ....ECG, PIC32MZ....ECM, PIC32MZ....ECE, PIC32MZ....EFH, PIC32MZ....EFM...

In which order  they came, then did they correct X bug? which one is considered the stable one? Is the most stable/bugfree PIC32MZ hold up against PIC32MX?

[JPortici]

Each family has its peculiarities so you should aim to choose the one you need

check the errata and see if that line of chips can work for you or if it's a no-no
check the errata to see if this or that bug is corrected. it doesn't have to have anything to do with age

[Sal Ammoniac]

The PIC32MX has errata, but nothing too significant at this point. It's a mature line.

The MX line came first, followed by the MZ line. The MZ first appeared about two years ago and was a very flawed chip with an errata sheet as long as your arm (no pun intended). Microchip chipped away at these errata and the EF iteration came out about a year ago which not only fixed many of the errata that plagued the earlier EC part, but added functionality such as a floating point unit. The EF still has some significant errata, but at least it's usable in its current form.

At this point I'd say that the MZ parts are not as stable as the MX parts, The MX parts have been around longer and Microchip has had more time to fix the errata.

[hans]

There are only 2 generations of PIC32MZ: EC and EF. Third letter are expansions to include CAN bus and crypto on the top of my head.
I also believe the DA is unofficially announced which will be a chip targeted for high RAM applications or running embedded linux, because it will contain embedded SDRAM.

EC was the first PIC32MZ series, which plagued by errata bugs above average. Now that doesn't necessarily have to be a showstopper, as all micro's will have some errata to varying degree. Some bugs can have decent workarounds or be of no importance at all. I would recommended not assuming the application of errata's across multiple families, heck.. maybe not within a particular family of chips (e.g. different package). I've seen stuff like "Ethernet: on 64-pin devices, pins used with MII cannot be used even when controller is set to RMII mode", which is trap when you think the project turned out to use less GPIO's than assumed and the package is shrunk. Therefore I would always recommended looking up the errata for your specific chip if you are contemplating on using/switching it.

The CPU core in the PIC32MZ is a bit different to PIC32MX, because of the higher clock. Similar to ARM Cortex m7; these CPU's have instruction and data caches to allow these high clock speeds.
Similarly, I believe you can also use an external SQI chip to integrate into memory space and run large images (e.g. Linux) from it. I'm not sure of the penalty hit when you do so, but I imagine it wouldn't be as high because of the caches.

[JPortici]

http://www.microchip.com/design-centers/32-bit

bottom of the page, click on documents tab. you have the datasheets of each family, the errata etc

[mikeselectricstuff]

The new 32MM looks interesting - very low cost, and a different approach to I/O pin mapping :

PIC24F : any peripheral to any RP pin

PIC32MX and MZ : each peripheral has a subset of pins it can map to. Pin allocation can get quite involved if you need many of the peripherals.

PIC32MM : One of typically 2 instances of a peripheral (UART SPI etc.) has fixed pin mapping, one is mappable to any RP pin. Probably a more flexible approach.

A quick skim of the errata didn't show much of any concern, but it's early days. Pinout, at least of the 28 pin one I looked at today,  is reasonably compatible with the 32MX1xx, so you can design in a 32MX1xx as a fallback, if you don't need all peripherals and all pins.
 It's a while since I read the data, but ISTR reading they'd included an interrupt shadow register bank, which was an annoying omisison on the 32MX1xx as it increased interrupt latency significantly. 

[Sal Ammoniac]

PIC32MX and MZ : each peripheral has a subset of pins it can map to. Pin allocation can get quite involved if you need many of the peripherals.

The PIC32MX5XX/6XX/7XX series do not support Peripheral Pin Select.

[mikeselectricstuff]

PIC32MX and MZ : each peripheral has a subset of pins it can map to. Pin allocation can get quite involved if you need many of the peripherals.

The PIC32MX5XX/6XX/7XX series do not support Peripheral Pin Select.

Sorry I was referring to the 32MX1xx/2xx which are the only ones I know.

[hans]

The PIC32MX3x0 and PIC32MX4x0 where x is an uneven number (e.g. PIC32MX470F512H) also contain PPS. They also contain a 120MHz MIPS CPU on 0-70C, which is faster than the PIC32MX5xx, 6xx and 7xx series. Unfortunately though, these MCU's do not contain any ethernet MAC which 5xx and up series do.

I believe these series micro's were released before PIC32MZ, maybe Microchip had plans to also "upgrade" the higher tiers of PIC32MX, but I am just completely speculating here.

[andersm]

* What's the current story with the cheap / free / good compiler toolchain and sanely usable hardware device programmers for PIC24 / PIC32 these days?

Microchip's toolchains are free with limited optimizations, which is good enough for most users. PIC32s support the MIPS standard EJTAG interface in addition to Microchip's proprietary ones, and there's support for at least some parts in OpenOCD.

[mikeselectricstuff]

I've got a very basic and related question coming from someone who has never used a PIC32 and very rarely uses older PICs.

From a "let's play with this technology just because it is different in nicer ways than something else" standpoint,
* Is there any point to invest in using the older PICs new hobbyist purposes if I care nothing much about part cost / size?  Are the capabilities and peripherals on the new PIC32s basically "supersets" of the capabilities of the PIC24/18/16 parts enough that I wouldn't be missing much useful technologically to focus future experimentation mostly on PIC32?  I'm aware they may not be exactly code / function compatible, but a UART is a UART, a timer is a timer, I2C is I2C, etc.  So unless some of the old PICs have something that is wonderfully BETTER than the PIC32 I might as well not do much more personally with the old parts.

There are still reasons to use 8 & 16 bit parts. Small size, 5V operation, lowest power ( active and sleep),  simplicity and wider availability in DIP ( 40 pin in particular - 16/32 bit parts only have 28 pin in DIP).
Also depends what you mean by "invest". The programmers and IDE are the same and there is a lot of commmonality in the peripherals, so moving between parts is much easier than most other manufacturers.
If you can use PIC32, the others are pretty trivial to get running with.
[/quote]
* Similarly other than the obviously more capable 32 bit MIPS CPU core with modern capabilities what are the great reasons to care about PIC32 when the world is a sea of ARM CORTEX-M4F/M4/M3/M0+ parts with all kinds of CPU capabilities and peripherals.  Why would I want to spend money and time on PIC32 model XYZ today because there is some gem of a feature that ARM C-M doesn't give me?  Not higher speed.  I assume not lower power.  I assume not lower cost.  So.... what's compelling if not cost and code / tool / architecture familiarity & compatibility reasons?
[/quote]
The core just doesn't matter. It's all about the peripherals.

* What's the current story with the cheap / free / good compiler toolchain and sanely usable hardware device programmers for PIC24 / PIC32 these days?  I've always recalled that PIC had "special" tools (SW, programmer) that weren't compatible with basically anything else.

The free compilers for PIC24 and PIC32 with -o1 optimisation are perfectly useable and unless you're really trying to squeeze  size or speed to the absolute maximum I don't think you'd need to buy the paid-for version.
The free version of XC8 is pretty sucky in terms of size and speed, but still useable on all but the tiniest parts.
PICkit3 is a cheap and reliable programmer/debugger for all devices, and there are plenty of cheap clones out there which IME work just fine. An advantage of using this is that new parts are guaranteed to be supported as soon as they are available.

Seems like I've even heard that the new PIC toolchain/environment might be widely hated ()

This is probably the Harmony stuff - this is not the IDE but a framework of libraries for higher level stuff like USB, Ethernet, Graphics, filesystem etc. I've not used it so can't comment, but it's been around a while now so may well be better than it was when it was initially released. You don't need to use it unless you want to use this functionality. If you _just_ want USB, or graphics, or SD filesystem, there is still the old "library for applications" which are more standalone and supplied with full source code, but messier if you want to use more than one library.

I only recently started with MPLABX when I needed to use a new 32MZ part, & it seems perfectly OK - ISTR it had a lot of issues early on.  I still use MPLAB 8.91 for older stuff just because I'm more familiar with it - the only issue is that you need to switch drivers for programmers, but they provide a utility to do this fairly painlessly.
 

[jesuscf]

Microchip's toolchains are free with limited optimizations, which is good enough for most users. PIC32s support the MIPS standard EJTAG interface in addition to Microchip's proprietary ones, and there's support for at least some parts in OpenOCD.

Microchip charges a lot for the optimizing compiler for PIC32s (XC32) which is a derivative work from the MIPS port of GCC.   Lots of people, which whom I agree, had questioned the morality of such charges.  Granted, Microchip releases XC32's source code for each version, most  probably to comply with the GCC's license.  Unfortunately, Microchip doesn't release the information with the required options/settings to build the compiler successfully.  Nevertheless, several people had managed to build XC32 from sources, at least to the point of re-enabling optimizations.  The optimizing compiler, in particular option -mips16, makes a huge difference in code size.

[westfw]

So why do you even need the microchip compiler?  Isn't there a vanilla gcc that supports MIPS that should work fine when combined with the includes and linker maps and such from the microchip free version?

[SteveyG]

Microchip's toolchains are free with limited optimizations, which is good enough for most users. PIC32s support the MIPS standard EJTAG interface in addition to Microchip's proprietary ones, and there's support for at least some parts in OpenOCD.

Microchip charges a lot for the optimizing compiler for PIC32s (XC32) which is a derivative work from the MIPS port of GCC.   Lots of people, which whom I agree, had questioned the morality of such charges.  Granted, Microchip releases XC32's source code for each version, most  probably to comply with the GCC's license.  Unfortunately, Microchip doesn't release the information with the required options/settings to build the compiler successfully.  Nevertheless, several people had managed to build XC32 from sources, at least to the point of re-enabling optimizations.  The optimizing compiler, in particular option -mips16, makes a huge difference in code size.

It might depend on your usage, but I've had no issues getting free licences from our FAE.

Responding to a question earlier on, PIC24/dsPIC33's are a good compromise between performance and complexity if you're only doing hobby stuff. The learning curve is a little steep on the PIC32s purely because configuration of the devices can be a little complex and the example code is extremely minimal.

I still regularly use devices from all the families though - they all have their place. The price point of the PIC10/12/16's is attractive if you're making something which needs lots of them and you can design some pretty complex stuff on these devices. There does seem to be a trend to be lazy and use powerful MCUs for the simplest tasks. 

[dannyf]

 'Is there any point to invest in using the older PICs new hobbyist purposes if I care nothing much about part cost / size? '

I still use a lot if low end oics because I have an inventory of then, mostly 12f675, 16f684, and 16f886.

Given the choices out there now, it makes no sense to start on the pic.

' Are the capabilities and peripherals on the new PIC32s basically "supersets" of the capabilities of the PIC24/18/16 parts enough that I wouldn't be missing much useful technologically to focus future experimentation mostly on PIC32'

Generally no. There is a high degree of similarity between peripherals for the pic24 and pic32 but the low end pics are simply weird.

[dannyf]

'Why would I want to spend money and time on PIC32 model XYZ today because there is some gem of a feature that ARM C-M doesn't give me?'

To me, the answer is none, other than learning. I tend tobthink the pic32 is on borrowed time, and investing in it is a mistake.

[dannyf]

'What's the current story with the cheap / free / good compiler toolchain and sanely usable hardware device programmers for PIC24 / PIC32 these days? '

My main environment for pic24 is  emblocks plus c30, the prior version of xc16. Extremely happy with that setup.

Sometimes I use mplab but hate its 1980s interface. Not a fan of mplab x.

Not yet supporting puc24 and pic32, mplab xpress is pretty good as well.

[dannyf]

'Lots of people, which whom I agree, had questioned the morality of such charges. '

What's morally questionable to charge for ones labor? I hope none of the people above are working for free.

Philosophically, I think it is morally questionable for people to project their morality onto others.

[dannyf]

You didn't ask this but the recent versions of xc8 compiler do a very good job.

I did extensive benchmarking between the free xc8 (1.12 and later) vs. Picc 9,63 STD and pro. The picc is the last non OCG compiler.

The xc8 in free mode is about somewhere between the STD and pro. So people can whine about it, but end of the day it is as good as a paid commercial grade compiler.

[andersm]

The core just doesn't matter. It's all about the peripherals.

It can matter. You were yourself lamenting the long interrupt latency of the MX1xx/2xx, but mostly it's just reflected in the quality of the available tools.

[mikeselectricstuff]

You didn't ask this but the recent versions of xc8 compiler do a very good job.

I did extensive benchmarking between the free xc8 (1.12 and later) vs. Picc 9,63 STD and pro. The picc is the last non OCG compiler.

The xc8 in free mode is about somewhere between the STD and pro. So people can whine about it, but end of the day it is as good as a paid commercial grade compiler.

Not looked recently as I have the full version, but could be one of those things that sucked badly at first ( and it really did), and nobody has noticed any improvements tat have happenned since.

[SteveyG]

'Why would I want to spend money and time on PIC32 model XYZ today because there is some gem of a feature that ARM C-M doesn't give me?'

To me, the answer is none, other than learning. I tend tobthink the pic32 is on borrowed time, and investing in it is a mistake.

Not a mistake if you ever end up working with them commercially. Microchip's stock control and silicon availability is a huge advantage over just about everyone else and is often enough to sway clients who need long term availability and bonded stock.

[SteveyG]

The core just doesn't matter. It's all about the peripherals.

It can matter. You were yourself lamenting the long interrupt latency of the MX1xx/2xx, but mostly it's just reflected in the quality of the available tools.

I agree with Mike, the core rarely makes any difference. Choice comes down to availability, supply chain and peripherals.

[Howardlong]

The core just doesn't matter. It's all about the peripherals.

It can matter. You were yourself lamenting the long interrupt latency of the MX1xx/2xx, but mostly it's just reflected in the quality of the available tools.

I agree with Mike, the core rarely makes any difference. Choice comes down to availability, supply chain and peripherals.

I'd agree with that too. Strongly biasing your decision to use ARM rather than MIPS because ARM has a significantly larger number of vendors doesn't hold a lot of water. If you think there's much portability between ARMs from different vendors you're in for a rude awakening, the way vendors differentiate themselves is by what value they add on to the part, and that should usually be the primary decision maker, far more so than whether it's MIPS or ARM.

However, if you are looking to use an MZ part, you may well be wanting to use one of the complex peripherals like Eth, USB etc., which pretty much forces you into using Harmony, which is a software framework (aka straitjacket) that demands a very significant amount of effort to become proficient enough to write production code, is not very efficient, and is proprietary to Microchip's PIC32 family only. It also pretty much forces you to use MHC, a code generator that generates buggy code, is very difficult to maintain (yes, you have to edit code that it generates), and breaks its own generated code between releases. Other than that it's great 

The lower end PIC32MX1xx and MX2xx are pretty useful, I've used them a lot, and they're available in DIP if you like prototyping on solderless breadboard.

[hans]

My take on this:

I've got a very basic and related question coming from someone who has never used a PIC32 and very rarely uses older PICs.

From a "let's play with this technology just because it is different in nicer ways than something else" standpoint,
* Is there any point to invest in using the older PICs new hobbyist purposes if I care nothing much about part cost / size?  Are the capabilities and peripherals on the new PIC32s basically "supersets" of the capabilities of the PIC24/18/16 parts enough that I wouldn't be missing much useful technologically to focus future experimentation mostly on PIC32?  I'm aware they may not be exactly code / function compatible, but a UART is a UART, a timer is a timer, I2C is I2C, etc.  So unless some of the old PICs have something that is wonderfully BETTER than the PIC32 I might as well not do much more personally with the old parts.

For hobby I wouldn't consider them. 8-bit PIC core is still usable for a push-a-button-and-then-light-this-LED kind of boards, because PIC12s are in 8-pin packages and those programs may end up with a few hundred lines of code. However at the 14 or 20-pin package size I will grab a PIC24F32KA301 (DIP) or even a 32-bit chip because laziness. Also, more MHz, more memory, more I/O, less frustration about platform limits, better debugging features, etc. The 3 euro I spent extra in the chip, I save in the hours coding and debugging the project.

In terms of peripherals; PIC32MX and PIC24 share very similar peripherals. PIC24 XLP chips are better suitable for low power designs, PIC32 power consumption is fairly high, dsPIC also quite high.

There is some caveats to be expected from a 32-bit architecture, like interrupt latency because of software stack, and for example non-atomic I/O operations.
However, compared to 8-bit PICs the higher clock usually greatly offset the remedies for these problems, so I would expect a 8-bit PIC to be beaten in almost any case by a PIC24 or PIC32.

* Similarly other than the obviously more capable 32 bit MIPS CPU core with modern capabilities what are the great reasons to care about PIC32 when the world is a sea of ARM CORTEX-M4F/M4/M3/M0+ parts with all kinds of CPU capabilities and peripherals.  Why would I want to spend money and time on PIC32 model XYZ today because there is some gem of a feature that ARM C-M doesn't give me?  Not higher speed.  I assume not lower power.  I assume not lower cost.  So.... what's compelling if not cost and code / tool / architecture familiarity & compatibility reasons?

I can't say too much abuot the 32-bit MIPS core. It's a CPU, and it runs code. I write my programs in C, so all I get to see is registers of peripherals, and the platform specific definitions for interrupts and the like.

The peripherals on PIC32MX are wonderfully simple and straight forward to program. Most ARM Cortex chips are beasts with half a dozens of registers to set up clocks and peripheral power. Although programmatically all of these operations are simple to program, the amount and depth raises the complexity in using these chips. This is usually only a problem if you tend to write a lot of driver code. After that; a UART is a UART from the code's perspective, and advantages or disadvantages start to disappear.

I don't have much experience with Microchip's vendor-supplied driver/code library Harmony, but I heard it's unbelievably bloated and a can of worms.
I think I tried it like 2 years ago and I didn't like it.

* What's the current story with the cheap / free / good compiler toolchain and sanely usable hardware device programmers for PIC24 / PIC32 these days?  I've always recalled that PIC had "special" tools (SW, programmer) that weren't compatible with basically anything else.  Seems like I've even heard that the new PIC toolchain/environment might be widely hated () and a good version of it isn't necessarily even free now?  What's the story as to what I should look for to program and develop for PIC32 or PIC24 today if I had low cost and ease (and preferably works under LINUX not MS Windows) as my desiderata?
I don't necessarily want to get "expensive" dev boards just to get a free built in programmer/debugger but if like ARM boards there's lots of good $15 or less MCU + integrated debugger boards for PIC32 / PIC24 I'd consider it.  If so, I haven't seen them, though.

I think people are quite harsh on it. Here's my view on it:

- IDE: MPLAB X. Free. Native builds for Windows, Mac and Linux. Just run the installer and it installs on any modern Ubuntu or derived system. I haven't had any troubles with Java JDK's or whatever, those must be distro specific issues. I am fairly happy with MPLABX , except it's maybe a bit buggy compared to programs like Visual Studio.
- Compiler: XC8 / XC16 / XC32. Free versions, but also paid ones. Native builds for Win/Mac/Lin. Just install and integrates seamlessly into MPLAB X.
Another reason why I don't recommended 8-bit PICs is XC8. The paid optimizations are desperately needed on this already slow platform. The compiler lacks in many modern C features, like C99, and overall the only reason I keep this is installed is for one of those PIC12F609 projects.
XC16 and XC32 are modified versions of GCC. The free version allows optimizations up to level 1. This is sufficient for almost all projects. Well, ideally you may want to use O2 for release, but usually the gains are only a few % code size/speed. Only in very specific use cases you may want to use optimize for size or speed, like lots of code or ultra low-power respectively. Note that the gains are once again only a few % compared to -O1.

- Hardware: PICKIT3. Not free, but quite affordable considering it can program almost every PIC out there. I think it's reasonable to get started with this, but take note that any programmer/debugger on ARM evaluation boards (like Silabs with JLINK onboard, ST discovery with STLink, etc. etc) will beat the crap out of a PICKIT3. PICKIT3 takes like 5-10 seconds to start a debug session, code stepping is slow, sometimes downright buggy (EEVblog did a rant about it half a year ago or something), etc. This for me is personally becoming more and more of a dealbreaker though, considering that I only use 16-bit and 32-bit PICs; both of which are increasingly less interesting considering so many ARM chips these days.

However, I must admit Microchip's toolchain is turnkey across 3 platforms. Only a few ARM vendors can match or beat this. The only one which I had good experiences with on Linux is SiLabs. Most other vendors will recommended using something like Keil or IAR, which is either limited, very expensive, and above all Windows only.
Alternatively, for ARM you can roll your own toolchain in any GCC/GDB compatible IDE, which is ultimately what I did for STM32 on Linux using ARM GCC, GDB and OpenOCD.

[jesuscf]

So why do you even need the microchip compiler?  Isn't there a vanilla gcc that supports MIPS that should work fine when combined with the includes and linker maps and such from the microchip free version?

I thought that also, and that was my plan.  But I couldn't find even a downloadable GCC for MIPS.  So, I built GCC for MIPS from GCC sources; not a trivial task I may say.  But when I added the linker script and include files from XC32 and built my test application, it did nothing after flashing it to the PIC32 (a PIC32MX170F256 by the way).  No big deal, I thought, probably there was a problem with either the linker script or the include file.  Have you seen any of them?  They are not the average linker script or include file you'll find with other processors like the STM32 or LPC8xx, or even AVRs.  They are long and complex files where obfuscation looks like one of the goals!  Anyhow, after trying for many hours, I decided to give XC32 a try and got my test application worked right away.  So where is the problem with GCC for MIPS?  I don't know.  I may try GCC for MIPS again in the future when I have more time available...

[jesuscf]

'Lots of people, which whom I agree, had questioned the morality of such charges. '

What's morally questionable to charge for ones labor? I hope none of the people above are working for free.

Philosophically, I think it is morally questionable for people to project their morality onto others.

So, Microchip business is to sell compilers?  What is questionable to me is to charge for other people labor, which is what Microchip is doing.

[mikeselectricstuff]

'Why would I want to spend money and time on PIC32 model XYZ today because there is some gem of a feature that ARM C-M doesn't give me?'

To me, the answer is none, other than learning. I tend tobthink the pic32 is on borrowed time, and investing in it is a mistake.

Not a mistake if you ever end up working with them commercially. Microchip's stock control and silicon availability is a huge advantage over just about everyone else and is often enough to sway clients who need long term availability and bonded stock.

And their programming service.

[andersm]

Strongly biasing your decision to use ARM rather than MIPS because ARM has a significantly larger number of vendors doesn't hold a lot of water.

I was mainly referring to the various vendor-proprietary cores you run into now and again.

If you think there's much portability between ARMs from different vendors you're in for a rude awakening, the way vendors differentiate themselves is by what value they add on to the part, and that should usually be the primary decision maker, far more so than whether it's MIPS or ARM.

Everything except the peripherals is transferable knowledge. That includes the architecture, the core peripherals, the compiler, the debugger... That is not insignificant.

[andersm]

But I couldn't find even a downloadable GCC for MIPS.

If you need a precompiled toolchain, there's eg. ImgTec's own or Sourcery CodeBench. Building GCC from source isn't that difficult, it just takes time (and disk space).
EDIT: Also the chipKIT compiler, which is basically a recompiled version of XC32.

They are long and complex files where obfuscation looks like one of the goals!

The MIPS architecture adds a lot of complexity (eg. the KSEG0/1/USEG mappings, the external interrupt controller).

What is questionable to me is to charge for other people labor, which is what Microchip is doing.

Then you are in direct opposition with the Free Software Foundation.

[dannyf]

'Microchip business is to sell compilers?  '

They are in the business of making money for their shareholders.

If giving free compilers out does it, great. If charging for their compilers, great too. Thats their business and none of my business, unless I'm a microchip shareholder, to dictate.


'What is questionable to me is to charge for other people labor, which is what Microchip is doing.'

Why would that matter to you? Especially if the people whose work goes into the microchip compiler hasn't raised any objection?

For example, the trees I planted in my backyard makes the environment better, which you enjoy freely. Does that give someone the right objecting to your enjoyment of life?

We are all bystanders in this whole thing and we have no standing in projecting our moral values onto others.

If anything, it is unethical for us to do so.

[Howardlong]

Strongly biasing your decision to use ARM rather than MIPS because ARM has a significantly larger number of vendors doesn't hold a lot of water.

I was mainly referring to the various vendor-proprietary cores you run into now and again.

If you think there's much portability between ARMs from different vendors you're in for a rude awakening, the way vendors differentiate themselves is by what value they add on to the part, and that should usually be the primary decision maker, far more so than whether it's MIPS or ARM.

Everything except the peripherals is transferable knowledge. That includes the architecture, the core peripherals, the compiler, the debugger... That is not insignificant.

I agree, it's not insignificant, but it's really pretty minor compared to whether a part is fit for purpose.

We mustn't forget that there are also quite key differences within ARM implementations even within the same vendors, such as cache, varying wait states for different memory, differing memory segmentations, differing and sometimes absurdly complex clock schemes, all of which I'd say you'll encounter before you care about whether it's ARM or MIPS. Even saying "ARM" is a very general term, when we are to consider M0/M3/M4/M7 as well as the Cortex A and Cortex R ARMs.

As an example, say I wanted an on-chip high speed (>10MSa/s) ADC the obvious first port of call might be NXP's LPC4370 ARM Cortex M4F. However, say I want multi channel simultaneous sampling, pretty much the only option is the PIC32MZ EF.

One other facet also sometimes overlooked in device choice is leveraging the existing skill set of your development personnel, and whether there is a reasonable pool of skilled individuals out there to deal with normal churn rate. The cost of re-skilling and purchasing new tools is commonly not to be sniffed at. That is also a key reason why I find some vendors' recent examples of pushing proprietary frameworks so baffling, they are placing a extra unnecessary barrier in the way of selling their devices.

So that's why, in my view, the choice of core should be a relatively minor consideration among many others when choosing a device.

[jesuscf]

What is questionable to me is to charge for other people labor, which is what Microchip is doing.

Then you are in direct opposition with the Free Software Foundation.
[/quote]

Fare enough.  If I paid for the 'pro' XC32 version, will I get both the source and the scripts to build it?

[Sal Ammoniac]

- Hardware: PICKIT3. Not free, but quite affordable considering it can program almost every PIC out there. I think it's reasonable to get started with this, but take note that any programmer/debugger on ARM evaluation boards (like Silabs with JLINK onboard, ST discovery with STLink, etc. etc) will beat the crap out of a PICKIT3. PICKIT3 takes like 5-10 seconds to start a debug session, code stepping is slow, sometimes downright buggy (EEVblog did a rant about it half a year ago or something), etc. This for me is personally becoming more and more of a dealbreaker though, considering that I only use 16-bit and 32-bit PICs; both of which are increasingly less interesting considering so many ARM chips these days.

The ICD3 is a big improvement over the PICKit3. It downloads code much faster and stepping code is reasonably fast (although not nearly as fast as a Segger J-Link used with an ARM MCU). The downside is that the ICD3 costs $200. Compare that to NXP's LPC-LINK2, which costs $20 and is J-Link compatible and just as fast. The ST ST-LINK/V2 is also around $20 and almost as fast as a J-Link.

[dannyf]

'If I paid for the 'pro' XC32 version, will I get both the source and the scripts to build it?'

The source is freely downloadable, even if you don't pay.

I think the confusion comes from people's inability to understand the meaning of 'free' as in 'free software'.

[ale500]

Newer versions of J-Link work with PIC32s too.  Mine does , fully integrated with MPLABX, now debugging is fast enough to be usable

[dannyf]

Older programmers like oickit2 can be used to program pic32.

[jesuscf]

'If I paid for the 'pro' XC32 version, will I get both the source and the scripts to build it?'

The source is freely downloadable, even if you don't pay.

I think the confusion comes from people's inability to understand the meaning of 'free' as in 'free software'.

Yes, the source code for XC32  is downloadable.  Have you tried to compile it?  Here, some help:

http://jubatian.com/articles/turning-on-optimizations-in-microchips-xc32/

There is where the problem lays.

[andersm]

If I paid for the 'pro' XC32 version, will I get both the source and the scripts to build it?

Anyone can download the source code, but if you really want to build from source then the chipKIT repositories have scripts for fully automating the process.

[dannyf]

'There is where the problem lays.'

So your objection to the microchip compiler is that it isn't free.

Then the objection becomes they charge for something built on free software.

Then the objection becomes it is downloadable only with the pro version.

Then the objection becomes that you cannot built it with optimization.

Two question:

1 what's your real objection? Pick one, anyone.
2. Why is it microchips fault that you cannot build their compiler?

Can I blame you for the 100f humid day I'm having now?

[jesuscf]

If I paid for the 'pro' XC32 version, will I get both the source and the scripts to build it?

Anyone can download the source code, but if you really want to build from source then the chipKIT repositories have scripts for fully automating the process.

Link?

[jesuscf]

'There is where the problem lays.'

So your objection to the microchip compiler is that it isn't free.

Then the objection becomes they charge for something built on free software.

Then the objection becomes it is downloadable only with the pro version.

Then the objection becomes that you cannot built it with optimization.

Two question:

1 what's your real objection? Pick one, anyone.
2. Why is it microchips fault that you cannot build their compiler?

Can I blame you for the 100f humid day I'm having now?

Ok, I am wrong and your are right.  You win.  Now you go and paid 1500$ or whatever they charge to get the -mips16 option enabled with XC32.  An option that is part of GCC for MIPS for free, and programmed by someone else.  By the way I already built XC32 from source some time ago.

[dannyf]

'By the way I already built XC32 from source some time ago'

And why do you ask for the link to download the source and complain about being unable to build it?

I think you can publish your build so the whole community, even microchip, can benefit front it.

Doesn't GPL compell you to publish it?

[jesuscf]

'By the way I already built XC32 from source some time ago'

And why do you ask for the link to download the source and complain about being unable to build it?

I think you can publish your build so the whole community, even microchip, can benefit front it.

Doesn't GPL compell you to publish it?

If I distribute the compiler, which I am not, then I am compelled to publish it.  The issue is that as soon as someone figures out how to build XC32, Microchip changes something and releases a new version for which the build is not compatible with the previous one.  The building scripts/instructions I have found are for XC32 version V1.40.  That is why I was asking for the link.  Are there any building scripts for XC32 version 1.42 available anywhere?  The script I used is from https://github.com/cepr/xc32.

[Sal Ammoniac]

I wonder why (presuming that it is not the case) Microchip have not come out with dev boards with J-LINK embedded programmers like many of the ARM vendors now have or something newer for PIC32 like the ST-LINKv2 / LPC-LINK2 sorts of options from other vendors.

They already do. Take a look at the PIC32 Starter Kit. No external debugger needed--just connect it to a PC using a USB cable and you're good to go. Surprisingly, single stepping code over this USB connection is a lot faster than using an ICD3 with other boards.

[dannyf]

' The issue is that as soon as someone figures out how to build XC32, Microchip changes something and releases a new version for which the build is not compatible with the previous one'

So microchip is bad because they failed to make your life peachy?

By that notion, my neighbor is bad because he didn't give his house to me for a song.

My bank is bad because they didn't pay me am interest of 1048 percent.

You are bad because you didn't send me all of your earning and then some.



Have you ever thought about the possibility that microchip never existed just to make your life easier?

Having a more realistic view of who you are is in order, I am afraid.

[jesuscf]

' The issue is that as soon as someone figures out how to build XC32, Microchip changes something and releases a new version for which the build is not compatible with the previous one'

So microchip is bad because they failed to make your life peachy?

By that notion, my neighbor is bad because he didn't give his house to me for a song.

My bank is bad because they didn't pay me am interest of 1048 percent.

You are bad because you didn't send me all of your earning and then some.



Have you ever thought about the possibility that microchip never existed just to make your life easier?

Having a more realistic view of who you are is in order, I am afraid.

By any chance are you 14 years old?  You don't behave/write like an adult.

[andersm]

Take a look at the PIC32 Starter Kit. No external debugger needed--just connect it to a PC using a USB cable and you're good to go. Surprisingly, single stepping code over this USB connection is a lot faster than using an ICD3 with other boards.

The older starter kits had a different debugger, the newer ones (PIC32 Start Kit III onwards, IIRC) have an on-board PICKit 3.

[andersm]

Link?

https://github.com/chipKIT32

[jesuscf]

Link?

https://github.com/chipKIT32

Thanks!  Really good stuff there.

[Karel]

You can easily patch the GCC compiler without doing anything illegal (because we only alter a GPL licensed binary):

- save the hash: sha256sum /opt/microchip/xc32/v1.42/bin/xclm

- backup /opt/microchip/xc32/v1.42/bin/xclm

- compile a new "xclm" binary using the following C code:

Code: [Select]

int main(void)
{
  return 6;
}

and copy it to /opt/microchip/xc32/v1.42/bin/

- save also the hash of the new binary: sha256sum /opt/microchip/xc32/v1.42/bin/xclm

- backup /opt/microchip/xc32/v1.42/bin/bin/gcc/pic32mx/4.8.3/cc1

- open /opt/microchip/xc32/v1.42/bin/bin/gcc/pic32mx/4.8.3/cc1 with a hexeditor and
  replace the three occurrences of the old hash with the new hash.

That's it.  Works fine here with all optimization settings.

[jesuscf]

You can easily patch the GCC compiler without doing anything illegal (because we only alter a GPL licensed binary):
.
.
.
That's it.  Works fine here with all optimization settings.

Works like a charm!  Orders of magnitude faster than building from source.  On windows, Karel's instructions have to be applied to files cc1.exe, cc1plus.exe, and lto1.exe in folder xc32\v1.42\bin\bin\gcc\pic32mx\4.8.3.

[Sal Ammoniac]

What compiler did you use to compile xclm.c with on Windows?

[ale500]

I used gcc under mingw .

[Sal Ammoniac]

You can easily patch the GCC compiler without doing anything illegal (because we only alter a GPL licensed binary):
.
.
.
That's it.  Works fine here with all optimization settings.

Works like a charm!  Orders of magnitude faster than building from source.  On windows, Karel's instructions have to be applied to files cc1.exe, cc1plus.exe, and lto1.exe in folder xc32\v1.42\bin\bin\gcc\pic32mx\4.8.3.

Has anyone tried this procedure with XC32 v1.43 on Windows? I followed Karel's instructions, but could not find the sha256 hash of xclm anywhere in cc1.exe, cc1plus.exe, or lto1.exe in xc/v1.43/bin/bin/gcc/pic32mx/4.8.3

[Karel]

Has anyone tried this procedure with XC32 v1.43 on Windows?

Because I don't use windows, I can only confirm it still works with XC32 v1.43 on Linux.

[JanJansen]

You can easily patch the GCC compiler without doing anything illegal (because we only alter a GPL licensed binary):
- save the hash: sha256sum /opt/microchip/xc32/v1.42/bin/xclm

- save also the hash of the new binary: sha256sum /opt/microchip/xc32/v1.42/bin/xclm

Hi Karel, what do you mean with save the hash ?, how can i do that ?
And does this trick also works for XC8 and XC16 ?

I need to squeeze the power out my DSPIC33, with your trick i dont need stuff from hackers so its safe, lets try it.

[Karel]

You can easily patch the GCC compiler without doing anything illegal (because we only alter a GPL licensed binary):
- save the hash: sha256sum /opt/microchip/xc32/v1.42/bin/xclm

- save also the hash of the new binary: sha256sum /opt/microchip/xc32/v1.42/bin/xclm

Hi Karel, what do you mean with save the hash ?, how can i do that ?
And does this trick also works for XC8 and XC16 ?

With "save the hash" I meant: calculate the checksum of a file, in this case using a program named "sha256sum".
When you run this program with an argument (the name of the file of interest: xclm) it will calculate a so-called "hash" using the sha256 algorithm.
It's a string of 64 hexadecimal characters that uniquely identifies a file (at least in theory till we have faster computers).

It should work also for XC16 because it uses the same compiler.
The XC8 compiler is different, so this trick doesn't work there.

[Karel]

For your info, I just installed a newer version of xc32 (v1.44) and patched it as described above.

[JanJansen]

Suppose you ask Microchip if its legal ?, what do they say ?

[Karel]

Check the file /opt/microchip/xc32/v1.44/docs/MPLAB_XC32_Compiler_License.txt:

4. Open Source Components.  Notwithstanding the license grant in Section 2 above, Licensee further acknowledges that certain components of the Software may be covered by so-called "open source" software licenses ("Open Source Components"). Open Source Components means any software licenses approved as open source licenses by the Open Source Initiative or any substantially similar licenses, including without limitation any license that, as a condition of distribution of the software licensed under such license, requires that the distributor make the software available in source code format. To the extent required by the licenses covering Open Source Components, the terms of such license will apply in lieu of the terms of this Agreement. To the extent the terms of the licenses applicable to Open Source Components prohibit any of the restrictions in this Agreement with respect to such Open Source Components, such restrictions will not apply to such Open Source Component.

It's my opinion that I patch an open source (GPL) component, so I don't worry. If they dare to break balls about it, the free software foundation will be happy to drag them into court...

You have to decide for yourself, I can't do that for you, I'm not a lawyer.

[jesuscf]

Just patched XC32 V2.05.  The instructions above still work.

[technix]

If you are brave enough to poke around the source code (also released under GPL) you can comment out all the code related to license checking. It will make compiling even faster since it is no longer calling to the xclm binary. Or you can just replace xc32 with a standard mips-gcc too (which both compiles faster due to the lack of license check, and emits better code due to the more efficient interrupt entry and exit.)

The same applies to xc16 too actually, since that too is GCC based.

[cv007]

Or just do it the 'better/newer' way-
https://github.com/cv007/XC3216/blob/master/xc32xc16-info-rev4.txt
(OSX info is lacking for the xc32 binary mods, if wanted I would need the 3 binary files, then I can decompile and update the info)

No need to deal with xclm (section1 binary mod), or even do any mods (section2 simple txt file).
In the case of 'section1', the xclm file has to be present (but can be blank), but is never called (speedy compile). The no-mod 'section2' still calls xclm but the results are overridden. XC16 is a little different, and if I recall either method will not even bother with xclm at all.

The latest source mchp released for xc32 also appears to have the build scripts now included, but I have not tried it.  In some ways, it is better to be working with the same version as 'everyone' else, where the available documentation also matches, and any problems can be reproduced by others if needed.

[Karel]

You can easily patch the GCC compiler without doing anything illegal (because we only alter a GPL licensed binary):

- save the hash: sha256sum /opt/microchip/xc32/v1.42/bin/xclm

- backup /opt/microchip/xc32/v1.42/bin/xclm

- compile a new "xclm" binary using the following C code:

Code: [Select]

int main(void)
{
  return 6;
}

and copy it to /opt/microchip/xc32/v1.42/bin/

- save also the hash of the new binary: sha256sum /opt/microchip/xc32/v1.42/bin/xclm

- backup /opt/microchip/xc32/v1.42/bin/bin/gcc/pic32mx/4.8.3/cc1

- open /opt/microchip/xc32/v1.42/bin/bin/gcc/pic32mx/4.8.3/cc1 with a hexeditor and
  replace the three occurrences of the old hash with the new hash.

That's it.  Works fine here with all optimization settings.

This method stopped working with XC32 v2.10.

The solution is to simply change the return value in the C code from 6 to 2.

[TomS_]

cv007's git repo seems to be gone - does anyone know what happened to it?

edit: nevermind, just the link in this thread that doesnt go directly there any more, its still there!

https://github.com/cv007/XC3216