Author Topic: MPLAB X a PIC inhibitor! Alternatives ?  (Read 76677 times)

0 Members and 1 Guest are viewing this topic.

Offline fourtytwo42Topic starter

  • Super Contributor
  • ***
  • Posts: 1183
  • Country: gb
  • Interested in all things green/ECO NOT political
MPLAB X a PIC inhibitor! Alternatives ?
« on: November 03, 2017, 07:17:48 pm »
I have been using PIC micro's for years using MPLAB 8.92 apparently being the last release before MPLAB X was introduced, I did try X when it first came out, didn't like it and stuck to plain MPLAB.

Recently needing extra power I was looking at several of the DsPIC33 series, everything was fine till I discovered they were not supported in MPLAB 8.92 so downloaded the latest MPLAB X.

OMG how horrible! firstly it is very very super slow apparently due to it's Java base, but IMOP it is very unfriendly, I keep code with all the other project documents and expect to invoke the toolchain from there, not so with X. It probably falls into the classification of trying to do to much and none of it well.

I have no intention of wasting my time on such junk so will abandon any idea of using chips exclusively supported by it. Does anybody have experience of faster and more user friendly tool chains supporting 16/32 bit micro's that are free and run on windows (assembly only is fine) ?
 

Offline eugenenine

  • Frequent Contributor
  • **
  • Posts: 865
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #1 on: November 03, 2017, 07:38:53 pm »
My laptop is at least 5 years old and I don't find it slow.  But there are other tool chains such as sdcc.
 

Offline gocemk

  • Regular Contributor
  • *
  • Posts: 84
  • Country: mk
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #2 on: November 03, 2017, 07:41:17 pm »
I have the same problem. Currently i'm working on a project with dsPIC33EP512MU810 and MPLAB X under windows 10. The IDE is soooooo slow, even on SSD! Was searching the net these days for a better alternative, but couldn't find any. EmBitz: https://www.embitz.org] [url]https://www.embitz.org[/url] sounded like a good candidate, but unfortunately dsPIC33EP is not supported. Installed MPLAB X v.4.05 today and it doesn't feel any better. Also, the code parser is still giving false errors and highlighting on startup.   :palm:
 
The following users thanked this post: fourtytwo42

Offline fourtytwo42Topic starter

  • Super Contributor
  • ***
  • Posts: 1183
  • Country: gb
  • Interested in all things green/ECO NOT political
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #3 on: November 03, 2017, 07:54:11 pm »
My laptop is at least 5 years old and I don't find it slow.  But there are other tool chains such as sdcc.
I think (maybe wrong) these are all 8 bit micro's, I use mplab 8.92 for those with no problems but I need a 16 or 32 bit micro with either dsp extensions or so many mips it doesn't matter!
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #4 on: November 03, 2017, 07:58:43 pm »
Which DsPIC33s are you looking at?
 

Offline fourtytwo42Topic starter

  • Super Contributor
  • ***
  • Posts: 1183
  • Country: gb
  • Interested in all things green/ECO NOT political
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #5 on: November 03, 2017, 08:01:23 pm »
https://www.embitz.org sounded like a good candidate, but unfortunately dsPIC33EP is not supported. Installed MPLAB X v.4.05 today and it doesn't feel any better. Also, the code parser is still giving false errors and highlighting on startup.   :palm:
That's why I am thinking something ARM based would be far better insofar as toolchains are concerned and capable of doing the job.
 

Offline fourtytwo42Topic starter

  • Super Contributor
  • ***
  • Posts: 1183
  • Country: gb
  • Interested in all things green/ECO NOT political
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #6 on: November 03, 2017, 08:04:12 pm »
Which DsPIC33s are you looking at?
Things like dsPIC33EV32GM102 to get a 16 bit SPI to run external dacs as well as a good selection of analogue peripherals.
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #7 on: November 04, 2017, 07:06:30 am »
Eh, they wanted a multiplatform IDE (netbeans) that wans't eclipse. I actually dislike eclipse very, very much so i don't mind..
i'm afraid all your concerns (slow, parser errors - you have to click reparse project from project right click menu, other quirks) are really netbeans problems.
Why not move everything to visual studio? I wish, but then you'll lose mac and linux users
Maybe they should make it easier to use the compilers with other IDEs but i bet this would bring in a lot of headache if you have to fix bugs for N IDEs rsther than for just one

In the end i don't care if X is slow.. it's actually slow if you have some 20+ projects loaded as the parser will keep scanning them for external changes (you can force the parser to use just one thread or how many as you wish)
First loading and the very first compilation of the day are the slow ones. Just long enough so i can make a cup of tea
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #8 on: November 04, 2017, 08:15:09 am »
OMG how horrible! firstly it is very very super slow apparently due to it's Java base, ...

No problems here, probably because I use Linux. Windows & Java is not a good combination imho.
On Linux, Java runs like a rocket.

Apart from that, the XC compilers can be slow due to the license checking mechanism.
For the XC16 and XC32 compilers this can be easily fixed with a little editing described somewhere else
on this forum. Nice side effect is that you will be able to use higher optimization settings.
 
The following users thanked this post: austfox

Offline mrpackethead

  • Super Contributor
  • ***
  • Posts: 2845
  • Country: nz
  • D Size Cell
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #9 on: November 04, 2017, 08:31:51 am »
I use MPLABx 4.05 every day on windows and mac, and it works just fine for us. 
On a quest to find increasingly complicated ways to blink things
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #10 on: November 04, 2017, 08:45:15 am »
I agree regarding speed, but you get used to it.

In comparison to other IDEs I’ve used, from a performance perspective, MPLAB X is a painful development environment, and long running bugs, such as the parser breaking, they don’t seem to give a crap about. Anecdotally, I think the parser “feature” only seems to affect the 16 bitters IME, but it’s been there for several versions of MPLAB X and XC16.

In the edit-compile-program-debug cycle, it is painful compared to MPLAB 8.xx. I strongly suspect this is due to the JNI Java/native interface with a very chatty application/debugger protocol. You can alleviate some of it by telling it to maintain a debugger connection.

I find that MPLAB X is also unstable particularly when using hardware debuggers. It simply stops talking to debuggers for no apparent reason. On one occasion the only way I could restart a debug session was a full reboot each time it crashed as it left a Java shim in memory that I just couldn’t terminate. It’s frustrating and time wasting to say the least.

The compiler licensing check thing was fixed some time ago, but it was more evidence, it were ever needed, that their QA is shit.

Another way to speed things up is to limit the number of projects you have open, although if you have a lot of cores on your machine it does scale.

I just wish they’d invest their efforts in making a fluid UI rather than fannying around with bug infested code generators. I started using Atmel Studio a year or so ago for a couple of projects, it’s just so much slicker, I even thought the debugger wasn’t working, it’s so quick to program. I’m afraid that won’t please the non-Windows folk.
 
The following users thanked this post: fourtytwo42

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #11 on: November 04, 2017, 09:59:13 am »
I use MPLAB X from time to time, but I'm usually disappointed.

Netbeans is not very stable. I'm not sure if it's better than Eclipse, even though I really hate Eclipse but that could be more due to bad plugins than Eclipse itself.

In alot of cases the code scanner stops working, as such syntax highlighting and auto completion is completely broken. To fix, restart the IDE. But being the clunky JAVA IDE that it is, it needs to pull a full load briefly on this i7 quad-core+HT machine with Linux.

For other microcontrollers I tend to program in an editor like Qt Creator or CLion, which works absolutely fine. Sure CLion is also quite a heavy tool to use, but atleast it's fluent in usage while in the background processes are hammering along to scan your code and libraries.
If only they would release something like a GDB server for PIC24s and PIC16s, then it should be quite easy to integrate the XC compilers into any GNU compatible IDE.
« Last Edit: November 04, 2017, 12:53:07 pm by hans »
 
The following users thanked this post: fourtytwo42

Offline fourtytwo42Topic starter

  • Super Contributor
  • ***
  • Posts: 1183
  • Country: gb
  • Interested in all things green/ECO NOT political
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #12 on: November 04, 2017, 10:16:04 am »
Thank you for all your replies, it seems I am not the only one that finds this toolchain unacceptably clunky, I don't expect tools to get in the way of code development!

I started this quest as I have an application that needs at least a 10 bit flash DAC along with at least an 8x8 multiply, unfortunately DAC's are far and few between on PICs, the audio ones not being flash. A simple alternative I thought was an external SPI device however I soon found many PIC SPI interfaces are hobbled at 8 bit only whereas the SPI DACS have at least a 16 bit protocol.  I have compiled a very short list of those pic's supported by MPLAB 8, available in DIP packages and having a 16 bit SPI for anybody interested :)

Device/series   MPLAB   16b SPI   SrcPincl/moq   3/5V   MIPS   ADCb/ssec   Cmp/Oa   Prog/ramK   Pins
PIC24F16KA102   Y   Y   FNK270/1   3   16   10/0.5M   2cmp   16/1.5   28
PIC24FJ32GA002   Y   Y   FNL296/1   3   16   10/0.5M   2cmp   32/8   28
PIC24HJ32GP202   Y   Y   FNL365/1   3   40   10/12/1M/0.5M   0   32/2   28
dsPIC33FJ32GP302   Y   Y   RS448/1   3   40   10/12/1M/0.5M   2cmp   32/4   28
PIC24HJ32GP302   Y   Y   FNL501/1   3   40   10/12/1M/0.5M   2cmp   32/4   28
PIC24HJ64GP502   Y   Y   FNL527/1   3   40   10/12/1M/0.5M   2cmp   64/8   28
PIC24HJ128GP502   Y   Y   FNL576/1   3   40   10/12/1M/0.5M   2cmp   128/8   28

Note RS = Radiospares and FNL = Farnell, I dont bother with high moq parts.
 

Offline Ash

  • Regular Contributor
  • *
  • Posts: 161
  • Country: au
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #13 on: November 04, 2017, 11:00:42 am »
Yep, its crap... MPLAB X is just terribly slow on my PC. It often gets confused and had non-stopping "parsing project xxxxx" messages, especially if I have several projects open at once.

I have a whole list of gripes but it does come down to being used to something like Visual Studio (there is a Linux version call "Visual Studio Code",  I think, I've not used it).

Also because I'm working on PIC32MZ project almost exclusively in C++ (XC32 compiler is actually pretty good/modern thanks to is being gcc, the shipped std library I avoid though, I use ETLCPP http://www.etlcpp.com) but the C++ support in MPLAB is essentially non-existent. Errors and warning constantly in the code that is actually perfectly fine..

Also don't get me started on Harmony.. Argh.. But that is another gripe altogether :) (basically just don't is my advice). |O

Once I get some time, I'll be reverting to manual Makefiles and XC32 directly I think.

Also I get very little use from the debugger - mostly it can't tell me anything, almost all variables I try to inspect are not found.. totally useless I think in my project. I have to debug using logging/pin toggling/'scope anyway so I'm not loosing anything and I'll be able to use an editor of my choice rather than the stuff in MPLAB X.

My suggestion: get familiar with the makefile flavour of your choice and use command line builds, then use what ever editor you find most comfortable :) If you build a bootloader as the first part of your project, you then won't even need a PIC programmer much after that (assuming your device support self programming)...

Ash.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #14 on: November 04, 2017, 12:10:11 pm »
What speed 10-bit DAC are you after, and how many channels?
 

Online bookaboo

  • Frequent Contributor
  • **
  • Posts: 725
  • Country: ie
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #15 on: November 04, 2017, 01:15:07 pm »
Something to mitigate the compile cycle courtesy of Mike:

https://youtu.be/jXVWk-7OFvY?t=16m45s
 
The following users thanked this post: fourtytwo42

Offline jpanhalt

  • Super Contributor
  • ***
  • Posts: 3395
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #16 on: November 04, 2017, 01:50:57 pm »
Here's a link to a thread with comments from some quite knowledgeable individuals who describe  workarounds for using MPLabX with chips that are not and presumably never will be included in MPLab 8.92:

http://www.electro-tech-online.com/threads/assembly-on-the-mplab-x-ide-how.152124/

John
 
The following users thanked this post: fourtytwo42

Offline fourtytwo42Topic starter

  • Super Contributor
  • ***
  • Posts: 1183
  • Country: gb
  • Interested in all things green/ECO NOT political
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #17 on: November 04, 2017, 04:29:16 pm »
What speed 10-bit DAC are you after, and how many channels?
Only one channel but settling in <= 25uS. The other key is in combination with one clock multiply so sadly the 16F cores wont do.

Also thanks for the links guys, I have to say they don't inspire me with confidence, right bag of worms for us assembly programmers, and before you say it I do write in C but not time critical stuff on itsi little processors!
« Last Edit: November 04, 2017, 04:33:20 pm by fourtytwo42 »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #18 on: November 05, 2017, 07:21:43 am »
Quote
I don't expect tools to get in the way of code development!
Hmm.  I do.  Always.  Figuring out how to properly bash your head against whatever toolset you're using is usually a significant percentage of any project.  Especially if you're NEW to that toolset.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #19 on: November 05, 2017, 08:00:01 am »
I had a similar aversion to MPLABX for a long time, but have recently had to use it for newer devices and actually now prefer it.
The one thing I discovered that makes it a lot less painful is the option   "Maintain active connection to hardware tool" in options->embedded. This makes it behave more like MPLAB8 and speed is now similar.

The editor is way better, with formatting, folding  and realtime syntax checking and prompting of constants ( e.g. you type "IFS0bits." and it pops up a list of values).

The things I don't like :
The error reporting is confusing with all the "xxx in recipie yyy" fluff before the real error message.
Unnecessarily deep nesting of directories
When you have mulltiple projects open , it's not immediately obvious which file belongs to which project  -Mouseover the tab shows the path, but it needs to be more obvious to avoid accidentally editing the wrong file, like changing the tab colour for the selected project
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #20 on: November 05, 2017, 08:08:51 am »
Here's a link to a thread with comments from some quite knowledgeable individuals who describe  workarounds for using MPLabX with chips that are not and presumably never will be included in MPLab 8.92:

http://www.electro-tech-online.com/threads/assembly-on-the-mplab-x-ide-how.152124/

John
It's quite easy to get MPLAB8 to work with minor chip variations, e.g. PIC32MX170 - from memory I think it's just one file that needs changing to alias the device ID and parameters onto an unused similar one.
 
Oh and by the way for anyone using ICD3 and swapping between MPLAB8 and X with different device families, there is an issue, that I think is related to FPGA versions,which sometimes makes it not work under 8 after using the switcher.
The fix is, when moving from X to 8, before using the switcher, run MPLAB IPE, select the target device you want to use with 8, connect, let it do whatever firmware update it wants, then exit and run the switcher.

It's nice that at least Microchip recognises that people still want to use 8 and provide the driver switcher.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #21 on: November 05, 2017, 08:11:31 am »
I do wonder if maybe there are some machine or configuration-dependent things that make X slower for some people - I'm very sensitive to slow build/run cycles and I find it pretty tolerable, on not-crazy-fast hardware.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #22 on: November 05, 2017, 08:15:09 am »
I find that MPLAB X is also unstable particularly when using hardware debuggers. It simply stops talking to debuggers for no apparent reason. On one occasion the only way I could restart a debug session was a full reboot each time it crashed as it left a Java shim in memory that I just couldn’t terminate. It’s frustrating and time wasting to say the least.

I use MPLAB X in Linux, works reasonable good. But sometimes the programmer stops working as well. Fortunately I can kill all Java processes with "killall -9 java" and it really does kill every java process, when a normal kill doesn't work.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 12806
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #23 on: November 05, 2017, 08:20:09 am »
One thing that may be causing a lot of people grief is the Microchip MPLAB X and compiler teams *DO* *NOT* run any virus checker that deep scans files on their development PCs.  As MPLAB X consists of a very large number of Jar files containing its Java code, if you don't exclude everything in and below the Microchip folder in 'Program Files' from your Antivirus solution's scan on read and scan on execute, you can experience an order of magnitude slowdown launching MPLAB X or changing operating modes within MPLAB X (i.e doing a build, or opening a different type of information or properties window or dialog).   Scan on write is permissible for the Microchip folder tree, but will slow down the compilers when building large projects, due to their use of intermediate files.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #24 on: November 05, 2017, 08:49:32 am »
I find that MPLAB X is also unstable particularly when using hardware debuggers. It simply stops talking to debuggers for no apparent reason. On one occasion the only way I could restart a debug session was a full reboot each time it crashed as it left a Java shim in memory that I just couldn’t terminate. It’s frustrating and time wasting to say the least.

I use MPLAB X in Linux, works reasonable good. But sometimes the programmer stops working as well. Fortunately I can kill all Java processes with "killall -9 java" and it really does kill every java process, when a normal kill doesn't work.

I use MPLABX on Linux a lot for PIC32 development using an ICD3. I never experienced that. But I never use the debugger.
 

Offline fourtytwo42Topic starter

  • Super Contributor
  • ***
  • Posts: 1183
  • Country: gb
  • Interested in all things green/ECO NOT political
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #25 on: November 05, 2017, 10:31:41 am »
Hello and once again thank you for your many comments and help, I think part of my problem is possibly my ancient laptop that however serves me well, it uses an Intel T2300 @ 1.6Ghz together with 2Gb of 980Mhz ram and of course a standard mechanical hard drive. For most applications I use this is adequate but not comparable in any way with the performance of a high end system BUT it is quiet, consumes little power and paid for itself long ago! I also use Windows XP SP3 as it is reliable! I use a good virus checker and very good router-firewall for protection, yup there's a risk to downloads but the system can be rebuilt from backups in half a day.

As for the PIC issues I have expended considerable effort fitting the project into the constraints of devices supported by MPLAB 8 as I have no intention of buying a new laptop for MPLAB X (Oops just discovered unsuccessful). So in future for more DSP like projects I can see the ARM based products are probably the way to go, better to invest the learning curve in something with flexible tool paths than being stuck with one tool only with serious shortcomings IMOP.

Another potential path that I have some historical knowledge of is to use FPGA's using the hardware to do the required DSP extensions for a small embedded mpu. BTW I have no problems running Verilog/VHDL compilers on this laptop so it is not that slow!! MPLAB X must be total bloatware!!
« Last Edit: November 05, 2017, 11:59:47 am by fourtytwo42 »
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #26 on: November 05, 2017, 11:25:03 am »
Hello and once again thank you for your many comments and help, I think part of my problem is possibly my ancient laptop that however serves me well, it uses an Intel T2300 @ 1.6Ghz together with 2Gb of 980Mhz ram and of course a standard mechanical hard drive.
Upgrading to an SSD is a no-brainer these days. 
MPLABX runs fine on my Lenovo X220
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #27 on: November 05, 2017, 11:53:16 am »
One thing that may be causing a lot of people grief is the Microchip MPLAB X and compiler teams *DO* *NOT* run any virus checker that deep scans files on their development PCs.  As MPLAB X consists of a very large number of Jar files containing its Java code, if you don't exclude everything in and below the Microchip folder in 'Program Files' from your Antivirus solution's scan on read and scan on execute, you can experience an order of magnitude slowdown launching MPLAB X or changing operating modes within MPLAB X (i.e doing a build, or opening a different type of information or properties window or dialog).   Scan on write is permissible for the Microchip folder tree, but will slow down the compilers when building large projects, due to their use of intermediate files.

This is a good point, I have been known to switch off real time virus checking on lower spec PCs as the various AV components chew up enormous amounts of CPU when starting up MPLAB X and using it’s various components for the first time.

MPLAB X is also a very memory hungry beast, and it gets worse the more you use it in a single session, it doesn’t seem to return resources well without restarting it, much of it JITed bloat as far as I can determine. This particularly affects some plug-ins like MHC, and also if you have multiple projects open, particularly those generated by Harmony, which create a gazillion files to flash an LED.

2GB RAM is at the very lowest limit I consider viable, and I’d avoid running anything else at the same time.

 
The following users thanked this post: fourtytwo42

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 12806
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #28 on: November 05, 2017, 12:10:03 pm »
I misstated the above - scan on write is permissible for the Microchip program folder tree - it rarely gets written to.   Realtime scanning can slow down compilation if activated for the project folder tree, but is usually tolerable.
« Last Edit: November 05, 2017, 12:11:36 pm by Ian.M »
 

Offline TomS_

  • Frequent Contributor
  • **
  • Posts: 834
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #29 on: November 05, 2017, 12:39:09 pm »
I think part of my problem is possibly my ancient laptop that however serves me well, it uses an Intel T2300 @ 1.6Ghz together with 2Gb of 980Mhz ram and of course a standard mechanical hard drive.

 :palm:

You owe yourself at least an SSD - memory swapping might not impose quite as much of a performance hit. Or at the very least more physical memory, if it can take more...
 
The following users thanked this post: JPortici

Offline eugenenine

  • Frequent Contributor
  • **
  • Posts: 865
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #30 on: November 05, 2017, 05:07:47 pm »
My laptop is about the same specs, your problem is the OS.  You can't do any serious dev work in windows, its just too inefficient.  When MS releases XP they disabled the registry keys that you could control the swap threshold in windows 2000 to make XP memory inefficient in order to sell their own hypervisor.  So you have 2G of ram but it starts swapping after utilizing 1G and in something like a big IDE like mplabx, eclipse, visual studio its trying to read/write the files its compiling all while its trying to read/write swap.  When I was at a small company and stuck on XP I put in a separate drive for sawp just so it wasn't fighting itsself but now at big company I don't have any say over the hardware or os and even MS visual studio with 16G or ram is still slow.
 
The following users thanked this post: fourtytwo42

Offline fourtytwo42Topic starter

  • Super Contributor
  • ***
  • Posts: 1183
  • Country: gb
  • Interested in all things green/ECO NOT political
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #31 on: November 05, 2017, 09:23:10 pm »
I think unfortunately this laptop is past its sell by date insofar as extending the memory as I think it only accepts <= 1Gb sims and its already full. Suffice to say I have spent ALL DAY compiling a list of PIC's that will both fulfill the requirements AND be supported by MPLAB 8. I have decided the only way to get my dacs and multiply is to use external dacs however this requires a 16 bit SPI interface and not all PIC SPI interfaces are alike even in 16/32 bit processors hence the whole day's work just for that!

But I have to say Microchip are still way ahead of the competition on silicon price, I can get a 16 bit 70MIP processor with extensive maths landed on my caves doorstep for UK£3.60 (about the same in any other currency these days) and there is nothing out there Armwise that can compete with that in through hole packaging (or did I miss something  :scared: ).
 

Offline eugenenine

  • Frequent Contributor
  • **
  • Posts: 865
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #32 on: November 05, 2017, 10:11:09 pm »
I wasn't saying its a needs more ram problem, its an OS problem, boot under a Linux distro and try mplab x (or eclipse, or whatever) and see how much better it runs.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #33 on: November 06, 2017, 12:00:31 am »
While I too applaud Microchip for maintaining a substantial selection of DIP parts, nowadays you are seriously restricting your options.

I’m not sure of the rationale regarding having to be through hole? If it’s for a kit for end user assembly I guess I can understand. If it’s for solderless breadboarding, you can use breakout boards which would dramatically increase the options available to you.
 

Offline fourtytwo42Topic starter

  • Super Contributor
  • ***
  • Posts: 1183
  • Country: gb
  • Interested in all things green/ECO NOT political
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #34 on: November 06, 2017, 09:32:59 am »
I wasn't saying its a needs more ram problem, its an OS problem, boot under a Linux distro and try mplab x (or eclipse, or whatever) and see how much better it runs.
I am sorry I should have explained I have to many other tools etc built up over many years that are often windows only and dual boot whilst possible is an unnecessary complexity to me. I am not anti-linux, quite the opposite I have written kernal based code for it over the years but when it comes to my primary engineering PC other matters force the choice.
 

Offline fourtytwo42Topic starter

  • Super Contributor
  • ***
  • Posts: 1183
  • Country: gb
  • Interested in all things green/ECO NOT political
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #35 on: November 06, 2017, 09:36:34 am »
I’m not sure of the rationale regarding having to be through hole? If it’s for a kit for end user assembly I guess I can understand. If it’s for solderless breadboarding, you can use breakout boards which would dramatically increase the options available to you.
Its called DIY on a shoestring! I don't want the added £50+ per project for a pcb, nor do I want the extra size of a development board or breakout. 99% of my stuff is built on stripboard and is often compact.
« Last Edit: November 06, 2017, 09:38:45 am by fourtytwo42 »
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #36 on: November 06, 2017, 10:07:28 am »
https://shop.mikroe.com/compilers/compilers-pic


Or move to ARM and get's a big list to chose
« Last Edit: November 06, 2017, 10:09:07 am by ebclr »
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 12806
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #37 on: November 06, 2017, 12:59:39 pm »
MikroElektronika's toolchain is known for being a closed source walled garden that lags well behind Microchip's current device support.   That's fine if you go into it eyes wide open, but if, to get reasonable performance, you are going to have to use a 3rd party IDE or editor and integrate the compilers and programming tool yourself, you might as well do the same with the Microchip XC compilers, MPASM assembler if you need it, and Microchip IPE or IPECMD for programming, and at least get sourcecode for all the libraries, and support for recent devices. 

Also the cost of entry is significantly lower as PICkit 3 clone programmer/debuggers are dirt cheap, the XC licences don't prohibit commercial use in Free mode, and you can rent Pro mode for a reasonable monthly fee.

OTOH Mikroelektronica's hardware is worth looking at if you are adverse to soldering,  as they do build some nice development boards that are far more configurable than similar ones from Microchip, and many of their accessory 'Clik' boards are well thought out
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #38 on: November 06, 2017, 01:32:40 pm »
" XC licences don't prohibit commercial "

They do because the so-called no optimisation of the free version, injects a lot of trash on the code, and the performance is terrible on free mode, It's impossible to use  on anything that  really uses the power of the CPU, since 60% of the time will be in nop's, and bad code
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #39 on: November 06, 2017, 01:34:13 pm »
I like MikroElektronika because Pascal can be used, and I really like Pascal
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #40 on: November 06, 2017, 01:43:49 pm »
" XC licences don't prohibit commercial "

They do because the so-called no optimisation of the free version, injects a lot of trash on the code, and the performance is terrible on free mode, It's impossible to use  on anything that  really uses the power of the CPU, since 60% of the time will be in nop's, and bad code
That's only the case for XC8 ( and I think less so nowadays than it used to be). 
XC16 and XC32 are totally useable in free mode
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 
The following users thanked this post: hans, gocemk

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #41 on: November 06, 2017, 01:50:02 pm »
" XC licences don't prohibit commercial "

They do because the so-called no optimisation of the free version, injects a lot of trash on the code, and the performance is terrible on free mode, It's impossible to use  on anything that  really uses the power of the CPU, since 60% of the time will be in nop's, and bad code
That's only the case for XC8 ( and I think less so nowadays than it used to be). 
XC16 and XC32 are totally useable in free mode

XC16 and XC32 are GCC compilers with some modifications. It's licensed under the GPL and everybody can use it with all optimizations enabled. No need to buy a stupid license from Microchip...
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #42 on: November 06, 2017, 08:45:23 pm »
the so-called no optimisation of the free version, injects a lot of trash on the code,
Not exactly true. It's just that with no optimization XC8 doesn't take the trash out of the code.

And it's not always as bad as you might think. Here are  two listings of a minimal 'blinky.c' for the 16F630, compiled with XC8 in free and pro modes. Can you figure out which one is which?

Code: [Select]
_main:
movlw 7
movwf 25 ;volatile
bsf 3,5 ;RP0=1, select bank1
clrf 5 ;volatile
clrf 7 ;volatile
l492:
bcf 3,5 ;RP0=0, select bank0
bcf 5,1 ;volatile
bsf 5,1 ;volatile
goto l492
__end_of_main:

