[sdiy] PIC Re: how you got started with your current µC? (was: Re: Most common ICs)

[rsdio at audiobanshee.com]

On Sep 20, 2015, at 1:05 AM, Thomas Strathmann <thomas at pdp7.org> wrote:
> BTW, how is the situation of using C on PICs (or dsPICs for that matter)?

Others have already provided fine answers to your question, but I wanted to add a few details.

The older, Microchip C18 compiler is quite usable. I've never been forced to do strange things in C to get the code to compile or interface with assembly. There were a few times that I caught the optimizer making choices where I thought I could do better, but it turned out that all I had was a different way of calculating the same result, in the same number of cycles, but using different opcodes. That's not to say that the C compiler was always better than hand-assembly, but that it was fairly smart. I briefly tried the performance of the licensed version, which supports the special opcodes in slightly older PIC18 chips intended for making Standard C easier, but I was focused on total code size and it didn't seem to make the code any smaller. It's possible that the licensed version had advantages, but I did not find them during my trial period. Although the C18 version is old and probably no longer supported, at least not actively, it's a fine choice.

The new XC8 compiler, which became Microchip's when they purchased HI-TECH, is quite advanced, but difficult to tame. I've had many examples where the compiler failed to work, mostly because I need to support some assembly language code and place specific variables in the Access Bank. Overall, the compiler is worth learning and using, but it's not easy. I think that the HI-TECH design approach is probably better, in the long run, for such a strange architecture as the PIC, but that doesn't mean it will be the best choice for beginners. I've yet to license this compiler, but my current opinion is that you should probably considering purchasing the compiler as a necessity. There is at least one article online about how poorly the free, unoptimized version works.

With either compiler, it's a good idea to use the MPLAB feature that allows you to view the assembly output, which has your C source as comments. This can give you an idea of how much you're using of the limited PIC resources, and how well the compiler is working with your coding style. As I've mentioned, I nearly always write the interrupt handlers in pure assembly, because it's usually possible to cut the number of cycles in half, or better, compared to a C language interrupt routine. Of course, a lot of this performance is due to design and organization of the code, rather than brute optimization.

The most advanced C compiler I know about is from Texas Instruments, for the TMS320 DSP. It will actually remove function parameters if they're always constant, and use efficient immediate opcodes to handle the constant values. This allows for the portability of C and ability to support different channels or instances of peripherals without the overhead of parameterized object code where no variations are actually needed. I have a hunch that Microchip's XC8 gets fairly close to that in terms of advanced techniques in optimization. Firmware is not really easy, and the best tools are not always easy, either.

That said, I would not recommend the PIC as a first choice for anyone. There are certainly reasons to choose it, and if you must use the PIC then you can certainly get the job done. It's not even the worst platform I've used, when you consider the compiler, examples, libraries, maturity, stability, documentation and support. For that reason, I avoid making too strong of a criticism, because I know how bad it could be.

Brian Willoughby
Sound Consulting