ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
Kat[m] has joined #rust-embedded
<Kat[m]> Quick question—is there currently anything like thread_local! for no_std? I want to have a static mut variable in a single-threaded piece of software without having to put “unsafe” through the code whenever I access it.
nadja has quit [Ping timeout: 252 seconds]
nadja has joined #rust-embedded
<M9names[m]> keep in mind that embedded is not really single-threaded (https://onevariable.com/blog/interrupts-is-threads/).
<M9names[m]> and there's no simple answer, either - it depends on how you're using your static mut. could you give some context?
<cr1901> >Volatile is not intended to be used for synchronization, and depending on whether you have multiple cores, or data cache on your CPU <-- data cache can affect volatile (when used for synchronization. If you try doing MMIO in a cached region, then indeed volatile won't save you.)?
dygear[m] has joined #rust-embedded
<dygear[m]> <M9names[m]> "keep in mind that embedded is..." <- > <@9names:matrix.org> keep in mind that embedded is not really single-threaded (https://onevariable.com/blog/interrupts-is-threads/).
<dygear[m]> I take it that the RP2350's Cortex-M33 has the required "Compare and Swap",`LDREX` / `STREX` for this to actually work properly now for AtomicBools and other Atomic data types.
<dygear[m]> > and there's no simple answer, either - it depends on how you're using your static mut. could you give some context?
<M9names[m]> yep
<dygear[m]> Excellent!
<M9names[m]> they've implemented it in a way that also works across cores even if the other core is one of the riscv ones, at least according to the datasheet.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/wGrVIkERkawKJedbjNDfjfni>)
<dygear[m]> I was pretty sure that I was going to be able to keep my program well within the 264kB of RAM that the RP2040 has, so I'm fairly sure that I won't touch the 520kB of RAM the RP2350 has.
<dygear[m]> But holy WOW! They managed to make the RISC-V cores and the ARM cores share a global exlusive lock. That's really impressive.
<dygear[m]> * But holy WOW! They managed to make the RISC-V cores and the ARM cores share a global exclusive lock. That's really impressive. Honestly, that would be one of those things that I would expect not to work, but they did it anyway.
Guest50 has joined #rust-embedded
Guest50 has quit [Quit: Client closed]
<Kat[m]> <M9names[m]> "keep in mind that embedded is..." <- > <@9names:matrix.org> keep in mind that embedded is not really single-threaded (https://onevariable.com/blog/interrupts-is-threads/).... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ymqHQonvnOwkkXkUXLxrDNHF>)
KevinClark[m] has joined #rust-embedded
<KevinClark[m]> Hey folks - I was trying to play with the pacmog crate (for wav file decoding) on an rp2040 but despite advertising that its for embedded it forgot to declare no_std and is using anyhow which needs a global allocator. I fixed the no_std but I'm struggling with whether I should just rip out anyhow myself (and just panic on err) or if there's an anyhow equivalent I should adapt instead. Any advice?
<KevinClark[m]> Alternatively, is there an error crate a la anyhow that's no-alloc? embedded_error_chain looks like a thiserror equivalent kind if?
<KevinClark[m]> s/embedded_error_chain/embedded\_error\_chain/, s/if/of/
TeXitoi[m] has joined #rust-embedded
<TeXitoi[m]> anyhow is not ideal for this use case, even with std. Better to just use a plain enum that model the different errors.
<M9names[m]> new rustc point release just dropped
lehmrob has joined #rust-embedded
lehmrob has quit [Quit: Konversation terminated!]
lehmrob has joined #rust-embedded
BenoitLIETAER[m] has joined #rust-embedded
<BenoitLIETAER[m]> Now, how is this `lib.rs` file renamed/splitted/imported/used/called within the HAL repo ?
<BenoitLIETAER[m]> Do, diving into the PAC/HAL relationship, mainly within the ATSAMx7x Rust HAL repo (and then RTIC implication).
<BenoitLIETAER[m]> It is my understanding a PAC is mainly a single (~50k lines) file (e.g. `lib.rs`) of defines, generated from the respective CMSIS\DFP\SVD xml file.
<BenoitLIETAER[m]> s/Do/So/, s/\/\\/, s/\/\\/
<ryan-summers[m]> The PAC is a separate crate entirely. It's not renamed at all, so then you can use it as my_pac::DEFINE
<BenoitLIETAER[m]> Yes, it is not a dedicated dependencies entry in the respective Cargo.toml, is it ?
<BenoitLIETAER[m]> * Yet, it is not a dedicated dependencies entry in the respective Cargo.toml, is it ?
<BenoitLIETAER[m]> oooh wait it is actually: https://crates.io/crates/atsamv71q21b
<BenoitLIETAER[m]> Beautiful
<M9names[m]> most (all?) svd2rust PACs use the tool `form` to split the giant lib.rs into separate modules, then format it.
<M9names[m]> otherwise the output would be very hard to read
<BenoitLIETAER[m]> Mmmh I guess in [this](https://github.com/atsams-rs/atsamx7x-pac) case, it is rather a custom (Python) tool that is following pre-defined templates ?
<M9names[m]> the python is just turning templates into crates for each svd file. the work of building a pac is inside the build.rs that is generated from each template.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/AwRLCJHlRkUYbdbLuzgyrihm>)
<M9names[m]> you can see how it got this way: never-ending list of chips, don't want to maintain a single pac for each one, so automate generation.
<M9names[m]> there's also another strategy you can do, which is to extract the useful/unique info from each SVD for each peripheral, work out where each chip places them and then generate PACs based on an combination peripheral @ offset - which is kinda what stm32-metapac does:
<M9names[m]> embassy-stm32 hal does a bit of the lifting there as well tbh
Vicente[m] has joined #rust-embedded
<Vicente[m]> Seems there is not Arc in thumbv6m-none-eabi core. Dou you know any alternative?
<Vicente[m]> * Seems there is no Arc in thumbv6m-none-eabi core. Dou you know any alternative?
<Vicente[m]> * Seems there is no Arc in thumbv6m-none-eabi core. Do you know any alternative?
<M9names[m]> heapless::Arc with the `portable-atomic` feature if you don't want to use a heap in your embedded program.
<M9names[m]> otherwise `portable-atomic` and an allocator
<Vicente[m]> Cool, thanks
crabbedhaloablut has quit [Ping timeout: 252 seconds]
crabbedhaloablut has joined #rust-embedded
GeorgesP[m] has quit [Quit: Idle timeout reached: 172800s]
KevinLynagh[m] has quit [Quit: Idle timeout reached: 172800s]
<Vicente[m]> Does it make a difference to use Raspberry Pi Pico SWD vs UART? Any preference?
<ryan-summers[m]> <Vicente[m]> "Does it make a difference to use..." <- Do you mean using the ITM port to print data via the SWO pin vs UART? Honestly, I would opt for neither and use RTT instead for basic logging. It has less impact on the operational state of the system, is a lot faster, and is way more configurable and easy to set up IMHO
<Vicente[m]> ryan-summers[m]: Didn't knew about it. I'm gonna check it. And yes, I asked mainly for print debug data using a Pico Probe.
<ryan-summers[m]> Yeah for anything related to development, look at RTT+defmt for logging over anything that uses actual hardware. It basically just uses a bit of RAM to do it all with zero configuration otherwise
<ryan-summers[m]> * Yeah for anything related to development, look at RTT+defmt for logging instead of anything that uses actual hardware. It basically just uses a bit of RAM to do it all with zero configuration otherwise
<Vicente[m]> Cool, tx :)
lehmrob has quit [Quit: Konversation terminated!]
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
<pacarito[m]> <JamesMunns[m]> "Feel free to ping me if you need..." <- My articles are designed for business/cto/ceo types, not the technical community. I cover things like green technologies, software engineering topics, and some cross-over. https://greenguild.substack.com
<pacarito[m]> James Munns I would like to write an article on embedded security and the state of consumer IOT, focussing on firewall/wifi appliances, so I may need some help later.
<pacarito[m]> <JamesMunns[m]> "Feel free to ping me if you need..." <- James: should I send the article preview to you directly or in the channel?
<JamesMunns[m]> Gotcha! I probably can't advise too heavily (that's my job!), but I am interested in helping to make sure info out in public around embedded rust is generally accurate. If you post it here, happy to give it a skim or answer any questions in public here.
<pacarito[m]> pacarito[m]: Here is the article.. Embedded section is small.
balbi[m] has quit [Quit: Idle timeout reached: 172800s]
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
GuineaWheek[m] has quit [Quit: Idle timeout reached: 172800s]
TomB[m] has quit [Quit: Idle timeout reached: 172800s]
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]