<sparky[m]>
looks right now, including the address its being read from. i stupidly did not add 1 to the register each loop, but the entire register value
<sparky[m]>
now i get varying outputs for temp, but they are all around -130 lol
<sparky[m]>
* register value so "reg2" was some totally out of bounds and non-existent register
<sparky[m]>
* register value so "reg2" was some totally out of bounds and non-existent register before
<sparky[m]>
probably should do le_bytes here too with a 0 byte for the first huh?
<sparky[m]>
Ok(u32::from_le_bytes([0,msb,lsb,xlsb])) seems to have made things worse?
<GrantM11235[m]>
it should be be if you start with msb
<sparky[m]>
weird cause Ok(u32::from_le_bytes([msb,lsb,xlsb,0])) seems to produce accurate temperatures now?
<GrantM11235[m]>
Your previous code was equivalent to from_be_bytes([0, msb, lsb, xlsb])
<sparky[m]>
yeah. i put it back to that cause its the only thing that makes sense to me with the reading of the datasheet. but readings make no sense at all still 😢
<GrantM11235[m]>
did you try from_be_bytes([msb, lsb, xlsb, 0])?
<sparky[m]>
oddly, that seemed to make no change at all unlike with the le variant that caused a dramatic change and made temp (but not pressure) appear accurate
<sparky[m]>
honestly, i think theres something deeper and dumber broken... a temp sensor should trivially change its value with a finger on it, even if its got bad math for displaying the output. yet its somehow static and unchanging
<sparky[m]>
i probably just need sleep lol
<GrantM11235[m]>
can you print the raw msb, lsb, and xlsb?
<GrantM11235[m]>
those should definitely change
<GrantM11235[m]>
Your register addresses are wrong
<GrantM11235[m]>
temp msb should be 0x09, no 0x07
<sparky[m]>
ay yai yai... i cannot do things in order can i?
<GrantM11235[m]>
s/no/not/
<GrantM11235[m]>
once again, the data sheet lists them backwards 🙃
<sparky[m]>
well, now temp looks ok but it doesnt change at all even with me touching it and pressure is clearly wrong as im not in a situation where im under 4.770057e13 pascals of pressure...
<sparky[m]>
while temp never changes, the XLSB does for pressure and so its value fluctuates a bit
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
<sparky[m]>
no idea... guess ill do more register and data validation tomorrow. at the very least, i found a bunch of problems tonight so thanks a bunch!
<firefrommoonligh>
Hey, short in the dark and possibly off-topic, but there may be some overlap with embedded: Has anyone got Rust with Cuda FFI working? I am having a struggle with the linking!
<firefrommoonligh>
Does anyone know the specific clang++ or nvcc compile command to make a shared library? I can get non-Cuda C++ to do FFI with the -c command, but this is apparently a hack; the -shared command isn't able to link, and the -c command with nvcc fails due to linking other libs
<firefrommoonligh>
For some context, link errors give me anxiety, and I usually can't get past them
cyrozap_ has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
<johngigantic[m]>
Released my crate today! It's a crate for a few Allegro Microsystems motor controllers. If other folks have released IC driver crates and have suggestions or other good crates to get inspiration from, I'd love to hear it :)
crabbedhaloablut has joined #rust-embedded
pmnxis[m] has quit [Quit: Idle timeout reached: 172800s]
jake_001[m] has joined #rust-embedded
<jake_001[m]>
Has anyone worked with the wch risc-v based controllers?
<jake_001[m]>
I've done some searching but haven't come across a whole lot about it besides issues with link.x and memory.x from repos I've seen.
<jake_001[m]>
I'm considering trying to get rust working on them and was curious if there was any potential issues I should look out for.
Guest7221 has joined #rust-embedded
Guest7221 has left #rust-embedded [Error from remote client]
starblue has quit [Ping timeout: 255 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
starblue has joined #rust-embedded
Guest7221 has joined #rust-embedded
Guest7221 has left #rust-embedded [Error from remote client]
<JamesMunns[m]>
Have any interest from (potential) customers on doing async rust training? My last couple of clients have all used Embassy, tho they've been smaller teams (1-2 devs plus me helping).
<JamesMunns[m]>
Wondering what the state of things are looking for larger customers that have 6+ devs that need training on embedded Rust.
<JamesMunns[m]>
( dirbaio might be worth verifying the embassy-net h7 has this fix too, if it isn't the same underlying code as the 7xx-hal)
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
ST's HALs have had a few really terrible ethernet bugs like this. The previous peripheral had the thing where it would hard lock your chip after 2^31 packets if you didn't set the bit to stop that, lol
<mameluc[m]>
<JamesMunns[m]> "https://www.mattkeeter.com/blog/..."; <- Scary! The article was a nice read with just enough information to make it easy to follow for somebody not that familiar with the topic
<dirbaio[m]>
holy shit
<dirbaio[m]>
it's incredibly bad hardware design if it's so easy to turn that into a remote arbitrary memory write!
<adamgreig[m]>
@room, meeting time again! hope you've all set your clocks appropriately :P agenda is https://hackmd.io/ccfnlAwYTw6uspxd5BpXMA, please add anything you want to announce or discuss and we'll start in a few mins
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Finally someone who can track DST correctly. 😛
<thejpster[m]>
dirbaio: I get your numbers on my Debian machine. The numbers before were from my Apple Silicon macBook.
<JamesMunns[m]>
therealprof[m]: "8pm Berlin Time"
<dirbaio[m]>
thejpster[m]: huh. how can that affect the result so much?
<adamgreig[m]>
even though I know berlin and london time still enters dst together I had to double check :P
<adamgreig[m]>
for now anyway....
<thejpster[m]>
dirbaio[m]: I have literally no idea. I'm starting to think I dreamed the whole episode.
<dirbaio[m]>
thejpster[m]: (Arch Linux here, though I guess it doesn't matter if it's from rustup)
neceve has joined #rust-embedded
<thejpster[m]>
dirbaio[m]: Does anyone check that two different hosts actually make the same binaries?
<dirbaio[m]>
thejpster[m]: your repo checkout was clean? no .cargo/config.toml changes, no Cargo.lock changes?
<dirbaio[m]>
dirbaio[m]: no `.cargo/config.toml` in parent folders that could affect? :P
<therealprof[m]>
JamesMunns[m]: Sure, that doesn't mean people know what time it is in Berlin now...
<dirbaio[m]>
dirbaio[m]: or system-wide `CARGO_*` envvars?
<therealprof[m]>
(and that it changed last Sunday at 3:00 AM)
kevlan[m] has joined #rust-embedded
<kevlan[m]>
Was just wondering what time the meeting was defined at. Can that be added to the channel topic?
<adamgreig[m]>
good idea
<adamgreig[m]>
ah, a race condition
<kevlan[m]>
Perfect!
<adamgreig[m]>
if only, rust
<thejpster[m]>
dirbaio[m]: I don't think so?
<adamgreig[m]>
anyway, let's start
<adamgreig[m]>
no announcements from me this week, did anyone else have any?
<dirbaio[m]>
thejpster[m]: I don't have any mac to check :(
<dirbaio[m]>
thejpster[m]: hopefully someone in here does
<therealprof[m]>
adamgreig[m]: Whoops.
<adamgreig[m]>
we've had the anti-spam bot Ruma Moderation for a month or so now without any apparent issues, so I'll stop asking in the weekly meetings and just keep an eye out for trouble
<adamgreig[m]>
still no word back on the rust target maintainers PR, I've pinged that
<firefrommoonligh>
Keep up the good work everyone!
<adamgreig[m]>
I was away for most of last week so still haven't had a chance to test out the proposed swap of cortex-m's InterruptNumber trait to a separate crate, though I still expect it to be fine, so I think the plan for that remains "check and then release c-m-in, release cortex-m 0.7.8 that uses it, update svd2rust to depend on the new crate directly, then in the future we'll be able to do cortex-m 0.8 without breaking everything"
<firefrommoonligh>
I've been doing a lot of Python coding at work (yes, programming job now), and it's full of traps! Eg it's a mystery surprise if functions will pass by value/ref mutate or not etc.
<adamgreig[m]>
but when we do that svd2rust update, we'll also want an answer for cortex-m-rt, which is the other thing to plan and will be a more obvious user-facing change
<adamgreig[m]>
(and also chiptool, raltool, stm32ral, the other PAC generators etc)
<firefrommoonligh>
Adam, do you think RAL is suitable for building HALs around? I love the syntax, and can't remember why I chose PAC instead
<thejpster[m]>
thejpster[m]: I copied the mac binary to my Linux machine and it got bigger!
<firefrommoonligh>
Maybe it's just bc that's what everyone else was doing?
<dirbaio[m]>
thejpster[m]: wut
<firefrommoonligh>
Except dirbaio lol
<adamgreig[m]>
I think the best proposal so for for c-m-rt is to replace use pac::interrupt; #[interrupt] fn USART1() with use cortex_m_rt::interrupt; #[interrupt(pac::Interrupt)] fn USART1()
<dirbaio[m]>
LGTM to that so much
<thejpster[m]>
dirbaio[m]: no, wait, not that. The binary got bigger on the mac.
<adamgreig[m]>
the downside is the macro invocation requires that extra argument compared to currently, so while it's not much more typing for users, it is a noticable (and less convenient) breaking change
<firefrommoonligh>
Hey so I always thought naming the fn with the interrupt line was kind of jank, although harmless. How about making it so we can use ARM interrupts the same as normal?
<adamgreig[m]>
the only upside to users is their PAC no longer depends on c-m-rt, so it's easier for them to use a newer version or alternative runtime crate
<firefrommoonligh>
Like, RN it's easy to use STM32 peripheral interrupts or w/e, but I can't figure out how to use ARM ones like SYSTICK
<dirbaio[m]>
if we're willing to "mandate" the Interrupt name, it could also be #[interrupt(pac)]
<thejpster[m]>
seems worth it
<dirbaio[m]>
I don't think it's worth it though
<thejpster[m]>
firefrommoonlight: If they belong to Cortex-M they are called Exceptions, not Interurpts
<dirbaio[m]>
I guess the core of the question is "what's the contract between PACs and cortex-m/cortex-m-rt"
<adamgreig[m]>
firefrommoonlight: I'm not sure I follow, but exceptions (rather than interrupts) are `#[exception] fn SysTick()`
<adamgreig[m]>
dirbaio: yea, I think ideally this would be written out because in principle other archs are using the same or similar contracts
<adamgreig[m]>
and like, rtic relies on the pacs exporting certain things
<firefrommoonligh>
adamgreig[m]: Oh interresting... maybe I just overlooked that when I was diving into this a few weeks ago and ultimately gave up
<adamgreig[m]>
for cortex-m, we know we're saying the pac must have an enum that impls InterruptNumber, and other arches have a similar trait that PACs must impl on an enum
<adamgreig[m]>
but currently we don't say "it must be pac::Interrupt", but we could if we wanted to save people some typing
<adamgreig[m]>
conceivably we could have the macro detect interrupt(pac) vs interrupt(pac::Interrupt) and work either way
<adamgreig[m]>
maybe it should just be called cortex-m-interrupts and document those requirements there
<thejpster[m]>
<thejpster[m]> "no, wait, not that. The binary..." <- ok, I know what I did. If you don't use -A, you get .text + .rodata in the .text column. The 4992 comes from actual .text using -A.
<dirbaio[m]>
if we make it #[interrupt(pac)], the contract would have to say something like "the PAC must be one module, where there's one child item named Interrupts which is an enum and implements ..."
<dirbaio[m]>
which feels much less clean
<adamgreig[m]>
I guess it doesn't need to be one module, but it does need to (re-)export Interrupts at the top level
<dirbaio[m]>
well yea
<dirbaio[m]>
"module-like thing"
<adamgreig[m]>
(eg stm32f4 PAC has a module per chip, selected via feature, but the module contents are all re-exported at the top level for the one you selected, including Interrupt)
<dirbaio[m]>
module or crate
<adamgreig[m]>
maybe a compelling alternative is #[interrupt(pac::Interrupt::USART0)] fn my_interrupt()
<adamgreig[m]>
old skool
<dirbaio[m]>
that means the macro has to parse pac::Interrupt::USART0 into pac::Interrupt, USART0
<dirbaio[m]>
thejpster[m]: ahhh
<dirbaio[m]>
thejpster[m]: so with that, you get a +400b increase on mac too?
<adamgreig[m]>
hm, yea, I guess it needs the literal name and doesn't care about the vector number at all
<adamgreig[m]>
trying to remember which version of c-m-rt/svd2rust had the old interrupt!() macro which worked a bit like that
<dirbaio[m]>
and it'd be inconsistent vs #[exception] which still uses the function name
<dirbaio[m]>
thejpster[m]: though +400b is still not nice...
<GrantM11235[m]>
dirbaio[m]: Maybe it should be `#[exception(SysTick)] my_fn() { /* ... */ }`?
<dirbaio[m]>
but why
<thejpster[m]>
dirbaio[m]: And no idea where that 6588 came from originally
<dirbaio[m]>
what's the advantage? you have to type more, and you have to type a dummy function name that's not used for anything because you can't call that function directly anyway
<thejpster[m]>
thejpster[m]: (which was in the -A output)
<adamgreig[m]>
what do you think of permitting #[interrupt(pac)] by defaulting to an Interrupt top-level item if only a crate name is provided to the macro?
<adamgreig[m]>
I don't love it as it seems a bit ambiguous and "two ways to do things", if we thought it was better we should probably just say PACs should do that
<adamgreig[m]>
but it is a bit slicker and less typing
<thejpster[m]>
I prefer the interrupt name in the attribute because interrupt names do not follow function name norms.
<thejpster[m]>
I like giving people flexibility, so using either pac or pac::Interrupt is fine.
<thejpster[m]>
I greatly prefer exception and interrupt to work the same way.
<GrantM11235[m]>
It is kinda weird that the function name is magical and all caps
<thejpster[m]>
Also interrupts can be like GpioExt3Uart4 because the vendor was weirdly sharing an NVIC line, and the function name is an opportunity to clarify which one you actually care about
<adamgreig[m]>
dirbaio's right though, the alternative is you have to make up a dummy name for the function that doesn't matter and can't be called
<adamgreig[m]>
so what are you gonna call it apart from usart0?
<adamgreig[m]>
I don't think the macro system is potent enough that we could make it case-insensitive, even if that sounded like a good idea
<adamgreig[m]>
I don't know that you can use pac::Interrupt::*; [interrupt(USART0)] anyway, because the macro has to put the name into the interrupt enum to check it exists
tamme[m] has joined #rust-embedded
<tamme[m]>
adamgreig[m]: Could just be `use pac::Interrupt::{UART0, EXT1, ADC};`
<adamgreig[m]>
so we couldn't permit #[interrupt(USART0)], it would have to be #[interrupt(Interrupt::USART0)] at least?
<thejpster[m]>
Never put into a comment what you could have put into a variable name or function name
<dirbaio[m]>
sure, but making the macro allow a dummy funciton name so the user can use it as a comment is weird
<thejpster[m]>
No more so than #[entry]?
<thejpster[m]>
and doesn't the function name make it into the symbol table?
<dirbaio[m]>
also, good function/variable names help because they make the code calling/using them more readable
<adamgreig[m]>
the underlying interrupt name does, whatever the user picks for their handler doesn't
<dirbaio[m]>
but here you're not calling that function from anywhere
<adamgreig[m]>
(the macro renames it)
<thejpster[m]>
ok, if we're just going to rename it, letting them pick a name is less useful / arguably more confusing.
<adamgreig[m]>
(obviously currently it looks like the name makes it to the table because the name is the interrupt name)
<adamgreig[m]>
so the name in the ELF is always USART0
<thejpster[m]>
although, again, interrupt names as function names make clippy sad BecauseCapsAreWrong
<tamme[m]>
RTIC is similar in having arbitrary function names and naming the interrupt in the attribute: #[task(binds = UART0)] fn uart0(cx: ..)
<dirbaio[m]>
adamgreig[m]: yep. the macro also needs access to the path to `Interrupt` so it can emit some code that "asserts" that it impls InterruptNumber
<dirbaio[m]>
no way to do that with #[interrupt(USART0)]
<adamgreig[m]>
yea
<dirbaio[m]>
ah no. maybe it can emit code that asserts USART0 is a value of a type that impls InterruptNumber
<adamgreig[m]>
that you have to call #[interrupt(Interrupt::USART0)] and can't use use Interrupt::USART0; #[interrupt(USART)] seems like one reason to not do it
<thejpster[m]>
And let's not forget, STM32 give us USART3_4_5_6 and EXTI4_15
<adamgreig[m]>
hm
<thejpster[m]>
so don't imagine the interrupt name will always make sense
<dirbaio[m]>
but the point is moot because you can break it if you use pac::interrupt::USART0 as Foo; #[interrupt(Foo)] fn blah() {}
<adamgreig[m]>
is that enough to check it's inside the PAC's InterruptNumber-impl'ing enum?
<adamgreig[m]>
true
<therealprof[m]>
If STM gives you crap interrupt names... oh wait...
<adamgreig[m]>
from the call syntax it looks as though it's using the value of the enum variant, but in reality it's using the name of the enum variant
<adamgreig[m]>
which I think is expressed more clearly by having the macro take the enum and the function name select the variant
<kevlan[m]>
If the function name doesn't make it into the output then debugging with GDB gets real confusing when you're setting a breakpoint at the function and the function isn't there.
<dirbaio[m]>
yeah
<tamme[m]>
Does the function need to be renamed? Is it not just used as a function pointer in the interrupt table?
<thejpster[m]>
It gets inserted into the vector table with its Well Known name.
<thejpster[m]>
You can't insert arbitrary function pointers into an array in Crate A, simply by writing code in Crate B.
<dirbaio[m]>
so I think the only solution that makes sense is #[interrupt(pac::interrupt)] fn USART0() {}
<thejpster[m]>
You can however replace a function Crate A already knew about (because it had a weak alias to DefaultHandler)
<thejpster[m]>
This is basically all to avoid us copying the vector table to RAM and just actually putting the function pointer into the RAM copy at run-time, like many RTOSes do.
<tamme[m]>
thejpster[m]: Oh, yes I forgot that you might want different crates to define different interrupt handlers... Thanks :)
<thejpster[m]>
the vector table is defined by the PAC, so your code is Crate B in this instance.
<adamgreig[m]>
dirbaio[m]: what about allowing `#[interrupt(pac)]`? in retrospect I don't think you can disambiguate it from `use pac::Interrupt; #[interrupt(Interrupt)]`, so perhaps not great
burrbull[m] has joined #rust-embedded
<burrbull[m]>
adamgreig[m]: what is wrong here?
<adamgreig[m]>
burrbull[m]: it would create a handler for TIM2, not for USART0
<adamgreig[m]>
which is probably not what the user planned
ryanpaulgannon[m has joined #rust-embedded
<ryanpaulgannon[m>
Hey, sorry I’m in the wrong place (still getting used to Element!). I’m wondering if anyone can point me in the right direction, I have an Elite-Pi that I’m trying to practice some embedded Rust on, I cloned the project to use blinky on the RP2040. After I ran cargo build —release —features=“critical-section-impl” —example blinky it appeared to work okay and then it disconnected my device and now I can’t get
<ryanpaulgannon[m>
it to be recognised by my MacBook?
<burrbull[m]>
adamgreig[m]: why? It is just a number
<adamgreig[m]>
it uses the name, not the number
<adamgreig[m]>
the number's only used by cortex_m's NVIC driver
<dirbaio[m]>
adamgreig[m]: yep that doesn't work. the macro would have to either always append `::Interrupt` or never. you can't "autodetect"
<adamgreig[m]>
right, you could detect a path vs an item but it breaks down if the item might be the enum itself, so nevermind
<dirbaio[m]>
shame there's no way to autogenerate a symbol name from a const number
<therealprof[m]>
adamgreig[m]: Why would we assume that a user who wrote such a thing didn't actually mean it, too?
<burrbull[m]>
adamgreig[m]: how it uses the name? for what?
<thejpster[m]>
ryanpaulgannon: sorry, we're in the middle of a meeting right now
<dirbaio[m]>
we could use numbers in symbol names if it was possble to do something like#[export_name = concat!("INTERRUPT_", $irq as usize)] fn foo()
<GrantM11235[m]>
ryanpaulgannon[m: This is the right place to ask, but we are in the middle of our weekly meeting right now. Ask again once the meeting is done, we will be happy to help
<thejpster[m]>
ryanpaulgannon[m: You might want to ask in the rp-rs channel. But you will need to hold the BOOT power whilst you power on your RP2040 if you want it to go back to bootloader mode.
<adamgreig[m]>
burrbull: the macro just re-exports the function with a no_mangle interrupt handler name, and the PAC puts a function pointer to the same extern global name into the vector table in flash
<ryanpaulgannon[m>
thejpster[m]: Appreciate the help, will take a look!
<tamme[m]>
I guess there is a very good reason, but using the linker to build the vector table feels pretty magical...
<adamgreig[m]>
dirbaio[m]: this is even less debugger-friendly, and would be a kinda scary breaking change as we move the interrupt macro between PAC and c-m-rt at the same time as the PACs redefine the vector table names, I think?
<thejpster[m]>
the vector table is just an array of 32-bit values. The size and specific order of the array is only known by the PAC.
<dirbaio[m]>
yeah
<adamgreig[m]>
tamme[m]: this is pretty much how everything does it, including most RTOSs, afaik
<thejpster[m]>
and you don't want to make 155 linker sections, one for each entry in the array
<adamgreig[m]>
it's often possible to move the vector table into RAM in an RTOS, but many do just have static allocations, it's not uncommon
<dirbaio[m]>
it's not possible anyway so... ¯⧵_(ツ)_/¯
<thejpster[m]>
adamgreig: in my experience, most RTOSes put the table in RAM
<thejpster[m]>
but anyway
<adamgreig[m]>
maybe we use different RTOSs :P
<tamme[m]>
Yes, I am not questioning that it is a neat way to do it, just that it was a bit supprising :)
<adamgreig[m]>
but yea, regardless, that part's probably not changing
<adamgreig[m]>
tamme: it's maybe more like "the PAC defines a static array of function pointers which it exports with a particular unmangled name, the linker script places that array into the start of the output section that will be written to flash"
<adamgreig[m]>
to wrap up the discussion then, I think we have the outline of a plan for PACs to be independent of c-m-rt, and the interface should be documented in the new c-m-interrupt-number crate
<adamgreig[m]>
which maybe should be called c-m-interrupts
<dirbaio[m]>
c-m-interrupt is taken :P
<adamgreig[m]>
ah
<dirbaio[m]>
c-m-interrupt s isn't
<adamgreig[m]>
perfect
<adamgreig[m]>
not yet anyway lol
<therealprof[m]>
Wouldn't that be super confusing?
<adamgreig[m]>
as in, because both crates exist?
<dirbaio[m]>
blame crates.io wild west lack of namespacing
<therealprof[m]>
As in, the names are so close together that it would be rather likely that people confuse them.
<adamgreig[m]>
they're different names and c-m-interrupt isn't one of our crates or very widely used, I think it would be OK?
<adamgreig[m]>
cortex-m-interrupt-number is quite a mouthful and if the crate is now both "the trait" and also "the interface agreement between PACs and the cortex-m crates" it does more than just "interrupt number"
<dirbaio[m]>
end-users would still only interact with c-m, c-m-rt
<adamgreig[m]>
still, open to suggestions
<GrantM11235[m]>
What about asking the author of c-m-interrupt if they would be willing to donate the name?
<adamgreig[m]>
I don't mind c-m-pac-interface, but is it anything except interrupts?
<dirbaio[m]>
it might have more stuff in the future
<dirbaio[m]>
no idea what though
<dirbaio[m]>
nvic prio bits maybe
<therealprof[m]>
Are those the other topics thejpster wanted to use the remainder of time on... when there was some left? 😉
<dirbaio[m]>
or somehow configure which thumb arch the chip is using
<adamgreig[m]>
I Was going to ask if any of it is even cortex-m specific, but yes, the whole point is that it's got the u16 InterruptNumber
<dirbaio[m]>
yeah it's definitely cortex-m specific
<adamgreig[m]>
yea, nvic prio bits is a fair point
<dirbaio[m]>
other arch crates could copy the pattern of having their own "arch crate -- pac interface"
<adamgreig[m]>
therealprof[m]: right, right
<dirbaio[m]>
:D
<adamgreig[m]>
I was going to talk about a new embedded-alloc and heapless release, but I think both are more or less in hand thanks to the libs team, so I'm not sure there's much to discuss
<dirbaio[m]>
there's a few PRs left but they're not breaking, so they can be done in 0.8.1
<thejpster[m]>
came up today in training
<dirbaio[m]>
lol it shoud definitely be repr(C)
<dirbaio[m]>
re `mutex-trait`. imo we should archive it.
<dirbaio[m]>
However, who has the authority to decide that? I think we should sort that out then decide somethign. otherwise it's going to keep coming up every meeting. and it was already discussed, it's not like we have any new insights for discussion...
<adamgreig[m]>
resources team own it, so resources team
<adamgreig[m]>
I agree, but so far other things have been more worth talking about and it's not been urgent that we archive it, so I've left it on the agenda
<therealprof[m]>
adamgreig[m]: Make an RFC, put it up for vote.
<therealprof[m]>
Should have been to dirbaio .
<dirbaio[m]>
also it's not like it's permanent. if in the future someone wants to take on the challenge of making a mutex trait that actually works, we can always unarchive / reuse the crate name
<adamgreig[m]>
yea
<therealprof[m]>
Indeed.
<adamgreig[m]>
thejpster: I guess this is very like the repr(C) in volatile-register: yes, though at present it shouldn't make any difference
<thejpster[m]>
oh, and someone tried implementing embedded-sdmmc against embedded-hal 1.0 and it didn't go well.
<thejpster[m]>
embedded-sdmmc really needs to clock bytes out into the bus with NO device selected, to put the card into SPI mode. The API doesn't really allow for that.
<adamgreig[m]>
both things in the union are 4-bytes-big and 4-bytes-aligned with reprs that match c themselves, so rustc is somewhat limited in how it might fuck it up, but nevertheless
<dirbaio[m]>
was discussed in this channel a few days ago. SpiBus does, SpiDevice doesn't
<dirbaio[m]>
but you can write your own thing on a `&RefCell<SpiBus>`, it can even coexist on the same bus with drivers that do use SpiDevice.
<dirbaio[m]>
same as displays with a DC pin
<thejpster[m]>
ok, interesting
<adamgreig[m]>
sure is an annoying quirk of sd cards in spi mode
<adamgreig[m]>
we're decently over time so I'll end the meeting here, thanks everyone!
<dirbaio[m]>
so I still think the SpiDevice trait is okay
<dirbaio[m]>
docs should be expanded to clarify "this is only meant to be used for standard SPI devices, which are just: assert CS, do transactions, deassert CS"
<dirbaio[m]>
and hints of what to do if your device isn't that
<dirbaio[m]>
perhaps linking to the embedded-sdmmc and display-interface code once they're upgraded to eh1.0, as examples
<dirbaio[m]>
s/transactions/transfers/
<dirbaio[m]>
because the alternative is having a "LockableSpiBus" trait or something, like the previous closure-based SpiDevice we had before
<dirbaio[m]>
which has a few big downsides
<dirbaio[m]>
(not implementable on linux, not implementable on some RTOSs, not dyn-safe, doesn't work for async because no async closures)
<thejpster[m]>
<thejpster[m]> "(which was in the -A output)" <- core::fmt::Formatter::pad went from 0x498 to 0x69e
<thejpster[m]>
thejpster[m]: and core::slice::index::slice_start_index_len_fail appeared, at 0x48
<thejpster[m]>
thejpster[m]: It was the disabling of some unsound MIR optimisation passes
<thejpster[m]>
thejpster[m]: So, yay, code is more sound now!
datdenkikniet[m] has joined #rust-embedded
<datdenkikniet[m]>
<GrantM11235[m]> "What about asking the author..." <- I'd be fine donating the name :) When we still worked on it it was an interesting concept but it never really took off. I will ask a bit to see if other contributors to that project have a problem with that, and report back when there is clarity
<thejpster[m]>
<thejpster[m]> "So, yay, code is more sound now!" <- re-running with 6500 bytes of flash space, and we find a different commit
<adamgreig[m]>
thank you, but please don't feel pressured, we might want a totally different name in the end anyway!
<diondokter[m]>
<JamesMunns[m]> "Then yeah, it was probably the..." <- Btw, in some spare time I've been looking into the fmt code and am collecting things in this repo: https://github.com/diondokter/rust-fmt-size
<diondokter[m]>
So far not really any conclusions yet other than that the system is pretty bad for code size, but we all already knew that haha
neceve has quit [Ping timeout: 255 seconds]
Guest7221 has left #rust-embedded [Error from remote client]