MPLAB X a PIC inhibitor! Alternatives ? - Page 1
Forum section: electronics / general

author: fourtytwo42
author_rank: Super Contributor
timestamp: November 03, 2017, 07:17:48 pm
content: 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) ?

author: eugenenine
author_rank: Frequent Contributor
timestamp: November 03, 2017, 07:38:53 pm
content: My laptop is at least 5 years old and I don't find it slow. But there are other tool chains such as sdcc.

author: gocemk
author_rank: Regular Contributor
timestamp: November 03, 2017, 07:41:17 pm
content: 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] 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.

author: fourtytwo42
author_rank: Super Contributor
timestamp: November 03, 2017, 07:54:11 pm
content: Quote from: eugenenine on November 03, 2017, 07:38:53 pmI 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!

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 03, 2017, 07:58:43 pm
content: Which DsPIC33s are you looking at?

author: fourtytwo42
author_rank: Super Contributor
timestamp: November 03, 2017, 08:01:23 pm
content: Quote from: gocemk on November 03, 2017, 07:41:17 pmThat's why I am thinking something ARM based would be far better insofar as toolchains are concerned and capable of doing the job.

author: fourtytwo42
author_rank: Super Contributor
timestamp: November 03, 2017, 08:04:12 pm
content: Quote from: Bruce Abbott on November 03, 2017, 07:58:43 pmThings like dsPIC33EV32GM102 to get a 16 bit SPI to run external dacs as well as a good selection of analogue peripherals.

author: JPortici
author_rank: Super Contributor
timestamp: November 04, 2017, 07:06:30 am
content: 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 usersMaybe 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 oneIn 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

author: Karel
author_rank: Super Contributor
timestamp: November 04, 2017, 08:15:09 am
content: Quote from: fourtytwo42 on November 03, 2017, 07:17:48 pmNo 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 elseon this forum. Nice side effect is that you will be able to use higher optimization settings.

author: mrpackethead
author_rank: Super Contributor
timestamp: November 04, 2017, 08:31:51 am
content: I use MPLABx 4.05 every day on windows and mac, and it works just fine for us.

author: Howardlong
author_rank: Super Contributor
timestamp: November 04, 2017, 08:45:15 am
content: 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.

author: hans
author_rank: Super Contributor
timestamp: November 04, 2017, 09:59:13 am
content: 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.

author: fourtytwo42
author_rank: Super Contributor
timestamp: November 04, 2017, 10:16:04 am
content: 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 interestedDevice/series MPLAB 16b SPI SrcPincl/moq 3/5V MIPS ADCb/ssec Cmp/Oa Prog/ramK PinsPIC24F16KA102 Y Y FNK270/1 3 16 10/0.5M 2cmp 16/1.5 28PIC24FJ32GA002 Y Y FNL296/1 3 16 10/0.5M 2cmp 32/8 28PIC24HJ32GP202 Y Y FNL365/1 3 40 10/12/1M/0.5M 0 32/2 28dsPIC33FJ32GP302 Y Y RS448/1 3 40 10/12/1M/0.5M 2cmp 32/4 28PIC24HJ32GP302 Y Y FNL501/1 3 40 10/12/1M/0.5M 2cmp 32/4 28PIC24HJ64GP502 Y Y FNL527/1 3 40 10/12/1M/0.5M 2cmp 64/8 28PIC24HJ128GP502 Y Y FNL576/1 3 40 10/12/1M/0.5M 2cmp 128/8 28Note RS = Radiospares and FNL = Farnell, I dont bother with high moq parts.

author: Ash
author_rank: Regular Contributor
timestamp: November 04, 2017, 11:00:42 am
content: 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 ETLCPPhttp://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).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 comfortableIf 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.

author: Howardlong
author_rank: Super Contributor
timestamp: November 04, 2017, 12:10:11 pm
content: What speed 10-bit DAC are you after, and how many channels?

author: bookaboo
author_rank: Frequent Contributor
timestamp: November 04, 2017, 01:15:07 pm
content: Something to mitigate the compile cycle courtesy of Mike:https://youtu.be/jXVWk-7OFvY?t=16m45s

author: jpanhalt
author_rank: Super Contributor
timestamp: November 04, 2017, 01:50:57 pm
content: 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

author: fourtytwo42
author_rank: Super Contributor
timestamp: November 04, 2017, 04:29:16 pm
content: Quote from: Howardlong on November 04, 2017, 12:10:11 pmOnly 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!

author: westfw
author_rank: Super Contributor
timestamp: November 05, 2017, 07:21:43 am
content: QuoteHmm. 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 05, 2017, 08:00:01 am
content: 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 directoriesWhen 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

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 05, 2017, 08:08:51 am
content: Quote from: jpanhalt on November 04, 2017, 01:50:57 pmIt'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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 05, 2017, 08:11:31 am
content: 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.

author: FrankBuss
author_rank: Unknown
timestamp: November 05, 2017, 08:15:09 am
content: Quote from: Howardlong on November 04, 2017, 08:45:15 amI 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.

author: Ian.M
author_rank: Super Contributor
timestamp: November 05, 2017, 08:20:09 am
content: 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.

author: Karel
author_rank: Super Contributor
timestamp: November 05, 2017, 08:49:32 am
content: Quote from: FrankBuss on November 05, 2017, 08:15:09 amI use MPLABX on Linux a lot for PIC32 development using an ICD3. I never experienced that. But I never use the debugger.

author: fourtytwo42
author_rank: Super Contributor
timestamp: November 05, 2017, 10:31:41 am
content: 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!!

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 05, 2017, 11:25:03 am
content: Quote from: fourtytwo42 on November 05, 2017, 10:31:41 amUpgrading to an SSD is a no-brainer these days.MPLABX runs fine on my Lenovo X220

author: Howardlong
author_rank: Super Contributor
timestamp: November 05, 2017, 11:53:16 am
content: Quote from: Ian.M on November 05, 2017, 08:20:09 amThis 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.

author: Ian.M
author_rank: Super Contributor
timestamp: November 05, 2017, 12:10:03 pm
content: 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.

author: TomS_
author_rank: Frequent Contributor
timestamp: November 05, 2017, 12:39:09 pm
content: Quote from: fourtytwo42 on November 05, 2017, 10:31:41 amYou 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...

author: eugenenine
author_rank: Frequent Contributor
timestamp: November 05, 2017, 05:07:47 pm
content: 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.

author: fourtytwo42
author_rank: Super Contributor
timestamp: November 05, 2017, 09:23:10 pm
content: 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).

author: eugenenine
author_rank: Frequent Contributor
timestamp: November 05, 2017, 10:11:09 pm
content: 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.

author: Howardlong
author_rank: Super Contributor
timestamp: November 06, 2017, 12:00:31 am
content: 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.

author: fourtytwo42
author_rank: Super Contributor
timestamp: November 06, 2017, 09:32:59 am
content: Quote from: eugenenine on November 05, 2017, 10:11:09 pmI 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.

author: fourtytwo42
author_rank: Super Contributor
timestamp: November 06, 2017, 09:36:34 am
content: Quote from: Howardlong on November 06, 2017, 12:00:31 amIts 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.

author: ebclr
author_rank: Super Contributor
timestamp: November 06, 2017, 10:07:28 am
content: https://shop.mikroe.com/compilers/compilers-picOr move to ARM and get's a big list to chose

author: Ian.M
author_rank: Super Contributor
timestamp: November 06, 2017, 12:59:39 pm
content: 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

author: ebclr
author_rank: Super Contributor
timestamp: November 06, 2017, 01:32:40 pm
content: " 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

author: ebclr
author_rank: Super Contributor
timestamp: November 06, 2017, 01:34:13 pm
content: I like MikroElektronika because Pascal can be used, and I really like Pascal

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 06, 2017, 01:43:49 pm
content: Quote from: ebclr on November 06, 2017, 01:32:40 pmThat'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

author: Karel
author_rank: Super Contributor
timestamp: November 06, 2017, 01:50:02 pm
content: Quote from: mikeselectricstuff on November 06, 2017, 01:43:49 pmXC16 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...

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 06, 2017, 08:45:23 pm
content: Quote from: ebclr on November 06, 2017, 01:32:40 pmNot exactly true. It's just that with no optimization XC8 doesn't take the trashoutof 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:_main:movlw7movwf25;volatilebsf3,5;RP0=1, select bank1clrf5;volatileclrf7;volatilel492:bcf3,5;RP0=0, select bank0bcf5,1;volatilebsf5,1;volatilegotol492__end_of_main:Code:_main:movlw7bcf3,5;RP0=0, select bank0movwf25;volatilebsf3,5;RP0=1, select bank1clrf5;volatileclrf7;volatilel492:bcf3,5;RP0=0, select bank0bcf5,1;volatilebsf5,1;volatilegotol492__end_of_main:Now compare that to similar code for the ATmega328, compiled with avr-gcc in Os and O0 modes:-Code:/* blinky.c */#include <avr/io.h>int main(void){DDRB=0xFF;PORTB=0x00;while(1){PORTB|=0x1;PORTB&=~0x01;}}Code:80:8f efldir24, 0xFF; 25582:84 b9out0x04, r24; 484:15 b8out0x05, r1; 586:28 9asbi0x05, 0; 588:28 98cbi0x05, 0; 58a:fd cfrjmp.-6; 0x86 <main+0x6>8c:f8 94cli8e:ff cfrjmp.-2; 0x8e <__stop_program>Code:80:df 93pushr2982:cf 93pushr2884:cd b7inr28, 0x3d; 6186:de b7inr29, 0x3e; 6288:e4 e2ldir30, 0x24; 368a:f0 e0ldir31, 0x00; 08c:8f efldir24, 0xFF; 2558e:80 83stZ, r2490:e5 e2ldir30, 0x25; 3792:f0 e0ldir31, 0x00; 094:10 82stZ, r196:a5 e2ldir26, 0x25; 3798:b0 e0ldir27, 0x00; 09a:e5 e2ldir30, 0x25; 379c:f0 e0ldir31, 0x00; 09e:80 81ldr24, Za0:81 60orir24, 0x01; 1a2:8c 93stX, r24a4:a5 e2ldir26, 0x25; 37a6:b0 e0ldir27, 0x00; 0a8:e5 e2ldir30, 0x25; 37aa:f0 e0ldir31, 0x00; 0ac:80 81ldr24, Zae:8e 7fandir24, 0xFE; 254b0:8c 93stX, r24b2:f1 cfrjmp.-30; 0x96 <main+0x16>b4:f8 94clib6:ff cfrjmp.-2; 0xb6 <__stop_program>

