Update -> Microchip C Compilers-which free complier do you use ?  (from 2011) - Page 1
Forum section: electronics / general

author: ez24
author_rank: Super Contributor
timestamp: November 15, 2015, 11:54:07 pm
content: Re: Microchip C Compilers - which free compiler do you use? (from July 04, 2011)https://www.eevblog.com/forum/microcontrollers/microchip-c-compilers-which-free-compiler-do-you-use/What has happened in the last 4 years in regards to free compilers for PICs?Better or worse ? Also there were comments on ARM and AVR compliers, so any updates on them (free compilers) would be appreciated.thanks

author: Howardlong
author_rank: Super Contributor
timestamp: November 16, 2015, 08:15:25 am
content: XC8 is the replacement for C18, but it covers PIC10F thru PIC18. It is based on the Hitech C I believe who Microchip bought out. It is a bit buggy, but it hides the programmer from a lot of the nasties such as banked memory.XC16 replaces C30 and is a direct descendent of C30.XC32 replaces C32 and is a direct descendent of C32.The free versions lack much optimisation, but are not size limited. If you want to spend, there are standard and pro versions of each compiler. Costs are high in particular if you work across all families, although as XC16 and XC32 are based on GCC it is possible to work around that, or at least it was. There is chatter about XC8 being fiddled to liberated options too.There is an entry cost to each level (standard or pro) and then there's a software assurance type annual licence. You only have to pay the software assurance if you need, say, support for new chips. I haven't updated any of mine since June as I have no need for any new functionality yet, but they all still work with the versions I have installed. A year's software assurance is included with the first purchase.There is also a C++ for PIC32, it's not something I've bothered with myself.I find XC16 and XC32 pretty robust, XC8 less so, it sometimes generates errors from nowhere and you have to deliberately reorganise your code to stop it failing.

author: westfw
author_rank: Super Contributor
timestamp: November 16, 2015, 09:36:37 am
content: I have heard that the "brainless translation of intermediate code" non-optimization that the freeware 8bit PIC compiler used to do has actually been replaced by something that isn't as obnoxious and embarrassing. But it was sorta too late for me, so I haven't looked at it closely, and I don't remember whether that happened before or after the previous discussion...For PIC32, you can consider using the toolset that comes with MPIDE (the Arduino-clone for ChipKit boards.)

author: Ian.M
author_rank: Super Contributor
timestamp: November 16, 2015, 09:45:31 am
content: XC8 free mode is generally getting better. Microchip has also introduced device support updates that can be applied to earlier versions if your support licence has expired. Also, unlike many competitors, the free mode licence does NOT prohibit commercial use, so if you haven't got funding yet for your project you can still go ahead with a clear concience.However, anyone who plugs XC8 as a drop-in replacement for C18 is talking out their arse. Existing code that's more complex than basic pin wiggling usually requires major work to port to XC8.

author: nctnico
author_rank: Super Contributor
timestamp: November 16, 2015, 01:48:40 pm
content: IMHO the price for the PIC compiler kinda negates the cost savings for using a PIC compared to the free GCC compilers availabled for other platforms.

author: Howardlong
author_rank: Super Contributor
timestamp: November 16, 2015, 04:15:46 pm
content: Quote from: nctnico on November 16, 2015, 01:48:40 pmI agree, Microchip need to get much more competitive in this respect.

author: AndyC_772
author_rank: Super Contributor
timestamp: November 16, 2015, 05:04:41 pm
content: +1.I use PICs for simple stuff, or occasionally if I happen to need specific peripherals. For analogue stuff, they're quite good, and generally not too demanding in terms of the code they need to run.However, if I need anything faster or more capable than a PIC18 running code from the free XC8 compiler, I jump straight to an ARM processor.Seriously, Microchip, a crippled compiler in this day and age? You do know that Cortex-M0 exists and that gcc is free... right?

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: November 16, 2015, 06:40:27 pm
content: Quote from: AndyC_772 on November 16, 2015, 05:04:41 pmsigh.the full optmizing xc32 is free, you just have to compile it. (its gcc. you know that gcc is free... right?).

