<JamesMunns[m]>
so, most people would use either the PAC or the HAL specific to their chip, if you have a specific need
<rattboi[m]>
I am planning to make a rom emulator for something that is like 16 address lines, 8 bit data bus, and I was sorta assuming I'd just do it as a parallel gpio bus
<JamesMunns[m]>
yep, makes sense! Folks I've seen do similar things often use something like the FSMC on STM32, but that's specific to that family of chips
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
For a rom emulator you'd ought to be able to latch values onto the bus quick enough before the other end drives nOE?
<rattboi[m]>
i509vcb[m]: yeah, it *might* work, but I imagine it's way more confusing to look at on a LA
<JamesMunns[m]>
Do you know what chip you plan to use?
<rattboi[m]>
rp2350
<rattboi[m]>
JamesMunns[m]: oh, FSMC is interesting. I hadn't heard of that.
<JamesMunns[m]>
rattboi[m]: I'm not certain you CAN write 24 pins in one cycle on the 2350
<JamesMunns[m]>
(looking at the datasheet now tho)
<JamesMunns[m]>
ah jk I think you totally can
<rattboi[m]>
I'm reading 16 bits, and reacting by setting the 8-bit data bus
<i509vcb[m]>
I do have a wip project in a close enough domain but it's far more boring as the mcu just programs the flash and selects the bank to use
<rattboi[m]>
so it doesn't need to be 24 bits in one cycle
<i509vcb[m]>
i509vcb[m]: However the dual issues of size (50x20mm) and fitting the level shifters in there is fun
<rattboi[m]>
I'm just looking for the best way to sample the inputs and be able to react as quickly as possibly
<JamesMunns[m]>
Yeah, using the PAC and interacting directly with the SIO is likely the best choice here.
<JamesMunns[m]>
s/I think//
AtleoS has quit [Ping timeout: 244 seconds]
cbjamo[m] has joined #rust-embedded
<cbjamo[m]>
<rattboi[m]> "rp2350" <- If you're using the 2350, I'd recommend using the pio.
vancz has quit []
vancz has joined #rust-embedded
emerent has quit [Ping timeout: 272 seconds]
emerent has joined #rust-embedded
starblue1 has quit [Ping timeout: 265 seconds]
starblue1 has joined #rust-embedded
jasperw- has quit [Read error: Connection reset by peer]
jasperw has joined #rust-embedded
<thejpster[m]>
TIL: ASP (Architecture Support Package)
<thejpster[m]>
That’s what cortex-m-rt is.
diondokter[m] has joined #rust-embedded
<diondokter[m]>
Pretty good name!
JomerDev[m] has joined #rust-embedded
<JomerDev[m]>
So ASP.Rust would be a support package for Rust, seeing as ASP.NET is for C#?
AtleoS has joined #rust-embedded
whitequark[cis] has joined #rust-embedded
<whitequark[cis]>
it's upsetting that the order of hierarchy is ASP -> CSP -> BSP
brebeam[m] has joined #rust-embedded
<brebeam[m]>
On an esp32-c3 using usb-serial-jtag, is it possible to use the jtag part for sending defmt messages rather than serial, similarly to how you can use swd for defmt and keep serial ports free for other stuff on e.g. RP2040?
<brebeam[m]>
I'm on embassy if that makes a difference
starblue1 has quit [Ping timeout: 255 seconds]
starblue1 has joined #rust-embedded
xitan has joined #rust-embedded
xitan has quit [Remote host closed the connection]
<vollbrecht[m]>
<brebeam[m]> "On an esp32-c3 using usb-serial..." <- defmt is transport agnostic in that sense. You can use rtt over probe-rs and send your defmt frames in a specific rtt channel.
<vollbrecht[m]>
though all in all probe-rs will still want to have full access to the usb-device. I am not sure if you can share the connection while probe-rs is connected.
<vollbrecht[m]>
but if you are not connected you can use other stuff over your usb-cdc with a normal terminal
<AdinAck[m]>
i have noticed that something is wrong with the flash algorithm for the esp32s3 when BLE is used. I cannot change anything about the services or characteristics. i can add println!s and they appear, and if i remove the gatt code it is no longer visible in nrf connect, but the moment i add the gatt back, no matter how i have it configured, it shows the first service and characteristic that was flashed to it. wtf is going on???
<AdinAck[m]>
if i get out a brand new board and flash my firmware it will have the latest changes, but then i cannot change the BLE GATT configuration at all
<JamesMunns[m]>
Maybe worth asking in #esp-rs:matrix.org ?
<AdinAck[m]>
omg yes i was looking for that room, thank you james!
<JomerDev[m]>
So I'm currently looking for a way to keep a global config struct around, to be changed via menu on an lcd, and the values to be used in some tasks. While the editing and reading are done in different (embassy) tasks, since I'm only using one core/executor afaik I should be fine with using a static RefCell with the config inside, as long as I don't await while editing or reading? But I'm very unsure about that and would love to
<JomerDev[m]>
hear about better ideas or issues with my current solution
<JamesMunns[m]>
We'll get started at :05 past the hour.
<JamesMunns[m]>
Also if you have anything to share or announce, feel free to shout it out now!
AtleoS has quit [Read error: Connection reset by peer]
<JomerDev[m]>
<dirbaio[m]> "if it's plain data then RefCell..." <- Yes, some numeric values, nothing bad. I assume unplain data would be stuff like weird references, function pointers and such?
Henk[m] has joined #rust-embedded
<Henk[m]>
📣 Announcement: next book sprint for the Discovery MB2 book will be on October 26, 17:00-21:00 CEST, 15:00-19:00 UTC, 8:00AM-12:00PM PST. Join if you're interested in helping to write the new discovery book!
AtleoS has joined #rust-embedded
<JamesMunns[m]>
Henk[m]: Anywhere we can register as interested?
<Henk[m]>
JamesMunns[m]: Good call. I'll add a comment in the discussion that you can like to your hearts content
<JamesMunns[m]>
Okay, quick call:
<JamesMunns[m]>
Do we have any HAL team members present? This is for 1️⃣ and 3️⃣ from above
<jannic[m]>
Probably doesn't make sense to spend time on this - we already discussed these last week a bit, and without additional input we won't get further today.
<JamesMunns[m]>
yep, just wanted to call it out, but I don't think we have anyone clamoring to speak on either :)
<JamesMunns[m]>
(can we make a cortex-m-rt release?)
<JamesMunns[m]>
I'm guessing the answer is probably "the fact Adam is busy at the moment", but if there are any other cortex-m members here who would like to chime in, please feel free!
<dirbaio[m]>
re UnsafeCell in Mutex: it's probably true that it's not needed, but i'd prefer to not touch it just in case (it's not hurting, except missed optimizations when not using interior mutability which imo is rare)
<JamesMunns[m]>
Yeah, the only thing I can think of is some kind of spooky "requires critical section for safety" thing
<dirbaio[m]>
re mmio references: the only actionable thing I can see is migrate svd2rust off vcell? but this is not HAL team thing, it's the tools team
<JamesMunns[m]>
JamesMunns[m]: But I think this was maybe covered by "then you should put an unsafecell in your type that goes in the mutex"
<JamesMunns[m]>
dirbaio[m]: oh, that's a good call. I should have pinged the tools team.
<bartmassey[m]>
Given that Mutex is de facto mutable, I wonder if we could provide some API to use it like a "normal" Mutex and get a mutable guard or something?
<bartmassey[m]>
(interior mutable ofc)
<JamesMunns[m]>
yeah, the opinion at the time was to "split" the behavior into two parts:
<JamesMunns[m]>
* runs in a critical section
<JamesMunns[m]>
* get mutable access
<jannic[m]>
dirbaio[m]: Ralf Jung mentioned in the ticket that it _may_ be an option to change rustc. (Well actually I don't think a change would be needed, just declaring the current behavior as official). But do we want that? Is it worth the effort?
<JamesMunns[m]>
I'm not sure I still (personally) believe that paid off, and I have used more clear types of my own, or from crates like embassy-sync
<dirbaio[m]>
if we're going to make changes to Mutex, i'd make a new crate and mark critical_section::Mutex as deprecated
<JamesMunns[m]>
The biggest issue is that the cs::Mutex is a reentrant mutex
<dirbaio[m]>
so we can freely do critical_section_mutex v1, v2, v3... without fracturing the ecosystem
<JamesMunns[m]>
it is clearly labeled as a blocking, scoped mutex, that can be fulfilled by a critical section
<dirbaio[m]>
jannic[m]: IMO it's not worth increasing the complexity of the language if you can do MMIO 100% soundly today with raw pointers and `read_volatile/write_volatile`
<JamesMunns[m]>
(but also could be fulfilled by a std mutex)
<dirbaio[m]>
also the current design of svd2rust has other footguns
<dirbaio[m]>
people just do it because of the inertia of "this is how it's always been done in C"
<dirbaio[m]>
> Do we make chiptool a part of the wg?
<dirbaio[m]>
I don't have the bandwidth to maintain chiptool beyond embassy's use cases, and i'd rather not have to spend time updating embassy to chase the changes the wg would do to chiptool. if people want chiptool-in-wg i'd prefer if the wg forked it.
<dirbaio[m]>
but it feels to me it'd be less disruptive to update svd2rust
<dirbaio[m]>
it can probably be done with no syntax changes, after the last update that changed all regs to require parentheses peri.somereg()
<dirbaio[m]>
that's up to the chiptool maintainers to decide tho :D
<dirbaio[m]>
s/chiptool/svd2rust/
<jannic[m]>
`peri.somereg()` returns a `&Reg<SOMEREG_SPEC>` - it should to do `let reg = peri.somereg();` as it is a reference to the same register?
<dirbaio[m]>
right. this is with nrf pacs which haven't been rebuilt with the svd2rust that requires parentheses
<dirbaio[m]>
nice to see it's fixed
<dirbaio[m]>
(hopefully Reg is not copy so you can't do let reg = *peri.somereg();?)
<rmsyn[m]>
dirbaio[m]: correct, that's not possible
<dirbaio[m]>
nice
<rmsyn[m]>
but you can move peripherals out of the Peripherals struct
<jannic[m]>
rmsyn[m]: Did you try?
<rmsyn[m]>
jannic[m]: yes, you have to move the types (e.g. as an arg to a function), then return the instance if you want to use it somewhere else
<rmsyn[m]>
at least with the 0.33.2 version, and I don't think it's changed in 0.33.4
<rmsyn[m]>
maybe we're talking about different things, though
<rmsyn[m]>
last I checked let periph = *pac::SomePeripheral::ptr() throws a compiler error
<jannic[m]>
I tried with a pac generated with 0.31.5 and it seems to copy the register.
<JamesMunns[m]>
I think dirbaio was talking about specifically a Reg field of a peripheral
<JamesMunns[m]>
so like rcc.cr, not Rcc
<jannic[m]>
`let reg: Reg<FIFO_SPEC> = *pac.ADC.fifo().clone();` (`.clone()` only added to make it explicit - does the same without)
<jannic[m]>
Anyway - it only supports dirbaios observation that "current design of svd2rust has other footguns".
<rmsyn[m]>
I think a lot changed in the 0.32 release
<Henk[m]>
I gotta run. bb! 👋
<jannic[m]>
rmsyn[m]: Yes, I can try later if that changed.
<rmsyn[m]>
looking at the Reg definition in src/generic.rs of a 0.32 generated PAC doesn't look like it implements Copy
<JamesMunns[m]>
k, I will link today's discussion on the tracking issue, and suggest that "move svd2rust to pointers and not struct refs, use read/write_volatile" was the general sentiment? And maybe we try to capture some other issues on the svd2rust repo if we can enumerate footguns like these?
<JamesMunns[m]>
There's a request for feedback on releasing stable versions, when there are non-1.0 deps
<rmsyn[m]>
JamesMunns[m]: I think this also has to come with associated helpers, unless the pointer is completely an internal implementation detail
<JamesMunns[m]>
yes, sorry, not "everything is pointers", I oversimplified a bit :)
<rmsyn[m]>
currently working with raw pointers in Rust is pretty different than the reference interfaces (I know you know, just saying)
<JamesMunns[m]>
but you would lose `&rcc.sr()` (and get a reference to SR you could pass to DMA), and instead have to do something like `rcc.sr().as_ptr()`
<Ralph[m]>
JamesMunns[m]: do you want me to add anything beyond what i already wrote there? (not sure what i should add - basically i'm looking either for "hey, we're ready to release v1.0 of most/all foundational crates", "here's how we're doing it" or "that proposal sounds reasonable, let's go with it to move things towards v1.0")
<Ralph[m]>
i realise that the crate where i have a need for that decision right now is completely irrelevant, but i think the discussion applies generally as it affects a lot of crates
<JamesMunns[m]>
Yeah, I think it's worth discussing. I also got bit by heapless making breaking changes (even though it was right to do that!)
<JamesMunns[m]>
tho for the record, defmt is outside of the WG's control
<JamesMunns[m]>
I don't personally think there is a right answer.
<JamesMunns[m]>
Often as long as the deps don't show up in the public interface, updating them shouldn't be a breaking change
<jannic[m]>
That's a good point: The API guidelines are talking about public dependencies.
<JamesMunns[m]>
I think there have been some rumblings for getting crates like heapless and defmt to 1.0, but still: sometimes you want to take a heapless::Vec in public APIs.
<dirbaio[m]>
imo heapless in public apis is bad
<dirbaio[m]>
you can usually take a `&[T]` instead of taking a vec
<dirbaio[m]>
and take a `&mut [T]` and return a usize, instead of returning a vec
<JamesMunns[m]>
I usually need it when I want to return "up to N" items
<dirbaio[m]>
returning a vec is especially prone to blow up your stack
<JamesMunns[m]>
(you could still pass in `&mut heapless::Vec<T; N>`, but I know most people don't)
<dirbaio[m]>
plus it bloats code size due to monomorphization of the const generic, while slices don't
<dirbaio[m]>
plus it makes heapless a public dependency :)
<Ralph[m]>
dirbaio[m]: i need to return data, not receive it. i have an `alloc` feature (=> `alloc::Vec`) and a `heapless` feature (which are mutually exclusive, which is also kind-of against the rust guidelines of only having additive features), though for the latter you must specify the size of the vector you expect
<dirbaio[m]>
you can take a &mut [T] and return a usize, instead of returning a vec
<dirbaio[m]>
* you can take a `&mut [T]` and return a usize, instead of returning a vec
<JamesMunns[m]>
dirbaio[m]: but I might need MaybeUninit if T is not trival
<dirbaio[m]>
ie make the caller pass you the memory where they want the results
<JamesMunns[m]>
and at that point we're just asking everyone to re-roll heapless::Vec
<JamesMunns[m]>
which, is an option, for sure!
<JamesMunns[m]>
but I think the general question isn't about heapless specifically
<JamesMunns[m]>
but rather "hey there's still a lot of non-1.0 deps in the ecosystem"
<JamesMunns[m]>
Beyond that, it's sort of a personal value judgement, IMO :p
<dirbaio[m]>
imo 0.x vs 1.0 means nothing, just do whatever you feel like :D
<jannic[m]>
IMHO we shouldn't care too much about these numbers. Which is true in both directions: Crates should be more willing to publish a 1.0 if they converged to some reasonably stable API. And treating a crate as de-facto stable even if it's version number is still 0.x is also fine.
<rmsyn[m]>
dirbaio[m]: because those macros are also being made public, so the `paste` dep needs to be public
<dirbaio[m]>
ah but that's "fake public"
<rmsyn[m]>
we ran into a similar issue with other helper macros in a previous PR
<dirbaio[m]>
imo in these cases it's acceptable to stick it in a #[doc(hidden)] pub mod _export {...} and consider it private
<rmsyn[m]>
dirbaio[m]: right, if by that you mean a public re-export
<dirbaio[m]>
I mean you have to make it public due to technicalities of how macros work
<dirbaio[m]>
but it's still considered private, the user shouldn't go and use paste through your reexport
<JamesMunns[m]>
I think even cargo-semver-checks considered doc(hidden) not-public
<dirbaio[m]>
so it's common practice to reexport these things through a hidden module
<JamesMunns[m]>
s/considered/consideres/
<JamesMunns[m]>
s/considered/considers/
<dirbaio[m]>
if you consider these things private then you can update paste 0.43 -> 0.44 (major) in yourcrate 0.1.0->0.1.1 (minor), because you update the reexport and the macros at the same time so it's all guaranteed to keep working
<rmsyn[m]>
right, that makes sense. didn't mean to derail things. we have two PRs open in riscv, I can add them as discussion topics for next meeting
<Ralph[m]>
JamesMunns[m]: i was hoping that in this case (if you're saying that it should be stable for the foreseeable future) it should be as easy as `pub use heapless_1::*;` in heapless 0.8.x? (ok, maybe _slightly_ oversimplified)
<dirbaio[m]>
🦀
<Ralph[m]>
just as a small wrap-up: would you generally consider it ok to add a statement to the README labelling optional 0.x dependencies (all 0.x dependencies are optional) as being out-of-scope of regular semver guarantees and that any breaking change there can happen in a major release here until they reach 1.0 and just release v1.0 of my crate?
<Ralph[m]>
i.e.: are you happy to use such a crate? presuming you don't use the optional features you wouldn't notice it, but what if you do use the optional features (in my specific case there are three relevant ones: `heapless` (alternative: use `alloc`), `defmt` (if you want the `Debug` derives) and `rgb` (for some data conversion as it's the de-facto standard for RGB data))
<JamesMunns[m]>
I'd be a little upset if one of my crates broke without a major change.
<JamesMunns[m]>
s/crates/deps/
<JamesMunns[m]>
(fwiw for postcard, I plan to add specific heapless-0_8 features)
<Ralph[m]>
ok, so v1.0 of my crate and heapless-08, defmt-03, etc. as features with the added work of adding more of these if the dependencies have breaking changes or just a major release of my crate also in those cases (which might be ok for my crate as i doubt there are many using it, but might be "less nice" for more central crates affected by the same dilemma)
pjaros[m] has quit [Quit: Idle timeout reached: 172800s]
aliceryhl[m] has joined #rust-embedded
<aliceryhl[m]>
I saw you had your meeting. Did I get mentioned? It seems to say I did, but I can't find it anywhere.
Jubilee[m] has joined #rust-embedded
<Jubilee[m]>
aliceryhl[m]: You might have gotten mentioned by the initial room ping?
<aliceryhl[m]>
ah, maybe
cr1901_ has joined #rust-embedded
<JomerDev[m]>
<JomerDev[m]> "So I'm currently looking for a..." <- Coming back to that question, it looks like a RefCell might not be enough? `RefCell<ConfigData> cannot be shared between threads safely. the trait core::marker::Sync is not implemented for RefCell<ConfigData>`
cr1901 has quit [Ping timeout: 245 seconds]
<dirbaio[m]>
Then you need to wrap it in a Mutex
<dirbaio[m]>
If you only share it between tasks at the same prio and don't want Mutex, wrap it in a StaticCell, init it in main and pass `&'static RefCell` to the tasks
sirhcel[m] has quit [Quit: Idle timeout reached: 172800s]
<JomerDev[m]>
Ah fair enough, I'll do that then
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
rtc in nrf52 has a few fun gotchas where you have to do things in a certain order or wait for a certain time
<dirbaio[m]>
maybe you have to set the prescaler before enabling, or you can't set it too fast after enabling
<dirbaio[m]>
i'd suggest checking the Product Specification and the erratas
<dirbaio[m]>
i
<dirbaio[m]>
* i'd avoid coding against the rtc directly, you're going to have endless fun this way
<dirbaio[m]>
* i'd avoid coding against the rtc directly, you're going to have endless fun if you do
dngrs[m] has joined #rust-embedded
<dngrs[m]>
is there a no_std topological sort?
Lumpio- has joined #rust-embedded
<kentborg[m]>
<dirbaio[m]> "maybe you have to set the..." <- Yes! It was a speed thing. Having previously done embedded programming in C, it smelled like a missing `volatile` or such like. I'll have to get used to trusting Rust. Timing, it never occurred to me.
<kentborg[m]>
As for not programming the RTC myself…indeed it isn't clear that it would get me anything beyond just using `embassy_time`, but I have learned a lot doing this.