Code: [Select]
_main:
movlw 7
bcf 3,5 ;RP0=0, select bank0
movwf 25 ;volatile
bsf 3,5 ;RP0=1, select bank1
clrf 5 ;volatile
clrf 7 ;volatile
l492:
bcf 3,5 ;RP0=0, select bank0
bcf 5,1 ;volatile
bsf 5,1 ;volatile
goto l492
__end_of_main:
 
 
Now compare that to similar code for the ATmega328, compiled with avr-gcc in Os and O0 modes:-

Code: [Select]
/* blinky.c */
#include <avr/io.h>

int main(void)
{
   DDRB=0xFF;
   PORTB=0x00;
   while(1)
   {
      PORTB|=0x1; 
      PORTB&=~0x01;
   }
}


Code: [Select]
  80: 8f ef        ldi r24, 0xFF ; 255
  82: 84 b9        out 0x04, r24 ; 4
  84: 15 b8        out 0x05, r1 ; 5
  86: 28 9a        sbi 0x05, 0 ; 5
  88: 28 98        cbi 0x05, 0 ; 5
  8a: fd cf        rjmp .-6      ; 0x86 <main+0x6>
  8c: f8 94        cli
  8e: ff cf        rjmp .-2      ; 0x8e <__stop_program>


Code: [Select]
  80: df 93        push r29
  82: cf 93        push r28
  84: cd b7        in r28, 0x3d ; 61
  86: de b7        in r29, 0x3e ; 62
  88: e4 e2        ldi r30, 0x24 ; 36
  8a: f0 e0        ldi r31, 0x00 ; 0
  8c: 8f ef        ldi r24, 0xFF ; 255
  8e: 80 83        st Z, r24
  90: e5 e2        ldi r30, 0x25 ; 37
  92: f0 e0        ldi r31, 0x00 ; 0
  94: 10 82        st Z, r1
  96: a5 e2        ldi r26, 0x25 ; 37
  98: b0 e0        ldi r27, 0x00 ; 0
  9a: e5 e2        ldi r30, 0x25 ; 37
  9c: f0 e0        ldi r31, 0x00 ; 0
  9e: 80 81        ld r24, Z
  a0: 81 60        ori r24, 0x01 ; 1
  a2: 8c 93        st X, r24
  a4: a5 e2        ldi r26, 0x25 ; 37
  a6: b0 e0        ldi r27, 0x00 ; 0
  a8: e5 e2        ldi r30, 0x25 ; 37
  aa: f0 e0        ldi r31, 0x00 ; 0
  ac: 80 81        ld r24, Z
  ae: 8e 7f        andi r24, 0xFE ; 254
  b0: 8c 93        st X, r24
  b2: f1 cf        rjmp .-30      ; 0x96 <main+0x16>
  b4: f8 94        cli
  b6: ff cf        rjmp .-2      ; 0xb6 <__stop_program>
« Last Edit: November 07, 2017, 03:34:38 pm by Bruce Abbott »
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #43 on: November 06, 2017, 09:09:06 pm »
I’m not sure of the rationale regarding having to be through hole? If it’s for a kit for end user assembly I guess I can understand. If it’s for solderless breadboarding, you can use breakout boards which would dramatically increase the options available to you.
Its called DIY on a shoestring! I don't want the added £50+ per project for a pcb, nor do I want the extra size of a development board or breakout. 99% of my stuff is built on stripboard and is often compact.

If it helps, I come from the same school.

An option I now use frequently for SMD are Busboard SMT protoboards http://www.busboard.com/surfacemountpcbs which allows you to easily mount SOIC devices and passives down to 01005. I even do small BGAs and CSPs on it by turning them upside down and breaking them out myself with fine wire strands. The boards with the solid copper ground plane are the ones to go for, you have a reasonable chance of maintaining signal integrity up to reasonably high speeds with them.

Getting a homebrew PCB process running is another option for surface mount, but it takes some time to master, and there will be plenty of failures along the way. I can turn around a board when the wife’s not looking in the kitchen from start to finish in half an hour. Admittedly I do dislike doing PCB layout, but you can do fine pitch QFP and QFN this way, certainly 0.5mm is easily achievable.
 
The following users thanked this post: fourtytwo42

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #44 on: November 07, 2017, 02:17:54 am »
Getting a homebrew PCB process running is another option for surface mount, but it takes some time to master, and there will be plenty of failures along the way. I can turn around a board when the wife’s not looking in the kitchen from start to finish in half an hour. Admittedly I do dislike doing PCB layout, but you can do fine pitch QFP and QFN this way, certainly 0.5mm is easily achievable.

I do most of the prototyping on breadboards. Less on PCBs. I used to make my own PCBs. It would take me few hours to design, build, drill, and solder something that I could test on. Now I just order (mostly from Oshpark) - takes an hour or so to design, then 3 weeks to get it. It is much better quality that I could master, and it is actually cheaper than all the boards, chemicals, drill bits and stuff - typically only few dollars to order. I don't mind the delays - often boards sit on my shelf for few weeks until I get to them. I still solder some, but reflow is much faster.

 
The following users thanked this post: fourtytwo42

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #45 on: November 07, 2017, 05:55:15 am »
Quote
Code: [Select]
PORTB&=!0x01;
That code is incorrect, you know...  "!" is logical NOT.  You need "~" for bitwise NOT (thus producing somewhat "weird" code.)

I've heard  that the current versions of XC8 produced much better output than the initial "no optimization" version, and I think I believe that.  But ... the damage to Microchip's reputation has been done, and I hope it sends a message to compiler authors everywhere.

 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #46 on: November 07, 2017, 11:39:41 am »
Getting a homebrew PCB process running is another option for surface mount, but it takes some time to master, and there will be plenty of failures along the way. I can turn around a board when the wife’s not looking in the kitchen from start to finish in half an hour. Admittedly I do dislike doing PCB layout, but you can do fine pitch QFP and QFN this way, certainly 0.5mm is easily achievable.

I do most of the prototyping on breadboards. Less on PCBs. I used to make my own PCBs. It would take me few hours to design, build, drill, and solder something that I could test on. Now I just order (mostly from Oshpark) - takes an hour or so to design, then 3 weeks to get it. It is much better quality that I could master, and it is actually cheaper than all the boards, chemicals, drill bits and stuff - typically only few dollars to order. I don't mind the delays - often boards sit on my shelf for few weeks until I get to them. I still solder some, but reflow is much faster.

Most of my non-RF prototyping is done on breadboards too. When I do my own PCBs it's 99%+ SMD parts, so the overhead of drilling is far less, and almost always it's for unit testing rather than a complete finished system: for the final spins it's off to the board house. The design rules I use for self-etching is quite different to when I farm it out: vias are larger (0.6mm vs 0.3mm drill) due to drill limitations, track and gap are larger (0.2mm [8 mil] track and gap vs 0.125mm [5mil]) in that I generally leave the underside solid copper ground plane and the only vias are for ground connections. This in itself limits the need for true double sided, and usually there are only a handful, if any, inter-board wire connections to make. For RF ground plane stitching, the accuracy isn't too critical for the frequencies I am interested in.
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #47 on: November 07, 2017, 04:32:16 pm »
Quote
Code: [Select]
PORTB&=!0x01;
That code is incorrect, you know...  "!" is logical NOT.  You need "~" for bitwise NOT (thus producing somewhat "weird" code.)
You are right! (note: the PIC code was correct, I blame my keyboard!). When corrected the unoptimized avr code is even more bloated...

Quote
I've heard  that the current versions of XC8 produced much better output than the initial "no optimization" version, and I think I believe that.  But ... the damage to Microchip's reputation has been done, and I hope it sends a message to compiler authors everywhere.
And the message is - expect idiots who don't know what they are talking about to damage your reputation.  Give people free stuff and all they do is complain about it! No wonder other vendors only offer time or code-size limited demos.
 
The following users thanked this post: JPortici

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #48 on: November 07, 2017, 05:29:33 pm »
But ... the damage to Microchip's reputation has been done, and I hope it sends a message to compiler authors everywhere.
And the message is - expect idiots who don't know what they are talking about to damage your reputation.  Give people free stuff and all they do is complain about it! No wonder other vendors only offer time or code-size limited demos.

I don't think XC8 damaged Microchip position, but MPLAB X certainly did. MPLAB 8 had problems, but it was Ok. I don't need much of IDE and MPLAB 8 was quite enough for me. MPLAB X is big, has lots of features that I don't use (although there are some nice ones such as generating config settings), but it is slow, it always interferes with my editing, dynamically highlights things which I don't need. Seach/replace function is horrible. Multi-project functionality is really annoying. Somehow, all the stuff that I use the most is buried deep in the menus. I still use MPLAB 8 when I can.
 

Offline thm_w

  • Super Contributor
  • ***
  • Posts: 6272
  • Country: ca
  • Non-expert
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #49 on: November 07, 2017, 09:51:48 pm »
Another potential path that I have some historical knowledge of is to use FPGA's using the hardware to do the required DSP extensions for a small embedded mpu. BTW I have no problems running Verilog/VHDL compilers on this laptop so it is not that slow!! MPLAB X must be total bloatware!!

CPU is 11 years old, do yourself a favor and pick up a desktop (preferably) or laptop on craigslist from this decade.
The first SSD laptop I saw on craigslist was $180 for i7 620M, passmark 2741, vs the T2300 at 732.

If only everyone was as thoughtful as you and listed their system specs when they claimed some modern software was "too slow".
Profile -> Modify profile -> Look and Layout ->  Don't show users' signatures
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #50 on: November 08, 2017, 07:22:38 am »
If only everyone was as thoughtful as you and listed their system specs when they claimed some modern software was "too slow".
MPlabX is bloatware, and is slow even on relatively modern hardware. But it's not all Microchip's fault. Users were asking for a Linux version, so they did it the only way they knew how - with Java. Instant performance hit. Of course people noticed, but they had an answer - "Just buy a new PC with 10 times faster CPU and 5 times more RAM!". "What, still too slow? Run it in Linux off an SSD!".

I am currently working on a program written in Borland Turbo C++. The editor is a little clunky and doesn't support the mouse wheel, but apart from that it's amazing! 3 seconds after clicking the project icon I am editing the source code. 1 second to compile and run in the debugger. On an 'ancient' Pentium D CPU with a 'mere' 1GB RAM running 'obsolete' Windows Xp. Heaven! 

But I dread running MPlabX to test a few lines of code. Over 1 minute to get a blank page, then another minute or so for 'parsing projects' and 'background scanning' that leaves no CPU time left for what I want to do. Finally it gets to the point where I can start typing in some code, but no! Typing the first character triggers some other process that freezes the cursor for a few seconds. Open a file, change project settings, compile, debug - everything seems to need an annoying amount of time get started. And during all this time MPlabx is sucking up more and more memory - over 500MB to do pretty much the same stuff that MPlab 8.92 does in 150MB. You can't say that isn't bloatware.

I uninstalled Atmel Studio 6 because I kept running out of patience waiting for it to start up. Now Microchip is talking about integrating Atmel parts into MPlabX. Get ready for more bloat!
 
The following users thanked this post: fourtytwo42

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #51 on: November 08, 2017, 07:49:44 am »
But I dread running MPlabX to test a few lines of code. Over 1 minute to get a blank page, then another minute or so for 'parsing projects' and 'background scanning' that leaves no CPU time left for what I want to do.
You must be either running on something too ancient to class as a vaguely modern machine,or something is broken or badly configured.
I just tried a  a clean+build on MPLABX 4.05 and XC32 on a project that  generates 100K of code takes 9 secs on my X220, introduced 5 years ago,  which can be had on ebay for £200 or less, with an SSD, maybe £100 tops.
A make with a change to one source file takes under 2 seconds



Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline fourtytwo42Topic starter

  • Super Contributor
  • ***
  • Posts: 1183
  • Country: gb
  • Interested in all things green/ECO NOT political
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #52 on: November 08, 2017, 05:13:29 pm »
But I dread running MPlabX to test a few lines of code. Over 1 minute to get a blank page, then another minute or so for 'parsing projects' and 'background scanning' that leaves no CPU time left for what I want to do.
You must be either running on something too ancient to class as a vaguely modern machine,or something is broken or badly configured.
I just tried a  a clean+build on MPLABX 4.05 and XC32 on a project that  generates 100K of code takes 9 secs on my X220, introduced 5 years ago,  which can be had on ebay for £200 or less, with an SSD, maybe £100 tops.
A make with a change to one source file takes under 2 seconds
Personally I have no wish to expend my scarce resources on some high end toy so that I can go on about how fast I can run various bits of bloatware, as I said before it is supposed to be a tool, not an end in itself. Please confine your comments to geeks who wish to genuflect over needlessly powerful machines and pointlessly complicated software! Personally I stick to the KISS principle every time, Keep It Simple Stupid.
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #53 on: November 08, 2017, 05:55:33 pm »
I just tried a  a clean+build on MPLABX 4.05 and XC32 on a project that  generates 100K of code takes 9 secs...
A make with a change to one source file takes under 2 seconds
You don't understand, it's not the speed of compilation that's the issue, but the time it take for MPlabX to get the point of being able to compile some code. Kiel Microvision takes 12 seconds to get up and running, Atmel Studio 4 takes 13 seconds, Embitz 20 seconds, MikroC Pro 21 seconds, MPlab 8.92 40 seconds (slow, but still acceptable). And once these IDEs get going they are relatively clean and responsive, unlike MPlabX which continues to do 'background' stuff that just gets in the way.

Unfortunately if you want to program the latest PICs there is no practical alternative to MPlabX, because it hides the chip configuration inside its database and trying to generate it by hand is just too painful. However once it has created a project with the required make file etc., you can compile from a batch file and use your favorite text editor to work on the source. Gets rid of the bloat, but is not quite as convenient as a proper IDE.

I like having a GUI with buttons to click on etc. rather than having to type in commands, but only when the response is immediate so it feels like I am in control. We have computers which are so powerful they should be able to do most stuff instantly, not be hobbled by bloatware.
 
Quote
...on my X220, introduced 5 years ago,  which can be had on ebay for £200 or less, with an SSD
That 'under £200' computer might cost me over NZ$700 once freight and customs duty was paid, then I would have to spend time setting it up. And it probably won't run Xp so I would have to get used to using an OS that I don't like. Why should I invest that kind of time and money (which I can't afford right now) just to program a $1.50 chip?   

Sure I have an 'ancient' computer with a mechanical hard drive that could do with a defrag, but its lower performance just makes the issue more apparent. I have another more powerful machine running Linux which is assigned to another job. MPlabX is faster on it, but still has unexpected lags and still uses over 0.5GB of RAM. The fact remains that Java based IDEs are sluggish and MPlabX is bloated. That such bloat can be masked by throwing more hardware at it is irrelevant.

 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #54 on: November 08, 2017, 06:29:24 pm »
Just for kicks, it took 17 seconds for me to cold-boot MPLABX and let it finish background scanning of projects. Visual studio takes more time.

intel NUC7i5 with SSD, 8GB Ram.
I have just a couple projects open on this PC.

On the computer at work it takes something like 60 seconds but it is
-a laptop with a 5th gen i5
-no ssd (i really have to tell the guy to upgrade my pc, i know.)
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #55 on: November 08, 2017, 08:14:44 pm »
Just for kicks, it took 17 seconds for me to cold-boot MPLABX and let it finish background scanning of projects.

Two pc's here, both running Linux and using ext4 filesystem. One has an ssd, the other has a traditional harddrive.
The one with the ssd takes 15 seconds to start MPLABX and finish scanning the project.
The one with the traditional harddisk takes 12 seconds... :-//
 

Offline thm_w

  • Super Contributor
  • ***
  • Posts: 6272
  • Country: ca
  • Non-expert
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #56 on: November 08, 2017, 08:16:00 pm »
MPlabX is bloatware, and is slow even on relatively modern hardware. But it's not all Microchip's fault. Users were asking for a Linux version, so they did it the only way they knew how - with Java. Instant performance hit. Of course people noticed, but they had an answer - "Just buy a new PC with 10 times faster CPU and 5 times more RAM!". "What, still too slow? Run it in Linux off an SSD!".

I am currently working on a program written in Borland Turbo C++. The editor is a little clunky and doesn't support the mouse wheel, but apart from that it's amazing! 3 seconds after clicking the project icon I am editing the source code. 1 second to compile and run in the debugger. On an 'ancient' Pentium D CPU with a 'mere' 1GB RAM running 'obsolete' Windows Xp. Heaven! 

But I dread running MPlabX to test a few lines of code. Over 1 minute to get a blank page, then another minute or so for 'parsing projects' and 'background scanning' that leaves no CPU time left for what I want to do. Finally it gets to the point where I can start typing in some code, but no! Typing the first character triggers some other process that freezes the cursor for a few seconds. Open a file, change project settings, compile, debug - everything seems to need an annoying amount of time get started. And during all this time MPlabx is sucking up more and more memory - over 500MB to do pretty much the same stuff that MPlab 8.92 does in 150MB. You can't say that isn't bloatware.

I uninstalled Atmel Studio 6 because I kept running out of patience waiting for it to start up. Now Microchip is talking about integrating Atmel parts into MPlabX. Get ready for more bloat!

I doubt that computer would run the latest version of Chrome, Firefox, or word well either. Modern software requires a relatively modern PC.
If you are fine with using very old OS and hardware, and older software, and it works for you, that's great. But if you want to run modern software, don't complain that a PC made in the last 10 years is necessary.

Quote
That 'under £200' computer might cost me over NZ$700 once freight and customs duty was paid, then I would have to spend time setting it up. And it probably won't run Xp so I would have to get used to using an OS that I don't like. Why should I invest that kind of time and money (which I can't afford right now) just to program a $1.50 chip?   

I see on trademe.co.nz a desktop i5 with 8GB ram (passmark 6600) for $220 (NZ?). I'm sure better deals can be had, but it tells me that PC's are not unreasonably expensive there.
Profile -> Modify profile -> Look and Layout ->  Don't show users' signatures
 

Offline Fire Doger

  • Regular Contributor
  • *
  • Posts: 207
  • Country: 00
  • Stefanos
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #57 on: November 08, 2017, 08:31:49 pm »
As a new mplab user my experience was: "WTF? dat thing is broken?"
I was trying to learn harmony, every time I open harmony configurator it allocates RAM and doesn't release it on closure... I got 8Gb of RAM, It's not normal an IDE running nothing to fill it up...
As a newbie I love CTRL+SPACE, stops working, restart... :palm:
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #58 on: November 08, 2017, 09:15:05 pm »
If you are fine with using very old OS and hardware, and older software, and it works for you, that's great. But if you want to run modern software, don't complain that a PC made in the last 10 years is necessary.

Why? The software can run quite fast on a PC which has a small fraction of the capabilities of modern PCs. It did run fast enough 20 years ago. But then there were decades of rapid growth in computer capability. Software wise, this produced extremely boated software. It was beneficial to add bloat on top of bloat because all the inefficiencies were eaten by the computer progress soon after the release. Not any more. The bloat of last 5-7 years remains. Software is getting slower and slower, and it also getting buggier and buggier. The public accepts this as necessary evil because they don't know better. The only thing that thrives is gaming - no one will play the games which are slow. Everything else is slow ... And buggy.

Meanwhile these Intel processors are blazingly fast. Have you tried to run any benchmarks on them? How can software be slow on these processors? Are you implying that we must accept the software horrors without complaining?

 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #59 on: November 08, 2017, 09:49:36 pm »
If you are fine with using very old OS and hardware, and older software, and it works for you, that's great. But if you want to run modern software, don't complain that a PC made in the last 10 years is necessary.

Why?
It's just a fact of life, get over it. There is no reason for a vendor to put in any work to support very obsolete hardware when new hardware is cheap. Anyone who can't afford a few hundred bucks to run reasonably modern kit is not a significant customer to them.
Microchip have been good in continuing to support old MPLAB8 via the driver switcher, that's as much as anyone could reasonably ask.

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 
The following users thanked this post: TomS_

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #60 on: November 08, 2017, 10:36:04 pm »
It's just a fact of life, get over it. There is no reason for a vendor to put in any work to support very obsolete hardware when new hardware is cheap.

I don't have MPLAB X on anything quite 10 years old so I perhaps cannot judge well. But I have it on some old PCs (ca 2010), as well as new ones. I didn't really notice much of a difference between MPLAB X performance on these old computers and the new ones. It might be reasonably fast, but it still loads slow, it still has inexplicable delays here and there, bugs. MPLAB 8 (on the same PCs) doesn't have any of these problems. Looking forward, MPLAB X will only get slower, but computers won't get much faster. That is a fact of life.

Cannot really blame Microchip. Everyone does the same.

One poster here has built a PC specially to run Vivado - lots of memory, multi-core processor, cooling - whole enchilada. But it still was slow ...
 

Offline KL27x

  • Super Contributor
  • ***
  • Posts: 4099
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #61 on: November 08, 2017, 10:54:52 pm »
I'll add my experience that MPLAB X and IPE are clunkers.

My computer is less than 5 years old. Nothing special, because I don't play games on it or do video editing. icore 5 3GHz win 7 64bit. 4 measly GB RAM. Maybe RAM is the problem?

If I can buy a computer for 200.00 that runs MPLAB in a way that isn't infuriating, and to do it on Windows, ok fine. I'm more curious what spec on the computer is needed. Is it the processor and clock speed? Is there an issue with 64bit vs 32 bit? How much RAM do you need?

200.00 is chump change, but include time as being AV guy, IT guy, crawling around with a flashlight and plugging/unplugging wires, removing bloatware, getting computer on your network, and reinstalling all your software. And in general, looking at "loading 23%" bars. To heck with the money, it's the time and effort and aggravation.
 

Offline thm_w

  • Super Contributor
  • ***
  • Posts: 6272
  • Country: ca
  • Non-expert
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #62 on: November 08, 2017, 11:01:43 pm »
I'll add my experience that MPLAB X and IPE are clunkers.

My computer is less than 5 years old. Nothing special, because I don't play games on it or do video editing. icore 5 3GHz win 7 64bit. 4 measly GB RAM. Maybe RAM is the problem?

4GB ram is a little low, yes, can't say if it would make a difference for mplab though. Do you have an SSD?
Profile -> Modify profile -> Look and Layout ->  Don't show users' signatures
 

Offline KL27x

  • Super Contributor
  • ***
  • Posts: 4099
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #63 on: November 08, 2017, 11:04:40 pm »
No. If this thread extracts what exactly is needed to run MPLAB X / netbeans on Windows, maybe that would be the best thing to come out of the thread.

When I am up for the 8 hours of work involved in transferring over to a new system, I would keep those in mind. SSD and 16GB RAM is on my list.
 

Offline thm_w

  • Super Contributor
  • ***
  • Posts: 6272
  • Country: ca
  • Non-expert
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #64 on: November 08, 2017, 11:13:16 pm »
No. If this thread extracts what exactly is needed to run MPLAB X / netbeans on Windows, maybe that would be the best thing to come out of the thread.

When I am up for the 8 hours of work involved in transferring over to a new system, I would keep those in mind. SSD and 16GB RAM is on my list.

Samsung SSDs comes with an app to transfer your existing OS/disk over. If your current data is less than the size of the SSD, then its a few clicks. I think it took mine a few hours or less (150GB), you can let it run overnight. You should see noticeable improvements in any other apps you use (load time, etc.).
Profile -> Modify profile -> Look and Layout ->  Don't show users' signatures
 

Offline KL27x

  • Super Contributor
  • ***
  • Posts: 4099
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #65 on: November 08, 2017, 11:33:35 pm »
It also seems like icore 7 vs 5 is a big difference, per some of the responses. Maybe more effect than an SSD.

 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #66 on: November 09, 2017, 12:01:54 am »
It also seems like icore 7 vs 5 is a big difference, per some of the responses. Maybe more effect than an SSD.

Depends on what you want. IMHO, the memory speed is important. With all this multi-threading and hyperthreading memory access is often a bottleneck. The high pin count CPUs (e.g. i7-7800X) have wider memory bus, so when combined with fast DDR4 memory should increase the speed. But they're probably $400-500, plus $500 for motherboard, $150 memory. 200 you wanted to spend on it, may not be enough.

I don't think SSD is important - it is all cached after the first read anyway. Better get rid of the antivirus on your way.

 
The following users thanked this post: KL27x

Offline mrpackethead

  • Super Contributor
  • ***
  • Posts: 2845
  • Country: nz
  • D Size Cell
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #67 on: November 09, 2017, 12:19:20 am »
I do some quite large PIC32 Projects, using MPLAB X ( 4.05 now ) with XC32.   I have a reletively decent workstation at which i work runnign win10.

I7-6700 @ 3.4Ghz, 32GB ram.. mirrored SSD drives, and a decent video card.     The only thing that is 'slow' is start up of MPLABX which takes about 6 seconds to load up all its modules etc.         My machine is not bogged down with lots of other crap, its what i use to 'work' on.    I use the machine for other design work as well,  and having the grunt is just sensible.   

MPLABX is'tn perfect, but its far from the worst, and increasingly i'm just learing that more often than not, the problems i face are of my own making ( due to lack of knowing ) than it being fundementally flawed.



On a quest to find increasingly complicated ways to blink things
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #68 on: November 09, 2017, 03:27:50 am »
Quote
When you have mulltiple projects open , it's not immediately obvious which file belongs to which project  -Mouseover the tab shows the path, but it needs to be more obvious to avoid accidentally editing the wrong file, like changing the tab colour for the selected project
There are options under tools-options-appearance-document tabs- you can have tab colors, parent folder name in tab, etc.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #69 on: November 09, 2017, 04:54:15 am »
More numbers: starting MPLAB X and opening the last project, with a PIC12LF1572 and XC8, one source file, needs 14 s for me after booting (restarting the IDE: 4 s). First time "clean and build main project" needs 6 s, successive clean and builds need less than 2 s. Opening the main.c file needs about 2 s initially, closing and opening again is immediate. Also no delays when editing the source code. So it needs some time to warm up. Not the fastest, but it is very usable.

Computer: Intel i7, 4 GHz, 32 GB RAM (Windows 10 was running in parallel in a VM, with 16 GB RAM reserved when measuring the MPLAB X performance), oldschool spinning harddisk, running on Linux Debian, even with software RAID 1 and software harddisk encryption enabled (unlocked at boot time, good protection against data leaks in case someone steals the computer).
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline jaromir

  • Supporter
  • ****
  • Posts: 337
  • Country: sk
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #70 on: November 09, 2017, 08:42:41 am »
Another set of numbers, cold start of MPLABX to finish of scanning the projects;
1) Main home computer: Intel G1610 with 8G RAM, 64G SSD, running Linux Mint 18 - 16s to start
2) Tiny 11,6" notebook with some old dual core celeron, 4G RAM, SSD, Linux Mint 18 - 21s to start
3) Computer at work - intel i7 2630QM, 8G RAM, SSD, Windows 7 - 15s to start

Notice the tiny difference between 1 and 3 case. Windows can kill the performance of i7 down to level of crappy cheapest dual core.
In all cases there was few processes running in background, like Firefox with few tabs open and some PDF files, cloud sync running, to better "emulate" real life scenario. I bet that after clean start with no other processes the numbers would be better.
At work I leave MPLABX running all the time, so I waste the horrible quarter of minute startup time once per week.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #71 on: November 09, 2017, 09:59:28 am »
Somebody told me that the difference in performance of Java between Linux and windows is because Java was originally developed (and still is?) on POSIX systems (Solaris).
Then it got ported to windows.
So, the problem isn't so much Java, it's the choice of the operating system. If you are forced to use windows, there's not much you can do apart from upgrading your hardware.
IMHO developing and testing on POSIX systems is the sane choice because there's the way microsoft is doing things and there's the way the rest of the world is doing things.
Not to speak about vendor-lockin...
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #72 on: November 09, 2017, 06:37:59 pm »
OMG how horrible! firstly it is very very super slow apparently due to it's Java base, ...