author: Delta
author_rank: Super Contributor
timestamp: November 16, 2015, 06:54:37 pm
content: The free version of XC8 doesn't just "not optimise", rather it deliberately and embarrassingly bloats the ASM it produces. Often as blatant as using additional MOV instructions to move a value out of the W register into a temp location, then immediately back again.http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/There are ways for unscrupulous users to enable the pro mode without buying the licence...

author: andersm
author_rank: Super Contributor
timestamp: November 16, 2015, 07:35:58 pm
content: Quote from: Delta on November 16, 2015, 06:54:37 pmThat is a lie, and you should stop spreading it.

author: bson
author_rank: Unknown
timestamp: November 16, 2015, 07:40:17 pm
content: Quote from: AndyC_772 on November 16, 2015, 05:04:41 pmYeah, if the code is too big or requires any optimization whatsoever, then PIC18 isn't the right platform to begin with. It excels where all the C code does is set up hardware peripherals and the WDT and does pretty much nothing else. It's never going to be a good software target. An MSP430 at 1/4 the clock will run circles around a PIC18 for anything non-trivial; USB, chained buffers, rendering to a panel, etc. Doesn't matter how heavily optimized the code generation is, or even if it's carefully handcrafted, it will never be a computational platform. It does have excellent peripherals (like PWM outputs capable of operating in bridge mode without any external components), very fast interrupt service, and very low power consumption at low clocks (which precludes the software doing any significant lifting).For everything else, there is MSP430 and ARM.

author: Ian.M
author_rank: Super Contributor
timestamp: November 16, 2015, 07:42:06 pm
content: Quote from: andersm on November 16, 2015, 07:35:58 pmIt depends on the definition of "deliberately". The HiTech/XC8 compiler team did have a tradition of leaving the optimiser rather a lot to do . . . .

author: kony
author_rank: Regular Contributor
timestamp: November 16, 2015, 08:08:50 pm
content: Quote from: andersm on November 16, 2015, 07:35:58 pmEver looked at disassembly of what it produces in free mode?

author: AndyC_772
author_rank: Super Contributor
timestamp: November 16, 2015, 09:18:42 pm
content: Quote from: BloodyCactus on November 16, 2015, 06:40:27 pmXC32 is for PIC32, though, and I can't think of one single, solitary reason toeverconsider using PIC32 over an ARM based device. Happy to take suggestions.

author: hans
author_rank: Super Contributor
timestamp: November 16, 2015, 09:23:44 pm
content: I would NOT recommended XC8. Simply because it does not fully support C99, which is15+years old by now and can be very useful (snprintf)/less frustrating. Will it ever fully support C99? Not sure.. the architecture has it constraints which likely impose a limit on this (e.g. variable length arrays).The XC8 compiler relies heavily on the optimizer as shown, and in the free version you don't get all bells and whistles. And don't think the PRO will save you; I could not get an expanding macro's to collapse back to bit set/clr instructions (bit set/clr a to a dereferenced const I/O ptr). This which works fine on XC16/XC32 with -O1 optimizations (which is still free).XC16/XC32 are fine, I have little issues with them. Yeah the -O2, 3 and s are missing for free, but -O1 is often more than good enough. It usually shrinks the code by the biggest step, -O2 and -Os adds very little IMHO.What XC16 could very well use is C++ support (there are plenty of capable 16-bit uCs around with 32kB of RAM, DMA, USB, CAN, LCD, etc.). The AVR and ARM GCC compilers don't have this 'problem' (and are also free).

author: neslekkim
author_rank: Super Contributor
timestamp: November 16, 2015, 10:01:23 pm
content: Quote from: hans on November 16, 2015, 09:23:44 pmAnd the alternative for xc8 is?

author: Delta
author_rank: Super Contributor
timestamp: November 16, 2015, 10:37:11 pm
content: Quote from: andersm on November 16, 2015, 07:35:58 pmDid you read the link I posted? That guy gives clear code examples. Admittedly, he's using v1.21 rather than the latest version. I've got v1.34, so I'll do some testing and report back. (Always happy to be proved wrong!)

