Memory usage by macro variables

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 5.
To post in this forum you must have a registered copy of Flowcode 5 or higher.

Moderator: Benj

Post Reply
Mark
Posts: 209
Joined: Thu Oct 19, 2006 11:46 am
Location: Bakewell, UK
Has thanked: 20 times
Been thanked: 16 times
Contact:

Memory usage by macro variables

Post by Mark »

Hi,

Does code generated by Flowcode allow the space freed up from local macro variables when a macro is closed
to be used for other local variables for their macro variables?

Flowcode 5 is making it easy for me to generate large numbers of Macro variables, which makes a program far more readable,
but I am wondering if this is going to put me in memory problems for larger programs (such as one I have in mind).

Thanks,

Mark
Go with the Flow.

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Memory usage by macro variables

Post by Benj »

Hi Mark,

Any local variables will only consume memory while the macro is being executed. As soon as the microcontroller reaches the end of a macro and returns to the calling function the memory locations occupied by the local variables will become free again.

We did a lot of work to try and make this much easier in v5 as its always good practice to use local variables where possible. Glad you are finding it easier :)

Mark
Posts: 209
Joined: Thu Oct 19, 2006 11:46 am
Location: Bakewell, UK
Has thanked: 20 times
Been thanked: 16 times
Contact:

Re: Memory usage by macro variables

Post by Mark »

Hi Ben,

Many thanks, yes, Flowcode v5 is far better to work with.

I particularly like the provision of Constants, which I imagine are transferred to actual values on compilation but where I can readily tinker with values and alter the functionality of whole swathes of code simply by amending the value initialised in the Constant.

To help me more effectively code I would appreciate your comment on macros only returning a single value. The issue is that I often want a macro to return several values and hence end up dipping into global variables. For example, I process input data and wish to return an average and a measure of spread. I could use separate macros but then they would be duplicating processing of the data, often significant amounts of data. How would you approach such an issue?

Best Regards,

Mark
Go with the Flow.

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Memory usage by macro variables

Post by Benj »

Hi Mark,

You should be able to use the string variable type to return an array of data.

The string data type will let you access each of the memory locations as a byte so you could return data like this.

.Return[0] = ADC0ReadByte
.Return[1] = ADC1ReadByte

Then outside the function simply use a string variable to hold the return value and you can access this the same way.

LCDPrintNumber ( String[0] )

If you need larger variables then bytes then you can split it into bytes and then re-create at the other end.

.Return[0] = INTvar
.Return[1] = INTvar >> 8

Then to re-combine

INTvar = String[0]
INTvar = INTvar | ( String[1] << 8 )

Longs and Floats can also be handled this way by using 4 byte locations per variable instead of 2.

User avatar
JonnyW
Posts: 1230
Joined: Fri Oct 29, 2010 9:13 am
Location: Matrix Multimedia Ltd
Has thanked: 63 times
Been thanked: 290 times
Contact:

Re: Memory usage by macro variables

Post by JonnyW »

Hello. To add to Bens answer it is also a particular annoyance of mine that you can only return a single value.

Languages like Visual Basic have a concept of 'reference variables' - a variable passed by reference to a macro has its value updated. It is likely that we will be implementing such a feature in the future so functions such as GetPoint(x, y) can easily be implemented. This is still just an idea though and would be a v6 addition if at all.

Jonny

Mark
Posts: 209
Joined: Thu Oct 19, 2006 11:46 am
Location: Bakewell, UK
Has thanked: 20 times
Been thanked: 16 times
Contact:

Re: Memory usage by macro variables

Post by Mark »

Benj, Jonny,

Thanks for both your inputs.

My feeling with Flowcode 5 is that I am reaping the benefits mostly from improvement of current functionality and the addition of further functions/peripherals is becoming more and more esoteric. Hence, continuing to work on improved functionality of existing functions seems well worth considering.

Whilst we're on the subject of bugbears, I would very much appreciate the loop function being updated so that it enables initialisation of the loop value and incrementing of the loop value.
Hence, having a box which allows you to say Loop initial value is X, on each iteration increment by Y, will save cluttering up the flow chart with low level housekeeping icons Loop = 1, Loop = Loop +1.
The basics are already there in the existing options it just needs a handy user interface and access to the underlying loop variable.

Once again, many thanks,

Mark
Go with the Flow.

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Memory usage by macro variables

Post by Benj »

Some good idea's there Mark, let us know how you get on with the multiple return values. Will the string work around work for you?

If I may add to your list, it would also be quite nice to have access to the count variable via the program so you don't have to recreate your own as an index etc.

User avatar
JonnyW
Posts: 1230
Joined: Fri Oct 29, 2010 9:13 am
Location: Matrix Multimedia Ltd
Has thanked: 63 times
Been thanked: 290 times
Contact:

Re: Memory usage by macro variables

Post by JonnyW »

Hi Mark. Yes, I think this could be very doable. We will have to consider the simplicity of the loop as it is vs. the benefits of essentially implementing full C-style 'for' loops, but personally I like the idea.

It would also allow access to the 'loop' variable as you would have to specify this in the icon, solving that problem too!

Post Reply