What's wrong with connection pont in a macro?

[metric]

Perhaps obvious for many, but I'm stuck.

All I want is to use an interrupt on RB0 line to quit my normal program (by jumping to the
end of the flow). So I inserted interrupt icon, which calls mymacro. Macro->show menu selection
displays new window (flow) with default macro that contains only "begin" linked to the "end".
All I did is inserted connection point icon "goto connection point B" in between "Begin" and "End".
I don't need this macro to do anything else but immediately jump to "B" on the interrupt event.

Is such a macro allowed?

So In the main program I inserted respective "B:" connection point entering the part of
the flow where I want execution to jump to when interrupt occurs and macro supposedly executes.

Well, compiler errors out complaining with this message:

"Unable to compile or simulate because connection point B: is called but not defined in flowchart mymacro.
Either remove the connection point call or add a definition of the connection point to the flow chart."

Can someone explain in plain English what is wrong? How can I define a connection point? the only
option after double-clicking on the connection point icon is to choose a letter of corresponding
entry point (whether this entry point is in within the same macro flow or the main flow, right?).

So basically the flow compiles OK only as long as "goto B" and "B:" are in the same flow, either both
somewhere in the main flow, or both in a macro. If one is in the main flow and the other is inside a macro
called by this main flow, compiler doesn't see them as associated pair and errors out.

What gives?

Thanks,

Victor

[Benj]

Hello Victor

The connection points are essentially goto statements and using goto statements from within macros is asking for trouble. I would advise that you do this.

In your interrupt routine use a calculation icon to assign a 1 to a variable.

In you main program start by initialising the same variable to 0. You can then include a decision icon inside your main loop to check the status of the variable and run extra code if the interrupt has occurred. You can even clear the variable when you are finished so you can wait for the interrupt to happen again.

There are a few other ways of acheiving this as the variable method will not always produce a instant link to your connection point B code.

Hope this helps.

[metric]

Ben,

Suspecting trouble you're warning against, I in fact tried what you've suggested and it didn't work for me.
Let me ask you - when an interrupts occurs, is the program going to quit doing what it was doing
and starts executing the program in the flow at the place where "interrupt" icon is inserted?

So if in the interrupt's macro flow I make a special variable =1 and in my main flow I place a decision
checking right below interrupt icon that will branch out if that special variable indeed became "1",
is it sufficient?

If no interrupts occur, interrupt icon in the flow is just being
"ignored" and the next icon below is executed, correct?

Well, if so, it didn't work for me. In my flow I initially disabled interrupt on RB0,
initialized that special variable to 0, enabled interrupt on RB0 and went on.
Is the flowcode smart enough to understand that if I enable interrupt on RB0,
I'm using RB0 as an input, or I still have to explicitly make RB0 as input?

Reason I'm asking is what is legally correct way (I tried both ways -
making RB0 input with I/O icon and omitting it, but it makes no
difference - actual interrupt is ignored. I use a button and RB0 pin
indeed goes from 0V to 4.6V or so on the button press).

Thank you for great support!

Victor

[Benj]

Hello Victor

The interrupt enable icon is just configuring the interrupt to allow it to work. You will have to define a new macro for the interrupt to call. When the interrupt happens the interrupt macro is called straight away. When the macro is finished the program will return to what it was doing before the interrupt occurred.

You may also have to do a simple input on RB0 to enable the input before enabling the interrupt to allow the pin to be converted to an input.

You could do a simple check to see if your interrupt is working by writing a very small test program, eg increment a variable and the send to porta when the interrupt is triggered. This will allow you to see the value on porta change every time you press the switch connected to RB0.

[metric]

OK, I understand the theory behind. If my very simple project won't run though,
I'll upload it for your inspection. As many here, I'm new to this, but my PIC application
really requires reliable operation, else it's going to be a big mess with powerful
hardware attached to it. I mean BIG mess - about 50 kW battery (up to 750VDC)
shorted to a collection of low voltage (48V) DC-DC converters =:O

Thus my detailed questions to gain understanding; hopefully others benefit
from your answers too.

Thank you Ben again,

Victor

[metric]

Ben,

The problem: if interrupt on RB0 only calls a macro that changes a variable and then the flow
continues, now I have to poll (test) this variable if it has changed. This defeats the
whole point of interrupt - I might as well just poll RB0 directly.

How is this suppose to work? The only way I figured was actually put copy of the code I
want executed in the macro itself instead of pointing to it. Wasteful, but works.

If I want to keep this code in the main program only and just use interrupt (so the macro)
to jump there, it doesn't seem doable without polling the variable that interrupt macro
sets up. Is this true?

The reason I want to keep the code only in the main because if it's fairly large chunk.
For now I have to duplicate it in main AND in macro. If I could use goto between main and macros,
I could use only one copy of this code, but you're saying it's asking for trouble...

How is this solved in C in general?

Victor

[Benj]

Hello Victor

What you can do is place your section of code into a software macro. Then you can call the macro from your main and from your interrupt without duplicating the code.

Your right about the flag variable polling being the same as just polling the I/O pin. It is good practise to keep the interrupt routine as short as possible though because if the same RB0 interrupt occurrs again while inside the service routine then you will miss the said interrupt. maybe you could only include the items in the service routine that need immediate attention.