<re_irc>
<@thejpster:matrix.org> if I forget, can someone remind me to talk about nominations for the launching pad leadership council rep at the Tuesday meeting.
<re_irc>
<@therealprof:matrix.org> : I think might be still not available to run the meeting and I'm travelling as well so the upcoming Tuesday meeting might not happen unless someone else volunteers to run it.
<re_irc>
<@thejpster:matrix.org> Then we should probably have the discussion in-band, as J-E will be starting the selection on 20 April over on the Rust zulip.
<re_irc>
<@adamgreig:matrix.org> My understanding from the email is he's looking for nominations from the various team/wg leadership?
<re_irc>
<@adamgreig:matrix.org> (I indeed won't be around to run a meeting on Tuesday)
<re_irc>
<@thejpster:matrix.org> My understanding is we now fall under a new team called "Launching Pad" becuase we are not (yet) a real team. Every Team gets a rep on the Leadership Council. JE is picking the Launching Pad rep for the Leadership Council, and the various Launching Pad sub-teams can propose someone as the overall Launching Pad Team rep.
<re_irc>
<@thejpster:matrix.org> I may have read it wrong though.
<re_irc>
<@thejpster:matrix.org> So we can propose someone, and the CLI WG can propose someone, and the Game Dev WG can propose someone, and one of those people will be picked to represent all of the above.
<re_irc>
<@thejpster:matrix.org> We could also nominate someone to do the selection instead of Jan-Erik. I propose that we let Jan-Erik do it.
<re_irc>
<@adamgreig:matrix.org> Yes, that's my understanding
<re_irc>
<@adamgreig:matrix.org> +too
<re_irc>
<@adamgreig:matrix.org> But I don't know exactly what process Jan-Erik plans to use for selection, if any yet, I think at this point it might just be a case of chat on the 20th and find out then?
<re_irc>
<@adamgreig:matrix.org> i.e., I don't think he needs any nominations before then
<re_irc>
<@thejpster:matrix.org> I suppose "I am asking you all to begin considering candidates for the Council Representative position." could mean individually, or collectively.
dc740 has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
emerent has quit [Ping timeout: 265 seconds]
emerent has joined #rust-embedded
starblue has quit [Ping timeout: 265 seconds]
starblue has joined #rust-embedded
creich has joined #rust-embedded
<re_irc>
<@d3zd3z:matrix.org> Is there any advice or guidance on how to setup a project where I'd like most of the code to be shared, but I want to be able to support several different board/MCUs?
<re_irc>
<@vollbrecht:matrix.org> : is the project some library and also some implementations for this different mcu's, or should this library only give the support for this range of mcu's? in other words should the implementation for the mcu live in that project?
<re_irc>
<@d3zd3z:matrix.org> Ultimately, I'll be implementing one or more libraries for the main functionality, probably built around either HAL traits, or my own traits that I'll implement for the different MCUs. But, I'll also need some main crates that build the application for each of the MCUs that I want to support.
<re_irc>
<@vollbrecht:matrix.org> if you want one silo crate most likely you want something like cargo workspaces?
<re_irc>
<@d3zd3z:matrix.org> I'm thinking of having a directory "boards" with subdirectories for each board that I want. Inside of that would be a project that can be built, with a main that sets things up, does the board-specific stuff, and then uses the other crates.
<re_irc>
<@d3zd3z:matrix.org> Yes, I was intending to put all of this within a workspace.
creich has quit [Quit: Leaving]
<re_irc>
<@dirbaio:matrix.org> workspaces with different chips is a target for trouble, since Cargo merges the features for the different crates
<re_irc>
<@vollbrecht:matrix.org> you could maybe have a look at the structure of esp_hal https://github.com/esp-rs/esp-hal they have a common implementation shared for all chips and than chip specific implementations all in one repo. for further features like wifi etc they use different repos though. maybe a structure like this is what you are looking for, though in a smaller scale
<re_irc>
<@d3zd3z:matrix.org> I notice that the examples have their own features, .cargo/config.tml and memory.x files. Presumably this would let me build the boards independently?
<re_irc>
<@d3zd3z:matrix.org> I should probably just spend some time studying/using embassy.
<re_irc>
<@bitslinger:matrix.org> Not sure how embassy does it but right, there's going to be some sort of board init/setup routine involved
<re_irc>
<@lulf_:matrix.org> embassy uses separate examples/crates for each board, so if you have a slightly different variant you need to edit memory.x and some Cargo.toml features and maybe the probe-run target in .cargo/config.toml
<re_irc>
<@bitslinger:matrix.org> imxrt-hal has like a boards feature setup for the samples
<re_irc>
<@lulf_:matrix.org> Right, it uses cargo features + build.rs to get the right stuff in place it looks like
<re_irc>
<@lulf_:matrix.org> seems like it's roughly the same target arch though
<re_irc>
<@lulf_:matrix.org> maybe that makes it simpler
<re_irc>
<@lulf_:matrix.org> seems like it's the same target arch though
<re_irc>
<@lulf_:matrix.org> I have a pet project where I'm going for something more generic, with macros, build scripts and traits that hide the details for different boards, and I'm not sure what to think about the result yet...
<re_irc>
<@dirbaio:matrix.org> the problem with making HAL examples cross-chip/board is that they no longer reflect the "normal" use of the HAL that a normal user would do
<re_irc>
<@dirbaio:matrix.org> because there's fancy Cargo features and BSPs in the middle, obscuring how things work
<re_irc>
<@lulf_:matrix.org> Exactly
<re_irc>
<@dirbaio:matrix.org> this is why embassy simply copypastes everything
<re_irc>
<@dirbaio:matrix.org> it sucks to maintain though 🤣
<re_irc>
<@bitslinger:matrix.org> I mean there's devicetree I guess, but then you usually still want the actual peripheral type not just the hal trait
<re_irc>
<@lulf_:matrix.org> So this is what I've been playing with https://github.com/lulf/ferrino . It tries to make a project fully reusable across boards, but there are a lot of details to that, like mapping leds and buttons for instance. And then it's the target arch, linker scripts and other config.
<re_irc>
<@lulf_:matrix.org> So instead of a device-tree, i was going for rust traits to represent the mapping
<re_irc>
<@bitslinger:matrix.org> like you _could_ concoct something where you get like a struct MyBoard{} with traits and such... but yeah, to make it generic kind of sucks, you lose the actual types... and the actual hardware functionality
<re_irc>
<@bitslinger:matrix.org> you end up with a worst common denominator sort of situation
<re_irc>
<@lulf_:matrix.org> Yeah, exactly
<re_irc>
<@dirbaio:matrix.org> devicetree 💀
<re_irc>
<@bitslinger:matrix.org> some dma's/peripheral IPs let you do all sorts of cool great things to offload tasks to hardware
<re_irc>
<@bitslinger:matrix.org> how do you make that generic without ended up with the global minimum of features?
<re_irc>
<@bitslinger:matrix.org> * ending
<re_irc>
<@bitslinger:matrix.org> : Right, don't need a C preprocessed file format involved
<re_irc>
<@jamesmunns:beeper.com> I have some silly ideas/experiments for a more "dynamic loading" approach, to also make applications smaller and faster to load
<re_irc>
<@jamesmunns:beeper.com> which is likely larger than statically linking everything, but then also allows for things like partial software updates
<re_irc>
<@bitslinger:matrix.org> like a partially linked elf with relocatables? a dyn elf?
<re_irc>
<@bitslinger:matrix.org> * elf with load time symbol mapping?
<re_irc>
<@jamesmunns:beeper.com> bitslinger: Yeah, pretty much. With a (very) limited subset of a full elf file
<re_irc>
<@bitslinger:matrix.org> tock kind of does something like that now doesn't it?
<re_irc>
<@bitslinger:matrix.org> with mpu regions and all
<re_irc>
<@jamesmunns:beeper.com> Yeah, it's always had capsules, it's a bit more granular/"service like" iirc, but it's been a couple years since I looked closely
<re_irc>
<@jamesmunns:beeper.com> I more "want to do it and learn about it" than "need it", so I haven't done a ton of background research tbh :)
<re_irc>
<@bitslinger:matrix.org> you can build rust or c applications against their libtock-[c/rs] (syscall library) and load, its neat
<re_irc>
<@bitslinger:matrix.org> +(processes I guess in tock terms)
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<re_irc>
<@shakencodes:matrix.org> Is defmt_test intended to let you execute unit tests on a target processor?
<re_irc>
<@dirbaio:matrix.org> yep, not on host
<re_irc>
<@shakencodes:matrix.org> What are the recommended ways to hook an RTT channel up to a test framework running on the host? Is there a CLI program I can attach the test framework to? Or do I need to hook it up programmatically using the probe-rs crate?
<re_irc>
<@dirbaio:matrix.org> probe-rs has "rtthost"
<re_irc>
<@dirbaio:matrix.org> keep in mind defmt logs go through rtt but are encoded, you need to decode them to see them as strings. you can pipe it to "defmt-print"
<re_irc>
<@dirbaio:matrix.org> or use probe-rs + defmt-decoder programatically
<re_irc>
<@dirbaio:matrix.org> what do you want to do exactly?
<re_irc>
<@shakencodes:matrix.org> I need a test framework to verify our firmware and hardware. The test framework attaches to the production data interfaces and test doubles (dev boards that simulate externally connected hardware) to verify the system under test.
<re_irc>
The overall test system needs to build and download the firmware, and then execute its suite of tests.
<re_irc>
The test system needs a back-channel into the system under test to set test modes that simulate faults in hardware on the board, as well as allowing examination of data not available through production interface.