author: Howardlong
author_rank: Super Contributor
timestamp: November 06, 2017, 09:09:06 pm
content: Quote from: fourtytwo42 on November 06, 2017, 09:36:34 amIf it helps, I come from the same school.An option I now use frequently for SMD are Busboard SMT protoboardshttp://www.busboard.com/surfacemountpcbswhich 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 07, 2017, 02:17:54 am
content: Quote from: Howardlong on November 06, 2017, 09:09:06 pmI 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.

author: westfw
author_rank: Super Contributor
timestamp: November 07, 2017, 05:55:15 am
content: QuoteThat 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.

author: Howardlong
author_rank: Super Contributor
timestamp: November 07, 2017, 11:39:41 am
content: Quote from: NorthGuy on November 07, 2017, 02:17:54 amMost 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 ) 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.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 07, 2017, 04:32:16 pm
content: Quote from: westfw on November 07, 2017, 05:55:15 amYou are right! (note: the PIC code was correct, I blame my keyboard!). When corrected the unoptimized avr code is even more bloated...QuoteAnd 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 07, 2017, 05:29:33 pm
content: Quote from: Bruce Abbott on November 07, 2017, 04:32:16 pmI 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.

author: thm_w
author_rank: Super Contributor
timestamp: November 07, 2017, 09:51:48 pm
content: Quote from: fourtytwo42 on November 05, 2017, 10:31:41 amCPU 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".

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 08, 2017, 07:22:38 am
content: Quote from: thm_w on November 07, 2017, 09:51:48 pmMPlabXisbloatware, 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 whatIwant 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 -everythingseems 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!

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 08, 2017, 07:49:44 am
content: Quote from: Bruce Abbott on November 08, 2017, 07:22:38 amYou 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

author: fourtytwo42
author_rank: Super Contributor
timestamp: November 08, 2017, 05:13:29 pm
content: Quote from: mikeselectricstuff on November 08, 2017, 07:49:44 amPersonally 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.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 08, 2017, 05:55:33 pm
content: Quote from: mikeselectricstuff on November 08, 2017, 07:49:44 amYou 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 beingableto 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 stuffinstantly, not be hobbled by bloatware.QuoteThat '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.

author: JPortici
author_rank: Super Contributor
timestamp: November 08, 2017, 06:29:24 pm
content: 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.)

author: Karel
author_rank: Super Contributor
timestamp: November 08, 2017, 08:14:44 pm
content: Quote from: JPortici on November 08, 2017, 06:29:24 pmTwo 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...

author: thm_w
author_rank: Super Contributor
timestamp: November 08, 2017, 08:16:00 pm
content: Quote from: Bruce Abbott on November 08, 2017, 07:22:38 amI 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.QuoteI 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.

author: Fire Doger
author_rank: Regular Contributor
timestamp: November 08, 2017, 08:31:49 pm
content: 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...

author: NorthGuy
author_rank: Super Contributor
timestamp: November 08, 2017, 09:15:05 pm
content: Quote from: thm_w on November 08, 2017, 08:16:00 pmWhy? 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 ontheseprocessors? Are you implying that we must accept the software horrors without complaining?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 08, 2017, 09:49:36 pm
content: Quote from: NorthGuy on November 08, 2017, 09:15:05 pmIt'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.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 08, 2017, 10:36:04 pm
content: Quote from: mikeselectricstuff on November 08, 2017, 09:49:36 pmI 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 ...

author: KL27x
author_rank: Super Contributor
timestamp: November 08, 2017, 10:54:52 pm
content: 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.

author: thm_w
author_rank: Super Contributor
timestamp: November 08, 2017, 11:01:43 pm
content: Quote from: KL27x on November 08, 2017, 10:54:52 pm4GB ram is a little low, yes, can't say if it would make a difference for mplab though. Do you have an SSD?

author: KL27x
author_rank: Super Contributor
timestamp: November 08, 2017, 11:04:40 pm
content: 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.

author: thm_w
author_rank: Super Contributor
timestamp: November 08, 2017, 11:13:16 pm
content: Quote from: KL27x on November 08, 2017, 11:04:40 pmSamsung 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.).

author: KL27x
author_rank: Super Contributor
timestamp: November 08, 2017, 11:33:35 pm
content: It also seems like icore 7 vs 5 is a big difference, per some of the responses. Maybe more effect than an SSD.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 09, 2017, 12:01:54 am
content: Quote from: KL27x on November 08, 2017, 11:33:35 pmDepends 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.

author: mrpackethead
author_rank: Super Contributor
timestamp: November 09, 2017, 12:19:20 am
content: 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.

author: cv007
author_rank: Frequent Contributor
timestamp: November 09, 2017, 03:27:50 am
content: QuoteThere are options under tools-options-appearance-document tabs- you can have tab colors, parent folder name in tab, etc.

author: FrankBuss
author_rank: Unknown
timestamp: November 09, 2017, 04:54:15 am
content: 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).

author: jaromir
author_rank: Unknown
timestamp: November 09, 2017, 08:42:41 am
content: 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 start2) Tiny 11,6" notebook with some old dual core celeron, 4G RAM, SSD, Linux Mint 18 - 21s to start3) Computer at work - intel i7 2630QM, 8G RAM, SSD, Windows 7 - 15s to startNotice 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 thehorrible quarter of minute startuptime once per week.

author: Karel
author_rank: Super Contributor
timestamp: November 09, 2017, 09:59:28 am
content: 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...

author: technix
author_rank: Super Contributor
timestamp: November 09, 2017, 06:37:59 pm
content: Quote from: Karel on November 04, 2017, 08:15:09 amNot 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.

author: technix
author_rank: Super Contributor
timestamp: November 09, 2017, 06:45:47 pm
content: 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: November 09, 2017, 06:50:49 pm
content: Quote from: fourtytwo42 on November 05, 2017, 10:31:41 amMPLAB 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?

author: Karel
author_rank: Super Contributor
timestamp: November 09, 2017, 07:06:18 pm
content: Quote from: technix on November 09, 2017, 06:37:59 pmMuch easier and faster:https://www.eevblog.com/forum/microcontrollers/pic32-evolution/msg1007099/#msg1007099

author: technix
author_rank: Super Contributor
timestamp: November 09, 2017, 07:08:20 pm
content: Quote from: fourtytwo42 on November 05, 2017, 10:31:41 amBingo 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.)

author: technix
author_rank: Super Contributor
timestamp: November 09, 2017, 07:13:08 pm
content: Quote from: Karel on November 09, 2017, 07:06:18 pmRebuilding 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.

author: fourtytwo42
author_rank: Super Contributor
timestamp: November 09, 2017, 07:31:27 pm
content: 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 approachesI 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 elseAs 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))

author: mrpackethead
author_rank: Super Contributor
timestamp: November 09, 2017, 07:52:33 pm
content: Quote from: mikeselectricstuff on October 14, 1974, 09:22:57 pmIts 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,

author: eugenenine
author_rank: Frequent Contributor
timestamp: November 09, 2017, 08:41:14 pm
content: Quote from: technix on November 09, 2017, 07:08:20 pmEven 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.

author: TomS_
author_rank: Frequent Contributor
timestamp: November 17, 2017, 08:20:44 pm
content: Quote from: Karel on November 06, 2017, 01:50:02 pmCan 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?

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 17, 2017, 09:17:59 pm
content: Quote from: TomS_ on November 17, 2017, 08:20:44 pmYou missed thelinkwith dodgy legal advice that tells you how to crack the licence.

author: Karel
author_rank: Super Contributor
timestamp: November 18, 2017, 09:04:02 am
content: Quote from: Bruce Abbott on November 17, 2017, 09:17:59 pmIf 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.

author: Ian.M
author_rank: Super Contributor
timestamp: November 18, 2017, 09:42:46 am
content: 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.

author: Karel
author_rank: Super Contributor
timestamp: November 18, 2017, 03:08:59 pm
content: Quote from: Ian.M on November 18, 2017, 09:42:46 amThere 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:QuoteSo, 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 18, 2017, 03:15:09 pm
content: Quote from: Karel on November 18, 2017, 03:08:59 pmAlso, I think that the optimizations in question are mostly part of the original GCC, not something added by Microchip.

author: technix
author_rank: Super Contributor
timestamp: November 19, 2017, 05:17:32 am
content: Quote from: NorthGuy on November 18, 2017, 03:15:09 pmEven 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 andevery single piece of codecompiled 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?)

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 19, 2017, 06:34:42 am
content: Quote from: NorthGuy on November 18, 2017, 03:15:09 pmQuote from: technixQuote from: KarelUnlike 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 hadactuallawyers 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.

