Why hardware behaves different to Flowcode simulation?

echase · Post by **echase** » Mon Jul 16, 2007 9:50 am

As a newbie to Flowcode I naively hoped that when I loaded the code into my PIC it would behave exactly as the Flowcode simulation. I have found though that this does not happen. Can anyone give me the top ten reasons why this may be the case?

My limited experience leads me to the following contributions to the top 10.

1) Circuit different to the Flowcode design. E.g. switches giving push to give 0V instead of Flowcode default. Miswiring of circuit.

2) Circuit not working at voltage expected. E.g. my 886 based version bizarrely does not work at 5V, unlike the 876 version. Have to reduce it to 4V to make it run. Might be something to do with the crystal/capacitor combination. Fortunately with PICKIT2 can easily change the voltage.

3) Inadequate reset. I find that just turning the supply on does not always reset the PIC to start it running so I have to reduce voltage to 2.5V and increase it again to get it running, presumably this trips the brownout reset. Am going to add a reset switch.

4) Bugs in Flowcode FCD files?

5) Incorrect config words set. Unless using E block programmer and PPP the setting of config words not simple. See post http://www.matrixmultimedia.com/mmforum ... php?t=2431

Any other suggestions that would help me debug my circuit?

Post by **Benj** » Mon Jul 16, 2007 1:06 pm

Hello

Here are some reasons as to why the simulation may differ from the hardware.

1) Incorrect Config Words. Number 1 problem. Make sure that Watchdog is always off unless you know how to use it correctly.

2) The hardware is not correct or is wired differently. Eg you example of push to break instead of push to make.

3) Problems with Power supply. Make sure that your circuitry is compatible with the PICmicro devices. There is a good guide to the PSU circuitry available on the Microchip website.

4) A possible bug in the FCD or Flowcode where the computer is not emulating the PICmicro with 100% accuracy. This is most likely to occur when doing large calculations or sampling analogue channels etc.

Post by **Steve** » Mon Jul 16, 2007 1:14 pm

And be aware that Flowcode will not simulate any 'C' code you put in.

echase · Post by **echase** » Mon Jul 16, 2007 1:42 pm

Ben, what is the way around 4)? If Flowcode isnβ€™t always 100% accurate fiddling around with the flowchart isnβ€™t necessarily going to cure it. Do we have to amend the C or ASM to cure it? But we donβ€™t know how to read C or ASM which is why we bought Flowcode, so whatβ€™s the way out? Would buying a debugger help me? Which is compatible with my PICKIT 2 programmer? Or by β€100% accuracyβ€™ do you mean that mathematical calcs might be a few % out, rather than crashing the PIC? I can cope with some inaccuracy.

On that subject of large calculations does the following calculation work correctly in Flowcode/ C/ASM? x= (2/10) * 256? Answer should be 26, but does it give 0 as per 2/10 is 0.2, which is rounded down to nearest integer, i.e. 0. And 0*256 = 0. That is about as complex as my calculations get. And what does x=256*20/128 give if in BYTE form, as 256*20 exceeds the size of a BYTE variable? Or does the PIC internally change it to INTEGER, do the calc and then convert back to BYTE?

Post by **Benj** » Tue Jul 17, 2007 11:29 am

Hello

The BoostC compiler is quite advanced and should take care of most of your calculations for you. Eg 8 <-> 16 bit

As for your 2/10 and then * 256 this will very likely give a 0 like you said.

There are ways around this problem.

1) Use the second calculation you suggested with integer variables.

2) Use the Floating point 32 bit library which will allow for real floating point numbers.

Post by **Steve** » Tue Jul 17, 2007 1:05 pm

Instead of this:

Code: Select all

(2/10)*256

I would use integer arithmetic and do this:

Code: Select all

(2*256)/10

echase · Post by **echase** » Tue Jul 17, 2007 1:14 pm

So can I assume that the code always works the calculation in the order I input it? So it should be correct as long as I check that the answer to each stage is within 0-255 for BYTE and -30000 to +30000 (or so) for Integer.

Whats's the answer to:-

Ben, what is the way around 4)? If Flowcode isnβ€™t always 100% accurate, my fiddling around with the flowchart isnβ€™t necessarily going to make my code work. Do we have to amend the C or ASM to cure it? But we donβ€™t know how to read C or ASM which is why we bought Flowcode, so whatβ€™s the way out? Would buying a debugger help me? Which is compatible with my PICKIT 2 programmer? Or by β€100% accuracyβ€™ do you mean that mathematical calcs might be a few % out, rather than crashing the PIC? I can cope with some inaccuracy.

Post by **Steve** » Tue Jul 17, 2007 2:10 pm

echase wrote:So can I assume that the code always works the calculation in the order I input it? So it should be correct as long as I check that the answer to each stage is within 0-255 for BYTE and -30000 to +30000 (or so) for Integer.

No - in this case, the brackets determine the order of precedence.

Ben, what is the way around 4)? If Flowcode isnβ€™t always 100% accurate, my fiddling around with the flowchart isnβ€™t necessarily going to make my code work. Do we have to amend the C or ASM to cure it? But we donβ€™t know how to read C or ASM which is why we bought Flowcode, so whatβ€™s the way out? Would buying a debugger help me? Which is compatible with my PICKIT 2 programmer? Or by β€100% accuracyβ€™ do you mean that mathematical calcs might be a few % out, rather than crashing the PIC? I can cope with some inaccuracy.

I think we have to deal with this on a case-by-case basis. If you have specific instances where the simulation does not behave like the hardware, then we'll look into it. We are keen to improve the simulation features of Flowcode.