More Memory for Lua Script Section

Got a burning desire for a new feature? post it here!

Moderators: JeffC, stieg

wcorredor
Posts: 50
Joined: Thu Oct 27, 2016 6:29 pm

Post by wcorredor »

Could you finally get more memory for LUA in 2.12.0? How much?

brentp
Site Admin
Posts: 6274
Joined: Wed Jan 24, 2007 6:36 am

Post by brentp »

Hi,

Exploring the option to add more memory in Lua is scheduled for 2.13.0, which isn't too far off, as it will include the much requested native GoPro control.

We'll release it for beta earlier so you can test it. Probably in a couple of weeks.

Thanks!
Brent Picasso
CEO and Founder, Autosport Labs
Facebook | Twitter

brentp
Site Admin
Posts: 6274
Joined: Wed Jan 24, 2007 6:36 am

Post by brentp »

Update; The beta 2.13.0 firmware has 20% more memory available to Lua scripting. You can download the firmware for your unit here: http://podium.live/software

Thanks!
Brent Picasso
CEO and Founder, Autosport Labs
Facebook | Twitter

wcorredor
Posts: 50
Joined: Thu Oct 27, 2016 6:29 pm

Post by wcorredor »

I had a MK2 and recently got an Mk3. Memory limit went way down on the Mk3. My old scripts don't fit at all. I would guess it went down to allow a lua script of about 5K to about 3K.

Any thoughts?

brentp
Site Admin
Posts: 6274
Joined: Wed Jan 24, 2007 6:36 am

Post by brentp »

Hi,

The memory ceiling is identical for MK2 and MK3, and was raised 20% in the 2.13.0 firmware release, for both MK2 and MK3.

I suspect your memory limitation is being caused by a secondary factor, or it is right at the very edge of working / not working and could benefit from additional optimization.

Thanks,
Brent Picasso
CEO and Founder, Autosport Labs
Facebook | Twitter

wcorredor
Posts: 50
Joined: Thu Oct 27, 2016 6:29 pm

Post by wcorredor »

The only difference is the shiftX2. Your samples functions are tinny, but many, and they eat up the memory quickly. I put several together to save memory. But if I load, even after using lua minifier, anything with more that 3000 characters, it won't load it. I already optimized it, but to be able to use shiftX2, I had to remover several channels that I had on the MK2.

So I went back and loaded the working lua script that I have on the Mk2. I fits on the Mk2 and it won't fit on the Mk3 without any changes.