author: Karel
author_rank: Super Contributor
timestamp: November 19, 2017, 07:53:31 am
content: Quote from: Bruce Abbott on November 19, 2017, 06:34:42 amMe neither. That doesn't mean I can't have an opinion about it.Quote from: Bruce Abbott on November 19, 2017, 06:34:42 amIt'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.Quote from: Bruce Abbott on November 19, 2017, 06:34:42 amI guess the Free Software Foundation will be happy to dragtheirasses into court if they are going to break balls about the GCC compiler....Quote from: Bruce Abbott on November 19, 2017, 06:34:42 amPlease don't make the mistake to think it's a crack. It's not.Microchiphackedthe compiler in order to block certain optimizations.Ihackedthe compiler to unblock the optimizations.Quote from: Bruce Abbott on November 19, 2017, 06:34:42 amI 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 youto hack it and improve it and give back to the community.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 19, 2017, 08:12:00 am
content: Quote from: Karel on November 19, 2017, 07:53:31 amSo all those device-specific info files, linker scripts, documentation etc. costs nothing to produce ?

author: Karel
author_rank: Super Contributor
timestamp: November 19, 2017, 08:43:14 am
content: Quote from: mikeselectricstuff on November 19, 2017, 08:12:00 amWhere 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.

author: voltsandjolts
author_rank: Unknown
timestamp: November 19, 2017, 09:57:07 am
content: Quote from: mikeselectricstuff on November 19, 2017, 08:12:00 amIn comparison to the cost of GCC's development (which Microchip contributed nothing to and gained much from), yes, nothing.

author: JanJansen
author_rank: Frequent Contributor
timestamp: November 19, 2017, 01:58:31 pm
content: 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 19, 2017, 03:07:35 pm
content: Quote from: Bruce Abbott on November 19, 2017, 06:34:42 amBlame? 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.

author: Karel
author_rank: Super Contributor
timestamp: November 19, 2017, 04:57:09 pm
content: Quote from: NorthGuy on November 19, 2017, 03:07:35 pmYou 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 19, 2017, 05:16:03 pm
content: Quote from: Karel on November 19, 2017, 04:57:09 pmI 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.

author: voltsandjolts
author_rank: Unknown
timestamp: November 19, 2017, 05:22:45 pm
content: 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

author: Karel
author_rank: Super Contributor
timestamp: November 19, 2017, 05:31:46 pm
content: Quote from: NorthGuy on November 19, 2017, 05:16:03 pmWell, 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.

author: FrankBuss
author_rank: Unknown
timestamp: November 19, 2017, 05:39:21 pm
content: Quote from: Karel on November 19, 2017, 05:31:46 pmOf 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.

author: Karel
author_rank: Super Contributor
timestamp: November 19, 2017, 05:53:35 pm
content: Quote from: FrankBuss on November 19, 2017, 05:39:21 pmI agree but it's a little more complicated. If you read back this thread, it appears that some people think that it is perfecly fineif Microchip hacks the GCC compiler in order to block optimizations but it's not fine when I unblock them by hacking it again.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 19, 2017, 06:00:04 pm
content: Quote from: Karel on November 19, 2017, 05:31:46 pmHave you tried?Quote from: Karel on November 19, 2017, 05:31:46 pmI 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.

author: cv007
author_rank: Frequent Contributor
timestamp: November 19, 2017, 06:12:57 pm
content: QuoteMCHP 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?

author: technix
author_rank: Super Contributor
timestamp: November 19, 2017, 06:33:13 pm
content: Quote from: voltsandjolts on November 19, 2017, 05:22:45 pmJust 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.

author: technix
author_rank: Super Contributor
timestamp: November 19, 2017, 06:41:06 pm
content: Quote from: NorthGuy on November 19, 2017, 06:00:04 pmThere 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:$ avr-gcc --versionavr-gcc (GCC) 7.2.0Copyright (C) 2017 Free Software Foundation, Inc.This is free software; see the source for copying conditions. There is NOwarranty; 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:$ arm-none-eabi-gcc --versionarm-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 NOwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.Or the one from Atmel Studio:Code:avr-gcc --versionavr-gcc (AVR_8_bit_GNU_Toolchain_3.6.1_1750) 5.4.0Copyright (C) 2015 Free Software Foundation, Inc.This is free software; see the source for copying conditions. There is NOwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

author: technix
author_rank: Super Contributor
timestamp: November 19, 2017, 06:50:35 pm
content: Quote from: Karel on November 19, 2017, 05:53:35 pmIf 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.

author: technix
author_rank: Super Contributor
timestamp: November 19, 2017, 06:57:57 pm
content: 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.

author: MT
author_rank: Super Contributor
timestamp: November 19, 2017, 09:57:46 pm
content: Quote from: FrankBuss on November 19, 2017, 05:39:21 pmSo i wonder, did Microchip publish their hack to restrict optimization levels? And if so why did they restrict optimization levels to begin with?

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 19, 2017, 11:20:31 pm
content: Quote from: Karel on November 19, 2017, 04:57:09 pmThat too, but mostly it's about cracking proprietary software.Here's the primary offense:-QuoteInside 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 thatReprise License Manageris not covered by GCC's GPL.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 19, 2017, 11:47:29 pm
content: Quote from: Bruce Abbott on November 19, 2017, 11:20:31 pmOn 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 ...

author: cv007
author_rank: Frequent Contributor
timestamp: November 20, 2017, 12:29:07 am
content: QuoteThere 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.

author: technix
author_rank: Super Contributor
timestamp: November 20, 2017, 06:30:24 am
content: Quote from: Bruce Abbott on November 19, 2017, 11:20:31 pmI 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.

author: Karel
author_rank: Super Contributor
timestamp: November 20, 2017, 07:38:32 am
content: Quote from: Bruce Abbott on November 19, 2017, 11:20:31 pmCV007 is right:https://www.eevblog.com/forum/microcontrollers/mplab-x-a-pic-inhibitor!-alternatives/msg1353555/#msg1353555There'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...

author: cv007
author_rank: Frequent Contributor
timestamp: November 20, 2017, 07:44:06 am
content: 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 filesalso no laws against creating your own file with the name xclmthe only modifications are to gpl licensed code (3 binary files), which now have the hash value of the new xclm fileOption 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 itI 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).

author: hans
author_rank: Super Contributor
timestamp: November 20, 2017, 11:01:03 am
content: Quote from: cv007 on November 20, 2017, 12:29:07 amWell, it could be that the XC16/XC32 as a "complete package" isnotGPL, 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 theArch 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 be2xfaster 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 useXC16 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 than7 years old(released 2010). This version hasfew C++11 featuresintegrated, 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.

author: Karel
author_rank: Super Contributor
timestamp: November 20, 2017, 11:30:36 am
content: Quote from: hans on November 20, 2017, 11:01:03 amIt'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.

author: andersm
author_rank: Super Contributor
timestamp: November 20, 2017, 11:41:34 am
content: Quote from: hans on November 20, 2017, 11:01:03 amThe compiler itself is GPL, but eg. the libraries and device database files are not.

author: technix
author_rank: Super Contributor
timestamp: November 20, 2017, 01:31:05 pm
content: Quote from: andersm on November 20, 2017, 11:41:34 amI 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.

author: technix
author_rank: Super Contributor
timestamp: November 20, 2017, 01:33:19 pm
content: Quote from: Karel on November 20, 2017, 07:38:32 amOr 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.)

author: NorthGuy
author_rank: Super Contributor
timestamp: November 20, 2017, 04:43:16 pm
content: Quote from: Karel on November 20, 2017, 11:30:36 amOr perhaps they're not satisfied with all the free wheels laying around, but rather want to invent a better wheel.

author: Karel
author_rank: Super Contributor
timestamp: November 20, 2017, 05:05:56 pm
content: Quote from: NorthGuy on November 20, 2017, 04:43:16 pmThat's fine, I encourage competition. No need to show hate/angriness about the GPL. If you don't like it, don't use it.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 20, 2017, 07:02:48 pm
content: Quote from: hans on November 20, 2017, 11:01:03 amWhat 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'tanyoneproduce a better version if they want? What is stopping the PIC versions from being as up-to-date as others?Quote from: cv007The source to xclm is available?QuoteYou 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 isnotcovered by GPL... Now I may be wrong, and it's all perfectly legal. But I still think it's dodgy.

author: technix
author_rank: Super Contributor
timestamp: November 20, 2017, 07:04:32 pm
content: Quote from: Karel on November 20, 2017, 05:05:56 pmOh the corporates will hate on GPL. In factthey already do.

author: Karel
author_rank: Super Contributor
timestamp: November 20, 2017, 07:52:50 pm
content: Quote from: Bruce Abbott on November 20, 2017, 07:02:48 pmHere 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"?

author: andersm
author_rank: Super Contributor
timestamp: November 20, 2017, 07:54:30 pm
content: Quote from: technix on November 20, 2017, 01:31:05 pmI'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.QuoteWhich header files?Someof 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.

author: cv007
author_rank: Frequent Contributor
timestamp: November 20, 2017, 08:31:48 pm
content: QuoteNo. 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-archivethere 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}-0x${b}+0x${b})); printf "%0.8x: 0600 0000 0000 0000" $offset | xxd -r - $f; done

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 21, 2017, 12:16:37 am
content: Just out of curiosity I downloaded the XC32 source.Over 103,00 files....

author: westfw
author_rank: Super Contributor
timestamp: November 21, 2017, 01:36:58 am
content: QuoteYeah... 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.QuoteIn 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...)

author: andersm
author_rank: Super Contributor
timestamp: November 21, 2017, 06:50:33 am
content: Quote from: westfw on November 21, 2017, 01:36:58 amAlso 30 years of history.QuoteLike 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.

