Log onto the hi-tech support board and look for a long thread by me entitled "12 step program for CCS users" It details nuts and bolts the agonies and ecstacies of porting from CCS to Hitech C. http://www.htsoft.com/ Hitech Support Board There are several main Gotchas: 1. Words, ints, longs etc. are not the same number of bits from Hitech to CCS. I have started declaring "int8" instead of "byte" or "word" in CCS, because someday when I port it, this will translate correctly. An int is 16 bits in Hitech, 8 bits in CCS, IFIRC 2. Hitech's paradigm about Printf is different, and printf'ing will generate more PIC code bloat in Hitech than CCS. 3. Hitech has a minimalist attitude toward providing non-ansi functions. Other people have posted them around, things such as a packaged A/D function specific for the PIC. OTOH, CCS tries to support all the PIC functions, with various leves of success. If you are re-writing CCS's PIC specific functions over to suit your taste, you need to be using Hitech IMHO. 4. I was able to feel confident about porting CCS code to Hitech after a coupla days of head scratching. 5. Virtually all of CCS's PIC specific functions have to be hacked or re-written to port to Hitech. (stuff like read_eeprom(), set_pwm_duty_1() and so on. ) I ended up scrapping them and writing my own. There will be some code which would need extensive revision, esp. if you could not pull off a function that duplicates CCS' syntax exactly. Mostly I just wrote a function that uses the same syntax, so it could substitute. But not having infinite time, I would always end up with functions that only worked on one PIC, and maybe not others. OTOH, the effort put into this could make a nice little personal library. 6. Advice? You will probably be able to produce projects from here to eternity with either compiler. I've used (and cussed) CCS for maybe 4 years, and despite all the cussing I am still writing new projects with it. More than likely you'll stick with whatever you learn first. --Lawrence Lile ----- Original Message ----- From: "Mark Newland" To: Sent: Sunday, December 30, 2001 1:16 PM Subject: Re: Porting from one C compiler to another. > Thanks Dale and Gerhard, > > That kind of tells me what I needed to know. I don't actually have CCS yet but > getting tired of writing in assembler. Not that I hate writing in assembler and > am fairly familiar with it, it's just that I can see the speed / time advantages > in switching to C. I was hoping that I could get CCS now and upgrade to Hi-Tech > later when I can afford it a little more. Sounds like that may not be the best > option. Therefore, I can see my options as follows (someone feel free to add > more): > > 1) Buy CCS and deal with it. Assume that I will use it forever. > > 2) Buy CCS and write it for easy porting to HT later (that should be FUN, haha!!). > > 3) Buy something else such as FED which is "ANSI-C compilant" (or so they say) and > port over to HT from there. Altho I didn't see that it supports the 12-bit cores. > > 4) Bite my nails and wait for SDCC. Unfortunately, I have a customer (my first > one) waiting for his project > > 5) Go into debt and give Don (Hi Don!!) $750 and buy HT (kind of leaning towards > this way) > > The big issue here is not what is the best complier for the money. I have heard > many dicussions about this and the information was great, thanks. The question > that I have is more on being trapped to one compiler after I buy it. I haven't > seen many discussions about the portability of one to another. Compiler "X" may > be twice as good and half the price as compiler "Y", but is compiler "X" > compatible with anything else? Sounds like CCS is more like compiler "X" with > twice the functions at at a great price but as Gerhard said, it has a "... very > high non-compliance ..." compared to others. > > > Dale Botkin wrote: > > > Mark Newland said: > > > > > The last thing I want to do is create yet another holy war on the great > > > aspects of one C compiler over another. What I would like to ask is the > > > complexity involved with re-writing my old CCS code to someother > > > compiler such as Hi-Tech. I know that there is some work involved when > > > going to/from Microchips native assembly language (*.asm) and Techtools > > > CVASM (*.src) for instance. However, it is not beyond a little time to > > > do so. Would converting from my old CCS code to Hi-Tech be better, > > > worse, or about the same as going from a *.asm file to a *.src file? > > > > I've tried to convert code written for CC5X to CCS, from Hi-Tech to CC5X, and > > from Hi-Tech to CCS, with varying degrees of success. Going from anything to > > CC5X I had no luck due to the limitations of CC5X, though I understand it's > > much improved since I tried it. Going from Hi-Tech to CCS and back you will > > run into a couple of issues: > > > > 1. CCS has built-in functions that HT doesn't, so some code will have to be > > written/re-written from scratch. For example, with CCS I say: > > > > setup_adc(ADC_CLOCK_DIV_32); > > setup_ccp1(CCP_CAPTURE_RE); > > setup_timer_1(T1_INTERNAL | T1_DIV_BY_1); > > > > With HT I'd have to rewrite all that to set individual control register bits. > > I could probably actually write functions in an #included file and leave the > > original source untouched. If it's a lot of CCS code, though, you may find > > there are a LOT of functions you will need to write from scratch. Those > > builtin functions, as well as an extensive driver library, are a couple of the > > reasons I selected CCS... > > > > 2. I *think* -- and I'm sure someone will correct me if I'm wrong -- HT > > considers int to be 16 bits and short to be 8 bits, as opposed to 8 and 1 bits > > in CCS. I also seem to recall HT has no single-bit type (maybe booloean?). > > Some typedefs might be needed to get past this. > > > > In short, if you've used none of CCS' compiler-specific features, it may not > > be a real big job. Otherwise it would probably be more of a line-by-line > > rewrite than simply making a few minor changes. Still not too difficult, of > > course, they are both C. > > > > As for going from .asm to C source... rotsa ruck, never heard of an animal > > like that. It would seem that writing such a beast would be an order of > > magnitude more difficult than writing a compiler. > > > > Dale > > > > -- > > http://www.piclist.com hint: The PICList is archived three different > > ways. See http://www.piclist.com/#archives for details. > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. > > -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body