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
<re_irc> < (@adamgreig:matrix.org)> for Rust, you might check out the main Rust space #rust-space:matrix.org (https://matrix.to/#/#rust-space:matrix.org) and #rust-embedded-space:matrix.org (https://matrix.to/#/#rust-embedded-space:matrix.org) which are groups of related rooms
<re_irc> <Tech Guy> I need help with an error, this is the error message
<re_irc> <Tech Guy> https://pastebin.com/Wai9xX9z
<re_irc> < (@jamesmunns:beeper.com)> Tech Guy it looks like:
<re_irc> - are you not setting the "--target" to your embedded target? It looks sorta like it is building for windows
<re_irc> - There's a lot of C++ code in there?
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
genpaku has quit [Remote host closed the connection]
genpaku has joined #rust-embedded
conplan has joined #rust-embedded
<re_irc> <pgibson> Hi all, I'm just starting out with embedded rust (and embassy). I need to upload manufacturer firmware to a sensor (VL53L5CX) but I'm running out of space on the STM32 I'm using, even though the manufacturers demo apps fit fine.
<re_irc> <pgibson> "cargo run --release" reports "rust-lld: error: section '.uninit' will not fit in region 'RAM': overflowed by 816 bytes"
<re_irc> pub const VL53L5CX_FIRMWARE:[u8; 0x15000] = [
<re_irc> <pgibson> I'm storing the firmware like
<re_irc> 0xe0, 0x04, 0x07, 0x68,
<re_irc> 0xe0, 0x04, 0x0f, 0x28,
<re_irc> 0xe0, 0x04, 0x09, 0x68,
<re_irc> <pgibson> But the sensor expects this to be delivered in packets 0x8000 (32768) bytes at a time via i2c
<re_irc> <pgibson> So I'm copying it into an array
<re_irc> data[0..2].copy_from_slice(&reg_buf);
<re_irc> data[2..].copy_from_slice(&VL53L5CX_FIRMWARE[0..0x8000]);
<re_irc> let mut data = [0u8; 0x8002];
<re_irc> <pgibson> Where reg_buf contains the register address
<re_irc> <pgibson> Is there a better way to do this that takes up less RAM? I've been reading about uninitialised arrays, but I'm not sure if the array initilisation is taking up space or not
<re_irc> <pgibson> Is the "const VL53L5CX_FIRMWARE" array automatically stored in flash, or do I need to handle that separately?
<re_irc> <pgibson> The chip I'm using is an STM32F401RE with 512KB Flash and 96KB RAM
<re_irc> <pgibson> * STM32F401RC with 256KB Flash and 64KB
causal has quit [Quit: WeeChat 3.7.1]
<re_irc> < (@dirbaio:matrix.org)> pgibson: try using "static" instead of "const"
<re_irc> < (@dirbaio:matrix.org)> ah but anyway the "data" there has to be in RAM because you're modifying it at runtime, and it's 32k :D
<re_irc> < (@dirbaio:matrix.org)> i2c requires the whole transaction to be in a single contiguous chunk
<re_irc> < (@dirbaio:matrix.org)> that's a shortcoming that should get fixed, for example there's https://github.com/rust-embedded/embedded-hal/pull/392
<re_irc> < (@dirbaio:matrix.org)> that'd allow you to write the 2-byte-header from RAM then the 0x8000 data straight from flash in a single i2c transaction...
<re_irc> < (@dirbaio:matrix.org)> are you sure the chip doesn't accept smaller chunks?
<re_irc> < (@dirbaio:matrix.org)> if it doesn't, as a workaround you can
<re_irc> < (@dirbaio:matrix.org)> +do this
<re_irc> < (@dirbaio:matrix.org)> static CHUNK1: [u8; 0x8002] = [ ... ];
<re_irc> static CHUNK2: [u8; 0x8002] = [ ... ];
<re_irc> i2c.write(addr, &CHUNK1);
<re_irc> static CHUNK3: [u8; whatever is left] = [ ... ];
<re_irc> < (@dirbaio:matrix.org)> "pre baking" the 2-byte header into the "static" :D
<re_irc> < (@dirbaio:matrix.org)> that'll write straight from flash. zero RAM usage.
<re_irc> < (@dirbaio:matrix.org)> (hopefully the header is constant... 😓)
<re_irc> < (@matoushybl:matrix.org)> are non-mutable statics stored in flash?
<re_irc> < (@dirbaio:matrix.org)> yep
<re_irc> < (@matoushybl:matrix.org)> nice, thanks! What would be the issue with using const, would that get inlined somewhere in the code where the constant would be used?
<re_irc> < (@dirbaio:matrix.org)> const is weird, it's roughly equivalent to copypaste the value on every use
<re_irc> < (@matoushybl:matrix.org)> makes sense, thanks!
<re_irc> < (@dirbaio:matrix.org)> so I dunno if it's guaranteed that the value is in flash and never copied to the stack
<re_irc> < (@dirbaio:matrix.org)> if it's a giant array it'd be pretty dumb for the compiler to copy it
<re_irc> < (@dirbaio:matrix.org)> so it probably doesn't...? but I don't think it's guaranteed
<re_irc> < (@dirbaio:matrix.org)> while with statics it is
<re_irc> <pgibson> Thanks I'll give it a try
<re_irc> <pgibson> Yes the header is constant. This is only used when initialising the sensor so I was thinking I just use a 32K array and then let it go out of scope, but I like your idea better
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<re_irc> < (@ryan-summers:matrix.org)> Is there a "no_std" Serializer/Deserializer that encodes a struct following "repr(C)" semantics? I.e encodes u32 as big-endian bytes, only accepts known-sized datatypes etc.
<re_irc> < (@ryan-summers:matrix.org)> I'm looking for something to basically handle encoding and decoding a settings structure for storage in an external EEPROM. The data is pretty basic (i.e. 4 byte array, integers, max-length string)
<re_irc> < (@ryan-summers:matrix.org)> I used to use postcard for this, but the refactor to use varints for everything kind of breaks my use case
<re_irc> < (@jamesmunns:beeper.com)> I know has a new crate specifically for that use case!
<re_irc> < (@jamesmunns:beeper.com)> https://docs.rs/encdec/latest/encdec/
<re_irc> < (@ryan-summers:matrix.org)> Wonderful, will take a look, thanks! :)
<re_irc> < (@jamesmunns:beeper.com)> I should probably start linking to it in the postcard readme. It seems like a really common ask, even though it's not the design direction I want for postcard.
IlPalazzo-ojiisa has joined #rust-embedded
conplan has quit [Remote host closed the connection]
<re_irc> < (@firefrommoonlight:matrix.org)> I'm also still looking for something to abstract serializing. Have been doing a lot of it lately. Saving/loading binary files in non embedded. Embedded uart. uSB serial from MCU to PC. Things get messy making a standard abstraction when the inevitable edge cases happen
<re_irc> < (@firefrommoonlight:matrix.org)> Passing byte arrays to GPU graphics/compute shaders is another one, which includes alignment considerations
<re_irc> < (@firefrommoonlight:matrix.org)> WGPU examples use a crate called Bytemuck for it, but it's IMO too opaque/poorly documented
<re_irc> < (@firefrommoonlight:matrix.org)> Will check out encdec
<re_irc> < (@firefrommoonlight:matrix.org)> At the core of those 4 problems and more, is the unifversalish format of byte arrays, and how to convert those to and from arbitrary data structs
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
<re_irc> < (@firefrommoonlight:matrix.org)> Also relevant to this is if you control both sides of the protocol, or just one
<re_irc> < (@firefrommoonlight:matrix.org)> For all the above, I set and deser manually currently, eg with From impls etc. Assist from the num_enum crate for parsing u8-repr enuma. Explicit and self-contained, but verbose and has inertia
bjc has quit [Remote host closed the connection]
conplan has joined #rust-embedded
conplan has quit [Quit: Leaving.]
conplan has joined #rust-embedded
<re_irc> < (@jamesmunns:beeper.com)> I mean, serde is that? And if you control both sides, postcard is a pretty good bet
<re_irc> < (@jamesmunns:beeper.com)> if you do need something specific, e.g. for interfacing with existing binary formats or line protocols, that's the niche encdec is looking to fill
<re_irc> < (@jamesmunns:beeper.com)> (serde certainly isn't perfect, and there are cases it's a bad match, but it's a damned good tool of first choice for a LOT of things)
<re_irc> < (@jamesmunns:beeper.com)> : Specifically, I have and do use postcard for literally every one of these use cases.
<re_irc> <henrik_alser> Same here
<re_irc> < (@ryan-summers:matrix.org)> Yeah I even used serde to implement the MQTT protocol. Was tricky, but still worked
<re_irc> < (@ryan-summers:matrix.org)> Makes it really easy to update and extend packet structures
<re_irc> < (@ryan-summers:matrix.org)> I just don't want to do a whole serializer/deserializer for a small, 32-byte data structure for EEPROM
<re_irc> < (@firefrommoonlight:matrix.org)> : I'll re eval Serde. There's a reason I haven't been using it, but don't remember the reason or if it's still relevant. I've been using Serde for JSON, but not binary
<re_irc> < (@firefrommoonlight:matrix.org)> Sounds like I should give PC another go too
<re_irc> < (@firefrommoonlight:matrix.org)> I'm not happy with the inertia of doing it manually
<re_irc> < (@jamesmunns:beeper.com)> It's pretty magical to slap "#[derive(Serialize, Deserialize)]" on just about any data type, and boom bam, you have a line format.
<re_irc> < (@jamesmunns:beeper.com)> The postcard spec goes over the core serde data types (what you can model with serde), as well as how postcard does it 1:1 on the wire: https://postcard.jamesmunns.com/
<re_irc> < (@firefrommoonlight:matrix.org)> I should really try it
<re_irc> <henrik_alser> I love it 💌
<re_irc> <henrik_alser> And postcard can also do COBS framing
<re_irc> <henrik_alser> And the CobsAccumulator is really handy
<re_irc> < (@CyReVolt:matrix.org)> Spreading the word: "mold" linker devs looking for feedback
<re_irc> < (@CyReVolt:matrix.org)> titled
<re_irc> mold kernel/embedded programming support plan
<re_irc> < (@CyReVolt:matrix.org)> > The mold linker currently lacks features for kernel or embedded programming. We want to support them. At the same time, we don't want to support the GNU ld's linker script language as it is overly complicated. This document explains what options we are planning to add to the linker as an alternative to linker script support.
conplan has quit [Quit: Leaving.]
<re_irc> <dalepsmith> So does that mean mold will _only_ have command-line options, and no "script" support at all?
<re_irc> <dalepsmith> Or not gnu-ld script format?
<re_irc> <dalepsmith> +just
conplan has joined #rust-embedded
<re_irc> <dalepsmith> Yea, looks like no "script" support at all.
<re_irc> <imdoor> heya, does anyone know whether you can enter any of the arduino sleep modes (e.g., "SLEEP_MODE_PWR_DOWN") using "avr-hal" or anything similar? btw, is this a good place for such questions, or is this channel meant more for the working group stuff?
<re_irc> < (@jwagen:matrix.org)> You might need to configure the sleep mode but sleep can be initiated by
<re_irc> < (@jwagen:matrix.org)> +first
bjc has joined #rust-embedded
<re_irc> <imdoor> any suggestions where to look for how to configure the sleep mode? i'm browsing through "avr_device" but can't quite find anything
<re_irc> < (@9names:matrix.org)> imdoor: This channel is fine, but you might find your question is already answered if you search in #avr-rust_Lobby:gitter.im
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 256 seconds]
<re_irc> <imdoor> ok, thanks!
cr1901_ is now known as cr1901
<re_irc> <the tab openoor (spookyvision@{github,cohost})> it's shameless self promotion o'clock! I'm pretty happy with this hot code reload/VM/questionable sanity project of mine (https://twitter.com/pandora9001/status/1592270814623465472)
IlPalazzo-ojiisa has quit [Quit: Leaving.]
dc740 has joined #rust-embedded
conplan has quit [Quit: Leaving.]
<re_irc> < (@almindor:matrix.org)> what does everyone use for "representation changes" in rust/noheap? I mean things like "I have 3 "u16"s that I need to represent as a "&[u8]" in some order (say big endian on each too)". In C I'd just cast and forget, but with Rust that's extremely unidiomatic, unsafe and just seems wrong. On the other hand I don't want to add another "midrepresentation" memory chunk for this and have the data...
<re_irc> ... duplicated. I thought about using trait/iterator aproach but that only works on singleton cases (coz each iterator is a different implementation/size)
<re_irc> < (@k900:0upti.me)> There's the "byteorder" crate
<re_irc> < (@almindor:matrix.org)> yeah it's not about that though. I also need to transform the internal representation into the bytes e.g. which field goes first etc. I tried going the Iterator/trait route but that requires alloc somewhere since i have a many implementors case (e.g. each trait implementor returns a different iterator type and so I can't generalize those without Box)
<re_irc> <rjmp> Well, there's "core::mem::transmute". Unsafe though.
<re_irc> < (@almindor:matrix.org)> indeed, I could do that with "#[repr(C)]" (so the fields can be "together in memory") but that just seems so wrong :D
<re_irc> < (@almindor:matrix.org)> also in the end I can't just do a pointer thing it needs to be more like an iterator when I do "this byte of this field first, then this one, then this one" in some order
<re_irc> < (@adamgreig:matrix.org)> you can't "just cast" in C if you want to change byteorder, casting would use platform byteorder
<re_irc> <rjmp> Does "u16::to_le_bytes" not give you what you need?
<re_irc> <rjmp> (or to_be_bytes, if you prefer)
<re_irc> < (@adamgreig:matrix.org)> yea, I'd be using to_le_bytes and to_be_bytes to get an array, and either using the three arrays or maybe copying them into a new [u8; 6] if you need them together
<re_irc> < (@adamgreig:matrix.org)> if you can just use the platform byteorder then slice::from_raw_parts can unsafely turn a &[u16] into &[u8], and crates like bytebuck and encdec can handle doing that without you needing to write out "unsafe"
<re_irc> <the tab openoor (spookyvision@{github,cohost})> +1 on stdlib
<re_irc> <the tab openoor (spookyvision@{github,cohost})> and bytemuck
<re_irc> < (@almindor:matrix.org)> yeah, my issue is I need to also go by fields, so e.g. field1 (but in BE order) then field2 (same) and field3(same). In rust iterator terms it could be something like "self.field1.to_be_bytes().into_iter().chain(this.field2.to_be_bytes().into_iter()).chain(self.field3.to_be_bytes().into_iter();" but that's mean I'd have to store the iterator "somewhere"
<re_irc> < (@almindor:matrix.org)> and since i need many of these (each with different logic) but unified in the "give me u8 list to send over" I can't use this without heap
<re_irc> < (@adamgreig:matrix.org)> that seems very convoluted