author: Karel
author_rank: Super Contributor
timestamp: November 21, 2017, 07:30:48 am
content: Quote from: westfw on November 21, 2017, 01:36:58 amWrong, it's (still) done by skilled professionals who make a good living with it.Quote from: westfw on November 21, 2017, 01:36:58 amI 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.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 21, 2017, 12:20:00 pm
content: Quote from: Karel on November 21, 2017, 07:30:48 amGCC is being maintained by skilled professionals who make a good living out of it?QuoteAndroid?

author: andersm
author_rank: Super Contributor
timestamp: November 21, 2017, 12:40:04 pm
content: Quote from: Bruce Abbott on November 21, 2017, 12:20:00 pmI don't know how much they're getting paid, but even a cursory glance at themaintainer listshows 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.

author: Karel
author_rank: Super Contributor
timestamp: November 21, 2017, 01:00:04 pm
content: Quote from: Bruce Abbott on November 21, 2017, 12:20:00 pmLinux

author: Karel
author_rank: Super Contributor
timestamp: November 21, 2017, 01:34:24 pm
content: I can confirm that the commandCode: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}-0x${b}+0x${b})); printf "%0.8x: 0600 0000 0000 0000" $offset | xxd -r - $f; doneworks correctly. No need to replace the xclm executable.Thanks againI assume even Bruce will be happy now

author: cv007
author_rank: Frequent Contributor
timestamp: November 21, 2017, 09:28:30 pm
content: 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

author: hans
author_rank: Super Contributor
timestamp: November 21, 2017, 09:33:04 pm
content: Quote from: Bruce Abbott on November 20, 2017, 07:02:48 pmWell 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', becausesomewherea 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)

author: andersm
author_rank: Super Contributor
timestamp: November 21, 2017, 10:02:02 pm
content: Quote from: hans on November 21, 2017, 09:33:04 pmAs 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.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 22, 2017, 12:39:33 am
content: Quote from: andersm on November 21, 2017, 12:40:04 pmNobody said that. My question was, is GCC being maintained by skilled professionals who make a good living out ofit?QuoteThat's a lot of people. Who pays them for working on GCC?

author: andersm
author_rank: Super Contributor
timestamp: November 22, 2017, 06:19:32 am
content: Quote from: Bruce Abbott on November 22, 2017, 12:39:33 amLook 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.

author: ruffy91
author_rank: Regular Contributor
timestamp: November 22, 2017, 06:23:39 am
content: https://gcc.gnu.org/onlinedocs/gcc/Contributors.htmlMost 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.

author: technix
author_rank: Super Contributor
timestamp: November 22, 2017, 07:18:14 am
content: Quote from: ruffy91 on November 22, 2017, 06:23:39 amFrom 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.

author: @rt
author_rank: Super Contributor
timestamp: November 22, 2017, 02:20:07 pm
content: 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.

author: fourtytwo42
author_rank: Super Contributor
timestamp: November 22, 2017, 05:40:30 pm
content: Quote from: @rt on November 22, 2017, 02:20:07 pmYou 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

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 22, 2017, 07:16:12 pm
content: Quote from: Karel on November 21, 2017, 01:34:24 pmIf I can get XC32 to optimize my code without violating any of Microchip's licensing agreementsandcan 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?

author: Siwastaja
author_rank: Super Contributor
timestamp: November 22, 2017, 07:22:17 pm
content: Quote from: Bruce Abbott on November 22, 2017, 07:16:12 pmYes, 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 yourownsoftware, on your own computer.

author: Karel
author_rank: Super Contributor
timestamp: November 22, 2017, 07:52:27 pm
content: Quote from: Bruce Abbott on November 22, 2017, 07:16:12 pmIt'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.

author: @rt
author_rank: Super Contributor
timestamp: November 22, 2017, 08:14:31 pm
content: Where does “objdump” come from?

author: voltsandjolts
author_rank: Unknown
timestamp: November 22, 2017, 08:27:29 pm
content: The script patches the xc32 executables on linux, objdump is standard part of most linux distros.

author: @rt
author_rank: Super Contributor
timestamp: November 22, 2017, 08:29:53 pm
content: Bummer! Mine is installed on a Mac.

author: cv007
author_rank: Frequent Contributor
timestamp: November 22, 2017, 08:41:09 pm
content: 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.

author: @rt
author_rank: Super Contributor
timestamp: November 22, 2017, 09:02:17 pm
content: Can you modify XC16 with a Mac?

author: @rt
author_rank: Super Contributor
timestamp: November 22, 2017, 10:38:33 pm
content: 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”Fortunately I can still select the older XC16 version, and it compiles as it used to!

author: cv007
author_rank: Frequent Contributor
timestamp: November 22, 2017, 10:39:34 pm
content: 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.txtCode:*cc1:+ -mafrlcsj*cc1plus:+ -mafrlcsjedit- 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.txtCompile 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 22, 2017, 11:35:10 pm
content: 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.

author: @rt
author_rank: Super Contributor
timestamp: November 23, 2017, 02:52:20 am
content: 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

author: cv007
author_rank: Frequent Contributor
timestamp: November 23, 2017, 04:58:18 am
content: 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.cgcc/gcc/config/pic32/mchp.optgcc/gcc/config/pic32/mchp.c

author: technix
author_rank: Super Contributor
timestamp: November 23, 2017, 05:20:27 am
content: Quote from: @rt on November 22, 2017, 09:02:17 pmSure I can. macOS is UNIX too, being based on BSD instead of Linux though.

author: @rt
author_rank: Super Contributor
timestamp: November 23, 2017, 05:26:51 am
content: 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.

author: technix
author_rank: Super Contributor
timestamp: November 23, 2017, 05:43:48 am
content: Quote from: @rt on November 23, 2017, 05:26:51 amDelay 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.

author: @rt
author_rank: Super Contributor
timestamp: November 23, 2017, 06:05:03 am
content: 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.

author: technix
author_rank: Super Contributor
timestamp: November 23, 2017, 06:15:34 am
content: Quote from: @rt on November 23, 2017, 06:05:03 amThe 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.

author: JPortici
author_rank: Super Contributor
timestamp: November 23, 2017, 06:24:23 am
content: Quote from: cv007 on November 23, 2017, 04:58:18 am-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

author: hans
author_rank: Super Contributor
timestamp: November 23, 2017, 08:45:05 am
content: 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.

author: @rt
author_rank: Super Contributor
timestamp: November 23, 2017, 01:19:44 pm
content: Looking a the output window for mine, changing the opt level does nothing.I can change it for each file in “configurations.xml”.

author: andersm
author_rank: Super Contributor
timestamp: November 23, 2017, 04:02:25 pm
content: Quote from: @rt on November 23, 2017, 01:19:44 pmWhy 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.

author: @rt
author_rank: Super Contributor
timestamp: November 23, 2017, 11:29:26 pm
content: If you read some posts above. It didn’t work, and still doesn’t. Images are also attached.

author: cv007
author_rank: Frequent Contributor
timestamp: November 24, 2017, 12:19:11 am
content: 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).QuoteYour 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).

author: @rt
author_rank: Super Contributor
timestamp: November 24, 2017, 02:54:18 am
content: 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) 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

author: andersm
author_rank: Super Contributor
timestamp: November 24, 2017, 06:03:26 am
content: Quote from: @rt on November 23, 2017, 11:29:26 pmYour images didn't show the build transcript, which would show that you built with the options you think you did.

author: @rt
author_rank: Super Contributor
timestamp: November 24, 2017, 06:11:19 am
content: 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.

author: andersm
author_rank: Super Contributor
timestamp: November 24, 2017, 07:30:55 am
content: Quote from: @rt on November 24, 2017, 06:11:19 amSo 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.

author: JPortici
author_rank: Super Contributor
timestamp: November 24, 2017, 09:11:00 am
content: Quote from: cv007 on November 22, 2017, 10:39:34 pmhey, it did something(XC16 v1.33 on windows)tried with -O2 without additional options: "license file is required" and it compiled with -O1with the additional options, it compiled.-O0 and -O1 produce the same hex file with and without the additional optionOptimization level -O0Data: 6950Program: 8119Optimization level -O1Data: 6950Program: 6045Optimization level -O2Data: 6950Program: 7190 <--probably unrolling some loopsOptimization level -OsData: 6950Program: 5799 <-- this actually worries meOptimization level -O0Data: 6950Program: 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)

