Post by thread:PIC C compilers

Andrew Warren - spam_OUTfastfwdTakeThisOuTix.netcom.com said: Maybe I should just keep re-posting my "MPC is the only C compiler suitable for professional software development" message until it finally sinks in... Maybe, but that doesn't mean it needs to be. A C-compiler aimed at generate byte-codes similar to what parallax uses in the basic stamp might be a lot easier. A pascal compiler easier still (Since it's been done - remember p-codes?) Personally, I'll side with the guy who thought trying to program a PIC in C was silly. Sorta like trying to reprogram your video game machine in smalltalk. The sort of C program that fits in a couple K of memory on a machine with no stacks or pointers could equally well be written in any high level language. There might be portability reasons for writing C code without pointers or stackframes or printf or any of that stuff, but the resulting code would end up so PIC specific anyway, there wouldn't be much point. Structured assembler anyone? [So, I haven't introduced myself yet. I work for cisco Systems, the networking company, writing code in C. Before that I was a dec-20 assembly programmer. I like assembly. I thought I wanted to be a EE, but I got into microcontrollers in about 1976 (in highschool), when I realized that nearly every electronic project I had ever built could have been equally easilly programmed in the RCA1802 system recently published in popular electronics. In college I chased microprocessors, noting what was neat about each one. I wrote a simulator for the 8085, and for a senior project code for an SDK-86. Sadly, few of the newer processors are "neat" in the same way that they were in the heyday of the 70s and 80s - now everything is designed with the fact that a compiler is going to hide all the gross stuff from the user. Except microcontrollers. Some of those are still neat, perhaps driven by the need to write programs in finite memory space. While older microcontroller systems might have replaced electronic projects, the new low pin count controllers might well replace any number of individual chips. That's neat too. I've got a PICstart on my shelf, awating attention. And an 82750 kit too. I want to play with them, and perhaps put them in model rockets. When I get time...] BillW

Greetings all. I'm sure this message has come up before (sorry about that) but I couldn't find any information to answer my question in any of the online FAQs/WWW pages/etc...so here goes. What is the best C compiler for the PIC, for the price? I've found information on two different compilers, one from Byte Craft and the other from Custom Computer Services. The main difference that I can see is the cost. $795 vs $100. Anyone out there have experience with these compilers? Any reason why I shouldn't buy the compiler from CCS for a hundred bills? ----- o----------------------------------------------------------------------o | James C. Baughman | | | | Applied Research Laboratories .....jbaughmnKILLspam@spam@mail.utexas.edu | | University of Texas, Austin Home: (512) 836-3272 | | Work: (512) 835-3633 Mobile: (512) 923-9418 | o----------------------------------------------------------------------o

On Wed, 6 Dec 1995, Jim Baughman wrote: > Greetings all. I'm sure this message has come up before (sorry about that) > but I couldn't find any information to answer my question in any of the > online FAQs/WWW pages/etc...so here goes. > > What is the best C compiler for the PIC, for the price? > > I've found information on two different compilers, one from Byte Craft and > the other from Custom Computer Services. The main difference that I can > see is the cost. $795 vs $100. > > Anyone out there have experience with these compilers? > > Any reason why I shouldn't buy the compiler from CCS for a hundred bills? Depends... If you're compiling for the PIC16C84, you could use the *FREE* C compiler "pic_cc" available in source code from the GNUPIC archive: http://www.execpc.com/~digalog/.magic/address.html It's only good for the PIC16C84, and requires you to use Parallax's PASM (pseudo-8051-style assembler) under DOS, but it works. Rick Miller, Design Engineer (and local "Internet Guy") Digalog Systems, Inc. <rickKILLspamdigalogsys.com> 3180 S. 166th St. <.....Rick.MillerKILLspam.....Linux.org> New Berlin, WI 53151 USA +1 414 797 8000 x-228

> Date: Wed, 6 Dec 1995 09:46:09 -0600 > From: Jim Baughman <EraseMEjbaughmnspam_OUTTakeThisOuTMAIL.UTEXAS.EDU> > What is the best C compiler for the PIC, for the price? For my money, it was the MPC. > I've found information on two different compilers, one from Byte Craft and > the other from Custom Computer Services. The main difference that I can > see is the cost. $795 vs $100. Quite a bit more to it than that. The ByteCraft MPC supports all PIC's, you need two compilers from CCS, so the comparison should be $200 <-> $795. The way either compiler does the nitty-gritty stuff is different, so you can't easily support both with one source code. The MPC is _much_ more robust, and fits better into an experienced developers work environment. > Anyone out there have experience with these compilers? I've used both. There's a difference, indicated by the prices. If you can afford it, get the ByteCraft. > Any reason why I shouldn't buy the compiler from CCS for a hundred bills? The first one that comes to mind is that it may not do what you want, rendering the $100 spent wasted. I resent the time I wasted on it more than the cash. Of course, I wasn't targetting the 16c84, so the free ones (which weren't widely available 9 months ago) weren't an option then. Check them out. Tim Braun | Voice: 204-942-2992 ext 228 Continental Healthcare Systems Canada | FAX: 204-942-3001 1900-155 Carlton St | Email: timspam_OUTchs.mb.ca Winnipeg, Manitoba, Canada R3C 3H8 | www: http://www.chs.mb.ca/~tim/home.html

