Stream: general

Topic: Begining the process of proposing an Embedded SIG

Chris Woods (Feb 16 2024 at 16:48):

Hi Folks, A group of us are considering setting up an embedded / industrail special interest group. This group would focus on supporting the needs of the already deployed embedded WASM customers by providing tooling, notes and recommendations for useage. It could also, I hope would, provide guidence and support via use case examples / user scenarios / requirements to the standardization bodies. We're still at a very early stage of just sketching out the goals for the SIG. I'd love your thoughts on this, and if there was anything specific you feel such a SIG could provide that would help the overall community. cc: @Ayako Akasaka @Wang Xin @Marcin Kolny

Ralph (Feb 16 2024 at 16:52):

Hey Chris, I think it's a great idea. There are things underneath wasm that require more careful thought about where and how they should fit together.

David Bryant (Feb 16 2024 at 17:17):

I very much like the idea of having an embedded/industrial SIG and applaud the plans to work that out. I can imagine there are a number of related platform, hardware, and tool chain use cases that would absolutely benefit from collaborative focus, yielding enhancements both to existing project work and the possibility of new projects coming into existence.

Dan Gohman (Feb 16 2024 at 18:01):

Hi Chris, I agree, this is a great idea. I've been working on a sketch of what a Wit interface for I²C, GPIO, etc. might look like, largely derived from embedded-hal. It'd be great to talk more about what a bigger picture might look like.

Chris Woods (Feb 16 2024 at 19:20):

Hi Dan, that's awesome, and overlaps with some of the work I've seen from academia and internally. This would be an ideal topic for the SIG.

Dan Gohman (Feb 17 2024 at 00:48):

I've now put together a simple project that uses that embedded.wit file to build a component that (in theory) blinks an LED: https://github.com/sunfishcode/hello-embedded

Christof Petig (Feb 17 2024 at 18:01):

Hi Chris, count me as interested in this group. I feel that functional safety and ahead of time compilation are my key interests.

I can also contribute some experience on using preview2 modules with wasm2c or w2c2, sadly there are yet some gaps in (host) bindgen for this.

Dan Gohman (Feb 17 2024 at 18:15):

I've now added a host implementation that simulates an LED and a timer and can run the component, to the hello-embedded repo linked above.

Dan Gohman (Feb 17 2024 at 18:16):

In case anyone else would like to build it, note that it requires this fix in cargo-component .

Ayako Akasaka (Feb 19 2024 at 07:12):

Thank you for setting this up. @Chris Woods
We want to discuss

• How to reduce memory usage and processing overhead to withstand the use of embedded products, the I/F that should be there for this purpose
• The appropriate level of abstraction I/F for HW that takes advantage of the portability of Wasm.

I look forward to working with you.

Milan (Feb 19 2024 at 17:16):

I'm interested from an industrial control protocol point-of-view (serial, gpib, lxi)! Seems like component model virtualization could lead to an interesting set of experiments on instrument control HALs and testing simulation.

Catherine (whitequark) (Feb 20 2024 at 01:30):

This is exciting! One thing that immediately jumped out at me is the SPI pin names. I would expect controller/peripheral (COPI/CIPO) following this resolution. (It's also just a better name from a technical perspective than "sub", and is free from the weirdly sexual connotation of that word.)

Catherine (whitequark) (Feb 20 2024 at 01:35):

I also have a design question. In pwm.set-duty-cycle, you have both set-duty-cycle/max-duty-cycle and set-duty-cycle-fully-off. Isn't the latter completely redundant? It seems to me that having both has essentially no benefits in terms of usability (it's slightly shorter at the cost of having one more function to remember and two ways to write the same code) but has the drawback that the two implementations can desync, that proxy components will have to proxy those calls too, and so on.

Should we have these methods?

Catherine (whitequark) (Feb 20 2024 at 01:39):

A perhaps less interesting, but still (to me at least) interesting question is that of spi.operation.delay-ns. This is undeniably very useful, and there are plenty of cases (ADCs for example) where one has to insert wait states for the device to work correctly. If I recall, in the Rust Embedded discussions, this operation was added because of practical necessity. I'm wondering if we should not reconsider it, namely, replace it with something more composable in the Wasm world, where we can coordinate delays between several peripherals, which does come up a lot more often than you wish it would.

Dan Gohman (Feb 20 2024 at 04:18):

Catherine (whitequark) said:

This is exciting! One thing that immediately jumped out at me is the SPI pin names. I would expect controller/peripheral (COPI/CIPO) following this resolution. (It's also just a better name from a technical perspective than "sub", and is free from the weirdly sexual connotation of that word.)

Main/sub is Wikipedia's current choice, but I'm happy to switch to controller/peripheral, COPI/CIPO, etc., and cite that OSHWA resolution. Thanks for that link!

Dan Gohman (Feb 20 2024 at 04:23):

Catherine (whitequark) said:

I also have a design question. In pwm.set-duty-cycle, you have both set-duty-cycle/max-duty-cycle and set-duty-cycle-fully-off. Isn't the latter completely redundant? It seems to me that having both has essentially no benefits in terms of usability (it's slightly shorter at the cost of having one more function to remember and two ways to write the same code) but has the drawback that the two implementations can desync, that proxy components will have to proxy those calls too, and so on.

Should we have these methods?

This is a good point. These methods are provided methods in the embedded-hal trait these are based on. If there were ever a reason to implement them differently, then it'd be valuable to have them, but looking at them more closely, that does seem pretty unlikely. So I'll remove them.

Dan Gohman (Feb 20 2024 at 04:27):

Catherine (whitequark) said:

A perhaps less interesting, but still (to me at least) interesting question is that of spi.operation.delay-ns. This is undeniably very useful, and there are plenty of cases (ADCs for example) where one has to insert wait states for the device to work correctly. If I recall, in the Rust Embedded discussions, this operation was added because of practical necessity. I'm wondering if we should not reconsider it, namely, replace it with something more composable in the Wasm world, where we can coordinate delays between several peripherals, which does come up a lot more often than you wish it would.

We can certainly reconsider it. The main question is, what should the interface look like?

Stephen Berard (Feb 20 2024 at 16:58):

Hey Chris - Atym would love to participate in an industrial-related SIG. We’ve built an orchestration and management solution using Wasm for constrained devices. We’re committed to standardization and it would be great to collaborate.

Catherine (whitequark) (Feb 20 2024 at 18:28):

Dan Gohman said:

We can certainly reconsider it. The main question is, what should the interface look like?

This is a very high-level description, but to me, the underlying problem would be solvable with an event scheduling system, where:

• you can start two concurrent processes simultaneously (e.g. toggle two GPIOs at once to make data that was inserted into shift registers previously take place--think of DACs for example)
• you can start a process after the end of another process, and potentially a delay between these (e.g. start readout from ADC a few micros after initiating conversion)
• you can start a process after the start of another process, with a delay (e.g. periodically starting readout)
• you can wake the CPU up at any arbitrary point that can be specified with these rules
• you can loop the entire thing so it continues forever

