FYI - Received an email from Microchip today with the above subject line. Similar
text as that found here, read from License Change Notice: https://www.microchip.com/mplab/compilers Two key points: - All MPLAB XC PRO licenses activated after this date (September 1, 2020) will expire after one year unless the HPA is renewed - An existing MPLAB XC PRO license will change to this new model as the HPA is renewed and applied to it. Where HPA = High Priority Access. Presently gives (existing owners) an ungrade to the latest version plus any other new versions released in the next 12 months. So the compiler will stop working after 12 months unless one pays a yearly license fee. I imagine it stops working in Pro mode, and instead falls back to the free/un-licensed mode with little to no optimization. Where fully optimized code is essential, this effectively means it stops working. Feels like it might be an un-popular change, especially for those with smaller budgets. I was quite accepting of HPA as it was... ability to upgrade only as and when required, e.g. starting a new project with a new chip, and ability to maintain older projects at will. -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Sounds like a good time to re-investigate unlocking ...
On 28/07/2020 8:24 am, Brent Brown wrote: > FYI - Received an email from Microchip today with the above subject line. Similar > text as that found here, read from License Change Notice: > > https://www.microchip.com/mplab/compilers > > Two key points: > > - All MPLAB XC PRO licenses activated after this date (September 1, 2020) will > expire after one year unless the HPA is renewed > > - An existing MPLAB XC PRO license will change to this new model as the HPA is > renewed and applied to it. > > Where HPA = High Priority Access. Presently gives (existing owners) an ungrade to > the latest version plus any other new versions released in the next 12 months. > > So the compiler will stop working after 12 months unless one pays a yearly license > fee. I imagine it stops working in Pro mode, and instead falls back to the > free/un-licensed mode with little to no optimization. Where fully optimized code is > essential, this effectively means it stops working. > > Feels like it might be an un-popular change, especially for those with smaller > budgets. I was quite accepting of HPA as it was... ability to upgrade only as and > when required, e.g. starting a new project with a new chip, and ability to maintain > older projects at will. > -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by Brent Brown-2
I seem to recall that previously this was the case, and they may have
changed, and it looks like they are changing back. However the free versions of XC8 and XC16 allow you to use -O2, which for a lot of people is all they need. The other thing to note is that if really squeezed for room or speed you can buy the PRO license by the month, so most of the development can be done in free mode then further optimisation can be done with a short term license purchase. The ones who will be hit hardest will be those who have the accredited compiler which will only run in PRO mode. I wonder how this affects people who have the dongle version of the PRO license. On Mon, 27 Jul 2020 at 23:25, Brent Brown <[hidden email]> wrote: > > FYI - Received an email from Microchip today with the above subject line. Similar > text as that found here, read from License Change Notice: > > https://www.microchip.com/mplab/compilers > > Two key points: > > - All MPLAB XC PRO licenses activated after this date (September 1, 2020) will > expire after one year unless the HPA is renewed > > - An existing MPLAB XC PRO license will change to this new model as the HPA is > renewed and applied to it. > > Where HPA = High Priority Access. Presently gives (existing owners) an ungrade to > the latest version plus any other new versions released in the next 12 months. > > So the compiler will stop working after 12 months unless one pays a yearly license > fee. I imagine it stops working in Pro mode, and instead falls back to the > free/un-licensed mode with little to no optimization. Where fully optimized code is > essential, this effectively means it stops working. > > Feels like it might be an un-popular change, especially for those with smaller > budgets. I was quite accepting of HPA as it was... ability to upgrade only as and > when required, e.g. starting a new project with a new chip, and ability to maintain > older projects at will. > > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by David Duffy (AVD)
Might I suggest that, rather than outright revolt, perhaps defection as an alternate route? AVR and STM32 are both quite capable...
Best regards, Bob ________________________________________ From: [hidden email] <[hidden email]> on behalf of David Duffy (AVD) Sent: Monday, July 27, 2020 3:53 PM To: Microcontroller discussion list - Public. Subject: Re: [PIC]: MPLAB XC C Compiler License Change Sounds like a good time to re-investigate unlocking ... On 28/07/2020 8:24 am, Brent Brown wrote: > FYI - Received an email from Microchip today with the above subject line. Similar > text as that found here, read from License Change Notice: > > https://www.microchip.com/mplab/compilers > > Two key points: > > - All MPLAB XC PRO licenses activated after this date (September 1, 2020) will > expire after one year unless the HPA is renewed > > - An existing MPLAB XC PRO license will change to this new model as the HPA is > renewed and applied to it. > > Where HPA = High Priority Access. Presently gives (existing owners) an ungrade to > the latest version plus any other new versions released in the next 12 months. > > So the compiler will stop working after 12 months unless one pays a yearly license > fee. I imagine it stops working in Pro mode, and instead falls back to the > free/un-licensed mode with little to no optimization. Where fully optimized code is > essential, this effectively means it stops working. > > Feels like it might be an un-popular change, especially for those with smaller > budgets. I was quite accepting of HPA as it was... ability to upgrade only as and > when required, e.g. starting a new project with a new chip, and ability to maintain > older projects at will. > -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Em 27/07/2020 23:06, Bob Blick escreveu:
> Might I suggest that, rather than outright revolt, perhaps defection as an alternate route? AVR and STM32 are both quite capable... > > Best regards, Bob That's what I'm doing. Most of my new projects are using ARM devices. For now I'm still using Cortex-M3 (SAM3) devices, from Atmel/Microchip. If they change their compiler's license policy for ARM devices, then I will migrate definitively to STM. Right now I'm experimenting with STM's Cortex-M7 devices. My RTOS is not ready for Cortex-M7, but soon I will have to byte the bullet and do the conversion. STM's STM32H7xxx are fantastic devices. Much more powerful than Microchip's and still less expensive. Cheers, Isaac -- Este email foi escaneado pelo Avast antivírus. https://www.avast.com/antivirus -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
I would still be a big proponent of Microchip C if it weren't for XC...
and early Harmony. That was when I was getting into PIC32's. I still do PIC18's with MPLAB 8.x though However, I'm now into ARM. Mostly STM32-flavoured because they offer significant package/feature choices, and pricing is good. Some dev options: - First Keil and IAR offer their ARM tools free for Cortex-M0/M0+ devices, and for limited code side (IIRC 32K). - However, a couple years ago, ST purchased Atollic TrueStudio and offered it for free for any of their processors, and they've now revised/morphed that into STM32CubeIDE. Yes, it's Eclipse-based, but pretty decent if you take a moment to learn to use it and workspaces. - There are surprisingly many other development paths, which I've been capturing in a flowchart. The latest version is here... http://orlandorobotbuilders.com/stuff/STM32_Getting_Started-v0_6.png ST's discussion forum is disappointing, but feel free to join us on STM32 Developers FB group, Cheers, -Neil On 7/27/2020 10:18 PM, Isaac M. Bavaresco wrote: > Em 27/07/2020 23:06, Bob Blick escreveu: >> Might I suggest that, rather than outright revolt, perhaps defection as an alternate route? AVR and STM32 are both quite capable... >> >> Best regards, Bob > > That's what I'm doing. Most of my new projects are using ARM devices. > > For now I'm still using Cortex-M3 (SAM3) devices, from Atmel/Microchip. > If they change their compiler's license policy for ARM devices, then I > will migrate definitively to STM. > > Right now I'm experimenting with STM's Cortex-M7 devices. My RTOS is not > ready for Cortex-M7, but soon I will have to byte the bullet and do the > conversion. > > STM's STM32H7xxx are fantastic devices. Much more powerful than > Microchip's and still less expensive. > > > Cheers, > > Isaac > > > -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
On Mon, Jul 27, 2020 at 11:28:03PM -0400, Neil wrote:
> http://orlandorobotbuilders.com/stuff/STM32_Getting_Started-v0_6.png > "Do you have excess money spilling out of your pockets?" Nice one! Laughed in enjoyment. I'm familiar with the platformio pathway, or the editor w/GCC & makefiles. We used Keil for 8051 on the OLPC XO series. -- James Cameron http://quozl.netrek.org/ -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by Neil
I just discovered Keil for 8051 for free... Silicon Labs offer a licence key for anyone
who registers. It seems to retail for about USD1500. Revived a project that has a SiLabs C8051F120 (no slouch for an 8051, runs @ up to 100MIPS). Began with HiTech 8051 C about 8 years ago, but Microchip bought them and dropped it, so we switched to SDCC (free). Recently customer mentioned it was taking them up to 15 minutes to compile, seems chip was getting close to full. Price checked IAR, they wanted AUD5000. Ported to Keil it builds in 20s and code shrunk by 30-40%. (Actually just upgraded my CPU/RAM and now it compiles in 3s~!) Not the flashest IDE, but perfectly usable... and exceptional value for money~! Well, that's my good news compiler story, worth sharing. Even though the above example is not Microchip, it does hint at some of the reasons their licence change doesn't suit me particularly. I have a handful of longer term projects that get feature additions now via new firmware. Last compiler upgrade I did was maybe 6 years ago... no hardware changes in at least that long. I may well use more (newer) Microchip parts in the future and require a compiler upgrade... but that introduces an expiry date ~ and forces into on-going yearly updates. Similar happened with Altium Designer... for a couple of years I was using it a lot fopr some contract work and I could justify, but only just, paying ~USD1000/yr for upgrades and support. They increased that to ~USD1500/yr and I opted out. Then I think they started wanting backdated payments to fill in the gaps if/when one wanted to "resume" support. I waited quite a few years until they had a special "once only" trade-in offer including 2 years upgardes & support. On 27 Jul 2020 at 23:28, Neil wrote: > I would still be a big proponent of Microchip C if it weren't for XC... > and early Harmony. That was when I was getting into PIC32's. > I still do PIC18's with MPLAB 8.x though > > However, I'm now into ARM. Mostly STM32-flavoured because they offer > significant package/feature choices, and pricing is good. > > Some dev options: > - First Keil and IAR offer their ARM tools free for Cortex-M0/M0+ > devices, and for limited code side (IIRC 32K). > - However, a couple years ago, ST purchased Atollic TrueStudio and > offered it for free for any of their processors, and they've now > revised/morphed that into STM32CubeIDE. Yes, it's Eclipse-based, but > pretty decent if you take a moment to learn to use it and workspaces. > - There are surprisingly many other development paths, which I've been > capturing in a flowchart. The latest version is here... > http://orlandorobotbuilders.com/stuff/STM32_Getting_Started-v0_6.png > > ST's discussion forum is disappointing, but feel free to join us on > STM32 Developers FB group, > > Cheers, > -Neil > > On 7/27/2020 10:18 PM, Isaac M. Bavaresco wrote: > > Em 27/07/2020 23:06, Bob Blick escreveu: > >> Might I suggest that, rather than outright revolt, perhaps defection as an alternate route? AVR and STM32 are both quite capable... > >> > >> Best regards, Bob > > > > That's what I'm doing. Most of my new projects are using ARM devices. > > > > For now I'm still using Cortex-M3 (SAM3) devices, from Atmel/Microchip. > > If they change their compiler's license policy for ARM devices, then I > > will migrate definitively to STM. > > > > Right now I'm experimenting with STM's Cortex-M7 devices. My RTOS is not > > ready for Cortex-M7, but soon I will have to byte the bullet and do the > > conversion. > > > > STM's STM32H7xxx are fantastic devices. Much more powerful than > > Microchip's and still less expensive. -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by Neil
> http://orlandorobotbuilders.com/stuff/STM32_Getting_Started-v0_6.png
I am firmly in the GCC/makefiles camp, but I guess I am not typical - educational rather than industry - C++ (I don't want the code bloat from using C) - I want to switch lightly between chips (mainly Cortexes, but sometimes AVR or MPS430) -- Wouter "Objects? No Thanks!" van Ooijen -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
That's a handy little decision chart, confirms I'm in the right place with
STMCube. On Tue, 28 Jul 2020 at 15:38, Wouter van Ooijen <[hidden email]> wrote: > > http://orlandorobotbuilders.com/stuff/STM32_Getting_Started-v0_6.png > > I am firmly in the GCC/makefiles camp, but I guess I am not typical > > - educational rather than industry > > - C++ (I don't want the code bloat from using C) > > - I want to switch lightly between chips (mainly Cortexes, but > sometimes AVR or MPS430) > > -- > Wouter "Objects? No Thanks!" van Ooijen > > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- Clint. M0UAW IO83 *No trees were harmed in the sending of this mail. However, a large number of electrons were greatly inconvenienced.* -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by Wouter van Ooijen
> - C++ (I don't want the code bloat from using C)
I hear the opposite generally - have you ever managed to do a C++ program for a 16F series? C++ is generally seen as producing larger code than C. On Tue, 28 Jul 2020 at 15:38, Wouter van Ooijen <[hidden email]> wrote: > > > http://orlandorobotbuilders.com/stuff/STM32_Getting_Started-v0_6.png > > I am firmly in the GCC/makefiles camp, but I guess I am not typical > > - educational rather than industry > > - C++ (I don't want the code bloat from using C) > > - I want to switch lightly between chips (mainly Cortexes, but > sometimes AVR or MPS430) > > -- > Wouter "Objects? No Thanks!" van Ooijen > > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
(Wild speculation) Maybe Wouter meant that he can express complex logic and
memory operations more concisely in C++ than C? In my experience, well written C++ at best is only "as good" as well written C. Sometimes, the C++ binaries can be a little larger than C ones when more advanced language features are used. -Jason White On Tue, Jul 28, 2020 at 11:46 AM Alan Pearce <[hidden email]> wrote: > > - C++ (I don't want the code bloat from using C) > > I hear the opposite generally - have you ever managed to do a C++ > program for a 16F series? > C++ is generally seen as producing larger code than C. -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Free forum by Nabble | Edit this page |