No problems here, probably because I use Linux. Windows & Java is not a good combination imho.
On Linux, Java runs like a rocket.

Apart from that, the XC compilers can be slow due to the license checking mechanism.
For the XC16 and XC32 compilers this can be easily fixed with a little editing described somewhere else
on this forum. Nice side effect is that you will be able to use higher optimization settings.
Not just that. XC16 and XC32 are really just GCC.

For PIC32 you can just use vanilla MIPS32 GNU toolchain (like the one OpenWRT folks use to build programs for routers) and it should work. You may need to get your custom linker script though but I think the ARM Cortex-M linker scripts are good examples for this.

For PIC16 you can grab the XC16 source release from Microchip, patch out license checks and build it yourself. Use your best optimizing compiler and link-time optimizer for fastest resulting code. For XC16 you can also try turn on the C++ language.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #73 on: November 09, 2017, 06:45:47 pm »
Just to drop in on Java: butter smooth on macOS. Quad-core Haswell Xeon E3-1231v3 at 3.6GHz, 32GB RAM, Fusion Drive, macOS Sierra, Java 8. macOS is UNIX by the way, the BSD flavor, just not the Linux flavor.
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #74 on: November 09, 2017, 06:50:49 pm »
MPLAB X must be total bloatware!!

MPLAB X isn't bloatware. The problem is the antique hardware you're trying to run it on. The T2300 came out in 2006. That's eleven years ago! I'm not surprised that X runs slowly on your machine. I'm really surprised that you're able to run FPGA tools on the same machine and not experience the same slowness... What FPGA tools are you running? Vivado? ISE 14.7? Quartus Prime 17?
Complexity is the number-one enemy of high-quality code.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #75 on: November 09, 2017, 07:06:18 pm »
For PIC16 you can grab the XC16 source release from Microchip, patch out license checks and build it yourself.

Much easier and faster: https://www.eevblog.com/forum/microcontrollers/pic32-evolution/msg1007099/#msg1007099

 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #76 on: November 09, 2017, 07:08:20 pm »
Hello and once again thank you for your many comments and help, I think part of my problem is possibly my ancient laptop that however serves me well, it uses an Intel T2300 @ 1.6Ghz together with 2Gb of 980Mhz ram and of course a standard mechanical hard drive. For most applications I use this is adequate but not comparable in any way with the performance of a high end system BUT it is quiet, consumes little power and paid for itself long ago! I also use Windows XP SP3 as it is reliable! I use a good virus checker and very good router-firewall for protection, yup there's a risk to downloads but the system can be rebuilt from backups in half a day.

As for the PIC issues I have expended considerable effort fitting the project into the constraints of devices supported by MPLAB 8 as I have no intention of buying a new laptop for MPLAB X (Oops just discovered unsuccessful). So in future for more DSP like projects I can see the ARM based products are probably the way to go, better to invest the learning curve in something with flexible tool paths than being stuck with one tool only with serious shortcomings IMOP.

Another potential path that I have some historical knowledge of is to use FPGA's using the hardware to do the required DSP extensions for a small embedded mpu. BTW I have no problems running Verilog/VHDL compilers on this laptop so it is not that slow!! MPLAB X must be total bloatware!!

Bingo the decade-old processor is the culprit. Does your laptop have the processor socketed? I have a spare Core 2 Duo T7400 (2.16GHz dual core) for sale if you want it. (My Dell Latitude D620 has a socketed T2300 initially, I upgraded it to T5600, later T7400 and finally, recently T7600. The spare T7400 is now yo to sale.)
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #77 on: November 09, 2017, 07:13:08 pm »
For PIC16 you can grab the XC16 source release from Microchip, patch out license checks and build it yourself.

Much easier and faster: https://www.eevblog.com/forum/microcontrollers/pic32-evolution/msg1007099/#msg1007099
Rebuilding XC16 gives you the chance to enable the “XC++16” option. Also the result compiler can be faster than Microchip’s by applying mainline patches upgrading the base compiler, and use an aggressive optimizing compiler and link time optimization.
 

Offline fourtytwo42Topic starter

  • Super Contributor
  • ***
  • Posts: 1183
  • Country: gb
  • Interested in all things green/ECO NOT political
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #78 on: November 09, 2017, 07:31:27 pm »
I must admit to enjoying and being impressed by everybody's contributions, I think it is good to explore the stripped to basics vs the bloatware approaches :) I have been happily building and debugging some pic24 code for the last few days using MPLAB 8 and ATM I would be challenged to measure anything in seconds even given my terrible decade old hardware! I do like stuff that is both responsive and reasonably simple to use but then of course anything you have used for years is simple compared to anything else :)
As for HDL I must confess since the last virus inspired rebuild I have not re-installed anything so not particularly active on that front ATM but in the past I have used Xylinx, Lattice and Altera without issue except the download time on my very slow rural internet! BTW once again I write everything for micro-controllers in assembler, not C as I am an inveterate clock counter......another crime!

P.S.I just realized something else that may be relevant, this machine has been stripped of anything else that wastes time or is a security risk, so no automatic updates of any kind, nothing auto-starting except the basics, no cruddy flash, never over my dead body java and no microcrap net or whatever its called ewwww!! So most of my parsimoniously small memory is available for ME (OMG I seem to remember an awful windows called that, no I mean ME in person :)))
« Last Edit: November 09, 2017, 07:50:27 pm by fourtytwo42 »
 

Offline mrpackethead

  • Super Contributor
  • ***
  • Posts: 2845
  • Country: nz
  • D Size Cell
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #79 on: November 09, 2017, 07:52:33 pm »
It's just a fact of life, get over it. There is no reason for a vendor to put in any work to support very obsolete hardware when new hardware is cheap. Anyone who can't afford a few hundred bucks to run reasonably modern kit is not a significant customer to them.
Microchip have been good in continuing to support old MPLAB8 via the driver switcher, that's as much as anyone could reasonably ask.

Its hard enough to get any level of significant support when you only buy low $100sk of parts a year.     I've found a few good people to interface directly with and thats helped immensely..     But its been a two way street, i've been finding a few bugs, ( mostly because i always seem to be pushing corner cases ) and then reporting them back to microchip,   sometimes even providing the fixes.   

I'd love them to open the open-source harmony a bit more though, 
On a quest to find increasingly complicated ways to blink things
 

Offline eugenenine

  • Frequent Contributor
  • **
  • Posts: 865
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #80 on: November 09, 2017, 08:41:14 pm »
Hello and once again thank you for your many comments and help, I think part of my problem is possibly my ancient laptop that however serves me well, it uses an Intel T2300 @ 1.6Ghz together with 2Gb of 980Mhz ram and of course a standard mechanical hard drive. For most applications I use this is adequate but not comparable in any way with the performance of a high end system BUT it is quiet, consumes little power and paid for itself long ago! I also use Windows XP SP3 as it is reliable! I use a good virus checker and very good router-firewall for protection, yup there's a risk to downloads but the system can be rebuilt from backups in half a day.

As for the PIC issues I have expended considerable effort fitting the project into the constraints of devices supported by MPLAB 8 as I have no intention of buying a new laptop for MPLAB X (Oops just discovered unsuccessful). So in future for more DSP like projects I can see the ARM based products are probably the way to go, better to invest the learning curve in something with flexible tool paths than being stuck with one tool only with serious shortcomings IMOP.

Another potential path that I have some historical knowledge of is to use FPGA's using the hardware to do the required DSP extensions for a small embedded mpu. BTW I have no problems running Verilog/VHDL compilers on this laptop so it is not that slow!! MPLAB X must be total bloatware!!

Bingo the decade-old processor is the culprit. Does your laptop have the processor socketed? I have a spare Core 2 Duo T7400 (2.16GHz dual core) for sale if you want it. (My Dell Latitude D620 has a socketed T2300 initially, I upgraded it to T5600, later T7400 and finally, recently T7600. The spare T7400 is now yo to sale.)

Even if its an older laptop it still shouldn't be that slow.  I have a Dell Latitude 1100 netbook and mplab X takes under 30seconds to launch, open a project and start building.  This is an Atom CPU  with a whole 2G of RAM.
 

Offline TomS_

  • Frequent Contributor
  • **
  • Posts: 834
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #81 on: November 17, 2017, 08:20:44 pm »
XC16 and XC32 are GCC compilers with some modifications. It's licensed under the GPL and everybody can use it with all optimizations enabled. No need to buy a stupid license from Microchip...

Can you elaborate?

I am working on a project that is using XC16, but if I, for example, try to enable optimisation level 3 through MPLAB X, I just a whole bunch of red nag messages in the build window saying I need to purchase a license.

0 and 1 work just fine though.

Maybe I missed something?
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #82 on: November 17, 2017, 09:17:59 pm »
Maybe I missed something?
You missed the link with dodgy legal advice that tells you how to crack the licence.
 
The following users thanked this post: TomS_

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #83 on: November 18, 2017, 09:04:02 am »
Maybe I missed something?
You missed the link with dodgy legal advice that tells you how to crack the licence.

If you should have read the instructions, you would have noticed that it's not about cracking the license...

The compiler is licensed under the GPL, Microchip can not change that. Everybody is free to modify it.
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 12806
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #84 on: November 18, 2017, 09:42:46 am »
However the Microchip XC16/XC32 runtimes are *NOT* GPLed and IIRC are closed source and only licensed for use with a licensed Microchip XC compiler.  There are various other proprietary components as well (e.g linker scripts). That means you'd have to clean-room reverse engineer, write and build compatible runtimes and other components from scratch to get a clean legal GPL toolchain.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #85 on: November 18, 2017, 03:08:59 pm »
However the Microchip XC16/XC32 runtimes are *NOT* GPLed and IIRC are closed source and only licensed for use with a licensed Microchip XC compiler.

There does not exist something like a "licensed Microchip XC compiler" for PIC16 or PIC32.
You can not change the license of (or re-license) software that comes under the GPL license.
XC16 and XC32 are actually modified GCC compilers.
That means that, according to you, everybody who uses it without a license is at risk anyway.
Obviously, that's not the case.

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

Quote
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.

So, the restrictions of the license does NOT apply to the XC32 and XC16 compilers. You are free to select (switch-on) whatever optimization you like.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #86 on: November 18, 2017, 03:15:09 pm »
So, the restrictions of the license does NOT apply to the XC32 and XC16 compilers. You are free to select (switch-on) whatever optimization you like.

Also, I think that the optimizations in question are mostly part of the original GCC, not something added by Microchip.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #87 on: November 19, 2017, 05:17:32 am »
So, the restrictions of the license does NOT apply to the XC32 and XC16 compilers. You are free to select (switch-on) whatever optimization you like.

Also, I think that the optimizations in question are mostly part of the original GCC, not something added by Microchip.
Even if it is added by Microchip, the second it is added into GCC code tree it is subjected to GPL. Otherwise the GCC Linking Exception will be invalidated and every single piece of code compiled by XC16 and XC32 becomes GPL, making Microchip and all users of PIC24/dsPIC33/PIC32 easy targets for FSF to enforce GPL on. (Remember back when FSF sued Linksys over Linux kernel for GPL?)
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #88 on: November 19, 2017, 06:34:42 am »
Also, I think that the optimizations in question are mostly part of the original GCC, not something added by Microchip.

Quote from: technix
Even if it is added by Microchip, the second it is added into GCC code tree it is subjected to GPL

Quote from: Karel
There does not exist something like a "licensed Microchip XC compiler" for PIC16

Unlike all you internet lawyers, I have neither the training nor sufficient knowledge of how Microchip implemented their license scheme to give reliable legal advice on the subject. However Microchip obviously thinks they have a right to enforce their licenses, and I bet they had actual lawyers check it out. Are you willing to challenge them in court?

But hey, if you think you can get away with it then crack away! Then when Microchip moves to fully proprietary pay-only software with onerous EULAs I will know who to blame.
 
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #89 on: November 19, 2017, 07:53:31 am »
I have neither the training nor sufficient knowledge of how Microchip implemented their license scheme to give reliable legal advice on the subject.

Me neither. That doesn't mean I can't have an opinion about it.

However Microchip obviously thinks they have a right to enforce their licenses, and I bet they had actual lawyers check it out.

It's my opinion that Microchip had their lawyers checkout how to "enforce" a license on a piece of GPL software without getting sued themselves, not how to sue others.

Are you willing to challenge them in court?

I guess the Free Software Foundation will be happy to drag their asses into court if they are going to break balls about the GCC compiler....

But hey, if you think you can get away with it then crack away!

Please don't make the mistake to think it's a crack. It's not.
Microchip hacked the compiler in order to block certain optimizations.
I hacked the compiler to unblock the optimizations.

Then when Microchip moves to fully proprietary pay-only software with onerous EULAs I will know who to blame.

I blame people like you that a company can get away with asking money for software they didn't pay a dime for.
Software that is meant to be free, written by people who want you not only to use it for free, but also encourage you
to hack it and improve it and give back to the community.


« Last Edit: November 19, 2017, 07:55:04 am by Karel »
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #90 on: November 19, 2017, 08:12:00 am »
.... asking money for software they didn't pay a dime for.
So all those device-specific info files, linker scripts, documentation etc. costs nothing to produce ?
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #91 on: November 19, 2017, 08:43:14 am »
.... asking money for software they didn't pay a dime for.
So all those device-specific info files, linker scripts, documentation etc. costs nothing to produce ?

Where did I say that? I was talking about the compiler.
Microchip let you use those device-specific info files, linker scripts, documentation for free. Probably it helps them selling lot's of microcontrollers.
In that case it's just a normal cost that comes with the business.

The hack that undo the hack of Microchip doesn't change (the usage of) those device-specific info files, linker scripts, documentation.
It only affects the GCC compiler optimization setting.
 

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 2277
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #92 on: November 19, 2017, 09:57:07 am »
.... asking money for software they didn't pay a dime for.
So all those device-specific info files, linker scripts, documentation etc. costs nothing to produce ?

In comparison to the cost of GCC's development (which Microchip contributed nothing to and gained much from), yes, nothing.
« Last Edit: November 19, 2017, 10:06:00 am by voltsandjolts »
 

Offline JanJansen

  • Frequent Contributor
  • **
  • Posts: 380
  • Country: nl
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #93 on: November 19, 2017, 01:58:31 pm »
On my PC the new MPLAB X dont even works,
when downloading the old version 2.35 it works.
Ok its very slow to start up, takes at least one minute to initialize, started up once its faster.
While waiting the minute i have visual running in advance to edit code.
The netbeans is a problem, they better remove that.
aliexpress parachute
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #94 on: November 19, 2017, 03:07:35 pm »
Then when Microchip moves to fully proprietary pay-only software with onerous EULAs I will know who to blame.

Blame? That would be very positive.

XC8 is proprietary - it works well given the CPU. MPLAB 8 was proprietary - worked great by my opinion.

XC16 and XC32 are leveraged. XC32 is good because GCC already had implementation for MIPS. But if you look at the Microchip's part - e.g. interrupt prologues/epilogues etc - these are not highly optimized. Neither is XC16 - it doesn't really produce highly optimized code because GCC doesn't have direct support for their CPU (Microchip had to do it by themselves). Microchip is MPLAB X is leveraged, you know how it works ...

Looking at these examples, I am all for proprietary.

If you want either XC16 or XC32 compiler you can simply compile from the source. Moreover, if you have any difficulties doing so, Microchip will help you. The full source code is published and may be downloaded. Microchip is not cheating here. Or, you can buy the pre-compiled version. For most people, it is easier to spend money than to compile, so the vast majority will buy it instead of compiling. Others (me for example) will use the free version which is perfectly perfect for most practical purposes.

This is how the market works. However, this is not an indication that Microchip has put lots of efforts into these compilers. That's the opposite. They used open source GCC for the exact purpose of not spending efforts on the development. And people who buy non-free version don't pay for the Microchip's development effort. If you read the license, the payment is mostly for the on-going support.

 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #95 on: November 19, 2017, 04:57:09 pm »
Then when Microchip moves to fully proprietary pay-only software with onerous EULAs I will know who to blame.
If you want either XC16 or XC32 compiler you can simply compile from the source. Moreover, if you have any difficulties doing so, Microchip will help you. The full source code is published and may be downloaded. Microchip is not cheating here. Or, you can buy the pre-compiled version. For most people, it is easier to spend money than to compile, so the vast majority will buy it instead of compiling. Others (me for example) will use the free version which is perfectly perfect for most practical purposes.

You missed the point. This not about buying the pre-compiled GCC compiler. This is also not about compiling the compiler from source.
This is about modifying/hacking the compiled, GCC compiler, as provided by Microchip i.e. editing the executable in order to unblock the optimizations which have been blocked by Microchip which Microchip did by hacking the GCC source code.
« Last Edit: November 19, 2017, 05:00:43 pm by Karel »
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #96 on: November 19, 2017, 05:16:03 pm »
You missed the point. This not about buying the pre-compiled GCC compiler. This is also not about compiling the compiler from source.
This is about modifying/hacking the compiled, GCC compiler, as provided by Microchip i.e. editing the executable in order to unblock the optimizations which have been blocked by Microchip which Microchip did by hacking the GCC source code.

