ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
ian_rees[m] has quit [Quit: Idle timeout reached: 172800s]
pmnxis[m] has joined #rust-embedded
<pmnxis[m]> I made some MP Tool for my rust-embedded product.
<pmnxis[m]> Unlock Flash -> Flashing Firmware -> Get Serial Number from DB -> Write on OTP section in MCU -> Lock Flash Again
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
<fu5ha[m]> > So the driver takes a SpiDevice with a dummy CS pin, and the real CS pin separately... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/CsDHHnalMpsWbIqklIVDgeZN>)
<fu5ha[m]> * > So the driver takes a SpiDevice with a dummy CS pin, and the real CS pin separately... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/lwzIHPCgdqCbhTzLoXqHnzDQ>)
Guest7221 has joined #rust-embedded
dsvsdveg[m] has joined #rust-embedded
<dsvsdveg[m]> hello, are they any operate system for microcontroller open source ? (rust)
K900 has joined #rust-embedded
<K900> You generally don't need an _operating system_ for a microcontroller
<K900> If you want to do multitasking, there's frameworks like Embassy or RTIC
FreeKill[m] has joined #rust-embedded
<FreeKill[m]> There is Tock
<FreeKill[m]> Which calls itself an OS
<FreeKill[m]> I don't actually know if that's written in Rust or if it just has rust in userspace
<dsvsdveg[m]> K900: yes but is there any microcontroller os open source?
<dsvsdveg[m]> like for esp32 or stm32
<K900> It depends on what you mean by "OS"
<K900> But Tock is an option
<dsvsdveg[m]> operate system ?
<K900> If you want an actual kernel
<FreeKill[m]> But I would say that a classic embedded operating system (like FreeRTOS or ChibiOS)
<FreeKill[m]> Is well replaced by something like RTIC/Embassy
barafael[m] has joined #rust-embedded
<barafael[m]> FreeKill: I agree with that, if it fits what dsvsdveg means by "OS"
<dirbaio[m]> <fu5ha[m]> "> So the driver takes a SpiDevic..." <- > <@fu5ha:matrix.org> > So the driver takes a SpiDevice with a dummy CS pin, and the real CS pin separately... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/OOdSYzookuLgLPOEivWdrlgR>)
<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]> imo a cli interface
<K900> Over serial possibly
<Shellhound> what are you trying to do
<K900> There's https://mnemos.dev/
Lumpio[m] has joined #rust-embedded
<Lumpio[m]> fwiw I've seen many things with a cli interface
<Lumpio[m]> Can spare the effort of creating and maintaiking like a proper client program on a PC when you can just use a serial terminal
<Lumpio[m]> s/maintaiking/maintaining/
<dsvsdveg[m]> K900: thanks going to read the book about. It can run in STM32 or ESP32 ?
<K900> Their main target is Allwinner D1
<K900> Which is a small RISC-V microcontroller
<dsvsdveg[m]> K900: well Allwinner D1 is too much expensive
<dsvsdveg[m]> i'm' more looking for something that run in small and cheap microcontroler
<K900> Honestly I'm pretty sure you're looking for the wrong thing
<K900> The smaller your hardware, the less STUFF you need to be running on top of it
<dsvsdveg[m]> K900: sure yes but i'm just doing experience : )
<K900> If you just want to have a console-like interface, you can make one yourself
<K900> Over, say, serial
<dsvsdveg[m]> K900: this would take some time i think thats why i'm looking for something open source
<K900> That would likely be a lot faster than trying to get a full "OS" to run on an STM32
<dsvsdveg[m]> K900: do we have any awsome github repo for microcontroller
<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> Google says those are some Ingenic thing
<K900> I'm talking about https://vocore.io/v2.html
<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.
<JamesMunns[m]> but yeah in C iirc a single element struct and that element are not required to have the same ABI
<Lumpio-> >Ok_____c_void
<Lumpio-> Is that _five_ underscores in one type name?
<Lumpio-> I mean in a row
<thejpster[m]> cbindgen .... isn't great
<thejpster[m]> That's what it did to FfiResult<()>, where FfiResult is like Result but marked repr(C) (I need crabi!!!)
Guest7221 has joined #rust-embedded
<thejpster[m]> ```text
<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]> reading the aapcs32 right now...
<JamesMunns[m]> gotta look for "Composite Type"
<thejpster[m]> The length of my buffer (36) has appeared on the C side in r3.
<thejpster[m]> On the C side it went r2 (into _write), over to r4 and then into r3. So that checks out.
<thejpster[m]> A collection of one or more Fundamental Data Types?
<JamesMunns[m]> yeah, that's a struct
<JamesMunns[m]> and you have a struct of exactly one fundamental data type
<thejpster[m]> I was looking at a PDF copy from some university course. I'll switch to that one.
<JamesMunns[m]> How big is `Result<()>`? More than 4 bytes? im guessing 32-bit discriminant then something for the error itself?
<thejpster[m]> Let me check
<thejpster[m]> On the Rust side, it is expecting the handle in r0.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/vrUSNtzzDsIORehJwQHjTDmd>)
<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]> r0=0x2007fa48, r1=1, r2=0x2002a830, r3=0x24
<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]> whaaaaat
<thejpster[m]> Maybe I need to turn -fshort-enums /on/?
<JamesMunns[m]> hm. I'm actually not sure enums CAN be considered FFI safe at all
<thejpster[m]> pretty sure it's well defined that you get a struct with a tag and a union of every field
<JamesMunns[m]> like, you should probably specify it as... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/GXPfhIHrdGQWlrKlCNBMJWuH>)
<thejpster[m]> oh ffs bindgen
<thejpster[m]> you suck
<JamesMunns[m]> FIELDLESS enums are specified as the C enum type
<thejpster[m]> s/bindgen/cbindgen/
<thejpster[m]> No, () is not void*
<JamesMunns[m]> why wouldn't () be void*?
<JamesMunns[m]> ah because that makes the ABI think it's a pointer
<thejpster[m]> because () has no size and void* has size four bytes
<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?)
<JamesMunns[m]> like if you had `Result<(), ()>`?
<thejpster[m]> that would just be a tag?
<thejpster[m]> 💥
<JamesMunns[m]> yeah, I guess bindgen could handle all that as special cases.
<JamesMunns[m]> did you just hand edit the c header? or which fix did you go with?
<thejpster[m]> I just manually edited the C header
<thejpster[m]> the cbindgen output was wrong anyway and I'd already edited it
<thejpster[m]> thanks for the help. It runs on hardware, but I got a HardFault when running a program, which is exciting
<thejpster[m]> I'll need to patch up the QEMU version to have the same size stack and see what happens. I suspect it's a bit stack heavy.
Guest7221 has left #rust-embedded [Error from remote client]
neceve has quit [Ping timeout: 255 seconds]
crabbedhaloablut has quit []
notgull has quit [Ping timeout: 255 seconds]
notgull has joined #rust-embedded
Guest7221 has joined #rust-embedded