09:26 <wassasin[m]> I have the vague plan to run an interpreter on an embedded cortex-m33 platform for some user scripts. These are not 'trusted' in the sense that they may run indefinitely. When stuck I would like to kill the script, and I think this can only be done with some kind of pre-emption/threading. Any thoughts? Anyone know of some lightweight threading implementations?

09:30 <Lumpio-> If you know any indefinitely running things would be inside the script and not inside some "system call" to the outside of the interpreter you could just put a timeout in your interpreter loop, for a small performance penalty

09:30 <Lumpio-> E.g. your interpreter probably has some kind of "main loop" where it runs stuff, just put a "if time() > deadline" inside it.

09:30 <diondokter[m]> wassasin[m]: I looked at something like this before like a year ago. There are no great options AFAIK.

09:30 <diondokter[m]> Best I can think of is having some timeout interrupt which can set some var in the interpreter so it quits running the script.

09:30 <diondokter[m]> Depending on your security situation, you could run your system in the secure mode and the script in the non-secure mode of the trustzone. That way you can make sure the script doesn't disable the interrupt.

09:31 <wassasin[m]> Lumpio-: good point, I could add that

09:31 <Lumpio-> Now if you expect the script to call into your (presumably Rust) code and _that_ code could get stuck, then you might need some kind of pre-emption... but tearing down a thread is not easy

09:31 <wassasin[m]> The current idea is to use a wasm interpreter like tinywasm or stitch

09:31 <wassasin[m]> Submitting a patch to these interpreters would be best

09:33 <wassasin[m]> It's a trustzone chipset so I am planning on running the interpreter in nonsecure mode

09:34 <wassasin[m]> Still, some C libraries require threading support (disregarding thread teardown), so having a lightweight Rust implementation for this seems very useful

09:35 <diondokter[m]> Yeah I once looked at existing projects, but all are like `fn run() -> !`. There were none that I could find that were `fn poll()`

11:05 <JamesMunns[m]> fwiw, I have a (very bad, very unsafe) forth implementation that supports blocking or async intrinsics, and has the concept of a "fuel counter" so you can manually yield after the interpreter makes N steps

11:06 <JamesMunns[m]> it's really not fit for production, but if you want inspiration I can share. This approach would be suitable if the "intrinsics" (e.g. native functions) are trusted, but the user submitted code (e.g. scripts) are not trusted.

11:07 <JamesMunns[m]> https://github.com/tosc-rs/mnemos/tree/main/source/forth3

11:10 <JamesMunns[m]> but in general, afaik the two approaches to bounded running are either:

11:10 <JamesMunns[m]> * Use threads, kill the threads (but then how do you reclaim resources if necessary? If you don't need to or can reset/remake them, then this is probably the best option

11:10 <JamesMunns[m]> * Have your VM count some kind of "interpreter fuel" that forces a yield. This is how many full VMs like BEAM/Erlang work

17:04 <scorpion2185[m]> lulf does it provides things for working out? I saw workout in the video

17:04 <scorpion2185[m]> s/provides/provide/

17:35 <lulf[m]> <scorpion2185[m]> "lulf does it provides things for..." <- I only got it to the stage where I can sample the values, but getting a heart rate requires some more processing that I haven't gotten to.

19:43 <shilga[m]> Hi,

19:43 <shilga[m]> I'm using the embedded-sdmmc crate and I noticed that the sd-card is getting warm although I'm not accessing it at all. Is it possible that the crate does not let the card into low-power mode?

19:54 <thejpster[m]> The crate certainly doesn’t actively send any low power commands but I’ve never noticed my cards get hot

19:56 <shilga[m]> thejpster[m]: It's not getting hot. But it is certainly warmer then the rest of the pcb. And that means it's drawing current, which I would rather not do. In low-power mode not accessing the card after it was initialized it should draw less than 1mA. It should certainly not get warm. I guess I will measure the actual current.

20:00 <thejpster[m]> Feel free to read the spec and send a PR to add an API for sending the relevant cards.

20:00 <thejpster[m]> s/cards/commands/

20:06 <shilga[m]> <thejpster[m]> "Feel free to read the spec and..." <- I have to say I'm not so firm with sd cards commands. I can't find a comprehensive list, but if I find the culprit I will do for sure.

20:19 <thejpster[m]> You probably just need the Simplified Specification from the SD Card Association. If it’s not in there then it’s in the full spec which costs a lot of money and so isn’t happening.

20:27 <dirbaio[m]> can't you 🌈obtain🌈 the full spec somewhere? :D

20:28 <dirbaio[m]> * spec somewhere magic? :D

20:58 <whitequark[cis]> i have the physical layer non-simplified one

20:58 <whitequark[cis]> ver 3.00

20:59 <whitequark[cis]> thank you vanessa chui of netcom digital (hong kong)

22:22 <shilga[m]> I see in the well-used Arduino lib that the author sends a 0xFF byte on the SPI without the CS asserted after each command so the card goes into sleep mode. That is sadly not so easily done with the crate as it does not have direct control over the CS-pin. https://github.com/greiman/SdFat/issues/90#issuecomment-353599464

22:42 <shilga[m]> As a short test I manually send some clocks to the sd card without asserting CS after I'm done reading what I need from the sd card. That seems to help, the sd card now does not even get slightly warm. It's even measureable, about 20mA less power draw of the whole system.