If you look at this system at a very high level, this is basically a mini-language for a common subset of hardware acceleration for various peripherals. You could map this to what e.g. STM32's peripherals are capable of and reap the benefit of lower power consumption where you don't need to start the PLL for the main core, etc.

You could also say that this is out of scope and any delays should be inserted using an async function driving these component interfaces because it's fully redundant with delay, in a similar way as the set-duty-cycle-fully-off is fully redundant. (No SPI peripheral I know of has built-in delay functionality, so the implementation of the embedded-hal trait would have to use some sort of hardware timer, shared or dedicated, which is what a normal async delay would use too. I could of course be wrong here, but this is what my experience indicates.)

I think either solution would work well for embedded components. My personal API design principles suggest implementing the latter ('just write an async function') before the former ('event scheduling system').

This is probably clear by now, but I'd be interested to participate in the Embedded SIG ^^

Chris Woods (Feb 21 2024 at 01:32):

Wow - some great conversations happening already, this is pretty awesome! Thank you all. Please do keep the suggestions going. There definately does seem to be a need and a desire to tackle the problems within the embedded space. I think moving to a structured conversation with a SIG would be pretty awesome.

I'll continue on with the next step in getting the SIG going, that's the paper work / git updates and start coordinating with the BCA.

Dan Gohman (Feb 21 2024 at 03:40):

I've now added a linux-embedded-hal host to the hello-embedded demo. I don't have a board to test it on, but if I wired everything up right, on a board configured for it, that should let the same guest blink an actual LED.

Pascal Bach (Feb 21 2024 at 07:26):

Dan Gohman said:

I've now added a linux-embedded-hal host to the hello-embedded demo. I don't have a board to test it on, but if I wired everything up right, on a board configured for it, that should let the same guest blink an actual LED.

This is awsome I like the fact that it is based on the Rust embedded-hal. We can benefit from their experience in designing a portable HAL layer.

Wang Xin (Feb 21 2024 at 08:22):

Another topic we talked before is safe reentry of wasm code by the interrupt handing.

Nuno Pereira (Feb 21 2024 at 15:13):

Dan Gohman said:

I've now put together a simple project that uses that embedded.wit file to build a component that (in theory) blinks an LED: https://github.com/sunfishcode/hello-embedded

Pretty cool! Wondering if the plan is to do the same split rust embedded hal does between blocking traits and async ones?

I think c guests are particularly relevant here, and these could be more welcoming of non-async interfaces. Android's Context Hub Runtime Environment (CHRE), might be an additional design point worth checking out:
https://source.android.com/docs/core/interaction/contexthub

The CHRE is for C/C++ but has several frameworks called Platform Abstraction Layers for stuff like sensor IO, location, audio, and more.

David Bryant (Feb 21 2024 at 17:13):

Dan Gohman said:

I've now added a linux-embedded-hal host to the hello-embedded demo. I don't have a board to test it on, but if I wired everything up right, on a board configured for it, that should let the same guest blink an actual LED.

This begs a question I've been wanting to ask -- what hardware is a good target for your demo app, @Dan Gohman? I have a workbench cabinet full of various MCU boards and would love to give the app a try. And if I don't have any suitable hardware I know where to get more. :-)

Dan Gohman (Feb 21 2024 at 17:16):

The host impl I built is based on linux-embedded-hal, which should support Raspberry Pi and similar boards.

Dan Gohman (Feb 21 2024 at 17:22):

It looks like there are embedded-hal drives for FTDI boards, and others. I haven't looked into it much yet, but the nice thing about the API being close to embedded-hal is that there is an ecosystem out there that we can directly use.

Chris Woods (Feb 21 2024 at 17:30):

David Bryant said:

Dan Gohman said:

I've now added a linux-embedded-hal host to the hello-embedded demo. I don't have a board to test it on, but if I wired everything up right, on a board configured for it, that should let the same guest blink an actual LED.

This begs a question I've been wanting to ask -- what hardware is a good target for your demo app, Dan Gohman? I have a workbench cabinet full of various MCU boards and would love to give the app a try. And if I don't have any suitable hardware I know where to get more. :-)

I shared some of this perspective at the last W3C in person meeting. Once we get to the devices which run Linux, the question becomes - Why WebAssembly? - Why not just a container? - and you can, if you are careful make really small containers.

The sweet spot for WASM are devices which run an RTOS, and are not capable of running Linux and Containerized applications. Roughly speaking, this is devices with 16 - maybe 8megs of RAM or less. Something like an STM32, or an ESP32.

I love the discussion here already, it's very cool, and Dan's work is really interesting - the Pi is a great platform to develop with - and a fantastic starting point, but the final target hardware is likely to be considerably cheaper and hence less powerful than a Pi.

This is a fantastic discussion in general for the SIG and community, what would be a realistic minimal hardware footprint to target?

Edit: Type-o, I used W2C instead of W3C ... you know you've been playing with WABT for too long when... ;p

Dan Gohman (Feb 21 2024 at 17:32):

Looks like I need to pick a different host driver, to avoid my API being seen as "The Pi is a great platform, but" :lol:

Chris Woods (Feb 21 2024 at 17:34):

Dan Gohman said:

Looks like I need to pick a different host driver, to avoid my API being seen as "The Pi is a great platform, but" :lol:

For speed of development and iterating through interfaces, it's totally the right platform! :grinning:

Dan Gohman (Feb 21 2024 at 17:43):

Ok, this is a little more work than I'm looking to do right right now, but, there are embedded-hal implementations for ESP32, STM32H7 and others.

David Bryant (Feb 21 2024 at 17:47):

Chris Woods said:

The sweet spot for WASM are devices which run an RTOS, and are not capable of running Linux and Containerized applications. Roughly speaking, this is devices with 16 - maybe 8megs of RAM or less. Something like an STM32, or an ESP32.

What about that same class of hardware but with no OS whatsoever?

And +1 to being fine developing and iterating on the Pi, especially in terms of engaging lots of developers.

Ralph (Feb 21 2024 at 17:59):

Dear @Chris Woods do not get me started on the usage of containers, pretty much anywhere intending to pretend either portability or security. But they're useful, they sure are.

Ralph (Feb 21 2024 at 18:00):

This, however, @Chris Woods, is a critical point to get clear on: "This is a fantastic discussion in general for the SIG and community, what would be a realistic minimal hardware footprint to target?"

Ralph (Feb 21 2024 at 18:02):

once the resource constraints of a device become limiting even to wasm, then those things will remain "artisanal" or native targets. Wasm brings some security and radical portability (containers, why bother in truly constrained environments?), but scenarios that do NOT benefit from those features are not likely targets for wasm. So your question is the first correct one I think: where is the standard hardware/OS boundary underneath which it makes no sense to use wasm/components?

Ralph (Feb 21 2024 at 18:32):

