Choosing a PIC C compiler - Page 1
Forum section: electronics / general

author: djsb
author_rank: Super Contributor
timestamp: November 20, 2010, 05:45:25 pm
content: I'm having a debate at work about which PIC C compiler to adopt for class use. The undergraduate students I work with are not from a programming background and are studying Electronics as part of a degree in design.The compilers in the frame at present are HiTech C (included with Mplab and now owned by Microchip) and CCS PCB. We are using the PIC16F628/16F1827 and PIC16F877. The CCS compiler is the one I'm most familiar with but the HiTech compiler is free to use in it's Lite incarnation. Does anyone have any experiences with these tools and any advice they can give on making a good choice?Thanks.

author: migsantiago
author_rank: Frequent Contributor
timestamp: November 20, 2010, 06:14:02 pm
content: Hello, I have used both of them.CCS is kinda easy to use. It makes you forget any ASM code you should now. It's good for fast development, small ROM usage and has very good floating point calculations... they are done very quickly. CCS also has bugs, specific syntax bugs and calculations. A very important thing... CCS is not ANSI.HiTech Lite is so good. It does everything you need. It does not compile with optimizations, but it can work with PIC10/12/16 and beyond... for free.As a teacher,I'd use the HiTech Lite compiler. Students wouldn't have to pay anything. Besides, the bugs I've found in CCS are kinda tricky to be found... and you have to use a workaround to fix them or wait til the next CCS update appears.I always think that CCS is the Arduino of PICs. Easy to use, and you don't have to care (so much) about how the PIC works. But I do not recommend it because of its bugs.

author: Bored@Work
author_rank: Super Contributor
timestamp: November 20, 2010, 08:38:32 pm
content: It doesn't matter. You teach beginners, they don't need and can't appreciate the finer details. And if you are clever, you teach principles, not compiler / IDE specific rubbish knowledge.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 20, 2010, 09:00:07 pm
content: my bro in college, usually asked to burn the code in assembly without knowing anything about the code except its working. and he is still confused between C and basic, well OT. as long as it is C, they are all the same to me... more expensive the better though i think in term of support and update. the CCS is pre-installed in MPLAB i think, so that one is more accessible and easy i think.

author: .o:0|O|0:o.
author_rank: Regular Contributor
timestamp: November 20, 2010, 09:03:27 pm
content: Quote from: BoredAtWork on November 20, 2010, 08:38:32 pmPrinciples will always outlast IDE's, but sometimes lecturers are assigned the task of teaching a module on a subject they are not really qualified in (for budgetting reasons) and they just about get around to figuring out how to use the IDE with no actual experience designing anything with the devices they are teaching.The best way would be to teach the fundamentals of the chip's architecture with ASM so that the student has a clear "cause - consequence" understanding of how things work at the hardware level (tristates, interrupts, banks, addressing). If you abstract the programming process from the hardware you may as well be teaching a very poor course in programming.Once the basic operations have been taught in ASM, then you move on to one of the C packages in order to design more sophisticated programs..o:0|O|0:o.

author: djsb
author_rank: Super Contributor
timestamp: November 20, 2010, 11:27:48 pm
content: To clarify I'm only acting as an instructor in the labs I work in as a technician. I will have to work with whatever compiler is chosen and I hope to have some input/influence (if I'm listened to). The students are using assembly language now and may continue to do so, Im not sure. I suppose it's a matter of emphasis as most of the students are not pure engineering students (BA and BSc degree). The programming of the chips is a means to an end for them, the end being something they have designed, that just happens to use electronics. I suppose C once learned would help with productivity and make our jobs a bit easier (that's the theory).

author: .o:0|O|0:o.
author_rank: Regular Contributor
timestamp: November 20, 2010, 11:43:27 pm
content: I have used Hi-Tech C. I already knew ASM and C/C++ and didn't have difficulties learning it. There is a free limited version and there is a more complete version for commercial use.Hi-Tech C seems to be the most popular of them. This small review might give a sense of the differences:http://www.microchipc.com/reviews/Hi-Tech_C/I understand that there are also Linux equivalents which are supposedly free and not limited, but I cannot comment from experience. Would using a Linux version be an option?Perhaps someone more experienced than I could comment.Best of luck..o:0|O|0:o.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 21, 2010, 12:45:19 am
content: For teaching, Hitech is good as there is minimal setup - #include<pic.h> is all you need.And it doesn't matter that the code density on the free version totally sucks ass. Just don't try using it to teach how C code gets translated to the corresponding assembler..!