author: JPortici
author_rank: Super Contributor
timestamp: November 24, 2017, 09:30:39 am
content: oh oh.. i already see some of the tricks it adopted (that i can use with -O1 to force the compiler to optimize)comparison #1this routine produce the same code with -O1, -O2 and -O3Code:27: void shift_sentbuf(sentbuf_t* sentbuf,unsigned int times) {28: int idx;29: while (times > 0) {004EFE E00001 CP0 W1004F00 32000D BRA Z, 0x4F1C004F1A 3AFFF3 BRA NZ, 0x4F0230: for (idx=0;idx<(_SENT_BUF_SIZE-1);idx++) {31: sentbuf->buffer = sentbuf->buffer[idx+1];004F02 900120 MOV [W0+4], W2004F04 9001B0 MOV [W0+6], W3004F06 BE8802 MOV.D W2, 004F08 900140 MOV [W0+8], W2004F0A 9001D0 MOV [W0+10], W3004F0C 980022 MOV W2, [W0+4]004F0E 980033 MOV W3, [W0+6]004F10 900160 MOV [W0+12], W2004F12 9001F0 MOV [W0+14], W3004F14 980042 MOV W2, [W0+8]004F16 980053 MOV W3, [W0+10]32: }33: times--;004F18 E90081 DEC W1, W134: }35: }004F1C 060000 RETURNwith -Os, howeverCode:27: void shift_sentbuf(sentbuf_t* sentbuf,unsigned int times) {28: int idx;29: while (times > 0) {004D14 370008 BRA 0x4D26004D26 E00001 CP0 W130: for (idx=0;idx<(_SENT_BUF_SIZE-1);idx++) {004D20 518FE3 SUB W3, #0x3, 004D22 3AFFF9 BRA NZ, 0x4D1631: sentbuf->buffer = sentbuf->buffer[idx+1];004D16 E80183 INC W3, W3004D18 900222 MOV [W2+4], W4004D1A 9002B2 MOV [W2+6], W5004D1C BE8904 MOV.D W4, 004D1E 410164 ADD W2, #0x4, W232: }33: times--;004D24 E90081 DEC W1, W1004D26 E00001 CP0 W1004D28 320003 BRA Z, 0x4D30004D2A 780100 MOV W0, W2004D2C EB0180 CLR W3004D2E 37FFF3 BRA 0x4D16004D30 060000 RETURN34: }35: }reason is simple: #define _SENT_BUF_SIZE 4so 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 -O1Code: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], W2004ED2 E00002 CP0 W2004ED4 320010 BRA Z, 0x4EF614: data = sentbuf->buffer;004ED6 781831 MOV [W1++], [W0++]004ED8 781021 MOV [W1--], [W0--]15: for (idx=0;idx<_SENT_BUF_SIZE-1;idx++) {16: sentbuf->buffer = sentbuf->buffer[idx+1];004EDA 900221 MOV [W1+4], W4004EDC 9002B1 MOV [W1+6], W5004EDE BE8884 MOV.D W4, 004EE0 900241 MOV [W1+8], W4004EE2 9002D1 MOV [W1+10], W5004EE4 9800A4 MOV W4, [W1+4]004EE6 9800B5 MOV W5, [W1+6]004EE8 900261 MOV [W1+12], W4004EEA 9002F1 MOV [W1+14], W5004EEC 9800C4 MOV W4, [W1+8]004EEE 9800D5 MOV W5, [W1+10]17: }18: sentbuf->idx--;004EF0 E90102 DEC W2, W2004EF2 980882 MOV W2, [W1+16]004EF4 370003 BRA 0x4EFC19: }20: else {21: data.Data_H = 0;004EF6 EB0080 CLR W1004EF8 780801 MOV W1, 22: data.Data_L = 0;004EFA 980011 MOV W1, [W0+2]23: }24: return data;25: }004EFC 060000 RETURNand with every other optimization levelCode: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], W20057C6 E00002 CP0 W20057C8 320010 BRA Z, 0x57EA14: data = sentbuf->buffer;0057CA 781831 MOV [W1++], [W0++]0057CC 781021 MOV [W1--], [W0--]15: for (idx=0;idx<_SENT_BUF_SIZE-1;idx++) {16: sentbuf->buffer = sentbuf->buffer[idx+1];0057CE 900221 MOV [W1+4], W40057D0 9002B1 MOV [W1+6], W50057D2 BE8884 MOV.D W4, 0057D4 900241 MOV [W1+8], W40057D6 9002D1 MOV [W1+10], W50057D8 9800A4 MOV W4, [W1+4]0057DA 9800B5 MOV W5, [W1+6]0057DC 900261 MOV [W1+12], W40057DE 9002F1 MOV [W1+14], W50057E0 9800C4 MOV W4, [W1+8]0057E2 9800D5 MOV W5, [W1+10]17: }18: sentbuf->idx--;0057E4 E90102 DEC W2, W20057E6 980882 MOV W2, [W1+16]0057E8 060000 RETURN19: }20: else {21: data.Data_H = 0;0057EA 780802 MOV W2, 22: data.Data_L = 0;0057EC 980012 MOV W2, [W0+2]23: }24: return data;25: }0057EE 060000 RETURNnot 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)

author: JPortici
author_rank: Super Contributor
timestamp: November 24, 2017, 10:09:18 am
content: strangenes...-O1Code:54: UART2_TXBuf.dim = 6;004224 200060 MOV #0x6, W0004226 889390 MOV W0, 0x1272vs -O2 (this may explain the 300 or so more instruction as i don't see much difference in the listing)Code:54: UART2_TXBuf.dim = 6;0049A0 200060 MOV #0x6, W00049A2 889390 MOV W0, 0x12720049CA 200060 MOV #0x6, W00049CC 889390 MOV W0, 0x12720049F6 200060 MOV #0x6, W00049F8 889390 MOV W0, 0x1272this happens many times..and with routine calls too.. WTF?Code:60: UART2_TXBuf.buffer = uart_chkCalc(&UART2_TXBuf);0049B0 212500 MOV #0x1250, W00049B2 0706E3 RCALL _uart_chkCalc0049B4 8892D0 MOV W0, 0x125A0049DA 212500 MOV #0x1250, W00049DC 0706CE RCALL _uart_chkCalc0049DE 8892D0 MOV W0, 0x125A004A06 212500 MOV #0x1250, W0004A08 0706B8 RCALL _uart_chkCalc004A0A 8892D0 MOV W0, 0x125A

author: @rt
author_rank: Super Contributor
timestamp: November 24, 2017, 11:06:33 am
content: Quote from: andersm on November 24, 2017, 07:30:55 amNo, 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.

author: gocemk
author_rank: Regular Contributor
timestamp: November 24, 2017, 01:21:06 pm
content: 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 3340mRAN: 8GBSSD Hard Drive: Kingston HyperX Fury 128GBOS: Windows 10Based on what i read here, i should be able to start MPLABX much faster.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 24, 2017, 02:40:22 pm
content: Quote from: JPortici on November 24, 2017, 10:09:18 amThis 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.

author: cv007
author_rank: Frequent Contributor
timestamp: November 24, 2017, 03:14:02 pm
content: Quote'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.QuoteRight-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.

author: @rt
author_rank: Super Contributor
timestamp: November 24, 2017, 03:14:09 pm
content: 2.3GHz i5 Mac with 9Gb RAM, and MPLABX opens, and is ready to type in the current open file in 15 seconds.

author: gocemk
author_rank: Regular Contributor
timestamp: November 24, 2017, 08:15:32 pm
content: 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.

author: cv007
author_rank: Frequent Contributor
timestamp: November 24, 2017, 11:16:56 pm
content: QuoteThere 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 compilerC Compiler - /opt/microchip/xc32/v1.44/bin/xc32-gccadd 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 projectthis 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)

author: eugenenine
author_rank: Frequent Contributor
timestamp: November 25, 2017, 12:52:43 am
content: Quote from: gocemk on November 24, 2017, 01:21:06 pmMy 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

author: technix
author_rank: Super Contributor
timestamp: November 25, 2017, 08:51:50 am
content: 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)

author: @rt
author_rank: Super Contributor
timestamp: November 25, 2017, 09:34:05 am
content: I’ll be the first to give you my blessing if what I read here is true

author: cv007
author_rank: Frequent Contributor
timestamp: November 26, 2017, 12:40:37 am
content: QuoteIt just means the compile fails sooner.

author: cv007
author_rank: Frequent Contributor
timestamp: November 26, 2017, 01:15:40 am
content: 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)

author: cv007
author_rank: Frequent Contributor
timestamp: December 03, 2017, 01:19:00 am
content: 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 sizesCode:ISO = isolate functions into sections/remove unused sections-O0 -> 32kISO -> 29k-O1 -> 22kISO + -O1 -> 20kISO + -O2 -> 19kISO + -O3 -> 20kISO + -Os -> 17.5kSo, 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: December 03, 2017, 04:22:08 am
content: Quote from: cv007 on December 03, 2017, 01:19:00 amNot 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.

author: @rt
author_rank: Super Contributor
timestamp: December 03, 2017, 05:22:27 am
content: 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?

author: JPortici
author_rank: Super Contributor
timestamp: December 03, 2017, 07:26:23 pm
content: more details pleaseQuote from: cv007 on December 03, 2017, 01:19:00 amwhy. WHY?

author: andersm
author_rank: Super Contributor
timestamp: December 03, 2017, 08:27:42 pm
content: Quote from: JPortici on December 03, 2017, 07:26:23 pmAssuming 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.

author: cv007
author_rank: Frequent Contributor
timestamp: December 03, 2017, 08:41:22 pm
content: Quote101 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.

author: JPortici
author_rank: Super Contributor
timestamp: December 04, 2017, 02:06:31 am
content: Ah, IVT. Makes sense. To he completely honest i haven't had a chance to use a MM yet, so please forgive methey 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)

author: cv007
author_rank: Frequent Contributor
timestamp: December 04, 2017, 02:59:15 am
content: 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.

author: voltsandjolts
author_rank: Unknown
timestamp: December 04, 2017, 11:38:43 am
content: Nicely presented schematic and layout.What ECAD package are you using?

author: cv007
author_rank: Frequent Contributor
timestamp: December 04, 2017, 01:33:57 pm
content: QuoteSprint Layout 6, sPlan 7These 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

author: picdev
author_rank: Contributor
timestamp: December 05, 2017, 11:22:48 pm
content: 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

author: cv007
author_rank: Frequent Contributor
timestamp: December 06, 2017, 12:13:08 am
content: QuoteLike 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).

author: picdev
author_rank: Contributor
timestamp: December 06, 2017, 06:18:31 am
content: Quote from: cv007 on December 06, 2017, 12:13:08 amWhat about libraries ?Sometimes you need something readySent from my Redmi 4 using Tapatalk

author: Karel
author_rank: Super Contributor
timestamp: December 06, 2017, 07:31:37 am
content: Quote from: picdev on December 06, 2017, 06:18:31 amApart 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: December 06, 2017, 04:42:47 pm
content: Quote from: Karel on December 06, 2017, 07:31:37 amMe too. I'll take well documented hardware datasheet over black-box libraries at any time.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 06, 2017, 04:52:15 pm
content: Quote from: Karel on December 06, 2017, 07:31:37 amThis. x1000000