and everyone will likely differ, but that conversation will tend to clarify which features do and do not have persuasive power with someone, and clarity is always good.....

Chris Woods (Feb 21 2024 at 21:05):

David Bryant said:

Chris Woods said:

The sweet spot for WASM are devices which run an RTOS, and are not capable of running Linux and Containerized applications. Roughly speaking, this is devices with 16 - maybe 8megs of RAM or less. Something like an STM32, or an ESP32.

What about that same class of hardware but with no OS whatsoever?

And +1 to being fine developing and iterating on the Pi, especially in terms of engaging lots of developers.

Yup, totally viable too; you don't need an RTOS, it is conceivable, that someone in the future produces a very thin layer, a BSP that get's a minimal runtime executing, that is very true. It's guess that that layer will start "thick" with an RTOS, but will migrate to something much thinner; much in the same way we've seen unikernels develop.

Christof Petig (Feb 21 2024 at 22:27):

Dan Gohman said:

Catherine (whitequark) said:

Should we have these methods?

This is a good point. These methods are provided methods in the embedded-hal trait these are based on. If there were ever a reason to implement them differently, then it'd be valuable to have them, but looking at them more closely, that does seem pretty unlikely. So I'll remove them.

I will need to look up the details but I recall from either the embassy or embedded WG matrix that a fraction can't represent all hardware states and thus the second one was added, dirbaio will know the details as he made the change.

Also please dare to dream small, arduino might already be large enough to do wasm aot compilation on chip, an interpreter will surely fit.

Chris Woods (Feb 21 2024 at 22:30):

@Ralph Thinking about the smallest scenario in which the benefits of WASM make sense is a great idea and I’m happy to share some thinking and some research here, and I mean this as a way to provoke discussion and debate – I hope everyone can chip in your own view too.

There are perhaps three key things, to think about with regard to the smallest possible target, these are:

1. Defining a viable minimal set of functionality. By this I mean to leverage the benefit of portability, isolated execution and security, we'd need some way of remotely deploying and managing the life cycle of a WASM element – this at the very least implies some form of networking stack. (Others may not need the remote life cycle management and we could reduce the platform further removing connectivity and life cycle from the software footprint. – and this would be a good point to discuss too)
2. The 64kb WASM page size, sets an effective limit. The smallest WASM enabled application is going to need 64kb of RAM for linear memory, additional ram for the function table, bytecode, runtime state, stack pointers, and runtime code, plus whatever RTOS or elements we have today to provide threading, heap and peripheral management. This gives a minimal executable WASM application. (As Keith pointed out, using WASM2C and dropping the effective size of runtime down to something smaller allows us to go a little further.)
3. Today's compilers introduce another set of limitations. The default smallest page allocation for Zig and Rust appears to be 1meg or 16 WASM pages. For C it's 2 pages, or 128kb. I know we can change these defaults and lower them, but it is something to be aware of.

Chris Woods (Feb 21 2024 at 22:30):

We've done some experiments and a device with 340kb of RAM was a really viable target. Anything smaller than that became difficult to use. This experiment was done with 'c' based WASM applications with their lifecycle remotely controlled.

Chris Woods (Feb 21 2024 at 22:32):

@Christof Petig - "Dare to dream small" :heart:

Chris Woods (Feb 21 2024 at 22:34):

Pardon the pun of "chip" in your own view, when talking about embedded solutions... I need a coffee :smile:

IFcoltransG (Feb 21 2024 at 22:59):

Chris Woods said:

The smallest WASM enabled application is going to need 64kb of RAM for linear memory, additional ram for the function table, bytecode, runtime state, stack pointers, and runtime code, ...

On the tiniest of hardware and with special compiler support, a program could use globals instead of linear memory. That doesn't change points 1 and 3, of course: less than 64kb user memory would be enough for a blinking lights demo, but I don't know about real use-cases.

Chris Woods (Feb 21 2024 at 23:05):

@IFcoltransG Ohh.. now there is a thought, no linear memory.... interesting... :thinking:

But speaking of special compiler support, we didn't mention using some form of AoT compiled WASM with a runtime....

Dan Gohman (Feb 21 2024 at 23:07):

I think it's pretty likely that we could get the Wasm CG to accept a proposal for <64KiB page sizes.

Chris Woods (Feb 21 2024 at 23:11):

That's a cool idea...

Christof Petig (Feb 21 2024 at 23:13):

I found the paper: https://dl.acm.org/doi/10.1145/3498361.3538922 or https://github.com/liborui/WAIT claims an 4kb RAM and 128kb flash ATmega enough for simple on-chip AoT compilations. This for sure is an extreme.

https://github.com/TOPLLab/WARDuino mentions the 64k wasm page size lower limit.

When I said small, I had really tiny CPUs in mind, loosely remembering above paper.

Given enough backing a <64k page size standard would be possible and an extension of the relocation convention at
https://github.com/WebAssembly/tool-conventions/blob/main/Linking.md#processing-relocations could permit separating read-only data sections into ROM by introducing a special relocation base (probably weakening insulation).

Chris Woods (Feb 21 2024 at 23:14):

Wow - great find. I've got some homework / reading to do.

Christof Petig (Feb 21 2024 at 23:31):

https://github.com/gwsystems/aWsm?tab=readme-ov-file#advice-for-wasm-standardization contains similar recommendations for embedded wasm runtimes (page size, read only memory, out of bounds trap guarantees)

Dan Gohman (Feb 21 2024 at 23:38):

Looking at those recommendations, I'd guess that page sizes and read only memory are doable if we design them carefully. However, I expect "undefined behavior on Out of Bounds" would face a lot of pressure to find alternative solutions.

Wang Xin (Feb 21 2024 at 23:58):

Nuno Pereira said:

Dan Gohman said:

I've now put together a simple project that uses that embedded.wit file to build a component that (in theory) blinks an LED: https://github.com/sunfishcode/hello-embedded

Pretty cool! Wondering if the plan is to do the same split rust embedded hal does between blocking traits and async ones?

I think c guests are particularly relevant here, and these could be more welcoming of non-async interfaces. Android's Context Hub Runtime Environment (CHRE), might be an additional design point worth checking out:
https://source.android.com/docs/core/interaction/contexthub

The CHRE is for C/C++ but has several frameworks called Platform Abstraction Layers for stuff like sensor IO, location, audio, and more.

You might want to check out this regarding Wasm for CHRE:
https://wasmcon2023.sched.com/event/1PmEw/develop-the-android-context-hub-runtime-environment-chre-nanoapps-in-webassembly-mingqiu-sun-intel

Christof Petig (Feb 22 2024 at 00:00):

Christof Petig said:

I will need to look up the details but I recall from either the embassy or embedded WG matrix that a fraction can't represent all hardware states and thus the second one was added, dirbaio will know the details as he made the change.

I just recall the fully-on is not necessarily the same as 100% and fully-off not identical with 0%, so all three might be necessary. Some hardware still gives small spikes at minimum and maximum width, so these special functions decouple the pin from from the pwm/timer to drive constant level output.