I understand your idea. I just don't think it's a huge difference between this and compiling. If I wanted the pro version for free (which I don't), I would probably go with compiling. This gives you an opportunity to fix or add something, use more modern version of GCC, etc. One example would be to improve interrupt prologue/epilogue generation for PIC32. You can even fork it and publish it on GitHub if you're so inclined.
 

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 2277
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #97 on: November 19, 2017, 05:22:45 pm »
Thats a good idea.
If you could set up a linux virtualbox machine with the necessary build environment and distribute it that would be much appreciated (and legal of course). Its beyond me  :(
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #98 on: November 19, 2017, 05:31:46 pm »
You missed the point. This not about buying the pre-compiled GCC compiler. This is also not about compiling the compiler from source.
This is about modifying/hacking the compiled, GCC compiler, as provided by Microchip i.e. editing the executable in order to unblock the optimizations which have been blocked by Microchip which Microchip did by hacking the GCC source code.
I just don't think it's a huge difference between this and compiling.

Well, I guess that for most people (at least for me), it is a huge difference. So, if you can provide a step by step manual for dummies like me how to download and compile the GCC sourcecode from Microchip, that would be very nice.

But, also this was not the point. The point was if it's legal or not to hack/modify GPL licensed software.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #99 on: November 19, 2017, 05:39:21 pm »
But, also this was not the point. The point was if it's legal or not to hack/modify GPL licensed software.

Of course it is legal. It is illegal to forbid hacking GPL licensed software. And it is not really a challenge, because GPL means that you get all the source code and a manual how to compile it (and if you don't, it is illegal again and the FSF will be happy to help you), so you can just modify the source code as you like. But don't forget to publish your modifications or a contact address how to get it, because this is required by GPL.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #100 on: November 19, 2017, 05:53:35 pm »
But, also this was not the point. The point was if it's legal or not to hack/modify GPL licensed software.
Of course it is legal.

I agree but it's a little more complicated. If you read back this thread, it appears that some people think that it is perfecly fine
if Microchip hacks the GCC compiler in order to block optimizations but it's not fine when I unblock them by hacking it again.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #101 on: November 19, 2017, 06:00:04 pm »
I just don't think it's a huge difference between this and compiling.
Well, I guess that for most people (at least for me), it is a huge difference.

Have you tried?

So, if you can provide a step by step manual for dummies like me how to download and compile the GCC sourcecode from Microchip, that would be very nice.

I don't need it. But I guess people who did compile it could blog about it or post a video. If you don't see this, it is most likely because there's no demand for such thing.

 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #102 on: November 19, 2017, 06:12:57 pm »
Quote
If you read the license, the payment is mostly for the on-going support.
MCHP would be better off (in my opinion) by just selling 'priority support' (or whatever they currently call it -High Priority Access or something).  Let everyone get the same compiler, whoever wants/needs priority support, they can pay (as they do now). I would assume very little would change for those who currently buy support/extra compiler optimizations. MCHP could then use the resources currently allocated for licensing (dongles, license server, license verification, etc.) to support the actual hardware. Those in charge of XC16/32 could eliminate all the extra code for the various license levels and could work on one single codebase. The Atmel side could do the same thing- add paid support options to their already open/free gcc arm compiler (maybe they already have paid support options, I don't know).

It will be interesting how they merge the Atmel side into what they have- there is no way they are going to make you pay for optimization for their sam/avr parts. If that is true, then the mips side will most likely end up the same eventually. How many companies are left in the MCU chip selling business that also are in the compiler selling business?
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #103 on: November 19, 2017, 06:33:13 pm »
Thats a good idea.
If you could set up a linux virtualbox machine with the necessary build environment and distribute it that would be much appreciated (and legal of course). Its beyond me  :(
Just pick someone's ready-made MIPS32 GCC and you are good to go. If you need startup files and linker scripts, extract them from XC32. Or if your machine runs Linux or macOS I may be able to build you one.
« Last Edit: November 19, 2017, 06:44:08 pm by technix »
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #104 on: November 19, 2017, 06:41:06 pm »
I just don't think it's a huge difference between this and compiling.
Well, I guess that for most people (at least for me), it is a huge difference.

Have you tried?

So, if you can provide a step by step manual for dummies like me how to download and compile the GCC sourcecode from Microchip, that would be very nice.

I don't need it. But I guess people who did compile it could blog about it or post a video. If you don't see this, it is most likely because there's no demand for such thing.
There are tutorials for building GCC targeting AVR (as part of avr-libc tutorial) or i386 (as part of Linux From Scratch bootstrap process.) I think you can take inspirations from those and build a stock MIPS32 GCC from upstream code.

Just saying, I have used that (fairly outdated) tutorial to build AVR-GCC 7.2 (latest release from upstream) from source for my macOS machine. Not even Microchip is distributing this version. Notice the lack of branding here, with the compiler simple calling itself avr-gcc (GCC) 7.2.0?
Code: [Select]
$ avr-gcc --version
avr-gcc (GCC) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Here is the output of my ARM Embedded GCC that is branded GCC 6.2.1:
Code: [Select]
$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437]
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Or the one from Atmel Studio:
Code: [Select]
avr-gcc --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.1_1750) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
« Last Edit: November 19, 2017, 06:42:38 pm by technix »
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #105 on: November 19, 2017, 06:50:35 pm »
But, also this was not the point. The point was if it's legal or not to hack/modify GPL licensed software.
Of course it is legal.

I agree but it's a little more complicated. If you read back this thread, it appears that some people think that it is perfecly fine
if Microchip hacks the GCC compiler in order to block optimizations but it's not fine when I unblock them by hacking it again.
If Microchip is actively trying to prevent other from modifying XC16 and XC32 to remove the license check, tell FSF and they will be very gladly to sue for you. FSF owns GCC after all, and they have a history of defending GPL. I think Cisco (owns Linksys back then) have better lawyers than Microchip, yet they get successfully sued by FSF for GPL violation.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #106 on: November 19, 2017, 06:57:57 pm »
If Microchip really want to make a compiler that they can put in a license check that they can properly defend, while still providing modern functionality, use LLVM as upstream instead of GCC. LLVM can be relicensed as proprietary unlike GCC which is permanently GPL. ARM is already doing this (the ARMCC version 6 is based on LLVM, replacing their own ARMCC version 5 deprecated.) LLVM already have MIPS32 support. Speaking of, LLVM can be used to built modern compiler for 8-bit and 16-bit microcontrollers too, just look at the LLVM-MSP430 and LLVM-AVR branch.
 

Offline MT

  • Super Contributor
  • ***
  • Posts: 1616
  • Country: aq
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #107 on: November 19, 2017, 09:57:46 pm »
But, also this was not the point. The point was if it's legal or not to hack/modify GPL licensed software.

Of course it is legal. It is illegal to forbid hacking GPL licensed software. And it is not really a challenge, because GPL means that you get all the source code and a manual how to compile it (and if you don't, it is illegal again and the FSF will be happy to help you), so you can just modify the source code as you like. But don't forget to publish your modifications or a contact address how to get it, because this is required by GPL.

So i wonder, did Microchip publish their hack to restrict optimization levels? And if so why did they restrict optimization levels to begin with?
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #108 on: November 19, 2017, 11:20:31 pm »
You missed the point...
This is about modifying/hacking the compiled, GCC compiler,
That too, but mostly it's about cracking proprietary software.

Here's the primary offense:-
 
Quote
- compile a new "xclm" binary using the following C code:

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
 
 

Inside the original xclm.exe we find this message:-

  'Reprise License Manager (RLM) v12.0, Copyright (C) 2006-2015, Reprise Software, Inc.'
   
The crack modifies xclm.exe to stop it from actually checking the license, instead faking the return code for a valid license. It also removes Reprise's copyright from the code, an offense in itself.

I am not a lawyer, but I'm betting that Reprise License Manager is not covered by GCC's GPL.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #109 on: November 19, 2017, 11:47:29 pm »
I am not a lawyer, but I'm betting that Reprise License Manager is not covered by GCC's GPL.

On a side note, the license manager which is so easily removed is a fraud in itself. "Reprise Software" scammed Microchip into believing that their licensing model is secure while, as you can see, it is so easily by-passed. There's no intellectual property in this piece of crap. Nothing intellectual at all. On the other hand, scammers usually have the best lawyers ...
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #110 on: November 20, 2017, 12:29:07 am »
Quote
Here's the primary offense:
There is nothing wrong there. The original xclm is not modified at all, and not even used.
Unless I'm missing something, they are simply creating their own program that has the same name- xclm - which returns an exit code. Then a hash is computed on the new xclm program which is inserted into a gpl binary. Unless there is something wrong with deleting proprietary files, I don't see what offense may be occurring.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #111 on: November 20, 2017, 06:30:24 am »
You missed the point...
This is about modifying/hacking the compiled, GCC compiler,
That too, but mostly it's about cracking proprietary software.

Here's the primary offense:-
 
Quote
- compile a new "xclm" binary using the following C code:

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
 
 

Inside the original xclm.exe we find this message:-

  'Reprise License Manager (RLM) v12.0, Copyright (C) 2006-2015, Reprise Software, Inc.'
   
The crack modifies xclm.exe to stop it from actually checking the license, instead faking the return code for a valid license. It also removes Reprise's copyright from the code, an offense in itself.

I am not a lawyer, but I'm betting that Reprise License Manager is not covered by GCC's GPL.
I am not sure if such a modification is GPL-compliant. Maybe we should report this to FSF, and if this "putting a proprietary license check into GPL code" breaks GPL they will happily sue.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #112 on: November 20, 2017, 07:38:32 am »
Here's the primary offense:-

CV007 is right: https://www.eevblog.com/forum/microcontrollers/mplab-x-a-pic-inhibitor!-alternatives/msg1353555/#msg1353555

There's nothing wrong there.

Hypothetically speaking, I can patch the GCC compiler executable to not look for xclm but for xclm_karel instead.
In that case it's not a problem anymore. No need to replace the xclm. I can do that in five minutes...




 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #113 on: November 20, 2017, 07:44:06 am »
This is not that complicated. The source is available, so you can clearly see what they are doing.

Option 1- write 6 lines of shell script that replaces xclm, and inserts the hash of the newly compiled xclm file into three gpl licensed files.
the original xclm is not used or modified, you can delete it- no laws against deleting files
also no laws against creating your own file with the name xclm
the only modifications are to gpl licensed code (3 binary files), which now have the hash value of the new xclm file

Option 2- write 7 lines of shell script that changes the init value of the global variable 'mchp_pic32_license_valid'
in 3 files, change the init value of 'mchp_pic32_license_valid' (.data section)  from -1 (FFFFFFFFFFFFFF) to 6 (0600000000000000)
the xclm file is not used at all since the variable is now initialized to the value 'MCHP_XCLM_VALID_CPP_FULL' (6) (basically, no license check is done)
no need to have an external program (xclm) return a number, but there still needs to be a file named xclm (can be an empty file)
the original xclm is not used or modified, you can delete it

I have tried both ways, both work equally well. I like option 2.

It took me a couple hours to write both scripts (I'm not that bright, so it took a little time to figure out how to do it all from the command line also took some time looking at the gcc source code provided by Microchip). It seems to me that the whole license infrastructure they have is a complete waste of time/resources (excluding XC8 I suppose).
« Last Edit: November 20, 2017, 10:00:32 am by cv007 »
 
The following users thanked this post: thm_w, Karel, newbrain, JPortici

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #114 on: November 20, 2017, 11:01:03 am »
Quote
Here's the primary offense:
There is nothing wrong there. The original xclm is not modified at all, and not even used.
Unless I'm missing something, they are simply creating their own program that has the same name- xclm - which returns an exit code. Then a hash is computed on the new xclm program which is inserted into a gpl binary. Unless there is something wrong with deleting proprietary files, I don't see what offense may be occurring.

Well, it could be that the XC16/XC32 as a "complete package" is not GPL, and that modifications to the "package" (i.e. how parts of GPL and non-GPL parts interact) is not allowed.
Then again, if GPL dominates then I suppose this is not the case.

----

Nevertheless, I think the underlying problem is support by the manufacturer. AVR & ARM (and to some degree MSP430) have very accessible GCC compilers that are not proprietary products. This means they are easily installed by 1 command with a  package managers on virtually any system.

The platform specific modifications are taken upstream, so one can build AVR and ARM compilers (haven't tried/used MSP430 though) for the latest GCC 7.2.0. Look at the Arch software repositories (or Fedora for that matter..), the cutting edge stuff is out there if you absolutely need it.

The cutting edge stuff have primarily front-end updates (new C++ features, some of which are nice for embedded).

But there are also some very relevant backend tunings as well. A few weeks ago, we were doing a little coding challenge to implement some math operations as fast as possible on an AVR. I was surprised to see that the code (with some inline assembly for custom integer types) could be 2x faster on GCC7.2.0 compared to GCC4.9.2 (standard Arduino branch). The compiler was much better in handling register pressure for some iterative parts of the code, leading to far less memory loads, thus a much higher level of optimization.

I tried to use XC16 C++ a little back. It does work.. somewhat, if you can miss the stdc++ library... (there is an embedded oriented SSTL version, admittedly haven't tried using that for XC16 yet though).

And then.. I found out that XC16 is still using GCC base version 4.5.1. That version is more than 7 years old (released 2010). This version has few C++11 features integrated, but many nice features are not available.
I have never tried modifying the GCC code base, but something tells me that "building a newer GCC version if you want" is a major undertaking due to regressions. And I don't think you could blame the GCC maintainers for that; they cannot babysit code that is not in their repository. Though luck if a 3rd party has to fix all the regressions.

As a user looking for a good long-term embedded platform, I think the pay-to-unlock compiler optimizations is not even the biggest issue. You can either pay 1k$ or get your hands dirty. Stagnation in the compiler development is a much bigger issue for me.

As far as I am aware, Microchip has always ignored C++ requests for XC16 and other compiler complaints on their forums. Ever since it's introduction in I think 2012(?) XC32 C++ version is now a "free offering!", like as if they have gone above themselves to provide this to their customers.

I think in 2015, XC32 1.40 upgraded to GCC 4.8.3, which was somewhat recent version back then. However by now also already 3 years old..  The cynic in me thinks that perhaps we would have never 'gotten' this upgrade if it wasn't for Microchip working on embedded Linux support for their larger PIC32MZ parts.

I'm not holding my hopes up for a change in this paradigm anytime soon. I think if MCHP wants to get their compiler quality up to par with ARM and AVR, they will need to drop this corporate shenanigans.
« Last Edit: November 20, 2017, 11:03:16 am by hans »
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #115 on: November 20, 2017, 11:30:36 am »
Quote
Here's the primary offense:
There is nothing wrong there. The original xclm is not modified at all, and not even used.
Unless I'm missing something, they are simply creating their own program that has the same name- xclm - which returns an exit code. Then a hash is computed on the new xclm program which is inserted into a gpl binary. Unless there is something wrong with deleting proprietary files, I don't see what offense may be occurring.
Well, it could be that the XC16/XC32 as a "complete package" is not GPL, and that modifications to the "package" (i.e. how parts of GPL and non-GPL parts interact) is not allowed.
Then again, if GPL dominates then I suppose this is not the case.

It's not the case. The GPL dominates because you can not change the license of (or re-license) GPL'ed software without the permission of all respective copyright holders of that software.

That's why so many companies hate the GPL license, they want to take but they don't want to give back.
They can't stand it that they have to write all their software themselves and re-invent the wheel in order to keep their inventions for themselves.

Don't get me wrong, there's nothing wrong with writing closed-source proprietary software (I'm not a commy). But when you do, don't whine that you can not use GPL'ed software in your projects.
It has been made very clear that when you distribute modified GPL'ed software, you have to distribute the source as well and allow that other people start to use your modifications in their software (on the same conditions).

Edit:

Also, by distributing GPL'ed software, you have to accept that people can modify ("hack" if you prefer) your software and don't use it as you intended.
« Last Edit: November 20, 2017, 12:02:18 pm by Karel »
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #116 on: November 20, 2017, 11:41:34 am »
Well, it could be that the XC16/XC32 as a "complete package" is not GPL, and that modifications to the "package" (i.e. how parts of GPL and non-GPL parts interact) is not allowed.
The compiler itself is GPL, but eg. the libraries and device database files are not.

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #117 on: November 20, 2017, 01:31:05 pm »
Well, it could be that the XC16/XC32 as a "complete package" is not GPL, and that modifications to the "package" (i.e. how parts of GPL and non-GPL parts interact) is not allowed.
The compiler itself is GPL, but eg. the libraries and device database files are not.
I am not sure if FSF share this view. They have some pretty rigid requirements about what can be packaged along with GCC in order not to make every single piece of code emitted by the package GPL (due to libgcc usage.)

At least the header files are 3BSDL AFAIK. FSF views 3BSDL as GPL-compatible.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #118 on: November 20, 2017, 01:33:19 pm »
Here's the primary offense:-

CV007 is right: https://www.eevblog.com/forum/microcontrollers/mplab-x-a-pic-inhibitor!-alternatives/msg1353555/#msg1353555

There's nothing wrong there.

Hypothetically speaking, I can patch the GCC compiler executable to not look for xclm but for xclm_karel instead.
In that case it's not a problem anymore. No need to replace the xclm. I can do that in five minutes...
Or just patch that entire check out. Or port the patches Microchip made for PIC32 back into stock MIPS32 GCC (so we get C11 and better optimizations.)
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #119 on: November 20, 2017, 04:43:16 pm »
That's why so many companies hate the GPL license, they want to take but they don't want to give back.
They can't stand it that they have to write all their software themselves and re-invent the wheel in order to keep their inventions for themselves.

Or perhaps they're not satisfied with all the free wheels laying around, but rather want to invent a better wheel.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #120 on: November 20, 2017, 05:05:56 pm »
That's why so many companies hate the GPL license, they want to take but they don't want to give back.
They can't stand it that they have to write all their software themselves and re-invent the wheel in order to keep their inventions for themselves.

Or perhaps they're not satisfied with all the free wheels laying around, but rather want to invent a better wheel.

That's fine, I encourage competition. No need to show hate/angriness about the GPL. If you don't like it, don't use it.
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #121 on: November 20, 2017, 07:02:48 pm »
I think if MCHP wants to get their compiler quality up to par with ARM and AVR, they will need to drop this corporate shenanigans.
What does Microchip's 'corporate shenanigans' have to do with updates to GCC for PICs? The compiler is is open-source (not really, but...) so why can't anyone produce a better version if they want? What is stopping the PIC versions from being as up-to-date as others?

Quote from: cv007
This is not that complicated. The source is available, so you can clearly see what they are doing.
The source to xclm is available?

Quote
no laws against deleting files
also no laws against creating your own file with the name xclm
You are an actual lawyer versed in IP law? If not then how can you know this is true?

The way I see it, compiling some code and patching it into xclm (which is what happens when you copy it over the existing file) equates to modifying it. Since xclm is proprietary copyrighted software which is not covered by GPL... Now I may be wrong, and it's all perfectly legal. But I still think it's dodgy.

 
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #122 on: November 20, 2017, 07:04:32 pm »
That's why so many companies hate the GPL license, they want to take but they don't want to give back.
They can't stand it that they have to write all their software themselves and re-invent the wheel in order to keep their inventions for themselves.

Or perhaps they're not satisfied with all the free wheels laying around, but rather want to invent a better wheel.

That's fine, I encourage competition. No need to show hate/angriness about the GPL. If you don't like it, don't use it.
Oh the corporates will hate on GPL. In fact they already do.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #123 on: November 20, 2017, 07:52:50 pm »
The way I see it, compiling some code and patching it into xclm (which is what happens when you copy it over the existing file) equates to modifying it.

Here I lost you. If you believe that there's no difference between replacing and modifying, than any further discussion with you is futile.

But for the sake of the discussion, and purely hypothetical, let's assume for a moment that you are right and it is actually "dodgy".
In that case, you don't replace it but you simply patch the compiler by using the alternative methods as described before by others.
Or is that also "dodgy"?
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #124 on: November 20, 2017, 07:54:30 pm »
I am not sure if FSF share this view. They have some pretty rigid requirements about what can be packaged along with GCC in order not to make every single piece of code emitted by the package GPL (due to libgcc usage.)
I'm not sure what you're trying to say here. The GPL aggregate clause permits distributing GPL-licensed software with non-GPL software. The GPL also doesn't impose any limits on the license of the libraries it links.

Quote
At least the header files are 3BSDL AFAIK. FSF views 3BSDL as GPL-compatible.
Which header files? Some of the library headers installed with XC32 have a BSD-style license, but mostly it's a mishmash of proprietary or no explicitly stated license. The installer places a "compiler license" text file in the root install directory detailing the various components and their licenses.

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #125 on: November 20, 2017, 08:31:48 pm »
Quote
The source to xclm is available?
No. The source to xclm is not available, but who cares- xclm is not needed. Forget xclm. Not required.

The source for the XC gcc compilers is here-
http://www.microchip.com/development-tools/downloads-archive
there is a file mhcp.c which has the license checking (and also includes the gpl license)- this is the source I was referring to.

There is nothing sinister about modifying gpl programs- that is the whole purpose of the license.


for f in cc1plus cc1 lto1; do a=($(objdump -T $f | grep mchp_pic32_license_valid)); b=($(objdump -h $f | grep " .data ")); offset=$((0X${a[0]}-0x${b[4]}+0x${b[5]})); printf "%0.8x: 0600 0000 0000 0000" $offset | xxd -r - $f; done
« Last Edit: November 20, 2017, 08:37:53 pm by cv007 »
 
The following users thanked this post: voltsandjolts, Karel

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #126 on: November 21, 2017, 12:16:37 am »
Just out of curiosity I downloaded the XC32 source.
Over 103,00 files.... :wtf:
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #127 on: November 21, 2017, 01:36:58 am »
Quote
Over 103,00 files
Yeah...  You didn't think gcc was SMALL, did you?   I count over 80000 files for gcc (not including binutils) (dowloaded from fsf)
After all, it has C, and C++, and Fortran, and Ada, and Java and who knows what else...  And generally architecture-specific files for a whole slew of architectures (although, if you want the most recent version for any particular architecture, you'd be ill advised to use the gcc download from a vendor who primarily sells some other architecture...)
XC32 probably adds an include file and a linker script for each separate PIC32 chip.

This is why people are willing to pay microchip for a rather old version instead of piecing together the latest and greatest generic MIPS compiler and assorted libraries.  It doesn't take much $50/h engineer time fussing with build processes and dependency hell before you could have just paid for a full license.  Or put up with the lesser optimization.


Quote
the corporates will hate on GPL
In my time, a fair number of people made a good living writing compilers.  Not so much any more.  I have a bit of fear for the next generation, when gcc is likely to be all that's available, and it's maintained by a bunch of amateurs (or competing vendor-acquired hackers...)
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #128 on: November 21, 2017, 06:50:33 am »
After all, it has C, and C++, and Fortran, and Ada, and Java and who knows what else...
Also 30 years of history.

Quote
I have a bit of fear for the next generation, when gcc is likely to be all that's available, and it's maintained by a bunch of amateurs (or competing vendor-acquired hackers...)
Like most successful open-source projects, the vast majority of GCC development is done on a professional basis. Clang and LLVM are also still gaining popularity, both because its friendlier license and embeddability, and because the more modern codebase means its easier to work on. However it doesn't support nearly as many architectures as GCC, and likely never will. Also, although people have used it with Cortex-M CPUs, it is currently not meant for bare-metal environments.

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #129 on: November 21, 2017, 07:30:48 am »
In my time, a fair number of people made a good living writing compilers.  Not so much any more.

Wrong, it's (still) done by skilled professionals who make a good living with it.

I have a bit of fear for the next generation, when gcc is likely to be all that's available, and it's maintained by a bunch of amateurs

I have no idea what you are talking about. If GCC is good enough to compile the most used (and most reliable) operating system in the world,
it's definitely good enough for my projects.

 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #130 on: November 21, 2017, 12:20:00 pm »
Wrong, it's (still) done by skilled professionals who make a good living with it.
GCC is being maintained by skilled professionals who make a good living out of it?

Quote
If GCC is good enough to compile the most used (and most reliable) operating system in the world,
Android?
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #131 on: November 21, 2017, 12:40:04 pm »
GCC is being maintained by skilled professionals who make a good living out of it?
I don't know how much they're getting paid, but even a cursory glance at the maintainer list shows that the majority are paid for their work (many with a personal email address listed are also doing work-for-hire). The "open source must mean amateurs" canard is straight out of Microsoft's playbook ca. 1998 and was never particularly true.

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #132 on: November 21, 2017, 01:00:04 pm »
Wrong, it's (still) done by skilled professionals who make a good living with it.
GCC is being maintained by skilled professionals who make a good living out of it?

Quote
If GCC is good enough to compile the most used (and most reliable) operating system in the world,
Android?

Linux
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #133 on: November 21, 2017, 01:34:24 pm »
I can confirm that the command

Code: [Select]
for f in cc1plus cc1 lto1; do a=($(objdump -T $f | grep mchp_pic32_license_valid)); b=($(objdump -h $f | grep " .data ")); offset=$((0X${a[0]}-0x${b[4]}+0x${b[5]})); printf "%0.8x: 0600 0000 0000 0000" $offset | xxd -r - $f; done
works correctly. No need to replace the xclm executable.

Thanks again  :-+

I assume even Bruce will be happy now  ;)
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #134 on: November 21, 2017, 09:28:30 pm »
Its too bad I will probably never use the xc16/32 compilers, but you never know. I have played around with pic32/pic24 before,  and they are kind of neat in some ways. I also have tried quite a few arm chips (cheapest dev boards), and the only one I had any fun with was the LPC1114. The documentation was straight forward, didn't have to have a dozen pdf's open, everything I tried worked. I even created my own simple forth in asm (gas). Debugging was easy and fast also. Give me a LPC1114 with some peripherals similar to a newer pic16f and I would be happy(er).


cp elf-cc1 elf-cc1.bak; a=$(objdump -T elf-cc1.bak | grep mchp_mafrlcsj); a=${a:6:2}${a:4:2}${a:2:2}${a:0:2}; old="8b35${a}85f60f85"; new="8b35${a}85f60f84"; xxd -ps elf-cc1.bak | sed "s:$old:$new:" | xxd -r -p - elf-cc1
« Last Edit: November 21, 2017, 09:51:14 pm by cv007 »
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #135 on: November 21, 2017, 09:33:04 pm »
I think if MCHP wants to get their compiler quality up to par with ARM and AVR, they will need to drop this corporate shenanigans.
What does Microchip's 'corporate shenanigans' have to do with updates to GCC for PICs? The compiler is is open-source (not really, but...) so why can't anyone produce a better version if they want? What is stopping the PIC versions from being as up-to-date as others?
Well it has basically been partially answered by westfw. It takes an advanced skill set to develop compilers forwards, above all GCC is an enormous project.

The other part is by 'selling' a GPL product Microchip creates a conflicting interest. As a community it would be hard work on such a project (i.e. push changes upstream) if the only package from Microchip supplied is a ZIP file. There is a nice thing called version control systems, like GIT, which is useful in tracking changes, resolving merge conflicts and cherry picking the right modifications for merging. Going from GIT (or some other technology Microchip internally uses) > ZIP file > GIT sounds like a nightmare.

Above all; if one would was successful in merging the changes together, what guarantee does one have that Microchip doesn't release a new compiler next week with "significant better ISA level optimizations"? Good luck chasing your own tail again..

I think there are probably only 2 types of people that really can/should care:

- Fanatic hobbyists that like the PIC24 and PIC32 parts and want to program the latest language and static checking/optimization technology. But with the struggles imposed I just described, I think most will choose the path of least resistance (different parts).

- The people working at Microchip, because their job is to supply tools to their customers. This is why I call it 'corporate', because somewhere a decision had been taken that they rather will charge $$$ for a GCC compiler and work on their island instead of helping the GCC project forward like other vendors do (ST, Freescale, ARM, Atmel).

I guess the other 'types' of people just don't care, I understand :-) If code runs, it runs. Not fast enough, mangle the code manually until it does, if not resort to inline assembly, or give up and buy a faster chip.

But at some day (e.g. 5-10 years from now), you may find that some middleware library is available only in C++ (think CAN protocols), and need to port this onto an existing board with dsPIC/PIC24. Good luck defending the artificial tool limitations at that moment in time.

(As a side note; I still really like the PIC24 & PIC32 parts.. The PPS on PIC24 is awesome, the peripherals are amazingly simple and intuitive to use.. nice hardware pros, it's just a pity that software tooling is not as good as it can be)
« Last Edit: November 21, 2017, 09:35:21 pm by hans »
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #136 on: November 21, 2017, 10:02:02 pm »
As a community it would be hard work on such a project (i.e. push changes upstream) if the only package from Microchip supplied is a ZIP file.
As a GNU project, GCC requires copyright assignment from all contributors, so upstreaming is not even an option.

The chipKIT project maintains a PIC32 compiler that is more or less the redistributable bits of XC32.

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #137 on: November 22, 2017, 12:39:33 am »
The "open source must mean amateurs" canard is straight out of Microsoft's playbook ca. 1998 and was never particularly true.
Nobody said that. My question was, is GCC being maintained by skilled professionals who make a good living out of it?

Quote
I don't know how much they're getting paid, but even a cursory glance at the maintainer list shows that the majority are paid for their work
That's a lot of people. Who pays them for working on GCC?

 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #138 on: November 22, 2017, 06:19:32 am »
That's a lot of people. Who pays them for working on GCC?
Look at the email addresses. Mentor Graphics (CodeSourcery), RedHat, SUSE, Intel, ARM, AMD, IBM etc. are all major contributors. Note that the list is of maintainers, not all contributors, nor all companies that have sponsored work on the compiler.

Edit: Also absent are the list of non-mainlined ports, like Microchip's.
« Last Edit: November 22, 2017, 06:21:43 am by andersm »
 

Offline ruffy91

  • Regular Contributor
  • *
  • Posts: 240
  • Country: ch
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #139 on: November 22, 2017, 06:23:39 am »
https://gcc.gnu.org/onlinedocs/gcc/Contributors.html

Most of them are paid full-time to work on gcc by their companies.
I think at least 3 people there are from Intel, but they also work on the linux kernel.
You will also find people paid by AMD, ARM and every other processor or operating system vendor.
The second big part should be universities.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #140 on: November 22, 2017, 07:18:14 am »
https://gcc.gnu.org/onlinedocs/gcc/Contributors.html

Most of them are paid full-time to work on gcc by their companies.
I think at least 3 people there are from Intel, but they also work on the linux kernel.
You will also find people paid by AMD, ARM and every other processor or operating system vendor.
The second big part should be universities.
From what I see in various FOSS projects (mostly GNUstep and LLVM,) the main driving force is corporate and academia. Both are highly professional people well paid to do this. Corporate contributor submits code that works best for their commercial purposes like most processor support and some optimize passes. while academia maintains the core functionality and project neutrality like a good portion of language support and moving optimize passes around.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #141 on: November 22, 2017, 02:20:07 pm »
You don’t need MPLABX to write for dsPic.
I think optimisation is the only reason I’m using it, but I have the same dsPic33F project on two operating systems,
and one is a ten or so year old MPLAB 8.36, which is much older than yours.


« Last Edit: November 22, 2017, 02:38:33 pm by @rt »
 

Offline fourtytwo42Topic starter

  • Super Contributor
  • ***
  • Posts: 1183
  • Country: gb
  • Interested in all things green/ECO NOT political
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #142 on: November 22, 2017, 05:40:30 pm »
You don’t need MPLABX to write for dsPic.
I think optimisation is the only reason I’m using it, but I have the same dsPic33F project on two operating systems,
and one is a ten or so year old MPLAB 8.36, which is much older than yours.
You are correct if you chose your device carefully to ensure support in MPLAB, In the end I re-designed the project to fit in a PIC24EPxxxMCxxx that IS supported by MPLAB and so I have managed without the bloatware! Everybody to there own but I strongly remain a supporter of the KISS principle  :-+
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #143 on: November 22, 2017, 07:16:12 pm »
I can confirm that the command

Code: [Select]
for f in cc1plus cc1 lto1; do a=($(objdump -T $f | grep mchp_pic32_license_valid)); b=($(objdump -h $f | grep " .data ")); offset=$((0X${a[0]}-0x${b[4]}+0x${b[5]})); printf "%0.8x: 0600 0000 0000 0000" $offset | xxd -r - $f; done
works correctly. No need to replace the xclm executable.

Thanks again  :-+

I assume even Bruce will be happy now  ;)
If I can get XC32 to optimize my code without violating any of Microchip's licensing agreements and can recommend it to others without being on shaky legal or moral ground then I will be happy.

Exactly what code is your command patching? Can I do it with a hex editor?
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #144 on: November 22, 2017, 07:22:17 pm »
If I can get XC32 to optimize my code without violating any of Microchip's licensing agreements and can recommend it to others without being on shaky legal or moral ground then I will be happy.

Yes, you can. As others have told you already, by very definition, by modifying GPL licensed code and distributing the resulting software, they are required to publish the source code of all said modifications, on the same GPL license, so they cannot remove any freedoms in the process. This is the basics - you don't need to be a lawyer to discuss this.

The only party here who has been on a little bit "shaky legal or moral ground" here has been Microchip. GPL also requires that the sources must be in a typical useable form, with typical build instructions, etc, for a good reason. I'm sure Microchip has done their job with their lawyers so that they are not actually violating GPL, or if they are, not bad enough so that they'd be in a deep trouble. This is the complex side of the issue where the lawyers come in.

Anyway, as their product's user, you are in a very good position thanks to their good choice of using GPL licensed software.

And, no one has been "patching" or modifying or anything their xclm. You just remove it and replace it with your own software, on your own computer.
« Last Edit: November 22, 2017, 07:28:02 pm by Siwastaja »
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #145 on: November 22, 2017, 07:52:27 pm »
I can confirm that the command

Code: [Select]
for f in cc1plus cc1 lto1; do a=($(objdump -T $f | grep mchp_pic32_license_valid)); b=($(objdump -h $f | grep " .data ")); offset=$((0X${a[0]}-0x${b[4]}+0x${b[5]})); printf "%0.8x: 0600 0000 0000 0000" $offset | xxd -r - $f; done
works correctly. No need to replace the xclm executable.

Thanks again  :-+

I assume even Bruce will be happy now  ;)
If I can get XC32 to optimize my code without violating any of Microchip's licensing agreements and can recommend it to others without being on shaky legal or moral ground then I will be happy.

Exactly what code is your command patching? Can I do it with a hex editor?

It's a command you run in the console in the directory where the compilers are located.
It calls a tool objdump to look for and retreive the offset (address) of a variable in the compiler executable.
Then it changes that value and writes it in the executable. It does NOT modify the xclm executable. No need to replace it neither.
The fastest and simplest patch so far.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #146 on: November 22, 2017, 08:14:31 pm »
Where does “objdump” come from?
 

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 2277
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #147 on: November 22, 2017, 08:27:29 pm »
The script patches the xc32 executables on linux, objdump is standard part of most linux distros.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #148 on: November 22, 2017, 08:29:53 pm »
Bummer! Mine is installed on a Mac.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #149 on: November 22, 2017, 08:41:09 pm »
They also have an -m option -> -mafrlcsj  which 'should' also give the full version, but it does not work (using the global option -mafrlcsj ). That option is a boolean in the global_options, is being used in the code (and works when using cc1 directly), but it wouldn't surprise me if they are not allowing that option to get to cc1 (two version of xc32-v1.44-src/binutils/bfd/pic32-options.c , one they release source code, and the other used to distribute the executables where the option is not set). I assume this is an option for internal use so they don't have to deal with the license when developing. The cc1/cc1plus/lto1 are still looking for that option in the globals, but it never gets set.

The xc16 mod I showed (in one of my posts) is different as they don't use a global for 'mchp_pic32_license_valid', but they have mchp_mafrlcsj in the globals (but is in .bss so initial value is 0). So, just look for the code where they check 'mchp_mafrlcsj', and change the subsequent jne to je.

Microchip makes it almost impossible to compile from the source they provide. Since that is the case, just use your right to modify the gpl binaries instead.

Their whole licensing contraption is somewhat silly when you see what is really going on.
« Last Edit: November 22, 2017, 08:42:56 pm by cv007 »
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #150 on: November 22, 2017, 09:02:17 pm »
Can you modify XC16 with a Mac?
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #151 on: November 22, 2017, 10:38:33 pm »
I just updated XC16 (not the IDE) from 1.30 to 1.33 so I could try the 60 day trial,
and now it compiles the same project some 300 words greater code size with optimisation “s” :D
Fortunately I can still select the older XC16 version, and it compiles as it used to!
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #152 on: November 22, 2017, 10:39:34 pm »
OK. This is simpler than I thought (and may work for Windows/Mac users, also). No need to change anything.
(that mchp_mafrlcsj symbol was bugging me, so I had to figure out what was going on)

Create a text file in the project (project root folder is where I put it), call it specs.txt
Code: [Select]
*cc1:+ -mafrlcsj

*cc1plus:+ -mafrlcsj
edit- cleaned up a little, notice the required blank line also (specs file format is a little odd)
(if you want to see the gcc specs output when compiling, add -v to the global additional options)

Now,  in project properties, XC16 or XC32 (Global Options),  additional options field add this     -specs=specs.txt
Compile away with whatever options you want.

The XC16/32 front end is not allowing the -mafrlcsj option to get to cc1/cc1plus. By specifying your own specs files it appears the option gets to where it needs. The specs file above simply adds the -mafrlcsj option to what  it already uses in its default specs.

I'm not the smartest bulb in the Christmas tree, so if I can figure this out, not too complicated.
(edit- that should be 'brightest bulb', which is more proof)

MCHP could change the next version, but they are required to release the source, so its a futile game they would be playing. I would also add that it looks like the source they are using is not the source they are providing, otherwise that option would make it to cc1. I suspect they are changing the switch/case for that option- in the source we get, that global option is being set to true in the switch/case for the -mafrlcsj option, in their source I think they just set it to 0 as the option is otherwise recognized.
« Last Edit: November 23, 2017, 05:07:17 pm by cv007 »
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #153 on: November 22, 2017, 11:35:10 pm »
Just tried that on the HAD badge project (86K object code), -s optimisation saved 10% code -3 doubled it ( hopefully improved speed)
Not checked if it runs.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #154 on: November 23, 2017, 02:52:20 am »
Is it unlikely the program and data size for a large project would stay exactly the same no matter the optimisation option?
That’s what’s happening here. Also the same if optimisation is zero.

I remember when first installing MPLABX, there was some way I enabled it for each individual file in a project, and I saw a difference then.

https://photos.app.goo.gl/WuHzzvErHNUsqbb83
« Last Edit: November 23, 2017, 03:57:22 am by @rt »
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #155 on: November 23, 2017, 04:58:18 am »
I'm not sure how great the optimizations are for pic24/33 or pic32 (I seem to recall it was not a big deal when I tried them). For the pic32, the greater benefit it would seem to me is the mips16 and c++ options. I also seem to recall that generating mips16 code reduced the size a bit, but I think there were some hoops to jump through like maybe not being able to use in interrupts (or something like that).

Also, there are more options than -Os/1/2/3- things like isolate each function in its own section (gcc) along with removed unused sections (ld), and others.


It looks like a few versions ago, they created that -mafrlcsj option to (I assume) free the developers from having to deal with the hassle of (their own) licensing. I'll bet they didn't realize they could not prevent that option from making its way to cc1/cc1plus/lto1.

Here are the relevant files for 'mafrlcsj'
binutils/bfd/pic32-options.c
gcc/gcc/config/pic32/mchp.opt
gcc/gcc/config/pic32/mchp.c
« Last Edit: November 23, 2017, 05:18:00 am by cv007 »
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #156 on: November 23, 2017, 05:20:27 am »
Can you modify XC16 with a Mac?
Sure I can. macOS is UNIX too, being based on BSD instead of Linux though.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #157 on: November 23, 2017, 05:26:51 am »
I seem to recall when I first installed it, and was able to set optimisation on project files individually, that optimisation did make a difference with the same project.
It broke the main file, and I had to change a delay loop that would have appeared useless.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #158 on: November 23, 2017, 05:43:48 am »
I seem to recall when I first installed it, and was able to set optimisation on project files individually, that optimisation did make a difference with the same project.
It broke the main file, and I had to change a delay loop that would have appeared useless.
Delay loops usually don't survive well with optimizers' DCE passes. If you have timers to spare it may be better to implement delays using one of those.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #159 on: November 23, 2017, 06:05:03 am »
The only delay required was a call to a function with argument, so it was easily resolved, but that doesn’t explain the rest of it. I still find it hard to believe it’s working at all. I mean surely there should be one word difference at least.. between all five options. I bet if I wrote a new useless function full of setting an unused variable to zero, it still won’t change anything.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #160 on: November 23, 2017, 06:15:34 am »
The only delay required was a call to a function with argument, so it was easily resolved, but that doesn’t explain the rest of it. I still find it hard to believe it’s working at all. I mean surely there should be one word difference at least.. between all five options. I bet if I wrote a new useless function full of setting an unused variable to zero, it still won’t change anything.
The function would be DCE'd into a single "return" instruction, and if the function is only used in the same file it would be entirely optimized out through inlining and further DCE.
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #161 on: November 23, 2017, 06:24:23 am »
I'm not sure how great the optimizations are for pic24/33 or pic32 (I seem to recall it was not a big deal when I tried them).

-O0 to -O1 (which is available in free mode) is already optimizing A LOT, the acccumulators are used in a more intelligent way and a lot of unnecessary stack / frame pointers are not saved/restored between function calls
« Last Edit: November 23, 2017, 06:27:23 am by JPortici »
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #162 on: November 23, 2017, 08:45:05 am »
Optimization level 0 turns it basically off, creating rather large and slow code. But for debugger best to follow along.
At any other optimization level, except 'g' which I don't think XC16/XC32 support, you lose this support.

Also consider using optimization level 2. I find that optimizing for size makes the function inliner very lazy, especially in C++. It seems to compile functions as compact as it can in an isolated manner. That means the code still has lots of calls to tiny functions which it could have inlined.
If you use optimize level 3, you may find the compiler wants to unroll entire loops, which can make the code size explode. It is a bit faster, but at what cost.
Finally, you can always use attribute optimize (add __attribute__((optimize("Os")))  to function prototype) in GCC to hand pick which functions should be more aggressively optimized.

The remove unused sections should IMO be on by default. Sometimes you get a library from a vendor and only call 5% of it's functions, but meanwhile it compiles the other 95% of code with it. If you don't isolate functions into seperate sections, the linker cannot usually be as aggressive in doing this.
« Last Edit: November 23, 2017, 08:48:26 am by hans »
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #163 on: November 23, 2017, 01:19:44 pm »
Looking a the output window for mine, changing the opt level does nothing.
I can change it for each file in “configurations.xml”.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #164 on: November 23, 2017, 04:02:25 pm »
Looking a the output window for mine, changing the opt level does nothing.
I can change it for each file in “configurations.xml”.
Why not do the sane thing and change it in the IDE project options? You have no control over when the IDE reads/saves its files, or when the makefiles are generated.

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #165 on: November 23, 2017, 11:29:26 pm »
If you read some posts above. It didn’t work, and still doesn’t. Images are also attached.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #166 on: November 24, 2017, 12:19:11 am »
I tested the -mafrlcsj option via a specs file on a Windows pc, and it works also. I assume MacOS would work, too.

Only the latest XC16 (v1.33) and XC32 (v1.44) were tested, but the source code shows the option was added in XC16 ver 1.26, and in XC32 v1.42 so assume it will work starting with those versions.

3 lines of 'code' (1 blank) into 1 file in the project folder, 1 added global option, and you have no restrictions as it should be.

Disregard my previous scripts (unless they decide to remove the -mafrlcsj option in later builds).



Quote
If you read some posts above. It didn’t work, and still doesn’t. Images are also attached.
Your images don't really help. The gui may show that you selected the 's' optimization, but only the debug build output would show what is actually being applied- for instance if there is a problem with your trial license it would revert to free mode and the 's' optimization would not happen (you will also then get messages in the build debug output- which we cannot see).
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #167 on: November 24, 2017, 02:54:18 am »
The output window shows optimisation level 1, no matter what is globally selected, which is what I originally applied in the free version.
MPLABX does appear to acknowledge the trial license (for the GPL software :D ) by telling me I had 61 days remaining,
which displays as 60 days when I look at it today.
Having worked on the same project on & off for 18 months or so, I’d definitely notice anything odd in the output window.

It’s only when I changed the optimisation level it the configurations.xml file that they actually take effect,
and I am able to do that for individual project files.

I wouldn’t consider this an issue anymore, since the file is easy to edit if it does change.
I’ll see what I can do in the 60 days, and then fiddle with it again after that.

Same project again:
https://photos.app.goo.gl/EJ2inghXXUQoaXxP2
« Last Edit: November 24, 2017, 02:56:08 am by @rt »
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #168 on: November 24, 2017, 06:03:26 am »
If you read some posts above. It didn’t work, and still doesn’t. Images are also attached.
Your images didn't show the build transcript, which would show that you built with the options you think you did.
« Last Edit: November 24, 2017, 06:05:23 am by andersm »
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #169 on: November 24, 2017, 06:11:19 am »
They show the generated code size, which doesn’t change until I manually edit the file. The output window shows optimisation level 1 for all project files no matter which of five options are set.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #170 on: November 24, 2017, 07:30:55 am »
The output window shows optimisation level 1 for all project files no matter which of five options are set.
So you've diddled with the project settings in a way that the IDE hasn't regenerated the makefiles, and haven't actually built the project with different settings.

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #171 on: November 24, 2017, 09:11:00 am »
OK. This is simpler than I thought (and may work for Windows/Mac users, also). No need to change anything.
(that mchp_mafrlcsj symbol was bugging me, so I had to figure out what was going on)

Create a text file in the project (project root folder is where I put it), call it specs.txt
Code: [Select]
*cc1:+ -mafrlcsj

*cc1plus:+ -mafrlcsj
edit- cleaned up a little, notice the required blank line also (specs file format is a little odd)
(if you want to see the gcc specs output when compiling, add -v to the global additional options)

Now,  in project properties, XC16 or XC32 (Global Options),  additional options field add this     -specs=specs.txt
Compile away with whatever options you want.

The XC16/32 front end is not allowing the -mafrlcsj option to get to cc1/cc1plus. By specifying your own specs files it appears the option gets to where it needs. The specs file above simply adds the -mafrlcsj option to what  it already uses in its default specs.

I'm not the smartest bulb in the Christmas tree, so if I can figure this out, not too complicated.
(edit- that should be 'brightest bulb', which is more proof)

MCHP could change the next version, but they are required to release the source, so its a futile game they would be playing. I would also add that it looks like the source they are using is not the source they are providing, otherwise that option would make it to cc1. I suspect they are changing the switch/case for that option- in the source we get, that global option is being set to true in the switch/case for the -mafrlcsj option, in their source I think they just set it to 0 as the option is otherwise recognized.

hey, it did something :D (XC16 v1.33 on windows)

tried with -O2 without additional options: "license file is required" and it compiled with -O1
with the additional options, it compiled.

-O0 and -O1 produce the same hex file with and without the additional option

Optimization level -O0
Data: 6950
Program: 8119

Optimization level -O1
Data: 6950
Program: 6045

Optimization level -O2
Data: 6950
Program: 7190  <--probably unrolling some loops

Optimization level -Os
Data: 6950
Program: 5799  <-- this actually worries me

Optimization level -O0
Data: 6950
Program: 9006 <-- hm...

So something is happening but i have to investigate WTH is happening, I wonder what happens, in this project code is written to be as optimized as it can get, all number-crunching tasks were either assembly routines or using builtins for things like divisions (where the variables are bounded so it will never overflow)
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #172 on: November 24, 2017, 09:30:39 am »
oh oh.. i already see some of the tricks it adopted (that i can use with -O1 to force the compiler to optimize)

comparison #1
this routine produce the same code with -O1, -O2 and -O3

Code: [Select]
27:                void shift_sentbuf(sentbuf_t* sentbuf,unsigned int times) {
28:                  int idx;
29:                  while (times > 0) {
004EFE  E00001     CP0 W1
004F00  32000D     BRA Z, 0x4F1C
004F1A  3AFFF3     BRA NZ, 0x4F02
30:                    for (idx=0;idx<(_SENT_BUF_SIZE-1);idx++) {
31:                      sentbuf->buffer[idx] = sentbuf->buffer[idx+1];
004F02  900120     MOV [W0+4], W2
004F04  9001B0     MOV [W0+6], W3
004F06  BE8802     MOV.D W2, [W0]
004F08  900140     MOV [W0+8], W2
004F0A  9001D0     MOV [W0+10], W3
004F0C  980022     MOV W2, [W0+4]
004F0E  980033     MOV W3, [W0+6]
004F10  900160     MOV [W0+12], W2
004F12  9001F0     MOV [W0+14], W3
004F14  980042     MOV W2, [W0+8]
004F16  980053     MOV W3, [W0+10]
32:                    }
33:                    times--;
004F18  E90081     DEC W1, W1
34:                  }
35:                }
004F1C  060000     RETURN

with -Os, however

Code: [Select]
27:                void shift_sentbuf(sentbuf_t* sentbuf,unsigned int times) {
28:                  int idx;
29:                  while (times > 0) {
004D14  370008     BRA 0x4D26
004D26  E00001     CP0 W1
30:                    for (idx=0;idx<(_SENT_BUF_SIZE-1);idx++) {
004D20  518FE3     SUB W3, #0x3, [W15]
004D22  3AFFF9     BRA NZ, 0x4D16
31:                      sentbuf->buffer[idx] = sentbuf->buffer[idx+1];
004D16  E80183     INC W3, W3
004D18  900222     MOV [W2+4], W4
004D1A  9002B2     MOV [W2+6], W5
004D1C  BE8904     MOV.D W4, [W2]
004D1E  410164     ADD W2, #0x4, W2
32:                    }
33:                    times--;
004D24  E90081     DEC W1, W1
004D26  E00001     CP0 W1
004D28  320003     BRA Z, 0x4D30
004D2A  780100     MOV W0, W2
004D2C  EB0180     CLR W3
004D2E  37FFF3     BRA 0x4D16
004D30  060000     RETURN
34:                  }
35:                }

reason is simple: #define _SENT_BUF_SIZE 4
so the compiler decided to unroll the loop for small loops in every optimization level but -Os. i wouldn't have done that because in dsPIC33E branches have a high latency.. with 33F instead it would be fine but see it uses the MOV.D instructions!

this however can be applied with every optimization.. with -O1
Code: [Select]
10:                sent_t pop_sentbuf(sentbuf_t* sentbuf) {
11:                  sent_t data;
12:                  unsigned int idx;
13:                  if (sentbuf->idx > 0) {
004ED0  900901     MOV [W1+16], W2
004ED2  E00002     CP0 W2
004ED4  320010     BRA Z, 0x4EF6
14:                    data = sentbuf->buffer[0];
004ED6  781831     MOV [W1++], [W0++]
004ED8  781021     MOV [W1--], [W0--]
15:                    for (idx=0;idx<_SENT_BUF_SIZE-1;idx++) {
16:                      sentbuf->buffer[idx] = sentbuf->buffer[idx+1];
004EDA  900221     MOV [W1+4], W4
004EDC  9002B1     MOV [W1+6], W5
004EDE  BE8884     MOV.D W4, [W1]
004EE0  900241     MOV [W1+8], W4
004EE2  9002D1     MOV [W1+10], W5
004EE4  9800A4     MOV W4, [W1+4]
004EE6  9800B5     MOV W5, [W1+6]
004EE8  900261     MOV [W1+12], W4
004EEA  9002F1     MOV [W1+14], W5
004EEC  9800C4     MOV W4, [W1+8]
004EEE  9800D5     MOV W5, [W1+10]
17:                    }
18:                    sentbuf->idx--;
004EF0  E90102     DEC W2, W2
004EF2  980882     MOV W2, [W1+16]
004EF4  370003     BRA 0x4EFC
19:                  }
20:                  else {
21:                    data.Data_H = 0;
004EF6  EB0080     CLR W1
004EF8  780801     MOV W1, [W0]
22:                    data.Data_L = 0;
004EFA  980011     MOV W1, [W0+2]
23:                  }
24:                  return data;
25:                }
004EFC  060000     RETURN

and with every other optimization level
Code: [Select]
10:                sent_t pop_sentbuf(sentbuf_t* sentbuf) {
11:                  sent_t data;
12:                  unsigned int idx;
13:                  if (sentbuf->idx > 0) {
0057C4  900901     MOV [W1+16], W2
0057C6  E00002     CP0 W2
0057C8  320010     BRA Z, 0x57EA
14:                    data = sentbuf->buffer[0];
0057CA  781831     MOV [W1++], [W0++]
0057CC  781021     MOV [W1--], [W0--]
15:                    for (idx=0;idx<_SENT_BUF_SIZE-1;idx++) {
16:                      sentbuf->buffer[idx] = sentbuf->buffer[idx+1];
0057CE  900221     MOV [W1+4], W4
0057D0  9002B1     MOV [W1+6], W5
0057D2  BE8884     MOV.D W4, [W1]
0057D4  900241     MOV [W1+8], W4
0057D6  9002D1     MOV [W1+10], W5
0057D8  9800A4     MOV W4, [W1+4]
0057DA  9800B5     MOV W5, [W1+6]
0057DC  900261     MOV [W1+12], W4
0057DE  9002F1     MOV [W1+14], W5
0057E0  9800C4     MOV W4, [W1+8]
0057E2  9800D5     MOV W5, [W1+10]
17:                    }
18:                    sentbuf->idx--;
0057E4  E90102     DEC W2, W2
0057E6  980882     MOV W2, [W1+16]
0057E8  060000     RETURN
19:                  }
20:                  else {
21:                    data.Data_H = 0;
0057EA  780802     MOV W2, [W0]
22:                    data.Data_L = 0;
0057EC  980012     MOV W2, [W0+2]
23:                  }
24:                  return data;
25:                }
0057EE  060000     RETURN

not much difference, right? but notice at the end, with -O1 at the end of the if (or at the end of switch statements) that go to the end of the routine, one could simply use return, instead with -O1 there is a branch to the end of the statement, which would be the general case. add "return" where needed and spare yourself 3/5 cycles! (this may be a "duh" but i would have expected the compiler to do it already with -O1)
« Last Edit: November 24, 2017, 09:34:45 am by JPortici »
 
The following users thanked this post: thm_w

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #173 on: November 24, 2017, 10:09:18 am »
strangenes...
-O1
Code: [Select]
54:                  UART2_TXBuf.dim = 6;
004224  200060     MOV #0x6, W0
004226  889390     MOV W0, 0x1272

vs -O2 (this may explain the 300 or so more instruction as i don't see much difference in the listing)
Code: [Select]
54:                  UART2_TXBuf.dim = 6;
0049A0  200060     MOV #0x6, W0
0049A2  889390     MOV W0, 0x1272
0049CA  200060     MOV #0x6, W0
0049CC  889390     MOV W0, 0x1272
0049F6  200060     MOV #0x6, W0
0049F8  889390     MOV W0, 0x1272

this happens many times..
and with routine calls too.. WTF?
Code: [Select]
60:                  UART2_TXBuf.buffer[5] = uart_chkCalc(&UART2_TXBuf);
0049B0  212500     MOV #0x1250, W0
0049B2  0706E3     RCALL _uart_chkCalc
0049B4  8892D0     MOV W0, 0x125A
0049DA  212500     MOV #0x1250, W0
0049DC  0706CE     RCALL _uart_chkCalc
0049DE  8892D0     MOV W0, 0x125A
004A06  212500     MOV #0x1250, W0
004A08  0706B8     RCALL _uart_chkCalc
004A0A  8892D0     MOV W0, 0x125A
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #174 on: November 24, 2017, 11:06:33 am »
The output window shows optimisation level 1 for all project files no matter which of five options are set.
So you've diddled with the project settings in a way that the IDE hasn't regenerated the makefiles, and haven't actually built the project with different settings.

No, I’ve set the optimisation to 1 for every individual file through the MPLABX interface before updating XC16,
and either lost the ability, or forgotten how to set optimisation for individual project files.


 

Offline gocemk

  • Regular Contributor
  • *
  • Posts: 84
  • Country: mk
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #175 on: November 24, 2017, 01:21:06 pm »
After reading some of the benchmarks and timings for starting MPLABX posted here, i am starting to think that perhaps my PC (or the OS) is the problem for the slow experience i have.
Starting MPLABX from a fresh restart of the PC and waiting for it to start all the modules, parsing, etc... takes 1m and 16s. I have 3 projects, only one of them open. After i close MPLABX and then start it again, the whole procedure takes ~44s.

My laptop is Dell E6330:
CPU: i5 3340m
RAN: 8GB
SSD Hard Drive: Kingston HyperX Fury 128GB
OS: Windows 10

Based on what i read here, i should be able to start MPLABX much faster.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #176 on: November 24, 2017, 02:40:22 pm »
this happens many times..
and with routine calls too.. WTF?

This doesn't happen many times. Just the encompassing routine has been inlined several times here and there, so there are several copies of the code.

Look at the addresses - they're not consecutive, they're different invocations from different places.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #177 on: November 24, 2017, 03:14:02 pm »
Quote
Based on what i read here, i should be able to start MPLABX much faster.
'Should' is the key word. With Windows, one never knows what is also running in the background (antivirus, toolbars, adware, every other program that wants to run in the background checking into the mother ship every 5 minutes, etc.). I clean up pc's all the time, and in most cases it can be done, but sometimes a clean install is required. Every version of Windows is the same- you start out thinking this is the fastest/best os ever, then over time it gets worse like there is a molasses leak somewhere.

Your os install may be just fine, and there could be other reasons, but it would be hard for anyone to pinpoint 'why' it is slower than it should be. If you really want to know what it 'should' run like- grab a spare drive, do a clean install of Win10 (no extra stuff after), install MPLABX and see how it runs- that is the best you will get. You can then see how much worse your current MPLABX is.

I run MPLABX on linux (core i3/8GB/ssd), and it runs pretty good but there are times that it seems to start consuming excessive memory and I have to kill it.  I also have an older pc with 4GB, some cpu which Win10 will only install the 32bit version,  and it runs ok but runs at about 2/3 the speed of my linux pc.


Quote
forgotten how to set optimisation for individual project files
Right-click the source file, properties, select override build options.
I would also create a new project (not copy the project), then add your files from the current project and see what happens. You will then be dealing with a 'clean' project rather than competing with MPLABX to see who gets to modify the build files last.
« Last Edit: November 24, 2017, 03:17:06 pm by cv007 »
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #178 on: November 24, 2017, 03:14:09 pm »
2.3GHz i5 Mac with 9Gb RAM, and MPLABX opens, and is ready to type in the current open file in 15 seconds.
 

Offline gocemk

  • Regular Contributor
  • *
  • Posts: 84
  • Country: mk
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #179 on: November 24, 2017, 08:15:32 pm »
I think the problem is (suprise, suprise) Windows 10 Fall Creators update. The service "Service host internet connection sharing" was constantly drawing 35% CPU power! It's state was always "Starting". And as far as i could read on the Microsoft forums, i am not the only one with this problem, it seems to be very common on this last update. After i disabled the service, the CPU usage dropped between 1-10% in idle.

Starting MPLABX with 3 objects in the workspace now takes ~35s (including waiting for "Opening Projects", "Background scanning of projects", and "Parsing" to finish). Not a huge improvement, but definitely noticeable.

Also, i can too start typing in the text editor in the current opened file ~15s after starting it, but i consider MPLABX is "properly" started only after those 3 aforementioned tasks are finished.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #180 on: November 24, 2017, 11:16:56 pm »
Quote
Disregard my previous scripts (unless they decide to remove the -mafrlcsj option in later builds).
There are several advantages to using the scripts, though-
1. you do not need the specs file and global option for every project (even though minimal)
2. xclm is not called every time you compile- which may mean a speedup if you compile lots of files
 (XC16 does not call get_license when -mafrlcsj is set, and XC32 does not exec xclm if mchp_pic32_license_valid is already set)

In my setup at least, MPLABX is fussy about the xc include file- if I use any global option, MPLABX loses its ability to view include file symbols (cannot find include file <xc.h> error), although it compiles fine. So, when using the -scripts= global option, half the words in the c file get highlighted in red. With the script mods, it works fine as no global option is required.

For the Windows user, the specs method is easist because the command line tools in Windows are horrible compared to linux.



I have several more ways (how many do you want? tell me when to quit)

another option for XC32-

tools- options- embedded- build tools- Toolchain- select compiler
C Compiler - /opt/microchip/xc32/v1.44/bin/xc32-gcc
add another /bin in that line like so-
C Compiler - /opt/microchip/xc32/v1.44/bin/bin/xc32-gcc
(also do for xc32-g++ if using c++)

then add the -mafrlcsj global option to the project
this bypasses the xc32-gcc that is blocking the -mafrlcsj option (and then calling bin/xc32-gcc with the modified options)
(note- the new compiler path may not take effect right away, seems to lag to some degree)
« Last Edit: November 25, 2017, 12:41:28 am by cv007 »
 

Offline eugenenine

  • Frequent Contributor
  • **
  • Posts: 865
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #181 on: November 25, 2017, 12:52:43 am »
After reading some of the benchmarks and timings for starting MPLABX posted here, i am starting to think that perhaps my PC (or the OS) is the problem for the slow experience i have.
Starting MPLABX from a fresh restart of the PC and waiting for it to start all the modules, parsing, etc... takes 1m and 16s. I have 3 projects, only one of them open. After i close MPLABX and then start it again, the whole procedure takes ~44s.

My laptop is Dell E6330:
CPU: i5 3340m
RAN: 8GB
SSD Hard Drive: Kingston HyperX Fury 128GB
OS: Windows 10

Based on what i read here, i should be able to start MPLABX much faster.

My main machine is  a Dell Latitude E 6230 with 4G of ram and it starts much faster.  I have a Latitude 1100 which is a 1.6 GHz netbook with 2G of RAM and it starts in less than 30 seconds
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #182 on: November 25, 2017, 08:51:50 am »
Who needs rebuilt-from-source licence-check-free versions of XC16 and XC32? I have my 16-core beast machine fixed and it can build packages like those in no time. (two Xeon E5-2680's, 128GB RAM)
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #183 on: November 25, 2017, 09:34:05 am »
I’ll be the first to give you my blessing if what I read here is true :D
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #184 on: November 26, 2017, 12:40:37 am »
Quote
nd it can build packages like those in no time
It just means the compile fails sooner.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #185 on: November 26, 2017, 01:15:40 am »
To make it a little easier, attached is summary of the XC16/XC32 options to remove the restrictions.

(edit- changed text file line endings from UNIX to Windows - sorry, but not terribly,  to any Windows users using notepad)
« Last Edit: November 27, 2017, 07:22:04 pm by cv007 »
 
The following users thanked this post: thm_w, jaromir, @rt, Karel, Fire Doger

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #186 on: December 03, 2017, 01:19:00 am »
Any C++ users out there? (besides arduino users, I guess :) )

Since I now have a compiler with C++ (without limitations- whatever they were), I have been playing around with it and have a pic32mm usb curiosity board to test with.
A number of C++ features are big consumers of flash/memory (and its obvious when you run into them), but there seems enough there for a microcontroller to put to good use.

I'm a C++ beginner (mostly), and here is a simple project to blink some the led's on the board along with using CP0 timer for all delays-
https://github.com/cv007/PIC32MM_Curiosity_CPP
(I know nothing about GitHub, either- but the files ended up where I wanted anyway)

The normal include file <xc.h> is not used, and one goal I have is to eliminate as much as possible defines/macros (maybe not a good goal, but I dislike digging through layers of macros). I also was going to try to do the same simple project in C to compare, but I got stuck thinking about how to create the 6 delays all using CP0 (but didn't try very hard). The compile size is about 3k and an empty project is 1.7k- I doubt the C version would be much different.

Anyway, there was a usb headset demo project available for this curiosity board, and here is a comparison of the compile sizes
Code: [Select]
ISO = isolate functions into sections/remove unused sections
-O0         -> 32k
ISO         -> 29k
-O1         -> 22k
ISO + -O1   -> 20k
ISO + -O2   -> 19k
ISO + -O3   -> 20k
ISO + -Os   -> 17.5k
So, it looks like you gain about ~2.5k on this project with the 'unrestricted' version. Probably not a big deal on a 64k part (the smallest available with usb), but if you start using the smallest mm chips, then it could make a difference.



 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #187 on: December 03, 2017, 04:22:08 am »
So, it looks like you gain about ~2.5k on this project with the 'unrestricted' version. Probably not a big deal on a 64k part (the smallest available with usb), but if you start using the smallest mm chips, then it could make a difference.

Not much. Not surprising.

As flash gets cheaper, it is not as important how big the code is - in the vast majority of cases you can get a bigger part which costs just few extra pennies.

Speed may be more important (costs more), but I expect the improvements speedwise will be even more modest.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #188 on: December 03, 2017, 05:22:27 am »
Something I’ve wondered for some time..
A program is full when my indicator says program memory is 90%.
Where did the other 10% go? What is not being counted?
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #189 on: December 03, 2017, 07:26:23 pm »
??? more details please

an empty project is 1.7k

why. WHY?
« Last Edit: December 03, 2017, 07:29:21 pm by JPortici »
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #190 on: December 03, 2017, 08:27:42 pm »
why. WHY?
Assuming the target device is the PIC32MM0256GPM064, just the vector table will be almost half that (101 vectors * 8 bytes each). The crt0 startup code adds a bit over half a kilo.
 
The following users thanked this post: JPortici

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #191 on: December 03, 2017, 08:41:22 pm »
Quote
why. WHY?
101 interrupt vectors x 8 bytes each is a good start, then throw in 450 bytes for startup code,  another 128 for general exception context, then add more for a handful of other exception/default interrupt stuff, and before long you are at 1.7k. My github code example (c++) doubles that number.

Although there is not much to do on these chips to get them going (in user code), there is still a fair amount of work done before 'main'. Once into main, you basically have a souped up pic16, it seems.
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #192 on: December 04, 2017, 02:06:31 am »
Ah, IVT. Makes sense. To he completely honest i haven't had a chance to use a MM yet, so please forgive me :) they looked nice at first but i really can't think of a project where i would use them, instead of a pic18 K22/K42.. (there could be a couple but redesigning the board for 3V operation, just to get a faster divide... nnaaah)
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #193 on: December 04, 2017, 02:59:15 am »
The smallest mm part I think is a 16k/4k part, and if using only a few vectors and need the space you can switch to single vector mode (linker needs to know, not sure of all the details).

The reason I ordered an mm usb curiosity board, was I now have an unrestricted compiler (they can get me in $1-$30 increments), and I was looking for a way to possibly do something like a pcm2706 with a micro/dac combo instead (need usb+i2s)-
https://goo.gl/photos/NeTGW3yKBvwEHDzG8  (bottom row, 2 on left - pcm2706 does sound good, even with the simple board I made)

I wanted to try the SAMD21, but after reading the datasheet a few times I still don't understand the clock system, and couldn't find any usb audio example code. The mm usb board had a usb headset demo that actually compiled without any errors (quite unusual), so I figured I could hook up my own dac and give it a try. Whatever one thinks of MPLABX, I already use it and can find my way around so nothing really to learn except the chip itself.

The only problems I have so far, is the datasheet had bad numbers for the interrupt register map- there is a gap they don't show so the numbers are off starting with IEC0. The defines they have show the true addresses (I'm not using xc.h, but am now double checking addresses). The debugging is a little sluggish, but that is a known thing with pickit3 type debuggers- no surprise. Other than the wrong addresses. my simple code blinking lights, reading switches is working and the chip is quite simple  to use not unlike a pic16. I'm also liking c++ although I'm relatively new to using it.
 

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 2277
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #194 on: December 04, 2017, 11:38:43 am »
Nicely presented schematic and layout.
What ECAD package are you using?
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #195 on: December 04, 2017, 01:33:57 pm »
Quote
What ECAD package are you using
Sprint Layout 6, sPlan 7

These are about the only ones I can use without much thinking, and the price is right. Combined, these two programs are a little over 10MB in size (that's an M), and run in Linux (Wine) so I can run on any of my pc's. I go a little overboard with the colors on the schematics, but just like to see what is possible. There is an interesting youtube channel with Sprint Layout 'tips' using it to create audio amplifiers.

some more stuff-
https://goo.gl/photos/jXXJuEtBk9RpjLer6
 
The following users thanked this post: splin

Offline picdev

  • Contributor
  • Posts: 14
  • Country: gr
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #196 on: December 05, 2017, 11:22:48 pm »
I thought that mikroc is crap, (IDE bugs, bugs on debuging)And i was planing to move to mplabx because I have start to write big projects,
no I am reading that mplab is crap too, (also I hate code generator).
 :-// So what about css with mplabx ? css has a very old Ide too  :palm:
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #197 on: December 06, 2017, 12:13:08 am »
Quote
I am reading that mplab is crap too
Like most things, what you read and what you may experience yourself are not always the same thing. In this case, you don't have to pay to find out. Download MPLABX and test it out, then you will know firsthand. Using a code generator is not a requirement (I don't use it).
 

Offline picdev

  • Contributor
  • Posts: 14
  • Country: gr
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #198 on: December 06, 2017, 06:18:31 am »
Quote
I am reading that mplab is crap too
Like most things, what you read and what you may experience yourself are not always the same thing. In this case, you don't have to pay to find out. Download MPLABX and test it out, then you will know firsthand. Using a code generator is not a requirement (I don't use it).
What about libraries ?
Sometimes you need something ready

Sent from my Redmi 4 using Tapatalk

 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #199 on: December 06, 2017, 07:31:37 am »
What about libraries ?
Sometimes you need something ready

Apart from USB and TCP/IP-stack, you write them yourself. At least I do. If there's a bug, I can blame myself instead of others.
Besides, what you have made, you can fix. The time I need to read and understand somebody elses code, I can write it from scratch.
 
The following users thanked this post: hans, Siwastaja, JPortici

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #200 on: December 06, 2017, 04:42:47 pm »
What about libraries ?
Sometimes you need something ready

... you write them yourself. At least I do. If there's a bug, I can blame myself instead of others.
Besides, what you have made, you can fix. The time I need to read and understand somebody elses code, I can write it from scratch.

Me too. I'll take well documented hardware datasheet over black-box libraries at any time.
 
The following users thanked this post: hans, Siwastaja

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #201 on: December 06, 2017, 04:52:15 pm »
What about libraries ?
Sometimes you need something ready

Apart from USB and TCP/IP-stack, you write them yourself. At least I do. If there's a bug, I can blame myself instead of others.
Besides, what you have made, you can fix. The time I need to read and understand somebody elses code, I can write it from scratch.
This. x1000000
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #202 on: December 06, 2017, 07:23:45 pm »
What about libraries ?
Sometimes you need something ready

... you write them yourself. At least I do. If there's a bug, I can blame myself instead of others.
Besides, what you have made, you can fix. The time I need to read and understand somebody elses code, I can write it from scratch.

Me too. I'll take well documented hardware datasheet over black-box libraries at any time.
Gee the “you need to use libraries” mentality...

I recently got into a bit of squabble on a Chinese embedded developers forum regarding the use of vendor-provided libraries. The other commenter insists that you should always use as much if the vendor libraries as possible so you don’t have to deal with low level stuff. I am not seeing the point here as the vendor libraries are not that much of an abstraction, do things you are not sure, and can be bloated AF.

There was even a thread complaining about losing SWD connection on STM32 with Cube-generated library code. Neither the OP or me have any idea what was going on, since nobody bloody knows what is going on inside the vendor libraries. The library might disabled SWD during initialization and despite the application enabling it later (also in generates code) the connection is already down. And don’t get me started on the extreme bloat that is known as STM32Cube. Bloody hell. AFAIK the ASF and Harmony isn’t any much better. Float point arithmetic just for I2C baudrate calculation? I am kind of okay with this if you are using Cortex-M4F hard float ABI (so guaranteed existence and access to FPU) bit on a M0? Are you kidding me?
« Last Edit: December 06, 2017, 07:27:32 pm by technix »
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #203 on: December 06, 2017, 07:45:58 pm »
I recently got into a bit of squabble on a Chinese embedded developers forum regarding the use of vendor-provided libraries. The other commenter insists that you should always use as much if the vendor libraries as possible so you don’t have to deal with low level stuff.

They just don't have a freaking clue about what they are talking about, they have no experience, no understanding, no knowledge.

I have gone through that battle too many times in the past. It simply doesn't make sense to argue with them. I have never seen a working system made by those people, except some hello world led blinkers on a demo board. And to make that led blink through the library, they can waste weeks, it's not a problem since it's supposedly "saving time in the future".

99% of the time, what is called a "library" is simply an utter disaster, made by idiots for idiots, wrapped into huge complexity and poorly written code, but nothing fancy going on.

Although, 1% of the time, there are quite some nice things you can use.

BTW, to some degree, this even applies to PC software side. Of course, the things are more vague there, as much higher software complexity often necessitates some library usage. Still, this only makes it even more important to focus on the quality, not quantity, of the libraries.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #204 on: December 06, 2017, 08:03:58 pm »
Quote
I recently got into a bit of squabble on a Chinese embedded developers forum regarding the use of vendor-provided libraries. The other commenter insists that you should always use as much if the vendor libraries as possible.
That says a lot about how Chinese firmware gets done-throw some libraries together instead of using any original creativity.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline picdev

  • Contributor
  • Posts: 14
  • Country: gr
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #205 on: December 06, 2017, 08:28:41 pm »
On my last project I had to work with a big protocol.
So at first I worked with the simple UART functions of mikroc .
Later I write my own uart functions with interrupt for tx and Rx , I used also buffers etc.
I wirte my own task manager and I made a lot of work from scratch.
But mikroc libraries help me to start.

Also we speak about 16bit mcus,
How about stm? Is it possible to write your own libraries on such  complicated arm MCU ?

Sent from my Redmi 4 using Tapatalk
« Last Edit: December 06, 2017, 08:30:53 pm by picdev »
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #206 on: December 06, 2017, 09:55:19 pm »
Float point arithmetic just for I2C baudrate calculation? I am kind of okay with this if you are using Cortex-M4F hard float ABI (so guaranteed existence and access to FPU) bit on a M0? Are you kidding me?

I saw this for an ATTiny delay calculation as well. No way that this fits in 2k flash, so the compiler probably optimized it at compile time to a constant, which should be possible if you use constants as the arguments.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #207 on: December 06, 2017, 10:14:12 pm »
How about stm? Is it possible to write your own libraries on such  complicated arm MCU ?

Not only possible, but practically mandatory for the development to be "sustainable" - the ST-provided libraries are total joke. The STM32 libraries don't offer much or any abstaction (which is the whole point of using libraries in the first place) -- instead, they wrap every configuration register access to a more complex, bloated boilerplate, you still need to exactly know what configuration registers to access in what sequences, just instead of 10 lines you use 200 lines to do the same. Needless to say, no one writes that kind of code from scratch - just writing the code to change an IO pin to an output would take minutes, and it'd be impossible to remember how all the configuration structs and functions were called - that's why it's either copy-pasted from example files, or forum posts; or autogenerated with code generation tools.

Or, like sensible people do, don't use that shit.

I can understand your notion that higher complexity requires something "better" than total "DIY". While this would be true in the ideal world, in real world, the libraries more often end up increasing complexity. And the more complex something is to begin with, the more important it becomes that this complexity is not increased even more. In practice, this means: either use very high-quality abstaction layers/libraries or do your own. In STM32, it's the latter.

But, in the end, you can, and I certainly do, write STM32 code exactly in the same manner I have been doing 8-bit AVR code since forever: look at the reference manual, configure the registers. For example, setting an IO pin as an output is:
(1) In AVR: 1 bit written in 1 register
(2) In STM32 "bare": 2 bits written in 1 register, and remember to turn the port clock on first (1 bit in 1 register).
(3) In STM32 "libraries": about 10 lines of building a configuration structs with long names and passing them to functions, you need to remember everything correctly or copy-paste it.

I'm sorry to say this but using such a complex product (especially with STM32 with dozens of pages of errata, with a lot more officially undocumented) results in so many strange issues to be debugged that you absolutely need the skills and mindset to thoroughly crawl in the mud through the reference manual - even if you used a library. And with the library, you have more code to reverse-engineer while doing this. Instead, you need to be building piece by piece, bottom up.

I like looking at the library code as a reference when I'm stuck and nothing else helps, but this rarely happens, and it rarely helps, since the libraries do not actually do much, are often limited in functionality, poorly designed, or outright broken by design.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #208 on: December 07, 2017, 12:12:59 am »
How about stm? Is it possible to write your own libraries on such  complicated arm MCU ?
Why would it not be.
One peripheral at a time.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #209 on: December 07, 2017, 12:32:57 am »

I like looking at the library code as a reference when I'm stuck and nothing else helps, but this rarely happens, and it rarely helps, since the libraries do not actually do much, are often limited in functionality, poorly designed, or outright broken by design.
And IME libraries are often a big mess of multiple-level #defines and macros in way too many files so it's often very difficult to figure out what they're doing - just figuring out what constant ends up being written to a register can be quicker to do by reading it back & spitting it out of a serial port than working it out by looking at the code.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 
The following users thanked this post: Siwastaja

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #210 on: December 07, 2017, 03:01:29 am »
Quote
I saw this for an ATTiny delay calculation as well. No way that this fits in 2k flash, so the compiler probably optimized it at compile time to a constant, which should be possible if you use constants as the arguments.
In fact, the avr-libc "_delay_ms(float time)" is VERY EXPLICITLY DOCUMENTED to require that "time" be a compile-time constant AND that you have enabled enough optimization to make sure that the various calculations all happen at compile time:

http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html :
Quote
In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable), and applications that otherwise do not use floating-point calculations will experience severe code bloat by the floating-point library routines linked into the application.

(This doesn't stop it from biting someone a couple times a year...)
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #211 on: December 07, 2017, 09:22:09 am »
Quote
I saw this for an ATTiny delay calculation as well. No way that this fits in 2k flash, so the compiler probably optimized it at compile time to a constant, which should be possible if you use constants as the arguments.
In fact, the avr-libc "_delay_ms(float time)" is VERY EXPLICITLY DOCUMENTED to require that "time" be a compile-time constant AND that you have enabled enough optimization to make sure that the various calculations all happen at compile time:

http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html :
Quote
In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable), and applications that otherwise do not use floating-point calculations will experience severe code bloat by the floating-point library routines linked into the application.

(This doesn't stop it from biting someone a couple times a year...)
And does the macro generate a compile-time warning of these conditions are not met ?

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #212 on: December 07, 2017, 10:00:36 am »
Quote
I saw this for an ATTiny delay calculation as well. No way that this fits in 2k flash, so the compiler probably optimized it at compile time to a constant, which should be possible if you use constants as the arguments.
In fact, the avr-libc "_delay_ms(float time)" is VERY EXPLICITLY DOCUMENTED to require that "time" be a compile-time constant AND that you have enabled enough optimization to make sure that the various calculations all happen at compile time:

http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html :
Quote
In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable), and applications that otherwise do not use floating-point calculations will experience severe code bloat by the floating-point library routines linked into the application.

(This doesn't stop it from biting someone a couple times a year...)
And does the macro generate a compile-time warning of these conditions are not met ?
They do.

Although I am wondering for the fork that requires GCC 5, why not surround that code in attribute((optimize("-Os"))) or the like so the compiler knows that this bit of code must be optimized disregarding the command line settings?
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #213 on: December 07, 2017, 10:21:40 am »
Quote
I recently got into a bit of squabble on a Chinese embedded developers forum regarding the use of vendor-provided libraries. The other commenter insists that you should always use as much if the vendor libraries as possible.
That says a lot about how Chinese firmware gets done-throw some libraries together instead of using any original creativity.
You kind of expect it from an engineer that is paid $5 an hour or less, and from bosses that have no intention of maintaining their products after release (not even past the 1.0-itis.) If I am tied down to a job paying $5 an hour with 72-hour weeks, how can I have the time or resource to perform the in-depth thinking and experimenting that is required for original creativity? I don't have a day job for now, not because I am not interested in work, but because the job offers I get ended up making me fell less human. I might get a teaching license if this kind of offer is still running rampant.

And way too many people try to copy others' work (hence the need of heavily fortified MCU's and the abundance of "MCU decryption services") to make quick money. Yes electronics in China are cheap, but it comes with the cost of heavily undervaluing human intelligence and violation of intellectual properties.

A lot of people in China have weak to none moral compasses, and wherever there is money there will be a lot of sort-of-rich people dragging their employees into grabbing quick money from it. Nobody bloody want to use any original creativity, since nobody values it anyway; and nobody can use original creativity, as they are prevented from having any in the first place.
« Last Edit: December 07, 2017, 10:26:14 am by technix »
 

Offline KL27x

  • Super Contributor
  • ***
  • Posts: 4099
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #214 on: December 07, 2017, 10:48:21 am »
Quote
Apart from USB and TCP/IP-stack, you write them yourself. At least I do. If there's a bug, I can blame myself instead of others.
Besides, what you have made, you can fix. The time I need to read and understand somebody elses code, I can write it from scratch.

Thanks, Karel, for posting this.

I am self-taught and work in a bit of a vacuum. All this time I thought I was bad at coding for writing all my own code, rather than "simply" reading and understand and altering premade libraries. (Also, after a few hours of trying to grasp USB, I noped out of it.) 

Your post and the host of followups from other members who I look up to has made me feel a little less retarded, today.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #215 on: December 07, 2017, 11:58:41 am »
Quote
Apart from USB and TCP/IP-stack, you write them yourself. At least I do. If there's a bug, I can blame myself instead of others.
Besides, what you have made, you can fix. The time I need to read and understand somebody elses code, I can write it from scratch.

Thanks, Karel, for posting this.

I am self-taught and work in a bit of a vacuum. All this time I thought I was bad at coding for writing all my own code, rather than "simply" reading and understand and altering premade libraries. (Also, after a few hours of trying to grasp USB, I noped out of it.) 

Your post and the host of followups from other members who I look up to has made me feel a little less retarded, today.
USB and TCP/IP are the two big complicated protocols you may want to stick to a library with, but for everything else you might be better just start from scratch. You won't want to risk it with USB or TCP/IP, since USB libraries are hard to write without an (likely expensive) USB protocol analyzer unlike SPI or I2C that most oscilloscopes (ex. Rigol DS1054Z after the hack) can decode, a bad USB library can make the host computer crash, and a bad TCP/IP library leaves you vulnerable to hackers. All pre-made libraries have their strengths and drawbacks though, and you need to choose and discard them based on what you need.

For example I know that a good portion of Chinese STM32 engineers feel that STM32Cube+FreeRTOS is the best support library for STM32 ever and they don't even talk about coding bare metal. However I found that setup bloated and just throws it away in favor of my own stack (temporarily named DreamOS-RT but not quite linked to my own DIY OS project DreamOS.) that implementes a few modified Arduino interfaces.
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #216 on: December 07, 2017, 07:30:49 pm »
All pre-made libraries have their strengths and drawbacks though, and you need to choose and discard them based on what you need.
And what most people need is the quickest easiest solution that gets the job done - which is why they use libraries.

Quote
A good portion of Chinese STM32 engineers feel that STM32Cube+FreeRTOS is the best support library for STM32 ever and they don't even talk about coding bare metal. However I found that setup bloated.
Bloated for sure, but who has the time and skill to write everything themselves?  Just throw more memory and a faster CPU at it!
 
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #217 on: December 07, 2017, 07:33:42 pm »
And what most people need is the quickest easiest solution that gets the job done - which is why they use libraries.

For often inferior values of "job done"
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #218 on: December 07, 2017, 08:59:58 pm »
And what most people need is the quickest easiest solution that gets the job done - which is why they use libraries.

This is often a fallacy. It's touted often enough that people actually believe it, like it's some kind of law of physics, never questioned.

It's true with exceptionally good libraries - or in the case of extreme underlying, inevitable complexity that must be there. (TCP/IP or USB stack might be usable examples.)

However, most libraries are horribly bad and only end up wasting everyone's time. And, most of the time, they only solve trivial problems. Especially in embedded. In embedded, they often are unusable as is due to the highly hardware-dependent implementation; sidestepping this issue requires extremely good library design skills, rarely seen.

Indeed, in some cases, the design flow of "use random libraries, copypaste random code from the Internet or example files, try random things until it works" is used. This allows people with substandard skills and no experience in programming to produce something - but most of the time, they just talk big and fail to provide anything at all. Even if they eventually do provide, this design flow is not "easy" or "quick" at all. I have overseen stunts like this too many times, and it's not uncommon at all to spend weeks of combining those libraries to get a Minimum Viable Prototype (version 0) out. They just genuinely think it's inevitably that hard, and they actually believe that the libraries "helped" them and it would have been years without, since they have bought the law: "libraries make hard things less hard" without questioning its context.

Typically, I can deliver similar minimum viable software prototype in about a day or two. (Sometimes, these two-day coding session products end up being in heavy production use for years without touching :P).

Can't do that with "libraries", unless you happen to find a finished example application exactly designed for that purpose. If one exists, by all means use it. Heck, if you can go out and buy the thing, do that. But I'm called in when someone needs something that doesn't exist.

Good programmers/developers/designers are rare. It's attitude like this (false sense of laziness, you think you save time, but you actually waste it, especially in the long run, since you prevent yourself from learning anything) that keeps this number low.

Real, succesful laziness keeps us innovating. How to make things quickly in the long run? The answer: don't muscle it, do it wisely! Understand what you are doing!
« Last Edit: December 07, 2017, 09:06:28 pm by Siwastaja »
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #219 on: December 07, 2017, 11:04:35 pm »
And what most people need is the quickest easiest solution that gets the job done - which is why they use libraries.
In embedded, they often are unusable as is due to the highly hardware-dependent implementation; sidestepping this issue requires extremely good library design skills, rarely seen.

Indeed, software developers like to write generic solutions for problems, especially when it can be platform independent. This has brought us good things, like programming languages such as C, but perhaps also bad things, like overgeneralized solutions. Matching this with hardware often doesn't make sense, because a few examples:

1) Not every microcontroller pin is connected to the analog mux for ADCs or "output" PWM. Some libraries imply every pin can be read analog. See further.
2) More specific example: on STM32F4 not every DMA stream/channel is mapable to any request, and even multiple peripherals share the same channel, thus blocking some multi-DMA setups from working all together. Does a software library assert these limitations and perform preferably compile time checks on this? Is C expressive enough for these static checks? Woops!

Example on 1): take Arduino libraries. These are often praised for throwing together a quick prototype. Let's look at analogWrite: https://www.arduino.cc/reference/en/language/functions/analog-io/analogwrite/
The "contract" for this function, at first glance, seems to be relatively simple:
Quote
Parameters
pin: the pin to write to. Allowed data types: int.
value: the duty cycle: between 0 (always off) and 255 (always on). Allowed data types: int

Returns
nothing

But then see the following mess:
Quote
On most Arduino boards (those with the ATmega168 or ATmega328P), this function works on pins 3, 5, 6, 9, 10, and 11. On the Arduino Mega, it works on pins 2 - 13 and 44 - 46. Older Arduino boards with an ATmega8 only support analogWrite() on pins 9, 10, and 11.
The Arduino DUE supports analogWrite() on pins 2 through 13, plus pins DAC0 and DAC1. Unlike the PWM pins, DAC0 and DAC1 are Digital to Analog converters, and act as true analog outputs.
You do not need to call pinMode() to set the pin as an output before calling analogWrite().
Makes me wonder, what actually happens if you chose an invalid pin? This could happen because you upgraded from a Mega to a Due board.. The documentation doesn't say much.. well actually this happens:
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/wiring_analog.c#L284
Great 1-bit analog output. In pragmatic ways; yes this is the best one can do. But this kind of undefined internal behaviour can drive a programmer crazy.
Not to say some of the side effects functions can have, e.g. this forces the I/O into "output" mode. What happens if you actually had set it up as an open-drain PWM? Is that now disabled?

If you look at e.g. CMSIS libraries; there was a question if these can be written yourself. Yes they can. It's actually not that much more complex than on a PIC microcontroller; it's just there is a bit more to do. But I don't define that as immediately "complex".
That is because these libraries internally contain almost no state whatsoever. Their functions are just 'convenient' functions to use peripherals, if they contain no spelling mistakes, errors, abuse of floats, etc. (which in my experience is not uncommon, no vendor excluded)
Maybe convenient is not the right word, let me rephrase: they contain some 'mechanical' operations to push a set of values into registers. In many cases you can still mix flags between peripherals (like interrupt flags); as long as the "bits" it's accepted. They are not dummy proof.

When you're designing a system that uses peripherals in a clever way, like a combination of UARTs, SPIs, timers, DMA, interrupts and clock control, you may dive deep into datasheets to find out what operation modes each peripheral should run. While you're at this level, you might as well push these settings into registers yourself.. it's not that much effort anymore.

And if you're really uncomfortable how a peripheral works, there is always a cheat sheet.. namely github.com and CMSIS itself. But don't take any piece of code by heart. Think critical about design decisions. Sure a floating point type will work for baud rate calculation. Maybe it was the easiest solution to a fractional baud rate division calculator. But alternative algorithms exist.
And perhaps you don't even require these run-time calculations of baud rate.. just punch your clocks into a calculator and hard code the numbers. If you're quite pragmatic and worry about documenting your chosen values, this can work reasonably well..
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #220 on: December 08, 2017, 06:14:46 am »
Good programmers/developers/designers are rare. It's attitude like this (false sense of laziness, you think you save time, but you actually waste it, especially in the long run, since you prevent yourself from learning anything) that keeps this number low.
And it will always be this way because the vast majority are not good programmers/developers/designers, they are just average schmucks trying to make a living. These people will never be able to write good code themselves, but they can produce (mostly) working code using libraries. If that keeps them employed then - mission accomplished!

Quote
Real, succesful laziness keeps us innovating. How to make things quickly in the long run? The answer: don't muscle it, do it wisely!
Real, successful laziness means using other people's code rather then taking the time to write your own.

Quote
Understand what you are doing!
...is unnecessary. You only need to understand just enough to get your code to (mostly) work.


 
The following users thanked this post: hans

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #221 on: December 08, 2017, 06:48:57 am »
Bruce Abbot, you have completely given up hope, without realizing it, and are just rationalizing it. I'm so sorry for you.

I'm not questioning the "just get the job done quick&dirty" attitude. I work that way. Our current company motto is "good enough", coined by me.

It's just that you are simply&plainly wrong about how to achieve that target.

While I agree it's not for everyone, becoming a decent (not necessarily great) programmer is not rocket science. I can do it, you can do it, many of those "hack something together with copypasta code" people can do it, because they do have the persistence. I know this because I have seen how difficult, slow and unrewarding it often becomes to build software that way. They only need to find the root cause to their issue and fix that, and their next project will be quicker and easier - and more satisfying. This satisfaction will also keep them in the business, making a living in the long run, too.

Personal story: before I found out that the way I'm doing this is exactly right, I also did live the phase of questioning: "I'm doing something wrong, must use moar libraries!" When I accessed HD44780 display for the first time, I spent a few hours trying to find a library and to get it to work. Nothing, did it from scratch, took maybe half an hour. Which one was quicker? Two hours - no result, or half an hour - working project?

The same happened later with the DS1820 temperature sensor. This is more complex than HD44780, I surely need to use a library to speed up my design, I just want this to work as quickly as possible! Logical motivation, makes sense. So, again, trying to find a library, tried two or three libraries, wasted a full day (maybe 10 hours), nothing works at all, can't find the reason, not enough skills to debug through the massive library code. Next day, write my own from scratch, about 6-7 hours later working just as expected. Again, which one was quicker?

The comparison is meaningless, since in these cases, the "reuse existing code" solution didn't work at all, ended up just wasting my time. I don't know how long it would have been taken to get that DS1820 to work, but watching others do the same using the copypasta method (and me helping them out to get it work), I'd expect about a week.

And I was somewhat a beginner at that point. If I redid the same test now, I could probably find out why those libraries did not work much quicker, and actually make them work in some manageable time, like a day or two. On the other hand, making the own solution has become even easier for me.

Another personal story: at the local electronics club, I have "overseen" one particular guy who started from absolute scratch about two years ago. He came and started asking about Arduinos, and I told him: forget all the libraries, here's the datasheet. Now, he's been the fastest learning guy I've ever seen. After a few months, he made his own software-controlled boost DC/DC controller. A few months later, a coffeemaker controller, with strain gauge + his self-designed amplifier circuit for it to measure the amount of coffee, RTC chip, with ESP8266 control over WiFi and all kinds of interesting features and modes. Horrible hacked up stuff held in place with hot melt glue, but a lot of innovation in no time. This innovation and quick development cycle is completely thanks to "do it from scratch, code it yourself" attitude.


Here we have this metaphor which probably sounds funny when directly translated: "go through gray rock". This, with the untranslatable "sisu", is the side of Finnish culture I don't like. It's anti-innovation and focuses on early narrow-minded decision and having huge persistence and motivation to keep going through that gray rock, while a wise man would just walk around that rock.

But sometimes it's not self evident which way is easy and sustainable in the long run, especially when you listen to others, all the mixed signals you get.

The world tells you to use libraries (quantity over quality), frameworks, trendy programming languages, complex structures, etc. It happens so widely that you suspect: "they must be right", and you start questioning your own intuition, then you stop being intuitive and start going through the rock. Don't do this, become something better!
« Last Edit: December 08, 2017, 08:42:50 am by Siwastaja »
 
The following users thanked this post: Karel

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #222 on: December 08, 2017, 08:04:57 am »
Quote
most libraries are horribly bad and only end up wasting everyone's time.
I think I'm going to have to disagree, in general.
There are a lot of libraries that I'm willing to use, and have very little interest in re-writing.  libc.  floating point arithmetic.  File system code.  printf and string handling functions (except under special circumstances.)  xml parsers.  regular expression code.
These are all things that have matured to a point, and are pretty well understood.  Things that annoy people with them have been addresses in "modified" versions.   They've been used by a lot of people on a lot of systems, and ... they are pretty much the way I'd write them anyway.

They are platform independent and usefully abstract other dependencies, aiding portability.

The objectionable libraries are the supposed "Low level hardware abstraction libraries", where vendors try to wrap their proprietary and highly unique hardware features in code that is somehow easier to understand even though it is no less proprietary and no less unique, and has as a secondary unstated goal of locking your to that proprietary uniqueness.   Worse, it's at a level where there aren't widespread agreements on how things should work, or where that varies depending on the exact application; a level where Choices Are Made...
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #223 on: December 08, 2017, 08:12:35 am »
maybe with "libraries" they were referring to "peripheral libraries"?
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #224 on: December 08, 2017, 08:34:02 am »
Quote
most libraries are horribly bad and only end up wasting everyone's time.
I think I'm going to have to disagree, in general.
There are a lot of libraries that I'm willing to use, and have very little interest in re-writing.  libc.  floating point arithmetic.  File system code.

Filesystem code I wrote it myself as well. I had a project where I only wanted to write one file, no directories, no reading.
The common FAT32 libraries are overkill for such a purpose and FAT32 is actually quiet simple to implement.
This combined with my own code to access SD-cards created a fast, lean and robust piece of software.
This is important if you want to do commercial high volume projects and want to keep hardware cost and power consumption low.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #225 on: December 08, 2017, 08:40:33 am »
westfw, you are indeed correct. I didn't express myself too well. Of course, there is no point in recreating libc or software floating point standard libraries in most cases, even though sometimes even that makes sense.

But my point is, when someone is praising the ease of doing a project "with libraries" and reusing other's code, they are never talking about libc. Because almost everyone uses libc in almost every project, it's there "by default", many people don't even know what it is.

Yes, I was talking mostly about embedded-specific libraries, typically hardware abstraction. They are often pure shit. For a few good reasons: typically, a library is not needed, so few people want to develop them -> no good developers to make good library design. Second, in embedded, everything is too case-by-case specific and special. Very difficult to make a universally working library. The same goes with application notes that provide example code: they are too specifically designed, just to provide that single example. So they are not very useful in the actual customer application as is; they need to be redesigned so much that the amount of code that can be reused is often near zero.

At the same time, I was also talking about very "high-level" unnecessary libraries increasing complexity and being used just because they are trendy. I don't know if Boost is the best example, but something like that. I mean stuff that requires a significant learning curve to be useful at all, and even then of questionable value.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #226 on: December 08, 2017, 02:14:19 pm »
The libraries came to the embedded world from generic software development. Say, in Windows, your program may run on many different computers (who knows what) and it must display things correctly. So, a library is needed to interface your hardware-oblivious code to the specific graphics hardware. Hence you have GDI and also graphic drivers. There's no other way.

In the embedded world you don't want to be hardware-oblivious - your goal is to control hardware. You have a choice of the hardware. When you choose your hardware it is partly because you want it to work a certain way. You want to access specific features. Why would you use a library which tries to treats your carefully-chosen hardware in some generic way?

The very existence of such libraries is the result of applying programming principles developed for "big computers" to the embedded works. It is done without thinking, does not have any merit and is rather an impediment on embedded programmer's way.

 
The following users thanked this post: hans, Siwastaja, Karel, JPortici, fourtytwo42

Offline picdev

  • Contributor
  • Posts: 14
  • Country: gr
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #227 on: December 11, 2017, 07:48:42 pm »
As I see that there are a lot of good engineers in this topic , I have one question about arm.
I write c on 8 and 16 bit mcus , I don't have the need to go to arm , also there are 8bit mcus with pll and run at 64mhz .
So most  engineers say that arm have ethernet USB and are cheap.
So you chose stm32 207 with Ethernet , you pay 10 Euros for this MCU, and you must add  an ic for phy. Layer , so you pay extra  5 Euros .
And now you have a scary physical layer library and TCP /IP stack in your software , maybe you must add an rtos .
 Also stm give you a phycal library for a specific ic .
Why I have to chose this complex model?
I see that I can use a cheap  MCU with no Ethernet and one wiznet ic with intergrated tcp IP stack ?

I am sorry for my English


Sent from my Redmi 4 using Tapatalk
« Last Edit: December 11, 2017, 07:50:37 pm by picdev »
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #228 on: December 11, 2017, 09:06:35 pm »
As I see that there are a lot of good engineers in this topic , I have one question about arm.
I write c on 8 and 16 bit mcus , I don't have the need to go to arm , also there are 8bit mcus with pll and run at 64mhz .
So most  engineers say that arm have ethernet USB and are cheap.
So you chose stm32 207 with Ethernet , you pay 10 Euros for this MCU, and you must add  an ic for phy. Layer , so you pay extra  5 Euros .
And now you have a scary physical layer library and TCP /IP stack in your software , maybe you must add an rtos .
 Also stm give you a phycal library for a specific ic .
Why I have to chose this complex model?
I see that I can use a cheap  MCU with no Ethernet and one wiznet ic with intergrated tcp IP stack ?
I've used the Wiznet W5500 chip on a PIC32MZ that has an ethernet peripheral - the cost was similar to a PHY, and I didn't need to deal with Microchip's Harmony library BS.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline mrpackethead

  • Super Contributor
  • ***
  • Posts: 2845
  • Country: nz
  • D Size Cell
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #229 on: December 12, 2017, 02:59:08 am »
I've gone nearly full circle on harmony.   Its a scary learning curve its poorly docoumetned, and the examples are crap.  BUT once you get past that,  ( only took me 18 months ) I actually now can turn out working applications that are resoanbly complex in veryh short time frames.   I use the MZ and various phys.

On a quest to find increasingly complicated ways to blink things
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #230 on: December 13, 2017, 01:32:47 am »
There are certain libraries that I think most everyone uses. Who here writes their own floating point code to implement the basic math operations or things like printf? Most people just use what the compiler vendor provides, and that works well enough for 99% of the people using it.

Peripheral libraries are another thing entirely and these range from mediocre to just plain shit. Since this is a PIC thread, does anyone actually use Harmony? On a scale of 0 being shit and 10 being great, Harmony is probably a -5.
Complexity is the number-one enemy of high-quality code.
 

Offline mrpackethead

  • Super Contributor
  • ***
  • Posts: 2845
  • Country: nz
  • D Size Cell
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #231 on: December 13, 2017, 05:20:06 am »
There are certain libraries that I think most everyone uses. Who here writes their own floating point code to implement the basic math operations or things like printf? Most people just use what the compiler vendor provides, and that works well enough for 99% of the people using it.

Peripheral libraries are another thing entirely and these range from mediocre to just plain shit. Since this is a PIC thread, does anyone actually use Harmony? On a scale of 0 being shit and 10 being great, Harmony is probably a -5.

Yes, and deployed solutions based on it sucessfully.    It was a steep learning curve, but now i'm actulaly able to get it to do things quickly and profitably.
On a quest to find increasingly complicated ways to blink things
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #232 on: December 13, 2017, 05:41:18 am »
Just going back a bit because it’s something I recently checked,
Microchip’s image decoder library contains free code for JPEG decompression that once packaged into their own library,
Microchip say you can’t modify that either if I understand correctly (like GCC).

Code: [Select]
* jidctint.c
 *
 * Copyright (C) 1991-1998, Thomas G. Lane.
 * This file is part of the Independent JPEG Group's software.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #233 on: December 13, 2017, 11:04:04 am »
Just going back a bit because it’s something I recently checked,
Microchip’s image decoder library contains free code for JPEG decompression that once packaged into their own library,
Microchip say you can’t modify that either if I understand correctly (like GCC).

Code: [Select]
* jidctint.c
 *
 * Copyright (C) 1991-1998, Thomas G. Lane.
 * This file is part of the Independent JPEG Group's software.
That thing is libjpeg, which comes under BSD-like license, so Microchip technically can restrict the use of their version, although since it is libjpeg after all you can prevent the Microchip version from being linked it and substitute your own fork of it.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #234 on: January 22, 2018, 02:54:50 pm »
Hi :D I was waiting for my trial period to expire before trying it,
but I actually have the specific version 1.33 XC16 mentioned in the file, and the specs.txt file method doesn’t work.

Assuming this was a hex editor view, what actually has to be changed to what here?
Code: [Select]
8472db5: 8b 35 a0 25 94 08    mov    0x89425a0,%esi
 8472dbb: 85 f6                test   %esi,%esi
 8472dbd: 0f 85 d2 05 00 00    jne    8473395 <pic30_override_options+0x895>
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #235 on: January 22, 2018, 03:24:38 pm »
Hi :D I was waiting for my trial period to expire before trying it,
but I actually have the specific version 1.33 XC16 mentioned in the file, and the specs.txt file method doesn’t work.

In case it doesn't work out, you can always fall back to the method described here:

https://www.eevblog.com/forum/microcontrollers/pic32-evolution/msg1007099/#msg1007099
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #236 on: January 22, 2018, 04:17:58 pm »
Hi, mine is on a Mac, and I don’t have the tools for that.
I was hoping the easy way would work :D

I’m on a phone in bed now, and realised the blank line in the
Spec.txt might be wrong.
TextEdit for Mac insets 0x0A characters for new lines,
where other editors such as Windows Notepad inserts
0x0A, 0x0D. Hopefully it’s just that.

I have the same Ver XC16 as in the help document,
and my MPLAB-X ver is actually a few updates old,
so I don’t see how any new measure could stop it working.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #237 on: January 22, 2018, 09:33:42 pm »
Quote
Hopefully it’s just that.
I doubt it. My specs.txt file for xc16 has only a 0x0A (linux, created with kwrite), which works.

I would suspect something wrong with the global option-
-specs=specs.txt
although if something was wrong, the compiler would start complaining (you did add that option, right?)


You should be able to run this script (option 3) on a Mac
if not, then my opinion of Mac OS just went down :)
need- terminal- bash (or similar), objdump, grep, xxd, sed

get to terminal in this directory-
/opt/microchip/xc16/v1.33/bin/bin/
(not sure, maybe Mac uses something else, adjust as needed)

copy and paste this script-

Code: [Select]
for f in elf-cc1 coff-cc1; do
[ -e $f.bak ] || cp $f $f.bak
a=$(objdump -T $f | grep mchp_mafrlcsj)
a=${a:6:2}${a:4:2}${a:2:2}${a:0:2}
b=$(objdump -t elf-cc1 | grep gcc_version)
b=${b:6:2}${b:4:2}${b:2:2}${b:0:2}
old="\(8b..\)${a}"
new="\1${b}"
xxd -ps $f.bak | sed "s:$old:$new:" | xxd -r -p - $f
done

summary-
line1- just simply do for each  of these 2 files (nobody probably uses coff file, though)
line2- if backup copy not previously made, make one
line3- using objdump, get address of mchp_mafrlcsj
line4- convert address to little-endian
line5- using objdump, get address of gcc_version
line6- convert to little-endian
line7- create var for sed search- 8b..address of mchp_mafrlcsj
line8- create replacement var for sed- 8b..address of gcc_version
line9- dump file into sed as hex, replacing first (only) instance of match, dump back out to binary
line10- done

You can also use a hex editor on elf-cc1-
you need the address of mchp_mafrlcsj so you have something to search for (address is little-endian)
option1- replace the address of the mov instruction target from mchp_mafrlcsj to gcc_version
(need both addresses, from objdump)
option2- replace the jne soon after the mov to je (I think 0f 85 to 0f 84)
« Last Edit: January 22, 2018, 11:33:19 pm by cv007 »
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #238 on: January 23, 2018, 03:03:52 am »
It looks like it will work, as in no errors, but actually doesn’t.

Code: [Select]
for f in elf-cc1 coff-cc1; do
[ -e $f.bak ] || cp $f $f.bak
a=$(otool -T $f | grep mchp_mafrlcsj)
a=${a:6:2}${a:4:2}${a:2:2}${a:0:2}
b=$(otool -t elf-cc1 | grep gcc_version)
b=${b:6:2}${b:4:2}${b:2:2}${b:0:2}
old="\(8b..\)${a}"
new="\1${b}"
xxd -ps $f.bak | sed "s:$old:$new:" | xxd -r -p - $f
done

otool is apparently the Mac version of objdump.
It ends up with errors unless I change it.

Code: [Select]

Breks-Mac:desktop bmar0000$ cd XC16_Backup
Breks-Mac:XC16_Backup bmar0000$ cd xc16/v1.33/bin/bin/
Breks-Mac:bin bmar0000$ for f in elf-cc1 coff-cc1; do
> [ -e $f.bak ] || cp $f $f.bak
> a=$(otool -T $f | grep mchp_mafrlcsj)
> a=${a:6:2}${a:4:2}${a:2:2}${a:0:2}
> b=$(otool -t elf-cc1 | grep gcc_version)
> b=${b:6:2}${b:4:2}${b:2:2}${b:0:2}
> old="\(8b..\)${a}"
> new="\1${b}"
> xxd -ps $f.bak | sed "s:$old:$new:" | xxd -r -p - $f
> done

Breks-Maci:bin bmar0000$

No complaining in the terminal, but the project still tells me my license is restricted just the same.


« Last Edit: January 23, 2018, 03:05:52 am by @rt »
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #239 on: January 23, 2018, 03:27:31 am »
First, my script does have an error- line5 should be $f instead of elf-cc1 (probably didn't cause any problem as it only effects coff-cc1 users)

In linux, the ones to modify are in bin/bin- the ones in bin call the ones in bin/bin- a level of indirection for some reason (prevents -mafrlcsj option for one thing).

I'm not a Mac person, so not familiar with its tools, and its exe format (not elf apparently).

I would start over, cp your .bak copies back to original name so you are working with original copies again (always keep the .bak versions around for times like this).

in your bin/bin directory-
cp elf-cc1.bak elf-cc1
cp coff-cc1.bak coff-cc1

now you are working with the originals again

forget the script for now, just get the addresses from the command line-
otool -T elf-cc1 | grep mchp_mafrlcsj
otool -t elf-cc1 | grep gcc_version

once you get those two addresses, report back- will simply then need to run a hex edit program.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #240 on: January 23, 2018, 03:52:04 am »
I backed up the whole XC16 directory elsewhere before touching them. Then when it didn’t work,
deleted XC16 from the Application directory, and replaced the whole lot with original, so the .bak files don’t even exist anymore.

Code: [Select]
Breks-Mac:~ bmar0000$ cd /Applications/microchip/xc16/v1.33/bin/bin
Breks-Mac:bin bmar0000$ otool -T elf-cc1 | grep mchp_mafrlcsj
Breks-Mac:bin bmar0000$ otool -t elf-cc1 | grep gcc_version

I guess that’s a problem then :D
« Last Edit: January 23, 2018, 03:58:10 am by @rt »
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #241 on: January 23, 2018, 04:14:24 am »
I’ve subscribed monthly to XC16 Pro, because I need it working, and it’s running again.
$29US per month is what the free software costs, or $1500US for a USB dongle for XC16 only.

Just like the spec.txt method, I won’t really know if it works now on the Mac, because it’s Pro now anyway.

I can just as easy install this on a Windows 7 boot tonight, and try the other methods again.
I actually prefer the specs.txt way, without modification of anything, and it’s actually the project that enables it,
which could transfer between machines.

If it all works on Win 7, I’ll forgo my licence on the Mac install, and start fiddling with the Mac install again.

I’m pissed enough that I’m prepared to go and say anything on a well established account on Microchip’s own support forum
because I’m writing free, and what will become open source software with the thing!
I’m also pissed enough that I’d go look at starting again on another controller for my next project.

I only want this working for bugs others might discover.
I spent the last couple of weeks of the 60 day period looking for bugs while I could still compile.

Is this a rant yet? I’ll stop now :D







« Last Edit: January 23, 2018, 04:15:56 am by @rt »
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #242 on: January 23, 2018, 05:50:29 am »
I'm not sure otool options are the same as objdump. There are other utilities to do the job, like nm , maybe osx has nm?

nm elf-cc1

I'm not familiar with osx binary format, but 'something' should be able to give you the address of the symbol we want.

There is also the possibility Microchip uses unreleased source for the osx version, but I doubt it.

You can also use a hex editor to search for mchp_mafrlcsj in the elf-cc1 file, which would just confirm its in there.

Quote
I actually prefer the specs.txt way,
You did add the -specs=specs.txt global option I assume?
It seems odd that if you do have the global -specs option set, it should either work or get a complaining compiler- there is really no middle ground or silent failure

I tried xc16 again (with original elf-cc1), and I can get the specs file to work, and contrary to what I wrote it does not seem to make a difference if the extra line is there or not for xc16- it was required for xc32 as that needed 2 options where a blank line was required between them.

« Last Edit: January 23, 2018, 06:30:45 am by cv007 »
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #243 on: January 23, 2018, 06:01:58 am »
Thanks for sticking it out :)
I will try with Win 7 tonight. That would still be inconvenient, but workable.
I got my first Mac for writing iOS Apps for iPhone. Got sick of that soon enough,
but I ended up with a strong preference for actually using the Mac, over a Windows PC.

If the Win 7 install works the same, I don’t care then what happens to the Mac install, and can fiddle again.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #244 on: January 23, 2018, 08:00:18 am »
I'm not sure otool options are the same as objdump. There are other utilities to do the job, like nm , maybe osx has nm?
Otool is the Mac tool for that, but macOS executables normally don't include symbol info.

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #245 on: January 23, 2018, 08:38:32 am »
Thanks for clearing that up. I don’t pretend to understand the script other than the for loop.
I’m just a programmer :D

A win installation is better than $29US a month for the free software.
I shouldn’t have even licensed it today. I should have waited to find some bug in my program.


 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #246 on: January 23, 2018, 12:33:18 pm »
I now have MPLAB-X up to date on Both Win 7 and Mac.
There was some problem with Microchip’s page, so I downloaded XC16 v 1.32B from their archive page for the Win & install.

So far the specs.txt method isn’t working. The Build window gives the same messages as the Mac version does,
that I have license restrictions and blah...
I do have cygwin installed in Win 7 too, so I can try the other tomorrow maybe.
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #247 on: January 23, 2018, 01:41:34 pm »
actually the specs.txt method IS working for me, on win 7 win 10 and on osx 10.10

it works with XC16 v1.32 and v1.33, IDE versions 4.00, 4.05 (on windows) and 3.85 (on osx)

i attached the txt file i'm using (if for whatever reason you were generating an incorrect one)
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #248 on: January 23, 2018, 03:13:10 pm »
Well I don’t know what to say  :-//

It would be pointless to mess with the Mac install because it’s authorised now anyway,
but the Win 7 install, I used your specs.txt file, and it looks the same to me.
I have been placing it in the project root directory which is of the format PROJECT.X,
but ended up scattering copies of it in other places as well when it didn’t work.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #249 on: January 23, 2018, 03:44:11 pm »
cygwin didn’t like one of those commands. I think it was xxd.

Can someone pm me the modified file since it’s free open source?
You may have to include the source code of the modified file right?
So can someone not only send it to me, but also take out a front page add in a newspaper that they sent it to me?
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #250 on: January 23, 2018, 04:06:27 pm »
Quote
cygwin didn’t like one of those commands. I think it was xxd.
Those scripts work in Linux, not in Windows (or OSX I guess now we can say). You can't get anything done in Windows at the command line (easily) it seems. To modify the Windows exe would take a little more effort to come up with the location that needs to be changed, then use a hex editor to change.

I just tried xc16 1.32/1.33 on a Windows 10 pc and the specs method works ok. I'm not sure what you are doing wrong :) , but when you do a build, the output of the build should have that specs global option listed somewhere- if it does, then it was happy with the -specs option and could find the specs.txt file (and was happy with its contents), if not anywhere in the output the option is not being used. One or the other.

Maybe create a new simple project, add the specs.txt file, add the -specs=specs.txt global option, set optimization to -Os, and try.
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #251 on: January 23, 2018, 04:32:03 pm »
I don't undertand, is it working or not? if you want i can make you a sample project that works on all of my machines (tell me which pic, i always use dsPIC33Es and i am sure that with those is working.. wonder if it doesn't with other families..)

for the record: this method works, for now. The code compiles but i'm not using it in any project. I find that -O1 (available in free mode) gives to me a good balance between compiled code size, compiler cleverness and ability to properly debug without many headaches. if i really need the highest performance possible (fir or other algorythms that use the DSP) i use assembly anyway
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #252 on: January 23, 2018, 05:14:32 pm »
xc16 v1.32 - Windows version
C:\Program Files\Microchip\xc16\v1.32\bin\bin\elf-cc1.exe
file offset 0x1623AE
change 0x85 to 0x84


xc16 v1.33
C:\Program Files\Microchip\xc16\v1.33\bin\bin\elf-cc1.exe
file offset 0x161E7E
change 0x85 to 0x84
« Last Edit: January 23, 2018, 05:40:26 pm by cv007 »
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #253 on: January 23, 2018, 05:20:55 pm »
I’m not sure of the last question.
My project has different optimisation settings for different source files.
It compiled fine when the trial period was valid, and again now that I purchased a subscription.
For the new Win install, it doesn’t.
For the time between my trial expiring, and purchasing subscription,
it also didn’t compile, and gave the same warnings as the Win 7 install does now,
and I tried the specs.txt file, and other methods in between.

I don’t recall seeing anything different after using the specs.txt file in either case.
In fact, I’d confidently say it’s not any different.

What I was asking, the two files being modified are part of GCC yes?
So why aren’t those two files freely distributable? (So long as their source code is included).
Whether I needed them or not, if it weren’t for the fact that Microchip would fix it,
I’d go straight and post them on their own forum.






 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #254 on: January 23, 2018, 05:23:01 pm »
You must have got that in while I was typing.
Don’t worry about 1.32. Mine is 1.32B anyway. I’ll get 1.33 for Windows when I can,
there was just some error on their page at the time. 
Will try tomorrow! Thanks :)
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #255 on: January 23, 2018, 05:46:23 pm »
I added v1.33 info in previous post. If you can run a hex editor on the file, you will be good to go. A JNE is simply changed to a JE.

