creich has quit [Remote host closed the connection]
SomeWeirdAnon has quit [Ping timeout: 256 seconds]
creich has joined #rust-embedded
<re_irc>
<@dngrs:matrix.org> sooo, deserialization. I have an animation (sequence of frames with individual duration-per-frame - think GIF) stored on SD card. To save memory I'd like to stream this in chunks and not deserialize it all at once. How would I minimize reinventing the wheel here? (aka, use Serde as much as possible)
<re_irc>
<@dngrs:matrix.org> (reading from SD is solved, only wondering about the Serde part)
<re_irc>
<@dngrs:matrix.org> I should add that I also need to *create* those animation files in the first place, so would like to do that with Serde too
<re_irc>
<@dngrs:matrix.org> but this can be done on a desktop with everything in memory
<re_irc>
<@dirbaio:matrix.org> serde can't do streaming decode, right?
<re_irc>
<@dngrs:matrix.org> I don't think it can; I was wondering how to best chunk this (so I'd serialize the header/metadata and then a vec of frames)
<re_irc>
<@dirbaio:matrix.org> maybe use serde just for single frames, then invent your own "container format" to store a set of frames
<re_irc>
<@dngrs:matrix.org> exactly
<re_irc>
<@dngrs:matrix.org> that's the "as little wheel as possible" part
<re_irc>
<@dngrs:matrix.org> the frame data would literally be an array, every frame has the same size
<re_irc>
<@dirbaio:matrix.org> set of "len + data", so you read len, data then serderialize the data into your Frame struct
<re_irc>
<@dngrs:matrix.org> yup yup
<re_irc>
<@dngrs:matrix.org> ok so I guess I have to manually advance the data pointer and take it from there
<re_irc>
<@dngrs:matrix.org> I mean that's not so bad, I was just wondering if I have to write this from scratch
<re_irc>
<@dngrs:matrix.org> actually, scratch all this. Frame data literally is a `u8` array. I don't need serde for this.
<re_irc>
<@dngrs:matrix.org> brain fart moment 🤡
<re_irc>
<@dirbaio:matrix.org> lol
<re_irc>
<@dngrs:matrix.org> Ok I wasn't entirely brain farting, since every frame also has a custom delay, but that's just another `u8` so I can read+offset this manually
<re_irc>
<@dngrs:matrix.org> we'll see. Maybe if I optimize frames to use delta coding this could become useful.
<re_irc>
<@dirbaio:matrix.org> if it's all fixed size you may get away with a `repr(C)` struct and casting pointers :D
<re_irc>
<@dngrs:matrix.org> yeah! BTDT (with `bytemuck`, which is awesome)
<re_irc>
<@dirbaio:matrix.org> which is nicer than serde because you can get away with 1x copy
<re_irc>
<@dirbaio:matrix.org> with serde you usually need 2x, for the serde'd and deserde'd data
<re_irc>
<@dngrs:matrix.org> also true!
<re_irc>
<@dirbaio:matrix.org> and it's literally free, zero code
<re_irc>
<@dngrs:matrix.org> the delta coding is *probably* not worth the effort anyway. If I have plain old frames of same size I can DMA them all in
<re_irc>
<@dngrs:matrix.org> current state of affairs: streaming GIFs from a react app to an embedded webserver I wrote
<re_irc>
<@dirbaio:matrix.org> lol there's two crates
<re_irc>
<@dngrs:matrix.org> yeah, pretty happy with my progress here! Gotta say though, porting from the C++ WiFiNINA is a nightmare, code's super unreadable
<re_irc>
<@dngrs:matrix.org> and so. much. repetition.
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
fabic has joined #rust-embedded
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
<re_irc>
<@lachlansneff:matrix.org> Yeah, I wrote a driver for the wifinina as well.
<re_irc>
<@lachlansneff:matrix.org> The C++ version is sooo bad
<re_irc>
<@dngrs:matrix.org> Lachlan Sneff: hmmmm, wouldn't you have one socket per request? I haven't tried it out but it should be possible to multiplex over those
<re_irc>
<@richarddodd:matrix.org> Hey, is it not possible to use embassy with latest master ATM?
<re_irc>
<@dirbaio:matrix.org> which nightly are you using? a newer one?
<re_irc>
<@lachlansneff:matrix.org> dngrs (spookyvision@github): It's been a few weeks since I looked at it, but maybe? I think my annoyance largely came from it not being an event-based protocol.
<re_irc>
<@richarddodd:matrix.org> Yeah I literally just updated to latest master.
<re_irc>
<@dirbaio:matrix.org> which rust nightly version are you using I mean
<re_irc>
<@lachlansneff:matrix.org> E.g. you can poll socket (maybe) and definitely wait on them, but good luck actually knowing when data came down the wire
<re_irc>
<@richarddodd:matrix.org> note: the implementation was not maintainable, the feature may get reintroduced once the current refactorings are done
<re_irc>
<@dirbaio:matrix.org> aaarghl
<re_irc>
<@richarddodd:matrix.org> I'll do some more digging see if I can find the commit that disables it. Might find a plan there.
<re_irc>
<@richarddodd:matrix.org> ah you beat me
<re_irc>
<@dirbaio:matrix.org> just... removed
<re_irc>
<@dirbaio:matrix.org> poof, gone
<re_irc>
<@dirbaio:matrix.org> gonna check if we really need impl_trait_in_bindings, for some reason after the last breakage rustc was asking for it
<re_irc>
<@dirbaio:matrix.org> but I think it's just for `let x: impl Foo = blah()`
<re_irc>
<@dirbaio:matrix.org> but we just need `type MyFoo = impl Foo; let x: MyFoo = blah()`
<re_irc>
<@richarddodd:matrix.org> worth a try
<re_irc>
<@richarddodd:matrix.org> I guess it will come back eventually. I'm also guessing that the issue was syntatic ambiguities because I saw an issue about it being a breaking change, but could be wrong.
<re_irc>
<@richarddodd:matrix.org> ^^ TBF to the compiler team I was getting a *lot* of ICEs when using the feature, basically any situation where the compiler should error seemed instead to ICE.
<re_irc>
<@dirbaio:matrix.org> yeah TAIT has been super ICEy 🧊
<re_irc>
<@dirbaio:matrix.org> still been great for embassy, the `#[task]` macro forces correct usage :P
Lumpio- has quit [Ping timeout: 265 seconds]
<re_irc>
<@dirbaio:matrix.org> okay embassy doesn't need `impl_trait_in_bindings` at all
<re_irc>
<@richarddodd:matrix.org> .. having read further nICE
<re_irc>
<@dirbaio:matrix.org> yeah just stick to nightly-2021-07-13
<re_irc>
<@thisdudemorgan:matrix.org> hello there ! i've been searching around on the interwebs without much luck, so I'm turning to you fine folks. I have some trouble understanding how firmware fits on controllers. I mean, if the compiled binary weighs 2.5M, it shouldn't load on a MCU with a 2M flash right ?
<re_irc>
<@thisdudemorgan:matrix.org> Am I missing something obvious here ?
<re_irc>
<@lachlansneff:matrix.org> You have a binary you want to load onto an mcu that's 2MB?
<re_irc>
<@lachlansneff:matrix.org> I'm really curious what that would be
<re_irc>
<@dirbaio:matrix.org> when you build a rust firmware, you get a file in ELF format
<re_irc>
<@dirbaio:matrix.org> which has the built firmware, and lots of extra data (symbol tables, debug info...). Only the actual firmware is flashed to the chip, all the extra data isn't
<re_irc>
<@dirbaio:matrix.org> so the elf *file* size is much bigger than the actual *flash* size
<re_irc>
<@thisdudemorgan:matrix.org> oh alrighty, i'm checking the wrong file then I guess
<re_irc>
<@lachlansneff:matrix.org> Ah, I didn't realize how much larger the elf could be
<re_irc>
<@thisdudemorgan:matrix.org> How can I estimate the actual flashed weight then ?
<re_irc>
<@dirbaio:matrix.org> you can check the real size with `cargo size` (install cargo-binutils)
<re_irc>
<@thisdudemorgan:matrix.org> thank you for your help
<re_irc>
<@dirbaio:matrix.org> (flash usage is text+data, ram usage is data+bss)
<re_irc>
<@dngrs:matrix.org> Lachlan Sneff: I'd have to try that out with my implementation (as in, what happens when > 1 connection sends a lot of data). But I *thiiiiink* this works "okay enough" in my impl. We'll see.
<re_irc>
<@dngrs:matrix.org> so I do
<re_irc>
<@dngrs:matrix.org> ```rust
<re_irc>
<@dngrs:matrix.org> Ok(mut s) => { // read everything that's available on this socket
<re_irc>
<@dngrs:matrix.org> match wifi.wait_for_connection(&server_socket) {
<re_irc>
<@dngrs:matrix.org> loop {
<re_irc>
<@dngrs:matrix.org> and `wait_for_connection` is a misnomer, should be `wait_for_data`
<re_irc>
<@dirbaio:matrix.org> oh TIL that nina is just a firmware for the esp32
<re_irc>
<@dirbaio:matrix.org> replacing the AT firmware
<re_irc>
<@dirbaio:matrix.org> that looks much saner indeed
<re_irc>
<@adamgreig:matrix.org> huh, but made and sold by ublox?
<re_irc>
<@thalesfragoso:matrix.org> does it work on the 8266 ?
fabic has quit [Ping timeout: 255 seconds]
<re_irc>
<@yruama_lairba:matrix.org> hi, i need help to use SPI with the stm32f4_hal. I just can't find how i'm supposed to send data withe this hal ???
tokomak has quit [Read error: Connection reset by peer]
<re_irc>
<@firefrommoonlight:matrix.org> Do the examples on GH give you problems?
<re_irc>
<@yruama_lairba:matrix.org> firefrommoonlight: i can find example using directly spi
<re_irc>
<@firefrommoonlight:matrix.org> Ah you're right
<re_irc>
<@yruama_lairba:matrix.org> i discover there is a "write" method, but i don't know from where it comes
<re_irc>
<@firefrommoonlight:matrix.org> Bottom line: it works using embedded-hal traits. So, you write using embedded-hal::blocking::Spi::Write, or embedded-hal::spi::FullDuplex::send
<re_irc>
<@firefrommoonlight:matrix.org> Because that lib uses these traits as its primary API, its doc page will not have what you're looking for, so reference the traits (linked above) instead
<re_irc>
<@yruama_lairba:matrix.org> okay, seems the write function i use have the same behaviour of the embedded_hal trait
<re_irc>
<@yruama_lairba:matrix.org> it come from a "Write" trait, but i don't know if it's the embeded_hal write
<re_irc>
<@yruama_lairba:matrix.org> another question, is there some "chip select" management in embeded_hal SPI ?
<re_irc>
<@firefrommoonlight:matrix.org> No
<re_irc>
<@firefrommoonlight:matrix.org> Do it yourself. GrantM11235 is working on that
<re_irc>
<@yruama_lairba:matrix.org> yes, i just saw the behaviour may too specific across chip
<re_irc>
<@firefrommoonlight:matrix.org> You can use embedded-hal OutputPin to handle CS generically
<re_irc>
<@yruama_lairba:matrix.org> my chip require a rising edge on CS pin to validate a frame
<re_irc>
<@yruama_lairba:matrix.org> i currently don't care about genericity, i'm just trying to do a firmware to check if my extensionboard is working correctly
<re_irc>
<@firefrommoonlight:matrix.org> Rise it
<re_irc>
<@firefrommoonlight:matrix.org> Set low, write, set high
<re_irc>
<@firefrommoonlight:matrix.org> Btw, if you only have one SPI device, you can use stm32's hardware CS
<re_irc>
<@yruama_lairba:matrix.org> firefrommoonlight: to late, at the time i did my board i wasn't aware there was a hardware CS pin
<re_irc>
<@firefrommoonlight:matrix.org> Hah. Yea it has to be wired correctly
<re_irc>
<@firefrommoonlight:matrix.org> I never use it since I usually have more than one device
<re_irc>
<@yruama_lairba:matrix.org> i also may use another spi device at some point
<re_irc>
<@firefrommoonlight:matrix.org> It would be cool if hardware CS worked with multiple pins, but unfortunately that's not how it's set up. I'd use it for every project if that were the case
<re_irc>
<@firefrommoonlight:matrix.org> (Maybe other MCUs support multiple/arbitrary hardware CS?)
<re_irc>
<@yruama_lairba:matrix.org> firefrommoonlight: you mean having different CS signal or you mean hability to change the CS pin ?
<re_irc>
<@firefrommoonlight:matrix.org> STM32 has one (hardware) CS pin per line. So, you can't use it with more than one device. If there were sevearl, or if you could use an arbitrary GPIO, it would be more practical
<re_irc>
<@firefrommoonlight:matrix.org> Eg right now you set the AF appropriately on the hardware CS pin, set a field or something to enable, and it uses the prescribed pin. There's only one hardware CS avail per line.
<re_irc>
<@firefrommoonlight:matrix.org> Actually, I haven't thought this through - it would required setting a reg each write you did, so probably wouldn't buy you any simplicity
<re_irc>
<@firefrommoonlight:matrix.org> I see why they only let you use one now
<re_irc>
<@yruama_lairba:matrix.org> firefrommoonlight: i didn't even know it could be CS signal managed by hardware, arduino don't have it, and you can control many device without using it
<re_irc>
<@firefrommoonlight:matrix.org> Here's a description of using it with a SPI master:
<re_irc>
<@firefrommoonlight:matrix.org> > NSS output enable (SSM=0,SSOE = 1): this configuration is only used when the
<re_irc>
<@firefrommoonlight:matrix.org> MCU is set as master. The NSS pin is managed by the hardware. The NSS signal
<re_irc>
<@firefrommoonlight:matrix.org> is driven low as soon as the SPI is enabled in master mode (SPE=1), and is kept
<re_irc>
<@firefrommoonlight:matrix.org> So this assumes you're enabling and disabling SPI each write you do, which I think is not a safe assumption for a number of existing HALs
<re_irc>
<@josfemova:matrix.org> When could we expect a first embassy release? Just curious
<re_irc>
<@bradleyharden:matrix.org> Might want to ask here #embassy-rs:matrix.org
<re_irc>
<@ubik:matrix.org> any clue why my ELF is being generated with no names at all? `nm -C` returns empty
<re_irc>
<@dngrs:matrix.org> dirbaio: yes, can recommend. AT I/O is teh sux
<re_irc>
<@dngrs:matrix.org> adamgreig: yup!
<re_irc>
<@adamgreig:matrix.org> i'm surprised to see it but it's kinda cool
<re_irc>
<@dngrs:matrix.org> thalesfragoso: you need quite a few pins (SPI, CS, busy, Reset) , so an ESP-01 won't do, for example.
<re_irc>
<@adamgreig:matrix.org> ublox hardware is kinda nice even if ublox as a company are kinda annoying
<re_irc>
<@adamgreig:matrix.org> fun that you can buy an esp32 from them for sure
<re_irc>
<@dngrs:matrix.org> I've flashed it on an old LOLIN32-Lite and it works just fine
<re_irc>
<@adamgreig:matrix.org> did they just release the nina firmware open-source?
<re_irc>
<@dngrs:matrix.org> I think it's been open source for quite a while
<re_irc>
<@adamgreig:matrix.org> even nicer
<re_irc>
<@dngrs:matrix.org> first commit Jan 2016
<re_irc>
<@adamgreig:matrix.org> oh weird, I see, the NINA-B1 is an nRF52832, and the NINA-W10 is the ESP-32
<re_irc>
<@adamgreig:matrix.org> I have mostly used ublox's gps modules which are the exact opposite of open
<re_irc>
<@dngrs:matrix.org> I find it interesting how much of a hidden gem this nina stuff is. A year ago I saw someone just posting on stackoverflow that they had "used SPI instead of UART/AT for socket comms" and I thought wow, this person was quite committed to write an entire driver for that. Probably they were using nina but not calling...
<re_irc>
... it by name. I discovered the firmware a few months later by accident, don't even remember how.
<re_irc>
<@adamgreig:matrix.org> yea, sounds way nicer than having to deal with AT over uart
<re_irc>
<@dirbaio:matrix.org> AT is The Sux indeed
<re_irc>
<@dirbaio:matrix.org> I don't get why cell modem companies don't innovate in that
<re_irc>
<@dngrs:matrix.org> there's so many weird things (not) happening. A few years ago I bought a few [RDA5981](https://www.hackster.io/news/the-rda5981-an-esp8266-competitor-da161c9c37e2), thinking "this chip is AWESOME and WTF CHEAP", but they just sit around because the product has apparently been completely abandoned.
<re_irc>
<@thalesfragoso:matrix.org> Oh, one cortex-m with wifi, I actually bought a W600 board very cheap, but their blobs are indivisible from freertos it seems, unfortunately
<re_irc>
<@dngrs:matrix.org> it's such an underwhelming space. Guess nobody really wants to compete with espressif, which strikes me as quite odd, I'd much rather have a single M4F mcu with wifi
<re_irc>
<@thalesfragoso:matrix.org> W600 another chip*
<re_irc>
<@thalesfragoso:matrix.org> Seems like nobody wants to do wifi, so closed