author: Howardlong
author_rank: Super Contributor
timestamp: November 16, 2015, 10:59:47 pm
content: Quote from: AndyC_772 on November 16, 2015, 09:18:42 pmI do the entire PIC range as well as ARM, mostly Cortex M4(F) but some M0 and M3 from NXP and TI. You may think it's trivial, but being able to prototype something in ten minutes in DIP is a key reason for me to continue to use PIC extensively. The other reason, perhaps more telling, is that I've been using PICs, and their predecessors, since the late 70s. Like it or not I have an awful lot of boilerplate code and experience for PICs sitting there ready to go, but not as much as with NXP or TI ARM.The single biggest failure of Microchip has been their awful silicon and development framework since 2013 targeted at the the high end PIC32MZ, although this has improved of late significantly with their floating point PIC32MZ. I guess they were desperate to get something out of the door silicon-wise to compete with M4, but it was a car crash. The framework which you pretty much have to use on the latest PIC32MZs was and still is complete overkill. It was revealed recently it was written by some Linux kernel folks. It shows, it's hugely over abstracted and the newer PIC32MZ chips, with double the processor speed of the PIC32MX, run applications written for the MX without the framework significantly slower.I am not sure why this needs to be a PIC vs ARM in the same way you could have the same argument about TI ARM vs NXP ARM, to me although there are similarities in the cores, that's generally a minor consideration for most of the time: beyond that they're very different from the peripherals to the vendor libraries to the free IDEs, I could go on, but knowing one ARM Cortex chip from one manufacturer doesn't mean you automatically know all the others, far from it in fact.Having said all that, I do think Microchip made a marketing blunder going for MIPS rather than ARM, because like it or not that is where everyone thinks they should be, for now at least.

author: richardman
author_rank: Frequent Contributor
timestamp: November 16, 2015, 11:07:33 pm
content: Quote from: Howardlong on November 16, 2015, 10:59:47 pmThey are stuck - if they go with ARM, then they have to compete with everyone else. By going with MIPS, they only have to compete with, oh wait, everyone elseBut it's a tough situation for Microchip. Back in 2000s, BEFORE ARM really took over the 32-bit embedded / phone world, a BIG semiconductor company thought that they could dethrone the ARM7 with their own 32-bit architecture, and ... after even their own phone division would not use their chip but went with ARM, they had to cancel the whole product line. I am speaking of the mCore of course.And then of course we still have Atmel AVR32. How many people use that?So Microchip is stuck either way.

author: Howardlong
author_rank: Super Contributor
timestamp: November 16, 2015, 11:32:01 pm
content: Quote from: richardman on November 16, 2015, 11:07:33 pmFWIW, I remember a number of folks (including me!) questioning the decision to go MIPS when the PIC32 was announced ISTR in 2007 or so. However it didn't seem quite such a big deal then, although ARM was already a key player. I guess it depended who was playing golf with who.

author: nctnico
author_rank: Super Contributor
timestamp: November 16, 2015, 11:35:40 pm
content: Quote from: Howardlong on November 16, 2015, 10:59:47 pmI have solved that by having some boards lying around to which I can solder an ARM controller bolt that to a PCB or breadboard.

author: Howardlong
author_rank: Super Contributor
timestamp: November 16, 2015, 11:46:34 pm
content: Quote from: nctnico on November 16, 2015, 11:35:40 pmI do the same, but for BGA devices it's a lot more effort. Either way, having to solder up something when I don't need to is one less step. I found a few weeks ago that one of the newer 28 pin dsPIC33Es was only available in SOIC or smaller, not a big deal, like you I popped it on a breakout board and got on with it. So the end is nigh for DIP at Microchip too it would seem!

author: nctnico
author_rank: Super Contributor
timestamp: November 16, 2015, 11:54:35 pm
content: It is nice to have a board which already has a regulator, some decoupling caps, maybe a USB connector, programming header etc. It can also be used in more permanent one-of solutions.

