Compiling problem

[WingNut]

I've been working on this file for quite a while now. Out of the blue (ive been editing the flowcode but nothing which should have caused an issue). I've attached the message file and cant figure out what exactly the problem is.

[medelec35]

Hello.
It's best to post your project file as well.
Have you deleted any declare connection points?

[WingNut]

Hi Martin. Yes I have but i've gone through every single change and cant see why there appears to be 2 undeclared connections points. I have used copy and paste to save a bit of time but again i've gone through them all.
flowchart PM'd

[WingNut]

Weird. After a night of windows updates I thought I'd try to compile again this morning and it has compiled successfully. Good old Microsoft.

Windows 11 btw

[medelec35]

Hi
Although your project compiles for me, I have spotted some issues with it.
for example, within main you have a loop with While true, so it will always be running.
However, you have an Enable timer interrupt within the loop.
Timer interrupt Eanalbes should only be run once (unless a timer Disable icon is used first), so you must move it above the loop.
You have a component, calculation and connection point below the loop, which will never be accessed, as the loop will be running forever.
My guess is you meant to have a goto connection within the loop, but it got missed out.
Try and use loops instead of goto connections whenever you can

Withing the SaveData interrupt macro you have a fair few FileSD components and a Disable timer icon.
All interrupts should be as short as possible and the components that are used within the interrupt e.g FileSD should not be used in any other user macros otherwise corruption will occur.
The compiler messages is warning you about this, they are called non-reentrant functions
If you see that warning, don't ignore it. for example, you have messages like:

Code: Select all

C:\ProgramData\MatrixTSL\FlowcodeV9\CAL\PIC\PIC_CAL_Delay.c: 85: non-reentrant function "_delay_us" appears in multiple call graphs and has been duplicated by the compiler
C:\ProgramData\MatrixTSL\FlowcodeV9\CAL\PIC\PIC_CAL_String.c: 132: non-reentrant function "_FCI_GETLENGTH" appears in multiple call graphs and has been duplicated by the compiler
C:\ProgramData\MatrixTSL\FlowcodeV9\CAL\PIC\PIC_CAL_String.c: 377: non-reentrant function "_FCI_TOSTRING" appears in multiple call graphs and has been duplicated by the compiler
C:\ProgramData\MatrixTSL\FlowcodeV9\CAL\PIC\PIC_CAL_String.c: 542: non-reentrant function "_FCI_FLOAT_TO_STRING" appears in multiple call graphs and has been duplicated by the compiler
C:\ProgramData\MatrixTSL\FlowcodeV9\CAL\PIC\PIC_CAL_SPI.c: 285: non-reentrant function "_FC_CAL_SPI_Master_Byte_1" appears in multiple call graphs and has been duplicated by the compiler

I have left a fair few messages off the list.

I have found in the past, that there is an issue if you disable an interrupt within an interrupt.
my advice would be to set a flag within the interrupt. then move all the components and Interrupt Disable to a new user macro.
Then within the new user macro, you clear the flag.
Instead of timer enables and disable's, you could use another flag called Timer4 disable for example, within the interrupt, to bypass setting the interrupt flag.
I can generate an example for you if it will help.

I hope this helps you out.

[WingNut]

Thanks Martin. I take all your points. The goto connection in the main loop is a relic from the first attempts at this circuit and there are a lot of variables and components to be removed. (I deleted 6 or 7 unused variables last night as an example)
I'll take up your offer of generating an example for the interrupt.
The goto connections are an easy way out of a loop and have worked well so far but I do know its not good programming practice

[medelec35]

Hi.
I have attached a basic demo.
The seconds that count within the interrupt only increment when the interrupt is allowed to increment them.
It should be noted that simulation is much faster than live on hardware.

[WingNut]

Thanks Martin. I'll implement your suggestions as part of a tidy up.
Is there no need to disable an interrupt?

[medelec35]

You're welcome.
No, you just use a decision branch to bypass all of the code within the interrupt.