I guess I should have created a chart for simply changing the binaries of each version, would probably be easier for everyone. I guess we now have 2 entries.

Quote
My project has different optimisation settings for different source files.
That would explain it then- the global option is not so global when you have individual files using their own settings. It would seem.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #256 on: January 23, 2018, 06:48:21 pm »
Although I don’t understand that language,
the approach was probably smarter.
A constant table would expire with the next version, where your script may not.


 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #257 on: January 23, 2018, 07:20:11 pm »
That was the intent, but things could change anyway. Having more options is good, though.

XC16 for Windows was not too bad to come up with the location to change as they still had the symbol info in the binary. XC32 for Windows is more difficult as there is no symbol info in the exe. You have the original source, can get the section info, disassemble, but it will probably take a little bit of trial and error to pinpoint the global var location. It can be done, though. I assume the same for OSX, it will just require a little more work to modify the binaries without the symbol info.

Maybe I'll make a simple chart for binaries, with file offsets and byte(s) to change.

 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #258 on: January 24, 2018, 12:49:11 pm »
Hi again!

I was able to download the Windows version XC16 v1.33 tonight, and installed that, so the Mac and Win 7 install should compile a project the same.
The value at the offset you quoted was correct, and I changed the 0x85 value to 0x84, but it still doesn’t work.