{Quote hidden}>On Wed, 6 Dec 1995, Jim Baughman wrote: > >> Greetings all. I'm sure this message has come up before (sorry about that) >> but I couldn't find any information to answer my question in any of the >> online FAQs/WWW pages/etc...so here goes. >> >> What is the best C compiler for the PIC, for the price? >> >> I've found information on two different compilers, one from Byte Craft and >> the other from Custom Computer Services. The main difference that I can >> see is the cost. $795 vs $100. >> >> Anyone out there have experience with these compilers? >> >> Any reason why I shouldn't buy the compiler from CCS for a hundred bills? > >Depends... If you're compiling for the PIC16C84, >you could use the *FREE* C compiler "pic_cc" available >in source code from the GNUPIC archive: > > http://www.execpc.com/~digalog/.magic/address.html > >It's only good for the PIC16C84, and requires you to use >Parallax's PASM (pseudo-8051-style assembler) under DOS, >but it works. Just a couple of questions (I'm also not sure if this will show up in the discussion group, so if it isn't passed thru it, please let me know and I'll resend it) with regarding to using the "C" language with the PIC. I've been toodling around with '84s for the past little while and I'm curious to understand how any "C" implementation works, because I would have thought the overhead required (both in Space and Execution Time) for the language would seriously affect any applications. I haven't used any of the "C" implementations mentioned, so the questions probably would be answered just by looking at the packages. How do the Compilers handle the various ports and functions within the PICs? I would guess the true "C" way of doing things would be to write a library (in Assembler?) and then call it from the main program. With regards to functions, how does the compiler pass arguements back and forth? This is a huge question because there is also the problem of pointers and structures based on the pointer. Non of the PICs have a stack pointer, so the passing of data can be tedious/dangerous (in terms of getting overwritten). Are reenterant functions allowed? How are Interrupt Handlers handled? I know from personal experience that there is more to an Interrupt Handler than just having the code starting at address 4 and ending with a "retfie". How is the status and w registers handled? And lastly, what type of data types are available and how are they manipulated by the language? I would expect the space used for anything greater than 8 bits to be a problem because of the space required for the operation. Thanx for your answers, Myke Predko

