<re_irc>
< (@k900:0upti.me)> Not that you're going to notice
<re_irc>
<Félix the Newbie> Alright, I'll go for the easiest solution, then ;)
madb_ has quit [Quit: Leaving]
madb has joined #rust-embedded
madb has quit [Changing host]
madb has joined #rust-embedded
<re_irc>
<thejpster> I mean, it depends if you have rules you need to uphold. For example, if the rule is "only one LED can be on", then you need the first option. Because otherwise updating three separate atomic variables is not, as a whole, an atomic operation, and someone else could observe the invalid state of both BLUE and GREEN being enabled. Also three variables uses three times as much memory.
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
madb_ has joined #rust-embedded
madb has quit [Ping timeout: 252 seconds]
madb__ has joined #rust-embedded
madb_ has quit [Ping timeout: 256 seconds]
madb__ has quit [Quit: Leaving]
madb__ has joined #rust-embedded
madb__ has joined #rust-embedded
madb__ has quit [Changing host]
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, JP nailed the caveats. If they don't matter to you, then no worries. For more complex stuff you might.
madb__ is now known as madb
<re_irc>
<Félix the Newbie> thejpster: Thanks. It doesn't matter at all, those LEDs are keyboard indicators. Also, I think I don't really care about 2 bytes more of memory. I don't really know the CPU cost of updating 1 atomic variable, that was my main concern. I know it's not costly on a “regular“ CPU, but I don't know how costly it is on a cortex m.
<re_irc>
< (@k900:0upti.me)> On embedded atomics are basically no-ops since there's no threads anyway
<re_irc>
< (@ryan-summers:matrix.org)> That's not true
<re_irc>
< (@ryan-summers:matrix.org)> Interrupt priorities and ISRs are very equivalent to threads in respect to variable access
<re_irc>
< (@k900:0upti.me)> I don't think you can hit an interrupt in the middle of a load/store though?
<re_irc>
< (@ryan-summers:matrix.org)> You can cache variables in registers in functions, which is different than the RAM repr
<re_irc>
< (@k900:0upti.me)> At least for register sized values
<re_irc>
< (@jamesmunns:beeper.com)> : For stores/loads it's just STR/LDR, but for fetch_add and stuff STREX/LDREX and CAS loops are used
<re_irc>
< (@jamesmunns:beeper.com)> (on cortex m at least)
<re_irc>
< (@jamesmunns:beeper.com)> And yeah, for devices with cache, there might be runtime/compile time fences/barriers, like dmb
<re_irc>
< (@ryan-summers:matrix.org)> Hmm, I think I was thinking more about a shared resource vs. atomic access. Atomics are nice if you're e.g. checking a boolean flag
<re_irc>
< (@jamesmunns:beeper.com)> (my client doesn't support them, but I think the main element web/desktop client does)
<cr1901>
jamesmunns (yes, another postcard q, I'm sorry): Because postcard is not self-describing, should a data structure crate on top of postcard pin its deps to exact versions (or bugfixes only)?
<cr1901>
It just occurred to me that even adding private fields can break serialization w/o breaking semver
<cr1901>
(THIS WAS SUPPOSED TO BE A SIMPLE CRATE, DAMNIT!)
<re_irc>
< (@jamesmunns:beeper.com)> technically changes to structs that impl Ser/Deser SHOULD be breaking changes, but not all crates are great at that
<re_irc>
< (@jamesmunns:beeper.com)> so - yes, that might help, it might be a little "extra"
<cr1901>
I'll look at my options using the Cargo.toml dep syntax
<re_irc>
<dngrs (spookyvision@{github,cohost})> cr1901: That's actually a great point
<re_irc>
< (@jamesmunns:beeper.com)> for reference: you _SHOULD_ isolate ser/de "wire types" from your internal/in-memory structs if you ever plan to (or do) change them.
<cr1901>
That would be great is Deser/Ser wasn't such a PITA to impl manually
<cr1901>
Like this is a weakness to the derive macros, but I at least _understand_ why ppl use them
<re_irc>
< (@jamesmunns:beeper.com)> My suggestion would be to impl From between the "InternalType" and the "WireType"
<re_irc>
< (@jamesmunns:beeper.com)> and DON'T impl ser/de on the internal type
<cr1901>
I still am at the mercy of any external crates deser impls I depend on. Or are you saying "impl Ser/De manually for the WireType"?
<cr1901>
(And forego any de/ser impls that external crates provide?)
<re_irc>
< (@jamesmunns:beeper.com)> Oh, sorry, I'm talking "best practices", for the folks out there. Practically, pinning exact deps is likely fine for you
<cr1901>
I kinda want to test-drive the schema support for forwards-compat (old versions of the crate can tolerate newer versions of the data)
<cr1901>
and well, backwards-compat too (new versions of the infomem crate can tolerate old versions of the infomem data)
<re_irc>
< (@jamesmunns:beeper.com)> atm, I don't THINK there's any way to use the schema support other than verifying the schema matches (and that would be tricky and I don't know how)
<re_irc>
< (@jamesmunns:beeper.com)> I have _ideas_ for how to make a "self describing postcard format", that involves the schema, but it's napkin sketches at the moment.
<cr1901>
You had a match clause a few days ago where the semver is deserialized, and "do something different" based on which semver was found
<re_irc>
< (@jamesmunns:beeper.com)> (if you ever actually move over to matrix cr1901, come hang out in the Anachro room, I talked about it a lot there)
<re_irc>
< (@jamesmunns:beeper.com)> ohhh
<re_irc>
< (@jamesmunns:beeper.com)> yeah, you could do that, I'm not sure how the schema would help you though, other than detecting when you need to add a new supported variant.
<cr1901>
Yea, I thought you could answer that part :P. Uhhh, I wanted to deserialize only that field specially, and defer to a version-specific deser otherwise
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, that gets back to the thing I was talking about the other day about making your "root type" basically: "(String, Metadata)"
<re_irc>
< (@jamesmunns:beeper.com)> because you can always deser just the "String" first, which wouldn't touch the "Metadata" part until you know how you can handle it.
<re_irc>
< (@jamesmunns:beeper.com)> and if you use "take_from_bytes", the "remainder" will be just the "Metadata" part.
<cr1901>
(I thought a Slice's remainder was &[u8]?)
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, if you have the "original" slice as "[S1, S2, S3, ..., SN, M1, M2, ..., MN]", where "Sx" are string bytes, and "Mx" are Metadata bytes
<re_irc>
< (@jamesmunns:beeper.com)> and you call "take_from_bytes::<String>(slice)", the remainder you get back will just be the "[M1, M2, ..., MN]" part.
<re_irc>
< (@jamesmunns:beeper.com)> (even if you originally serialized it as "(String, Metadata)")
<cr1901>
Ahhh, in other words, don't Serialize the version as part of the Infomem struct proper, but rather as a preceding data
<re_irc>
< (@jamesmunns:beeper.com)> I mean, "struct { a: String, b: Metadata }" is the same as "(String, Metadata)" to postcard
<cr1901>
Hmmm, well, I could Deser as: (Semver, rest), and then Deser rest as (UserInfo, RustcInfo), and then create the proper InfoMem struct from that
* cr1901
may drop the forward compat requirement
<cr1901>
Did I mention that this was supposed to be easy?
<cr1901>
FWIW, I don't really want postcard to be self-describing. I'd rather there be resources to help with the fact that some ser formats are _not_ self-describing
<re_irc>
< (@jamesmunns:beeper.com)> "self describing postcard" would be separate from "today's postcard".
<re_irc>
< (@jamesmunns:beeper.com)> Ideally a "self describing postcard message" would be "the normal postcard part" and "the metadata part"
<cr1901>
I don't follow what you mean; the "normal postcard part" wouldn't be able to describe what "the metadata part" has, correct?
<cr1901>
jamesmunns: To be clear, I like postcard a lot. I'm bitching not at you or postcard, but b/c once again something I thought was gonna be easy wasn't.
<cr1901>
You'd think I learn by now
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, this is getting pretty off topic for this room, but ideally "the metadata part"more or less contains all the field/type names, and instructions on how to "unpack" the non-self-describing "normal postcard part"
<re_irc>
< (@jamesmunns:beeper.com)> Rather than something like CBOR, which has the "instructions" inline/encoded as part of the format.
* cr1901
nods
madb has quit [Ping timeout: 260 seconds]
<re_irc>
< (@datdenkikniet:matrix.org)> Hmm, how do I add variants to a field added by a patch in "svdtools"?
<re_irc>
< (@datdenkikniet:matrix.org)> is what I have ATM
<re_irc>
< (@datdenkikniet:matrix.org)> but wherever I choose to place the variants ("Ethernet_PTP.PTPPPSCR.PPSFREQ.<Variants>", "Ethernet_PTP.PTPPPSCR._add.PPSFREQ.<Variants>") it doesn't seem to want to add any variants
<re_irc>
< (@datdenkikniet:matrix.org)> it does generate the "PPSFREQ"
<re_irc>
< (@datdenkikniet:matrix.org)> +field
<re_irc>
< (@datdenkikniet:matrix.org)> or should the variants go in their own, separate "peripherals/blahblah.yaml" file...
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
<re_irc>
< (@datdenkikniet:matrix.org)> Nevermind, I was looking at the wrong output file...
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<cr1901>
>`DefaultHandler_' referenced in expression which cortex-m crate provides DefaultHandler?
<re_irc>
< (@jamesmunns:beeper.com)> DefaultHandler is the default interrupt/exception handler function
<cr1901>
So which crate provides it so I can make the linker stop bitching?
<re_irc>
< (@jamesmunns:beeper.com)> Do you have "cortex-m-rt" and "cortex-m", and if so, do you have the device feature turned on?
<re_irc>
< (@jamesmunns:beeper.com)> (or a hal that does that?)
<cr1901>
rp2040-hal = { version = "0.7.0", optional = true, features = [ "rt" ] }
<cr1901>
[target.thumbv6m-none-eabi.dependencies]
<cr1901>
cortex-m-rt = "0.7.2"
<cr1901>
panic-halt = "0.2.0"
<re_irc>
< (@jamesmunns:beeper.com)> can you post a gh link? might be faster
<re_irc>
< (@wucke13:matrix.org)> I'm on a platform where for some reason bss is not set to zero. What would be a quick hacky way to zeroize it in rust, that I can put into the entry function
<re_irc>
< (@jamesmunns:beeper.com)> : what platform? That's usually done by the "rt" crates, like "cortex-m-rt" or "riscv-rt"
<re_irc>
< (@ithinuel:matrix.org)> If you enable "rt" on "rp2040-hal" it'll enable the cortex-m-rt crate.
<re_irc>
< (@adamgreig:matrix.org)> cr1901: have you got -Tlink.x set too?
<re_irc>
< (@jamesmunns:beeper.com)> you might need "use rp2040_hal as _;"
<re_irc>
< (@adamgreig:matrix.org)> : the "entry" function, if you have one, is usually provided by the same rt crate that zeros bss though, so if your bss isn't zeroed it's probably something going wrong, like a bad memory.x or an extra memory section or a bug in the rt crate or something
<cr1901>
jamesmunns: That was it
<re_irc>
< (@wucke13:matrix.org)> : Unfortunately the surrounding construct is proprietary software written in C that I do not have the source code. Hence the hacky workarround approach of just fixing what I know to be wrong afterwards, once my Rust code is in charge.
<re_irc>
< (@jamesmunns:beeper.com)> cr1901 if you don't "use" a crate it won't get linked in
<re_irc>
< (@jamesmunns:beeper.com)> (and all of its recursive deps)
<cr1901>
This bit me earlier in the same file: "use msp430g2553::interrupt as _;"
<re_irc>
< (@adamgreig:matrix.org)> something's going badly wrong if your bss isn't 0, and overwriting it in entry is probably not a good plan
<cr1901>
interrupt includes the interrupt struct, without which the vectors won;t be populated
<re_irc>
< (@adamgreig:matrix.org)> if you have C code doing platform initialisation, it must be zeroing bss for the C< and your rust variables should be in that same bss section
<re_irc>
< (@adamgreig:matrix.org)> unless you have some really special case thing like the C is bootloading some snippet of rust that's not linked in with it?
<re_irc>
< (@adamgreig:matrix.org)> what architecture is it? it's UB to just write all the statics from within rust, but you could copy the assembly snippet from cortex-m-rt if you're on cortex-m.... but if you're on cortex-m and using cortex-m-rt, it will zero bss for you already, so
<re_irc>
< (@wucke13:matrix.org)> : This is armv7a I believe
<re_irc>
< (@adamgreig:matrix.org)> ah, that's more fun then
<re_irc>
< (@adamgreig:matrix.org)> any other details of how exactly your code comes to be running?
dne has quit [Remote host closed the connection]
<re_irc>
< (@adamgreig:matrix.org)> if whatever calls your code isn't also zeroing bss and loading values into the other statics, you'll need to do that sort of runtime initialisation yourself, and the only non-UB way to do that from rust is with assembly, but if you're just desperate to do something for now you could use the (deprecated, archived) "r0" https://crates.io/crates/r0 crate too
<re_irc>
< (@wucke13:matrix.org)> : My code is a partition to the XNG separation kernel running withing the LithOS runtime environment. There is a custom linker script from the kernel, that combined with firmware blobs is compiled into a partition image. The Rust code is started using a normal function symbol.
<re_irc>
< (@adamgreig:matrix.org)> your linker script will need to cooperate at least enough to tell you where bss and data start/stop
dne has joined #rust-embedded
<re_irc>
< (@adamgreig:matrix.org)> what do people normally do with e.g. C code?
<re_irc>
< (@adamgreig:matrix.org)> if the Rust code is started by a function symbol, does the kernel load it from an object archive like an elf file, rather than the raw binary?
<re_irc>
< (@wucke13:matrix.org)> : I think it does so. I also don't really understand why, but the behavior is clear, statics that are zero initialized (and thus land in the bss) have completely random values after boot, statics initialized with any value come up just fin
<re_irc>
< (@wucke13:matrix.org)> * fine
<re_irc>
< (@adamgreig:matrix.org)> you'd really hope it would initialise memory for you in that case but I don't know anything about xng...
<re_irc>
< (@adamgreig:matrix.org)> huh, so it _is_ loading .data into ram but just not zeroing bss? very odd
<re_irc>
< (@adamgreig:matrix.org)> maybe it's somehow something wrong with the linker script or sections or something so your bss variables are ending up in a different section to what the kernel expects to zero
<re_irc>
< (@jamesmunns:beeper.com)> it would be interesting to see if a C example has the same issue
<re_irc>
< (@wucke13:matrix.org)> : Linker magic is used for that, in the end the partition ends up as a binary where the actual entry function just ends up at a known offset from the address where the first byte of the bin is loaded to in RAM
<re_irc>
< (@adamgreig:matrix.org)> you might have better luck asking in an xng chat specifically, my best guess is somehow it should be zeroing bss for you, it's very very weird for it to load statics but not zero them and expect you to do that
<re_irc>
< (@adamgreig:matrix.org)> how does the kernel know where your data and statics are then?
<re_irc>
< (@adamgreig:matrix.org)> oh, just a thought, have you checked if _mutable_ statics get the right value loaded?
<re_irc>
< (@adamgreig:matrix.org)> it might be you're only examining ".rodata" statics, which don't need runtime loading at all, they just live next to the code
<re_irc>
< (@wucke13:matrix.org)> : I will check that next week for sure 😄
<re_irc>
< (@wucke13:matrix.org)> : It really doesn't, only the partition itself knows about the particular details of its own memory
<re_irc>
< (@wucke13:matrix.org)> : No, why would they differ in behavior?
<re_irc>
< (@adamgreig:matrix.org)> ah ok, so it sounds more like a regular embedded firmware which just gets "started" and has to handle its own initialisation, then
<re_irc>
< (@jamesmunns:beeper.com)> oh, so you might need to provide your own entrypoint equivalent to "crt0.s"
<re_irc>
< (@adamgreig:matrix.org)> if you have "static X: u32 = 12;", that lives in ".rodata", next to ".text" which is your code, and is never loaded into RAM, it's just read from the same memory space as code when required
<re_irc>
< (@wucke13:matrix.org)> : Yeah I was wondering about that as well, but grasping from the example makefiles with C code there doesn't seem to be anything like that in it.
<re_irc>
< (@adamgreig:matrix.org)> if you have "static mut X: u32 = 12;", the "12" lives in the binary and is then loaded into RAM by the runtime initialisation, so that you can mutate it later
madb has joined #rust-embedded
<re_irc>
< (@jamesmunns:beeper.com)> : uhh, what is the actual name of the rust entrypoint you are defining?
<re_irc>
< (@adamgreig:matrix.org)> if you have "static mut X: u32 = 0;", the 0 isn't stored anywhere, but it's placed into ".bss" in RAM and zero-initialised by the runtime initialisation
<re_irc>
< (@wucke13:matrix.org)> : The value that I encountered this was actually a "static mut", I forgot to mention
<re_irc>
< (@adamgreig:matrix.org)> (all section names are typical examples, linker scripts could do different things if they wanted to...)
<re_irc>
< (@adamgreig:matrix.org)> I see.... so ..... how did it possibly get the right value
<re_irc>
< (@adamgreig:matrix.org)> assuming you do actually mutate it so it can't be getting optimised into a non-mut static?
<re_irc>
< (@wucke13:matrix.org)> : funnily enough its a called "main", so I resorted to having a staticlib crate with an "extern "C" pub fn main()" that is not mangled :D
<re_irc>
< (@adamgreig:matrix.org)> seems very mean to make you call the entrypoint "main" but you have to do your own initialisation
<re_irc>
< (@adamgreig:matrix.org)> usually that would be called "start" or "_start" or something
<re_irc>
< (@jamesmunns:beeper.com)> huh, usually there's like an "_entry" or "_start" or whatever that is the "real" entrypoint
<re_irc>
< (@adamgreig:matrix.org)> "main" is for once memory has been set up imo :P
<re_irc>
< (@wucke13:matrix.org)> : When its initialized with a non zero value its in .data, not .bss, right? And that totally works, just everything in .bss has random values (instead of the desired zero)
<re_irc>
< (@adamgreig:matrix.org)> is your whole firmware loaded into and executed from RAM?
<re_irc>
< (@adamgreig:matrix.org)> possibly you don't actually need to initialise .data into ram in that case
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, but the code that "inits bss" and "inits data" is usually the same code
<re_irc>
< (@wucke13:matrix.org)> : I believe so
<re_irc>
< (@adamgreig:matrix.org)> ah, ok, that would explain the non-zero statics being correct then
<re_irc>
< (@jamesmunns:beeper.com)> ah, it might be doing something clever with mapping, yeah
<re_irc>
< (@adamgreig:matrix.org)> not even clever, it's just normal for things being run from ram I expect
<re_irc>
< (@wucke13:matrix.org)> The entire code has to be PIE, so I'm rather sure they just copy the bin to a memory region and "set pc" into it
<re_irc>
< (@adamgreig:matrix.org)> on "typical" embedded microcontrollers, the binary image loaded to the flash memory contains the values for the (mutable) statics, but they need to be copied into ram at startup because the statics have to live in ram to be modified
<re_irc>
< (@adamgreig:matrix.org)> but in your case, the linker script doesn't need to do this, it can just place all the statics in .data and the kernel will load them for you when it copies the whole thing into ram
<re_irc>
< (@adamgreig:matrix.org)> so yea, I guess you just need to zero bss then
<re_irc>
< (@adamgreig:matrix.org)> does the linker script have something like "_sbss" and "_ebss" or other start-bss/end-bss symbols defined?
<re_irc>
< (@adamgreig:matrix.org)> (or "bxj" to swap to jazelle!!)
<re_irc>
< (@jamesmunns:beeper.com)> lmao
<re_irc>
< (@adamgreig:matrix.org)> but I think you can just write that assembly in arm mode anyway, maybe except stm?
<re_irc>
< (@adamgreig:matrix.org)> stm is in armv7a too actually so it probably just builds fine either way
<re_irc>
< (@wucke13:matrix.org)> Ok, thank you two a lot! I take with me:
<re_irc>
1. try if the same behavior is seen with statics in C, to check that this is not a bug introduced by my crude makefile transformations
<re_irc>
2. if it does show with C as well, try manually initializing bss, expecting potential breakage due to overwriting any other statics that have been initialized previously
<re_irc>
3. in case of breakage, call the kernel vendor and yell at them politely
<re_irc>
< (@adamgreig:matrix.org)> I wouldn't expect breakage from initialising bss yourself, because it should not touch other statics (which are in .data not .bss)
<re_irc>
< (@jamesmunns:beeper.com)> fourth option (if C works) is "just make a staticlib, link it to a C file that calls rust main"
madb_ has quit [Ping timeout: 256 seconds]
<re_irc>
< (@adamgreig:matrix.org)> but yea, it would be good to understand whether C code is expected to initialise bss itself or if that's somehow getting done for it
<re_irc>
< (@adamgreig:matrix.org)> still it shouldn't be _hard_ to initialise it yourself in rust, it's just worth checking you are indeed meant to do so
<re_irc>
< (@wucke13:matrix.org)> : Oh no, yet another step in this 8 step build procedure 😥
madb_ has joined #rust-embedded
<re_irc>
< (@dequbed:chaosfield.at)> : my knowledge of XNG is very limited, but with ELF the kernel doesn't even know what segments it would need to zero and zeroing .bss is (usually, there are more asterisks here than letters because linking and loading is, simply put, a _mess_) entirely the job of the application.
<re_irc>
Also, gcc especially has a command line parameter to make it not expect a zeroed .bss. If you're handed a working C toolchain and that flag is used then uh, good luck I don't think that the rustc has such a flag at the moment.