Close

Myths and legends of PIC microcontrollers

jaromir.sukubajaromir.sukuba wrote 10/19/2016 at 09:03 • 4 min read • Like

I built this list, because sometimes I'm bored enough to write the same things again and again, so I have stable place to link.

1) PICs require awkward proprietary tools based on Windows, so you can't use it on Linux or Mac.

Nope, see points 2 and 3.

2) There are no free (as free beer) tools for PICs.

No, there are. XC compilers - for 8-, 16- and 32-bitters - are available for Windows, Mac and Linux. If you wish, you may also use their MPLABX IDE, available for all three platforms as well - at no cost.

Note those compilers are stripped down version of paid compilers. You have worse optimizations for compilers (IDE itself is unrestricted), but it is simplest way to start. On the other hand, the compilers are perfectly adequate for DIY use; from my experience the difference between full and free compiler in case of XC32, is something around 2-6% of code and 5% speed penalty for free version, though YMMV. I understand somebody may not want this, so here we go to point 3:

3) There are no free (as freedom) and open-source tools for PICs.

Again, no. You can go barebones and compile from command line on your raspberry pi zero with SDCC compiler for 8-bitters or vanilla MIPS GCC for PIC32. Both are open-sourced.

I used SDCC in my project #Micro progmeter where is also quick guide for setting up the compiler with MPLABX IDE, though you can omit the IDE part and use compiler only. For PIC16 and PIC18, there is also open-sourced programmer #Microchip PIC Arduino based programmer so you have fully free and open-source toolchain for 8-bitters. SDCC is used also in Pinguino project, which is Arduino derivative for PIC micros.

When it comes to PIC32, you can use compiler from MPIDE too, which is Arduino derivative for PIC32. I personally use free tools for PIC32 with retroBSD project (BSD Unix running on PIC32) which has also set-up guide in case you don't know how to build your own compiler. In the case you don't want to build your own, you have ready to go binaries here.

Also, check out this toolchain based on GCC 8 for PIC32.

4) PICs are 4x slower than AVR, because it has clock divided by 4.

Nope, because wrong terminology. When it comes to 8-bit PICs, they have not divided clock, but 4-clock core, so it needs 4 clock cycles to execute one instruction. 16- and 32-bitters are different story altogether and folks insisting on 4x slower PICs usually have no idea about it, which gives clue of their argument quality. So, while we agree that PIC needs 4 clocks for one instruction* and AVR only one**, the AVR usually ends up at 16 or 20MHz (=16 or 20MIPS), while PIC18 are going to 64MHz (=16MIPS), delivering approximately the same speed - definitely not 4x difference.

* and ** - only short instructions take 4 or 1 cycle respectively. For AVRs, you have a lot of two, three and even four cycle instructions. There are corner cases where one architecture has advantage over the another.

5) 8-bit PICs are nasty to program, with poor instruction set and banking and whatnot

8-bit PICs are barebones RISC architecture, which is human unfriendly by definition. If you are faint of heart, don't do it. With PIC18 and newer PIC16 devices, you are really occasionally forced to do any banking at all due to access bank (for direct variables) and FSRs (for buffers and arrays). I've done a few medium to larger (more than 5k lines of asm code) PIC18 projects and all of them NEVER touched bank select register except of single initial setting once after reset.

All this applies for programming in assembly language. Use compilers and you can forget it.

6) Microchip is closed source, hobbyist unfriendly, while other vendors are not

