openrcforums

LUA scripting is now being added to ersky9x (from prov "d2" r221). This post will be updated as progress is made.

As at 30-May-2017, only standalone scripts are supported. These should be plaed in a /SCRIPTS directory on the SD card.
To run a standalone script, go UP LONG from the main screens, then RIGHT a few times to get to the LUA menu. Highlight the required script file, then press MENU LONG to run it.

From "d3" onwards, you may also have a "foreground" telemetry script running on a custom telemetry screen.

Be aware that I haven't fully tested every function, feedback welcome.

Available LUA functions:

lcd.refresh()
lcd.clear()
lcd.drawPoint(x, y)
lcd.drawLine(x1, y1, x2, y2, pattern, flags)
lcd.getLastPos()
lcd.drawText(x, y, text, flags)
lcd.drawTimer(x, y, value, flags)
lcd.drawNumber(x, y, value, flags)
lcd.drawSwitch(x, y, switch, flags)
lcd.drawRectangle(x, y, w, h)
lcd.drawScreenTitle(title, page, pages)

__ersky9x.getValue(index) [0-6 sticks/pots, 12-19 trainer1-8, 20-43 channels 1-24, 44-117 telemetry, 120-124 Extra Pots, 180-187 trainer 9-16,
200-207 channels 25-32]
__ersky9x.getValue(“name”) ["name" may be any telemetry name, sticks, pots, PPM1-8 or channels 1-24]
__ersky9x.playNumber( value, unitsIndex, decimals )
From "d3" onwards:
__ersky9x.sportTelemetryPop()
__ersky9x.sportTelemetryPush(PhyId, Prim, AppId, Value)
__ersky9x.getTime()
__ersky9x.getDateTime()
__ersky9x.idleTime()

Constants:
For lcd:
FULLSCALE
DBLSIZE
INVERS
BLINK
LEFT
PREC1
PREC2

For __ersky9x:
EVT_MENU_BREAK
EVT_MENU_LONG
EVT_EXIT_BREAK
EVT_UP_BREAK
EVT_DOWN_BREAK
EVT_UP_FIRST
EVT_DOWN_FIRST
EVT_UP_REPT
EVT_DOWN_REPT
EVT_LEFT_FIRST
EVT_RIGHT_FIRST
EVT_BTN_BREAK
SOLID
DOTTED
FORCE
ERASE
ROUND
LCD_W
LCD_H

I'll do a document detailing this as time permits.

Mike.

Thanks Mike, I wouldn't know where to start Wasn't never bothered about LUA.
I am finishing another Ar9x radio at the moment but probably at the weekend might be able to play with this..
Will have to find some examples to get me started..

João

Sent from my thor using Tapatalk

Joao, Do know of any LUA scripts for erSky9x on 9xtreme that have been posted? I need to just look at one to understand the programming syntax and commands.
Mike

I'm afraid I know nothing about LUA

João

Sounds great!!!

Mike,
I understand it's a bit too early to ask about support for the Betaflight PID adjustment LUA?

mmilan: I doubt anyone has posted a LUA script for ersky9x since I've only just posted firmware that supports it in any way.
A good starting point for LUA in general is this manual: https://www.lua.org/ftp/refman-5.0.pdf.

For what it is worth, this is the first test LUA script I've written to see if it is working, I don't really know LUA either (yet). andrewju: Definitely too early for that! Is there a LUA for openTx that does that I could look at to see what needs to be implemented for it?

Mike.

The Taranis PID script is found here http://www.nitbeatfpv.com/frsky-taranis-pid-settings and looks amazing.

Quite amazed that a programming language can be integrated into a tx - FrSky or Turnigy. Can't wait to see what happens. If I had a portion of talent for scripting I'd even give it a go!

Sent from my Nexus 9 using Tapatalk

MikeB wrote: ↑Thu Jun 01, 2017 9:40 am andrewju: Definitely too early for that! Is there a LUA for openTx that does that I could look at to see what needs to be implemented for it?

Here are several LUAs for OpenTX (I guess the main difference between them is the UI adaptation for different screens).

It would be great to have this working on ersky9x!



BTW, can you advise the most powerful / largest memory CPU for an AR9x board? I'm thinking of upgrading mine, in case this LUA thing will require some extra memory.

