Page 1 of 2

More Memory for Lua Script Section

Posted: Wed Mar 22, 2017 1:53 am
by Mustangkev
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.

Posted: Fri Mar 24, 2017 1:04 am
by brentp
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!

We do need more memory for lua scripting

Posted: Sat Apr 22, 2017 3:38 am
by wcorredor
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

Posted: Sat Apr 22, 2017 3:46 am
by brentp
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/

Posted: Sat Apr 22, 2017 3:32 pm
by wcorredor
None. No CAN bus on a BMW E30. (1989)
Wcorredor

Posted: Sat Apr 22, 2017 3:47 pm
by brentp
Hi, got it. Can you share you script so we can check it out? you can email it or post it here if you'd like.

Thanks,

Re: More Memory for Lua Script Section

Posted: Sun Apr 23, 2017 10:23 am
by GTIspirit
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.....
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:

Before Lua out of memory with two new lines? (Mk1)

After Improved script for staged, variable blinking ShiftX light

Posted: Sun Apr 23, 2017 5:29 pm
by brentp
Right!

Another thing that saves significant memory is to use local variables wherever possible, especially inside of functions.

Happy to review and help optimize scripts.

Posted: Thu Apr 27, 2017 2:17 pm
by wcorredor
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.

Posted: Thu Apr 27, 2017 5:22 pm
by brentp
Thanks, we'll watch for your script. We'll see what we can do in order to improve things for you.

Posted: Sat Apr 29, 2017 2:44 am
by wcorredor
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

Posted: Sat Apr 29, 2017 2:59 am
by wcorredor
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.

Posted: Sat Apr 29, 2017 3:01 am
by brentp
Thanks, I'll do some analysis and get back. Not wholesale opposed to increasing memory available to script, but need to ensure we do it carefully so we don't compromise the system's stability, and provide adequate margin as well.

Posted: Mon Jun 19, 2017 5:09 am
by wcorredor
Never got your comments on our script. Did you find a way to optimize memory usage?
Any news on increasing even a bit?

Thanks

Posted: Mon Jun 19, 2017 5:31 am
by brentp
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!