korken89[m] has quit [Quit: Idle timeout reached: 172800s]
emerent_ has joined #rust-embedded
emerent has quit [Killed (calcium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
raulvt[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has joined #rust-embedded
Guest7221 has left #rust-embedded [Error from remote client]
notgull has quit [Ping timeout: 252 seconds]
notgull has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
Guest7221 has joined #rust-embedded
Guest7221 has left #rust-embedded [Error from remote client]
MathiasKoch[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7221 has joined #rust-embedded
gmarull[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7221 has left #rust-embedded [Error from remote client]
fu5ha[m] has joined #rust-embedded
<fu5ha[m]>
I just had an idea about the `SpiDevice` and manual CS management stuff we've discussed a few times. What if for cases where a driver wants to be able to do manual CS pin management, we could provide (or at least document the pattern of) a `DummyCsPin` struct that can be bundled with the actual shared `SpiBus` to turn it into a `SpiDevice` as usual (f.ex. through `embedded-hal-bus` helpers), but which doesn't *actually* manage the CS
<fu5ha[m]>
pin internally since it will just go to the dummy impl. Then the driver can still own the CS pin and manage it separately. I think this is enough to support the SD and display cases... Thoughts? cc dirbaio
<dirbaio[m]>
So the driver takes a SpiDevice with a dummy CS pin, and the real CS pin separately
<dirbaio[m]>
?
<dirbaio[m]>
That's equivalent to the driver taking a SpiBus and a CS pin: works, but doesn't allow safely sharing the bus between multiple drivers
<dirbaio[m]>
You have to assert cs after locking the bus
<fu5ha[m]>
dirbaio[m]: Right right, that makes sense. It's definitely a bit more error prone. Is it actually more likely to get preempted in hardware than the SpiDevice impl getting preempted in the middle of it doing the same thing? Or do you mean preempted as in programmer error
<dsvsdveg[m]>
<K900> "It depends on what you mean by..." <- by os i meant something that have an interface (example like linux )
<K900>
You mean a graphical interface?
<K900>
No, that's too big to run on any microcontroller
<dsvsdveg[m]>
K900: even if it's only terminal interface?
<dsvsdveg[m]>
K900: Thank you K900. You are amazing.
<JamesMunns[m]>
<K900> "Which is a small RISC-V microcon..." <- fwiw the D1 is a full 64-bit processor, rather than an MCU. It's more "small cortex A shaped" than "cortex m"
<JamesMunns[m]>
Agree with everything else you said tho :)
<K900>
Yeah what I was trying to say is "small RISC-V SoC"
<K900>
But brain is not braining well today
<K900>
And now I wonder how stupid of an idea it would be to port mnemos to one of those keycap-sized mt7628 boards
<JamesMunns[m]>
Basically the rule of thumb is "if you can run a bare metal rust program on it, you can probably port mnemos to it".
<JamesMunns[m]>
If you have interrupts, a timer, and a UART, you're good to go.
<JamesMunns[m]>
Also, I appreciate the mnemos plug, I really would only recommend it for "fun to play with if you are comfortable with async embedded rust", totally not super beginner friendly yet.
<JamesMunns[m]>
* mnemos plug, tho I really
<JamesMunns[m]>
I also probably wouldn't recommend mnemos with < 256KiB of RAM, you could tune everything down to fit, but at that point you're better off just using embassy IMO
<K900>
<JamesMunns[m]> "Basically the rule of thumb is..." <- I mean I'm sure it's _possible_
<K900>
It's just stupid
<K900>
Because those boards are exceptionally boring
<K900>
Except the one thing that is interesting about them
<K900>
Which is the fact that they're _tiny_
<JamesMunns[m]>
I think those are the ones they used in the notkia too
<K900>
And the many LEGIT⭐️⭐️ brand knockoffs thereof
<JamesMunns[m]>
Ah it's mips but not mediatek, yeah
<JamesMunns[m]>
Yup, and all the "micro wifi routers" too
<JamesMunns[m]>
OpenWRT class devices imo lol
<K900>
The 7628 is actually a surprisingly capable SoC
<K900>
It's got basically no CPU
<K900>
But enough fixed function networking stuff to actually be usable as a router
<JamesMunns[m]>
I've never had a better category descriptor. And tbh yeah that's the zone I'm aiming mnemos at actually
<JamesMunns[m]>
Just focusing on riscv or cortex-a type devices, primarily selected by "can I get a real datasheet for it to actually write drivers"
<JamesMunns[m]>
I plan to run it on esp32c3 and rp2040, not certain that's a good idea other, or if you should just use embassy and some crates from mnemos for comms and ease
<JamesMunns[m]>
(We do have a build for esp32c3 already, it's pretty "hello world" state so far)
_whitelogger has joined #rust-embedded
explodingwaffle1 has quit [Quit: Idle timeout reached: 172800s]
wucke13[m] has joined #rust-embedded
<wucke13[m]>
What is the canonic way to get embedded_hal::blocking::delay::DelayMs for one-time usage in the context of rtic v1?
Guest7221 has left #rust-embedded [Error from remote client]
<thejpster[m]>
Would anyone like a fun puzzle? I have a C program calling a Rust program and apparently they disagree about where structs are going in memory.
<Lumpio->
...not struct internal layout?
<thejpster[m]>
well possibly that to
<thejpster[m]>
or whether struct Handle(u8) should just go into a register
<thejpster[m]>
(it is repr(C) - I'm not that bad)
<JamesMunns[m]>
is handle marked transparent as well?
<JamesMunns[m]>
I'm not sure if repr c implies transparent
<JamesMunns[m]>
you might need repr(c, transparent)
<thejpster[m]>
it is not transparent. I thought repr(C) would be enough?
<Lumpio->
Oh no are you passing a struct as an argument
<JamesMunns[m]>
> Also, passing the struct/enum through FFI where the inner field type is expected on the other side is guaranteed to work. In particular, this is necessary for struct Foo(f32) or enum Foo { Bar(f32) } to always have the same ABI as f32.
<thejpster[m]>
r6 contains the function pointer (and is correct). I would have thought either the integer handle went into r0, or the address of the handle went into r0. Then I thought the address of the buffer struct would go in r1. But this is my naive assumption.
neceve has joined #rust-embedded
<thejpster[m]>
Because these are structs passed by value.
<JamesMunns[m]>
if its larger than 4 bytes, then you are returning by reference
<JamesMunns[m]>
then r0 would have the return pointer, r1 would have the handle, and r2 r3 would be the ptr+len of the slice
<thejpster[m]>
oh wait
<thejpster[m]>
I wonder if arm-none-eabi-gcc does short enums by default and Rust doesn't.
<thejpster[m]>
because that will change the size of the result type
<thejpster[m]>
and hence whether it's on the stack or goes back in r0
<JamesMunns[m]>
if not (the result is 4 bytes), then r0 would return the value of the result, and I think r1-r3 are as-ish
<JamesMunns[m]>
(I think, rereading)
<thejpster[m]>
on arrival in my function (my breakpoint was stopping on the first line and all the preamble was running, which was messing things up) I have
<thejpster[m]>
So that does look like (space for return value, handle, data pointer, length)
<JamesMunns[m]>
how big was the result?
<JamesMunns[m]>
if > 4, then I say that matches my understanding 1:1
<JamesMunns[m]>
if <= 4, then that seems weird to me, according to the AAPCS, which says items <= 4 bytes can be "inlined" by value instead of by reference
<thejpster[m]>
can I ask GDB to tell me how big it is?
<thejpster[m]>
because I can't print anything on the C side ... because this is the print function
<JamesMunns[m]>
don't you control `neotron_api::Result<()> `?
<JamesMunns[m]>
yeah its bigger than 4 bytes
<thejpster[m]>
On the Rust side, it thinks it is two bytes
<JamesMunns[m]>
enums discriminants in rust are 32-bit unless you repr them
<JamesMunns[m]>
Does C have a concept of zero sized types?
<JamesMunns[m]>
it has unsized, iirc, like blind struct defs, but I didn't think it had zsts
<JamesMunns[m]>
> #[repr(C)] currently just tells Rust to try to pick whatever integer type that a C compiler for the target platform would use for an enum.
<JamesMunns[m]>
yeah, idk. looks like Rust is using -fshort-enums for its enum abi?
<JamesMunns[m]>
you might want #[repr(u32)] (which implies repr(c) with a u32 discriminant
<thejpster[m]>
Rust is using short-enums, yes. Because I think that's the default for arm-none-eabi-gcc
<thejpster[m]>
C doesn't have ZSTs, but you can just delete that arm of the union
<thejpster[m]>
you only need the error arm if T is () for Ok(T)
<JamesMunns[m]>
that's fair!
<JamesMunns[m]>
(can you have an empty union in C?)