limit on statements????

[gatoulisss]

hello everyone...
im programming a pic16f88 mcu and im gonna ask now something that might sound stupid... is there a limit on how many if statements i can use?
im asking this because i have round 7 pages of code, 30% rom free on my mcu and everything works fine but if i add one more if statement on my code then my program reacts like it resets
erasing this if statement everything goes back to normal again

does anyone knows what might be happening?

thank you!!

 

[Aussie Susan]

No limit on 'if' statements. Or any other for that matter.
However you may be getting your logic mixed up if the code is not well structured.
Also look at the linker map to see if you are approaching some internal limits.
Have you tried to debug the code and see how far it gets?
Susan

 

[danadakk]

Rare but I have had it happen more than once, a non printable ascii
character gets embedded into a typed line of code and all hell breaks
loose. You cant see character, but its there and compiler / editor can
go nuts on you. I have even had instance where erasing the line does
not get rid of the problem.

Its not predictable, in my experience, and worst comes to worst I backtracked
to an old backup and re-wrote the code from that point going forward. Its a
curse if it happens....

Backup often.....


Regards, Dana.

 

[BradtheRad]

* Do you have nested IF trees? The program needs to keep track of all exit points, that they're in the correct sequence. For every 'IF' there absolutely must be an 'END IF'.

* Do you have lengthy IF statements (IF...ELSE statements)? Break up these into short statements so that the compiler more easily reveals the error.

* Does your keyword list have SELECT CASE? It's a useful alternative to IF keyword.

 

[KlausST]

Hi,

To avoid many "IF" you may consider a table and/or "loop"ed processing.
Or use "CASE" instruction

Klaus

 

[paulfjujo]

hello,

maybe due to this
see Parenthesis suspiccious on post .

https://www.edaboard.com/threads/can-i-save-memory.396604/

 

[betwixt]

Generally there is no limit but tell us which language your code is written in. 'if' can be used in different ways, as part of program decision making and as a compiler directive, it is quite possible some compilers may have a limit when used as a directive although I have never come across such a case.

Also tell us whether the limit you hit is for nested 'if's or not. If you are nesting to great depth there is usually an alternative method which is more code efficient.

Brian.

 

[gatoulisss]

im using mikro C i have build my code and everything works fine, then i realize that i had to use the eeprom memory so i could save some user changes on the program. everything was good again.
testing my program in hardware i saw that in the very first use before the user do the choices the program didn't work correctly because the first values where changed with the values of the eeprom and the eeprom till the user make his choice for the first time it was empty so i add an if statement to prevent that
then i test again in hardware and it was reacting like passing all the code and start over
i erase the if, test again everything ok! write again the if again the problem
and i was thinking how this could happened because the only change i made was to use an if statement
likely i have lot of back ups so i dont loose my code but again i cant understand

this is the code without the problem:

trisa=0b00001111;
trisb=0b00000001;
portb=0x00;
porta=0x00;
on=0;
hx=1;
x=0;
j=0;       
a=0;       
er=1;
flag=0;

hx=EEPROM_Read(0x01);
er=EEPROM_Read(0x02);

sound_init(&portb,3);

and this is with the problem:

trisa=0b00001111;
trisb=0b00000001;
portb=0x00;
porta=0x00;
on=0;
hx=1;
x=0;
j=0;       
a=0;       
er=1;
flag=0;

hx=EEPROM_Read(0x01);
er=EEPROM_Read(0x02);
if (er==1){x=7;}            //this line is the only change

sound_init(&portb,3);

 

[betwixt]

I note you do not specify the type of variables (char, int etc.) which I would advise you to do. I think MikroC defaults everything to 'int' types.

There is nothing technically wrong with the code though and the 'if' statement is perfectly valid. For a single instruction you don't need to the { } brackets so you can remove them but they shouldn't stop it working. Maybe this is a 'quirk' of MikroC, I don't use it myself to check.
Try editing the line so it simply says :
if (er == 1) x = 7;
and see what happens.

Brian.

 

[Aussie Susan]

What is the rest of the code?
Your description could well apply to code that you don't show us but is reacting to 'x' being 7 and not 0.
Susan

 

[gatoulisss]

What is the rest of the code?
Your description could well apply to code that you don't show us but is reacting to 'x' being 7 and not 0.
Susan

the code is too big to upload
before i use the eeprom memory the starting value of x was 7 then because of the epprom values i had to rebuild that part, the problem is not in the x or if, its like my program passing one time all the code and then it starts again
i had this problem and some time ago i rewrite the code then and it worked but i have to find out why this is happening is tiring to start over and over again
sometimes im thinking that it could be of mikro c bug ...

 

[KlausST]

Hi,
In post#1 you wrote:

30% rom free on my mcu and

Now you say it is too big. How do both statements fit?

Klaus

 

[Aussie Susan]

(I think @gatoulisss means the source code is too big, not the compiled binary.)
I have seen cases (with other compilers admittedly) where adding a line of code has pushed some psect over a limit and that has caused 'issues'.
Also the way some variables are used within the code can alter the code that is produced - even to the extent of optimising a variable away or brining it back which has then altered the way the variables are stored; a wayward pointer can then cause havoc that leads to a reset.
I guess the OP will have to look for these things himself if we can't see thecode.
Susan

 

[paulfjujo]

hello,

with 16Fxxx , very often problem is due to RAM overflow ...
for example when using direct Texte used in the code ...
this use a lot of RAM .. the only way to dtect this problem, is
the IRP bit alarm message ..
but not block the compiling .. Successfull compile !

to avoid this, use TEXTE in ROM and use the same RAM buffer to printout all TEXTE messages on LCD or Terminal..