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
Memory usage by macro variables
Moderator: Benj
- 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
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
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
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
-
- 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
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
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.
- 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
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.
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.
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
- 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
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
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
-
- 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
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
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.
- 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
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.
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.
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
- 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
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!
It would also allow access to the 'loop' variable as you would have to specify this in the icon, solving that problem too!