author: richardman
author_rank: Frequent Contributor
timestamp: November 16, 2015, 11:58:10 pm
content: Quote from: nctnico on November 16, 2015, 11:54:35 pmThat's pretty much what Teensy/ST-Nucleo-32 (the new ones) are right?We have thought about making "C-Stamp" but just cannot compete with ST on prices when they are practically giving them away.

author: nctnico
author_rank: Super Contributor
timestamp: November 17, 2015, 12:15:06 am
content: Actually I have my own boards. It is good to get some hands-on experience with putting a certain microcontroller on a circuit board.

author: richardman
author_rank: Frequent Contributor
timestamp: November 17, 2015, 12:21:29 am
content: Well, again, not for super-users, but for mere mortals :-)

author: Howardlong
author_rank: Super Contributor
timestamp: November 17, 2015, 08:56:52 am
content: Quote from: nctnico on November 16, 2015, 11:54:35 pmFor those, I just add them on: I have a small drawer with common parts that I only use for breadboarding including Rs and Cs, LDOs crystals etc. There are also ready made LCD, USB and debugger breakouts for example, but admittedly the USB breakouts are only for up to full speed. Inevitably at some point you're going to need to have something more exacting, such as for high speed USB, when I use a ready made board or I make up my own PCB. But there's a whole lot of unit testing and proof of concept work at can be done on breadboards for MCUs without even turning on a hot pointy thing, as long as your chip is DIP!

author: andersm
author_rank: Super Contributor
timestamp: November 17, 2015, 05:30:16 pm
content: Quote from: kony on November 16, 2015, 08:08:50 pmThe unoptimized code is bad, no-one's saying differently, but it is a very different thing to claim that it deliberately makes it worse. It's a dumb claim that doesn't even pass the simplest bullshit test (one, it would just be a possible source of bugs, second, you can imagine what would happen if someone took apart the code generator and found this code). You can go to Microchip's forum and read the explanation straight from the compiler engineers, but IIRC the issue is that during the initial code generation pass, the compiler doesn't yet know the memory layout of the data, and must assume that every variable lives on a different memory page. Later optimization passes removes the code that turned out to be unnecessary.The claim that the compiler would somehow naturally produce perfect code (on a C-hostile architecture like PICs, no less) and would then deliberately make it worse unless you pay is ludicrous.

