View previous topic :: View next topic |
Author |
Message |
Linuxbuilders
Joined: 20 Mar 2010 Posts: 193 Location: Auckland NZ
|
>= and others |
Posted: Tue Dec 07, 2010 4:17 am |
|
|
there are serious issues with equations like if (a >= b) or if (a > b), etc...
I have noticed it few times, the code compiles mad in such cases, if I use (a == b) then it works like a baby, main issue is 18F45j11, 18F4520 seems to be a bit better, I had issues with 16F690 too in this subject. I have noticed it a cross of many pics and it has nothing to do with a program, most simple comparation operations are killing whole program. I am not going to post any program for very simple reason, all vars are int, and it should work. It goes mad when it is long int but this I have managed to fix by doing double loops like this one:
Code: |
if (a == 255) {
b++;
}
if (b == 255) {
c do something
b = 0;
}
|
Compiler is unable to deal properly with 0xFFFF so I have to do such tricks.
This is real loop which hangs whole program...
Code: |
if (timer_debauncing_tick > 9) {
ready_to_send = 1;
debouncing_delay = 0;
}
|
All problems seem to come up after I reach 70% of my program space...
If I change it to == then there is no problem.
Very disappointing...I have read CCS manual in all possible directions and there is only one explanation to this:
CCS is buggy (as we know) or manual is not mentioning some things...
It is such waste of my time on such stupid things, it is hard to believe, like clocking bugs in many pics so I cannot use PLL, etc... _________________ Help "d" others and then you shell receive some help from "d" others. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Tue Dec 07, 2010 6:52 am |
|
|
Seriously, first post your compiler version.
Bugs like this, were 'common' with the early 4.xxx compilers, but on the 'mainstream' chips (PIC16/18), I have not seen anything like this in ages, _except_ for 'user error', with things like size of variables, numbers using unsigned types, and then going -ve, etc. etc...
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9170 Location: Greensville,Ontario
|
|
Posted: Tue Dec 07, 2010 7:09 am |
|
|
Have you contacted CCS with the type/version of your compiler and a very small program that shows the problem? Is the problem specific to only some PICS? Perhaps to just a certain version of the compiler?
Telling us here is nice but please email CCS so they can look into it and 'patch' the compiler as required.
It is not uncommon for a new PIC's die to have a 'problem', so Microchip will release 'errata' info.This is a hardware issue, not the compiler.
As for the compiler being 'buggy', you should have been around when the Radio Shack TRS80s came out. Every two weeks they sent out a letter with 'patches' to the OS requiring you to use a diskeditor to fix it.Any typo on your part could and did create havoc!CCS has invested tens of thousands of manhours in their products that are very affordable.I've never met a code cutter who wrote a perfect program the very first time and I've been doing this since 1975.
I do not 'upgrade' any software unless there is a specific need on MY part.This includes, compilers,operating systems,etc. Just because 'they' upgrade doesn't mean the code will run on my system.Some upgrades only work for newer chips.When I do, I make sure I backup the previous and can return to it, if(when?) the new version fails! |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Dec 07, 2010 2:41 pm |
|
|
Don't post your "fix". Post a test program that shows the problem.
Also post your compiler version.
The test program should have the #include for the PIC, #fuses, #use
delay(), all necessary variable declarations, main(), and test code.
It should be as short as possible (No "wizard" code, if not needed to
show the problem). |
|
![](templates/subSilver/images/spacer.gif) |
Linuxbuilders
Joined: 20 Mar 2010 Posts: 193 Location: Auckland NZ
|
|
Posted: Sun Dec 12, 2010 3:07 am |
|
|
4.107, the funny thing is that I have downloaded an upgrade 114 and then what? then software which work on 107 without any problem on 18f4520 does not work on 114, I do not know what to think any more. It is like a ccs playground but on my cost...no fun no go...I think I will freeze my a... to one stable version and keep it going as long as possible, so far as it goes CCS is changing into Apple and Microsoft and lost all of its stability and trust, uses customers as testing ground. _________________ Help "d" others and then you shell receive some help from "d" others. |
|
![](templates/subSilver/images/spacer.gif) |
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Sun Dec 12, 2010 5:17 am |
|
|
Quote: | software which work on 107 without any problem on 18f4520 does not work on 114 |
Things like this are happening quite often with PCD, apparently CCS also manages to release insufficiently tested compiler versions for the 8 Bit chips from time to time. At least PCD V4.114 is effectively useless because it has newly introduced bugs that can't handled by workarounds.
http://www.ccsinfo.com/forum/viewtopic.php?t=43918
If you are interested to find out the exact reason for the observed problem, you should make a test application, that allows to reproduce it, as PCM programmer suggested. However, if it only appears above 70% ROM utilization (unfortunately, this happens sometimes), it may be impratical. |
|
![](templates/subSilver/images/spacer.gif) |
JoeR
Joined: 26 Jul 2008 Posts: 3
|
|
Posted: Sun Dec 12, 2010 1:05 pm |
|
|
Hi,
I have this issue on PCH 4.073 on a PIC18F4550 with USB.
A simple test like "if (t3 > event_boundary)"
returns true when t3=-7 and event_boundary = 5
t3 and event_boundary are longs
Which version fixes these issues???
I do not really want to change compilers I have too much work invested, and this is my last problem. I managed the program down to 83% space.
I am trying to see what else I can eliminate to free up space.
any work arounds???
I've been chasing this for days, and its maddening.
Thanks. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Sun Dec 12, 2010 1:57 pm |
|
|
It would, and it'd be right!....
A 'long', is unsigned.
-7 represented as an unsigned number, is 0xfff9, which _is_ larger than 5.
This is exactly the sort of thing I was 'expecting'. Wrong choice of number types, and not understanding the limitations these impose.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
JoeR
Joined: 26 Jul 2008 Posts: 3
|
|
Posted: Sun Dec 12, 2010 2:51 pm |
|
|
Oh geez, you're right. In my old age, my eyes did not parse the help file correctly. I will define the values properly and I am sure it will work right using signed values....
Sorry for the noise. |
|
![](templates/subSilver/images/spacer.gif) |
5440
Joined: 08 Feb 2009 Posts: 11
|
|
Posted: Wed Dec 22, 2010 3:02 pm |
|
|
So is this <= or >= statements a known bug?
I don't use any CCS functions as I like to roll my own.
I'm using 4.106 on a PIC18F2585 and finally found a "random" issue with my code that is currently only uses 3% ROM that involves a <= statement.
If I use an == statement, all seems fine, but my code will be less reliable in the future. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Dec 22, 2010 3:11 pm |
|
|
If you want help, post a test program. Complete, but short, and that
compiles with errors. By complete, I mean it has the #include for the PIC
and the #fuses, and the #use delay, and all variable declarations and
#define statements, and a main().
The shorter, the better. Don't put in anything that isn't needed to show
the problem. |
|
![](templates/subSilver/images/spacer.gif) |
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Wed Dec 22, 2010 4:57 pm |
|
|
5440 wrote: | So is this <= or >= statements a known bug?
I don't use any CCS functions as I like to roll my own.
I'm using 4.106 on a PIC18F2585 and finally found a "random" issue with my code that is currently only uses 3% ROM that involves a <= statement.
If I use an == statement, all seems fine, but my code will be less reliable in the future. |
It doesn't seem that it was a compiler bug at all, just a programmer error. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
![](templates/subSilver/images/spacer.gif) |
scottc
Joined: 16 Aug 2010 Posts: 95
|
|
Posted: Wed Dec 29, 2010 4:14 pm |
|
|
I am using 4.116 and do see some weirdness with operators => and <=.
I don't know if its a bug but I have seen this before. Honestly I never really
paid attention to it as I could find a way to make my code work.
Here is an example of a small routine that works fine. KHZ is a INT Variable.
Code: |
if (bit_test(Enc_A,3) == bit_test(Enc_B,2)){
Khz++;
if (khz>99)
Khz=0;
}
else
{
Khz--;
If (Khz>99)
Khz=99;
}
|
The following does not work and throws the following error with the included =>
"Assignment inside relational expression"
"A numeric expression must appear here.
Code: |
if (bit_test(Enc_A,3) == bit_test(Enc_B,2)){
Khz++;
if (khz=>99)
Khz=0;
}
else
{
Khz--;
If (Khz=>99)
Khz=99;
}
|
It seems to me that I am testing to see if the value in Khz is equal to 99
or greater than 99 and if so I set Khz to zero should be ok. It makes sense
from a human readible standpoint, but it won't compile.
Can anyone help me out and explain why such an expression is not valid.
Thanks Scott. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
![](templates/subSilver/images/spacer.gif) |
scottc
Joined: 16 Aug 2010 Posts: 95
|
|
Posted: Wed Dec 29, 2010 4:36 pm |
|
|
Yep operator is not valid, should use
<= Less Than Or Equal To
Or
>= Greater Than Or Equal To
Code compiles fine
Thank You PCM |
|
![](templates/subSilver/images/spacer.gif) |
|