What would be the equivalent of PIC32MX in ARM world and PIC32MZ in ARM world? - Page 1
Forum section: electronics / general

author: asgard20032
author_rank: Regular Contributor
timestamp: September 12, 2015, 01:36:44 pm
content: What would be the equivalent of PIC32MX in ARM world and PIC32MZ in ARM world?And how it compare to its equivalent?I bet PIC32MZ compare to M7, but what do you guy think?

author: andersm
author_rank: Super Contributor
timestamp: September 12, 2015, 03:02:51 pm
content: What are you comparing? On an architectural level, PIC32MX (MIPS M4K core) resembles the ARM7TDMI (ARM/Thumb modes vs. MIPS32/MIPS16e). The PIC32MZ EC starts looking like a Cortex-M4 (Thumb-2 vs. microMIPS, DSP extensions) and the PIC32MZ EF's FPU brings it closer to the Cortex-M4F/M7.

author: asgard20032
author_rank: Regular Contributor
timestamp: September 12, 2015, 03:33:44 pm
content: Architectural level, performance, peripheral... Any comparaison is useful. One of the big mistake people do is to compare PIC32 to ARM instead of comparing subfamily.

author: nctnico
author_rank: Super Contributor
timestamp: September 12, 2015, 03:35:08 pm
content: All that doesn't matter if the compiler is crippled.

author: andersm
author_rank: Super Contributor
timestamp: September 12, 2015, 04:08:31 pm
content: Quote from: asgard20032 on September 12, 2015, 03:33:44 pmFor anything beyond a high-level architectural view you have to look at actual devices. Achievable performance depends on so many implementation details, and the same obviously goes for peripherals.

