11:17 <onio> I get an error when I issue cargo build command for esp32c3. "error: failed to run custom build command for 'esp-idf-sys v0.33.1' any I idea why this might be failing

11:18 <onio> I am running on Ubuntu 22.04.03 LTS in a VM

11:24 <sourcebox[m]> dirbaio: I had a brief look at the rp2040 hal how the multicore startup is done. I could try to do something similar, but there are possible pitfalls: when the second core is started, there's no stack at all. So either `inline(always)` has to work in any case, or a naked function has to be used as entry point. But I think they're still unstable, aren't they? Then I would have to execute some assembly right at the start to setup

11:24 <sourcebox[m]> stacks, the vector table and also the FPU. It already happened to me that code crashed when NEON was enabled because the compiler decided to use some related instructions even if my code did not do anything with floats. What I also see in the rp2040-hal is that there are things relying on the calling conventions. Hopefully this will never change in the future.

11:41 <dirbaio[m]> > naked function has to be used as entry point. But I think they're still unstable, aren't they?

11:41 <dirbaio[m]> you can do it with global asm too, which is stable

11:49 <sourcebox[m]> I think I will come back to this topic later. ATM there are more questions than answers to get it right. A Cortex-A is quite complex in some behaviour, it needs several stacks because there are different modes than can be switched like system, supervisor etc.

13:29 <firefrommoonligh> <JamesMunns[m]> "Feel free to refer to:..." <- > <@jamesmunns:beeper.com> Feel free to refer to:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/aBvnTRnARTvsHodfTzACbIJK>)

13:29 <firefrommoonligh> * Those are a lot of words and no deleting squatted crate names.

14:37 <JamesMunns[m]> <sourcebox[m]> "I think I will come back to this..." <- The usual answer here is to use an MMU and the page table for each core, I think. Not 100% certain tho.

14:55 <sourcebox[m]> <JamesMunns[m]> "The usual answer here is to..." <- MMU is used anyway. I'm mainly talking about all the things that have to be setup before you can even enable it.

17:29 <lynaghk[m]> I'm working on an tool to generate a browser UI from a Rust type that lets you read/write that type on a live microcontroller (via serial).... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/OxLQFOiXVguArSSswddokwyS>)

17:43 <dkhayes117[m]> lynaghk: I'm not sure how applicable this is, but dngrs (spookyvision@{github,cohost}): has this rust web ui project that might be helpful https://github.com/spookyvision/embedded-web-ui

17:52 <lynaghk[m]> Thanks! Yeah, the author pointed it out when I asked about my idea here last week. Very similar idea, though I don't want the embedded device to have to specify everything to a generic frontend (as that requires more runtime resources). I need some way to make it easy for developers to compile a bespoke frontend based on their type definition.

17:53 <lynaghk[m]> I just recorded a demo of my proof of concept: https://d189ym6tlc5mr2.cloudfront.net/misc/2023_08_12_eui_demo.mp4 UI is generated from the following type definition:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/maaDyuxsVjAxSBbWXfBZKkfK>)

18:12 <yandrik[m]> Looks very nice! I might make something like that for Kolibri too, basically a one-function setter UI generator for all the embedded-graphics displays. Mind if I copy some of your code for that?

18:16 <lynaghk[m]> would be happy to share code, planning on open sourcing once I figure out how to make it ergonomic for developers to use. basically I know I need it to be just a few lines to throw into a project, otherwise I'll never actually use it =D

18:17 <lynaghk[m]> right now the UI generation is done in ClojureScript since that's what I know best. I think that would be able to stay generic (i.e., I can compile myself when publishing the crate for public consumption). But the WASM runtime would need to be generated by the end consumer. That's what's sorta tricky to figure out. Right now I'm using trunk to generate it, but I don't want end-users to have to install and use that.

18:17 <lynaghk[m]> want it to be automagically done via cargo as much as possible.

18:19 <yandrik[m]> Kolibri already supports widget layout and such, which would all be done on-device. I assume that the complicated part would be getting the introspection -> UI part, which you seem to already have completed

18:20 <lynaghk[m]> Mine's just proof of concept right now, basically using postcard's experimental Schema stuff serialized to JSON, and then the ClojureScript builds a UI against that which constructs JavaScript values, which the WASM bit deserializes back into Rust, then serializes into postcard to send down to the embedded device.

18:22 <lynaghk[m]> there are still plenty of widgets to sort out (I only have enums, structs, and u8 primitives done now). user-defined widgets would be useful, but at that point it'd be easiest to fork the ClojureScript and edit there, rather than try to expose some sort of "API".

18:22 <yandrik[m]> Interesting, gotta take a look at Postcard's Schema. Do you know whether the schema can be accessed at compile time? Making a macro would be maximally efficient for this I believe

18:24 <yandrik[m]> (plus, making a headless UI thing would be interesting. Basically same idea as yours, but instead of MCU <---> Host it would be MCU (headless) <---> MCU (with touchscreen), but I'm sure there's a crate out there for remote getters and setters already. Just can't remember the name...)

18:25 <lynaghk[m]> what sort of efficiency are you wondering about? Here's what's on the WASM side of my proof of concept (I just copied the type definition over)... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/cBInXfRfGHXjHBqSldrBmNBH>)

18:25 <lynaghk[m]> Gotta run right now, but happy to discuss further or pair. Drop me an email if you want: kevin@keminglabs.com

18:28 <yandrik[m]> Thanks, will do! [Kolibri](http://github.com/yandrik/kolibri) is my take on an embedded GUI framework, so all the code runs on the MCU. If every widgets' order and position and such are pre-computed at compile time, the runtime overhead will be lower, hopefully. Plus, the order staying the same is really, really important for all the incremental redraw stuff, that's what I meant

18:29 <yandrik[m]> s/what/why/, s/meant/believe that a macro would be awesome for this/

19:39 <thiskappaisgrey[> Hello. I'm relatively new to embedded programming, and I have a question. How do I write Rust code to expose the RP2040's storage as a mass USB storage device? I don't know the vocab around this, but I wanted to achieve something like in Circuitpython where I can upload configuration files that my Rust firmware can read to change the behavior of my program. I couldn't find any resources on how to achieve this after googling,

19:39 <thiskappaisgrey[> so... Thank you.

19:39 <dngrsspookyvisio> <lynaghk[m]> "Thanks! Yeah, the author pointed..." <- FWIW: it's totally possible to map your examples (light, color) to UI widgets on the control side as well, so I don't think my approach has an *inherent* overhead (which would either way be rather neglible - a byte or two)

19:40 <dngrsspookyvisio> anyway, nice that you got things going too!

19:41 <dngrsspookyvisio> <lynaghk[m]> "right now the UI generation is..." <- you can precompile a wasm project and read configuration stuff e.g. as base64 encoded url parameter

19:42 <dngrsspookyvisio> I very much recommend Dioxus for this kind of stuff

19:42 <dngrsspookyvisio> s/stuff/UI generation/

19:42 <dngrsspookyvisio> since it's written in Rust you avoid crossing a language barrier that way, which always comes with annoying bridging code

19:44 <dngrsspookyvisio> thiskappaisgrey[: try #rp-rs:matrix.org if you don't get an answer here

19:45 <dngrsspookyvisio> <yandrik[m]> "(plus, making a headless UI..." <- do ping me if you remember the remote crate, sounds interesting