ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
fabic has joined #rust-embedded
genpaku has joined #rust-embedded
<re_irc> <dngrs (spookyvision@github)> was there some issue with cargo workspaces and setting a target? I'm running into a variant of
<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.
<re_irc> error: could not compile `stm32-metapac`
<re_irc> <dngrs (spookyvision@github)> hm, nevermind, I probably messed up some directory structure. Started afresh and things are fine.
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
fabic has quit [Ping timeout: 272 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
nort has joined #rust-embedded
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
<re_irc> <James Munns> Honestly, I never use workspaces anymore.
<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.
<re_irc> <James Munns> (multiple targets in the same workspace also causes all kinds of problems)
fabic has joined #rust-embedded
<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...
<re_irc> ... acceleration would be sweet.
<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)
<re_irc> <MathiasKoch> Sigh..
<re_irc> <MathiasKoch> anything that is possible to source at all?
<re_irc> <MathiasKoch> Cost is not really an issue currently
<re_irc> <matoushybl> maybe dirbaio can give you some pointers on NRF, they are using them a lot
<re_irc> <matoushybl> +obtaining
<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
<re_irc> <James Munns> Yeah, those were exactly my suggestions
<re_irc> <matoushybl> but I've seen some nucleos drop on mouser in quite large quantities, so maybe it is getting a bit better?
<re_irc> <James Munns> Rp2040s have some prod downsides tho, like no crypto afaik for acceleration or code readout protection
<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
<re_irc> <James Munns> What kind of quantities are you actually needing?
<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
<re_irc> <adamgreig> at least the stm32f103 has like a hundred clones that are mostly drop-in compatible :P
<re_irc> <MathiasKoch> RP2040s could be an option, but it would absolutely be with a smaller feature set in the final product :/
<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.
<re_irc> <MathiasKoch> but i guess products with less features are better than no products :p
<re_irc> <James Munns> They're pretty quick and dual core, honestly. A lot faster than an nrf52
<re_irc> <James Munns> Unless you're doing a ton of dsp
<re_irc> <matoushybl> adamgreig: :D I heard of a case where they ordered GD32V103 and were extremely surprised that it contained RISC-V core
<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.
<re_irc> <James Munns> Yeah, fair
<re_irc> <James Munns> I don't know how big a "life time buy" would be for you
<re_irc> <James Munns> Or how easily you could stuff the extras in your next product(s)
<re_irc> <James Munns> But you can buy rp2040s by the reel, and they just need jellybean clocks and SPI flash parts
<re_irc> <MathiasKoch> Nah, i was meerly looking for suggestions on availability, just like the RP2040 you suggested ๐Ÿ‘๏ธ
<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.
<re_irc> <MathiasKoch> Do you know why the RP's have the 16 MB limitation on flash?
<re_irc> <James Munns> (not that an F103 is practically any safer)
<re_irc> <James Munns> MathiasKoch: 24 bit address space, I assume?
<re_irc> <James Munns> (or an nrf52 either, for that matter)
<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
<re_irc> <James Munns> Makes sense. The rp2040 is gonna be like 3-5 bucks cheaper than anything else already tho
<re_irc> <Robert Jรถrdens> MathiasKoch: Desoldering from eval or dev boards may be a real option then.
<re_irc> <James Munns> But good call on the atecc
<re_irc> <James Munns> Robert Jรถrdens: Yeah, that's why I asked about quantity lol
<re_irc> <MathiasKoch> Yeah.. We are talking a few thousands, so i would rather not :p
<re_irc> <James Munns> Wouldn't want to do that for more than 10-100 units, unless you were really separate tho
<re_irc> <James Munns> *desperate
<re_irc> <James Munns> (like, already have 500 expensive boards with everything else already soldered down and orders waiting desperate)
<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
<re_irc> <James Munns> (which I've seen in the last two years, luckily not for me)
<re_irc> <matoushybl> wtf :D
<re_irc> <James Munns> Ooooooooooooooof
<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
<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)
<re_irc> <MathiasKoch> Makes sense ๐Ÿ‘๏ธ How far is the rp2040 rust hal?
<re_irc> <James Munns> I've not used it, but seems to be progressing?
<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
<re_irc> <matoushybl> Embassy also has some parts working
<re_irc> <Noah> James Munns: yup should be fine :)
<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):
<re_irc> <James Munns> (I really need to get my Pico boards out of the drawer and onto the bench one of these days...)
<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.
<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
<re_irc> <lulf> Yeah, I love the linkerscript codegen idea
<re_irc> <lulf> * I love the linkerscript codegen idea, and I think there's not enough rust bootloaders anyway :D
<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...
<re_irc> ... your own locking and use "unsafe".) Great community at
<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...
<re_irc> ... with RISC-V" or just general words of encouragement ๐Ÿ˜€
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
diagprov has quit [Ping timeout: 276 seconds]
diagprov has joined #rust-embedded
Socke has quit [Ping timeout: 240 seconds]
Socke has joined #rust-embedded
fabic has quit [Ping timeout: 276 seconds]
Socke has quit [Ping timeout: 256 seconds]
Amadiro__ has joined #rust-embedded
Amadiro_ has quit [Ping timeout: 248 seconds]
Socke has joined #rust-embedded
gsalazar has quit [Ping timeout: 272 seconds]
<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 ๐Ÿ‘
<re_irc> <yruama_lairba> hi, question in an embedded context, in which situation it's reasonnable to panics ?
Foxyloxy has quit [Remote host closed the connection]
Foxyloxy has joined #rust-embedded