yep, to me it sounds like what they want is Application Domain
a feature from old netmf days and already part of TinyCLR that lets you dynamically load assemblies at runtime
Application Domain can work but I think, at least in my mind, a script type language would run in a bit more of a protected âsandboxâ; limiting what could be executed and protected from hogging all the resources. Application Domain, if written wrong, and deployed to a remote device could render a device unreachable.
your c# code also runs not native but managed even if i would not name it sandbox
btw Watchdog takes care if your code tries to destroy the deviceâŚ
@Austrian_Dude, You are correct Watchdog could kick the device to reset. I am not ruling out App Domain and I donât want to minimize its usefulness, I am actually looking at it closely for other more advanced customization. But in defense of a scripting language, it does make it simpler to get the job done. It doesnât require a compiler and if using microPython, or similar, it could be simple enough for the customer to create their own scripts.
The Dude from Austria is right of course - you can do that, and it can be sandboxed from most bad behavior (thatâs what App Domains do), but if you want field-configurable devices, the AppDomain approach also requires that you have a compiler chain and the metadataprocessor to turn it into a loadable assembly. If you have some sort of hosted interpreter, you can more easily write an editor that can be hosted in a web page or in an app (either of which could run on more than Windows and without the C# compiler and friends) but which changes your deviceâs logic in the field.
âŚit also strikes me that this is a much less challenging than doing a full Basic or Python interpreter.
If you have something that can do math, loops, branches and call a sandboxed set of functions that your host program provides, then you have a generalized (and more friendly) equivalent to the ladder logic.
What I am saying is that for the 90% case of creating control scripts, you donât need a full language. You just need math, flow control, conditional exprs, assignment exprs, and call-outs.
Using a REPLâs and interpreters for education or hobby and so forth is a completely orthogonal problem, and much more expensive to implement than just âmake my program support logic defined at runtimeâ
Bullseye mcalsyn:
âIf you have something that can do math, loops, branches and call a sandboxed set of functions that your host program provides, then you have a generalized (and more friendly) equivalent to the ladder logic.â
âWhat I am saying is that for the 90% case of creating control scripts, you donât need a full language. You just need math, flow control, conditional exprs, assignment exprs, and call-outs.â
We are talking very simple stuff:
if
else if
else
Basic comparison stuff: ==, <, >,âŚetc
&&
||
Goto (jump)
âŚthats about it, timers, loops and stuff can be handled by .tinyCLR OS User code and need not be part of Scripting.
Back to basic example where Motor/Pump is turned on based on Reservoir Water Depth.
Turn on Pump when water level above High Setpoint, donât turn off pump until water level below Low Setpoint.
UC = .tinyCLR OS User code
SC = Script
An AI reads a Pressure Sensor and determine water depth (Water Column Inches)
Low - 10â
Mid - 60â
High - 100â
dead-Band Value - 1â
Filtering Function - EMA
UC would deal with the setpoints, dead-band, and filtering.
UC would determine when water level above High setpoint
UC would determine when water level below Low setpoint
Call SC Engine with script like: (input param, script, output param)
UC determines water above High Level
Call SC Engine with: (âtrueâ, âif (true): OUT1=On : else : OUT1=Offâ, âOUT1=Onâ)
input param = âtrueâ
script = âif (true): OUT1=On : else : OUT1=Offâ
output param = âOUT1=Onâ
The SC Engine ran the script, input param = âtrueâ and set output = âOUT1=Onâ
UC code would get âOUT1=Onâ value back and enumerate what such means.
UC determines water below Low Level
The SC Engine ran the script, input param = âfalseâ and set output = âOUT1=Offâ
UC code would get âOUT1=Offâ value back and enumerate what such means.
So, such exercise may lead one to think why not just do all in UCâŚwhy would one need SC.?
Because, edge-device has many inputs and outputs.
The inputs and outputs are mapped to reality based on what the customer wants to happen.
What the customer wants to happen can vary widely.
The SC allows customization based on customer needs.
1 Like
Yup - exactly the sort of thing I was thinking about. I did something similar in Lua for a native-code project, but even Lua was overkill.
Now, for compactness on the wire and in memory, I might suggest that a web app or desktop app front-end do the work of transforming diagrammatic or textual programs into byte codes. Then those byte code programs can be stored in Amazon or Azure as Device Twin data if folks are so inclined (since they are part of the deviceâs configuration state).
I am fine with as simple as possible. Such being:
Write script in notepad, save as.csv file, OTA to edge-deviceâŚletâer run.
1 Like
Please stop Gus, please, donât spill the beansâŚ
Yeah Gus⌠Stop⌠Stop⌠Donât do it⌠
Yes! Spill the beans!
Return of the RLP ?
Today, this calculated the fibinacci series âŚ
puts("Tritium v" T3_VERSION " on STM32F747-Disco, build " __DATE__ " " __TIME__ "\n");
run_wasm();
The original program was written in C and compiled to WASM and generated 62 bytes of WASM bytecode.
I thought this was an idea⌠Now it is working?!
Yeah. Color me surprised too.
But that was the easy bit - it is months and months away from being ârealâ in any sense, and not my top priority right now 
I am for the return of RLP
@jooos, I would be for the return of RLP too but a scripting language would solve a different use case.
Agree with @skeller about it being a different use case, but if RLP comes back it needs to come back with dynamic linking and relocation at upload (flash) time, so that you can compose native modules together without needing to have them statically linked to an absolute address. That way we could ânugetâ native modules along with their interpreter code - add a nuget and get both the native and interpreted parts. The firmware then becomes a just micro-kernel and interpreter with only the firmware overhead that your app requires. Native code driver elements only take up space if you need them in your higher-level code.
3 Likes
I remember Gus talking out a basic type language some months ago⌠remember??
1 Like