> How do the Compilers handle the various ports and functions within the PICs? > I would guess the true "C" way of doing things would be to write a library > (in Assembler?) and then call it from the main program. That would be a common method. I think the preferred method of handling things like integer math in C would be to have a couple registers reserved as an "integer accumulator" and have functions like [add int acc. to memory pointed to by FSR/W [function would have two entry points; the first would start with "MOVWF FSR" and fall through to the second]. For expressions which need more than one integer accumulator, turn the others into local variables [see below] > With regards to functions, how does the compiler pass arguements back and > forth? This is a huge question because there is also the problem of > pointers and structures based on the pointer. Non of the PICs have a stack > pointer, so the > passing of data can be tedious/dangerous (in terms of getting overwritten). Preferred approach I've seen on micro compilers is to have functions' argu- ments allocated statically using a call-graph to overlay variables [e.g. if function main calls foo and bar, neither of which calls each other, and all three functions have two byte-variables named main_i, main_j, foo_i, foo_j, bar_i, and bar_j, then a total of four bytes need to be allocated: one each for main_i and main_j, one shared between foo_i and bar_i, and one shared between foo_j and bar_j. Note that on many compilers the variables for a function must be located sequentially; this sometimes limits what the linker can do with allocation. For something like a PIC, it would be better if a compiler/linker could sub- divide functions into zones depending upon which variables were alive/dead, but I don't know if any do. Parameters on such compilers are defined as local variables, and are written to directly by the calling procedure. A variable argument list is defined as an array of char [of compiler-option-settable length] which is filled in by the calling procedure. > Are reenterant functions allowed? Generally not. > How are Interrupt Handlers handled? I know from personal experience that > there is more to an Interrupt Handler than just having the code starting at > address 4 and ending with a "retfie". How is the status and w registers > handled? Pretty much as you'd expect; the compiler creates standard prologue/epilogue code. For the PIC, you may get lucky and have a compiler skip, e.g., the saving of the status register, if nothing in the code affects status. I'd not expect such a thing, however; if your interrupt procedure consists only of, e.g., incrementing a counter I'd expect the compiler to generate [nb: code to reset cause of interrupt elided: .org 4 movwf WSAV swapf STATUS mofwf SSAV incfsz Timer goto $+2 incf Timer+1 swapf SSAV,w movwf STATUS swapf WSAV movf WSAV,w retfie rather than the [shorter and faster] .org 4 incfsz Timer goto $+3 incfsz Timer+1 nop retfie > And lastly, what type of data types are available and how are they > manipulated by the language? I would expect the space used for anything > greater than 8 bits to be a problem because of the space required for the > operation. Any decent micro compiler will support at least 16 bits decently [a 16-bit add translates as: movf Source,w addwf Dest btfsc C incf Dest+1 movf Source+1,w addwf Dest+1 [Saves time: 6 instructions; 6 cycles] or possibly as: movlw Source ;[address of] call Load16 movlw Dest call Add16f Load16: movwf FSR movf IND,w movwf AccL incf FSR movf IND,w movwf ACCH return Add16: movwf FSR movf IND,w addwf AccL btfsc C incf AccH incf FSR movf IND,w addwf AccH return [Saves code if many adds are used: 4 instructions per add; 24 cycles execution]

At 06:14 PM 1/9/97 -0500, you wrote: >I'm looking for an inexpensive C compiler for PIC processors. Has anybody >had any experience with the CCS compiler. I'm looking at the 14 bit >compiler (PCM). Are there any others worth considering. > >Eddie Starling >Telephonics Corp. >(516)549-6066 >RemoveMEedstarTakeThisOuTsw.telephonics.com > > I've developed a number of projects on the CCS compiler, I like it. Its the only PIC 'C' compiler I've used. At the time I bought it, cost was a issue for me as well. Since them I've talked with ByteCraft a number of times and they haven't been able to give me any compelling reason to 'upgrade' to their compiler. Cost wouldn't be much of a issue at this point so I think that might say something about the CCS compiler. The one I have used the most is 'PCB' which is for the 5x core. I also own PCM but haven't used it a whole bunch yet. Good luck Regards, ------------------------------------ | Jeff King Aero Data Systems | | spamBeGonejeffspamBeGonemich.com P.O. Box 9325 | | (810)471-1787 Livonia, MI 48151 | |F(810)471-0279 United States | ------------------------------------

You should have a look at the CC5X C-Compiler. This compiler supports the 12-bit and 14-bit PIC core. It integrates 100% with MPLAB. This is (as far as I know) the oldest PIC C-compiler available (i.e very well debugged). CC5X will also generate the most compact code, and reuses RAM whenever possible. This is the main advantage of this compiler. When most compilers have filled up your ROM, CC5X may be able to generate the same program in 2/3 of the space. The most frequent question from customers, is how to implement inline assembly... This is something that is not possible, and you don't need it. The reason for using inline assembly is usually to make sure a routine executes in a precise number of instructions, or to make a piece of code very compact. CC5X will generate precise assembler instructions if you want it to. Delays can be written in C with the accuracy of assembler programming. Try any internet search-engine, and search for CC5X. One of the pages should be the "Ormix page" which holds a more or less new demo version. Another page also contains a PIC C-compiler comparison test. Regards, Dag Bakken ______________________________ Reply Separator _________________________________ Subject: PIC C compilers Author: Eddie Starling <TakeThisOuTedstarEraseMEspam_OUTSW.TELEPHONICS.COM> at Internet_Exchange Date: 09.01.97 18:14 I'm looking for an inexpensive C compiler for PIC processors. Has anybody had any experience with the CCS compiler. I'm looking at the 14 bit compiler (PCM). Are there any others worth considering. Eddie Starling Telephonics Corp. (516)549-6066 RemoveMEedstarTakeThisOuTsw.telephonics.com

Eddie Starling wrote: > I'm looking for an inexpensive C compiler for PIC processors. Has > anybody had any experience with the CCS compiler. I'm looking at the > 14 bit compiler (PCM). Are there any others worth considering. ... and Dag Bakken <PICLISTEraseME.....MITVMA.MIT.EDU> replied: > You should have a look at the CC5X C-Compiler. This compiler > supports the 12-bit and 14-bit PIC core. But not the 16-bit core. > This is (as far as I know) the oldest PIC C-compiler available (i.e > very well debugged). While the compiler itself has very few real bugs, the libraries included with it (which are the most compelling reason for anyone to buy the compiler) often DO have serious bugs... New revisions of those libraries seem not to be tested very well by CCS before they're released. > CC5X will also generate the most compact code, and reuses RAM > whenever possible. This is the main advantage of this compiler. > When most compilers have filled up your ROM, CC5X may be able to > generate the same program in 2/3 of the space. It's important to note that: 1) CCS doesn't use any high-powered optimization algorithms or anything... The compactness of their generated code is due almost entirely to the fact that the compiler only supports a "Baby-C" subset, limited to the operations that are DIRECTLY supported by the PIC instruction set. 16-bit math, for example, is not directly supported; in fact, the compiler doesn't even support SIGNED math. 2) The CCS compiler doesn't really generate code that's all THAT compact, anyway. Here's a simple example of optimization failure: byte1 = x; byte2 = x; byte3 = x; In this case, the compiler produces: movf x,w movwf byte1 movf x,w movwf byte2 movf x,w movwf byte3 The trivial optimization that the compiler misses is, of course: movf x,w movwf byte1 movwf byte2 movwf byte3 "A-ha!" you say, "But what if 'x' is an I/O port? In THAT case, the optimized code might be inaccurate." Well, ok... But shouldn't a compiler written specifically for the PIC know the difference between an I/O port and a general-purpose file register? I mean, really... Besides, when the compiler's given: byte1++; it compiles it to: movf byte1,w incf byte1 What's up with THAT? > The most frequent question from customers, is how to implement > inline assembly... This is something that is not possible, and you > don't need it. You DO need it, and it IS possible... To write inline assembly, just bracket your assembly code with #ASM and #ENDASM directives. I know that Eddie didn't want to spend a lot of money, but if anyone else on the list is looking for a "real" C compiler, I recommend MPC and MPLAB-C. -Andy === Andrew Warren - EraseMEfastfwdix.netcom.com === === Fast Forward Engineering - Vista, California === === === === Did the information in this post help you? Consider === === contributing to the PICLIST Fund. Details are at: === === http://www.geocities.com/SiliconValley/2499/fund.html ===

---------- > From: Andrew Warren <RemoveMEfastfwdEraseMEEraseMEIX.NETCOM.COM> > > It's important to note that: > > 1) CCS doesn't use any high-powered optimization algorithms or > anything... The compactness of their generated code is due > almost entirely to the fact that the compiler only supports > a "Baby-C" subset, ... > Thank you Andy for the heads-up on CCS. I have never, in all the discussion, ever heard this on the PICLIST about the CCS compiler. Are any of the PICsters C programmers? > > I know that Eddie didn't want to spend a lot of money, but if > anyone else on the list is looking for a "real" C compiler, I > recommend MPC and MPLAB-C. > Our perspective is one of writing production code in RAD environment. We have extensively used the MPC compiler (MPLAB-C as of release last summer was a frozen, prior version of MPC according to ByteCraft). Although Walter Banks et al at ByteCraft are really good people with outstanding tech support, we are disappointed with the 18,000 versions of the MPC product. I have not tried the latest v1.20 of the linker equipped MPC. Has anyone used the MPC compiler with linker? (PS Walter, if your listening, I know it must drive you crazy to try and write a C compiler for a chip that is so resource limited as the PIC; Microchip can't even do it)

James Musselman wrote: > > I have not tried the latest v1.20 of the linker equipped MPC. > > Has anyone used the MPC compiler with linker? > > (PS Walter, if your listening, I know it must drive you crazy to try and > write a C compiler for a chip that is so resource limited as the PIC; > Microchip can't even do it) Thanks for the comments. Its tough to write a compiler in public for processors that did not have an existing high level language and processor family that had many major variations. V1.20b that was sent to all our registered users at the end of the summer was was designed to stabalize the MPC compiler and the process. In parallel to the V1.20 release we had another project working on additions to meet the needs of application developers. Walter Banks http://www.bytecraft.com