author: Murphy
author_rank: Regular Contributor
timestamp: November 21, 2010, 03:19:14 pm
content: Is code density with Hi-Tech Lite really that bad so long as you code with the processors capabilities in mind?I just recently switched from using assembly to Hi-Tech Lite on PIC 16s and it's been working great.It's ability to give intelligent error messages is kind of impressive. It keeps them short and sensible ... tells you exactly where you forgot the parenthesis or semicolon instead of just spewing 300 lines of garbage.Haven't heard of that other compiler, would definitely recommend Hi-Tech though especially since it's free.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 21, 2010, 03:33:21 pm
content: Quote from: Murphy on November 21, 2010, 03:19:14 pmthats called syntactic error, and common in every high level language. with assembly, u only deal with semantics (which is the big thing) error, the same to high level one. though you can generate stupid syntax error in asm. the garbage you are talking about, is created by you, not the machine. programmer's rule... GIGO

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 21, 2010, 04:12:41 pm
content: Quote from: Murphy on November 21, 2010, 03:19:14 pmYes it really is. It generates many completely unnecessary instructions - code size and execution time are up to 2x what they should be.The paid version is pretty good however.

author: TopherTheME
author_rank: Regular Contributor
timestamp: November 21, 2010, 04:47:04 pm
content: Quote from: mikeselectricstuff on November 21, 2010, 04:12:41 pmHow does it compare to the free or academic version of the standard Microchip C32 compiler? I would think that the Hitec compiler would be better than the status-quo even for the free versions, otherwise why would anyone ever use it?

author: Gary Servin
author_rank: Unknown
timestamp: November 21, 2010, 07:16:15 pm
content: Quote from: TopherTheME on November 21, 2010, 04:47:04 pmWith Microchip C32, C30 or C18 compilers you can't program PIC 10/12/16 MCUs. That's why we use it.

author: Simon
author_rank: Unknown
timestamp: November 21, 2010, 09:11:57 pm
content: there as also the compilers provided bywww.mikroe.comI use the basic one, I expect I better start learning C and I may then wander

