<re_irc>
<firefrommoonlight> This is cutting back on my HAL feature-gates and comments substantially
<re_irc>
<firefrommoonlight> Errata too
Lumpio- has quit [*.net *.split]
Lumpio- has joined #rust-embedded
GenTooMan has quit [Ping timeout: 256 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #rust-embedded
nohit has quit [*.net *.split]
edm has quit [*.net *.split]
edm has joined #rust-embedded
nohit has joined #rust-embedded
GenTooMan has quit [Excess Flood]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 260 seconds]
GenTooMan has joined #rust-embedded
jr-oss has quit [Ping timeout: 268 seconds]
jr-oss has joined #rust-embedded
<re_irc>
<dwagenk> I liked ceedling when doing C unit testing. Grennings Book is a good read!
GenTooMan has quit [Ping timeout: 264 seconds]
GenTooMan has joined #rust-embedded
gsalazar has joined #rust-embedded
fabic_ has quit [Ping timeout: 240 seconds]
<re_irc>
<heksa> Jan Bronicki: We use Renode in our university as an alternative to QEMU. Works well for C & Rust. The full instruction set translation and clean virtual machines makes it need very little setup. We design hardware mostly at the lab so it's nice to have a more or less "ideal" execution environment to reference.
<re_irc>
<heksa> You occasionally miss a kind of a full reference documentation, where you could find lists of all supported commands, parameters and features. But it's mostly intuitive enough at least for low-effort + lots of value virtual prototyping.
<re_irc>
<richarddodd> I've been meaning to ask - does anyone know any v good intro electronic engineering books for programmers. Like, I'm pretty advanced when it comes to how computers work at a logical level, but no necessarily at a physical level (by which I mean, I understand how a latch works, but not how emf from a nearby component my damage/break it). I'd like to be able to design simple gadgets with programmable ICs, and want to...
<re_irc>
... avoid problems like with PineTime drawing quite a lot of power on idle, because (as I've been told) it hasn't wired up the MCU well for low power consumption on sleep, and the pullup resistor for the main on/off button is fairly low and so leaks a relatively large amount of current.
<Lumpio->
They made a /watch/ with poor power management? Ouch
<re_irc>
<K900> How simple are you talking?
<re_irc>
<richarddodd> Like, I know how components like opamps work. I'm interested in how to but them together to make circuits that do what I want, and also to avoid physical problems with designs like emf interference, when you need surge protection etc.
<re_irc>
<richarddodd> How to work out from a component's datasheet what I need to do to integrate it into my design.
<re_irc>
<richarddodd> Lumpio-: It's not terrible - the battery lasts for 4 days on idle. It could be much longer though.
<re_irc>
<Mehmet Ali> richarddodd: I think the Art of Electronics is a good candidate. It omits theory for the sake of completeness, and generally includes it as an insight in parallel with hands on examples.
<re_irc>
<Mehmet Ali> I abhorred it during college, when I was more of a person that valued a ground up construction of things.
<re_irc>
<Mehmet Ali> But now I feel it would be my choice.
<re_irc>
<richarddodd> Thanks, I'll take a look.
<re_irc>
<dwagenk> richarddodd: I'm in a similar spot. Just made my second PCB and I'm always oscillating between far too much thought on small details and making beginners mistakes.
<re_irc>
I've recently watched Phil's Labs (Youtube Channel) "Mixed Signal Design Course" (that one is not on youtube and not free), which helped a lot. Grounding and thinking about signal paths takes a lot of space in his explanations...
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 264 seconds]
GenTooMan has joined #rust-embedded
<re_irc>
<Mehmet Ali> Is there a good crate that would help me parse a byte array in chunks?
<re_irc>
<Mehmet Ali> I mean I can hop around in a loop, but there might be a better way
<re_irc>
<James Munns> What kind of parsing?
<re_irc>
<James Munns> You might be interested in nom, if you'd like a parser combinator
<re_irc>
<James Munns> There's also https://docs.rs/bytemuck/latest/bytemuck/, if the data is always in one specific format (and you don't have to do any "branching" based on the info you get)
<re_irc>
<James Munns> bytemuck is for cases where you can "cast" your bytes into a struct (and back), like if you used repr packed + pointer casting in C :p
<re_irc>
<Mehmet Ali> Yes, that was the case.
<re_irc>
<Mehmet Ali> These will work great!
<re_irc>
<Mehmet Ali> Thanks.
<re_irc>
<Mehmet Ali> Looking at scroll now.
<re_irc>
<timokrgr> `zerocopy` is another similar crate
gsalazar has quit [Ping timeout: 246 seconds]
<re_irc>
<monacoprinsen> Error: ".defmt" section found, but no version symbol - check your linker configuration
<re_irc>
<monacoprinsen> anyone else got this error before?
<re_irc>
<monacoprinsen> while using probe-run
<re_irc>
/ IMU readings buffer. 3 accelerometer, and 3 gyro measurements; 2 bytes each. 0-padded on the left,
<re_irc>
// in the write buffer.
<re_irc>
<firefrommoonlight> Impl I've been using:
<re_irc>
// since that's where we pass the register
<re_irc>
<firefrommoonlight> Overall, quite similar
<re_irc>
<firefrommoonlight> The main diffs are I'm using "from_be_bytes()" instead of manual bit arith (I'm on the fence about which I prefer TBH, since manual arith is more universal, while the methods are terser). And I'm returning results in radians and m/s^2 instead of portions of the IMU's max configured value
<re_irc>
<firefrommoonlight> *Also i16 vs u16
<re_irc>
<firefrommoonlight> Here is also where James and I vehemently disagree about pulling in deps for something like this
<re_irc>
<firefrommoonlight> Impl I've been using:
<re_irc>
// since that's where we pass the register in the write buffer.
<re_irc>
// IMU readings buffer. 3 accelerometer, and 3 gyro measurements; 2 bytes each. 0-padded on the left,
<re_irc>
<James Munns> ¯\_(ツ)_/¯
<re_irc>
<bugadani> that is like 3 steps from Postcard, isn't it? :)
<re_irc>
<bugadani> * Postcard some flavor of serde,
<re_irc>
<bugadani> * ~Postcard~
<re_irc>
<James Munns> You probably could tweak postcard to work with that format, but that would be an "off-label" usage, which means it might be a little fiddly
<re_irc>
<dirbaio> postcard/serde are nicer when you're fine adopting its wire format because you're going to use it on both sides
<re_irc>
<dirbaio> if your hardware already specifies the wire format it's best to parse it manually
<re_irc>
<dirbaio> or with repr(c) structs at most
<re_irc>
// IMU readings buffer. 3 accelerometer, and 3 gyro measurements; 2 bytes each. 0-padded on the left,
<re_irc>
<firefrommoonlight> Impl I've been using:
<re_irc>
// since that's where we pass the register in the write buffer.
<re_irc>
<firefrommoonlight> Another style thing you could debate is if you impl "From[u8;13]" or w/e instead of normal methods like we both used
<re_irc>
<firefrommoonlight> * "From<[u8;13]>"
<re_irc>
<firefrommoonlight> * "From<&[u8;13]>"
<re_irc>
<firefrommoonlight> Adv: Standard API across the language. Disadv: More verbose
<re_irc>
<dirbaio> from/into impls are hard to discover in docs or autocomplete. if it's something "important" I always try to make it a method (and maybe also have the From impl, but not only)
<re_irc>
<firefrommoonlight> I buy that
<re_irc>
<firefrommoonlight> I wish that sort of thing was fixed on a Rust-docs level. Language wide
<re_irc>
<firefrommoonlight> It's one of the reasons I use traits cautiously
<re_irc>
<firefrommoonlight> Makes docs unusable
<re_irc>
<dirbaio> rustdoc shows the impls buried in "trait implementations", mixed with lots of generic gobledygook :D
<re_irc>
<firefrommoonlight> Yea
<re_irc>
<dirbaio> same with embedded-hal traits, I don't like that HALs impl _only_ the traits and have no inherent methods to do the stuff
<re_irc>
<firefrommoonlight> I inadvertently was thinking of another docs/trait gripe, where when an arg is a trait impl instead of concrete type, it's not obvious how you use the API
<re_irc>
<dirbaio> - hard to discover in docs
<re_irc>
- you have to import the traits to call the methods
<re_irc>
<firefrommoonlight> Same - if you look at the HALs that use EH as the only API, their corresponding docs pages are unhelpful (I think some have moved away from that?)
<re_irc>
<firefrommoonlight> I agree that the import req on Traits is another reason they're not friendly, although thats' separate from the 2 docs issues
<re_irc>
<firefrommoonlight> I think some libs handle that with a prelude, which is also not great since it can hide things
<re_irc>
<dirbaio> oh yeah
<re_irc>
<dirbaio> the prelude is gone in EH1.0 anyway
<re_irc>
<dirbaio> hopefully it pushes HALs to move away from using preludes
<re_irc>
<firefrommoonlight> From what I've seen in various domains of Rust, people are less accepting of preludes than used to be the case
<re_irc>
<firefrommoonlight> Saw something similar in python, re anonymous imports
<re_irc>
<firefrommoonlight> same reasoning
<re_irc>
<firefrommoonlight> It's a nightmare in C since it's all they have!
<re_irc>
<almindor> I never understood why preludes are even a thing
<re_irc>
<newam> Glob imports just give me flashbacks to my days at a python / kotlin developer.
<re_irc>
Fewer footguns with glob imports in rust, but it just makes me feel anxious seeing them.
<re_irc>
<newam> * as
fabic_ has quit [Ping timeout: 256 seconds]
Amadiro__ has joined #rust-embedded
<re_irc>
<adamgreig> stm32-rs PACs v0.15.1 released 😅
Amadiro_ has quit [Ping timeout: 240 seconds]
crabbedhaloablut has quit [Remote host closed the connection]