Dan Gohman (Feb 22 2024 at 00:29):

Nuno Pereira said:

Pretty cool! Wondering if the plan is to do the same split rust embedded hal does between blocking traits and async ones?

I currently have both sync and async inteteraces; embedded.wit has the sync interfaces and async.wit has the async ones: https://github.com/sunfishcode/hello-embedded/tree/main/wit

The CHRE is for C/C++ but has several frameworks called Platform Abstraction Layers for stuff like sensor IO, location, audio, and more.

I myself am hoping to focus on just the embedded-hal featureset for now, because it's pretty small and simple. But if someone else wants to look into what the SIG might do in the space of sensors, location, audio, etc., that'd be cool.

Christof Petig (Feb 22 2024 at 07:15):

Dan Gohman said:

Looking at those recommendations, I'd guess that page sizes and read only memory are doable if we design them carefully. However, I expect "undefined behavior on Out of Bounds" would face a lot of pressure to find alternative solutions.

I re-checked the paper for what exactly they proposed and it is masking addresses instead of comparing to the current bound. So oob addresses will wrap into the sandbox instead of trapping. This maintains the integrity of the sandbox but not trapping isn't spec compliant.

Ralph (Feb 22 2024 at 07:28):

I wake up to wonderful things! Lots of reading to do, which means a great day. :-)

Dan Gohman (Feb 22 2024 at 15:58):

Christof Petig said:

I just recall the fully-on is not necessarily the same as 100% and fully-off not identical with 0%, so all three might be necessary. Some hardware still gives small spikes at minimum and maximum width, so these special functions decouple the pin from from the pwm/timer to drive constant level output.

What if we fixed this by saying that on hardware that does that, set-duty-cycle(0) must be special-cased in the host to turn the power fully off? And similarly for set-duty-cycle(max-duty-cycle()) .

Dan Gohman (Feb 22 2024 at 16:47):

Ralph said:

[...] Wasm brings some security and radical portability (containers, why bother in truly constrained environments?), but scenarios that do NOT benefit from those features are not likely targets for wasm.

In addition to security and portability, I'd encourage us to keep in mind a third reason: toolchains. Even when people don't need Wasm's style of security or portability, they may want to use the same tools that they use when they do need those things.

Ralph (Feb 22 2024 at 16:51):

that argument is likely to be less persuasive than it at first might appear. Most businesses do not make money ensuring that their customers can use the wasm-friendly tool chains. Either they can, or they can't -- in either case, typically a business wouldn't care. if they're using Zork language now, and in the future Zork also supports components, for example, that's great, but in the specific scenario where wasm doesn't help, it's a no-op: they'll just keep using Zork native.

Ralph (Feb 22 2024 at 16:51):

is that what you meant? It's how I parsed it......

Dan Gohman (Feb 22 2024 at 16:55):

I'm expecting there will be a fuzzy and evolving boundary between wasm making sense and not. Sometimes it clearly will, sometimes it clearly won't (8-bit MCUs say hi). But sometimes, if a device can run Wasm, but you don't need the security or portability, you may still use Wasm, for the toolchains.

Chris Woods (Feb 22 2024 at 17:00):

Just for clarity on the container comments. It is not a comparison of technical merit. It is just the reality of dealing with an incumbent technical solution, which, today, for larger devices containers are seen as good enough.

There is always a cost of adopting a new technical solution. That cost is offset by a lower bill of materials (BoM). This is an opportunity for WASM, but also an effective limitation.

If embedded WASM’s required bill of materials is so high that I can use a container, then WASM as a solution will struggle to get the traction it may technically deserve.

As the cost of adoption drops, this equation will change, but at least, initially, it’s something to be cognizant of.

Ralph (Feb 22 2024 at 17:01):

opportunity cost is real.

Christof Petig (Feb 22 2024 at 17:02):

I really like to test wasm binaries/components locally on my favorite PC environment before deploying them to embedded (or cloud). In the case of multiple CPU targets this gets more and more attractive, even if I convert them back to native before flashing to a specific device. Wasm is so much more portable than source code :shrug:

Lann Martin (Feb 22 2024 at 17:07):

Its also incredibly difficult to reproduce embedded environments on workstations; just being able to reliably virtualize at that level would be a huge win for testing and rapid iteration

Catherine (whitequark) (Feb 22 2024 at 23:40):

Christof Petig said:

Christof Petig said:

I will need to look up the details but I recall from either the embassy or embedded WG matrix that a fraction can't represent all hardware states and thus the second one was added, dirbaio will know the details as he made the change.

I just recall the fully-on is not necessarily the same as 100% and fully-off not identical with 0%, so all three might be necessary. Some hardware still gives small spikes at minimum and maximum width, so these special functions decouple the pin from from the pwm/timer to drive constant level output.

But what happens if you read the duty after setting it to fully-on? Does it exceed the stated max duty? This seems like a bad idea to entrench in the API design to me.

Dan Gohman (Feb 23 2024 at 00:17):

cargo-component 0.8 is now released, so the hello-component demo no longer needs a custom build!

Christof Petig (Feb 23 2024 at 06:37):

Catherine (whitequark) said:

But what happens if you read the duty after setting it to fully-on? Does it exceed the stated max duty? This seems like a bad idea to entrench in the API design to me.

I asked on rust embedded matrix and received confirmation that now these functions have become a special case of set_duty_cycle. So I was remembering an older design limitation which was worked around by extending the duty cycle domain to one higher than the hardware limit.

So it is confirmed that fully is no longer needed.

Catherine (whitequark) (Feb 23 2024 at 20:11):

Thanks @Christof Petig!

Chris Woods (Feb 23 2024 at 21:38):

Draft Proposal Looking for Feedback
Happy Friday folks. The paperwork for requesting the SIG is underway! - As mentioned on the last WASI call I've been working on an initial draft proposal text for the Embedded SIG. I've put it up on GitHub here for everyone to review. Please do take a look, comment, correct me, and / or improve. I did try to include our discussion on defining the small footprint devices we'd try to support, as I think from our discussion here that it provides an important scope setting criteria for the SIG.

https://github.com/woodsmc/bca_governance/blob/SIG_Embedded/SIGs/SIG-embedded/proposal.md

Call for Support
To create the SIG, we need to ask for your support, if you are interested in expressing your support please do let me know, I'd be delighted to add a name to the list.

Call for Co-Chairs?
I know we've a lot of embedded contributions from all over the globe and in the proposal text, you'll see I'll suggested that the SIG have a rotating meeting schedule, between Europe, Asia and the Americas. This is just an idea, and we'd need to run it past the TSC of course, but to make it work, we'd ideally need to have volunteers to help co-chair from each of the geographical regions, do you think this is a good idea? Would you like to volunteer to help?

Dan Gohman (Feb 23 2024 at 23:03):

