statement limit on programming????

[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!!

[Ian.M]

<snark>
Our crystal balls have gone out of adjustment due to the impossibility of getting them serviced during beer-bug lockdown, so no, no-one has any idea what's wrong with your code *WITHOUT* *SEEING* *IT* !!!
</snark>

If you were programming in midrange PIC assembler, you might expect problems crossing 2 Kword page boundaries, but as PIC assembler doesn't have an IF instruction, and your PIC only has two pages, each 50% of the total program memory, that's unlikely at 30% used.

High level languages like C are supposed to handle crossing page boundaries cleanly, so unless you are using a buggy legacy compiler from the dark ages or have misreported the percentage use, that's also rather unlikely.

[brucehoult]

He did say 30% free, not 30% used, so maybe page crossing *is* the problem.

But, as you say, the compiler or linker should handle that transparently.

[snarkysparky]

What's inside the if statement.   If you prevent it from being true does the code still lockup.

There is no limit to any particular statement.  Only to the code size generated.

[rs20]

In case it's not clear to the OP: please post relevant details. The code that's not working, the name+version of the compiler you're using, full output from the compiler (rather than just the details that you think are relevant), etc.

[tszaboo]

No, there is no practical limit.
You can place if statements one after the other on inside each other, like no tomorrow.
Probably it is better to use other constructs though. You should probably familiarize yourself with the switch-case statements, and use those. If will result with faster more readable code. Possibly.

[aheid]

Some general tips debugging such weird issues.

First, is it the if at all? Comment out the if so that the body is always executed.

If there really is something  with the if, does it matter what is in the if statement condition? Try replacing the condition with something simple (but non-trivial so compiler doesn't just eliminate it). That is, is the problem the if statement itself or the code in the if statement.

If the condition is fine, does the contents of the body matter? Replace it with something simple.

If it's the if statement, does it matter where it is? Try adding a few simple statements before it that does nothing special but can't be optimized away.

If it matter where it is, maybe it is some alignment issue as mentioned.

If not, study the disassembly to verify the compiler generates the correct code.

In general this is a process of elimination, to try to gain understanding of which aspects that is causing it to fail. As a rule of thumb I always assume the compiler works correctly, as it is almost always an issue with the code itself.

[T3sl4co1l]

In extreme cases, it may even be a compiler bug.  But that's well and truly the last thing to suspect.

First step is to actually debug it, step through the machine code (you are familiar with your platform's instruction set, right?) and see where it goes awry.  Or if you don't have a single stepping debugger, then at least reviewing the assembler output (but, this can be daunting in such a large function -- a tip is to look for variables or addresses used by relevant statements, see where they are loaded as immediates/constants/whatever).

BTW is that 7 pages of code total, or 7 pages all in one function or clause or loop or whatever?

Tim

[gatoulisss]

im using mikro C, the 7 pages is the total (when for example i print my code )
testing my program on hardware when i add that if then its reacting like passing all the code and start over
when i erase the if, test again everything ok! write again the if again the problem
the code without having any problem is this:

Code: [Select]

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 one is WITH the problem:

Code: [Select]

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);

[brucehoult]

mikro C is licensed software. I expect it comes with support.

[snarkysparky]

are you using the result of the EEPROM_Read()  anywhere else?

If not it could be that the EEPROM_READ() is not compiled in without the test for if(er==1)

So the problem could be in the EEPROM_Read()

[ve7xen]

Hard to say for sure without seeing the rest of the code, but...

Code: [Select]

sound_init(&portb,3);
This looks to me like you are passing a pointer to an automatic variable where I'd expect either a true pointer (to an MMIO address) or passing by value. Is this intentional? Your if statement could be changing the address the compiler chooses for portb, making references to it within sound_init 'more fatal'.

When I encounter weird situations where minor unrelated changes cause crashes, it's fairly often because I've messed up a pointer reference somewhere and am accessing undefined/uninitialized memory, which the compiler is free to shuffle around based on the minor changes I make and trigger the failure.

[Doctorandus_P]

My first suspect is a rogue pointer.

That was before I scrolled down and read ve7xen's post, who has the same idea.