02:29 <re_irc> <dngrs (spookyvision@github)> was there some issue with cargo workspaces and setting a target? I'm running into a variant of https://github.com/stm32-rs/stm32-rs/issues/158

02:29 <re_irc> <dngrs (spookyvision@github)> LLVM ERROR: Global variable '__INTERRUPTS' has an invalid section specifier '.vector_table.interrupts': mach-o section specifier requires a segment and section separated by a comma.

02:30 <re_irc> error: could not compile `stm32-metapac`

02:36 <re_irc> <dngrs (spookyvision@github)> hm, nevermind, I probably messed up some directory structure. Started afresh and things are fine.

10:12 <re_irc> <James Munns> Honestly, I never use workspaces anymore.

10:12 <re_irc> <James Munns> they aren't bad, but at least for embedded stuff, they cause confusion and breakage more often than they are helpful.

10:13 <re_irc> <James Munns> (multiple targets in the same workspace also causes all kinds of problems)

11:44 <re_irc> <MathiasKoch> Supply chain situation on STM32 is horrible! We are currently using STM32L475VGTx at my job. If we were to change to something with equal rust support but better supply situation, would NRF's be suitable? And if so, which NRF should we be looking at? we not actually using the low power stuff, but similar number of peripherals (mainly 2/3 UARTS, QSPI, and an SPI port + various GPIOS). Builtin cryptozone with AES...

11:44 <re_irc> ... acceleration would be sweet.

11:47 <re_irc> <matoushybl> I don't think the situation with NRF is better to be honest :( (at least last time I checked mouser, they were unobtainable)

11:48 <re_irc> <MathiasKoch> Sigh..

11:48 <re_irc> <MathiasKoch> anything that is possible to source at all?

11:48 <re_irc> <MathiasKoch> Cost is not really an issue currently

11:49 <re_irc> <matoushybl> maybe dirbaio can give you some pointers on NRF, they are using them a lot

11:49 <re_irc> <matoushybl> +obtaining

11:50 <re_irc> <matoushybl> MathiasKoch: The way I see it only RP2040 and ESPs, there are also the new Risc-v STM32 clones, but dunno about their availability

11:50 <re_irc> <James Munns> Yeah, those were exactly my suggestions

11:52 <re_irc> <matoushybl> but I've seen some nucleos drop on mouser in quite large quantities, so maybe it is getting a bit better?

11:52 <re_irc> <James Munns> Rp2040s have some prod downsides tho, like no crypto afaik for acceleration or code readout protection

11:52 <re_irc> <James Munns> Newer stms like the G line seemed to have faired better, but I've only looked at the lower end ones like the stm32g03x

11:53 <re_irc> <James Munns> What kind of quantities are you actually needing?

11:54 <re_irc> <adamgreig> yea, some stm32 lines are much better than others but it's hard to guess how that will change in the next few months

11:54 <re_irc> <adamgreig> at least the stm32f103 has like a hundred clones that are mostly drop-in compatible :P

11:55 <re_irc> <MathiasKoch> RP2040s could be an option, but it would absolutely be with a smaller feature set in the final product :/

11:55 <re_irc> <James Munns> Honestly, you mentioned pretty loose specs, if you have the cash, it might make sense to just buy a bunch of whatever you can get, and work backwards from there.

11:55 <re_irc> <MathiasKoch> but i guess products with less features are better than no products :p

11:56 <re_irc> <James Munns> They're pretty quick and dual core, honestly. A lot faster than an nrf52

11:56 <re_irc> <James Munns> Unless you're doing a ton of dsp

11:56 <re_irc> <matoushybl> adamgreig: :D I heard of a case where they ordered GD32V103 and were extremely surprised that it contained RISC-V core

11:56 <re_irc> <MathiasKoch> James Munns: Aboslutely.. Which is why my initial question was extremely broad :p But it would be nice with something that would be available in general going forward.

11:57 <re_irc> <James Munns> Yeah, fair

11:57 <re_irc> <James Munns> I don't know how big a "life time buy" would be for you

11:57 <re_irc> <James Munns> Or how easily you could stuff the extras in your next product(s)

11:58 <re_irc> <James Munns> But you can buy rp2040s by the reel, and they just need jellybean clocks and SPI flash parts

11:58 <re_irc> <MathiasKoch> Nah, i was meerly looking for suggestions on availability, just like the RP2040 you suggested 👍️

11:58 <re_irc> <James Munns> But again, your code is gonna be sitting in plaintext on that easily removed SPI flash, if that matters to you.

11:58 <re_irc> <MathiasKoch> Do you know why the RP's have the 16 MB limitation on flash?

11:59 <re_irc> <James Munns> (not that an F103 is practically any safer)

11:59 <re_irc> <James Munns> MathiasKoch: 24 bit address space, I assume?

12:00 <re_irc> <James Munns> (or an nrf52 either, for that matter)