The group may provide notes and guides to the embedded community on how to address the specific constraints the ecosystem, this may complement the tooling available from the Bytecode Alliance.

Hi Chris, overall this looks great! Could you clarify what "this may complement the tooling available from the Bytecode Alliance" means here? I think I kind of get what it's saying there, but it feels like it'd be good to clarify.

Chris Woods (Feb 23 2024 at 23:13):

Hi Dan. Thanks for the quick turn around and the feedback. Love it.

The embedded world can be quite fragmented, and I was imagining a situation in which the group may need in the future to provide something specific for a board, or a platform. Depending on what it was, of course, it may not be something we support long term - but something that may help a partner get WASM / WASI up and running on their particular platform. I could envisage a bunch of scenarios like this which might occur. So its, not a core tool, but a complementary tool.... practically, that's what I was thinking about.

By complementary, I mean perhaps peripheral too and aligned with the general direction we're all heading in.

I'm happy to word-smith that better, or be more specific too. Is there a specific concern, a way I can phrase that a little better?

Dan Gohman (Feb 23 2024 at 23:38):

The sentence starts off talking about notes and guidance. If it's about building tools, perhaps that part should be part of sentence 5, which is about providing software?

Chris Woods (Feb 24 2024 at 03:03):

That makes sense. I'll make the change. Thanks Dan.

Dominik Tacke (Feb 24 2024 at 09:07):

Chris Woods said:

Draft Proposal Looking for Feedback
Happy Friday folks. The paperwork for requesting the SIG is underway! - As mentioned on the last WASI call I've been working on an initial draft proposal text for the Embedded SIG. I've put it up on GitHub here for everyone to review. Please do take a look, comment, correct me, and / or improve. I did try to include our discussion on defining the small footprint devices we'd try to support, as I think from our discussion here that it provides an important scope setting criteria for the SIG.

https://github.com/woodsmc/bca_governance/blob/SIG_Embedded/SIGs/SIG-embedded/proposal.md

Call for Support
To create the SIG, we need to ask for your support, if you are interested in expressing your support please do let me know, I'd be delighted to add a name to the list.

Call for Co-Chairs?
I know we've a lot of embedded contributions from all over the globe and in the proposal text, you'll see I'll suggested that the SIG have a rotating meeting schedule, between Europe, Asia and the Americas. This is just an idea, and we'd need to run it past the TSC of course, but to make it work, we'd ideally need to have volunteers to help co-chair from each of the geographical regions, do you think this is a good idea? Would you like to volunteer to help?

Thx Chris. Looks good.
I'd like to add my support where needed, especially looking at the Co-Chair question, I can offer my participation for Europe.

Christof Petig (Feb 24 2024 at 09:24):

Dominik Tacke said:

Thx Chris. Looks good.
I'd like to add my support where needed, especially looking at the Co-Chair question, I can offer my participation for Europe.

Hello Dominik :wave:, feel free to count me in for Europe activities. With already (co-)leading a Rust group at SAE and AUTOSAR I need to limit additional responsibilities, but wasm is dear to my heart.

Chris Woods (Feb 24 2024 at 13:13):

@Christof Petig awesome, does that mean I can put you down as a supporter? ;p

Chris Woods (Feb 24 2024 at 13:14):

@Dan Gohman - Just got the text updated.

Ralph (Feb 24 2024 at 13:14):

you people

Ralph (Feb 24 2024 at 13:15):

I'm not looking at this until Monday

Ralph (Feb 24 2024 at 13:15):

but lllloooooovvvvveeee it

Chris Woods (Feb 24 2024 at 13:22):

Have a great weekend @Ralph . Just aheads up, I'm flying to Germany on Sunday and will be at an internal work conference next week. Will be checking in here, but there will be involuntary periods of disconnection, and response times will be more within the European timezone... albeit with jet lag...

Ralph (Feb 24 2024 at 13:32):

I'm already in Europe, so no sympathy here buddy

Ralph (Feb 24 2024 at 13:33):

(enough tz dances for a lifetime)

Ralph (Feb 24 2024 at 13:33):

Fly safe!

Friedrich Vandenberghe (Feb 24 2024 at 14:38):

Dan Gohman said:

I've now put together a simple project that uses that embedded.wit file to build a component that (in theory) blinks an LED: https://github.com/sunfishcode/hello-embedded

Hi Dan, I just wanted to say thanks for the amazing repo! Using your embedded.wit as an API, I was able to successfully control an LCD screen I connected to my Raspberry Pi via I2C. (code)

Catherine (whitequark) (Feb 25 2024 at 09:12):

I'd like to express my support for the Embedded SIG.

Christof Petig (Feb 25 2024 at 22:31):

Chris Woods said:

Christof Petig awesome, does that mean I can put you down as a supporter? ;p

Yes, please. But please skip me when looking for a European chair.

PS: I prepared more of my WIT without wasm (sic) prototype, you can find it at <https://github.com/cpetig/wit-bindgen/tree/wasm64/crates/cpp/tests/native_strings> and it leverages Dan's recent wasm-tools work to enable 64 bit compatible code generation. I plan to create a w2c2 based wasm embedded and AoT variant of this example using the identical plugin ABI later.

Christof Petig (Feb 25 2024 at 22:34):

PPS: A rust based example (guest and host side) is planed afterwards. Feedback and help (modifying the Rust codegen macros) is welcome.

Chris Woods (Feb 26 2024 at 08:29):

Catherine (whitequark) said:

I'd like to express my support for the Embedded SIG.

Awesome @Catherine (whitequark) - I've added your name to the list of supporters, thank you!

Chris Woods (Feb 26 2024 at 08:30):

Ralph said:

(enough tz dances for a lifetime)

Living off the caffine.. :-p

Chris Woods (Feb 26 2024 at 08:30):

Friedrich Vandenberghe said:

Dan Gohman said:

I've now put together a simple project that uses that embedded.wit file to build a component that (in theory) blinks an LED: https://github.com/sunfishcode/hello-embedded

Hi Dan, I just wanted to say thanks for the amazing repo! Using your embedded.wit as an API, I was able to successfully control an LCD screen I connected to my Raspberry Pi via I2C. (code)

That's really cool. Just checking out the repository now.

Nuno Pereira (Feb 26 2024 at 12:12):

Chris Woods said:

Draft Proposal Looking for Feedback
...
Call for Support
To create the SIG, we need to ask for your support, if you are interested in expressing your support please do let me know, I'd be delighted to add a name to the list.
...

I would also like to express my support for the Embedded SIG.

Chris Woods (Feb 26 2024 at 14:12):

Nuno Pereira said:

Chris Woods said:

Draft Proposal Looking for Feedback
...
Call for Support
To create the SIG, we need to ask for your support, if you are interested in expressing your support please do let me know, I'd be delighted to add a name to the list.
...

I would also like to express my support for the Embedded SIG.

Thanks Nuno! I've added you to the page!

Ralph (Feb 26 2024 at 14:13):