I also run into another problem, that I have seen on another post. Eventually, after trying several scripts larger than it would take, it would not load anything else. It would give something like "not enough memory to load script buffer" (can't remember the exact message). The problem is that once you get there, it is very difficult to get out of that loop. It won't even take a empty script, and not even a reset or reinstalling the firmware would get it out. The only solution was to open a saved configuration that happened to have an empty script. After that I could write scripts again, but with the size limitation I mentioned. This happened several times while trying different sizes and every time I had to use the same method to get it to work again.

brentp
Site Admin
Posts: 6274
Joined: Wed Jan 24, 2007 6:36 am

Post by brentp »

When you mention 'channels' are you talking about CAN mapped channels, or calculated channels?

One thing you might try is to issue a collectgarbage() command at the beginning of your onTick() function. That will sweep away any extra data lying around.

Your RCP units, what firmware are they on?
Brent Picasso
CEO and Founder, Autosport Labs
Facebook | Twitter

wcorredor
Posts: 50
Joined: Thu Oct 27, 2016 6:29 pm

Post by wcorredor »

13.5.1
Regular AddChannel calls. I had 12 and had to remove 5 of them. They do release some memory each. But like I said, when it fails loading, it gives the size: on the Mk2 about 5200, on the mk3 all it takes is about 3000. In every case I always use the minifier.
See attached script that loads on the MK2 but not on the Mk3. (you would have to use minifier even on the MK2)



I found the other post that had the same issue. I had the exact same situation last night, including the putty session trying to resetConfig. See the FAILED message within. I even tried his solution to no avail. Mine was to load a previously saved configuration with an empty script to recover the unit.

The following text came from that other post:

resetConfig: Flashing Default Script: FAILED
This is more of a bug report than a question expecting an answer.

After several iterations of modifying lua scripts I will eventually get the following error:


lua: Failed to allocate memory for script buffer.

When this error pops up the RCP gets very unstable and has to be hard-reset. Usually I would expect this error would happen with a lua script that is too long. However, even with lua scripts that I *know* have worked before and also tried examples from the wiki.

So, naturally, I went to do a resetConfig over the TTY (which usually fixes any bad state with RCP). And I get the following error when doing resetConfig:

Code:
0 peter@ld64 ~$ sudo miniterm.py /dev/ttyACM0 115200
--- Miniterm on /dev/ttyACM0 115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---



=============================================
Welcome to RaceCapture/Pro MK3 version 2.12.0
=============================================

Available Commands:

resetConfig : Resets All configuration Data to factory default Usage: resetConfig
testSD : Test Write to SD card. Usage: testSD <lineWrites> <periodicFlush> <quietMode>
startTerminal : Starts a debugging terminal session on the specified port. Usage: startTerminal <port> <baud> [echo 1|0]
setLogLevel : Sets the log level Usage: setLogLevel <level>
logGpsData : Enables logging of raw GPS data from the GPS Mouse Usage: logGpsData <1|0>
viewLog : Prints out logging messages to the terminal as they happen Usage: viewLog
setSerialLog : Enables/disables logging of serial device for debug purposes Usage: setSerialLog <port> <0|1>
flashConfig : Flashes the NVRAM with the current configuration of the LoggerConfig Usage: flashConfig
showTasks : Show status of running tasks Usage: showTasks
version : Gets the version numbers Usage: version
showStats : Info on system statistics. Usage: showStats
sysReset : Reset the system Usage: sysReset [bootloader 0|1]
lua : Enter the lua script interpreter. Usage: lua
reloadScript : Reloads the current script. Usage: reloadScript
RaceCapture/Pro MK3 > resetConfig

Flashing Default Logger Config: PASS
Flashing Default Script: FAILED <<<<< UH OH?!?
Flashing Default Tracks: PASS


I try this several times with the same result. And the lua script persists.

wcorredor
Posts: 50
Joined: Thu Oct 27, 2016 6:29 pm

Post by wcorredor »

I was able to do more research on this issue, but have serious problems.

Suddenly (as I thought it was the collectgarbage() that fixed it), I was able to load longer scripts again. Also suddenly it went back to the previous state, where it won't load scripts larger that 3000 bytes. I get several different error messages including "lua: Failed to allocate memory for scrip buffer" and also "startup script error (not enough memory)", "Failure: Failed to load script".

The same script that was running yesterday, no longer runs. It was about 4600 bytes and was running fine. I added one single line and then the limit dropped to about 3000 bytes. Deleting the line that caused the problem, won't fix it any more. Once you entered in this state there is no way out (that I know).

I tried resetConfig, reflashing both with 2.12.0 and back to 2.13.5 and somehow this limit is persistent.

Any thoughts? Is there any way to return to a factory condition, or to really erase everything. I have even tried to load a saved configuration with a lua script that is empty.

So as of now, my only solution would is to erase about 30% of the code; which of course I don't want to do.

Let me know, I am stuck, and I have plenty of experience. I have been programming Racecapture for over 2 years and even when I run out of memory before, just shortening the script would fix the problem. Not any more.

psfp
Posts: 49
Joined: Mon Aug 21, 2017 10:40 pm
Location: DF - Brazil

Post by psfp »

Would you mind to share your script so I can take a look? I found out the lenght of the script is not the determinating factor regarding the memory issues. It's more related to number of functions, variables and virtual channels. Even the "optional" arguments in virtual channel creation will make difference (min/max/unit). I optimized my script to run only two ShiftX2 functions, one for general data broadcast (txCAN) and another to receive the button status (used to adjust brightness in my case). I'm running 40 virtual channels, monitoring 6 parameters in the two ShiftX2's Alert leds and two more parameters using shift light section, in conjunction with RPM data.

My script length is 13126 bytes before minifier and 4461 bytes after minifier.
--Paulo

Post Reply