author: Delta
author_rank: Super Contributor
timestamp: November 17, 2015, 06:08:13 pm
content: Fair enough Anders, I did some testing with XC8 v1.34, and it didn't do any of the redundant double MOVing malarkey. In free mode it did however useCode:MOVLW 0MOVWF the_varinstead of a simpleCode:CLRF the_varas it does in Pro mode.Is that an "optimisation"? I'm not sure, but admittedly I don't know anything. (I would say no it's not, based on the fact that even as a self-taught ASM programmer, I was using CLRF right from the start)My comments were based on this bit of code (taken fromhttp://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/) where the author was using XC8 v1.21 with a PIC18. I can't see how the unknown banking explanation could fit here...?Code:71: maxDev = CCPR1L>>1;001E 3611 LSRF CCPR1L, W001F 00F2 MOVWF 0x720020 0872 MOVF 0x72, W0021 00A2 MOVWF maxDev72: maxDev= maxDev>>1;0022 3622 LSRF maxDev, W0023 00F2 MOVWF 0x720024 0872 MOVF 0x72, W0025 00A2 MOVWF maxDev73: maxDev= maxDev>>1;0026 3622 LSRF maxDev, W0027 00F2 MOVWF 0x720028 0872 MOVF 0x72, W0029 00A2 MOVWF maxDev74: maxDev= maxDev>>1;002A 3622 LSRF maxDev, W002B 00F2 MOVWF 0x72002C 0872 MOVF 0x72, W002D 00A2 MOVWF maxDev

author: nctnico
author_rank: Super Contributor
timestamp: November 17, 2015, 06:28:26 pm
content: What would be interesting is to see the difference between no optimisation in the paid compiler and the free compiler.

author: Ian.M
author_rank: Super Contributor
timestamp: November 17, 2015, 07:49:13 pm
content: Any *NEW* user can test that as there is a option for a 60 day free trial of PRO mode and STD mode. (only applies if there's never been XC8 on the pc previously. The trial does NOT reset on version upgrade)

author: neslekkim
author_rank: Super Contributor
timestamp: November 17, 2015, 07:50:36 pm
content: Quote from: nctnico on November 17, 2015, 06:28:26 pmthe article referred do exactly that.. but yes, an older version.

author: hans
author_rank: Super Contributor
timestamp: November 17, 2015, 09:48:25 pm
content: Quote from: neslekkim on November 16, 2015, 10:01:23 pmIn my opinion XC8 is the best bet for 8-bit PIC, but from software point of view it falls short (for me). It is OK if I have something very simple that can be done via hardware registers directly without any need to have portable code.There may still be reasons to use a 8-bit PIC from hardware perspective, but as this topic is not discussing the hardware features it's unfair to not recommended 8-bit PICs in general. You may need to use a 8-bit PIC to reach a pricepoint, simplify hardware by using a CLC or 16-bit PWM DC/DC module, etc.Quote from: nctnico on November 17, 2015, 06:28:26 pmYou need to select the compiler mode as in Free, Std and Pro. The license just unlocks each tier and will turn on some (safe?) optimizations in the compiler. Some of which are really necessary, like tidying up the output of the assembler code generator. GCC at -O0 also produces crap code. In XC16/32 you do get -O1 for free which makes it livable IMO. But it often breaks debugging.However I think there are 2 additional flags, like debug and speed which will likely finetune the assembler output slightly. I am not sure how aggressive these are at each compiler mode. This would be worth testing at some point.

author: MT
author_rank: Super Contributor
timestamp: November 17, 2015, 09:51:17 pm
content: Quote from: Howardlong on November 16, 2015, 10:59:47 pmPIC32MX250 in DIP for instantaneous use early Saturday morning naked out of bed with an idea to test on plastic veroboard is nicebut that practice is no more for me since ST etc makes do LQFP32 (some devices) it is then a small stretch to make DIP board for itin 30 minutes.The problem is PicKit 3 who cant supply current enough to run a small standalone setups + off board faff and it's oftena hassle to setup from zero compared to Nucleos, Discoveries who always have some extra bananas able to supply this additional offboard faff to do these early Saturday morning tests without having to fire up the entire laboratory! All my old PIC and MSP code i haveported to ARM and that was easier then to actually set up ST peripherals. just my 5 cent!

author: nctnico
author_rank: Super Contributor
timestamp: November 17, 2015, 10:24:28 pm
content: Quote from: neslekkim on November 17, 2015, 07:50:36 pmI scanned through the article but I can't find where the author tries to compare 'pro mode' with no optimisation versus 'free mode'. If 'free mode' produces crappier code than 'pro mode' without optimisation than the author has a point stating the code generated by the free mode is deliberatly made longer.

author: Howardlong
author_rank: Super Contributor
timestamp: November 18, 2015, 12:54:55 pm
content: Quote from: MT on November 17, 2015, 09:51:17 pmBut that 30 minutes is three times longer than I take to get a PIC32 up and runningQuoteI can't say I've had much problem with a PK3 supplying power, I have though had an enormous amount of difficulty in getting it working at all on occasion on MPLAB X, the USB debugger interface is truly flakey, but I can say exactly the same frustrations for NXP with their LPCLink 2/LPCxpresso and TI with their LaunchPads/CCS for different reasons. The NXP problem is the use of using too loosely integrated components that don't recover from faults without restarting most of the dev setup. With TI it turned out to be to do with the change of USB descriptor requirements from initial bootloader mode to operational mode: the device is recognised fine in its initial power up bootloader mode, but when used in CCS it attempts to re-enumerate with different USB parameters which in some heavily subscribed USB scenarios will fail. All of these scenarios take hours if not days to figure out. Hardware debuggers seem to be a continual weak link in pretty much all development environments as long as I can remember, indeed I'm always surprised when they work consistently well!QuoteBut that will be to just one ARM family or subset from one vendor: that is why I cringe about the generic use of "ARM" as if it is some kind of universal panacea. While the same cores may be the same between vendors, everything else is different. The memory layout and interfaces, boot options, peripherals etc. And CMSIS isn't the answer, that ends up being such a compromise that it's usually not worth considering except for the most trivial of tasks like a blinky.In the big scheme of things whether you're running a core from ARM, MIPS or a proprietary one, that is of less relevance than hard considerations such as pricing, availability, reliability, speed, power consumption, integration level and functionality, together with soft considerations such as available skill sets, familiarity and existing investment in development tools.As an example I have a battery powered project I'm working on the uses a triple core ARM for the main processing and a PIC24 for the power control including regulation of three power domains, plus charging and on/off. The reason for the PIC24? It will run directly from 5V or a LiIon battery without regulation, plus it has a sub microamp standby. In short, couldn't find a better device for the specifications I had.

author: MT
author_rank: Super Contributor
timestamp: November 18, 2015, 07:13:54 pm
content: HowardlongQuoteExactly,that's why i prefer the Microsticks over Pickit3. I can be naked while coding!Hmm, it is peculiar in some way as ones get older one have less time to faff and learn yet another toolset,yet another MCU, yet another peripheral etc. Time is everything.QuoteWell, its an awful long time ago we used dsPIC's ,PIC24 and PIC32 but i recall PICkit3 had very little current to deliver out of the box. Hmm, i clearly read somewhere.....ah here the note, i might be entirely wrong as VDD_Target is delivered from USB but from Pickit3 user guide page 70 quote:Note: The PICkit 3 programmer/debugger is powered through its USB connection. The target board is poweredfrom its own supply. Alternatively, the PICkit 3 can power it only if the target consumes less than 30 mA.30mA is strangely low considering it's sourced from USB.MPLABX, aaaah well, that brings back awful memories! Did they ever fix it?QuoteThat i had no idea about! Thanks for info! In contrast ST-link works surprisingly well.QuoteYes but i didn't say it was a universal panacea just that it was easy to port code in those particularly cases and that includes , suprice some of the peripherals, for example MSP430 Timers is quite similarly to ST even uses same wording for reg bits. But ofcourse it depends how complicated, convoluted ones code ,peripheral are, it also might be very difficult, we was lucky i suppose.QuoteIn general yes but many things these days can be reconsidered, development tools for instance in the same way as the absolute need forlatest Altium one can get away with P99se or ANY other depending on what the requirements is for your product or in which market segment your company/you operates in.QuoteWho makes triple ARM core MCU's?

author: Howardlong
author_rank: Super Contributor
timestamp: November 18, 2015, 09:53:20 pm
content: Quote from: MT on November 18, 2015, 07:13:54 pmNXP, LPC4370.

author: ale500
author_rank: Frequent Contributor
timestamp: November 19, 2015, 06:39:14 am
content: In all seriousness, did someone here actually got microchip's xc32 compiled from sources ? Yes, I read it multiple times, I have yet to find someone who did it. (I found it described in a website...).I tried 3 times in cygwin, mingw and linux 32 bit. It doesn't compile in any of them and it aborts at different times....

author: andersm
author_rank: Super Contributor
timestamp: November 19, 2015, 07:56:39 am
content: Quote from: ale500 on November 19, 2015, 06:39:14 amThere was just athreadon Microchip's forums where someone did it.

author: Howardlong
author_rank: Super Contributor
timestamp: November 19, 2015, 08:05:14 am
content: Quote from: ale500 on November 19, 2015, 06:39:14 amMost of the work appeared to be around fooling the licensing wrapper interface which itself is continually evolving.

author: andersm
author_rank: Super Contributor
timestamp: November 19, 2015, 08:42:15 am
content: Quote from: Howardlong on November 19, 2015, 08:05:14 amIIRC the license checks are not enabled by default.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: November 19, 2015, 12:45:00 pm
content: Ive compiled x32 from microchips sources zip files multiple times. On linux its a cakewalk, run 'make' and done..

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: November 25, 2015, 03:43:06 pm
content: Quote from: AndyC_772 on November 16, 2015, 09:18:42 pmWhy not consider a PIC32? I realize that ARM is the current media and fanboi darling, but they're no better than PIC32 when it really comes down to it. Sure, the PIC32 uses a MIPS core, but MIPS is just as capable as ARM. There are differences, of course, but nothing that makes an ARM core intrinsically better than a MIPS core.The PIC32 has a lot going for it. There's a broad lineup of parts, including parts available in DIP packages, from low-end to high-end. Microchip has a free IDE (MPLAB X) which is quite capable, a free C compiler (which is restricted to lower levels of optimization, but since it's based on GCC you can always download the source and compile it to bypass the restrictions), and inexpensive debug tools (PICKit3, ICD3).Microchip's datasheets and user's guides tend to be better than their competitors, especially non-US based competitors. Microchip also tends to support their MCUs for long periods, which is very handy if you design long-lived products.Micicrochip's latest PIC32, the PIC32MZ, certainly gives the Cortex-M7 a run for its money with a clock speed of 200 MHz, up to 2MB of FLASH and 512K of RAM, a double precision FPU (the only Cortex-M7 I've seen so far is the STM32F7, which only has a single precision FPU). The MZ did have teething problems when Microchip released it too early with too many errata, but they've recently released a new revision that cleans up most of the issues.So, if you want to hang with the popular kids on the block, by all means go the ARM route, but if you want a 32-bit MCU that works, has good documentation and tools, and don't mind marching to the beat of a different drummer, don't dismiss the PIC32.

author: nctnico
author_rank: Super Contributor
timestamp: November 25, 2015, 09:04:17 pm
content: Good tools??? Why would I bother with a crippled compiler when I can get a fully working GCC for ARM which is maintained by ARM for free?And why would I bother with a broken chip in whichmostof the problems are solved? I use NXP's ARM devices and in those you rarely find show stopping problems.Besides that going the ARM route provides a lot of community support and many vendors support ARM fully. If you need some cutting edge digital signal processing routines in highly optimised assembly code you are much likely to find them for ARM than for MIPS. I have been down the MIPS road before and it was like being cast away on a deserted island.

author: Howardlong
author_rank: Super Contributor
timestamp: November 25, 2015, 10:43:09 pm
content: Quote from: nctnico on November 25, 2015, 09:04:17 pmThe recently released PIC32MZ EF devices are an order of magnitude better than the EC devices released with its pants down by its ankles eighteen months earlier. I can't imagine many projects have made it to production with the older EC chips. The EFs are another kettle of fish entirely. More concerning is the frikkin' Harmony Framework that you pretty much have to use to do anything more than a blinky, forget forking out a kilo dollar for a compiler, the Harmony Framework is by far the biggest barrier to getting anything production ready, although it's a lot better than it was a year or so ago. Almost every time I use it I find another bug!Every time in my life I've come across software frameworks it's been painful because you have to fundamentally change your programming design and style around somebody else's supposed "best practice". It's like getting into a car and the foot pedals are switched around. I just wish they'd forget forcing us to use frameworks and just give us simple consistent, full function, performant, light weight and working peripheral APIs to use instead, plus USB and IP stacks done in a similar manner.

author: westfw
author_rank: Super Contributor
timestamp: November 25, 2015, 11:20:15 pm
content: Quotewhy do you "have" to use it? Surely the peripherals aren't so complex and poorly documented that you can't use them without the vendor middleware?

author: Howardlong
author_rank: Super Contributor
timestamp: November 26, 2015, 12:06:04 am
content: Quote from: westfw on November 25, 2015, 11:20:15 pmAs soon as you want to use USB or Ethernet, you have to use their framework... Unless you fancy writing your own drivers and stacks that is.

author: Throy
author_rank: Regular Contributor
timestamp: November 26, 2015, 06:24:01 am
content: I'm forced to work with the Microchip tools everyday since we're not allowed to use anything other than Microchip.And I have to say I often get really annoyed and frustrated with their debugging tools.I have here sitting on my desk a RealICE and a Pickit3. The RealICE will lose its communications with MPLABX in the middle of debugging many times a day and I'm forced to unplug and plug it back in to the USB. The Pickit3 is just way too slow for me since I mainly work with the PIC32MX series. It takes quite a long time to program the target. Another lovely bug that I ran into yesterday with both debuggers was I'd set a breakpoint in the code, the device itself would stop, but in MPLABX it showed the device as still running!

author: Howardlong
author_rank: Super Contributor
timestamp: November 26, 2015, 08:55:25 am
content: Quote from: Throy on November 26, 2015, 06:24:01 amI feel your pain. This won't help much but the ICD3 is as fast as the RealICE and suffers fewer bugs.

author: nctnico
author_rank: Super Contributor
timestamp: November 26, 2015, 09:36:51 am
content: Quote from: Throy on November 26, 2015, 06:24:01 amThis is exactly why I have given up on on-target debugging a long time ago. It just never works reliable which is frustrating like hell. I use a command interpreter & terminal and other tools (edit: testing/debugging code on a PC) to debug code instead.

author: dannyf
author_rank: Super Contributor
timestamp: November 26, 2015, 08:43:29 pm
content: QuoteI have been the biggest fan there is of Hi-tech pic compilers, up til 9.61 (I think), just before they introduced the ocg compilers. The pro and non-pro compilers (9.61 and earlier) produce tight and robust code.Now, I am the biggest fan of their XC8 compilers: my tests suggest that the free XC8 compilers are on par or slightly ahead of the non-pro / standard PICC compilers, and the pro XC8 compilers are way ahead of the pro PICC compilers.I was never a fan of C18.XC16 is a copy of the old C30 - very good.Now, I use mostly XC8 and C30.

author: boz
author_rank: Regular Contributor
timestamp: December 08, 2015, 09:09:02 am
content: Gosh Guys, Lots of Doom and gloom here!I do all my projects, even commercial ones using the free versions of XC32 and XC8, the latest versions are both fine compilers and work well with the IDE and debuggers .Crippled is probably a bit strong a word, adding 10-20% percent to the memory requirements is annoying at worst but the only time I remember this affecting me was having to move from an 18F23K22 to a 18F24K22 which put my BOM up $0.20If I do the math on my last project which used an AT90USB646 (https://easyeda.com/editor#id=S0UNjdvpjd), Yes I got a free fully optimised compiler (woohoo!) but had to pay US$9.30 for the chip

author: ez24
author_rank: Super Contributor
timestamp: December 08, 2015, 08:33:24 pm
content: QuoteIs this suppose to bring something special up?

author: boz
author_rank: Regular Contributor
timestamp: December 09, 2015, 05:30:01 am
content: Just Another Arduino Clone I made for a friend a few weeks ago, as its open source I thought I'd include the link to the board, feel free to ignore.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: December 09, 2015, 01:57:10 pm
content: Quote from: boz on December 09, 2015, 05:30:01 amjust loads a blank eda schematic page for me

author: westfw
author_rank: Super Contributor
timestamp: December 09, 2015, 06:09:54 pm
content: QuoteI see a pcb layout, with traces outlined for CNC milling (?)QuoteIt used to be MUCH worse than that. Like I said earlier, I'd heard rumors that the "less optimization level" had been improved, but I've seen surprisingly little info on exactly when or how much...

author: Delta
author_rank: Super Contributor
timestamp: December 09, 2015, 11:50:43 pm
content: Quote from: westfw on December 09, 2015, 06:09:54 pmI've done some testing with XC8 v1.34, and the free mode doesn't seem too bad at all now to be fair. However earlier versions DID generate pointless MOV instructions, and if you google around you will find ASM snippets generated by Hi Tech C that were littered with NOPs! However fair play, they seem to have sorted that out now...

author: boz
author_rank: Regular Contributor
timestamp: December 11, 2015, 08:44:29 pm
content: Quote from: westfw on December 09, 2015, 06:09:54 pm