That’s what I expected to have to tell you really. By this time you’d understand I was holding my breath when building it,
but all is well :) I haven’t actually written to the chip, but there were no complaints, and the memory gauges match the Mac install,
so I’m sure it’s a success... So I owe you a big thank you for your continued replies.

I can live with this. I’d rather use it on Windows than pay what is asked for the Mac install that I’d prefer to use,
but if there’s anything YOU want me to try, I’m prepared to ruin my license (so long as you know how to do that) and play with it.
Cheers :)
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #259 on: January 24, 2018, 03:44:04 pm »
I have added binary info to rev3 of my document. Windows and Linux only, as I don't have access to OSX.

(I should add- I tested on Windows at the command prompt- compiled bare program, ok, added -Os option, license error, changed 3 files, compiled again with -Os, no license error- so I assume its correct)

Without symbols, this is generally the way its done for the Windows versions (but there may be better ways, I'm not an expert)-
Use objdump(mingw) on the exe with the -h option to get the section info,
also use objdump -D to disassemble everything, output to a file (will be quite large)
in the disassem dump, search for "Could not retrieve compiler license (%s)",  the file offset of this is then used to get the address used by the program (via the the -h section info)
search the disassem dump for this address (lowercase hex, no leading 0's), which will get you near the 'mchp_pic32_license_valid' var we want
there will be a couple 'movl 0' close around it, its a 64bit number (why, I don't know) so it will be using consecutive word addresses, the lowest is the one we want (address will also be in .data address range, which section info will show)
now that we have that address, need to work back to file offset also using section info (address - lma-address + section-file-offset)
with file offset found, look it up in hex editor, should be FFFFFFFFFFFFFFFF if we are right
replace with our number, all done (do for the 3 files)

Maybe someone with OSX can do something this also (with otool, I guess). All compilers have different ways of doing things, but I would guess since mac uses intel, its going to be somewhat close to what I described.
« Last Edit: January 25, 2018, 05:14:38 pm by cv007 »
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #260 on: January 24, 2018, 11:42:40 pm »
I’ll be happy with Windows. More that if you’re on a mission, I’ll have to help if I can. I must have been a fanboy. I’m more dissapointed than anything else.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #261 on: January 25, 2018, 01:47:16 am »
If someone has the xc16 elf-cc1 for osx they can upload somewhere, I could probably figure out what byte needs changing
(same for for 3 files for xc32)

An alternative, is to upload to a place like this-
https://onlinedisassembler.com/odaweb/
then create a share link so we can view the disassembly
(I think its free)

I downloaded the osx xc16 dmg from Microchip, I can extract the dmg, but the installer is osx specific so am unable to get any further (I was thinking I could extract the files from the installer, but I now realize the installer they use has their own on-the-fly decompression).
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #262 on: January 25, 2018, 03:38:37 am »
Zipped is 3.9Mb. Too large for the forum. Pm me an email address.
so long as my understanding of the situation is right, I offered to help where I can, just ask ;)
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #263 on: January 25, 2018, 08:48:16 pm »
I have added rev 3.1, xc16 osx binary info- untested, though.

Any osx users can inform me if it works.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #264 on: January 27, 2018, 03:28:07 am »
It’s now tested :)
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #265 on: February 10, 2018, 07:39:36 pm »
XC32 v2.05 added

Revision 4 attached.


Interestingly, they now include build scripts in the source code. There is quite of bit of scripting going on in those scripts, and I didn't try it, but it may now be possible for a mortal man to actually compile with success. Maybe. It is a lot easier to just change a few bytes in a few files, though.
 
The following users thanked this post: Fire Doger

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #266 on: February 10, 2018, 10:12:29 pm »
Haha :) I might as well install it, even though I have no need for XC32 just yet. Future me thanks you again :)
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #267 on: February 14, 2018, 01:26:00 pm »
Also, the first method (manually replacing the SHA256sum in the binary using a hex-editor) still works with xc32 v2.05.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #268 on: February 14, 2018, 05:40:54 pm »
All the 'license' code was unchanged. I suspect the only change in the future would be to get rid of it altogether. Their predicament is how to tell all the paying customers when it happens.

