View previous topic :: View next topic |
Author |
Message |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
UPDATE: PCD v4.141 Major Issue Warning |
Posted: Mon Apr 29, 2013 2:25 pm |
|
|
Just a warning to anyone using PCD, the compiler is not issuing a warning or error when it encounters an undefined data type in the argument list of a function definition. I know that this problem was present as far back as 4.124, perhaps earlier.
I bought a prewritten driver and I couldn't get some aspects of it to work. This was perplexing because I had previously purchased the 8 bit (PCH) version of the same driver and it worked perfectly. Turns out that my problem was that I had missed copying the typedef of a pBYTE (as used in the driver) over to my project. What's troubling is that the compiler didn't have any problem compiling it, even though it wasn't defined.
I last tried to find the problem late last year and I had to abandon the search to deal with other matters. I just got some spare time to return to the issue and I finally found it late Friday.
Yes, CCS has been told of the issue.
Last edited by newguy on Tue Apr 30, 2013 1:50 pm; edited 1 time in total |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Tue Apr 30, 2013 2:13 am |
|
|
Have you got a minimal program that shows the problem?.
If I try to declare this just about any way I can think of, the compiler does correctly complain.
Now pBYTE, is a suspicious type since it a commonly used shorthand for 'pointer to byte'. Does it still not fail if you just change one character in the name?.
I'd be very suspicious that in fact you are being caught by something slightly 'deeper', with possibly a #defined expansion resulting in the line actually being interpreted as something completely different, and hence accepted, but for the wrong actual type....
It is always a real 'annoyance', that you can't look at how CCS 'sees' the code after macro expansions etc., since it'd make finding this type of problem much easier.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Tue Apr 30, 2013 8:56 am |
|
|
The program that exhibits this behaviour is very large, and of course contains work related proprietary material. I've packaged up a version that shows the behaviour and sent it to CCS directly - they've responded already and are examining the fault.
pBYTE isn't used or defined anywhere in the program (well it wasn't - it is now). I've also done a search on every file included by the program, including the processor.h file, and other library CCS code. Nothing even closely spelled or with a different combination of lower & uppercase letters. It's the only instance of pBYTE anywhere in the project.
I do think it's a convergence issue where IF the code is at or above a certain size and/or IF the code targets a certain processor and/or IF the #case compiler directive is used and/or IF.....
It's interesting to note that v4.141 takes "forever" to compile this program. I say "forever" because the .hex file is generated quite quickly but the IDE takes a good 60-90 seconds to pop up the compilation report window (%RAM used, %ROM used, etc) and give focus back to the IDE. When I was tracing this fault, I would compile, CCS Load would quickly detect the new .hex, I'd program the target, test, and then I'd have to wait another 30 seconds (if not more) for the IDE to return focus so that I could tweak the code again & recompile.
The driver code that I bought is the SD card FAT driver from www.brushelectronics.com. I've been using this library on various projects since (I think) approximately 2007. It has always just worked. I purchased the PCD version of it since I'm now targeting a dsPIC33FJ256GP710A. In my haste to incorporate it into my project, I missed the typedef of pBYTE. Unfortunately the compiler didn't generate an error when I compiled and that started this long road. The author of the driver suggested that I revert to 4.124 because he knew for certain that it worked with that particular release. I did revert but I still couldn't get it to run. He then asked about the hardware, pullups, etc, but the layout is exactly the same as every other working SD card project I've developed, only with a 16 bit processor now, not an 8 bit. I probably wasted 2-3 weeks trying to find the problem and things got to the point that I had to drop it.
Thankfully it only took a day to find the root cause of the problem when I finally came back to it.
That said, I must declare that the SD card drivers available from Brush Electronics are well worth the $. They work "right out of the box" and save a lot of development headaches. I wouldn't hesitate to purchase any of his drivers in future. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Tue Apr 30, 2013 11:21 am |
|
|
I can tell you exactly what causes that long delay.
Project Options.
Output files
Call Tree file
This is enabled by default, and you are lucky if it takes as little as 60 to 90 seconds!....
Turn it off, and compile time totals will drop to about 1/5th.
I use the Brush electronics SD driver as well. It is just so much less work than trying to support all the vagaries of SD/SDHC yourself.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Tue Apr 30, 2013 11:27 am |
|
|
Ttelmah wrote: | I can tell you exactly what causes that long delay.
Project Options.
Output files
Call Tree file
This is enabled by default, and you are lucky if it takes as little as 60 to 90 seconds!....
|
I owe you a beer! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Tue Apr 30, 2013 11:41 am |
|
|
It had got to the point where I though "what the beep, is the compiler up to for so long". So I went and watched the output directory in another window. Found it had finished generating everything except this file.
Big smile when I turned the option off....
Why it takes so long to generate this I don't know.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Tue Apr 30, 2013 1:50 pm |
|
|
FYI...
"The problem you reported has been fixed and will be in the next compiler release." |
|
![](templates/subSilver/images/spacer.gif) |
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Tue Apr 30, 2013 3:49 pm |
|
|
To supplement the missing example
Code: | unsigned char x;
//typedef unsigned char* pBYTE;
void test(pBYTE *ppp)
{
*ppp = &x;
} |
Without the type definition, a byte value instead of a word (pointer value) is returned.
Developers who started using PCD for real projects some time ago will either have learned how to debug
similar issues or gave it up.
Because the present bug can be easily avoided by writing correct code, I don't consider it as severe.
I can assure you that the first attempt to port the FATM to PCD revealed several compiler bugs that required real workarounds. |
|
![](templates/subSilver/images/spacer.gif) |
|