Wait, I wanna join the list! Has that happened?

Chris Woods (Feb 26 2024 at 14:18):

Thanks Ralph! - You're on the list!

Dan Gohman (Feb 26 2024 at 14:19):

Hi Chris, can I join the list too?

Dan Gohman (Feb 26 2024 at 14:21):

Friedrich Vandenberghe said:

Hi Dan, I just wanted to say thanks for the amazing repo! Using your embedded.wit as an API, I was able to successfully control an LCD screen I connected to my Raspberry Pi via I2C. (code)

Very cool! I hadn't tested the I2C interface yet; it's fun seeing things go from "this should theoretically work" to "it actually works" :smile:

Ralph (Feb 26 2024 at 14:21):

"first try"

Chris Woods (Feb 26 2024 at 14:23):

Thanks Dan, and thanks for the working first time "sketch", I spent this morning, rather Jet lagging chatting about it with colleagues. Really cool stuff!

Stephen Berard (Feb 26 2024 at 16:14):

Thanks @Chris Woods for putting together the draft for the Embedded SIG. I'd like to express my support for the Embedded SIG.

Overall, your document looks good to me. Thank you for all your efforts here.

Chris Woods (Feb 27 2024 at 06:47):

Thanks Stephen! Awesome, I've added your support to the document.

Dan Gohman (Feb 27 2024 at 14:24):

Chris Woods said:

By complementary, I mean perhaps peripheral too and aligned with the general direction we're all heading in.

I'm happy to word-smith that better, or be more specific too. Is there a specific concern, a way I can phrase that a little better?

Reading it again, "may complement the tooling available from the BA" still feels a little unclear. What would you think of having the bullet point say something like this:

The group may provide software to support embedded use cases including proof of concept implementations, producer tools, or proposed solutions, which may be specialized for specific use cases.

Merlijn Sebrechts (Feb 27 2024 at 16:37):

Hey everyone! This is a great initiative! Please keep me in the loop! I'm happy to support the SIG. Should I create a PR or just let you add me?

We're super interested in Wasm for embedded devices, both on microcontrollers and embedded Linux devices. @Friedrich Vandenberghe is working on I2C support, and @Wouter Hennen and @Warre Dujardin are working on USB support.

One of the things that I think we will need to ensure capability-based security in the long term is the possibility to add additional metadata to components that describe not only what interfaces they use, but also what devices they support behind that interface. For example, a component might support a USB camera of a certain type, but it should not have access to other USB devices. Once that metadata is in place and indexable in warg, we could have a runtime that automatically loads drivers for connected hardware devices. For more info, see YouTube - Wasm Research Day 2023 – Merlijn Sebrechts

Milan (Feb 27 2024 at 23:39):

@Chris Woods Hope I'm not late to the party! I'd like to participate as a supporting member on the Embedded and Industrial Applications SIG as Milan Raj (National Instruments) @rajsite

Dan Gohman (Feb 28 2024 at 00:44):

Welcome!

Dan Gohman (Feb 28 2024 at 00:49):

@Merlijn Sebrechts How fine-grained are you imagining the USB device access control being? More like "this component shall access specific deviceIds/vendorIds/serialNumbers/etc.", or more like "this component shall only access digital cameras and not other kinds of devices"?

Qi Huang (Feb 28 2024 at 02:12):

@Chris Woods Hey Chris, I'd like to be a support member on this SIG as Qi Huang (Xiaomi), thanks for this great ieda

Chris Woods (Feb 28 2024 at 06:28):

@Qi Huang @Milan @Merlijn Sebrechts Thanks folks! - I've added your names to the list of supporters.

Chris Woods (Feb 28 2024 at 06:36):

Dan Gohman said:

Chris Woods said:

By complementary, I mean perhaps peripheral too and aligned with the general direction we're all heading in.

I'm happy to word-smith that better, or be more specific too. Is there a specific concern, a way I can phrase that a little better?

Reading it again, "may complement the tooling available from the BA" still feels a little unclear. What would you think of having the bullet point say something like this:

The group may provide software to support embedded use cases including proof of concept implementations, producer tools, or proposed solutions, which may be specialized for specific use cases.

Hey @Dan Gohman good morning, sorry for the delayed response - internal conference and timezones. Yes, I like this a lot actually. How about...

The group may provide software to support embedded use cases including proof of concept implementations, producer tools, or proposed solutions, which may be specialized for specific use cases or platforms.

Just thinking one of the reasons for this is the occasional weirdness of a specific IoT platform - HW + RTOS combination. I guess you could say that's covered by "use case" too? Or are we being overly specific? :thinking:

Chris Woods (Feb 28 2024 at 06:37):

I've added the proposed text to the md file, rewording point 5. What do you think?

Merlijn Sebrechts (Feb 28 2024 at 17:05):

>

Dan Gohman said:

Merlijn Sebrechts How fine-grained are you imagining the USB device access control being? More like "this component shall access specific deviceIds/vendorIds/serialNumbers/etc.", or more like "this component shall only access digital cameras and not other kinds of devices"?

Yes, I'm assuming we simply use existing standards and ad-hoc identifiers like serial numbers, device ids and vendor IDs. At the level that I'm talking about, this would be a driver getting access to the devices that it supports.

I think things like "this component shall only access digital cameras and not other kinds of devices" should be done at a higher level. A driver, for example, would turn a USB interface into a video stream interface. Then an app would state "I want access to a video stream" and be connected as such.

Merlijn Sebrechts (Feb 28 2024 at 17:08):

But at that level, I think the current setup of matching interfaces already works. A h264-stream interface, for example is descriptive enough and possible using the current version of the component model. It might be interesting to see if there are other use-cases for "additional metadata for an interface" beyond hardware interfaces, though.

Ralph (Feb 28 2024 at 17:12):

@Merlijn Sebrechts what of that information should be required of the capability interface, and what of the implementation? The way you described it, the For example, a component might support a USB camera of a certain type, but it should not have access to other USB devices. Once that metadata is in place and indexable in warg, we could have a runtime that automatically loads drivers for connected hardware devices.

So..... which type of component artifact should have what kind of information, the way you're thinking about it. I -- that is, the human personality that is Ralph -- would say hey, you implement wasi:digital-camera, but underneath you might have the supplying implementation that uses a wasi:usb to connect to and consume the camera stream but return only that.

you sorta reference that with your last comment, but is that how you think about it?

Ralph (Feb 28 2024 at 17:13):

and there's a difference between the component having this metadata itself vs. having that level of searchable metadata in the registry.........

Ralph (Feb 28 2024 at 17:13):

But, love the thoughts, keep 'em coming

Merlijn Sebrechts (Feb 28 2024 at 17:25):

So let's say you have a component that uses wasi:digital-camera. It processes a video feed. The runtime has access to a sony-f390 camera module via USB. It needs a "driver" component that translates wasi:usb to wasi-digital-camera. But every USB camera driver component will have that. How can the runtime