author: technix
author_rank: Super Contributor
timestamp: December 06, 2017, 07:23:45 pm
content: Quote from: NorthGuy on December 06, 2017, 04:42:47 pmGee 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?

author: Siwastaja
author_rank: Super Contributor
timestamp: December 06, 2017, 07:45:58 pm
content: Quote from: technix on December 06, 2017, 07:23:45 pmThey 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'ssupposedly"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 necessitatessomelibrary usage. Still, this only makes itevenmore important to focus on the quality, not quantity, of the libraries.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 06, 2017, 08:03:58 pm
content: QuoteThat says a lot about how Chinese firmware gets done-throw some libraries together instead of using any original creativity.

author: picdev
author_rank: Contributor
timestamp: December 06, 2017, 08:28:41 pm
content: 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

author: FrankBuss
author_rank: Unknown
timestamp: December 06, 2017, 09:55:19 pm
content: Quote from: technix on December 06, 2017, 07:23:45 pmI 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: December 06, 2017, 10:14:12 pm
content: Quote from: picdev on December 06, 2017, 08:28:41 pmNot 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 - justwritingthe code to change an IO pin to an output would take minutes, and it'd be impossible torememberhow 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 upincreasingcomplexity. 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 usevery high-quality abstaction layers/librariesordo 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 07, 2017, 12:12:59 am
content: Quote from: picdev on December 06, 2017, 08:28:41 pmWhy would it not be.One peripheral at a time.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 07, 2017, 12:32:57 am
content: Quote from: Siwastaja on December 06, 2017, 10:14:12 pmAnd 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.

author: westfw
author_rank: Super Contributor
timestamp: December 07, 2017, 03:01:29 am
content: QuoteIn 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(This doesn't stop it from bitingsomeonea couple times a year...)

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 07, 2017, 09:22:09 am
content: Quote from: westfw on December 07, 2017, 03:01:29 amAnd does the macro generate a compile-time warning of these conditions are not met ?

author: technix
author_rank: Super Contributor
timestamp: December 07, 2017, 10:00:36 am
content: Quote from: mikeselectricstuff on December 07, 2017, 09:22:09 amThey 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?

author: technix
author_rank: Super Contributor
timestamp: December 07, 2017, 10:21:40 am
content: Quote from: mikeselectricstuff on December 06, 2017, 08:03:58 pmYou 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.

author: KL27x
author_rank: Super Contributor
timestamp: December 07, 2017, 10:48:21 am
content: QuoteThanks, 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.

author: technix
author_rank: Super Contributor
timestamp: December 07, 2017, 11:58:41 am
content: Quote from: KL27x on December 07, 2017, 10:48:21 amUSB 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.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: December 07, 2017, 07:30:49 pm
content: Quote from: technix on December 07, 2017, 11:58:41 amAnd what most people need is the quickest easiest solution that gets the job done - which is why they use libraries.QuoteBloated for sure, but who has the time and skill to write everything themselves? Just throw more memory and a faster CPU at it!

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 07, 2017, 07:33:42 pm
content: Quote from: Bruce Abbott on December 07, 2017, 07:30:49 pmFor often inferior values of "job done"

author: Siwastaja
author_rank: Super Contributor
timestamp: December 07, 2017, 08:59:58 pm
content: Quote from: Bruce Abbott on December 07, 2017, 07:30:49 pmThis 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 producesomething- but most of the time, they just talk big and fail to provideanythingat 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 spendweeksof combining those libraries to get a Minimum Viable Prototype (version 0) out. They just genuinely think it's inevitably that hard, and they actuallybelievethat the libraries "helped" them and it would have beenyearswithout, 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).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, dothat. 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!

author: hans
author_rank: Super Contributor
timestamp: December 07, 2017, 11:04:35 pm
content: Quote from: Siwastaja on December 07, 2017, 08:59:58 pmIndeed, 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:QuoteBut then see the following mess:QuoteMakes 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#L284Great 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 bitmoreto 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..

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: December 08, 2017, 06:14:46 am
content: Quote from: Siwastaja on December 07, 2017, 08:59:58 pmAnd it will always be this way because the vast majority arenotgood 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 theycanproduce (mostly) working code using libraries. If that keeps them employed then - mission accomplished!QuoteReal, successful laziness means using other people's code rather then taking the time to write your own.Quote...is unnecessary. You only need to understandjustenough to get your code to (mostly) work.

author: Siwastaja
author_rank: Super Contributor
timestamp: December 08, 2017, 06:48:57 am
content: 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 livingin 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, Isurelyneed 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 outwhythose 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 havinghugepersistence 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: "theymustbe 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!

author: westfw
author_rank: Super Contributor
timestamp: December 08, 2017, 08:04:57 am
content: QuoteI 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 whereChoicesAre Made...

author: JPortici
author_rank: Super Contributor
timestamp: December 08, 2017, 08:12:35 am
content: maybe with "libraries" they were referring to "peripheral libraries"?

author: Karel
author_rank: Super Contributor
timestamp: December 08, 2017, 08:34:02 am
content: Quote from: westfw on December 08, 2017, 08:04:57 amFilesystem 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: December 08, 2017, 08:40:33 am
content: 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 arenevertalking 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: December 08, 2017, 02:14:19 pm
content: 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.

author: picdev
author_rank: Contributor
timestamp: December 11, 2017, 07:48:42 pm
content: 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 EnglishSent from my Redmi 4 using Tapatalk

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 11, 2017, 09:06:35 pm
content: Quote from: picdev on December 11, 2017, 07:48:42 pmI'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.

author: mrpackethead
author_rank: Super Contributor
timestamp: December 12, 2017, 02:59:08 am
content: 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: December 13, 2017, 01:32:47 am
content: 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.

author: mrpackethead
author_rank: Super Contributor
timestamp: December 13, 2017, 05:20:06 am
content: Quote from: Sal Ammoniac on December 13, 2017, 01:32:47 amYes, 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.

author: @rt
author_rank: Super Contributor
timestamp: December 13, 2017, 05:41:18 am
content: 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:* jidctint.c** Copyright (C) 1991-1998, Thomas G. Lane.* This file is part of the Independent JPEG Group's software.

author: technix
author_rank: Super Contributor
timestamp: December 13, 2017, 11:04:04 am
content: Quote from: @rt on December 13, 2017, 05:41:18 amThat 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.

author: @rt
author_rank: Super Contributor
timestamp: January 22, 2018, 02:54:50 pm
content: HiI 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:8472db5:8b 35 a0 25 94 08mov 0x89425a0,%esi8472dbb:85 f6test %esi,%esi8472dbd:0f 85 d2 05 00 00jne 8473395 <pic30_override_options+0x895>

author: Karel
author_rank: Super Contributor
timestamp: January 22, 2018, 03:24:38 pm
content: Quote from: @rt on January 22, 2018, 02:54:50 pmIn 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

author: @rt
author_rank: Super Contributor
timestamp: January 22, 2018, 04:17:58 pm
content: Hi, mine is on a Mac, and I don’t have the tools for that.I was hoping the easy way would workI’m on a phone in bed now, and realised the blank line in theSpec.txt might be wrong.TextEdit for Mac insets 0x0A characters for new lines,where other editors such as Windows Notepad inserts0x0A, 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.

author: cv007
author_rank: Frequent Contributor
timestamp: January 22, 2018, 09:33:42 pm
content: QuoteI 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.txtalthough 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 Macif not, then my opinion of Mac OS just went downneed- terminal- bash (or similar), objdump, grep, xxd, sedget 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:for f in elf-cc1 coff-cc1; do[ -e $f.bak ] || cp $f $f.baka=$(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 - $fdonesummary-line1- just simply do for each of these 2 files (nobody probably uses coff file, though)line2- if backup copy not previously made, make oneline3- using objdump, get address of mchp_mafrlcsjline4- convert address to little-endianline5- using objdump, get address of gcc_versionline6- convert to little-endianline7- create var for sed search- 8b..address of mchp_mafrlcsjline8- create replacement var for sed- 8b..address of gcc_versionline9- dump file into sed as hex, replacing first (only) instance of match, dump back out to binaryline10- doneYou 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)

author: @rt
author_rank: Super Contributor
timestamp: January 23, 2018, 03:03:52 am
content: It looks like it will work, as in no errors, but actually doesn’t.Code:for f in elf-cc1 coff-cc1; do[ -e $f.bak ] || cp $f $f.baka=$(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 - $fdoneotool is apparently the Mac version of objdump.It ends up with errors unless I change it.Code:Breks-Mac:desktop bmar0000$ cd XC16_BackupBreks-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> doneBreks-Maci:bin bmar0000$No complaining in the terminal, but the project still tells me my license is restricted just the same.

author: cv007
author_rank: Frequent Contributor
timestamp: January 23, 2018, 03:27:31 am
content: 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-cc1cp coff-cc1.bak coff-cc1now you are working with the originals againforget the script for now, just get the addresses from the command line-otool -T elf-cc1 | grep mchp_mafrlcsjotool -t elf-cc1 | grep gcc_versiononce you get those two addresses, report back- will simply then need to run a hex edit program.

author: @rt
author_rank: Super Contributor
timestamp: January 23, 2018, 03:52:04 am
content: 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:Breks-Mac:~ bmar0000$ cd /Applications/microchip/xc16/v1.33/bin/binBreks-Mac:bin bmar0000$ otool -T elf-cc1 | grep mchp_mafrlcsjBreks-Mac:bin bmar0000$ otool -t elf-cc1 | grep gcc_versionI guess that’s a problem then

author: @rt
author_rank: Super Contributor
timestamp: January 23, 2018, 04:14:24 am
content: 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 forumbecause 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

author: cv007
author_rank: Frequent Contributor
timestamp: January 23, 2018, 05:50:29 am
content: 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-cc1I'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.QuoteYou 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 failureI 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.

author: @rt
author_rank: Super Contributor
timestamp: January 23, 2018, 06:01:58 am
content: Thanks for sticking it outI 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.

author: andersm
author_rank: Super Contributor
timestamp: January 23, 2018, 08:00:18 am
content: Quote from: cv007 on January 23, 2018, 05:50:29 amOtool is the Mac tool for that, but macOS executables normally don't include symbol info.

author: @rt
author_rank: Super Contributor
timestamp: January 23, 2018, 08:38:32 am
content: Thanks for clearing that up. I don’t pretend to understand the script other than the for loop.I’m just a programmerA 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.

author: @rt
author_rank: Super Contributor
timestamp: January 23, 2018, 12:33:18 pm
content: 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.

author: JPortici
author_rank: Super Contributor
timestamp: January 23, 2018, 01:41:34 pm
content: actually the specs.txt method IS working for me, on win 7 win 10 and on osx 10.10it 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)

author: @rt
author_rank: Super Contributor
timestamp: January 23, 2018, 03:13:10 pm
content: Well I don’t know what to sayIt 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.

author: @rt
author_rank: Super Contributor
timestamp: January 23, 2018, 03:44:11 pm
content: 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?

author: cv007
author_rank: Frequent Contributor
timestamp: January 23, 2018, 04:06:27 pm
content: QuoteThose 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.

author: JPortici
author_rank: Super Contributor
timestamp: January 23, 2018, 04:32:03 pm
content: 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

author: cv007
author_rank: Frequent Contributor
timestamp: January 23, 2018, 05:14:32 pm
content: xc16 v1.32 - Windows versionC:\Program Files\Microchip\xc16\v1.32\bin\bin\elf-cc1.exefile offset 0x1623AEchange 0x85 to 0x84xc16 v1.33C:\Program Files\Microchip\xc16\v1.33\bin\bin\elf-cc1.exefile offset 0x161E7Echange 0x85 to 0x84

author: @rt
author_rank: Super Contributor
timestamp: January 23, 2018, 05:20:55 pm
content: 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.

author: @rt
author_rank: Super Contributor
timestamp: January 23, 2018, 05:23:01 pm
content: 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

author: cv007
author_rank: Frequent Contributor
timestamp: January 23, 2018, 05:46:23 pm
content: 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.QuoteThat would explain it then- the global option is not so global when you have individual files using their own settings. It would seem.

author: @rt
author_rank: Super Contributor
timestamp: January 23, 2018, 06:48:21 pm
content: 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.

author: cv007
author_rank: Frequent Contributor
timestamp: January 23, 2018, 07:20:11 pm
content: 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.

author: @rt
author_rank: Super Contributor
timestamp: January 24, 2018, 12:49:11 pm
content: 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 wellI 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

author: cv007
author_rank: Frequent Contributor
timestamp: January 24, 2018, 03:44:04 pm
content: 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 wantthere 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 rightreplace 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.

author: @rt
author_rank: Super Contributor
timestamp: January 24, 2018, 11:42:40 pm
content: 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.

author: cv007
author_rank: Frequent Contributor
timestamp: January 25, 2018, 01:47:16 am
content: 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).

