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
<thejpster[m]> if it doesn't have a shell and you can't load programs off some kind of storage media, it's not an os :mic drop:
GabeR[m] has joined #rust-embedded
<GabeR[m]> Hello all. Is there is a recommended way to set up unit testing for I2C devices?
<GabeR[m]> My gut was thinking of of creating a structure that implements the I2C trait, and allows a user to pre define register values. Is there already something like this out there?
<GabeR[m]> Aha. Very nice. That's exactly what I was thinking of, but better than I probably could have written.
<GabeR[m]> Thanks
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
Sea[m] has quit [Quit: Idle timeout reached: 172800s]
marmrt[m] has quit [Quit: Idle timeout reached: 172800s]
barnabyw[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]> <thejpster[m]> "if it doesn't have a shell and..." <- He says, after his OS existed for a year or two before adding a shell and a storage media :D
<JamesMunns[m]> Tho tbh, your previous comments about that inspired me to prioritize a shell and a storage media for MnemOS, so I can't say I disagree :)
<thejpster[m]> The shell was the first thing I added to the Monotron. The Neotron was only a tech demo until I added the shell
<JamesMunns[m]> Fair, I guess I started drawing history from the Neotron, not the Monotron
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
dngrs[m] has joined #rust-embedded
<dngrs[m]> when/why would cortex_m::Peripherals::take() return None?
<M9names[m]> it returns None when you've already taken them once
<dngrs[m]> hmmmm
<dngrs[m]> I haven't though
<M9names[m]> 🤔
<dngrs[m]> I'm using [this](https://github.com/yogiastawan/gx_HCSR04/blob/master/examples/use_rtic.rs) and the only thing I've changed is add defmt support
<dngrs[m]> ERROR panicked at examples/use_rtic.rs:74:48:
<dngrs[m]> called `Option::unwrap()` on a `None` value
<dngrs[m]> └─ <mod path> @ └─ <invalid location: defmt frame-index: 11>:0
<dngrs[m]> (it's line 75 in the link because I removed the semihosting import)
<M9names[m]> doesn't RTIC take them?
<dngrs[m]> I think that depends on the app macro invocation but yeah, I'll try poking there
<JamesMunns[m]> I'd say when things go "impossibly wrong", I'd suspect:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/zciRhqTaePmIYiDyzvIVujty>)
<dngrs[m]> looking at official rtic examples, yeah, let mut dp = ctx.device;
<dngrs[m]> but
<JamesMunns[m]> M9names[m]: ah
<JamesMunns[m]> yeah maybe that first tho :D
<dngrs[m]> `peripherals = true` in `#[rtic:app` there
<dngrs[m]> however, I see no reason to *not* use `peripherals = true)`
<dngrs[m]> s/*not*/_not_/, s/)//
<dngrs[m]> so let's see
barafael[m] has joined #rust-embedded
<barafael[m]> Postcard is nice. That said, is there something I can use that is serde-compatible but essentially gives a repr-C struct serialisation into a buffer, as if transmuted?
<dngrs[m]> ah so it always takes core
<barafael[m]> Or shall I just transmute them
<JamesMunns[m]> ssmarshal is closer to that, but still not exactly
<dngrs[m]> I wonder how the person who wrote the example I'm using tested it then...
<barafael[m]> Oh sorry for barging in
<JamesMunns[m]> it also doesn't support some things that should work, I forget all the caveats
<dngrs[m]> barafael[m]: no worries :)
<JamesMunns[m]> barafael[m]: I should write a blog post, but:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/DUVikwEdeXhAHtplyrEwITVc>)
<JamesMunns[m]> ah, does not compile, at least in a simple example!
<barafael[m]> Yes... I'm aware, hence the question. Could there be a serde serialise that just puts u32 in le in the output and also everything else in some defined way and then also deserializes it
<diondokter[m]> JamesMunns[m]: Yeah, would think it's strange to get UB from something so simple without using unsafe
<JamesMunns[m]> run in release: works (sort of)
<JamesMunns[m]> run in miri: immediate failure
<JamesMunns[m]> barafael[m]: like, do you just want "postcard without varints"?
<barafael[m]> Sure, why not
<JamesMunns[m]> like, you could definitely fork postcard and make a "postcard but no varints"
<barafael[m]> Flavour?
<JamesMunns[m]> I mean you could use the fixint tools, but you'd still have to address slice lengths and enum discriminants
<JamesMunns[m]> then you have to decide how to format those on the wire:
<JamesMunns[m]> `usize` is 64 bit on your PC, and 32 bit on your MCU
<JamesMunns[m]> you could pick one
<JamesMunns[m]> also, serde gives you no context you are serializing a usize, it just serializes a u64 on 64-bit platforms and u32 on 32-bit platforms
<barafael[m]> Ah, yes. It's hard. I think it would be easier to just make postcard adapters for everything receiving and sending buffers from/to my firmware
<barafael[m]> i.e. Javascript
<barafael[m]> And C. Not impossible
<JamesMunns[m]> maybe I'm missing what your real intent is :)
<JamesMunns[m]> you could write postcard helpers for C FFI and WASM
<JamesMunns[m]> I've done it personally for:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/HyTMyXvmFIMpldugkqfBVDhL>)
<barafael[m]> X/Y :D
<barafael[m]> I have a firmware and a protocol to talk to it. Also the firmware writes to the eeprom using postcard.
<barafael[m]> The host side wants the frames. So far I did this with simple rust programs. It should probably stay that way and I just pipe the data through postcard before further passing it up
<JamesMunns[m]> btw if you want to do something dynamic and codegen based, you could also use the Schema capabilities to do that, instead of CFFI
<JamesMunns[m]> the other thing you could do is write rust code (cffi or not) that coverts from postcard to repr c structs, or from postcard to json
<JamesMunns[m]> lots of ways to solve this :) dunno if this is for an open source or work thing
<barafael[m]> Both, Just Not Yet
<JamesMunns[m]> Fair!
<barafael[m]> I think I'll go the json route for now. I'll look into the schema stuff, that's really cool. Session types here we come
<JamesMunns[m]> I don't think that gets to session types, postcard-rpc sort of does, but more just pairing request and response types
<JamesMunns[m]> so "oneshot session types"? idk.
<barafael[m]> I lol'd when I saw postcard-rpc, it's in places eerily close to what I have :D
<JamesMunns[m]> :)
<JamesMunns[m]> it's a collection of patterns I've been doing loosely for the last 5 years
<JamesMunns[m]> the only "innovative" part is using the hash of the schema as a unique message kind ID
<JamesMunns[m]> vs using an outer enum that encapsulates all potential types
<JamesMunns[m]> I do think it would be fun to make a "codegen version of postcard" that doesn't use serde, and supports more langs than just rust
<JamesMunns[m]> which, hillariously, I basically did for a client, but they didn't let me open source it :(
<JamesMunns[m]> but I would do again, if I got sponsored for it :D
<barafael[m]> Language independent like protobuf, has a schema, but ubiquitous like serde? Heck yeah
<JamesMunns[m]> that said, a big value of serde is:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/cHlfCjdmiHKpREIOvSuXVtJH>)
<barafael[m]> Btw do you have hints where I can learn how to set up the usb buffer etc. with the right sizes for my application? I saw the numbers in postcard-rpc and have similar ones, but just eyeballing it, as I don't know what each of the buffers is for
<JamesMunns[m]> I gotta run now, you can use the size experimental derive in some cases
<JamesMunns[m]> I just guess a lot of the time :p
<barafael[m]> Ty!
michaeldesilva[m has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh> <JamesMunns[m]> "Do you mean "design your own..." <- Either
<firefrommoonligh> Both of those describe use cases I have have regularly
<JamesMunns[m]> Design your own: probably just use postcard. Describe an existing: idk probably not serde honestly
ruabmbua[m] has joined #rust-embedded
<ruabmbua[m]> So, assuming I do not have a svd file (and also do not want to write one), is there any nice way to create PaC like APIs? Is there maybe an existing crate with a macro I do not know anything about?
<ruabmbua[m]> I am currently writing a driver for an interrupt controller.
<firefrommoonligh> If I use postcard I can't effectively document it
<firefrommoonligh> Or expect the connected device to use it
<JamesMunns[m]> <firefrommoonligh> "If I use postcard I can't..." <- Why not?
<JamesMunns[m]> Postcard has a stable and documented wire format, and the schema derive could be used to generate docs.
<JamesMunns[m]> I'm not sure how you're worse off than a hand rolled format.
<JamesMunns[m]> <firefrommoonligh> "Or expect the connected device..." <- You could, but I agree it would take some work. Postcard is a pretty dumb format in terms of the number of primitives it uses, tbh.
<firefrommoonligh> Confirm/deny postcard doesn't have a direct index-to-field mapping?
<JamesMunns[m]> not sure what you mean, but no, varints are variable length, and arrays can be variable length, and enums can be variable length
<firefrommoonligh> And uses variable length encodings always
<JamesMunns[m]> firefrommoonligh: this is true for all ints bigger than one byte
<firefrommoonligh> So, when you read a datasheet, think of that
<firefrommoonligh> You want very clear and straightforward mappings in a table
<JamesMunns[m]> im not claiming postcard can be used to model arbitrary data formats
<JamesMunns[m]> just objecting to "you can't document postcard".
<JamesMunns[m]> i2c devices don't typically have discriminated unions or variable length arrays :)
<firefrommoonligh> When you are implementing an interface to a device, it's easier if there is a rigid, byte-aligned format where indexes and meanings map directly
<firefrommoonligh> Vice, having the indexes shift because you are using variants, and the value changed. Maybe I am misunderstanding
<JamesMunns[m]> I understand what you are saying, and I don't recommend postcard if you have to round trip the spec through a PDF.
<JamesMunns[m]> It could be done, and is deterministic, as documented at https://postcard.jamesmunns.com/
<firefrommoonligh> If it did that, I would use postcard all over my code bases. I am considering it now for internal config storage in flash.
explodingwaffle1 has quit [Quit: Idle timeout reached: 172800s]
cajt[m] has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh> I think ChatGPT just wrote the proc macro I'm looking for...
<firefrommoonligh> Here is the gist of it. Needs updates for recursion, deserialization, and probably more, but working for the basic serialization case:
<thejpster[m]> Anyone here responsible for tinybmp? Today I tried to add RLE8 support!
<thejpster[m]> Took a lot of trial and error, in the absence of decent docs. But I think I got there. At least my test bitmap came out ok.
<thejpster[m]> Docs for BMP, not the library. The library is pretty good.
MathiasKoch[m] has joined #rust-embedded
<MathiasKoch[m]> Hi, calling all generics wizards, that might be able to understand rustcryptos generics magic?!... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/FlFzJhgUqDVfzumZMMtBoxaL>)
pbsds has quit [Quit: The Lounge - https://thelounge.chat]
pbsds has joined #rust-embedded
PauCarrCardona[m has quit [Quit: Idle timeout reached: 172800s]
GenTooMan has quit [Ping timeout: 260 seconds]
StephenD[m] has joined #rust-embedded
<StephenD[m]> I absolutely cannot wrap my head around the architecture of the stm32fxx hal
<StephenD[m]> I've been trying to get the SCB register for like an hour
<StephenD[m]> I can get some of the other registers through the peripherals struct but that one is missing
<JamesMunns[m]> SCB is in cortex_m, specifically CorePeripherals
<StephenD[m]> However, it does exist in the peripherals struct of the cortex_m crate
<JamesMunns[m]> your pac should re-export the core peripherals
<StephenD[m]> Via the pac I get get like, the struct definition. But I need an instance of it
<JamesMunns[m]> let mut core = stm32f4xx_hal::pac::CorePeripherals::take().unwrap();
<JamesMunns[m]> core.SCB.enable_icache();
<JamesMunns[m]> some methods don't require an instance, so like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/qrVyfzNsMgaDEdRZbZpAzlmG>)
<StephenD[m]> JamesMunns[m]: > <@jamesmunns:beeper.com> ```rust... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/wyNLPnoMBBmrMiQebcteuylr>)
<JamesMunns[m]> I think RTIC has an option where you can have it give you the core peripherals, lemme check
mali[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]> I think you set peripherals = true, then you have cx.core
<JamesMunns[m]> (you might not need peripherals = true for that? Idk)
<StephenD[m]> ahh, core
<StephenD[m]> Thanks!
GenTooMan has joined #rust-embedded
ChristofPetig[m] has quit [Quit: Idle timeout reached: 172800s]
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]