10/19/2016 at 09:03 •
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.
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 more »
12/27/2015 at 14:22 •
As probably a lot of folks here, I developed very slight hoarding disorder, known also as "impulsive midnight aliexpress shopping sessions" over the time I tinker with electronics. I buy stuff that goes into "messy box" and after a time I find out it is very valuable item that can help me with my project.
Now, when thinking about future development of my arduino PIC programmer I remembered that I bought K150 programmer somewhere, perhaps ebay or aliexpress. It is available for price as low as 5-6USD that is absolutely unbeatable, as usual for chinese suppliers.
Not just price is unsurprisingly here - build quality is usual too, though for home and laboratory use it is IMHO OK. Engineering is classic too - rip-off of western product, in this case it is kitsrus K150 programmer, with a touch of engineering - MC34063 added as step-up converter for generating Vpp for older PIC micros. The ebay sellers point to download software directly from kitsrus website, it is classic clicky-blinky kind of software
A bit of googling shows the software leaves a lot of to be desired and is not very friendly with other than Windows OS and as its development ceased some 8 years ago, with every new version of Windows, probability of its proper working decreases. Linux/Mac users are out of luck - though the screenshot above was done in Linux, it obviously can't connect to hardware.
There were some initiatives to bring this programmer to other than Windows platforms - searching for K150 I found this site, pointing to this unavailable site. Digging in history points out that author planned his marriage and new apartment, so this is where hobbies and other fun are gone. As Dave Jones says, trap for young players.
Looking at the original schematics I can see they made a few changes (MC34063 mention above, FT232 to PL2303 conversion), but I believe the firmware is still untouched original, so except of the few changes the target interface part is the same, so not much of reverse engineering is needed.
Not that I don't have plenty of PIC programmers at hand, but this is hackaday, isn't it? If I'd like to bring this programmer out of dust, I have three options:
- Use windows and the old software.
- Use whatever platform and python software from the link above. Running 10 years old piece of software may not be great fun and bringing new chips into it could be problematic - I'm poor Python programmer. But this is definitely and option. There is even sketch of communication protocol inside the package.
Oh yes, and there is even theoretical possibility of using USBASP compatible programmer for some newer PIC micros. I have to take a look at the sources.