author: @rt
author_rank: Super Contributor
timestamp: January 25, 2018, 03:38:37 am
content: 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

author: cv007
author_rank: Frequent Contributor
timestamp: January 25, 2018, 08:48:16 pm
content: I have added rev 3.1, xc16 osx binary info- untested, though.Any osx users can inform me if it works.

author: @rt
author_rank: Super Contributor
timestamp: January 27, 2018, 03:28:07 am
content: It’s now tested

author: cv007
author_rank: Frequent Contributor
timestamp: February 10, 2018, 07:39:36 pm
content: XC32 v2.05 addedRevision 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.

author: @rt
author_rank: Super Contributor
timestamp: February 10, 2018, 10:12:29 pm
content: HahaI might as well install it, even though I have no need for XC32 just yet. Future me thanks you again

author: Karel
author_rank: Super Contributor
timestamp: February 14, 2018, 01:26:00 pm
content: Also, the first method (manually replacing the SHA256sum in the binary using a hex-editor) still works with xc32 v2.05.

author: cv007
author_rank: Frequent Contributor
timestamp: February 14, 2018, 05:40:54 pm
content: 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.QuoteIf 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).

author: technix
author_rank: Super Contributor
timestamp: February 15, 2018, 11:05:44 am
content: Quote from: cv007 on February 14, 2018, 05:40:54 pmI 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.

author: @rt
author_rank: Super Contributor
timestamp: May 03, 2018, 03:43:21 am
content: and after this totally legitimate thread:http://www.microchip.com/forums/tm.aspx?tree=true&m=1050166&mpage=1Code:Access DeniedYou don't have permission to access "http://www.microchip.com/forums/post.aspx?" on this server.Reference #18.edb7d117.1525318856.1defdb3

author: cv007
author_rank: Frequent Contributor
timestamp: May 03, 2018, 04:24:42 am
content: 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.

author: @rt
author_rank: Super Contributor
timestamp: May 03, 2018, 04:32:06 am
content: 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.

author: cv007
author_rank: Frequent Contributor
timestamp: May 03, 2018, 04:49:42 am
content: QuoteThen its just the flakey mchp forum software. I get the same access denied from time to time.

author: @rt
author_rank: Super Contributor
timestamp: May 03, 2018, 05:43:46 am
content: 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!

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2018, 06:17:08 am
content: Quote from: @rt on May 03, 2018, 04:32:06 amIt'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.

author: @rt
author_rank: Super Contributor
timestamp: May 03, 2018, 06:54:16 am
content: 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.

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2018, 07:31:18 am
content: Quote from: @rt on May 03, 2018, 06:54:16 amYes, it is.Quote from: @rt on May 03, 2018, 06:54:16 amNo, it's not. It's just a particular implementation of their particular implementation.Quote from: @rt on May 03, 2018, 06:54:16 amIf 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.

author: @rt
author_rank: Super Contributor
timestamp: May 03, 2018, 07:47:26 am
content: 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

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2018, 08:55:36 am
content: Quote from: @rt on May 03, 2018, 07:47:26 amAccording to Wikipedia:QuoteThat means that Microchip cracked the GCC compiler...! Because they removed or disabled the higher optimization settings.

author: @rt
author_rank: Super Contributor
timestamp: May 03, 2018, 09:00:17 am
content: It does if you can find any other example of a source code that is commonly referred to as cracked.Executables are cracked.

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2018, 09:15:59 am
content: Quote from: @rt on May 03, 2018, 09:00:17 amOnly 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 byoverwriting and/or inserting bytes directly into an existing executable (binary) file .

author: Siwastaja
author_rank: Super Contributor
timestamp: May 03, 2018, 10:31:46 am
content: 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.

author: cv007
author_rank: Frequent Contributor
timestamp: May 03, 2018, 12:56:43 pm
content: 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.

author: JanJansen
author_rank: Frequent Contributor
timestamp: May 03, 2018, 01:56:11 pm
content: 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 tohackunlockto get some more power out of these chips, and we saving energy alltogether to save the world, dont run slow code.

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2018, 03:54:38 pm
content: Quote from: JanJansen on May 03, 2018, 01:56:11 pmXC8 is a completely different compiler. It's not GCC and it's not open source. You are not allowed to modify it.

author: cv007
author_rank: Frequent Contributor
timestamp: May 03, 2018, 04:04:14 pm
content: I added xc16 v1.34 info (binary mod for Linux only at the moment)https://github.com/cv007/XC3216Even 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.

author: @rt
author_rank: Super Contributor
timestamp: May 06, 2018, 09:36:25 am
content: @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 withoutaccess 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.

author: Karel
author_rank: Super Contributor
timestamp: May 06, 2018, 02:09:36 pm
content: Quote from: @rt on May 06, 2018, 09:36:25 amSo 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:QuoteSo, 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.

author: westfw
author_rank: Super Contributor
timestamp: May 06, 2018, 08:41:35 pm
content: QuoteHmm. 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."

author: Karel
author_rank: Super Contributor
timestamp: May 07, 2018, 08:58:29 am
content: Quote from: westfw on May 06, 2018, 08:41:35 pmThat depends. Does your software contains GPL'ed software?

author: westfw
author_rank: Super Contributor
timestamp: May 08, 2018, 11:09:05 pm
content: QuoteAssume 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...

author: cv007
author_rank: Frequent Contributor
timestamp: May 09, 2018, 02:13:04 am
content: QuoteI 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.

author: @rt
author_rank: Super Contributor
timestamp: May 09, 2018, 04:13:56 am
content: 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 sowithout 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.

author: JPortici
author_rank: Super Contributor
timestamp: May 09, 2018, 05:14:39 am
content: 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..

author: Karel
author_rank: Super Contributor
timestamp: May 09, 2018, 06:36:32 am
content: Quote from: westfw on May 08, 2018, 11:09:05 pmIn 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.

author: imk
author_rank: Regular Contributor
timestamp: May 10, 2018, 04:22:53 pm
content: 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 10, 2018, 06:05:34 pm
content: Quote from: Karel on May 09, 2018, 06:36:32 amI 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.

author: Vasi
author_rank: Regular Contributor
timestamp: May 21, 2018, 04:04:29 am
content: Quote from: Howardlong on November 04, 2017, 08:45:15 amIf 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.

author: cv007
author_rank: Frequent Contributor
timestamp: June 19, 2018, 11:12:04 pm
content: 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.txtI 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.

author: cv007
author_rank: Frequent Contributor
timestamp: June 20, 2018, 06:55:35 pm
content: QuoteActually 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 specialAnyway, 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).

