MPLAB X a PIC inhibitor! Alternatives ?

[fourtytwo42]

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!!

[mikeselectricstuff]

Hello and once again thank you for your many comments and help, I think part of my problem is possibly my ancient laptop that however serves me well, it uses an Intel T2300 @ 1.6Ghz together with 2Gb of 980Mhz ram and of course a standard mechanical hard drive.

Upgrading to an SSD is a no-brainer these days. 
MPLABX runs fine on my Lenovo X220

[Howardlong]

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

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

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

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

[Ian.M]

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.

[TomS_]

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.

 

You owe yourself at least an SSD - memory swapping might not impose quite as much of a performance hit. Or at the very least more physical memory, if it can take more...

[eugenenine]

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.

[fourtytwo42]

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

[eugenenine]

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.

[Howardlong]

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.

[fourtytwo42]

I wasn't saying its a needs more ram problem, its an OS problem, boot under a Linux distro and try mplab x (or eclipse, or whatever) and see how much better it runs.

I am sorry I should have explained I have to many other tools etc built up over many years that are often windows only and dual boot whilst possible is an unnecessary complexity to me. I am not anti-linux, quite the opposite I have written kernal based code for it over the years but when it comes to my primary engineering PC other matters force the choice.

[fourtytwo42]

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

Its called DIY on a shoestring! I don't want the added £50+ per project for a pcb, nor do I want the extra size of a development board or breakout. 99% of my stuff is built on stripboard and is often compact.

[ebclr]

https://shop.mikroe.com/compilers/compilers-pic


Or move to ARM and get's a big list to chose

[Ian.M]

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

[ebclr]

" 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

[ebclr]

I like MikroElektronika because Pascal can be used, and I really like Pascal

[mikeselectricstuff]

" XC licences don't prohibit commercial "

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

That's only the case for XC8 ( and I think less so nowadays than it used to be). 
XC16 and XC32 are totally useable in free mode

[Karel]

" XC licences don't prohibit commercial "

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

That's only the case for XC8 ( and I think less so nowadays than it used to be). 
XC16 and XC32 are totally useable in free mode

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

[Bruce Abbott]

the so-called no optimisation of the free version, injects a lot of trash on the code,

Not exactly true. It's just that with no optimization XC8 doesn't take the trash out of the code.

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

Code: [Select]

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


Code: [Select]

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

Code: [Select]

/* blinky.c */
#include <avr/io.h>

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

Code: [Select]

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


Code: [Select]

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


[Howardlong]

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

Its called DIY on a shoestring! I don't want the added £50+ per project for a pcb, nor do I want the extra size of a development board or breakout. 99% of my stuff is built on stripboard and is often compact.

If it helps, I come from the same school.

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

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

[NorthGuy]

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

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

[westfw]

Code: [Select]

PORTB&=!0x01;

That code is incorrect, you know...  "!" is logical NOT.  You need "~" for bitwise NOT (thus producing somewhat "weird" code.)

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

[Howardlong]

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

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

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

[Bruce Abbott]

Code: [Select]

PORTB&=!0x01;

That code is incorrect, you know...  "!" is logical NOT.  You need "~" for bitwise NOT (thus producing somewhat "weird" code.)

You are right! (note: the PIC code was correct, I blame my keyboard!). When corrected the unoptimized avr code is even more bloated...

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

And the message is - expect idiots who don't know what they are talking about to damage your reputation.  Give people free stuff and all they do is complain about it! No wonder other vendors only offer time or code-size limited demos.

[NorthGuy]

But ... the damage to Microchip's reputation has been done, and I hope it sends a message to compiler authors everywhere.

And the message is - expect idiots who don't know what they are talking about to damage your reputation.  Give people free stuff and all they do is complain about it! No wonder other vendors only offer time or code-size limited demos.

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

[thm_w]

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

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

If only everyone was as thoughtful as you and listed their system specs when they claimed some modern software was "too slow".