author: ale500
author_rank: Frequent Contributor
timestamp: September 12, 2015, 04:16:29 pm
content: It would be great if someone would bring a Cortex-0 or 3 (or 4) DIP28/DIP32 other than the LPC1114 with more memory, I mean PIC32 are available with up to 256 kBytes Flash ! (Yeah, instructions are wider and the standard compiler does not allow for optimization but you can roll on you own compiler and compile most of your code as a lib with optimizations and link it with mchip's linker, formats are compatible.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 12, 2015, 04:30:06 pm
content: Quote from: ale500 on September 12, 2015, 04:16:29 pm..and 64K RAM, which is really rare on any small (<64 pin) package, let alone DIP/SOIC

author: ale500
author_rank: Frequent Contributor
timestamp: September 12, 2015, 07:39:19 pm
content: Exactly, that's why I wouldn't dismiss PIC32s that fast...

author: Howardlong
author_rank: Super Contributor
timestamp: September 12, 2015, 08:06:39 pm
content: Somewhat against my better instinct, since the release of the PIC32MZ EF a few weeks ago I am re-evaluating whether to use it or not instead of M4F. Not because of the floating point, but the silicon quality so far seems an order of magnitude better than the steaming pile that Microchip did nearly a couple of years ago with the PIC32MZ EC.And I might possibly say that their Harmony equally-steaming-pile that you pretty much have to use for PIC32MZ is almost working now too, not that it adds any value, because overall, it doesn't, the pile still steams but in a more predictable and manageable way. The saddest thing is is that they even thought they were right to release the EC and Harmony back then, the damage they've self-inflicted may never be healed.

author: MT
author_rank: Super Contributor
timestamp: September 12, 2015, 08:15:26 pm
content: Quote from: asgard20032 on September 12, 2015, 03:33:44 pmYou are asking for a very tiersome and ungreatful task from yourself, for example pheripherials, a dsPIC33 has superior DMA handlingand speed compared to a similar speeded or even faster MX or ST/F1-F3 (F2 is closing the gap).If you start to look closely atdetails a 40Mhz dsPIC33 actually beats up many 72 Mhz ST devices. On the other side of the river Styx most ARM based devices have superior pheripherials then dsPicC33 and Pic32...... The devil sits in the details!

author: commie
author_rank: Frequent Contributor
timestamp: September 12, 2015, 09:00:09 pm
content: Just as a matter of interest, how much does the compiler cost for this pic32 chip?What are the float data types offered by the compiler?How long will this chip be on the market for approx.?

author: andersm
author_rank: Super Contributor
timestamp: September 12, 2015, 09:42:28 pm
content: You can see the prices in Microchip'sonline store. The FPU supports the standard IEEE 754 single- and double-precision data types.

author: tszaboo
author_rank: Super Contributor
timestamp: September 12, 2015, 10:08:27 pm
content: PIC32MX compares to early Cortex M3 in terms of performance. The MX is good.PIC32MZ doesnt compare to any ARM product, because the wrath of god would destroy anyone who would try to release something with that many silicon errors.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 12, 2015, 11:05:55 pm
content: Quote from: commie on September 12, 2015, 09:00:09 pmThe free versions of the 32 bit compilers are entirely useable unless you need to squeeze the last drops of speed or code space.Microchip have probably the best record of anyone in the industry for not obsoleting parts - you can still buy the original 16C54 parts released 20-odd years ago.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: September 13, 2015, 10:18:59 pm
content: Quote from: commie on September 12, 2015, 09:00:09 pmthey cost 0$, because its gcc, opensource and microchip give you the sources. so, if you dont want to compile, you can pay$ or return 2or pay 0$ and compile.

author: Chris C
author_rank: Frequent Contributor
timestamp: September 13, 2015, 11:04:38 pm
content: Microchip's free compiler version allows -O1 optimization, but not -O2 or higher. However, -O2 is just a shortcut that turns on a predefined list of other optimization flags. And though you can't use the -O2 shortcut directly, you can use -O1, then add all the subflags that -O2 adds, accomplishing the same thing. Same applies to higher optimization levels. Flag lists here:https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.htmlLeaving only one other limitation, the free version doesn't allow the -mips16 global option. But you can manually add the mips16 attribute to some or all of your functions, and again accomplish the same thing.Or, as  noted, the compiler source code is freely downloadable. So if you prefer, you can download that, bypass calls to the license manager, and recompile. I believe the exact modifications are even documented on the web.It's so easy to bypass the limitations, that every time I see someone complaining that Microchip's compiler is "crippled", I can't help but wonder if they actually have the skills or patience to code anything that needs an uncrippled compiler in the first place.

author: nctnico
author_rank: Super Contributor
timestamp: September 14, 2015, 12:35:23 am
content: Compiling GCC+binutils from source isn't exactly a walk in the park so the source code isn't going to be very useful. Besides that: if the crippling is so easy to bypass then why does Microchip still charge money for it?

author: nctnico
author_rank: Super Contributor
timestamp: September 14, 2015, 01:13:01 am
content: I think Microchip added that licensing crap to GCC. This is bad because you'll have to rely on Microchip to port their changes into new versions of GCC. I'm also wondering if they made improvements over the vanilla MIPS version of GCC. Frankly I don't think so; maybe just command line switches so it automagically selects the right link script and CPU to compile for depending on a target option. I'm also pretty sure you can get the vanilla MIPS GCC version to work with full optimisation AND use the latest GCC version. I have been using ARM GCC that way for about a decade.

author: westfw
author_rank: Super Contributor
timestamp: September 14, 2015, 04:33:24 am
content: It would be worth something if microchip had better embedded libraries than newlib. (I'm don't know if they do.)You could also download the "mpide" (Arduino-like) environment and use the C compiler contained therein.QuoteThe PIC32s have fewer sub-types, so the MX probably spans everything from CM0 through low-end CM4s (120MHz, 512k flash), and the MZ with DPFP probably matches CM7s.Also, I think even the low-end MX devices have a sort of "baby MMU" that can be particularly useful for multitasking. For example, the larger PICKIT will run 2.10bsd unix.

author: andersm
author_rank: Super Contributor
timestamp: September 14, 2015, 04:55:49 am
content: Quote from: Chris C on September 13, 2015, 11:04:38 pmThat used to work, but reading the code, in newer versions of XC32 the individual settings flags are nullified.Quote from: nctnico on September 14, 2015, 12:35:23 amLots of people find value in having a precompiled, tested and supported toolchain. For years, all you needed to get full functionality of the compiler was a one-line shell script, but people still bought licenses. They also ship a commercially licensed C library, and Dinkumware's C++ libraries. The C library seems more buggier than Newlib, but that's another matter.QuoteAFAIK most of the changes have been on the linker side, adding a best-fit allocator and automatic stack allocation (personally I think they get more in the way, but if you're an IDE jockey there might be some value). The ISR specification and generation mechanism is also theirs I think, and as you guessed there is some part selection support. There might be more, those are what springs immediately to mind.QuoteFor whatever reason, CodeSourcery didn't submit their microMIPS work to mainline GCC until recently, so for full PIC32MZ support you need at least version 6.0. Microchip forked their compiler from CS's tree.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: September 14, 2015, 05:57:08 pm
content: Quote from: wilfred on September 14, 2015, 12:53:39 amit has two things;1 - call to license manager to see if you can run -O2 / -O32 - md5sum to see if you altered it (and thus getting around license manager).its like 1 function you can comment it out (and the calls to it) or just have the license function return a true value.building the compiler under linux is a cakewalk, I do not know about building it under windows tho. probably so much harder.

author: Chris C
author_rank: Frequent Contributor
timestamp: September 14, 2015, 11:38:56 pm
content: Quote from: wilfred on September 14, 2015, 12:53:39 amThis describes the recompilation process:http://jubatian.com/articles/turning-on-optimizations-in-microchips-xc32/I loaded up XC32 1.40, free version, in a virtual machine. Added a dozen of the -O2 subflags, and it does appear the -O2 subflags are now nulled as  reported. None of them had any effect.Putting the mips16 attribute on individual functions still seems to work.Compiling my current project various ways:1) Licensed compiler, with -O2 -mips16: 69,336 bytes2) Licensed compiler, with -O2: 87,976 bytes3) Free compiler, with -O1: 84,268 bytesBy manually placing the mips16 attribute on most of my functions (some I deliberately have marked -nomips16), I could get the size of #3 down. The free version doesn't seem too bad, though I didn't try benchmarking.

author: nctnico
author_rank: Super Contributor
timestamp: September 14, 2015, 11:43:43 pm
content: mips16 probably switches to a reduced 16 bit instruction set. The code gets smaller but that still doesn't mean it is any faster (probably even more instructions). Fortunately ARM provides a free and full version of ARM GCC.

author: Chris C
author_rank: Frequent Contributor
timestamp: September 15, 2015, 12:10:12 am
content: Quote from: nctnico on September 14, 2015, 11:43:43 pmYep, that's exactly what it does. Smaller code on average, but sometimes slower due to a limited instruction set, that may require additional instructions. In particular I've noticed there are no MIPS16 instructions to enable/disable interrupts, access co-processor registers, and perform certain bit manipulations. So if these are needed it has to perform a jump to an even address to switch to MIPS32e, execute the needed instructions, then jump to an odd address to switch back to MIPS16.Although I wonder if in some cases it might speed things up by virtue of being able to pull two instructions from FLASH instead of one. At least when FLASH wait states are required, and a cache is provided.I use MIPS16 by default, then mark speed-critical functions with nomips16. Sometimes the compiler overrides this. I have one C function, 1,600 lines long, that refuses to compile as MIPS16 at all. I'm guessing MIPS16 has some limitations on jump length.

author: ale500
author_rank: Frequent Contributor
timestamp: September 15, 2015, 05:19:26 am
content: You can use the core timer to time your routines... sometimes -O3 was slower than -O2, larger code....

author: nctnico
author_rank: Super Contributor
timestamp: September 15, 2015, 06:28:10 am
content: Quote from: ale500 on September 15, 2015, 05:19:26 amIn that case the compiler does not seem to be tuned properly to the pre-fetch/execution pipeline/branch prediction/cache of the core. O3 should always be faster or just as fast as O2. In general O3 uses loop unrolling to reduce the overhead of loop counting and emptying the pipeline at a branch instruction.

author: andersm
author_rank: Super Contributor
timestamp: September 15, 2015, 07:54:21 am
content: Quote from: nctnico on September 15, 2015, 06:28:10 amIt's not uncommon for smaller code to be faster when code execution speed is faster than instruction fetch speed. Eg. on machines with caches you really want your critical loops to stay within L1 cache, and on microcontrollers with slow flash you want to play nice with whatever prefetch mechanism is used.

author: tszaboo
author_rank: Super Contributor
timestamp: September 15, 2015, 09:47:13 am
content: Quote from: nctnico on September 15, 2015, 06:28:10 amThe last time I compiled for PIC32, the unroll loops was a extra option which could be separately turned on (-funroll-loops). For sure no-one want O1, I've seen every ; made in the assembly as a NOP, but there is generally very small difference between O2 Os and O3.I'm always saying, if these optimizations make a huge difference and possibly they could make a product unusable, or the spec has to be reduced, it is time to rethink the microcontroller used.If O3, Os or O2 makes a huge difference, the code is very fragile, any change can turn it into a not working code, and you need top programmers working on it (and I've only met a handful of those).

author: nctnico
author_rank: Super Contributor
timestamp: September 15, 2015, 10:35:28 am
content: Quote from: NANDBlog on September 15, 2015, 09:47:13 amSorry but that is just plain wrong. These options are supposed to make a huge difference! They stear the compiler/optimizer into making the smallest code or the fastest code. With GCC there generally is a big difference in speed between -Os and -O3. In -O3 it will use loop unrolling and depending on what the loop criteria is it can reduce a lot of overhead from the loop and thus make the code faster at the expense of repeating the same code several times and thus using more memory. I don't know how you get the idea code which shows a large difference is fragile because that is just plain nonsense.

author: tszaboo
author_rank: Super Contributor
timestamp: September 15, 2015, 03:41:57 pm
content: Quote from: nctnico on September 15, 2015, 10:35:28 amClearly you havent read my comment on not unrolling the loops. It is a separate thing.Should I point out the other things you misunderstood or didn't read?

author: andersm
author_rank: Super Contributor
timestamp: September 15, 2015, 04:07:43 pm
content: Quote from: NANDBlog on September 15, 2015, 03:41:57 pmGCC's optimizers work based on heuristics. With optimizations turned on, smaller loops may be unrolled. With higher optimization levels, the balance of unrolling vs. code size is adjusted allowing bigger loops to be unrolled, or unrolling more iterations. The same goes for eg. inlining.For example, take this toy function:Code:extern int *var;#define N_ITERS 3int foo(void){int i, sum = 0;for (i = 0; i < N_ITERS; i++){sum += var;}return sum;}At optimization level -O2, xc32-gcc 1.40 will unroll the loop if N_ITERS is less than 4. At -O3, the loop will be unrolled if N_ITERS is less than 18.

author: nctnico
author_rank: Super Contributor
timestamp: September 16, 2015, 12:13:50 am
content: Quote from: NANDBlog on September 15, 2015, 03:41:57 pmI think Andersm already pointed out where your mistake was. I've been using gcc for microcontrollers for over 15 years so I'm quite well aware of which option does what. The optimisation settings (-Ox) are just aliases for a whole bunch of options / settings. Microchip should not have put it in their manual like that.

author: tszaboo
author_rank: Super Contributor
timestamp: September 16, 2015, 08:00:34 am
content: Quote from: nctnico on September 16, 2015, 12:13:50 amBut it is in their Mplab like that.

author: nctnico
author_rank: Super Contributor
timestamp: September 16, 2015, 09:17:10 am
content: From GCC's manual it seems that just bluntly enabling loop unrolling may not have the desired effect:https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-OptionsThs page also shows what the -Ox options do exactly.

author: andersm
author_rank: Super Contributor
timestamp: September 16, 2015, 10:22:24 am
content: Quote from: NANDBlog on September 16, 2015, 08:00:34 amThe separate unroll flag allows you to request more loops to be unrolled than the base optimization level would allow. That does not means loops are not unrolled unless the flag is used, it just adjusts the compiler's internal tunings differently.

author: tszaboo
author_rank: Super Contributor
timestamp: September 16, 2015, 12:27:50 pm
content: Quote from: nctnico on September 16, 2015, 09:17:10 amThe page also say:QuoteQuote from: andersm on September 16, 2015, 10:22:24 amMaybe.To be honest I dont think this discussion leads to anywhere, I myself haven't write code in the last 4 years, and it is possible I remember wrong or GCC got extended with something in the meantime, or the C32 behaves differently.

author: Howardlong
author_rank: Super Contributor
timestamp: September 16, 2015, 12:57:12 pm
content: I am intrigued how optimising compilers deal with the concepts of differing wait states and cache: I suspect a lot of the time, they don't. I can see scenarios, for example, where knowledge of cache configuration might change the unrolling characteristics.I could see optimised code generated for a PIC32MX1xx/2xx (all code is zero wait state) being significantly different to that run on a PIC32MX5/6/7 within a flash cacheable KSEG0 segment, where excessive unrolling may become detrimental by continual purging of the prefetch cache.

author: Scrts
author_rank: Frequent Contributor
timestamp: September 16, 2015, 03:47:34 pm
content: I think I saw the capability of PIC32MZ to do virtualization. Is it possible with ARM M series?

author: Howardlong
author_rank: Super Contributor
timestamp: September 16, 2015, 04:03:24 pm
content: Quote from: Scrts on September 16, 2015, 03:47:34 pmNot in the hardware sense for either as far as I am aware. I am trying to think of what value that would have in the type of embedded targets these devices are aimed at?

author: andersm
author_rank: Super Contributor
timestamp: September 16, 2015, 04:14:52 pm
content: Quote from: Scrts on September 16, 2015, 03:47:34 pmI don't think the PIC32MZ EF has the VZ module, at least the documentation makes no mention of it. ARM have their own VMSAv7 virtualization extensions, but unlike ImgTec I don't think they're planning on bringing virtualization to microcontrollers.