MicroPython experts

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

1 Like

Can you provide a link ? Thank’s

link? Sorry, I did not understand

a link to install micropython on ghi boards if anyone does.:thinking:

Micropython was ported to classic BrainPad, FEZ T18 and cerb40 at least but I am taking about the new stuff

1 Like

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.

1 Like

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. :wink:

6 Likes

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

1 Like

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.?

1 Like

@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.

1 Like

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.

2 Likes

Oh no my eyes… It hurts seeing these words on this modern forum

3 Likes

@Gus_Issa

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.!

1 Like

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?