Matrix user forums

The above schedule after the operation result is A1=0 A2=0. Why go wrong? The above process operation will make mistakes. When E2 = 1 cannot jump out of circulation.
Parameter Settings : MCU is PIC18F4520;If you use Flowcode_PIC_V4, the result is correct; if use Flowcode_PIC_V5, the result is wrong;

Hello. Can you tell us if this is in simulation or in hardware?

I have tested both on the full v5.4 in simulation and both examples work OK.

This may be an issue with the FCD files for that chip, though in my version the code to do I/O on both v4 and v5 versions is identical.

Perhaps you could try the following code in a calculation (on v5 only): And see if this has the same effect? This type of call uses a slightly different mechanism. Other to that I can only guess at differing config settings - perhaps you could post your v4 and v5 sample programs?

Cheers,

Jonny

Hi Jonny,
Simulation run program are correct; When the program is downloaded to a MCU, hardware operation will make mistakes;

Hi Jonny,Below is a set of information：

Hello,

Regarding the pin outputs I'm wondering if there is a read/modify/write issue. What speed are you running your microcontroller? Does it help if you add a delay of say 10us in between the output icons?

The above process operation will make mistakes. When E2 = 1 cannot jump out of circulation.

As you are reading RE2 the value returned is likely to be 4 not 1. I would simply put key0 as the while loop parameter as this will allow the code in the loop to run until the variable key0 is greater then 0.

Hi Ben,
hope you and every one else on the forums had a good break?

Benj wrote:As you are reading RE2 the value returned is likely to be 4 not 1. I would simply put key0 as the while loop parameter as this will allow the code in the loop to run until the variable key0 is greater then 0.

I would like to point out that since andyzwb is reading an individual pin and not port (masked or not), then only 1 or 0 will be read and not 4.
Also the variable used is a Bool, so value will never be greater then 1
Since I/p condition is tested at the end and not the start, there should not be any problems?

as for the speed being too fast, PLL is not used.

My guess would be hardware not running at all, or i/p not reading value correctly?

But since it works with V4 i'm not so sure now.

@andyzwb
Would you mind posting your Flowchart, and generated hex file please?

hello
I now find why will make a mistake. When I set below will go wrong, and when I will "override language" set to "English" on result is correct, don't know the problem if you can solve it. Set as follows, the operation result is correct:

Evening. Thanks for letting us know.

I am still on holiday until the 7th so can not fix this properly until then, but the problem seems to be in the translation of some C code in the Flowcode language pack. The comment '// Initialization' when translated into Chinese has the newline cut off it.

This can be temporarily fixed for your build by adding a C-code icon to the top of Main() that has the code: I hope this helps (and works!)

Jonny

hello
I think it should solve the problem of language pack can be cured

Hi,

I have almost exactly the same issues as the original poster: output pins that seem to influence each other.
PIC12HV615, FC updated to V5.4
I also have a delay routine that doesn't seem to work in h/w (works in sim).
In searching for a clue I noticed that while the delay() routines were included in the C code, the build reports:

Warning unreferenced functions removed:
FCI_DELAYINT_US in: C:\Program Files (x86)\Flowcode\v5\CAL\PIC\PIC_CAL_Delay.c
FCI_DELAYINT_MS in: C:\Program Files (x86)\Flowcode\v5\CAL\PIC\PIC_CAL_Delay.c
FCI_DELAYINT_S in: C:\Program Files (x86)\Flowcode\v5\CAL\PIC\PIC_CAL_Delay.c

So is this an error? Are the removed non-referenced functions not necessary to use the delay functions??

Thanks for any pointers on this,

jan didden

Hello Jan,

Have you done the 1 second flasher test to get your delays correct. My guess is that your delays are appearing wrong because the software clock speed and configuration options do not match the hardware.

The DELAYINT functions are used to allow you to use 16-bit variables with the standard 8-bit delay functions without having to create a routine yourself. If your passing byte variables or constant values then these functions are not needed.

Benj wrote:Hello Jan,
Have you done the 1 second flasher test to get your delays correct. My guess is that your delays are appearing wrong because the software clock speed and configuration options do not match the hardware.

Ben, thanks for replying. Tried a very basic thing, set two output pins, then delay, then reverse output pins. Appears that it stays in delay indefinitely. Tried both sec and msec delays. Verified same s/w clock speed and speed in config dialog.

Benj wrote:The DELAYINT functions are used to allow you to use 16-bit variables with the standard 8-bit delay functions without having to create a routine yourself. If your passing byte variables or constant values then these functions are not needed.

OK thanks for clearing that up.
BTW I assumed that the GPIO bits 0-5 pins on the 12HV615 datasheet correspond with the PortA bits 0-5 in FC?

jan

Re-installed V4 (which doesn't recognise 12HV615 but does the 12F615 and I assumed it is identical as far as internals is concerned sans the shunt reg.
Same problem. Goes into the delay and stays there indefinitely.
Frustrating!

It appears that the original poster and I have in common the 12F6xx chip. Could there be an error in the definitions for thi
jan

Post deleted - wrong info.

jan

I think I have isolated the problem.

At the start of my flowchart I have:

asm
{
// bcf _option_reg, 7 //enable wpup
bsf _wpua, 2 //A2 wpu
}

If I un-comment the first line, the delay statement later on doesn't work and the program never gets out of the delay loop.
With this line commented out, all works as it should.
Any ideas?

jan

If I move the two asm lines shown above *after* the delay, all goes well and subsequent delays also work as advertised.
Still have no idea why it doesn't work with the register settings at the beginning but it's a useable workaround.

jan