 |
 |
| View previous topic :: View next topic |
| Author |
Message |
pic_user
Joined: 25 Aug 2005
Posts: 16
|
| PIC24F compiler problem |
 Posted: Thu Aug 12, 2010 12:42 pm |
 |
|
I have been running a program for the PIC18F for a long while. I need to use the PIC24F so I bought the PCD compiler. I have had problems with it.
The test case is a small program that defines a ROM array with some ascii characters, assigns a pointer to point to the array. When I look at the value pointed to it is not correct.
The code:
| Code: | #include <24FJ64GA102.h>
//#include <18lf24j11.h>
void main()
{
char ASCII_CODE;
ROM char *char_ptr;
ROM char ccs_ASCII_mess[20] = {"Hello"};
char_ptr = &ccs_ASCII_mess;
ASCII_CODE = *char_ptr;
while(1)
{
}
} |
When I ran the compiler with the PIC18 part, I correctly get ASCII_CODE = 0x48, which is the code for an 'H'
When I ran the compiler with the PIC24F part. I get an ASCII_CODE of 0xff.
Could someone please validate for me? |
|
 |
Gary Smithson
Joined: 13 Feb 2004
Posts: 22
|
|
| Posted: Thu Aug 12, 2010 7:12 pm |
|
|
I have ported about 4 projects from PIC18 to PIC24 and each and every one of them were, and still are, excruciatingly painful.
For example I reported 7 bugs yesterday just after 4.110 was released.
Credit where credit is due; communication has improved between myself and CCS and 4.110 did fix about 5 bugs I had reported since 4.109, but PCD is still no where near the product that PCH is.
Just by glancing at your code I can assure you that what you are experiencing is a PCD bug. About all you can do is report it and find a work-around until CCS sends you a beta (you'll have to ask for it) or they release 4.111.
Gary |
|
|
pic_user
Joined: 25 Aug 2005
Posts: 16
|
|
| Posted: Fri Aug 13, 2010 9:48 am |
|
|
This is the second bug I reported since I bought PCD a week ago.
Quite frankly I am not impressed, and I feel I was defrauded since I paid for a product that is unusable. Surely the inability to use a pointer to a ROM-based array shows that the product is brain dead. And yet, getting appropriate attention from CCS has failed.
I am now in the process of moving over to C30. Using the test case code from the first bug, the code from C30 was not only correct, but substantially smaller in size.
My preference was to not have to learn the idiosyncrasies of C30 in terms of setups, writing ISRs etc, but I am now in the midst of this since I am falling behind in my project for my employer.
It's a pity, actually, as I've used CCS compilers since 2005. Until now, I have always been able to figure out a workaround, and have put up with lame excuses from CCS as to why they can't support fundamental C syntactic structures. But not being able to move forward at all puts me at risk.
My conclusion: CCS consists of a bunch of hacks rather than professional programmers. They clearly do not have adequate regression testing of any sort. |
|
|
miketwo
Joined: 04 Aug 2010
Posts: 24
|
|
| Posted: Fri Aug 13, 2010 1:12 pm |
|
|
I second Gary's comments above. I'm using PCD with a PIC24FJ256GA110, and it's been nothing but trouble. Here's a quick rundown of what I've run in to...
#1 Nested array resolution = bad. Particularly when you use a bad coding practice like pointer arithmetic.
Example:
| Code: |
// Try this test function out
void Test6()
{
// Declarations
char a[10][10];
char b[5];
char c='c';
// Initialize
memset(a,0,10*10*sizeof(char)); // Zeroes everywhere
memset(b,0,5*sizeof(char)); // Zeroes everywhere
// Normal Assignment
*(a[0]+1) = c;
// Results
if(a[0][1]=='c') fprintf(COM_A,"\r\nPASSED");
else fprintf(COM_A,"\r\nFAILED");
// Reset
memset(a,0,10*10*sizeof(char)); // Zeroes everywhere
memset(b,0,5*sizeof(char)); // Zeroes everywhere
// Nested array assignment
*(a[b[0]]+1) = c;
// Results
if(a[0][1]=='c') fprintf(COM_A,"\r\nPASSED");
else fprintf(COM_A,"\r\nFAILED");
}
|
#2 Using printf on a float inside a function call when you have an interrupt timer running = bad
Example:
| Code: |
// Above main()
[set up fuses for 32MHz clock]...
// Set up a fast interrupt
unsigned int64 MSEC=0;
#int_timer1 // Millisecond timer
void rtc_isr()
{
MSEC++;
}
// Set up test function
void Test8()
{
float64 a=3.1415926535897932384626433832795028841971693993751;
fprintf(COM_A,"%12.8f doesn't!",a);
}
void main()
{
char test[10];
float64 a_float=3.1415926535897932384626433832795028841971693993751;
// Setup Timer Interrupt
setup_timer1(TMR_INTERNAL|TMR_DIV_BY_64,0x00FA); // 0x00FA is a rollover of 250, which at 32MHz and a prescaler of 64, should rollover every millisecond
enable_interrupts(INT_TIMER1);
fprintf(COM_A,"%12.8f works!",a_float); // Works
Test8(); // Same code, crashes
}
|
#3 Structs. I haven't been able to get a test to replicate this failure, but be careful of using structs that have a final element that is 8 bits. The struct will pad an extra byte onto it's size, but messes up the indexing of elements sometimes...
Anyone else have some more? |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sat Aug 14, 2010 2:23 am |
|
|
| Quote: | | Anyone else have some more? |
There are various contributions in the forum related to PCD bugs during the last years. They don't need to be repeated in detail.
One rule of thumb: Complex expressions, particularly involving int32 and pointers have still a high likelyhood to reveal PCD bugs. I'm willing to confirm that PCD is through, when it finally compiles the original RFC 1321 MD5 code without errors. See: | Quote: | | http://www.ccsinfo.com/forum/viewtopic.php?t=36359 |
But it's probably a long way. A few bugs reported nearly 2 years ago are still continued.
Most of these bugs show some kind of confusion with working registers. It seems like it's too much for PCD to keep track of them.
I guess your float example simply suffers from a stack overflow. Unfortunately the default stack size is too low to handle float reliably, unfortunately CCS ignored respective hints up to now. The compiler listing contains an estimation of required stack space that's completely inapproriate, apparently ignoring interrupts.
Personally, I still love PCD for it's ease of use. I also doubt the above findings about C30 producing more compact code. I found workarounds for present PCD bugs and I'm aware of possible surprises when using a new compiler release with an existing project. I e.g. had to stay with 4.107 because 4.109 messed up the builtin SPI functions. But I'll give 4.110 a try. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
| PCD Float: 1 - 2 = 3 |
| Posted: Sun Aug 15, 2010 11:29 pm |
|
|
The surprizing result of PCD float arithmetic (at least since V4.098) is:
1 - 2 = 3
| Code: | #include <24FJ128GA106.h>
#use delay(clock=8000000)
#use RS232(baud=1200, UART1)
void main()
{
float x,y,z;
x = 1.0;
y = 2.0;
z = x - y;
printf("%f - %f = %f\r\n",x,y,z);
while(1);
} |
Fortunately, there's a workaround: z = x + (-y) gives the correct result. |
|
|
pic_user
Joined: 25 Aug 2005
Posts: 16
|
|
| Posted: Mon Aug 16, 2010 2:51 pm |
|
|
| Quote: |
One rule of thumb: Complex expressions, particularly involving int32 and pointers have still a high likelyhood to reveal PCD bugs.
|
I don't know whether you are formally educated or not, but pointers are an integral part of C, just as they were for Pascal, and as they are for the alphabet soup of available programing languages. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Aug 16, 2010 3:02 pm |
|
|
Pic_user,
Please read FvM's 1500 posts on this forum and 3200 posts on the Altera
forum, and reconsider your post. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Mon Aug 16, 2010 3:52 pm |
|
|
| Quote: | | but pointers are an integral part of C |
Yes they are, there's no but. I only reported an observation.
As an illustration some problem that could be brought on by porting the brushelectronics SD card driver to PCD V4.107
| Code: | unsigned int32 clust;
unsigned int32 database;
unsigned int8 sects_clust;
FATFS *fs; // some struct
// the below expression produces an error in stack operation (unpaired push and pop count)
return (clust * fs->sects_clust + fs->database);
|
It works however, if the expression is "spoon feeded" to PCD
| Code: |
clust = fs->sects_clust*clust;
clust += fs->database;
return (clust); |
So you can use pointers with PCD, but possibly not the way you like to... |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Mon Aug 16, 2010 11:03 pm |
|
|
I can only hope to forget as much as FvM has about everything he knows.
-ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sat Aug 28, 2010 4:49 am |
|
|
The 1 - 2 = 3 issue has been verified by ccs, but still pending in V4.112. Hopefully corrected in the next release to come.
Frank |
|
|
arocholl
Joined: 14 Dec 2008
Posts: 21
|
|
| Posted: Wed Nov 10, 2010 10:24 am |
|
|
I concur PCD is significantly less stable than PCH.
There are many bugs, some of them really hard to diagnose and/or workaround, where CCS "simplicity" becomes a "nightmare" for any serious project.
I've reported ROM pointer problems like the one on this thread to CCS support a couple of months ago, including one which produces a PCD.dll internal error. I'm still waiting for an answer of any kind.
An even after increasing stack size I cannot reliably work with floats in my code. I can workaround most problems working with int32 for this project, but certainly will move to a different vendor for my next serious project on 16bit PIC. I wouldn't recommend PCD for professional use at this point to anybody, but actually suggest to consider other options.
Another stunning thing on PCD is apparently optimization doesn't work (or work all the time). If you compile the code with optimizations enabled to Max or fully disabled, the compiler produces exactly the same code all the time. Did anyone see anything different than this? |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Wed Nov 10, 2010 10:47 am |
|
|
I haven't been doing a lot of 16bit PIC projects lately. So I haven't seen that.
I would concur PCD is definitely not ready for primetime still.
However, if you find you are stuck with something important, besides emailing CCS Support, when you get back your ticket and call, talk to someone and just kindly remind them (fairly) of the severity level.
A PCD.dll issue is pretty bad. That should get immediate attention. Things I can work around, I let them know, "I worked around this for now... but it's still pretty bad"....
They usually get it done a little faster than "the next release".
I think they need a bugzilla server so we can log in and submit bugs in a more orderly fashion than just emailing to the support address...
Maybe they have one and just don't want us to see the nightmare. Fair enough - just get a more reliable trouble-ticket system.
In any case, I think they're like most companies these days, understaffed and overwhelmed. I think they're good peoples. Call 'em up - be nice - and they're pretty inclined to help.
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
arocholl
Joined: 14 Dec 2008
Posts: 21
|
|
| Posted: Wed Nov 10, 2010 11:10 am |
|
|
Oh, I am sure they are nice and capable people. I am nice people too... but the PCD product is still far from being where I need it to be. I think is a matter of how CCS work out their priorities: e.g. they add a switch/case feature to support strings on it. Nice, someone may find it useful even though non standard C, but would you invest on that when the list of bugs is large? I wouldn't.
I may give them a call to ask about my 2 month old reported bug but, honestly, I don't feel like this will go at the speed I need for the many bugs found. I already moved on and working on RAM pointers all the time, albeit using much more resources from the micro than initially predicted... |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Wed Nov 10, 2010 1:33 pm |
|
|
| arocholl wrote: | Oh, I am sure they are nice and capable people. I am nice people too... but the PCD product is still far from being where I need it to be. I think is a matter of how CCS work out their priorities: e.g. they add a switch/case feature to support strings on it. Nice, someone may find it useful even though non standard C, but would you invest on that when the list of bugs is large? I wouldn't.
I may give them a call to ask about my 2 month old reported bug but, honestly, I don't feel like this will go at the speed I need for the many bugs found. I already moved on and working on RAM pointers all the time, albeit using much more resources from the micro than initially predicted... |
I know.. I know.. I hear ya. But like I said, give 'em a call. The squeaky wheel gets the grease.. right?
Hahaha..
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
