<re_irc>
<burrbull> dirbaio, eldruin Do I understand right that when Spi in Bidi mode only "SpiBusRead" & "SpiBusWrite" should be implemented and "SpiBus" skipped as it Full-duplex specific?
<re_irc>
<eldruin> That is an interesting use-case. Yes, that seems correct, since the contract is that the transfers in "SpiBus" happen simultaneously. This may be problematic, though, since the "transfer" methods in the "SpiDevice" requires a full-duplex "SpiBus".
<re_irc>
<eldruin> * require
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc>
<burrbull> Ok. Then 1 question yet. Current stm32 SPI implementations enable SPE at the end of initialization. This corresponds to 3.3 "Configuring the SPI in master mode":
<re_irc>
<James Munns> I would say the final friday showcase was a success :D
brazuca has quit [Quit: Client closed]
<re_irc>
<James Munns> Got eight submissions, on one week's notice, took me probably 30-45 minutes to edit and schedule all the tweets
<re_irc>
<James Munns> So I guess I'll keep doing it as long as there is response and positive feedback :)
dc740 has joined #rust-embedded
loki_val has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #rust-embedded
<re_irc>
<thejpster> Can we get these updates in the newsletter as well?
dc_740 has joined #rust-embedded
WSalmon_ has joined #rust-embedded
Darius_ has joined #rust-embedded
Darius has quit [Ping timeout: 252 seconds]
dc740 has quit [Ping timeout: 252 seconds]
WSalmon has quit [Ping timeout: 252 seconds]
Darius_ is now known as Darius
<cr1901>
Is korken89 around on the Matrix side of the bridge? I have a question about spsc::heapless
<cr1901>
(Basically "why does the API take &mut self when internally things are implemented with interior mutability"?)
<cr1901>
(Is it a lint or is there actual UB if &mut isn't there)
dc_740 has quit [Ping timeout: 268 seconds]
<re_irc>
<James Munns> Typically, you use mut to enforce a single user
<re_irc>
<James Munns> Multiple users isn't unsafe, but it's not a "broadcast", channel, so user A might get message 1, and user B might get message 2
<re_irc>
<korken89> cr1901: Without that multiple processes could have concurrent access to the queue, and it's only single consumer, single producer :)
<re_irc>
<korken89> cr1901: There would be data races, so probably UB
user1209 has joined #rust-embedded
user1209 has quit [Quit: WeeChat 3.0]
brazuca has joined #rust-embedded
<cr1901>
korken89: So the reason I ask is I want to spin off my own queue into a crate, not because I think heapless::spsc/your code is bad, but because I have different requirements. And I wanted to get feedback from you to compare/contrast :P
<re_irc>
<korken89> Sounds good
<re_irc>
<korken89> The SPSC is quite limited if you need MPSC, SPMC, etc
<cr1901>
SPSC is fine, but I wanted completely safe code without the need for a Mutex. I managed to get rid of &mut completely w/ interior mutability and limiting the API surface and types that the queue can store
<cr1901>
korken89: Also, see https://github.com/japaric/heapless/issues/314 if I'm wrong, I'd love to know now :P. Even simple SPSC code is finicky, and I've made usability sacrifices to get rid of &mut :(.
<cr1901>
Studying your code has helped, but I think I might be getting myself confused about thing
<re_irc>
<korken89> cr1901: An SPSC with immutable interface is no longer an SPSC :)
<re_irc>
<korken89> It's either MPSC, SPMC, or MPMC
<cr1901>
hmmm, well, it's "MPMC, but it's only guaranteed to work properly for one Producer one Consumer" :D. It's not memory-unsafe to use it as MPMC, it just won't work properly :D.
<re_irc>
<korken89> Data race UB looking your way ;)
brazuca has quit [Quit: Client closed]
<re_irc>
<GrantM11235> eldruin: This isn't a problem, you just won't be able to use the "transfer" methods. The transfer methods wouldn't be useful anyway on a half-duplex bus because you would just be reading in the same data that you are clocking out
loki_val is now known as crabbedhaloablut
bjc has quit [Remote host closed the connection]
<re_irc>
<dirbaio> is there a fancy trick to collect an iterator into a (const-generic-sized) array without alloc?
<re_irc>
<dirbaio> all I can find online is "collect to vec, then try_into"! :(
<re_irc>
<dirbaio> hmm converting from vec to array won't be in-place though?
<re_irc>
<GrantM11235> The optimizer might help you out, but otherwise no
<re_irc>
<dirbaio> maybeuninit array it is then :'(
<re_irc>
<GrantM11235> I wonder if it would be useful to replace the "[MaybeUninit<T>; N]" in heapless::vec with an "impl AsMut<[MaybeUninit<T>; N]>"
<re_irc>
<dirbaio> the field? that'd require adding another generic param
<re_irc>
<GrantM11235> Yeah, the extra complexity would probably be too annoying for normal users, unless type defaults could smooth things out
<re_irc>
<chemicstry> I was actually surprised that you can map array into a different array if that's what you need. If it's a dynamic iterator then I think MaybeUninit and unsafe is the only way
<re_irc>
<GrantM11235> Do you actually need a "[T; N]", or would a "&mut [T; N]" be good enough
<re_irc>
<dirbaio> what I needed is _almost_ array map
<re_irc>
<dirbaio> array map does "[T;N] -> [U;N]", I need "&mut [T;N] -> [U;N]" :S
<re_irc>
<GrantM11235> I've heard that mapping arrays is a good way to blow up your stack
<re_irc>
<dirbaio> yeah... but so is maybeuninit transmutes
<re_irc>
<ian_rees> is there a crate that does GPIO on Linux, and works with either /dev or /sys ? I'm trying to consolidate/refactor some code that needs to run on an old 3.something kernel and a relatively current one, would be nice to not depend on the deprecated /sys interface
<re_irc>
<dirbaio> there's sysfs-gpio (old) and gpio-cdev (new
<re_irc>
<dirbaio> * (new)
<re_irc>
<dirbaio> linux-embedded-hal can use either through a feature flags but it seems it still exports a different API (?)
<re_irc>
<dirbaio> I don't think there's a crate that does both with the same API
<re_irc>
<ian_rees> yeah that's the impression I got as well - just asking in case I hadn't hit on the right search terms
<re_irc>
<dirbaio> you can use generics with the "embedded-hal" traits to allow your code to work with either
<re_irc>
<dirbaio> probably a bit boilerplatey
<re_irc>
<dirbaio> then some cfg's in "main" to use the right one
<re_irc>
<ian_rees> yeah, maybe if I stall long enough we'll get the old system running a newer kernel and can just use /dev :)
<re_irc>
<ian_rees> it's just for an interrupt and a reset line, not worth sinking much effort in to for this specific use
<re_irc>
<dirbaio> ahh the "wait until the problem solves itself" solution... :D
<re_irc>
<ian_rees> "Procrastination pays" is one of my mottos. Sometimes in conflict with "Nothing exceeds like excess"
<cr1901>
dirbaio: You see my previous question re: atomic-polyfill?
<cr1901>
portable-atomic uses inline asm on msp430 as a workaround for now to impl atomic loads without critical sections. When I fix LLVM, the LLVM backend will do something equivalent for msp430
<re_irc>
<dirbaio> hm
<re_irc>
<dirbaio> so the thing is
<re_irc>
<dirbaio> on msp430, CAS atomics are done through disabling irqs right?
<cr1901>
yes
<cr1901>
msp430 is inherently a single core arch. There are no multicore msp430s and TI would have to go thru hoops to make one
<re_irc>
<dirbaio> and currently atomic-polyfill still disables irqs for load/store, but that's only required for multicore
<cr1901>
Yes
<re_irc>
<dirbaio> so we could _not_ disable irqs for load/store on msp430, avr
<re_irc>
<dirbaio> I see, that's a nice optimization
<cr1901>
yes
<cr1901>
This is what portable-atomic is doing, after I pointed it out to taiki-e, who in turn pointed out the initial unsoundness of atomic polyfill
<cr1901>
The only reason I haven't added support to atomic-polyfill yet is because the lowering doesn't work on LLVM side, and I'm not sure how you feel about hacking around it w/ inline asm
<re_irc>
<thalesfragoso> dirbaio: Why would you need to disable irqs for simple load/store and how that helps in multi core ?
<cr1901>
(And well, the critical-section migration hasn't gone smoothly and that's been taking my bandwidth too)
<re_irc>
<dirbaio> so if you want to impl CAS (fetch_add etc) with CS's you also need load/store to take a CS
<re_irc>
<dirbaio> cr1901: re hacking with inline-asm: is the llvm fix coming anytime soon?
<cr1901>
I would like it to come soon, but I actually have to learn how to get around LLVM. That'll take a while
<re_irc>
<dirbaio> oh well
<re_irc>
<dirbaio> in generalI'm not a fan of maintaining so much arch-specific code... with the old c-s it was a pain
<re_irc>
<dirbaio> * general I'm
<cr1901>
What about having a target-specific dep on portable-atomic for msp430 just to bring in the inline asm?
<cr1901>
ahhh
<re_irc>
<thalesfragoso> dirbaio: How would a write sneak in inside a CS ? If we're talking multi core then you would still need a mutex and not a CS
<re_irc>
<dirbaio> i'd like it to have _less_ arch-specific stuff actually... like switching to "cfg(target_has_atomic)"
<re_irc>
<dirbaio> thalesfragoso: CS guarantees "no other CS can run concurrently", not "no other code can run concurrently". Code in the _other_ core that's not in a CS can still run
<re_irc>
<dirbaio> so it breaks if you do CS for CAS only
<re_irc>
<dirbaio> you have to do CS for both CAS and load/store.
<re_irc>
<thalesfragoso> dirbaio: Can't you just have a separate single core implementation?
<re_irc>
<dirbaio> that's kinda what the portable-atomic "unsafe-assume-single-core" cargo feature is I think?
<cr1901>
Yes
<cr1901>
Which is unconditionally enabled for msp430/avr
<re_irc>
<dirbaio> in atomic-polyfill case it's a bit more complicated because the actual CS impl is abstracted, via the "critical-section" crate
<cr1901>
so you don't need to include a scary cfg option
<re_irc>
<dirbaio> so the feature would have to be something like "unsafe-assume-the-active-critical-section-impl-means-no-other-code-can-run" :D
<re_irc>
<thalesfragoso> Can't you have the same on polyfill by just bringing a single core critical-section impl ?
<cr1901>
dirbaio: FWIW, I am assuming that portable-atomic types can live safely/soundly with critical-section crate in my msp430 code :)
<cr1901>
I will accept the consequences for this
<re_irc>
<dirbaio> cr1901: if the c-s impl you use is "disable all irqs" it should be fine
<cr1901>
yes
<re_irc>
<thalesfragoso> Oh, actually no, right ? Because polyfill it's the one calling the CS code and it needs to work to everyone
<re_irc>
<dirbaio> it might not be if you have fancy stuff going on like an RTOS
<re_irc>
<thalesfragoso> So it would also need a cargo feature
<cr1901>
There is probably no other reasonable c-s impl for msp430 (except maybe a lightweight thread-based one)
<re_irc>
<dirbaio> thalesfragoso: atomic-polyfill has no idea which CS impl is in use, so it has to assume the worst, the only guarantee from c-s is "no other CS can run concurrently"
<re_irc>
<dirbaio> to be sound according to that gaurantee, you MUST take a CS for load/store too
<re_irc>
<thalesfragoso> Damn, element Android app is worse than ever, getting delayed messages
<cr1901>
dirbaio: For semver compatibility until I release a major version bump, do you think it's acceptable to make msp430/critical-section-single-core a default-enabled feature?
<cr1901>
Actually... nevermind... I'm going to just make this a breaking change. Shame/painful, but it'll be good in the long run.