I'm starting work with a new client, who's using a PIC processor. They've selected a C toolchain that, frankly, sucks. It's not ANSI, it's not apparent that I can build from the command line, and the compiler often starts mysteriously crashing. I was able to fix this the last time by reinstalling, but I don't know if I have the patience to continue doing that.
Its early enough in the project that we could change the tool chain with little or no pain -- but I've never worked with PICs to this depth.
So, have you programmed in C for the PIC lately, and if so, what tool chain did you use? Did you like it? Does it have many peculiarities (I understand that the PIC tends to induce peculiarities into a C compiler, which I'm willing to work with as long as I know what they are)? Can you build stuff from the command line, or are you stuck with an IDE?
Thanks in advance.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Posting from Google? See http://cfaj.freeshell.org/google/
"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
Back in the last century I was using a PIC, 16 something, and gave up on C for it. I switched to pure assembly, and could now keep track of things and pack the needed code into the space available. It was necessary to keep careful track of call stack depth. The compiler (forget which) was a small outfit who was very co-operative on doing something about bugs, but they were non-ending. I could accept limitations, but not bugs.
I have finally learned that last century is no longer the 19th :-) Took a while.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
I've put some 3-400,000 lines of PIC10/12/16/17/18 code through Hi-Tech's compilers over the last 10 years, in projects ranging in size from ~50 lines of code to ~30,000 lines of code. I've been happy with them. There have been bugs, but support is always responsive.
Given that the target platform, not too many. Recursion/reentrancy isn't supported, and the type of string literals is "const array of char" rather than "array of char." Other than that, it tracks ANSI well.
I use "make" exclusively. And they support Windows, Mac, and Linux.
I did a lot of PIC18 C programming a few years ago.
You need to ask yourself several questions:
do you really need to work in C? - the PIC12-PIC16 are not C-friendly; the PIC17 is a complete dog's breakfast, the PIC18 will *tolerate* a C compiler; the PIC24 and PIC30 are actually rather nice!
do you really need to work in ANSI-like C (i.e. do you actually need to port code to the PIC)!, or can you live with the C syntax and quirky semantics of some of the compilers?
The main limitations on a lot of PIC compilers are caused by the tiny register set and Harvard architecture of the devices. On the "not quite real C" compilers these typically manifest themselves as:
no reentrancy
no 'automatic' variables - the default storage class is 'static'
no unified pointer type to both code and data space
no 'constants in ROM' due to the pure Harvard architecture
A lot of people are OK with this; their code base is PIC only and they work with the quirks of the toolchain. They treat C as a higher-level assembler and don't get too hung up on portability, standards etc. I've encountered some low-level flak in this group before for criticising wildly non-standard C compilers - but my opinion has always been "if it works for you, go for it - please don't call it C though!"
When I was working on the PIC18 however we were dealing with a codebase that needed to be portable across a range of devices from PICS to 64-bit RISCS. For that you want a toolchain that works like the rest of the world... mostly ;)
The IAR compiler is the nearest to a 'conventional' C compiler I've seen on a PIC. At least on the PIC18 it works around the first three limitations (the unified pointer types are particularly hairy, involving a lot of runtime library calls, but they do work in combination with some hacks to put data into code space). You're *better off* if you think about how your code is going to be mapped onto the hardware, but you can mostly treat a PIC as 'just another micro' with IAR.
Microchip's own compiler moves too fast to characterise but it used to be a cheap'n'cheerful bought-in effort that they've improved themselves. They seemed to believe in 'release early; release often' rather than engineering a lot of bugs out of it.
pete
--
pete@fenelon.com "he just stuck to buying beer and pointing at other stuff"
The consensus seems to be for the Hitec C. I'll see if I can bring the client around to paying for it (reminding him that he can either pay me to reboot my machine or pay me to get work done may help).
To those who asked:
The problem child compiler is MikroC from Mikroelectronika, but we're transferring the registration from my client to me, and the bugs could conceivably stem from weirdo registration issues. So I'm going to give them another chance, but only one if I can help it (of course, if my client wants to pay me to struggle with the registration process...)
It's a PIC 18.
I understand the ANSI issues -- I probably shouldn't have mentioned them because the PIC, like the 8051, is quite hostile to the C virtual machine. Given that, you can't expect total ANSI compliance without a lot of overhead.
The application is really too big for assembly language, at least given that I don't have an extensive library of stuff already written. I'd much rather write in 'pretend C' than assembly, particularly if the client is going to have some other folks working on this (he may).
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Posting from Google? See http://cfaj.freeshell.org/google/
"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
Certainly the PIC sucks from the perspective of writing software. The hardware design seems solid, however. In addition, I have heard strong rumors that the PIC has many fewer delivery issues than some of its competitors. If I'm stuck between some private irritation over non-standard C vs. allowing a client to design in a part that he can't get when he needs it, I'll take the non-standard C.
Come to think of it, I think I'll ask about availability in a new thread...
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Posting from Google? See http://cfaj.freeshell.org/google/
"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
I'm not sure how well this will be recieved (in light of the many other responses you've had) but I like the PIC and I like the CCS compiler. It was inexpensive (compared to Hi-tech C) and it addresses many of the high-level functional interfaces available on the PIC (I2C, SPI, serial, PWM, etc). While it's true the compiler is not strictly "ANSI-C", it still works. A command-line is also available. I've used the compiler through several generations on several PIC12, PIC14, PIC16, and PIC18 projects ranging from the simple to the extensive. The compiler allows bit-oriented low-level accesses to registers, also. With the latest version of the CCS compiler, though, (version 4.001) they have made major cosmetic changes while providing no appreciable improvements in operation. I had it installed (briefly) and found it difficult to work with. I had major issues with the operation of the editor. Questions posted to their tech support went completely unanswered.
...my 2 cents...
Dave
Please remove the "AT" and "DOT" from the return address before replying. The return address has been intentional mangled to reduce spam.
It does not take too much lost time due to toolchain problems to have paid for a better toolchain. Cut your (or the client's) losses now. I have lost very little time over the past 10+ years with HI-TECH's products.
I would also second the vote for CCS. I've used it on PIC16 and PIC18 devices without any problems. The generated code is fairly well optimized and you can cram a LOT of code into a little 8K device. The built-in support for the peripherals is nice, so you can call a function like set_pwm2_duty(1023) without having to worry about doing the bit-twiddling yourself.
However I'm also using version 3.x and I have't tried 4.x yet. The only downside of 3.x is that it doesn't have a linker.
Cutting his losses is exactly what I want to do. I haven't quite spent enough time for him to buy another tool chain yet, but that would happen pretty soon if I continued down this road.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Posting from Google? See http://cfaj.freeshell.org/google/
"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
I third the CCS vote. It gets the job done with a minimal amount of hassle and a reasonable price. Just avoid using the strange length short, int, and long data types and stick with int8, int16, int32 and so on and life is good. As with any major update release, their tech support system has been a bit overwhelmed, but the Rev 4.XX has been working well for me. BTW, you get a full set of device headers (16F88.h for example) that are always being updated and a pretty good project wizard that will get a majority of the hardware setup from the get go.
I also use the CCS compiler and I like it a lot. But I have a complaint about those device header files. They are not complete. They do not include every Special Function Register. They include only the ones they think you will need, assuming that you will be using their library functions for digital I/O. For performance reasons, I often need to access the SFRs directly. It is easy to do in CCS C with functions like:
PORTA = 0x23; or bit_set(PORTA,6);
The trouble is they don't define PORTA or anything like it in their device header. I have to make up my own auxiliary header file to define the missing SFRs. It is not too hard, but I wish they had done it for me, like in MPLAB does for assembly language.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.