More Memory for Lua Script Section
-
- Posts: 27
- Joined: Thu Apr 09, 2015 8:18 pm
More Memory for Lua Script Section
I've recently learnt how to write math channels on the pro2 and I'm now bumping up against the memory limit for this section. I've added about 7 channels in addition to the standard E46 lua script.
I've taken out all comments and every single space that I can find to condense the code down as much as possible.
Is it possible to have more memory assigned to this area by giving up other features? I'm currently not using the GPIOs and PWM inputs.
I've taken out all comments and every single space that I can find to condense the code down as much as possible.
Is it possible to have more memory assigned to this area by giving up other features? I'm currently not using the GPIOs and PWM inputs.
Hi,
Just replied to your other thread on the great work you've done there.
The best answer is that we're moving CAN mapping directly into the firmware, which will greatly offload the CAN mapping work out of the Lua script, which will create more space for tasks Lua is best suited for, performing virtual (math) channel calculations. Demo video here: https://www.youtube.com/watch?v=zc1Bi__0IDk
Thanks!
Just replied to your other thread on the great work you've done there.
The best answer is that we're moving CAN mapping directly into the firmware, which will greatly offload the CAN mapping work out of the Lua script, which will create more space for tasks Lua is best suited for, performing virtual (math) channel calculations. Demo video here: https://www.youtube.com/watch?v=zc1Bi__0IDk
Thanks!
We do need more memory for lua scripting
Hi Brent
As I mentioned before we are racing an E30 (no ODBII) so we have installed plenty of sensors and need a lot of scripting. So far we have RPM, coolant temp, oil temp, pressure, throttle position, break pressure, gas level, mpg, laps per gallon, laps left and more. I promised to publish code and instructions for E30, but we have had to make the code compressed and spaghetti, to fit in the memory avilable. Because of that, it has become very difficult to understand and I don't feel it would be good to share it like that. Is there a chance for you to increase the limit?. I have seen the question posted several times to no avail. Please believe it is necessary.
I do have a structured version I can send for your review, but unfortunatelly it won't run on the memory available.
Regards
Wcorredor
As I mentioned before we are racing an E30 (no ODBII) so we have installed plenty of sensors and need a lot of scripting. So far we have RPM, coolant temp, oil temp, pressure, throttle position, break pressure, gas level, mpg, laps per gallon, laps left and more. I promised to publish code and instructions for E30, but we have had to make the code compressed and spaghetti, to fit in the memory avilable. Because of that, it has become very difficult to understand and I don't feel it would be good to share it like that. Is there a chance for you to increase the limit?. I have seen the question posted several times to no avail. Please believe it is necessary.
I do have a structured version I can send for your review, but unfortunatelly it won't run on the memory available.
Regards
Wcorredor
Hi,
How much of your script handles mapping CAN bus channels?
With our latest release enabling direct CAN mapping you might be able to reduce your code quite a bit. Check it out here:
https://www.autosportlabs.com/racecaptu ... -released/
How much of your script handles mapping CAN bus channels?
With our latest release enabling direct CAN mapping you might be able to reduce your code quite a bit. Check it out here:
https://www.autosportlabs.com/racecaptu ... -released/
Re: More Memory for Lua Script Section
Sub-functions can possibly save significant memory! Same thing happened to me on a RCPro Mk1 with my variable blinky shift light script. Here's what I did to address the issue:Mustangkev wrote:I've recently learnt how to write math channels on the pro2 and I'm now bumping up against the memory limit for this section.....
Before Lua out of memory with two new lines? (Mk1)
After Improved script for staged, variable blinking ShiftX light
I will send it this weekend. But we have allready used all of those technics.
We have made variables as local as possible, reduce the number of functions, eliminating comments, eliminated all constants that end up behaving as variables, but make code less structured and more difficult to understand and maintain. I am sure, as we have done, we can find a few bites here and there, but the available space is still very limited. I hope you consider increasing the limit as we would like to continue adding functionalities and channels and that is not possible anymore. We have even been using the lua minimizer which also helps a bit by eliminating comments and shortening variable and function names. Coding is not new to us, that is what I do for living as an electrical and computer engineer.
We have made variables as local as possible, reduce the number of functions, eliminating comments, eliminated all constants that end up behaving as variables, but make code less structured and more difficult to understand and maintain. I am sure, as we have done, we can find a few bites here and there, but the available space is still very limited. I hope you consider increasing the limit as we would like to continue adding functionalities and channels and that is not possible anymore. We have even been using the lua minimizer which also helps a bit by eliminating comments and shortening variable and function names. Coding is not new to us, that is what I do for living as an electrical and computer engineer.
Here goes the script. This version is structured, but won't fit in memory.
We do have a version with the very same functionality that runs, but had to make it spaghetti code, reduce functions, constants, comments and use the "lua minimizer" to make it fit.
The issue is that even with that version we can't add any more functionality as we are at the very limit. It also becomes very hard to maintain.
As you can see we have done a lot of things and have more ideas that can't implement.
Let me know if you have any questions on the code.
Regards
wcorredor
We do have a version with the very same functionality that runs, but had to make it spaghetti code, reduce functions, constants, comments and use the "lua minimizer" to make it fit.
The issue is that even with that version we can't add any more functionality as we are at the very limit. It also becomes very hard to maintain.
As you can see we have done a lot of things and have more ideas that can't implement.
Let me know if you have any questions on the code.
Regards
wcorredor
- Attachments
-
- E30Ver2.2AutoLabs.txt
- (8.43 KiB) Downloaded 361 times
Something that would help would be to have a Total Distance function.
Just as documented getGpsDist() returns "distance from the beginning of the logging session, or from the start finish line, if configured." Which means, once lapping, the distance gets reset to 0 every time one crosses the finish line.
Can you publish a function that always returns the distance from the start of the session? It would be very useful to calculate mpg more accurately, and predict how many laps are left with current fuel.
I am calculating total distance with lua by adding the travelled distance before it gets reset, but it is not completely precise as the last part (between ticks) gets lost. It is also more code and memory for scripting is very limited.
Just as documented getGpsDist() returns "distance from the beginning of the logging session, or from the start finish line, if configured." Which means, once lapping, the distance gets reset to 0 every time one crosses the finish line.
Can you publish a function that always returns the distance from the start of the session? It would be very useful to calculate mpg more accurately, and predict how many laps are left with current fuel.
I am calculating total distance with lua by adding the travelled distance before it gets reset, but it is not completely precise as the last part (between ticks) gets lost. It is also more code and memory for scripting is very limited.
Hi,
We'll definitely look at it for 2.12.0 firmware.
We'll do what we can to increase space, but as you can understand, we can't back the firmware up against the wall and risk system stability when running scripts that are too large - and cause other parts of the system to fail.
What would happen in those cases is the system wouldn't boot up at all, effectively soft-bricking it. So, we have to be very careful.
Thanks!
We'll definitely look at it for 2.12.0 firmware.
We'll do what we can to increase space, but as you can understand, we can't back the firmware up against the wall and risk system stability when running scripts that are too large - and cause other parts of the system to fail.
What would happen in those cases is the system wouldn't boot up at all, effectively soft-bricking it. So, we have to be very careful.
Thanks!