I've fitted an Atmel ATSAM4S8CA-AU to a board (as has someone else). This is working fine at 120MHz and has 128K of RAM (instead of 64K).
I did need to do some small code changes for it to work correctly. These detect the chip from the "CHIPID" and adjust automatically. However, currently, to use the extra RAM for LUA, I need to change the linker options, so I'm building ersky9xl_rom.bin (l for large).
It probably makes sense to use this as I could then make full use of the M4 core at some point.

Mike.

I don't think I could swap those chips myself. I just don't have the right tools

João

Mike,

Does ATSAM4SA16CA-AU (1Mb FLASH, 160kB RAM) make any sense within foreseeable future for our application? In my local store, these are sold even a little cheaper (about $9) than the ATSAM4S8CA-AU (about $13). Neither of these are in stock though, so I'll have to place an order and wait a few weeks for the chips to arrive.

jhsa wrote: ↑Thu Jun 01, 2017 11:51 am I don't think I could swap those chips myself. I just don't have the right tools

I thought you did that already... didn't you?!

I think I posted some photos of how I did that with just a soldering iron. Not much tools are needed, actually. But it does take some time (and a good flux) to get it right.

I did replace a couple Atmega chips on my radios, but these have more pins and they are even closer

João

Don't worry, I can always make it for you, if you wish!

Ha, thanks for the offer We will see.

João

