A tale of optimizers and SPI

jventerprises · Joined: 01 Apr 2004 Posts: 43 Location: Boston

hi everyone,

i just spent a long night tracking down this 'feature' and wanted to run it by the group for advice. it is from 3.187 and for a PIC16F877a.

this snipet of code is from a USB HID handler i wrote. it takes data from a USB 9603 RX fifo and stuffs it out the SPI port (or returns it).

#IF USB_EP1_RX_ENABLE
if (endpoint == 1) {
if (dest == destLOCAL)
{
len = usb_get_packet(1, ptr, max);
return len;
}
else if (dest == destSPI)
{
len = 0;
while (len < max)
{
// get the next byte and send it to the SPI port
usb_get_packet(1, &data, 1);

SSPBUF = data;
while (!SPI_BF);
data = SSPBUF;
// data = data *2;
len++;
}
return len;
}
else
{
return 0;
}
}
#ENDIF

Well, that was the idea anyway. the lines in question are:

SSPBUF = data;
while (!SPI_BF);
data = SSPBUF

these take a byte of data, write it to the SSPBUF, wait for the BF flag, and then read what came in, thus clearing the BF flag. I dont need the incoming data.

with 3.187 and default optimization, it doesn't work. because i never do anything with the data from 'data = SSPBUF', the optimizer takes it out (rightly so i think). the effect is BF doesn't clear, and data starts to get lost since while (!SPI_BF) is always true, and i overwrite the SSPBUF!

to make it work with the optimizer on, i had to do the following.

SSPBUF = data;
while (!SPI_BF);
data = SSPBUF;
data = data *2;

now, the PIC reads SSPBUF fine, BF clears and my data flow is not corrupted.

Anybody have any ideas on what a 'correct' approach to solve this would be? i don't really want to turn of optimization, but the 'data = data *2' line feels like a hack to me....

i guess i could check the SSPIF interrupt flag instead of the BF flag.....

i know there must be a few opinions out there....
_________________
Jon

jventerprises · Joined: 01 Apr 2004 Posts: 43 Location: Boston

Why doesn't anybody ever answer my posts?
_________________
Jon

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

Charlie U · Posted: Thu Oct 28, 2004 10:30 am

I just tried your example, but used the built in functions. It appears that when you use these, you get the desired results. Here's the listing from a compile with 3.190 which is the closest I have 3.187.

Trampas · Joined: 04 Sep 2004 Posts: 89 Location: NC

I know with the CCS if you find a feature, try another version of compiler....

I have personally spent hours finding that the I2C_write function did not work. I finally debugged the assembly to find the compiler did not implement function correct. The worst part is it worked in one version, next version of compiler had bug, next version it was fixed, next version had same bug....

Thus NEVER use CCS intrensic functions! You will spend more time debugging their functions than writting your own. But you know that now!

Trampas

SherpaDoug · Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA

My solution is to use the built in functions, but only upgrade the compiler when I really really have to, and never in the middle of a project! I have never encountered a bug I can't live with, and I would much rather have the bugs I know than ones I don't. This doesn't just apply to CCS but to any software tools I work with including FPGA compilers and stuff from Microsoft.
_________________
The search for better is endless. Instead simply find very good and get the job done.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Trampas · Joined: 04 Sep 2004 Posts: 89 Location: NC

PCM Programmer,

What you suggest is sticking with one version of the compiler till you have to upgrade. I know that since 3.1xx I have been trying this approach, but CCS kind of prevents this. For example I updated the PCH compiler which cause a problem where I had to update the PCW compiler, which broke code. Then it was about 4 versions ping ponging, where one version fixed a problem but created another, etc. So basically I spent almost a week trying to get things working again, because of compiler bugs. Needless to say that that cheap price of the compiler cost me a week.

So basically I would say that the CCS intrensic functions are great and make it easy to get started developing code, however you will hit the wall hard usually when you are 95% done with your project. At which point you will spend days debugging only to find a bug in the compiler. So you being a good customer reports the bug and get this nice automatic response. Then you wait for 2 days expecting to get some announcement that they verified the bug and will send you a fix or that it was not reproducable. After the second day you call and say "Hey I NEED a fix" to which they will say "we are looking at it." In the mean time you start debugging the assembly and then email them the problem. At this point your frustration is high and start placing in-line assembly code in your C to fix the bug.

So basically what I am saying is that by not using intrensic functions you will save yourself some time when you get frustrated to no end and give up on CCS and switch to a real C compiler or back to assembly.

Trampas

jventerprises · Joined: 01 Apr 2004 Posts: 43 Location: Boston

well, i went collect more data to post here, and when i started the ICD SW i got the dreaded blue screen of death Shocked

complaining about a driver that went insane. When i booted back up the problem went away...

i can't explain it, and i tried to reproduce it for an hour. I must of had something bad going on with the ICD driver (i updated it to the latest version after that)

if i can get it to happen again, i will post more.

thanks for all your help.
_________________
Jon

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Part of it does seem to be luck. When we started doing a major
project with PCH, we were using vs. 3.187 and 3.188, and they
were stable for us. I think that right around that time, people
were having a lot of problems with versions slightly before that.
I remember thinking "whew ! Were we lucky !". Then I saw
CH Wu's comments on problems and I started feeling worried again.

So without the regression testing or other testing, there is a fair
amount of chance involved. I pity somebody that gets a bad
version as their very first version.

treitmey · Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA

I know no one wants to here this,....
I know we shouldn't have to do this,...
I know we are the customer and not the vender,...
I know everyone is short on time...
... etc..

BUT ,
Could we, as a group, make a set of regression tests? Idea

or are these done,.. and we just port them to CCS?

Or is this totaly out of our(CCS users group) scope?
--who would maintain?--who would check results?--
..lots of questions...

C-H Wu · Guest

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

It was this bug with PCH vs. 3.188:
http://www.ccsinfo.com/forum/viewtopic.php?t=19386&highlight=bsr
Since the bug depended upon the type of code (if-else or switch-case)
it caused me to worry if we would have the same problem. But in
our case it worked OK. So I consider that we were lucky.

C-H Wu · Guest