CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

3.207 Bug !!
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Trampas



Joined: 04 Sep 2004
Posts: 89
Location: NC

View user's profile Send private message MSN Messenger

PostPosted: Sun Sep 05, 2004 7:20 am     Reply with quote

I guess I need to take the time to create the header file for my processors to use the bit feilds and unions. I wish the ones for the C18 would directly port to the CCS, or CCS used simular nomincalture.

The multiple C files do not bother me much either, but it would be nicer especially for porting code.

I think if I had to list the major problems I had with CCS they would be:

1. Compiler Crap shoot - you never know if a new version will fix more problems than it creates.

2. Error reporting - The error reporting and "linting" of the code has improved, but there is room for improvement.

3. Pointers to Functions - I though about this one in some detail. The problem CCS has it that it is almost impossible to optimize code using pointer to functions. To get around this problem CCS could make a requirement that pointer to functions are "const" that is a pointer to function is not changable and static. If the user wants to use a non constant pointer to a function, then the function needs to save state simular to an ISR routine, this of course has it own problems..

4. Intrinsic functions - The use of the #use and such is nice to get started quick, however I find that I usually end up making my own library for the peripherals rather than using the #use. So here again a libray might be better than the intrinsic functions. This will be come more apparent on the larger chips. I can see where saving a few bytes on the smaller chips makes it worth the intrisic calls.

5. Strings - One of the biggest complaints I have with the Microchip architecture is that they did not mapp the program memory space into the data memory space. They did on the dsPIC, which is a good thing. The problem this program and data memory creates is the constant string problems. That is the strings stored in flash have to be handled different than strings stored in data memory. Well I personally think CCS and the C18 can eliminate this problem on the PIC 18 parts by making the compiler place all the constant strings in flash above 0x1000 (limit of data memory) then in the string manipulation routines if the address is above 0x1000 the string is a program memory, else it is data memory. I actually wrote a printf routine for the C18 which does just this and it works well.

Again I think CCS is a great compiler! The optimizations are excellent, and for some of my applications I would not have been able to get them to market with out CCS! So Mark, Darren, and others you are doing a great job! Please realize that I am not complianing as much as I am trying to provide some valuable user feedback to help you improve the compiler.

Trampas
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group