1. Find the component that consumes wasi:usb for the sony-f390 camera and implements wasi-digital-camera.
2. Give that component access to only that USB device.

So the driver should have metadata that says "I'm consuming wasi:usb with the specific property device-id: sony-f390".

Runtimes that don't understand the property should just give it access to all usb devices. Runtimes that understand the property should only give it access to that specific device. Moreover, runtimes can use this metadata to dynamically load drivers based on what USB device is connected.

Does this answer your question?

Ralph (Feb 28 2024 at 17:26):

yup, and I would think that there WOULD be a device specific interface for the sony-f390, not merely a "label" for it

Ralph (Feb 28 2024 at 17:26):

at the impl level

Ralph (Feb 28 2024 at 17:27):

but this is a first pass kind of thought, don't take it too seriously as I'm working out at what level I'd drive that information.....

Merlijn Sebrechts (Feb 28 2024 at 17:29):

Ralph said:

yup, and I would think that there WOULD be a device specific interface for the sony-f390, not merely a "label" for it

So the thing I'm trying to enable is giving a 10-year old embedded device access to new connected devices by dynamically loading drivers.

We could have a separate interface for every single device connected to USB, but

1. that would blow up the size of supported interfaces, if every device would be supported, and
2. would limit runtimes to only supporting devices released before that runtime.

Merlijn Sebrechts (Feb 28 2024 at 17:30):

In your scenario, the runtime could support passing USB to components. The drivers could be available, but it still wouldn't be possible to match the two simply because the runtime sees usb-sony-f390 as a separate, unsupported interface.

Dan Gohman (Feb 28 2024 at 17:31):

Yeah, that's the challenge I see too. Currently our main tool for components making static semantic declarations are signatures, but we don't currently have good tools for being generic or abstracting over different signatures.

Ralph (Feb 28 2024 at 17:32):

the two stories I'm extracting from this are those who do not care about devices will use any wasi:digital-camera impl; those who DO would want to:

• prevent usage of any other camera with that "driver" component
• separated metadata that would enable a runtime to make out of band decisions either in advance or at runtime

Merlijn Sebrechts (Feb 28 2024 at 17:34):

I'm not sure I follow. In my scenario, wasi:digital-camera consumers should never care about what the underlying device is. They just process a video stream. That's not the level that I'm talking about.

I'm talking about a wasi:usb consumer that only supports a specific camera.

Pat Hickey (Feb 28 2024 at 17:39):

meta-suggestion: maybe its time to make a SIG-embedded stream and break this into several threads

Chris Woods (Feb 29 2024 at 02:23):

Pat Hickey said:

meta-suggestion: maybe its time to make a SIG-embedded stream and break this into several threads

Just a question on etiquette, should we make sure we get the SIG formally recognized first? Or is it ok to go ahead to setup a SIG-Embeded without the formal SIG being established ?

I'd like to give folks a few more days to review, comment, voice support, offer to co-chair - we're still looking for volunteers, particularly in the America's...

Loved @Dan Gohman feedback so far (thank you!) .

Perhaps we can give it to Friday afternoon US time and if there are no further comments I can formally request the SIG proposal be reviewed by the TSC, and submit the PR?

Does that sound ok to all?

Chris Woods (Feb 29 2024 at 02:26):

I'm really loving the active conversation, and comments so far... I'm excited about getting the SIG setup so we can make these conversations easier, and more effective.

Merlijn Sebrechts (Feb 29 2024 at 09:08):

Chris Woods said:

Pat Hickey said:

meta-suggestion: maybe its time to make a SIG-embedded stream and break this into several threads

Just a question on etiquette, should we make sure we get the SIG formally recognized first? Or is it ok to go ahead to setup a SIG-Embeded without the formal SIG being established ?

Maybe you can start with a proposed-SIG Embedded stream and rename it to SIG Embedded once it becomes official?

IFcoltransG (Feb 29 2024 at 10:29):

It could also be called 'Embedded' until the SIG is formed, which is a little easier to read.

Dan Gohman (Mar 01 2024 at 17:43):

Here's a question for people to ponder: What should portability mean for Embedded?

Suppose we were to take eg. wasi-sdk and add flags like --chip=stm32, --chip=esp32, --chip=nrf5x, and more, which produce "Wasm" code that runs faster and with less RAM on those chips, but on other chips runs slower, or perhaps doesn't run at all, or perhaps has a risk of behaving differently. How would you think about this?

• That compromises the core value proposition of Wasm.
• That'd be normal and expected.
• It depends on how slow, or how big a risk, or other factors.

Please explain your reasoning :smile: .

Thomas Trenner (Mar 01 2024 at 18:18):

Dan Gohman schrieb:

Here's a question for people to ponder: What should portability mean for Embedded?

Suppose we were to take eg. wasi-sdk and add flags like --chip=stm32, --chip=esp32, --chip=nrf5x, and more, which produce "Wasm" code that runs faster and with less RAM on those chips, but on other chips runs slower, or perhaps doesn't run at all, or perhaps has a risk of behaving differently. How would you think about this?

• That compromises the core value proposition of Wasm.
• That'd be normal and expected.
• It depends on how slow, or how big a risk, or other factors.

Please explain your reasoning :smile: .

To me, personally, portability is the least important thing.
Here is my priority:

1. Sandboxing
2. Low footprint
3. High performance
4. Portability

Here are my reasons:

• Having a sandboxed execution on an embedded device implies “value” (patching software without harming the underlying system + without the need of flashing it)
• Embedded devices have different capabilities: SPI, I2C, UART, … -> so, portability is often not only a question of the chip, but the „interfaces“ it provides to interact with the outside world -> regarding WASI/component model/wit description: maybe the “connection” to WoT (web-of-things) standards could be considered when thinking about wit-file definitions. This might relate to the discussion above about “on which semantic/abstraction level should a wit-file act?”…
• Portable code and high performance are contradictory. In most cases, imho, performance is more important -> to get performance you must use AOT compilation, because using JIT just needs too much memory (ROM+RAM) on an embedded device; using JIT means higher footprint, which worsens the bill-of-material -> if you must use AOT anyways, something like cross-compilation kicks in - this is to be done latest just before the deployment process happens
• Deployment questions on wasm modules on embedded devices relate to the “device capabilities” questions - the concrete chip is just one of many criterias for deployment.

Other than that:
Looking forward if this proposal gets approved to do those discussions.

Lann Martin (Mar 01 2024 at 18:25):

patching software without harming the underlying system + without the need of flashing it

My earliest interest in Wasm was for exactly this. It is hard to overstate just how painful field updates can be.

Chris Woods (Mar 01 2024 at 18:29):

Following on from what Thomas has said - In a production environment, the most likely commerical deployment is going to be via an AoT compiled binary. WAMR excels at this and in some circumstances (along with WASMEdge) produces code which can run faster than native code. - I think Mats has seen the same results as we have.

