Hi all, I'll put in my two cents here. I'm using the Bytecraft C. I've had awesome support from Bytecraft for the most part. The version I am running still has some major errors so often when code doesn't work I go looking at the generated code first to find the problem. In most cases it has to do with pointers. Moral of the story, don't use too much in the way of pointers with ByteCraft C. Having said that though, if you are careful about how you declare variables and organize so they remain in the same page, the ByteCraft C is quite close to hand coding assembler without the pain. But they also don't support 32 bit longs, a printf. When I have a project that needs that I switch to the ICC AVR compiler and one of the AVR devices. But I've digressed. The important part to remember is that any fancy function that does most of the work in one line of an HLL does it behind the scenes and that may hide some serious problems. I got caught the other day with an interrupt routine that went wah wah only occasionally. I had written some really nice, consise library functions for the SPI bus based MCP2510 CAN device. I also had a nice library for SPI based MAXIM 7219 LED controller. Since the interrupt routine needed the SPI bus I had the appropriate interrupts turned off during SPI bus access to avoid contention. Worked like a charm most of the time. Finally after many hours of searching through the code trying this and that I discovered that the wonderful set of libraries I built needed a 9 level stack during the interrupt routines. Considering the 8 level stack that the PIC has, well, need I say more. So out came the CheckSPIReady() call and the code was inlined into the function. There! A few more places and I'm no longer in danger of a stack overflow. I guess the point is that no C compiler for the PIC can be truly ANSI or even really C. It's at best a structured assembler with C syntax. Works well and costs my clients far less money than doing it in assembler except for time critcal code where every clock cycle is important. Regards, John > -----Original Message----- > From: pic microcontroller discussion list > [mailto:PICLIST@MITVMA.MIT.EDU] On Behalf Of Paul Hutchinson > Sent: Wednesday, March 20, 2002 10:39 AM > To: PICLIST@MITVMA.MIT.EDU > Subject: Re: [PIC]: displaying a value on LCD > > > > -----Original Message----- > > From: pic microcontroller discussion list > > [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of michael brown > > Sent: Tuesday, March 19, 2002 11:23 PM > > > I have to say that I must agree. They should have created a new > > function name, they absolutely positively should NOT have done what > > they did. What C compiler is this? How many other things did they > > mess up? > > I believe the compiler is CCS PIC C and, a lot of things are > different than standard C's. It is closer to K&R C than ANSI > C but... As someone else on the PICList said a while back > (can't remember who) "it's a rapid development language with > a C like syntax". That pretty much sums up my feelings about CCS C. > > IMHO, CCS C is the worst compiler to use when learning C. > > Paul > > -- > 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.