<RobinMueller[m]>
re-configurabilityy at this time. UPdating the tables at run-time might become interesting once I use something like DMA soft cores mapped into the DRR memory, or I try to do multi-processing. XIlinx definitely provides a C API / FUnction to update the MMU table at run-time. My current focus will be the bare defaults so I can focus on the generation of A Zynq7000 PAC crate
<RobinMueller[m]>
re-configurabilityy at this time. UPdating the tables at run-time might become interesting once I use something like DMA soft cores mapped into the DRR memory, or I try to do multi-processing. XIlinx definitely provides a C API / FUnction to update the MMU table at run-time. My current focus will be the bare defaults so I can focus on the generation of A Zynq7000 PAC crate
ryan-summers[m] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
bitts[m] has quit [Quit: Idle timeout reached: 172800s]
<TomB[m]>
<RobinMueller[m]> "Tom B: generated table: https..." <- Links 404 for me, but cool to see you got something working! At one point zynq looked like the perfect part for a project I was doing so I was looking at the m-labs stuff as well but price per part has kept me away.
<RobinMueller[m]>
Yeah they are expensive 😅 still cheaper than the rad hard stuff i sometimes work with. I still have not to test it on the real board
<RobinMueller[m]>
s/still cheaper than the rad hard stuff i sometimes work with.//
lulf[m] has joined #rust-embedded
<lulf[m]>
<realroot[m]1> "lulf to sync the time do I..." <- realroot: yes, and you need to enable the 'GATT server' with the 'Time Synchronization Service' in the app settings
mabez[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
adamgreig James Munns - as merging the Arm teams is taking a while, what would I need to do to just get merge access to the Cortex-R repo and publish some crates? I'd really like to get some things published before Embedded World. I'll just join the Cortex-R team if I have to. Jorge said he'd help too.
JamesMunns[m] has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
<thejpster[m]> "adamgreig James Munns - as..." <- You already have merge access and can just force push a new initial commit I believe, or your merge commit
<adamgreig[m]>
For publishing crates it depends who the owner is on crates.io
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has joined #rust-embedded
<diondokter[m]>
Hey all, how much appetite would there be to get an I2C slave trait in the embedded-hal?
<diondokter[m]>
Seems like I'll be able to put some time in making a proposal. Don't know yet what it should look like. I'll have to research that still
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]>
I think there's interest and it's been discussed, but I think it's likely there's a couple different design decisions you could go with. Also a lot of impls need to be pretty opinionated for perf reasons, especially in cases where clock stretching isn't possible or desirable
<JamesMunns[m]>
I think 100% build it outside embedded-hal, get some impls in HALs, and you're likely to get much better constructive feedback (evergreen embedded-hal advice I guess)
<JamesMunns[m]>
There's also probably room for both a "strictly-register-only" interface, as well as a raw "could be any sequence" interface
<JamesMunns[m]>
(the "write reg addr, then read; or; write reg addr, then write" interface isn't TOTALLY universal, but is probably most usage of i2c)
<JamesMunns[m]>
I think you could pretty far with something like a mailbox interface: have a way to do either a "lock then update", or "write then swap" kind of way to update values, and for async have some kind of waker whenever a read occurs or a write occurs
<JamesMunns[m]>
* you could get pretty far
<JamesMunns[m]>
(but that's kinda more application layer? I dunno what you'd have for the actual embedded-hal bit)
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
i'm quite happy with the i2c slave api in embassy-nrf
<dirbaio[m]>
you first "listen" which gives you a struct with info on what the master/initiator/controller wants to do
<dirbaio[m]>
then if it's a read you have to "respond" with the data
<dirbaio[m]>
but even then, it has a few nrf-isms (for ex nrf can only match on 2 addrs. no idea how you'd abstract this in an embedded-hal trait)
<dirbaio[m]>
and only supports write, read, write+read. not arbitrary transactions (not sure if this is a hw or impl limitation though)