It's not only the speed here that is important it is the runtime size and prodction overhead for dealing with AoT is smaller than JIT. - This allows us to address a wider demographic of devices in general.

In this world the original WASM is cross compiled on demand for the target device.

This addresses bytecode portability, and performance as @Dan Gohman raised this point.

But the other point is ABI portability. We still need a way to deploy code which can run on a family of devices. The code will need to discover the functionality available from its host and adapt at runtime to that. This could be everything from asking how many I2C or I2C devces are available. Through to querying more higher level constructs, like local device storage, communication protocols etc.

Chris Woods (Mar 01 2024 at 18:30):

@Dan Gohman - the AoT delta is so significant, I'm wondering if that's something the folks at fastly would look at too?

Dan Gohman (Mar 01 2024 at 18:33):

@Chris Woods Fastly already does use AOT. We don't have a JIT in the fleet.

Chris Woods (Mar 01 2024 at 18:47):

@Dan Gohman - ahh, so you folks will probably have the next problem that this opens up - managing service catalogues and WASM + native assets... depending on how hetrogenous the fleet is, of course. :-) this is less a WASM and more an orchestraton / scheduling problem of course.

Dan Gohman (Mar 01 2024 at 18:50):

Yeah, so for our use cases, portability matters a lot, in the sense of being able to run the code on different kinds of machines, and also in letting our users run their code on different Wasm runtimes.

Thomas Trenner (Mar 01 2024 at 18:52):

Just to add one thing:
I would try to ensure that the semantics of the code stay the same on different devices. I.e.: if you have a control code using floats, then the result of the calculation should be the same, independent of where it gets executed. It might execute slower (which can have sever impact), but it yields the same (=predictable) results.
At this point, I guess deciding on what is more important (speed vs deterministic results) is to be done from case to case. Some discussions were done regarding SIMD & relaxed_simd.

However, having portability is a good thing to have. But with AoT, it could be reached (with some pain) with cross-compilation of wasm bytecode.

Chris Woods (Mar 01 2024 at 18:56):

Dan Gohman said:

Yeah, so for our use cases, portability matters a lot, in the sense of being able to run the code on different kinds of machines, and also in letting our users run their code on different Wasm runtimes.

Yes I can see this, particularly as part of the development story and we will have the same in the IoT space. The best runtime for development on the desktop could be different to the embedded runtime. We've looked at WAMR for IoT and I did discuss with Pat and Bailey trying to run the same code in Wasmtime on a desktop... it doesn't work. The networking / socket API in particular is different, and this was the source of the pain. I think from a WASI (interface) world solving this would be amazing.

Overall, in the WASI-P1 environment there is some fragementation between networking implementations , as these were not standardized in P1. It means writing adpaters to convert from P1 to P2 may end up being runtime specific, which would just be a lot of work. But a back port of the socket api from P2 to P1 as a P1 standard would give P1 dependent folks a way to migrate and prep for P2 and ultimately WASI V1 - just a thought.

Chris Woods (Mar 01 2024 at 19:37):

Just to clarify, while we've looked at WAMR, it isn't the only solution of course, there are lots of other solutions for embedded devices, I know that there is some amazing work on Wasmtime recently, and also some great work on getting WASM2C as a runtime too.

Cracking the code portability issues between these platforms, particularly with communications would be awesome.

I think we touched on this in the discussion above, there are perhaps two key ways to think about emebdded systems:

1. A world similar to the proposal from @Dan Gohman 's excelltn WIT, and the work from @Merlijn Sebrechts @Wouter Hennen @Warre Dujardin @Friedrich Vandenberghe (and I'm sure I've forgotten other names I should really add here) on a low level interface. In this world, perhaps you write your device driver in WASM.
2. A world where the low level interface is hidden, and devices are described - an LCD screen is directly exposed, or a external sensor provides an API - perhaps the device driver here is native.

I could imagine that this all depends on the target device and it's capabiltiies, security concerns, etc. ..

I'm really excited about talking more with everyone...

Chris Woods (Mar 01 2024 at 19:41):

Speaking of talking more with everyone...

I submitted the PR for creating the SIG. I think this kicks off the formal Bytecode Allaince process and as far as I know is the first step in asking the TSC to consider our request. I imagine that there will be some feedback on text and some improvements to that.

I'll keep you all posted on what I hear.

Chris Woods (Mar 01 2024 at 19:45):

So far for co-chairs, as a recap ... we have:

1. Europe - @Dominik Tacke volunteered
2. Asia - @Wang Xin volunteered
3. Americas - I've offered to help.

If you are interested in helping with the coordination, or if I've missed your offer of help (It can happen and I apologise in advance) let me know! - many thanks, and Happy Friday to all.

Dominik Tacke (Mar 01 2024 at 21:00):

Chris Woods said:

Speaking of talking more with everyone...

I submitted the PR for creating the SIG. I think this kicks off the formal Bytecode Allaince process and as far as I know is the first step in asking the TSC to consider our request. I imagine that there will be some feedback on text and some improvements to that.

I'll keep you all posted on what I hear.

Oh, exciting news. Looking at this thread, there are so many awesome people already discussing and it is a lot of things which would need our attention. It will not be an easy but I think a very fulfilling and exiting task to pave the way for embedded wasm.

Friedrich Vandenberghe (Mar 03 2024 at 08:38):

Hey @Chris Woods, if possible I would also like to join the SIG :big_smile:

Maximilian Seidler (Mar 03 2024 at 19:35):

Hi everyone, very interesting conversation here, I'll have to catch up the very first messages. I'm also currently working with WASM on highly constrained devices and especially integrating peripherals. So I'm very interested in joining the discussion (and the SIG of course)

Chris Woods (Mar 04 2024 at 16:10):

@Friedrich Vandenberghe -
Of course, SIG is open to all. I was just collecting supporting names from members of the Bytecode Alliance, it's a part of the application process to establish the SIG.

Chris Woods (Mar 04 2024 at 16:11):

For anyone wanting to track the PR for establishing the SIG, you can find it here: https://github.com/bytecodealliance/governance/pull/79

Chris Woods (Mar 05 2024 at 15:07):

Hi Folks, I've had a few folks reach out and ask how they can continue to show support for the proposed SIG. Now the PR is submitted, if you'd like to show support for the SIG please do comment on the Github PR (link above).

Merlijn Sebrechts (Apr 22 2024 at 11:57):

Hey everyone; we created a WIP stream for discussing WASI on embedded systems: https://bytecodealliance.zulipchat.com/#narrow/stream/434034-WIP-Embedded

Chris Woods (Jun 24 2024 at 15:47):

Hi Folks, we've got the second meeting of the embedded sig scheduled for tomorrow - full details available on the embedded-sig channel here : https://bytecodealliance.zulipchat.com/#narrow/stream/438936-SIG-Embedded/topic/Zoom.20Links.20and.20Meeting.20Schedule/near/446649135

Last updated: Nov 22 2024 at 17:03 UTC