Quote
manually replacing the SHA256sum in the binary using a hex-editor
If you have the hex editor open anyway, just change the 8 bytes of the 'mchp_pic32_license_valid' init value. The advantage is xclm will never run and does not need to be replaced, also no hash calculation computed each time (30 files compiling = 30 hash calculations, 30 open/close of the replacement xclm - probably not a big deal with the minimal xclm replacement, but its something).
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #269 on: February 15, 2018, 11:05:44 am »
All the 'license' code was unchanged. I suspect the only change in the future would be to get rid of it altogether. Their predicament is how to tell all the paying customers when it happens.

Quote
manually replacing the SHA256sum in the binary using a hex-editor
If you have the hex editor open anyway, just change the 8 bytes of the 'mchp_pic32_license_valid' init value. The advantage is xclm will never run and does not need to be replaced, also no hash calculation computed each time (30 files compiling = 30 hash calculations, 30 open/close of the replacement xclm - probably not a big deal with the minimal xclm replacement, but its something).
I wonder if it is possible to force inject a library before the program is started to override the symbol using the dynamic loader? This way as long as the symbol name is unchanged the injected library can be left unchanged. It might be able to be done by replacing the wrapper binary.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #270 on: May 03, 2018, 03:43:21 am »
and after this totally legitimate thread:
http://www.microchip.com/forums/tm.aspx?tree=true&m=1050166&mpage=1

