<re_irc>
<@vadixidav:matrix.org> however, it would be better if this could be put into the PAC so that this boilerplate doesnt need to be added to the final application
<re_irc>
<@vadixidav:matrix.org> for whatever reason, Rust chooses to elide the symbol during the compilation process from the PAC
<re_irc>
<@vadixidav:matrix.org> I dont know at what stage it gets removed, but putting it outside of the final binary's source code seems to cause it to get elided
<re_irc>
<@vadixidav:matrix.org> I have searched on google and the best thing I could find is some people say to use "#[used]", but that doesnt actually work in practice
<re_irc>
<@vadixidav:matrix.org> I am not sure where I would need to look to figure out why this is being elided, but I have noticed that other PACs appear to be able to include their vector table using the exact same msp430-rt in the PAC itself: https://github.com/YuhanLiin/msp430fr2355/blob/master/src/lib.rs#L69
<re_irc>
<@vadixidav:matrix.org> ive ensured I am using all the same linker arguments, anyone have any idea where I should go from here?
<re_irc>
<@vadixidav:matrix.org> command line I am using to test:
<re_irc>
<@vadixidav:matrix.org> I actually found this fantastic crate that basically solves all problems msp430 related, and it seems to be pretty unknown at current: https://crates.io/crates/msp430-periph
<re_irc>
<@vadixidav:matrix.org> seems to generate code to interface with every MSP430 (even rare ones)
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@korken89:matrix.org> Does anyone know of a good FFT lib that can be used in embedded? 32-128 points is my usecase
<re_irc>
<@korken89:matrix.org> In the old C days I used CMSIS-DSP, but maybe there is a good Rust lib today so I don't need to FFI :)
lehmrob has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> Hand-rolling an FFT sounds fun. ðĪ
<re_irc>
<@therealprof:matrix.org> Last time I wrote an FFT implementation was over 20 years ago. Could check whether there're still leftovers from my AltiVec (i)DCT code in some OpenSource project... ð
lehmrob has quit [Ping timeout: 252 seconds]
<re_irc>
<@adamgreig:matrix.org> Geordon Worley: Does your binary actually use the PAC at all, besides declaring a dependency on it? You need something like "use msp430i20xx as _;", otherwise rust sees that the PAC is completely unused and doesn't include it, so the interrupts never make it through
<re_irc>
<@2:0x2c.org> I finally managed to compile a C example for the Silabs EFR32BG22; now the question is, how do I integrate rust into this? Seems the path of least resistance is to build a rust static library and link it using their generated makefile, but I think I'd prefer to drive the link/build with build.rs
crabbedhaloablut has quit [Ping timeout: 255 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@mathy_v:matrix.org> : I did exactly this for the ESP32, build is driven from Rust and I use the CMake crate to generate a static lib for the C code.
rardiol has joined #rust-embedded
<re_irc>
<@2:0x2c.org> Mathy: do you have that code up somewhere?
<re_irc>
<@2:0x2c.org> one question is, how will linking that static lib interact with weak symbols, etc.
<re_irc>
<@mathy_v:matrix.org> : Unfortunately, no :-)
<re_irc>
<@mathy_v:matrix.org> : The general rule I follow is: keep the interface between the two worlds as simple as possible. Luckily my use case allows (for now) to limit interaction to passing and returning parameters by value which makes it that much easier. If you have ever developed complex code for Windows inside DLLs you can take lessons learned from that: hide as much as possible, on both sides ðĪĢ.
rardiol has quit [Ping timeout: 265 seconds]
<re_irc>
<@2:0x2c.org> yes, my intent is to design the rust application interface so that platform details are totally abstracted
<re_irc>
<@thejpster:matrix.org> Anyone going to Embedded World?
<re_irc>
<@therealprof:matrix.org> : Not me, the years before the pandemic became more and more boring...
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> : Cmsis-dsp, wrapped with Bingen
<re_irc>
<@firefrommoonlight:matrix.org> : No - will check that out later today. You mentioning it earlier is what inspired my msg
<re_irc>
<@firefrommoonlight:matrix.org> I know you mentioned that explicitly, but it works well
<re_irc>
<@firefrommoonlight:matrix.org> +Re CMSIS and FFI:
<re_irc>
<@firefrommoonlight:matrix.org> There's a pure rust lib floating around as well, but it has limited functionality (maybe the functionality you need though?)
<re_irc>
<@firefrommoonlight:matrix.org> Here's a wrapper I wrote on top of it that makes the API a bit nicer. Replaced pointers with array refs etc: https://github.com/David-OConnor/cmsis-dsp-api
<re_irc>
<@dngrs:matrix.org> Oh that's from you? Nice
<re_irc>
<@dngrs:matrix.org> Been meaning to try it for a while
<re_irc>
<@firefrommoonlight:matrix.org> Might be worth skimming the source file to see what those wrappings do. Just makes it a bit more... Rusty
<re_irc>
<@firefrommoonlight:matrix.org> And if you want to use the FFI directly, use the (incomplete) wrapper I wrote, or wrap it yourself
<re_irc>
<@n8tlarsen:matrix.org> > Hi everyone! I'm working on Rust firmware for a project which has historically been written in C/C++. The MCU doesn't have a HAL but does have a PAC. I've been working on generic peripheral functions but I'm not sure of the best way to structure them. The PAC source (https://github.com/n8tlarsen/efm32tg-pacs/tree/emf32tg11b120_derives/pacs/efm32tg11b/src/efm32tg11b120) has several timer modules all derived from...
<re_irc>
... "wtimer0". The following code compiles but I'm not sure if it's the best way to implement it:
<re_irc>
> tim.ifc.write(|w| w.of().set_bit()); => &mut W
<re_irc>
> tim.ien.write(|w| w.of().set_bit()); => &mut W
<re_irc>
> tim.cmd.write(|w| w.start().set_bit()); => &mut W
<re_irc>
> }
<re_irc>
Could someone point me in the right direction on this? (Posted a few days ago but I think it got lost in the thread)
rardiol has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> What's with the "=> &RegisterBlock"?
<re_irc>
<@n8tlarsen:matrix.org> Hmm looks like an artifact from nvim implementation of rust analyzer
lehmrob has quit [Quit: Konversation terminated!]
<re_irc>
<@n8tlarsen:matrix.org> > Hi everyone! I'm working on Rust firmware for a project which has historically been written in C/C++. The MCU doesn't have a HAL but does have a PAC. I've been working on generic peripheral functions but I'm not sure of the best way to structure them. The PAC source (https://github.com/n8tlarsen/efm32tg-pacs/tree/emf32tg11b120_derives/pacs/efm32tg11b/src/efm32tg11b120) has several timer modules all derived from...
<re_irc>
> pub trait TimerCounter {
<re_irc>
... "wtimer0". The following code compiles but I'm not sure if it's the best way to implement it:
<re_irc>
Could someone point me in the right direction on this? (Posted a few days ago but I think it got lost in the thread)
<re_irc>
<@n8tlarsen:matrix.org> Edited out the rust analyzer neovim type resolutions.
lehmrob has joined #rust-embedded
<re_irc>
<@2:0x2c.org> how do you typically automate building bin/hex files and flashing those? is there some cargo stuff i can use to implement other tasks?
<re_irc>
<@sourcebox:matrix.org> : I wish that the functionality of this crate would be included within the "cortex-m" crate since this already offers a delay provider using the SysTick. But unfortunately, this delay provider is done in a way that's incompatible with using the SysTick as monotonic time source because it modifies the counter value inbetween.
<re_irc>
<@sourcebox:matrix.org> For DFU, I've written a desktop app to flash the devices via a GUI. It should work with newer STM32s like L4, G4 etc. but not yet with older ones like F3 series. If someone is interested: https://github.com/sourcebox/dfu-buddy
<re_irc>
<@sourcebox:matrix.org> I hope I can get it running with the older ones, there's something with the USB protocol that is different there.
<re_irc>
<@2:0x2c.org> heh seems probe-rs supports my mcu, but openocd doesn't
fabic has quit [Ping timeout: 248 seconds]
<re_irc>
<@2:0x2c.org> i'm trying to compile and link for "thumbv8m.main-none-eabihf", but i'm getting liker errors about incompatible objects, regarding CPU architecture and VFP use
<re_irc>
<@2:0x2c.org> ah, something about nostartfiles and linking with gcc
IlPalazzo-ojiisa has joined #rust-embedded
xnor has quit [Quit: WeeChat 3.4]
xnor has joined #rust-embedded
xnor has quit [Client Quit]
xnor has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
Shell- has joined #rust-embedded
a2800276_ has joined #rust-embedded
cybernaut has joined #rust-embedded
Shell has quit [Killed (NickServ (GHOST command used by Shell-))]
Shell- is now known as Shell
a2800276 has quit [Ping timeout: 248 seconds]
GenTooMan has quit [Ping timeout: 248 seconds]
cybernaut has quit [Client Quit]
GenTooMan has joined #rust-embedded
Darius has quit [Read error: Connection reset by peer]
Darius has joined #rust-embedded
cybernaut has joined #rust-embedded
GenTooMan has quit [Ping timeout: 248 seconds]
<re_irc>
<@mehmet:grusbv.com> Is there anyone that use Asahi Linux on an ARM Mac and do embedded stuff?
cybernaut has quit [Quit: Leaving]
<re_irc>
<@dirbaio:matrix.org> what's the best practice with panic handlers and interrupts?
<re_irc>
disable interrupts, do udf?
<re_irc>
<@dirbaio:matrix.org> just spin?
<re_irc>
disable interrupts and spin?
<re_irc>
<@firefrommoonlight:matrix.org> : Your "cortex-m-systick" lib is perf; thx!
<re_irc>
<@jamesmunns:beeper.com> IMO (panic persist is on the list) is that disable interrupts and reset should be the default, unless you have a REALLY good reason to do otherwise
<re_irc>
<@dirbaio:matrix.org> also most hadcode cortex-m for "disable interrupts"
<re_irc>
<@jamesmunns:beeper.com> tbf when I write panic persist (mostly copying panic-ramdump, thanks :D), nothing else was stable. the docs say "support for other platforms welcome" :p
<re_irc>
<@jamesmunns:beeper.com> * wrote
<re_irc>
<@9names:matrix.org> Would you accept disable interrupts and spin if there's a watchdog involved?
<re_irc>
<@dirbaio:matrix.org> but using "critical-section" is not exactly the same, because it's going to lock the CS for both cores
<re_irc>
<@adamgreig:matrix.org> Maybe hardfault then? I pretty rarely want it to immediately reset on panic
<re_irc>
<@dirbaio:matrix.org> and multicore panic handling is also a cursed pandoras box
<re_irc>
<@jamesmunns:beeper.com> but tbh, you can "well what about..." for literally any panic/crash case
<re_irc>
<@jamesmunns:beeper.com> this is probably one of those "there will never be a one size fits all" solution ones.
<re_irc>
<@dirbaio:matrix.org> in rp2040 currently if one core panics, the other keeps going :D
<re_irc>
<@jamesmunns:beeper.com> lol
<re_irc>
<@jamesmunns:beeper.com> _that_ does seem suboptimal :D
<re_irc>
<@dirbaio:matrix.org> and also "sys_reset" resets only the current core, not both!
<re_irc>
<@dirbaio:matrix.org> * "SCB::sys_reset"
<re_irc>
<@jamesmunns:beeper.com> hurk!
<re_irc>
<@dirbaio:matrix.org> ðĪŠ
<re_irc>
<@jamesmunns:beeper.com> (is there _any_ sort of portable "kill all the cores" thing even on cortex m?)
<re_irc>
<@jamesmunns:beeper.com> udf on one core is still probably still only one core
<re_irc>
<@mabez:matrix.org> : Was the same story for the multicore variants of esp's :D, we added a feature to esp-backtrace to halt both cores on a panic
<re_irc>
<@adamgreig:matrix.org> No, basically all the multi cores are doing their own thing lol
<re_irc>
<@dirbaio:matrix.org> I didn't see it on rp2040. there's rp2040-specific regs to reset the other core
<re_irc>
<@jamesmunns:beeper.com> its a shame thumbv8 didn't do anything to make multicore more reasonable.
<re_irc>
<@dirbaio:matrix.org> and if you reset the current core instead of the other, chip is locked until powercycle :D
<re_irc>
<@jamesmunns:beeper.com> but hey, M0+ until 2095, so what are you gunna do.
<re_irc>
<@adamgreig:matrix.org> Heh
<re_irc>
<@mabez:matrix.org> It's a shame "core::intrinsics::abort" isn't stable, then it would be a lot easier to reset on panic without having to have platform specific deps
<re_irc>
<@jamesmunns:beeper.com> but really, "how should you crash" is one of those "seems simple, actually incredibly hard" systems problem
<re_irc>
which is proposing to use "critical-section" for "disable interrupts", to make it portable across ARM+RISCV
<re_irc>
<@dirbaio:matrix.org> but I have no idea whether it's a good idea or not...
<re_irc>
<@dirbaio:matrix.org> for example it could cause another core to hang trying to acquire the CS, and perhaps in a way that you can't orderly shut it down because it's disabled interrupts
<re_irc>
<@dirbaio:matrix.org> I think best practice would be to print the panic message and then do "udf" to elevate it to a HardFault
<re_irc>
<@jamesmunns:beeper.com> isn't the default hardfault handler a loop?
<re_irc>
<@dirbaio:matrix.org> yeah... and override that
<re_irc>
<@dirbaio:matrix.org> in HardFault handler perhaps do more printing, and _then_ do the actual error handling (reboot, whatever)
<re_irc>
<@jamesmunns:beeper.com> I guess I should campaign to change the default handler to a reboot :D
<re_irc>
<@dirbaio:matrix.org> because some crashes can go straight to HardFault
<re_irc>
<@mabez:matrix.org> What if someone puts a panic call inside the hard fault handler? â ïļ
<re_irc>
<@jamesmunns:beeper.com> really, everything hard fault handler should probably be asm anyway
<re_irc>
<@jamesmunns:beeper.com> like, NMIs really screw the whole safety guarantee of everything anyway lol
<re_irc>
<@jamesmunns:beeper.com> you can basically arrive from any sort of corrupt state in NMIs, sorta the same as the conversation with init
<re_irc>
<@jamesmunns:beeper.com> ("should be asm" might be a little overboard, but is the pedantically correct answer, IMO)
<re_irc>
<@dirbaio:matrix.org> meanwhile someone trying to print hardfault coredumps through usb serial :D
<re_irc>
<@mabez:matrix.org> I do agree, however that won't stop people doing it :D, unless naked functions stabilizes soon and we can force them to write inline asm for handlers
<re_irc>
<@jamesmunns:beeper.com> yeah, I mean, I get it, practically is likely fine, but IMO you're in the "_should_ work..." state of UB at that point :D
<re_irc>
<@jamesmunns:beeper.com> (you get fun cases like, "what if you hard fault before main", or "what if you are hard faulting because of some other dma/ffi caused memory corruption", but again, I appreciate "is practically good more often than not")
GenTooMan has joined #rust-embedded
<re_irc>
<@jannic:matrix.org> It's also very much an "it depends" situation. In many cases it's fine to say well, it's broken anyways, let's try to push out as much debug info as possible. And if the only way to get that is USB serial, well, why not?
<re_irc>
<@jannic:matrix.org> If it's in any way security critical, a clean reset to some known state might be preferable.
<re_irc>
<@jamesmunns:beeper.com> I mean, I can keep going with the "well what about" doom scenarios, but like, yeah. Once you're IN a hard fault, you KNOW you are having a bad day. Pretty much no (portable) guarantee about the environment.
<re_irc>
<@jamesmunns:beeper.com> anyway, this is super off topic, and it's not even a meeting day :D
<re_irc>
<@dirbaio:matrix.org> critical-section in the panic handler, yes or no? ð
<re_irc>
<@jamesmunns:beeper.com> I'd prooooobably say no, because critical section impls are not guaranteed to disable interrupts
<re_irc>
<@jamesmunns:beeper.com> like, the nrf-softdevice one doesn't (fully), for example
<re_irc>
<@dirbaio:matrix.org> hmm
<re_irc>
<@jamesmunns:beeper.com> dunno if that could still allow rust code to get called (via callbacks?) tho
<re_irc>
<@dirbaio:matrix.org> : in the particular case of the softdevice, no
<re_irc>
<@dirbaio:matrix.org> but it's true it's not guaranteed
<re_irc>
<@dirbaio:matrix.org> the c-s contract is "no other CS can run concurrently", not "no other code can run concurrently"
<re_irc>
<@dirbaio:matrix.org> but
<re_irc>
<@dirbaio:matrix.org> on the flip side, you do need critical-section to ensure safe access to the RTT buffers in case of multicore
<re_irc>
<@dirbaio:matrix.org> you do want to prevent the other core from trying
<re_irc>
<@jannic:matrix.org> I wonder if "SCB::sys_reset()" should be unsafe. At least on rp2040 it's definitely unsound to call it when the second core is running. The first core will just restart and might access static memory which the second core uses at the same time.
<re_irc>
<@dirbaio:matrix.org> I wonder whether core0 should force-reset core1 on boot
<re_irc>
<@dirbaio:matrix.org> there's still a window for UB until it can kill core1 though..
<re_irc>
<@jamesmunns:beeper.com> tbh that seems reasonable to me
<re_irc>
<@adamgreig:matrix.org> : Not if it kills core1 before accessing any shared resources?
<re_irc>
<@dirbaio:matrix.org> dunno... perhaps core1 still has pointers into core0 stack from the previous core0 execution or something
<re_irc>
<@dirbaio:matrix.org> I think nrf53 resets the network core on app core reset, and the app core explicitly has to release it
<re_irc>
<@dirbaio:matrix.org> that seems much more sane
<re_irc>
<@jamesmunns:beeper.com> can you do that with no ram in asm?
<re_irc>
<@dirbaio:matrix.org> it's the rp2040 design that's nuts
<re_irc>
<@jamesmunns:beeper.com> like, no stack usage, no worry about corruption
<re_irc>
<@dirbaio:matrix.org> lol! probably?
<re_irc>
<@jamesmunns:beeper.com> this wasn't a joe
<re_irc>
<@jamesmunns:beeper.com> * joke
<re_irc>
<@jamesmunns:beeper.com> like, do the couple of asm instructions to kill the other core in pre_init or whatever
<re_irc>
<@dirbaio:matrix.org> the HAL would have to hook pre-init
<re_irc>
<@dirbaio:matrix.org> I think rp2040-hal decided not to?
<re_irc>
<@jamesmunns:beeper.com> doesn't rp2040 have it's own rt anyway? Or did that change?
<re_irc>
<@dirbaio:matrix.org> for the "release spinlocks" issue
<re_irc>
<@dirbaio:matrix.org> it has its own "entry" macro so it can do the release spinlock thing
<re_irc>
<@jannic:matrix.org> Also, the boot rom of the rp2040 messes with the XIP flash settings, so core1 executing code from flash will be quite unhappy when core0 reboots.
<re_irc>
<@dirbaio:matrix.org> omg this is so cursed
<re_irc>
<@dirbaio:matrix.org> what's the best way to reboot the whole rp2040 chip?
<re_irc>
<@jannic:matrix.org> Watchdog.
<re_irc>
<@dirbaio:matrix.org> I was looking through the datasheet but didn't see any obvious solution
<re_irc>
<@jannic:matrix.org> Yes, IIRC the watchdog can trigger the power-on reset sequence
<re_irc>
<@jamesmunns:beeper.com> Does the RP watchdog have done kind of "immediate kill" method? Like writing the wrong value?
<re_irc>
<@jamesmunns:beeper.com> * some
<re_irc>
<@dirbaio:matrix.org> no! :(
<re_irc>
<@jamesmunns:beeper.com> _sigh_
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<re_irc>
<@jamesmunns:beeper.com> : Tbh I feel like this is what most "loop forever" handlers SHOULD do, but that also requires setting up the watchdog in the first place lol
<re_irc>
<@jannic:matrix.org> : Sure? WATCHDOG.CTRL has a bit TRIGGER. "Trigger a watchdog reset".
<re_irc>
<@dirbaio:matrix.org> ohhh
<re_irc>
<@dirbaio:matrix.org> I stand corrected then. I guess it always works? even if you haven't configured the watchdog?
<re_irc>
<@jannic:matrix.org> Well you at least have to configure which resets the watchdog should trigger. You can configure it to reset only parts of the chip.