12:00 <re_irc> <MathiasKoch> Im not super worried about my code, but would need some key storage. Currently we are using an ATECC608, so we can just continue with that.. The crypto was just a nice to have to get rid of the additional ATECC

12:01 <re_irc> <James Munns> Makes sense. The rp2040 is gonna be like 3-5 bucks cheaper than anything else already tho

12:01 <re_irc> <Robert Jördens> MathiasKoch: Desoldering from eval or dev boards may be a real option then.

12:01 <re_irc> <James Munns> But good call on the atecc

12:01 <re_irc> <James Munns> Robert Jördens: Yeah, that's why I asked about quantity lol

12:02 <re_irc> <MathiasKoch> Yeah.. We are talking a few thousands, so i would rather not :p

12:02 <re_irc> <James Munns> Wouldn't want to do that for more than 10-100 units, unless you were really separate tho

12:03 <re_irc> <James Munns> *desperate

12:03 <re_irc> <James Munns> (like, already have 500 expensive boards with everything else already soldered down and orders waiting desperate)

12:04 <re_irc> <MathiasKoch> We found a single supplier selling STM32L475VGTx at $418 each, and the corporate guys are actually considering that.. So i guess desperate describes it quite well

12:04 <re_irc> <James Munns> (which I've seen in the last two years, luckily not for me)

12:04 <re_irc> <matoushybl> wtf :D

12:04 <re_irc> <James Munns> Ooooooooooooooof

12:05 <re_irc> <James Munns> But yeah, the RPI folks have been talking a lot (at least) about being able to ramp up production to meet demand with the 2040

12:06 <re_irc> <James Munns> (i can find the tweets, but basically they've said they will keep everyone stocked, and know how to turn up the production dial. I imagine M0+ doesn't need super cutting edge fabs to make it happen)

12:07 <re_irc> <MathiasKoch> Makes sense 👍️ How far is the rp2040 rust hal?

12:07 <re_irc> <James Munns> I've not used it, but seems to be progressing? https://github.com/rp-rs/

12:07 <re_irc> <James Munns> I think probe-rs supports it since the last release too, as well as probe-run, so all the tooling should be happy

12:07 <re_irc> <matoushybl> Embassy also has some parts working

12:08 <re_irc> <Noah> James Munns: yup should be fine :)

12:13 <re_irc> <James Munns> https://twitter.com/EbenUpton/status/1455647401268682757 and https://twitter.com/EbenUpton/status/1500861055345610755 are some examples re: production

12:15 <re_irc> <James Munns> Already up to 500k/mo, which I have no idea how it compares to STM32 (probably a rounding error for them): https://twitter.com/EbenUpton/status/1514691280894402564

12:18 <re_irc> <James Munns> (I really need to get my Pico boards out of the drawer and onto the bench one of these days...)

12:18 <re_irc> <lulf> jhbruhn: after reading your blog post I see we're making similar design choices in embassy-boot (i.e. as a framework/lib where update is done by application), so that's a great validation for me at least 🚀 Going to write up some article about embassy-boot soon.

12:21 <re_irc> <jhbruhn> lulf: Sounds great! Yeah i only recently found that project, and I'm planning on looking into embassy more anyways, so I think moonboot would be the non-embassy/async equivalent to embassy-boot. Although at least the linkerscript codegen could be used for both, if extended further

12:22 <re_irc> <lulf> Yeah, I love the linkerscript codegen idea

12:22 <re_irc> <lulf> * I love the linkerscript codegen idea, and I think there's not enough rust bootloaders anyway :D

13:13 <re_irc> <jannic> MathiasKoch: I'd say it's in a good shape to get started, but if you want to fully exploit the hardware capabilities, you'll probably find some missing features. Contributions are always welcome 😄. One area with a lot of open questions is multi-core support. It is possible to run code on the second core, but it's not yet clear how to safely access peripherals from both cores, for example. (Of course you can always do...

13:13 <re_irc> ... your own locking and use "unsafe".) Great community at https://matrix.to/#/#rp-rs:matrix.org

13:35 <re_irc> <heksa> One of my supervisees is starting work on her master's thesis and she'd like to test her limits with Rust. Our project context is that we're developing a series of three research focused RISC-V SoCs, so I was thinking of something along the lines of 'model-based RISC-V interrupts firmware with embedded-hal', perhaps a use case demo leveraging the aforementioned. I'd appreciate ideas for "really smart & useful things to do...

13:35 <re_irc> ... with RISC-V" or just general words of encouragement 😀

22:34 <re_irc> <riskable> MathiasKoch: I'm using it every day in my project and it's _mostly_ feature complete. I've even got code working that does multi-core and reads/writes to flash 👍

22:55 <re_irc> <yruama_lairba> hi, question in an embedded context, in which situation it's reasonnable to panics ?