author: dfnr2
author_rank: Regular Contributor
timestamp: November 22, 2010, 08:32:34 am
content: I have used both for commercial production code.I started out with CCS, and would have been happy to stick with it. However, their release process seemed really haphazard. They frequently introduced new bugs and regressions into their code, and the first seventy (no kidding) or so minor releases after a new release were almost unusable. That in itself would have been OK, if they kept a list of all the bugs and what was being done about them. But the process was really opaque, and I didn't know what direction things were going. Actually, the major frustration was that I was using Linux, and the linux version number always significantly lagged the windows version number even if important bugs were fixed, since the Linux version was only tested every few months.However, I will say that I never actually personally hit a compiler bug with CCS. I liked the fact that CCSC hid (most) all the ugly PIC warts, and provided really useful and simple interfaces to the peripherals, without complex libraries. I didn't like the fact that there was no linker, and you had to put (or #include) all your code in one file. I also carefully reviewed the assembly output to make sure the code did what i wanted.The above misgivings led me to research all the available compilers at the time (about 2005) and I bit the bullet and bought the Hi-Tech license. The ANSI-C compatibility was an attraction, but proves to be a red-herring, especially with the PIC, since I have never ended up needing to switch compilers mid-project; and even ANSI-C code is not necessarily portable when tailored to embedded systems. However, Hi-Tech appeared to be thoughtful with their releases; documented their bugs thoroughly in their releases; had a presence on their forums; and in general seemed more stable and professional. Also, they had a linker and better pointer capabilities (at the time.) Although getting a program up and running was a bit more of a chore, I have not regretted the move.For a student, or a classroom and teaching lab, I would probably go with CCS because of the greater ease in getting a program up and running, seamless built-in support for the range of PIC peripherals, and better insulation from the awkwardness of the PIC machine architecture. If they had a more confidence-inspiring bug management process (or at least listed the known serious bugs somewhere in a release note) I'd use this for commercial code as well.I wrote a summary in response to a question from a colleague a few years back, It's REALLY long, and somewhat out of date, since it describes CCSC v3 (v4 was still too unstable) and Hitech v8. I believe that v4 of CCSC adds multiple files, and #inline functions work better with Hitech v9.I have had developed production firmware with the CCS C compiler andwith Hi-Tech's PICC compiler. The following points may be helpful toothers deciding between the two. Below, CCSC is the CCS C compilerand PICC is the Hi-Tech C compiler.*) ANSI compliance and PIC-specific extensions. The CCS compiler hasnumerous extensions which are not ANSI compliant. These generallyabstract the PIC hardware and permit very easy use of theperipherals, particularly the serial devices. CCS also makesdelays very easy to include. If you don't use these extensions,and directly set up registers, then you can write code that is veryclose to ANSI C.It is best to write final code for ANSI C, in case you ever have toswitch compilers (for example, your vendor decides to get out ofthe compiler business, or your current compiler is terminallybuggy, or you switch to a different chip family, or SDCC starts tolook very good.) Also, it's often useful to compile with more thanone compiler, to flush out subtle bugs.Although use of CCS extensions limits your ability to port to otherPIC compilers, they are handy for rapid development. Theextensions reduce the risk of introducing bugs, abbreviate thecode, and are easy to follow. That makes CCS C very easy for firstcut or throw-away code.If you use the nonstandard features of CCSC, you do lose someflexibility. For example, serial I/O is unbuffered. If you wantbuffering, you have to write your own routine, just like for thePICC.Incidentally, John F. Fitter has prepared a file full of macros forHi-Tech C which provides macros emulating most of the useful CCSbuiltins (but not delays). It is posted athttp://www.eagleairaust.com.au. Hi-tech does provide macros fordelays, which I have yet to test for accuracy. In general, theefficiency of the code generated from these macros is as good asthe CCS built-ins. These macros make writing for Hi-Tech PICCabout as easy as writing for CCSC. They also facilitate portingfrom CCSC to PICC.Advantage: none (tie)*) Optimization. Both CCSC and PICC seem to optimize very well. PICCin particular is good at generating spaghetti assembly code withjumps that avoid duplicating common blocks. That means that youcan write clean readable C code, and get the performance ofunmaintainable assembly code that a professional human programmershould rightly avoid.Since CCSC is in constant flux, its optimizations may break yourcode on some compiler versions (see below.) Partly because of theability to specify inline functions, and partly because of somenon-ANSI behaviors, CCSC is able to optimize certain code better.I've seen very similar code quality from the two compilers.However, CCSC seems to change is optimizations frequently, andsometimes for the worse.Advantage: none (tie).*) printf(). Since Hitech has an ANSI-compliant printf() libraryfunction, it takes up a chunk of code space and is slightly lessefficient because the format string is interpreted in real time.CCSC parses the format at compile time, and includes only the coderequired to print the string. Not ANSI, but sufficient for mostapplications.Hi-Tech does provide an itoa function in the "samples" directory,which can be interspersed with puts() calls, but readability isreduced. Hi-Tech does provide library source, though. That meansyou are free to scavenge the routines you want from printf.Slight advantage: CCS C*) Inline functions. The ability of CCS C to compile #inlinefunctions means that you can still organize your code into readablefunctions without wasting stack space or function call overhead. Isuspect that #inline functions are a good part of the reason whyCCSC avoids libraries.Hi-Tech just introduced some inline capability to PICC. Thecompiler will attempt to inline short functions when possible. Ibelieve this doesn't apply to library routines or routines declaredin one module and called from another. I think it would bepossible to produce a specialized linker capable of placingfunctions #inline. Alternatively, libraries and intermediate filescould be maintained as assembly source, with inline functionsimplemented as macros.Advantage: CCS C*) Bank assignment. The PIC has a banked memory architecture. CCS Cmanages bank assignments, so you can forget about this detail. HiTech requires you to assign a bank to each variable. However, bankswitching is automatically handled for all subsequent variableaccess. While CCS is slightly more transparent, I don't think thatbank declarations are a big deal. In fact, selecting the bankgives somewhat finer control over bank switching, and may allow theprogrammer to improve efficiency by, for example, placing a queuestructure and its pointers in the same bank.Advantage: None (tie)3) Libraries. CCS does not support libraries. In part, this may beto avoid complications, like not being able to #inline libraryfunctions, or to permit certain other optimizations. However,#including multiple C source files in the main C source file is noteven similar to having libraries.A library can be compiled with a known good assembler or compilerand validated. Afterwards, there is no risk of introducing newbugs into the library with a bad compiler. There is no risk ofcompiler and preprocessor directives an definitions altering thecompilation. There is no risk of conflict between similarly namedstatic variables in two source files. It would be helpful even ifCCS C could just work with existing linkers and librarians, such asthose in the GPUTILS package.Big advantage: Hi-Tech C4) Release process & testing.It's hard to know what a company's internal development process islike. I've spoken with tech support people at CCS, Hi-Tech, andIAR about their bug-tracking, QA, and release process. This is mybest understanding. Perhaps someone can correct any errors:At CCS, there's an internal list of current reported bugs. Thedevelopers work on whittling down the list. When a bug appearsfixed, a test suite is run on the windows version. This consistsof a set of C code which must produce a certain output. The Linuxtest suite is run every few release versions. I don't know if thecompiler output itself is directly examined (that would requiremodifying and re-validating the test suite for every code generatorchange. Alternatively, perhaps the output is run on a simulator,and the simulator output is verified. Regardless, it is evidentfrom the release history that effective regression tests are notalways added to the test suite. Whatever they do, it doesn't seemorganized or complete enough to prevent showstopping bugs fromoccasionally appearing in releases. There's no good public list ofreported bugs, fixes, and workarounds. There's no list of whichcompiler versions have which bugs. And even if there were, it'shard to get older compiler versions. Professional CCSC users mustinspect the assembly output and not switch compiler versions oncethe code compiles and passes the validation suite. This probablyworks OK (I've used it for a critical project), but it is hard fordevelopers to sell clients on this process. The test & releaseprocess also doesn't inspire much confidence, given the bugs sooften found in even the supposed stable releases.Hi-Tech seems to have a more thorough testing and release process,with known bugs posted to their forum between releases. The ANSIconformance may actually simplify release testing, since thepreprocessor, C parser, and library code are completely separate,as is the linker. Also, since Linux is their development platform,the Linux version is on equal footing with the windows version.Big advantage: Hi-Tech. The haphazard CCS release process may be adealbreaker.*) Examples. CCSC comes with more (and better) examples, containingusable code for real-world applications. PICC comes with a fewexamples, but they are fairly anemic. Better to scavenge and adaptthe CCS examples where possible, and look to the archives athttp://www.piclist.comandhttp://microchipc.com. Really, the PICCsamples directory could stand to be beefed up with micro-examplesof real world use of peripherals with and without interrupts, andoptimization examples (for example, printf alternatives).Advantage: CCS*) Technical support. Surprisingly, I've never had to use CCStechnical support for compiler issues. The compiler is easy touse; the non-ANSI extensions do simplify coding; the manual isvery thorough; the code examples are comprehensive, instructive,and directly useful; tech questions posted to the forum are usuallyanswered very well (and searching the archive usually yieldsanswers without need for posting.) I have spoken with tech supportregarding their testing practices and their linux version, and Iwas quickly given useful responses.Hi-Tech technical support appears to be excellent. Their techsupport engineer monitors the Hi-Tech PICC forum, and providesdetailed responses to posts there. The promised turnaround timefor email support is 24 hours. I've found their support to beswift, accurate, and helpful. I've also spoken with tech supportabout their release and testing process, and their engineerprovided helpful information.Advantage: none (tie) by my experience. However, I get theimpression that Hi-Tech has more support engineers and is much moreactive.Conclusion and recommendations:CCS has advantages of convenient extensions, fine control of inlinefunctions, and a very good example code base. It will also allow youto basically write ANSI C if you want.Hi-Tech has advantages of a sane release process, better documentationof bugs and workarounds, use of a linker, and provision of librarysource. Hi-Tech has more active technical support engineers whomonitor the forums.The advantages of one compiler are nearly exactly the disadvantages ofthe other--they are complementary. I think that Hi-Tech is about asgood an ANSI compiler as you will find for the PIC.If you use CCS C, then you can get programs running quickly. However,you will need to be wary of compiler bugs. It's a must to have thesupport contract, and archive every released version of the compiler.Monitor the boards and build your own database of bugs & versions.Maybe the community can start a WIKI for this, and save time & money.Add a header file that #defines registers with the Microchip names,and use those names. Once you have a program written and working,start removing the non-ANSI extensions. If you ever need to switch toanother compiler, or if CCS decides to become fully ANSI, or get outof the compiler business, you'll be in good shape to switch.If you use Hi-Tech, then develop a set of #defines and libraryfunctions to simplify certain tasks, such as serial communication anddelays. John Fitter's macros are an excellent starting point. Ifprintf() takes too much space, then cannibalize the printf librariesto produce numeric output functions for single values, and use thesewith puts() to avoid including the printf() format interpreter.Overall, I believe that the Hi-Tech compiler is better suited forproduction code. The library support improves readability andmaintainability, and allows known good code to validated with lessrisk of contamination from subsequent compiler changes. The testingand release process inspires more confidence. The known bugs andworkarounds are much better documented.It may be a good idea to buy *both* compilers, using the examplelibrary from CCS to get jumpstarted. Build libraries of tested codeto bridge the gaps for ANSI compilers, and ANSI-ify your CCS code onceproof of concept is working. Run lint or lclint on the code. Breakyour code into modules, and built test frameworks for those modules.Make separate header files abstracting compiler-dependent #defines and#includes for CCSC and PICC, and Compile the code with both compilers,both with maximum warning level until all compile without errors. ThePICC library source is insurance for the future. For any project,check the appropriate library source into CVS. Also, document andcheck in the compiler you used to build your release version. Pay forthe support contract, at least for the compiler you end up using forproduction. Verify bugs and report them. Use the discussion forumfor your compiler.Also, it may be worth trying to compile your working ANSI code withSDCC, if only to subject it to another ANSI compiler. I discoveredseveral declaration bugs this way. If it chokes, report the bug.Look at the output, and see if the output looks right. If not, see ifit's easy to make it look right, and submit a bug report or a patch tothe maintainers. Contribute basic library modules. That way, once ofthese days there may be a free production-grade compiler that won't goaway, with a good bug-reporting system. If your current vendor dropsPIC support, or stops supporting your host platform (such as Linux),you may have a viable alternative, which already compiles yourapplication.

author: the_raptor
author_rank: Regular Contributor
timestamp: November 22, 2010, 10:17:49 am
content: Quote from: .o:0|O|0:o. on November 20, 2010, 09:03:27 pmI disagree. Teaching micro programming in ASM is just teaching a low level programming course. This is a course for design students to do something cool with electronics, not for EE/CS students to learn how micros work. The vast majority of programmers never ever need to touch ASM/machine code because the cost is very rarely cheaper than just using better hardware for the same benefit.You don't need to know (real) physics to do electronics, and you don't need to know low level programming to do micro/computer work.P.S. I am saying this as someone who deliberately took the low level programming courses at uni and spent some time doing hobby low level stuff. It is great for understanding low level computing but it is of very niche application.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 22, 2010, 10:34:35 am
content: i remember i started programming in fortran. for me its easy and interesting. due to passion i learn myself basic and then C and then assembly, it was not provided in our course. remember back the experience, i have to agree with raptor (even though, now i prefer asm for mcu). higher level languange is easier and can build interest among students, lower level will just discourage weaker students in the first class and promotes higher rating of failure in exam. even my colleagues, i cannot point a single person who continue the programming habit later other than myself!most of them are either failed in the fortran class or simply forget it after passing the exam.ps: i can imagine how a simple math a = b + c could turn into a series of movf, addf swapf etc codes in asm.... yucks! most people say.

author: Unknown
author_rank: Unknown
timestamp: November 22, 2010, 10:36:40 am
content: Quote from: the_raptor on November 22, 2010, 10:17:49 amSounds like the Arduino audience, basically. Not much point teaching them about low-level designs, I agree, just have them make something fun/useful, instead of spending an hour blinking a LED.Quote from: the_raptor on November 22, 2010, 10:17:49 amBut understanding assembler does sometimes make you a better programmer, because it gives you a clue about what the compiler is going to do. For debugging, it's also useful, especially when debugging optimized code (probably not an issue with these free compilers). But that's for the EE/CS crowd, not beginners.Quote from: the_raptor on November 22, 2010, 10:17:49 amYou don't need to know, but doesn't almost every EE curriculum in the world include an electricity & magnetism course?

author: Jon Chandler
author_rank: Frequent Contributor
timestamp: November 22, 2010, 03:45:25 pm
content: I have to agree with Raptor. Being able to make something cool work will get people hooked. These are not computer science students, but engineering students where in a one-semester course, learning about what's possible and having an overall view of what can be done is the key.You might consider Swordfish Basic. It's similar in syntax and construction to Visual Basic and will probably have a familiar feel to many students. The Special Edition is free but limited in the size of program it can generate, but trust me, many people never reach that limitation.From theSwordfish Web Page:Quote

author: .o:0|O|0:o.
author_rank: Regular Contributor
timestamp: November 25, 2010, 04:40:59 am
content: There has been a bit of healthy criticism relating to my point regarding the usefulness of understanding low level coding in ASM in relation to the MCU (or MPU) architecture.I agree that for most it isn't "necessary", but it gives the designer a clearer understanding of what is actually happening and of the limitations of the chip, which can be crucial for some designs that demand more from the finite resources available. Upgrading to a more expensive chip or board is sometimes overkill or not feasible, and there is something very rewarding about having mastered a device.It is also a matter of how you like to learn things: top-down, bottom-up or mixture of both. Personally, I always feel a bit uncomfortable unless I have a deeper understanding of what is taking place. The knowledge is usually transferrable.But I would say that people should always learn the way they feel most comfortable..o:0|O|0:o.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 25, 2010, 05:19:02 am
content: you are correct, about your point. the same thing with others, about their point on high level language for students.