author: peterson
author_rank: Newbie
timestamp: June 21, 2018, 10:10:23 am
content: 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.

author: Karel
author_rank: Super Contributor
timestamp: June 21, 2018, 03:40:28 pm
content: Here's the download link to the source of the new compiler:http://ww1.microchip.com/downloads/en/DeviceDoc/xc32-v2.10-src.zipI 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/#msg1621915Here'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.hCode:/* 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_ERROR0x10/* something bad in supplied options - refer to stderr for details */#define MCHP_XCLM_INTERNAL_ERROR0x11/* internal error - memory, filesystem, network, ? */#define MCHP_XCLM_LICENSE_ERROR0x12/* no license available, or license expired *//* -liccheck */#define MCHP_XCLM_NO_VALID_LICENSE0x1#define MCHP_XCLM_SUBSCRIP_RENEWED0x2#define MCHP_XCLM_LICENSE_EXPIRED0x3#define MCHP_XCLM_LICENSE_RENEWED0x4#define MCHP_XCLM_DONGLE_LICENSE0x5

author: Howardlong
author_rank: Super Contributor
timestamp: July 22, 2018, 06:46:21 pm
content: cv007: xc32 v2.10, looks like there may be a couple of errors in the cc1/cc1plus Windows offsets inhttps://raw.githubusercontent.com/cv007/XC3216/master/xc32xc16-info-rev5.txtMay 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 0200000000000000File: cc1 Offset: 0x6c3410 Change: FFFFFFFFFFFFFFFF to 0200000000000000Furthermore, 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.

author: Howardlong
author_rank: Super Contributor
timestamp: July 22, 2018, 06:50:03 pm
content: Quote from: peterson on June 21, 2018, 10:10:23 amMany of us do exactly that, pretty much on almost a daily basis in my case!

author: NorthGuy
author_rank: Super Contributor
timestamp: July 22, 2018, 07:03:36 pm
content: Quote from: Howardlong on July 22, 2018, 06:50:03 pmI 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.

author: cv007
author_rank: Frequent Contributor
timestamp: July 23, 2018, 01:05:07 am
content: QuoteI corrected the Windows numbers for xc32 2.10, added xc16 1.35 info.QuoteSame as before, v1.35 offset is 0x161FEB. Tested.I would suggest using-https://github.com/cv007/XC3216/blob/master/xc32xc16-info-rev6.txtone 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.

author: Howardlong
author_rank: Super Contributor
timestamp: July 23, 2018, 08:08:11 am
content: Quote from: cv007 on July 23, 2018, 01:05:07 amI 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?

author: cv007
author_rank: Frequent Contributor
timestamp: July 23, 2018, 01:19:02 pm
content: QuoteRead 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.

author: Howardlong
author_rank: Super Contributor
timestamp: July 23, 2018, 07:33:33 pm
content: Quote from: cv007 on July 23, 2018, 01:19:02 pmOK, 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!

author: Howardlong
author_rank: Super Contributor
timestamp: October 03, 2020, 04:01:04 pm
content: Quote from: cv007 on July 23, 2018, 01:05:07 amAplogies 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:cc1.exe: error: target CPU does not support ARM modec:\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 directorycollect2.exe: error: ld returned 255 exit statusAre 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:*cc1:+ -mafrlcsj

author: hans
author_rank: Super Contributor
timestamp: October 03, 2020, 04:04:55 pm
content: 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.

author: cv007
author_rank: Frequent Contributor
timestamp: October 03, 2020, 06:01:36 pm
content: 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.

author: Howardlong
author_rank: Super Contributor
timestamp: October 03, 2020, 07:06:54 pm
content: Quote from: cv007 on October 03, 2020, 06:01:36 pmYes, 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.

author: cv007
author_rank: Frequent Contributor
timestamp: October 03, 2020, 08:37:43 pm
content: > Presumably it's simply an undocumented option outside of MicrochipIts 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).

author: Howardlong
author_rank: Super Contributor
timestamp: July 15, 2024, 09:33:30 am
content: Necroposting...Microchip recently released XC-DSC, and update for XC-16. For liberation, place the following file namedxc-dxc-specs(no file extension) to directoryC:\Program Files\Microchip\xc-dsc\v#.##\lib\Code:*cc1:+ -mafrlcsjI can confirm the previous v6 notes athttps://github.com/cv007/XC3216from cv007 still work on the latest XC32 (4.45) and XC16 (2.10).

author: Karel
author_rank: Super Contributor
timestamp: July 15, 2024, 04:14:24 pm
content: Quote from: Howardlong on July 15, 2024, 09:33:30 amwindows...?Stopped using that 21 years ago...

author: Howardlong
author_rank: Super Contributor
timestamp: July 16, 2024, 05:29:36 pm
content: Quote from: Karel on July 15, 2024, 04:14:24 pmWould that be the same time that you contracted a terminal case of sanctimoniousness? ;-)

author: fps
author_rank: Newbie
timestamp: September 18, 2024, 08:06:50 am
content: Quote from: Howardlong on July 15, 2024, 09:33:30 amIs there any method that can be used for XC8 on Windows? The XC8 method of cv007 seems to be invalid, and the relevant offset cannot be found. XC16 and XC32 can be used, but XC8 seems to be unusable.

author: voltsandjolts
author_rank: Unknown
timestamp: September 18, 2024, 09:41:07 am
content: The XC8 installer contains two compilers now, avr-gcc for AVR8 and the proprietary "XC8" for PIC8.The avr-gcc can likely be 'unrestricted' legally because it's an open source compiler."XC8" not so.

author: cv007
author_rank: Frequent Contributor
timestamp: September 18, 2024, 06:21:04 pm
content: QuoteIf using a PIC, you just use what they give you (xc8-pic). For an AVR, simply either download their gcc 'toolchain' version (a 'normal' but slightly old gcc version)-https://www.microchip.com/en-us/tools-resources/develop/microchip-studio/gcc-compilersor extract the toolchain from an arduino install executable or installation, then point MPLABX (assuming this is in use) to the new toolchain bin folder and you will have another choice for an avr toolchain.You are free to disassemble and modify the avr libexec executables to give you all optimization for xc8-avr (and since these are gcc files, you can modify all you want), but not worth the trouble in my opinion. For an avr you are better off using a 'normal/standard' version of gcc as the xc8 version diverges from gcc in various ways.

author: fps
author_rank: Newbie
timestamp: September 29, 2024, 08:16:21 am
content: Quote from: cv007 on September 18, 2024, 06:21:04 pmHello, thank you very much for replying to my question. I am using a PIC18F series microcontroller. My computer system is Windows 10 and I use the latest XC8 2.50 version of the compiler. The free optional optimization code is relatively limited. Since I am not using an AVR series microcontroller, is there any way to enable XC8 pro?

author: Karel
author_rank: Super Contributor
timestamp: September 29, 2024, 10:20:01 am
content: Quote from: fps on September 29, 2024, 08:16:21 amYes:https://www.microchip.com/en-us/development-tool/SW006021-SUB

author: westfw
author_rank: Super Contributor
timestamp: September 30, 2024, 08:08:25 pm
content: QuoteThe collective moral position here is that XC16 and XC32 are modified GCC (OSSW), and that therefore Microchip is "in the wrong" to be sending out artificially limited versions thereof. Therefore cracks and workarounds are OK and documented (and easy to figure out.)XC8, on the other hand, is legitimate closed-source proprietary/commercial software (even if that's really annoying), and "we" don't approve of "cracking" commercial software. (and furthermore, posting cracks might legally endanger EEVBlog.)

author: cv007
author_rank: Frequent Contributor
timestamp: October 01, 2024, 04:34:16 am
content: QuoteBe careful how you phrase that- the AVR half of XC8 is still using GCC, so the GCC executables are still governed by the GPL license so you can modify them all you want (but in contrast to XC16/32, you WILL have to modify the executables).

author: Ian.M
author_rank: Super Contributor
timestamp: October 01, 2024, 05:21:49 am
content: Microchip bought the Australian company HI-TECH Software, back in 2009 specifically to acquire their PICC C compiler for 8 bit PICs, killing off all other targets, to the disgust of the community. After in-housing the development team it became XC8, then became the XC8-pic component of XC8 after they in-housed toolchain development for their Atmel acquisition. It was *NEVER* FOSS!https://en.wikipedia.org/wiki/Microchip_Technology#HI-TECH_Software

author: Karel
author_rank: Super Contributor
timestamp: October 01, 2024, 07:43:02 am
content: Quote from: Ian.M on October 01, 2024, 05:21:49 amSorry, who said the XC8-pic component of XC8 was FOSS?

author: Ian.M
author_rank: Super Contributor
timestamp: October 01, 2024, 08:04:37 am
content: Quote from: Karel on October 01, 2024, 07:43:02 amNo one of significance. I suspect that those looking for cracks for it here don't care its not FOSS derived, but at least they no longer have the excuse of ignorance so can <expletive> off and leave this topic to those interested in exercising our GNU GPL rights to modify GCC derived XC compilers.

author: westfw
author_rank: Super Contributor
timestamp: October 01, 2024, 09:04:20 pm
content: It does make me wonder about the the state of libc for AVR XC8. Apparently XC8 no longer uses the OSSW avr-libc, but instead uses their own, "more conformant" and "functionally safer" libc ("Microchip Universal Standard Library": MUSL)I haven't looked for all the differences, but it did bite people when the initial versionsblew up floating point support(since fixed, supposedly)Questions to ponder:Do you get a different (more optimized) version of MUSL if you upgrade to XC8 Pro?is it "permissible" to set up avr-gcc (latest, from places other than Microchip) to use MUSL instead of avr-libc, avr-libm, etc?