<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.
<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]>
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?
<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.
<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?
<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 ?
<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]>
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.