Code: [Select]
Access Denied

You don't have permission to access "http://www.microchip.com/forums/post.aspx?" on this server.
Reference #18.edb7d117.1525318856.1defdb3
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #271 on: May 03, 2018, 04:24:42 am »
That's just the mchp forum server/software- it sometimes does not like links added to messages.

I got the same message when trying to reply (with a url), so I 'hid' my url (split), which then worked. Normally you get that problem when editing a post with a url, but for some reason it didn't like url's in a new post, either.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #272 on: May 03, 2018, 04:32:06 am »
There was no link in my reply.

I was actually going to say that the direct back to here, and some info in the thread was largely related to cracking XC16/32,
rather than the question I actually asked.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #273 on: May 03, 2018, 04:49:42 am »
Quote
There was no link in my reply.
Then its just the flakey mchp forum software. I get the same access denied from time to time.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #274 on: May 03, 2018, 05:43:46 am »
I think they have canned at least two of those methods for XC16 v1.34.
For the hex editing, there are no patterns of bytes resembling those in previous versions.
(the opcodes and data all in a row).
And the specs.txt, admittedly didn’t work for Mac OS, but in Windows, I get the same result.
I haven’t tried doing 1.33 that way in Windows though to verify I got it right.

As said in pm, I’m not too fussed anyway. My own program has been tested with 1.33.
Unless of course, it compiles to fewer words on average! :D

 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #275 on: May 03, 2018, 06:17:08 am »
..., and some info in the thread was largely related to cracking XC16/32, ...

It's important how you formulate it. It's not a crack. Microchip hacked the GCC compiler so that you can't use higher optimizations.
We un-hack it. A crack sounds illegal for a lot of people. It's not illegal, so don't use the word crack.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #276 on: May 03, 2018, 06:54:16 am »
I see where you’re coming from, but since their particular implementation and distribution is legal AFAIK,
so long as they provide sources and scripts to build open source components,
the methods to bypass XC16/32 license checking are cracks for that particular implementation,
and it has already been debated here, without consensus, whether or not that is legal to do, regardless of ethics.

 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #277 on: May 03, 2018, 07:31:18 am »
I see where you’re coming from, but since their particular implementation and distribution is legal AFAIK,
so long as they provide sources and scripts to build open source components,

Yes, it is.

the methods to bypass XC16/32 license checking are cracks for that particular implementation,

No, it's not. It's just a particular implementation of their particular implementation.

and it has already been debated here, without consensus, whether or not that is legal to do, regardless of ethics.

If you have the right to express your opinion and call it crack, then I have the right to express my opinion and say that you are wrong.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #278 on: May 03, 2018, 07:47:26 am »
I’m calling cracking, the bypassing of some software mechanism,
and wasn’t aware it was a matter of opinion:

https://en.m.wikipedia.org/wiki/Software_cracking
 
The following users thanked this post: hans

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #279 on: May 03, 2018, 08:55:36 am »
I’m calling cracking, the bypassing of some software mechanism,
and wasn’t aware it was a matter of opinion:

https://en.m.wikipedia.org/wiki/Software_cracking

According to Wikipedia:

Quote
Software cracking is the modification of software to remove or disable features which are considered undesirable by the person (or company!) cracking the software, ...

That means that Microchip cracked the GCC compiler...! Because they removed or disabled the higher optimization settings.

 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #280 on: May 03, 2018, 09:00:17 am »
It does if you can find any other example of a source code that is commonly referred to as cracked.
Executables are cracked.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #281 on: May 03, 2018, 09:15:59 am »
Executables are cracked.

Only in the context of closed source software.

In the context of open source software, specifically GPL'ed software, executables are patched, not cracked.

An example is the delta-rpm used by Opensuse. When they provide updates, the default is not to use normal rpm but delta-rpm that patches a part of the executable by
overwriting and/or inserting bytes directly into an existing executable (binary) file .

 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #282 on: May 03, 2018, 10:31:46 am »
Karel, the problem with stupidity is that people who are this freaking stupid are too stupid to see their own stupidness. Hence, any attempt to explain the case in a civil or logical manner is utter waste of time.

This exact same discussion has been seen several times on these forums, it's always the same couple of people and the discussion is never fruitful. It's best to just update your ignore list and go on.

It's the same as trying to discuss with anti-vaccinators or anti-abortion. It's political even when it should be factual, so it simply won't ever work out, no matter how much effort you put in trying to be sensible.
 
The following users thanked this post: fourtytwo42

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #283 on: May 03, 2018, 12:56:43 pm »
I didn't know they came out with xc16 v 1.34, I'll take a look and update my info if possible.
They don't provide the source to xc16 v1.34, so not sure what their new plan is- maybe just an oversight.
 

Offline JanJansen

  • Frequent Contributor
  • **
  • Posts: 380
  • Country: nl
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #284 on: May 03, 2018, 01:56:11 pm »
I used Karels method for XC16 & XC32, only not working for XC8.

I read there is another method also, and i read it also dont works anymore ?
If there is still another method, does it work also for XC8 ?, and does Karels method still works with new versions ?
Problem is i want the XC8 also.

Maybe they better release a full version for non commercial use, companys will pay, just like microsoft visual studio ?, as it looks now companys dont have to pay by law, i guess they can make more money, i bet they read this topic also, especially the word money.
Then we dont have to hack unlock to get some more power out of these chips, and we saving energy alltogether to save the world, dont run slow code.
« Last Edit: May 03, 2018, 01:59:34 pm by JanJansen »
aliexpress parachute
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #285 on: May 03, 2018, 03:54:38 pm »
I used Karels method for XC16 & XC32, only not working for XC8.

XC8 is a completely different compiler. It's not GCC and it's not open source. You are not allowed to modify it.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #286 on: May 03, 2018, 04:04:14 pm »
I added xc16 v1.34 info (binary mod for Linux only at the moment)
https://github.com/cv007/XC3216

Even though they do not provide the source, it appears nothing really changed, the specs method still works and finding the binary mod was the same as before.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #287 on: May 06, 2018, 09:36:25 am »
@cv007, you have a field for Mac OS that’s empty for v1.34, I assume you still don’t know. It’s 0x64D8E7.
I probably had it first go, but Hex Workshop saves the file original unless I “Save As” and write a new file.

With regard to the former,
It’s just semantics, and nothing that can be liked to opinions on anti-vac or anti-abortion (now THAT is stupid to even liken to a mere semantic topic).

Of course binaries can be patched. I said binaries are cracked, meaning only binaries are cracked.
Now I challenge you to go find any widely accepted reference to a source code that has been “cracked”, because that’s not what you have done.
XC16 is a commercial distribution, with a deliberate mechanism in place to restrict access to certain features. To bypass that mechanism without
access to it’s complete source code, and rebuilding it is called a crack. If you have the source code and a means to build it, there’s nothing to crack.

 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #288 on: May 06, 2018, 02:09:36 pm »
XC16 is a commercial distribution, ...

So what? Its' completely fine to commercially sell GPL software.
But they cannot take away the GPL license that says the enduser is always free to modify it.

Check the file /opt/microchip/xc32/v2.05/docs/MPLAB_XC32_Compiler_License.txt:

Quote
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.

So, the restrictions of the license does NOT apply to the XC32 and XC16 compilers. You are free to select (switch-on) whatever optimization you like. Also by patching the binary.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #289 on: May 06, 2018, 08:41:35 pm »
Quote
Also by patching the binary.
Hmm.  Is there an open-source license that specifically dis-allows "patching the binary"?
As in "my for-profit service is to sell pre-compiled binaries of (complicated) source-tree at various cost/performance levels, and while you are welcome to figure out the process to build from source any version you want, you MAY NOT patch one of my simplistically-protected low-cost binaries to become the same as the high-cost binary."
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #290 on: May 07, 2018, 08:58:29 am »
... , you MAY NOT patch one of my simplistically-protected low-cost binaries to become the same as the high-cost binary."

That depends. Does your software contains GPL'ed software?
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #291 on: May 08, 2018, 11:09:05 pm »
Quote
Quote
you MAY NOT patch the binary
That depends. Does your software contains GPL'ed software?
Assume not, for simplicities sake.  Just "does such a license exist", not "how does in interact with everything else."

Alternately, assume that it links in LGPL 2.x or "GPL3 with linking exception" libraries like libgcc...
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #292 on: May 09, 2018, 02:13:04 am »
Quote
Is there an open-source license
I think if you lookup the 'open-source' definition (I guess by those who claim to define it), I don't think you could come up with any license that would meet that definition and also restrict you from making changes (binary or otherwise). You can take open-source code such as bsd licensed code, put it in your own code, come up with any license (restrictions) you want- but then it no longer qualifies as open-source at that point.

Since gcc is gpl (and you cannot do as above with bsd code), we don't have to get too twisted up thinking about various possible scenarios that could be/could have been.
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1051
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #293 on: May 09, 2018, 04:13:56 am »
For the record, I wasn’t talking about what’s right or wrong, or what’s legal or illegal. Just a semantic.

Nevertheless, I’ll no longer have to worry about it.
I don’t think it’s even prudent to have been stuck into the same company microcontrollers for a decade or so
without trying something else.
(Regardless of whether or not I think they are shitting on GPL and their customers).

Next I’m trying a TI controller.
Admittedly not nearly as forthcoming with samples as Microchip are.


 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #294 on: May 09, 2018, 05:14:39 am »
Good luck, everytime i do that i fail to see what the big fuss is and fall back to using a pic18, dspic or pic32. Unless there is a completely different peripheral or a particular requirement i like to stick with the devil i know best..
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #295 on: May 09, 2018, 06:36:32 am »
Quote
Quote
you MAY NOT patch the binary
That depends. Does your software contains GPL'ed software?
Assume not, for simplicities sake.

In that case I don't know. What I do know is that XC16 and XC32 use the GCC compiler which uses the GPL v3.1 license.
And binaries made of GPL'ed software may be patched. Nobody can forbid that.
 

Offline imk

  • Regular Contributor
  • *
  • Posts: 183
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #296 on: May 10, 2018, 04:22:53 pm »
Must say 1st time i used mplab x i was not keen, but is growing on me.
not done a big project in it yet just little applets so early days
1201 Alarm
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #297 on: May 10, 2018, 06:05:34 pm »
Quote
Quote
you MAY NOT patch the binary
That depends. Does your software contains GPL'ed software?
Assume not, for simplicities sake.

In that case I don't know. What I do know is that XC16 and XC32 use the GCC compiler which uses the GPL v3.1 license.
And binaries made of GPL'ed software may be patched. Nobody can forbid that.

I guess you're right in principle. And the way GCC is built, there is now way Microchip could claim having isolated their contributions enough not to make the whole resulting compilers GPL. It's just impossible. So you should be able to do pretty much as you like with the compiler itself.

What they can protect though and not make GPL is all their support files for their microcontrollers (headers, libraries...) that they can't help but distribute freely. But those are the files that they should protect actually. It's just that it would be very unpractical to do so, so they protect the binaries instead, which is much easier (but not all that effective obviously).

On a legal point of view, I think you should be free to use XC16/32 as you see fit without any restriction, but I'm not sure you'd be authorized to use Microchip's support files. And without those, frankly, you wouldn't be able to do much. You could always rewrite them as long as it's obvious that they are substantially different from the original, but that sounds like a lot of work. (AFAIK, this is what the MinGW team has done for the Windows SDK headers and import libraries?. A lot of work.)

Anyway, according to the GPL, you should be free to redistribute the binaries themselves (even Microchip ones) as long as you distribute the source code along with them. Patching them is a different story - I don't know how that would be considered exactly on a legal standpoint. This would be a modification of the binaries that would make them not match the source code anymore, thus breaching the GPL somewhat. OTOH, circumventing artificial limitations in GPL software may not be considered as a modification at all. I guess the end of the story will only be known once a court settles a case like this.

I'd tend to doubt Microchip would take this to court though - they probably are borderline with the GPL so they may not want to risk losing a lot in court.
 

Offline Vasi

  • Regular Contributor
  • *
  • Posts: 60
  • Country: ro
    • Visual Pin Configurator for Nucleo L152RE - produces SPL code.
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #298 on: May 21, 2018, 04:04:29 am »
...
I just wish they’d invest their efforts in making a fluid UI rather than fannying around with bug infested code generators. I started using Atmel Studio a year or so ago for a couple of projects, it’s just so much slicker, I even thought the debugger wasn’t working, it’s so quick to program. I’m afraid that won’t please the non-Windows folk.

If you are able to generate a Makefile for your project, then using the cross platform Visual Studio Code can be as pleasing to use by the non-Windows folk.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #299 on: June 19, 2018, 11:12:04 pm »
Since there was a reminder that a new version of mplabx was out and xc32 increased recently to v2.10, I thought I would check them out (I'm on Linux fyi). I checked out the new xc32 v2.10 and although the byte offset location remains exactly the same (for the binary mod), it does not work.  The source is not available (yet), but at a quick glance it appears from an objdump it is similar to the previous versions- but they must be doing something different, or I am making some mistake. It is odd that the byte offsets of interest are exactly the same on all 3 files as v2.05- not sure how that happens with different code. I guess when the source becomes available I can check it out, although not terribly important.

While checking it out I discovered that gcc is looking for a specs file all over the place, so decided to simplify. I had previously assumed a -specs global option was required for the specs file, and therefore a global option had to be added to the project (every project). It now seems it is much simpler than that- just create a 1 (xc16) or 3 (xc32) line specs file and place it in a specific folder (there are many to choose from, I just picked one of them). All done.

My latest xc32/16 info-
https://raw.githubusercontent.com/cv007/XC3216/master/xc32xc16-info-rev6.txt

I tested with xc32 ver 1.44,2.05,2.10, xc16 ver 1.33,1.34 -  but have not tested with Windows, but there is no reason it should not work the same.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #300 on: June 20, 2018, 06:55:35 pm »
Quote
It is odd that the byte offsets of interest are exactly the same on all 3 files as v2.05- not sure how that happens with different code. I guess when the source becomes available I can check it out, although not terribly important.
Actually the source is available (via simple deduction), they just don't show it on the the web page (yet). XC32 v2.10 looks like it basically just removed all C++ license references and now just uses PRO (2). So the 6 (Full C++) becomes a 2 (PRO). Which is why I was failing. I should have noticed when I was viewing the objdump, as I saw that 2 being used (for the mafrlcsj test) but glanced over it as I thought 2 was referring to some form of the free version. I guess they now think c++ is mainstream and no longer special :)

Anyway, just use the simple way as my previous post suggests. The binary mod should be faster as it skips checking with xclm, but its hardly worth the trouble for most people (maybe for projects with many many files to compile, but it still probably only adds time measured in ms).
 

Offline peterson

  • Newbie
  • Posts: 1
  • Country: jp
    • skysmotor
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #301 on: June 21, 2018, 10:10:23 am »
While I too applaud Microchip for maintaining a substantial selection of DIP parts, nowadays you are seriously restricting your options.

I’m not sure of the rationale regarding having to be through hole? If it’s for a kit for end user assembly I guess I can understand. If it’s for solderless breadboarding, you can use breakout boards which would dramatically increase the options available to you.
Japan stepper motor site:skysmotor.com
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #302 on: June 21, 2018, 03:40:28 pm »
Here's the download link to the source of the new compiler:

http://ww1.microchip.com/downloads/en/DeviceDoc/xc32-v2.10-src.zip

I can confirm that the "old" method still works when you change the return value from 6 to 2 as described here:

https://www.eevblog.com/forum/microcontrollers/pic32-evolution/msg1621915/#msg1621915

Here's the content of an header file: XC32 source v2.10/xc32-v2.10-src/pic32c-gcc-binutils/pic32c-source/XC32-arm-gcc/gcc/gcc/config/mchp-cci/xclm_public.h

Code: [Select]
/* General XCLM return values */
#define MCHP_XCLM_NORMAL_EXIT            0x0

/* Original options used for C translation units */
#define MCHP_XCLM_FREE_LICENSE           0x0
#define MCHP_XCLM_VALID_STANDARD_LICENSE 0x1
#define MCHP_XCLM_VALID_PRO_LICENSE      0x2

#define MCHP_XCLM_DONOTUSE               0x3

/* New options used for C++ translation units */
#define MCHP_XCLM_NO_CPP_LICENSE         0x4
#define MCHP_XCLM_VALID_CPP_FREE         0x5
#define MCHP_XCLM_VALID_CPP_FULL         0x6

/* diagnose problems */
#define MCHP_XCLM_OPTION_ERROR 0x10 /* something bad in supplied options - refer to stderr for details */
#define MCHP_XCLM_INTERNAL_ERROR 0x11 /* internal error - memory, filesystem, network, ? */
#define MCHP_XCLM_LICENSE_ERROR 0x12 /* no license available, or license expired */


/* -liccheck */
#define MCHP_XCLM_NO_VALID_LICENSE 0x1
#define MCHP_XCLM_SUBSCRIP_RENEWED 0x2
#define MCHP_XCLM_LICENSE_EXPIRED 0x3
#define MCHP_XCLM_LICENSE_RENEWED 0x4
#define MCHP_XCLM_DONGLE_LICENSE 0x5
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #303 on: July 22, 2018, 06:46:21 pm »
cv007: xc32 v2.10, looks like there may be a couple of errors in the cc1/cc1plus Windows offsets in https://raw.githubusercontent.com/cv007/XC3216/master/xc32xc16-info-rev5.txt

May I suggest:

xc32 version 2.10 | - notice now uses 2 instead of 6
----------------------------------------------------------------------Windows--
 Dir: C:\Program Files\Microchip\xc32\v2.10\bin\bin\gcc\pic32mx\4.8.3\
File: cc1plus   Offset: 0x774510  Change: FFFFFFFFFFFFFFFF to 0200000000000000
File: cc1       Offset: 0x6c3410  Change: FFFFFFFFFFFFFFFF to 0200000000000000

Furthermore, for XC16 v1.35, things seemed to have changed in this regard. I've found where the relevant code appears to be (Windows at offset 0x16220C). The jump is now a short jump, and of the opposite sense. I switched it around (0x74 -> 0x75) but it doesn't open the optimisations up.

 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #304 on: July 22, 2018, 06:50:03 pm »
While I too applaud Microchip for maintaining a substantial selection of DIP parts, nowadays you are seriously restricting your options.

I’m not sure of the rationale regarding having to be through hole? If it’s for a kit for end user assembly I guess I can understand. If it’s for solderless breadboarding, you can use breakout boards which would dramatically increase the options available to you.

Many of us do exactly that, pretty much on almost a daily basis in my case!
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #305 on: July 22, 2018, 07:03:36 pm »
While I too applaud Microchip for maintaining a substantial selection of DIP parts, nowadays you are seriously restricting your options.

I’m not sure of the rationale regarding having to be through hole? If it’s for a kit for end user assembly I guess I can understand. If it’s for solderless breadboarding, you can use breakout boards which would dramatically increase the options available to you.

Many of us do exactly that, pretty much on almost a daily basis in my case!

I like DIP parts. Very easy to connect, very easy to probe. I don't need any more soldering in my life.

And when you need it, you can get the exact same part in QFN. Perfect.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #306 on: July 23, 2018, 01:05:07 am »
Quote
May I suggest:
I corrected the Windows numbers for xc32 2.10, added xc16 1.35 info.

Quote
for XC16 v1.35, things seemed to have changed in this regard
Same as before, v1.35 offset is 0x161FEB. Tested.

I would suggest using-
https://github.com/cv007/XC3216/blob/master/xc32xc16-info-rev6.txt
one simple file, when a new version rolls out, simply copy the file to the new version folder. Works for xc16 and xc32, every os.

I may take down the old method, as they seem to update the compilers more often and I really don't want to update the info for every new version when a simple method works just fine. I'm not sure more than a handful of people even use the info anyway.
 
The following users thanked this post: rachaelp

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #307 on: July 23, 2018, 08:08:11 am »

I may take down the old method, as they seem to update the compilers more often and I really don't want to update the info for every new version when a simple method works just fine. I'm not sure more than a handful of people even use the info anyway.

I may well have misunderstood, but with the new method, switching between optimised and not optimised requires you to add or remove spec files. I quite often switch between optimised and non optimised particularly while debugging, and it's not uncommon to switch off optimisation at an individual source file level. How well does the new method work with this?
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #308 on: July 23, 2018, 01:19:02 pm »
Quote
switching between optimised and not optimised requires you to add or remove spec files
Read the file I posted. Its too simple, I guess. Just create a file, put it in a folder, done. You have no restrictions. Change optimizations as wanted.
 
The following users thanked this post: Howardlong

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #309 on: July 23, 2018, 07:33:33 pm »
Quote
switching between optimised and not optimised requires you to add or remove spec files
Read the file I posted. Its too simple, I guess. Just create a file, put it in a folder, done. You have no restrictions. Change optimizations as wanted.

OK, I had misunderstood, the way I thought it worked was as a global "always on". It does indeed seem to just work with that file.

Regarding the XC16 location, I'm not sure how I managed to get fixated on the wrong part a few bytes down, anyway, no need for it now!
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #310 on: October 03, 2020, 04:01:04 pm »
Quote
May I suggest:
I corrected the Windows numbers for xc32 2.10, added xc16 1.35 info.

Quote
for XC16 v1.35, things seemed to have changed in this regard
Same as before, v1.35 offset is 0x161FEB. Tested.

I would suggest using-
https://github.com/cv007/XC3216/blob/master/xc32xc16-info-rev6.txt
one simple file, when a new version rolls out, simply copy the file to the new version folder. Works for xc16 and xc32, every os.

I may take down the old method, as they seem to update the compilers more often and I really don't want to update the info for every new version when a simple method works just fine. I'm not sure more than a handful of people even use the info anyway.

Aplogies for necroposting, now that XC32 includes ARM, the above seems to break the ARM compilation. If I remove the specs file, I can compile ARM targets.

Code: [Select]
cc1.exe: error: target CPU does not support ARM mode
c:\program files\microchip\xc32\v2.41\bin\bin\..\..\lib\gcc\pic32c\6.2.1\..\..\..\..\bin\bin/pic32c-ld.exe: cannot open linker script file ATSAMC21N18A.ld.00003098.00: No such file or directory
collect2.exe: error: ld returned 255 exit status

Are there any GCC aficionados out there who can explain this specs file to a GCC noob so I can figure this out? I've looked at the docs but I'm none the wiser to be honest.

Code: [Select]
*cc1:+ -mafrlcsj
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #311 on: October 03, 2020, 04:04:55 pm »
Have you tried adding the argument -mthumb? It tells the compiler to generate 16-bit thumb instructions instead of 32-bit ARM instructions.

IME older GCC versions does not default to generating thumb instructions for Cortex-m0, which does not support any 32-bit ARM instructions.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #312 on: October 03, 2020, 06:01:36 pm »
It appears you can rename (or remove) the specs file so it no longer gets used, and simply add the -mafrlcsj option to the project Global options/Additional options. They appear to no longer try to 'block' the use of -mafrlcsj when they move you from the bin executable to the bin/bin executable like they did previously (before adding in arm compiler). The specs file was a way to bypass the removal of the option by adding the option after they were done looking for it. A specs file could probably still be used instead of adding the option to each project, but not sure how at the moment as it appears the mips side is happy with the cc1 addition but the arm side is not (and the specs file could be moved to a more compiler specific folder so the mips version could be different than the arm version).

I hardly touch the pic32mm anymore, and for the samd10 I have I added the arm gcc compiler (downloaded from arm) as another toolchain option, but then requires some extra work to get it to work (replacing xc.h to the mcu specific include, or something). I would tend to want the arm supplied version of the gcc compiler as its a newer version and is used by everyone else, but I'm sure there can be good reasons to stick to the xc32 version.



« Last Edit: October 03, 2020, 06:46:48 pm by cv007 »
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #313 on: October 03, 2020, 07:06:54 pm »
It appears you can rename (or remove) the specs file so it no longer gets used, and simply add the -mafrlcsj option to the project Global options/Additional options. They appear to no longer try to 'block' the use of -mafrlcsj when they move you from the bin executable to the bin/bin executable like they did previously (before adding in arm compiler). The specs file was a way to bypass the removal of the option by adding the option after they were done looking for it. A specs file could probably still be used instead of adding the option to each project, but not sure how at the moment as it appears the mips side is happy with the cc1 addition but the arm side is not (and the specs file could be moved to a more compiler specific folder so the mips version could be different than the arm version).

I hardly touch the pic32mm anymore, and for the samd10 I have I added the arm gcc compiler (downloaded from arm) as another toolchain option, but then requires some extra work to get it to work (replacing xc.h to the mcu specific include, or something). I would tend to want the arm supplied version of the gcc compiler as its a newer version and is used by everyone else, but I'm sure there can be good reasons to stick to the xc32 version.

Yes, thanks. Coincidentally I just figured out that I could move it to the project specific options rather than in the specs file.

What threw me was the option itself, particularly not being a GCC guru other than as a dumb user for many years, I couldn't find its purpose explicitly documented anywhere, so I was thinking there was some clever shenanigans going on with a combination of flags somehow. Presumably it's simply an undocumented option outside of Microchip.
« Last Edit: October 03, 2020, 09:21:51 pm by Howardlong »
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: MPLAB X a PIC inhibitor! Alternatives ?
« Reply #314 on: October 03, 2020, 08:37:43 pm »
> Presumably it's simply an undocumented option outside of Microchip

Its an undocumented 'inside' option, and in the source code- mchp.opt (and used in mchp.c). Looks to me like someone at mchp wanted easy access to 'pro' without all the hoops everyone else has to go through (they don't like their own cooking). With a little imagination, its not hard to figure out what the option is saying, and who most likely created it (although there a two j's to choose from).
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf