Throughout the years there has been multiple people porting MicroPython to our boards. Any of the MicroPython experts are lingering around still?
I am trying a couple of things and may make this an official proposal to GHI.
How cool would it be if you can load your board with either TinyCLR or python?! One gives you full programming and debugging and the other gives full scripts with REPL
Can you provide a link ? Thankās
link? Sorry, I did not understand
a link to install micropython on ghi boards if anyone does.
Micropython was ported to classic BrainPad, FEZ T18 and cerb40 at least but I am taking about the new stuff
Ok. Thankās.
Could MicroPython run alongside or inside TinyCLR? Giving the ability of MicroPhython of calling functions and methods in TinyCLR. This would allow for easy customization of a device and Python scrips could easily be changed on demand.
A use case I would use it for is remote sensor monitoring/alarming. The logic for alerts, based on time of day or sensor readings, unique algorithms, would be defined and run in the Python script. When the alarm conditions are met Python calls functions in TinyCLR that push the information up to the cloud for further processing/alerts, etc. If the monitoring requirements change a new Python script could easily be pushed down to the device. TinyCLR would run all the critical software functions and maintaining the connections required for command and control. If the Python script were to go crazy and lock up TinyCLR could kill it and send an alert.
Hereās an alternative ā¦ how about a micro-kernel that runs WASM? Then you could run and debug C, C++, Rust, C#, F#, Go, Kotlin, Swift, D, and even Pascal? Who needs all the limitations of uPython when you have that?
Admittedly, you still need a PC, Mac, or Linux, because there would be no REPL on the chip but also, you can use a PC OR Mac OR Linux. 
Why isnt it possible to like a post multiple times?
@skeller Is spot onā¦!!
We have had to hand roll our own very primitive scripting language to handle the ever changing environs, sensors, yadi-yada, that edge device(s) must deal with.
We call this primitive scripting language āpseudoLadderLogicā.
Such is currently at the state of being far less than the most basic Ladder Logic compiler.
Use Case:
On boot, device reads config file from SD.
config file defines IO point parameters, say:
DI: Trigger Time
DO: Function - This is the pseudoLadderLogic
AI: Scaling, Limits, etc
Device needs to turn on Motor:
if DI (E-Stop) == true and AI (Pressure Sensor Measuring Water Depth)
I donāt want to spend dev time on pseudoLadderLogic, would rather just call an assembly that already has all baked in.
Not sure
Hit wrong key and replied before readyā¦
Device needs to turn on Motor:
If DI (E-Stop) == true
and
AI (Pressure Sensor Measuring Water Depth) = 15ā
This is simple example, things get a wee more complexā¦
I donāt want to spend dev time on pseudoLadderLogic, would rather just call an assembly that already has all baked in.
Not sure if @mcalsyn is talking down the same lines with WASM, or if WASM is a total tinyCLR replacement or what-not.?
@Pablo0031 - We āNEVERā forget suchā¦!
The topic was MicroPython and/or variants and possibility of .tinyCLR to run a script interpreter.
Assume script interpreter would run on its own thread.
script commands would be loaded in an object
object ref (pointer) passed from āuser codeā to interpreter via a queue
interpreter could signal whatever using Thread WaitHandles or whatever mechanism.
@Pablo0031 :
The point was āI donāt have all the time in the worldā
Looking for a Script interpreter (engine, VM), which could run within .tinyCLR OS environment.
Cost of such code is not of concern.
What I am hearing here is that you guys want a way to load code/script that loads-complies-runs at runtime.
We already have something for you. Did you think we have ran out of tricks? We are just getting started.
Oh no my eyesā¦ It hurts seeing these words on this modern forum
Ha, understoodā¦
No need for āLadder Logicā type of dev environment or such.
Script dev environment need be nothing more than notepad.
The Script engine, expecting properly formatted script, would just execute the script.
Perhaps this script engine would consume jsonā¦does not matter to me.
The json would qualify params such as:
inputs[ ]:
outputs[ ]:
script:
waitHandle referenced callback or such: ā¦again, the mechanics of all is whatever the specs say
ā¦If you have consumed any manufactured product, one can bet the odds that Ladder Logic was used in the process.!
Bingo, such is exactly what is meant.
Perhaps a basic-like script language will be a fit?
I still use it a lot in other projects. Pray for my emancipation.
So I have re-read @skeller and @mhardyās text a few times, and I understand the use case as : I need āsome but not all of my programās behavior to be dynamic codeā. So, if uPython or TinyBASIC or Lua or WASM could run hosted within a TinyCLR C# program, is that sufficient or does the whole program need to be parsed at runtime?
I think there are uses for writing whole programs in interpreted (REPL) languages [uPython, TinyBasic, Lua] and for WASM (bytecode interpreter), but it sounds like you are looking for the ability to dynamically update a small piece of your code, not write an entire program that way, and your current solution was to home-bake a ladder-logic engine. Correct?