Here is some info about ATSAM4S8CA-AU, Atmel AT91SAM3SC8, or Atmel AT91SAM3SD8 chip upgrade
for 9XR-PRO and the AR9X boards: (viewtopic.php?f=7&t=40&p=126414&hilit=A ... rd#p126414)
and (viewtopic.php?f=7&t=40&hilit=Atmel+ATSA ... 30#p126512).
Sky board too: (viewtopic.php?f=7&t=40&hilit=Atmel+ATSA ... 00#p126501)
and (viewtopic.php?f=7&t=40&hilit=Atmel+ATSA ... 50#p128140).
Some info on how to replace the chip: (viewtopic.php?f=95&t=3819&p=74105#p74046).

I think, if I was not dreaming of maybe someday, Mike talked about upgrading the Taranis chip also (could not find where it is).

Bob B.

Looking at the M4 core MCUs from Atmel, these seem like interesting options:

ATSAM4S8CA-AU (512kB FLASH, 128kB SRAM) - already supported by ersky9x
ATSAM4SA16CA-AU (1Mb FLASH, 160kB SRAM, 2kB HCACHE) - not yet supported / tested
ATSAM4SD32CA-AU (2x1Mb FLASH, 160kB SRAM, 2kB HCACHE) - not yet supported / tested

Mike, are you interested / do you think it makes any sense to add support for either of the latter two?
Whatever you decide, I'd be happy to become a tester, for sure!

Here we go again

João

I think that extending to yet more processor types will cause me problems. To properly support them, I feel I would need to have one in a radio myself. I already have 11(or 12 if you include the prototype Horus PCB) different transmitters/processors I use for testing firmware:
AVR 64 and 2561 (I've had to drop the 128!)
Taranis X9D/Plus/X9E/QX7
9XR-PRO
9Xtreme
SKY/AR9X/AR9X-M4

If you fit a '16 or '32 M4 processor, it may well work, but only use 128K of the RAM.

On LUA progress, I now have foreground telemetry scripts working as well as standalone ones. These run on one of the custom telemetry screens. I have added in the sending and receiving of SPort telemetry frames, and have successfully read a configuration value from a S8R using this.
With this, I think that PID adjustment should be possible, but may well need script(s) sorted specifically to do this. It may be necessary to limit exactly what is available in the script for the processors that only have 64K of RAM available, in order for the script(s) to fit.

I'll hopefully post a new test version later today with this in.

Mike.

"d3" now posted.

Mike.

I'm not sure whether I can reuse OpenTX scripts "as is", or I should apply some modifications first... I tried running unmodified BetaFlight scripts for X7 on my AR9x (still with a stock MCU) and the radio restarts as soon as I long-press "Menu" on a .lua file.

After the restart, please check the "BOOT REASON" screen and let me know if it shows "Watchdog".
What is the name of the script you tried running.
It will very likely need some editing, although I'd like to fix the reboot. Early days in getting this running fully.

Mike.

These are the scripts I tried: https://github.com/betaflight/betafligh ... cd7539.zip
There are two subfolders ('BF' and 'TELEMETRY'). Ersky9x doesn't see subfolders in the 'SCRIPTS' folder, so I had to copy all the lua files to 'SCRIPTS' (this may, probably, cause a compatibility issue as well).

I tried running all of the files: msp_sp.lua, ui.lua and BF.lua. It's somewhat strange. Sometimes nothing happens - no reaction at all. At other times, msp_sp.lua and ui.lua cause the radio to reboot. I didn't find a sequence to guarantee a reboot (or 'no action'), The exception was BF.lua. This one always had no action for me, but after I ran it, msp_sp.lua and ui.lua had no action, either. It's maybe like the BF.lua blocked something and prevented other scripts from running (and therefore rebooting the radio). But this is just a guess.

Yes, after the reboots, 'BOOT REASON' is 'WATCHDOG'. There's also '2' in the lower right corner and 'Chip 29AB 0A60' shown on the same screen.

It seems Mike chose a completely different API from OpenTX, so yes the scripts will need rewriting.

I suppose most people who requested Lua on ersky9x would have expected direct compatibility, their goal not being to write scripts but to use existing ones.

I'm looking in to this. I created a BF folder and put msp_sp.lua and ui.lua in it (BF.lua loads these from the BF directory. I've also added a 2-second watchdog delay on loading a LUA file. If I run BF, I now don't get a watchdog reboot, and quite a bit of RAM gets used, but nothing appears on the display. I need to add some error reporting.

The main change to the API I've done is to call the library ersky9x instead of openTx. I see the scripts only use "lcd." for the lcd functions, but don't use "__openTx." for those functions. I've just tested leaving out the "__ersky9x." and my test scripts still work.

So, most of the API should still work, but some things that are specific will need to change, e.g. getValue takes different names/numbers as parameter.

Mike.

Edit: Those .lua files are using some functions and constants I haven't implemented yet (e.g. drawFilledRectangle(), LCD_W, LCD_H).
I'll see about adding those, but I'll need to write the 'C' code for drawFilledRectangle() as I don't currently have that.

Mike,

This is not urgent for me at all. I don't expect to have much time for real flights over the next weeks.
Though, I still have evenings to do some bench testing, if you need my help.

Thanks!

I've made some progress. It seems the LUA code needs a lot of stack, I was getting the stack overflowing running BF.lua. I've got the missing functions and constants in, and the stack larger, so it runs. I'm running it without loading the msp_sp.lua file as well for testing.
It does use a lot of RAM though, I start with 81K free (Taranis QX7), and have only 24K free after BF.lua has run. This means it probably won't run on a 9XR-PRO with a processor with only 64K RAM in total!
Needing to make the main stack larger also reduces the amount of "spare" RAM.
At present, I don't know what is using all the RAM, it may just be because it needs to compile the script, so if I can sort pre-compiled scripts (don't know how they are created yet), maybe it will use less RAM.
I also don't know why this is in 3 parts, since the BF.lua loads ui.lua, which in turn loads msp_sp.lua. I think they could all be in 1 file, but maybe that uses even more RAM on loading.

Mike.

The reason we haven't even tried supporting Lua in radios with less RAM than the Taranis is that people regularly hit RAM limit even on that, so it was considered you barely could do anything useful with less and it would cause disappointment more than anything.

Good that the "__ersky9x." is not significant, I didn't know there was an equivalent on our side so it looked like that was added on purpose.

Ok thanks for starting the implementation of this Mike... count me in for testing both betaflight and raceflight versions.. I have both and I'm running both tramp and unify VTX's so I have ALL flavors so to speak.. re changing the chip in the 9xr-pro to 128 memory.. would there be a preferred chip that I can swap in now that will be supported? Seems the easiest option if we're going to hit RAM limits.. all the LUA scripts work on the taranis so 128 would appear to be enough

I am sure Mike will likely find a way of running LUA on the processors with less RAM. It is not the first time that he does what it seems to be impossible

João

Sent from my thor using Tapatalk