<re_irc>
<@jaxter184:matrix.org> I'm looking at the stm32h7xx example for exti interrupts, and I don't really understand where the exti register numbers are coming from
<re_irc>
<@jaxter184:matrix.org> according to the macro, it seems that PE3 corresponds to EXTICR1, but it uses EXTI3, and there are no other mentions of EXTI in the hal macro
<re_irc>
<@jaxter184:matrix.org> and oh wait, i think i get it? EXTI3 comes from the fact that its PE_3_?
<re_irc>
<@dirbaio:matrix.org> yes
<re_irc>
<@jaxter184:matrix.org> and i guess EXTI9_5 corresponds to both 9 and 5? or 9 through 5?
<re_irc>
<@dirbaio:matrix.org> through
<re_irc>
<@jaxter184:matrix.org> cool, always fun to ask a question and immediately realize the answer 🙃
<re_irc>
<@jaxter184:matrix.org> but thanks for the confirmation
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc>
<@firefrommoonlight:matrix.org> And, for GPIO, EXTI1 is Px1, EXTI2 is Px2 etc, where "x" is the port letter
<re_irc>
<@firefrommoonlight:matrix.org> +pin
<re_irc>
<@firefrommoonlight:matrix.org> Has anyone used the "fdcan" crate? I'm having a struggle~!
<re_irc>
<@firefrommoonlight:matrix.org> +Trying loopback first, although I have 2 devices wired together with tranceivers.
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> *CAN is working
<re_irc>
<@firefrommoonlight:matrix.org> I had the wrong MSG_RAM address
brazuca has quit [Ping timeout: 260 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> *Works on G4, but not H7 for some reason
<re_irc>
<@firefrommoonlight:matrix.org> (They are friends in this setup)
bjc has quit [Ping timeout: 268 seconds]
cosj[m] has quit [*.net *.split]
sigmaris has quit [*.net *.split]
Abhishek_ has quit [*.net *.split]
jsolano has quit [*.net *.split]
sauce has quit [*.net *.split]
jsolano has joined #rust-embedded
sauce has joined #rust-embedded
Abhishek_ has joined #rust-embedded
cosj[m] has joined #rust-embedded
sigmaris has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Works on H7 now. Also a message ram problem, although a bit more subtle of one
<re_irc>
<@firefrommoonlight:matrix.org> I don't know what message RAM is, but I already don't like it!!
<re_irc>
<@firefrommoonlight:matrix.org> * it!
<re_irc>
<@firefrommoonlight:matrix.org> Thanks to for making the fdcan lib!
<re_irc>
<@firefrommoonlight:matrix.org> Thanks to for making the fdcan lib!
lehmrob has quit [Ping timeout: 246 seconds]
starblue has quit [Ping timeout: 265 seconds]
starblue has joined #rust-embedded
bjc has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@mathias_koch:matrix.org> Does anyone know of a protobuf library that works "no_std" & "no_alloc", even with the strict limitations it would impose, eg by only suporting a subset of protobuf types?
<re_irc>
<@jamesmunns:beeper.com> I haven't seen one. In the C world, I've used nanopb to some success
<re_irc>
<@mathias_koch:matrix.org> Hmm :(
<re_irc>
<@jamesmunns:beeper.com> I'm guessing you want protobuf for compat with some existing service?
<re_irc>
<@korken89:matrix.org> Hmm, does anyone else have issues with crates.io ? I'm not able to publish crates
<re_irc>
<@mathias_koch:matrix.org> Exactly.. Otherwise i would have gone with a more embedded-friendly encoding
<re_irc>
<@jamesmunns:beeper.com> : I think github is having issues atm
<re_irc>
<@jamesmunns:beeper.com> I can't push a branch at all
<re_irc>
<@diondokter:matrix.org> : I think github is having a moment
<re_irc>
<@korken89:matrix.org> Yeah I'm also unable to push to github
<re_irc>
<@jamesmunns:beeper.com> rough month for gh :/
<re_irc>
<@korken89:matrix.org> But I could publish a crate (macros) but when i want to publish the crate that depends on the macros crate the crates.io index can't be updated it seems
<re_irc>
<@k900:0upti.me> Github is definitely having a moment, yes
<re_irc>
<@korken89:matrix.org> Is crates.io hosted on github?
<re_irc>
<@diondokter:matrix.org> The crate index yeah
<re_irc>
<@k900:0upti.me> The new index isn't
<re_irc>
<@k900:0upti.me> But it's not default yet
<re_irc>
<@korken89:matrix.org> Ah then it makes sense that I can't publish the dependent crate
<re_irc>
<@diondokter:matrix.org> Ah so if you use nightly, then maybe it'll work :P
<re_irc>
<@jamesmunns:beeper.com> I'd expect not for back-compat reasons, they probably keep things in sync
<re_irc>
<@diondokter:matrix.org> Wanna test your luck :D
<re_irc>
<@jamesmunns:beeper.com> but hey, could be fun to cause cratesio inconsistencies lol
<re_irc>
<@juliand:fehler-in-der-matrix.de> A question to the folks around here that use embedded Rust in a professional/production context: Which embedded platforms or microcontrollers do you usually use?
<re_irc>
I was told that some platforms like the ESP32 and RP2040 are rarely used for professional applications since the peripherals and core are often buggy/unstable and they lack internal flash (firmware and secrets easy to read out). Is that true? And if so, what are the alternatives?
<re_irc>
<@halfbit:matrix.org> I wonder how many folks are using it in a production context yet
<re_irc>
<@jamesmunns:beeper.com> RP2040 is pretty new, I haven't seen it in many commercial applications, but starting to see it in more places (like the framework modular keyboard thing). ESP32s are... everywhere. I've worked some places that actively chose not to use them (though most of it was reliability of off the shelf modules, and difficulty of meeting FCC cert due to that).
<re_irc>
<@jamesmunns:beeper.com> From the commercial uses of Rust that I've seen, I've mostly seen STM32 and nRF52 usage. That being said: those were already widely used chips in commercial applications
<re_irc>
<@halfbit:matrix.org> rust on nxp s32 would be interesting
<re_irc>
<@ithinuel:matrix.org> : The rp2040 has no internal flash, so there's indeed not the best for security/tampering protection.I'm not sure about the esp32 but a reason the rp2040 isn't as much used in commercial products is that its power consumption is (allegedly) a bit higher than the competition. But that may not always be that big of a concern.Other silicon vendor have been present in the industry for a lot longer and their b2b support story is...
<re_irc>
... established which definitely make them safe options.
<re_irc>
<@jamesmunns:beeper.com> (not vendor supported, but I knew I had seen it around somewhere)
<re_irc>
<@burrbull:matrix.org> looks abandoned
<re_irc>
<@halfbit:matrix.org> that's pretty ancient at this point... and there's various s32's, one the larger ones I saw I think had two clusters of 4 cortex-r cores
<re_irc>
<@jamesmunns:beeper.com> Yeah, true! I imagine the S32 (for automotive industry primarily, yeah?) is less about "could we run Rust on it" and "will it fit into our certification plan".
<re_irc>
<@halfbit:matrix.org> so 8 cortex-r cores, some m cores, dma's, can's, eth's, etc
<re_irc>
<@halfbit:matrix.org> like could legit build a fully autonomous drone on it
<re_irc>
<@halfbit:matrix.org> none of this "hook up yer st micro to the pi micro" cobbling
<re_irc>
<@jamesmunns:beeper.com> Yeah, I mean the building blocks are there. I imagine you could use svd2rust (or chiptool or whatever) just as well.
<re_irc>
<@halfbit:matrix.org> seeing how svd2rust produced 1mloc for the imxrt, and took way too long to compile, I think it'd be pushing what would feel ok with that tooling
<re_irc>
<@halfbit:matrix.org> chiptool could be cool, maybe reusing what imxrt-rs does for module generation
<re_irc>
<@jamesmunns:beeper.com> always chiptools and the rals. There's definitely many ways to make things happen.
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc>
<@halfbit:matrix.org> seeing how svd2rust produced 1mloc for the imxrt, and took way too long to compile (10+ minutes for the regmap basically... horrible), I think it'd be pushing what would feel ok with that tooling
<re_irc>
<@jamesmunns:beeper.com> but yeah, it would be cool if NXP did it :)
<re_irc>
<@halfbit:matrix.org> for sure, it s a bit of a chicken and egg them with them
<re_irc>
<@halfbit:matrix.org> if customers don't ask, they don't do
<re_irc>
<@halfbit:matrix.org> but since they don't do it, there's no customers asking for it
<re_irc>
<@halfbit:matrix.org> for sure, its a bit of a chicken and egg them with them
<re_irc>
<@jamesmunns:beeper.com> If you have a support rep, you should definitely bug them about it!
<re_irc>
<@halfbit:matrix.org> "whats yer volume" will be the first question that comes up, guarantee
<re_irc>
<@halfbit:matrix.org> * guaranteed
<re_irc>
<@jamesmunns:beeper.com> ¯\_(ツ)_/¯ maybe! maybe not. Always worth noting. If they do finally get a high volume customer requesting after hearing 5 or 10 smaller volumes requesting, maybe it helps
<re_irc>
<@jamesmunns:beeper.com> or maybe it doesn't! But then it's up to someone else.
<re_irc>
<@halfbit:matrix.org> yeah fair enough
<re_irc>
<@halfbit:matrix.org> or you know, one vendor does it...
<re_irc>
<@halfbit:matrix.org> can't wait to see what sort of falls out from esp-rs
<re_irc>
<@halfbit:matrix.org> right, tricore support is pretty unique though I feel like, its one of the first sort of esoteric arch's supported in my mind
<re_irc>
<@halfbit:matrix.org> like compared to arm and sort of riscv, there's esoteric arch's that really require closed toolchains otherwise and that adds a whole extra barrier to entry
<re_irc>
<@jamesmunns:beeper.com> Yeah, esoteric in the sense of "only used in specific industries", but like everywhere there.
<re_irc>
> The development of secure systems is critical for the automotive market. The Rust programming language, with its built-in support for memory-safe software development, is an important enabler for the design of mission-critical automotive software. Infineon Technologies AG takes the first step to create a Rust ecosystem in the embedded sector.
<re_irc>
<@halfbit:matrix.org> the same could be said of xtensa and arc
<cr1901>
How am I supposed to create a UsbDevice?!
<re_irc>
<@jamesmunns:beeper.com> uhhh, "singleton!" maybe? lemme go find an example
<cr1901>
I tried going the Mutex<OnceCell<>> approach, but the references from that won't live long enough to pass to an outer stack frame (also I don't really need a Mutex, I just used it for Sync)
<re_irc>
<@jamesmunns:beeper.com> cr1901: yeah, I do it with rtic's managed resources, but you could do the same with the "singleton!" macro from cortex-m, or if you're on msp430, you could duplicate it
<cr1901>
for once this is cortex-m; I've no immediate plans to do a msp430 usb port
<cr1901>
(Tho I've done it for tinyusb, so it should be doable)
<re_irc>
<@jamesmunns:beeper.com> ah yeah, then something like "let usb = singleton!(:UsbBusAllocator<Usbd<UsbPeripheral<'static>>> = Usbd::new(UsbPeripheral::new(device.USBD, clocks))).unwrap();"
<re_irc>
<@jamesmunns:beeper.com> (that's for the nrf52, could do the same for whatever other chip, your types may vary)
<cr1901>
Yes, this'll do what I want, thanks. Also, I notice it's impl'd in terms of interrupt::free instead of critical_section::with. Wonder if that's significant...
<re_irc>
<@jamesmunns:beeper.com> probably just waiting on cortex-m v0.8 to arrive
<re_irc>
<@dirbaio:matrix.org> if you don't want to write out the type, you can use this thing (nightly-only)
<cr1901>
It fails the dirbaio-compliance suite due to cfg!()s sprinkled as needed :P
<re_irc>
<@dirbaio:matrix.org> :D
<cr1901>
Also TIL about static_cell. wonder how it compares to Mutex<OnceCell<>> (which I use currently in msp430 land. Actually I don't get the error I'm seeing...
<re_irc>
<@dirbaio:matrix.org> it has an atomic bool, takes it with a CAS operation
<re_irc>
<@dirbaio:matrix.org> so better for realtime (no CS) if you have CAS. Not that it matters much because you just do it at startup lol
<cr1901>
ignore that last part, yes I do understand the error (forgot to wrap the OnceCell in Mutex). But yea, Mutex<OnceCell<>> won't give me a static lifetime, while StaticCell will
<re_irc>
<@jamesmunns:beeper.com> Because you can only hold the reference as long as the mutex is locked, afaik?
<re_irc>
<@jamesmunns:beeper.com> Mutex also gives you a &mut, which I think static cell doesn't
<re_irc>
<@dirbaio:matrix.org> it converts "T" to "&'static mut T"
<re_irc>
<@jamesmunns:beeper.com> ah no, that's not true, nvm
<cr1901>
critical_section::Mutex<> (sorry)
<re_irc>
<@jamesmunns:beeper.com> : I was confusing it with... something else in embassy that does that?
<cr1901>
Yea, and staticcell locks internally (tho I'd need to add a portable_atomic support to use it on msp430 since AFAIK I never added atomic_polyfill support to msp430 before it was deprecated)
<re_irc>
<@dirbaio:matrix.org> dunno. StaticCellcomes from embassy (it was called Forever before)
<re_irc>
<@dirbaio:matrix.org> if you send a PR to atomic-polyfill I can get it released
<re_irc>
<@jamesmunns:beeper.com> : Yeah, there was something else that was like "only gives you half of what ArcMutex (or something else) does"
<re_irc>
<@jamesmunns:beeper.com> it got discussed recently
<re_irc>
<@jamesmunns:beeper.com> but yeah, I was just wrong about static cell
<cr1901>
I'd rather add a disabled-by-default feature to static_cell that uses portable-atomic if enabled
<re_irc>
<@dirbaio:matrix.org> but yeah, i'd rather people stopped using "atomic-polyfill" and switched to "portable-atomic"
<re_irc>
<@dirbaio:matrix.org> except for that "--cfg", grrrr
<re_irc>
<@jamesmunns:beeper.com> Ah, when did you start suggesting that?
<cr1901>
after the critical-section support got merged I think :)
<re_irc>
<@dirbaio:matrix.org> I haven't officially deprecated "atomic-polyfill" yet
<re_irc>
<@jamesmunns:beeper.com> Good to know! I know I chatted with Eliza whether a-p or p-a made more sense for maitake
<re_irc>
<@jamesmunns:beeper.com> (she went with p-a)
<re_irc>
<@dirbaio:matrix.org> but I probably will
<re_irc>
<@dirbaio:matrix.org> PA with "critical-section" feature is equivalent to AP
<re_irc>
<@dirbaio:matrix.org> but it supports more targets etc
<re_irc>
<@dirbaio:matrix.org> it's an insane ocean of "cfg"s to support them all. No way in hell I want to maintain that
<re_irc>
<@dirbaio:matrix.org> so if I'm not going to try to "compete", better to point people to PA
<re_irc>
<@dirbaio:matrix.org> no point in splitting the ecosystem
<cr1901>
This was ultimately my concern w/ PA and AP existing, but I didn't want to seem like an asshole for bringing it up
<re_irc>
<@dirbaio:matrix.org> the only thing that bothers me is it has a "unsafe assume single core" flag that's more efficient than "critical-section" (only takes CS for CAS ops, not load/store)
<re_irc>
<@dirbaio:matrix.org> but it's a "--cfg", not a Cargo feature
<re_irc>
<@dirbaio:matrix.org> because ItS uNSaFe
<cr1901>
I rely on that behavior, but it's unconditionally enabled for msp430 b/c there are no multicore msp430s and prob never will be
<cr1901>
I'm not sure if accidentally enabling an unsound optimization is on the level of deliberately unsafety in safe code like "File::open("/dev/mem")"
<cr1901>
Related: usb_serial impls serial HAL traits, but they have to be driven from usb_poll periodically. Unless you're in a tight loop where you can call poll, seems like the only practical way to use the HAL traits is to... have an interrupt-driven poll :)
<cr1901>
(or use embassy)
<re_irc>
<@jamesmunns:beeper.com> Yeah, embassy with the e-h-async traits would work well there.
<re_irc>
<@dirbaio:matrix.org> yep. blocking USB doesn't work
<cr1901>
doesn't work except for cookie cutter examples*. And this example doesn't fit that mold
<cr1901>
God I am sick on working on the postcard-infomem example app
<re_irc>
<@dirbaio:matrix.org> even in the simplest example you have to spin polling on both the usb-serial and the usb-bus :)
<re_irc>
<@dirbaio:matrix.org> spinning on just the usb-serial will hang
<re_irc>
<@dirbaio:matrix.org> so it can't impl the embedded-hal traits at all
<cr1901>
yea the usb_serial example code has calls to poll and read/write
<re_irc>
<@juliand:fehler-in-der-matrix.de> : Thanks for the input. Indeed very interesting what will happen in the future, but there is going to be some pressure on to the manufacturers to support Rust if Espressif and Infineon are having success with it.
<re_irc>
<@jamesmunns:beeper.com> fwiw, my memory of why rpi didn't put flash readout protection on there (or why it wasn't a priority) is that generally, nobody has really delivered readout protection that survives the first serious decapping/glitching attack.
<re_irc>
<@jamesmunns:beeper.com> like, you can buy an STM32F103 or nRF51/52 today that has "readout protection", but it's not really particularly harder than just dumping the external flash
<re_irc>
<@dirbaio:matrix.org> newer nrf52's are supposed to be fixed
<re_irc>
<@jamesmunns:beeper.com> (still, I get "some protection" is better than "no protection", but practically, I get why they didn't prioritize it)
<re_irc>
<@dirbaio:matrix.org> ... until someone gives a serious try lol
<re_irc>
<@jamesmunns:beeper.com> : Fair, though it's generally always "for now". Maybe the industry gets better at glitching and decapping protection
<re_irc>
<@dirbaio:matrix.org> +them
<re_irc>
<@jamesmunns:beeper.com> lol yeah, "no longer works with known techniques" is different than "fixed", but it does re-raise the bar of how hard you have to try a bit
<cr1901>
so it can't impl the embedded-hal traits at all <-- well, I'm going to implement the HAL traits in-line for my purposes. I can envision a crate which Sends the device and serial device to an interrupt/dedicated thread and you do all your accesses via a queue for various ARM micros
<re_irc>
<@jamesmunns:beeper.com> I think the trick in that example is that they never tx/rx more than 64 bytes at a time
<re_irc>
<@jamesmunns:beeper.com> so it gets buffered into the usb driver
<re_irc>
<@jamesmunns:beeper.com> if you ever did _not_ that, it'd deadlock
<re_irc>
<@jamesmunns:beeper.com> maybe not, maybe it'd just spit out wouldblock
<cr1901>
In the pico_usb_serial_interrupt example?
<re_irc>
<@jamesmunns:beeper.com> ah, no, the usbd-serial example you linked