Welcome to the real world. Most of hardware vendors don't give a shit about open-source tools, though some of them are using it for their own advantage. In fact, hardware vendors don't give attention about YOU, hobbyist, unless you buy truckload of silicon every month. Atmel didn't give a flying fsck about AVR-GCC for years - read here. As well as Arduino was unnoticed for years, until they realized it is great way to promote them self and stick booth at every makerfaire. The debug protocols for AVRs are closed source, that's why you still don't have widely used and reliable open-source debug tools for AVR - and don't get me started about the Atmel Studio, Microsoft windows-only bloatware from Atmel. Situation is somehow better for ARM vendors (because ARM corporation has it's own requirements which has to be fulfilled by vendors), but point me out to the sources of ST-Link, please. Or LPC-Link. That's above the requirements, so no avail.

Microchip isn't generally better than this, though there are some efforts - it started with PicKit2, opensource (it started in 2004 or so, long before open-source was cool for MCU vendors) debug tool by Microchip. Unfortunately officially discontinued, but community around this is still vital, hardware is available and a lot of people use it. Another one is MPLAB Xpress loader.

But anyway, don't expect wonders from MCU vendors, they are producing hardware and expecting big money.

Like

Discussions

SHAOS wrote 10/19/2016 at 13:22 point

In early 00s (when Microchip didn't notice Linux at all) I used GPUTILS and some open source software to write into PIC chips through LPT on my Linux machine. And later I used PKLab as well. Even though Microchip is close and proprietary, they are pretty open from descriptive point of view - you can build your own compiler or programmer using publicly available documentation (many other vendors hide most of the specs).

  Are you sure? yes | no

danjovic wrote 10/19/2016 at 11:50 point

I had my struggles playing with SDCC and PICs altogether in Code::Blocks in Ubuntu, then I came to the following results:

- Ubuntu (14.04) prebuilt GPSIM package doesn't have support for GUI. You have to compile the sources manually to have GUI support.
- Codeblocks (12.something) requires configuration in global parameters when compiling for PIC. Then to switch back for another microcontroller you have to reconfigure the parameters again.
- 8 bit PIC header libraries are not included in Linux version of SDCC. You have to generate them manually (from assembly include files) running a perl script. I got errors running the script that I was not able to fix then copied the header files from the Windows version of SDCC

Besides all of the annoyances (of my particular setup)  I was able port some code generated by CCS C to compile on SDCC. The binary size was almost identical, indeed the SDCC code was some bytes smaller. I have wrote some notes about the port on a log of my retro keyboard emulator (https://hackaday.io/project/6140-tek-ps2-to-matrix-keyboard-adapteremulator)

My final opinion about Linux and 8 bit PICs? Yes!! perfectly doable!

What I miss more in Linux is an IDE or a text editor that can highlight PIC assembly code.

  Are you sure? yes | no

Stuart Longland wrote 10/19/2016 at 10:21 point

Is there an open-source simple command-line tool for downloading code into a PIC32?  I'm curious to have a look at them as on paper, they look alright, and are a nice alternative to ARM, especially since you can get versions of them in DIP.  (Yes, know about NXPs efforts, got a few LPC810s here and after trying one, was asking: "why did I bother?")

I've done MIPS cross-compilers before (former Gentoo/MIPS dev, still have my old SGI kit) however they're as good as useless if I can't go from .elf to image burned into flash.

AVR is dead simple, you can dead-bug a basic programmer from some transistors and a serial port if you're stuck for hardware.  LPC810, STM32 and AT91SAM aren't too difficult either, as all have RS-232 capable boot-loaders.  How does PIC32 compare?

  Are you sure? yes | no

jaromir.sukuba wrote 10/19/2016 at 11:17 point

Yes, there is pic32prog from @Serge.V - the same guy as behind the retrobsd project - https://github.com/sergev/pic32prog The pic32prog works with variety of hardware, including pickit2, available at usual sources for as low as 10 bucks, so FLASHing bootloader shouldn't be big deal.

PIC32 doesn't have residential bootloader in it, though you can buy PIC32MX250 with preloaded chipkit bootloader and there is a few other FLASH based bootloaders as well. But I agree having bootloader from factory can make life easier, sometimes. For development people usually prefer proper programmer anyway.

Loading PIC32 using parallel/serial port and few resistors is definitely possible too (as with AVR), but no one has done it. Programming specs are freely available, so I believe somebody would do that, if it was useful.

There is another PIC32 programmer, using JTAG port https://github.com/tekaikko/ardupic32 I didn't include it into list, as it seems somehow unfinished and slow, though it should be usable for burning FLASH based bootloader once.

  Are you sure? yes | no

esot.eric wrote 10/19/2016 at 12:57 point

I've been using openOCD with an FT2232H-based board... doable, but it did take some work.

I think (hope) I threw that info up at #operation: Learn The MIPS (PIC32MX1xx/2xx/370), otherwise I've got some work ahead of me ;)

@jaromir.sukuba, this is some good info. If you don't mind I'd like to link it there and at my PIC8 page, which for some reason people are following even though I declared it *far* back-burner.

  Are you sure? yes | no

jaromir.sukuba wrote 10/19/2016 at 13:10 point

Thank for link to your JTAG experiments - completely forgot about it, this is another way to go. Link this page as you wish, related info should be together - I assume it's this one https://hackaday.io/project/7529-operation-learn-the-pic-verrrrry-slowly

  Are you sure? yes | no

esot.eric wrote 10/19/2016 at 14:44 point

@jaromir.sukuba LOL Thanks for linking that... I completely forgot I renamed it to "verrrry slowly" ROTFL :) I should just delete the blasted thing... But at least it's a decent-enough place to add much-more-informative links like this page.

Oh, right, PIC32 is via JTAG... it's working pretty well. Documentation of how I accomplished it is... apparently sparse, and filled with "magic". My ability to recreate that... even less-likely. But I *am* using JTAG to program PIC32's pretty quick for nearly a year, now... so it's doable, and maybe my experience/scripts/diffs can help...

  Are you sure? yes | no

jaromir.sukuba wrote 10/19/2016 at 15:01 point

Right now I'm reading the projects log of the JTAG-PIC32 thingy and I must admit it is a bit convoluted, but I think it should be reproducible. 

But I'm genuinely inclined to try it, as soon as I find some FT2232 adaptor.

  Are you sure? yes | no

Stuart Longland wrote 10/19/2016 at 20:43 point

JTAG sounds great… I'm not sure if the two JTAG dongles I have can be re-purposed for this, one's a ST Link v2 and the other is an Olimex ARM JTAG.  My hunch is that it's mainly just connector differences, JTAG itself is an IEEE standard.

The first microcontroller I coded for was MSP430 and was using the FET-430 JTAG to program it: having the ability to set breakpoints, single-step and inspect values in memory really spoiled me, and is the biggest thing I miss going to AVR.

I'm working on that though (see #Open-source debugWire debugger), soon as I get more time I'll be putting one of my chips into debugWire mode and trying a few commands out.

  Are you sure? yes | no

Knudt wrote 10/19/2016 at 09:43 point

to 3) http://piklab.sourceforge.net/ its a Light IDE for PICs, Support the most Programmers OutOfBox

  Are you sure? yes | no

jaromir.sukuba wrote 10/19/2016 at 10:58 point

Oh yes, PikLab. I forgot to mention it - on the other hand, it looks abandoned. Definitely usable option, though.

  Are you sure? yes | no