<GuineaWheek[m]>
<DanielakaCyReVol> "Do you know more crates implemen..." <- i mean you can go look at it and the forks; that particular synopsys USB IP block that's all over stm32s and chinese clones of stm32s is probably one of the best supported IP blocks atm. The crate works it's just had its maintainers be AFK
<GuineaWheek[m]>
(and the fix for gd32vf103 is relatively simple it's just in a forever-dead PR)
<M9names[m]>
that crate might be a good candidate for moving into rust-embedded-community so they can provide caretaker maintenance
<ian_rees[m]>
<Farooq> "So today I brought out my DEC 33..." <- FWIW, I like my Brymen BM869s - had it several years and does more than I need
_whitelogger has joined #rust-embedded
<dcz[m]>
<M9names[m]> "that crate might be a good..." <- how does that work? I see a bunch of crates that would benefit from more active maintenance
<ian_rees[m]>
I'm keen to help out with usb-device, seems like it would be good to have a few folks actively involved (ideally using it for different things)
<Farooq>
<ian_rees[m]> "FWIW, I like my Brymen BM869s..." <- mate that's over 200 bucks
<Farooq>
aren't these 20-40 USD ones good?
<Farooq>
hmm maybe you folks are too pro
<Farooq>
I'm just getting started :)
<ian_rees[m]>
I guess everything's relative, the Brymen's quite good value compared to eg a similar spec Fluke
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
The very cheap ones will measure voltage and current fine
<i509vcb[m]>
I however think the tips on really cheap meters are kind of sad
<i509vcb[m]>
And I would not trust the safety ratings on those at all
<i509vcb[m]>
Do not stick your $20 meter's probes into an outlet
<Farooq>
of course
<Farooq>
I don't want to work with high voltages or currents
<ian_rees[m]>
some of the Uni-T stuff is decent, my toolbox (as in, fix the car/house/whatever) one is a DC clamp meter that IIRC was in that ~US$40 range
<Farooq>
the voltages I work with are 0-19 V
<Farooq>
s/0/1/
<Farooq>
low power stuff
<Farooq>
I probably even won't need AC
<ian_rees[m]>
Farooq: yeah, I pretty regularly poke around with mains etc
<Farooq>
I think it's my bad. I had to explain my requirements
<i509vcb[m]>
Yeah for that as long as you aren't scraping the literal bottom of the barrel to save a few cents practically anything will work
<Farooq>
So yeah I need DC volt meter 1-40 V, amper meter 0-5 A, ohm meter, diode tester and I need to learn pins of tranistors
<ian_rees[m]>
the eevblog forum has a bunch of info on meters, electronics gear is a rabbit hole that some folks quite enjoy
<Farooq>
but first how can I check if my current DEC multi meter can be fixed?
<i509vcb[m]>
ian_rees[m]: good reference for sure, but I feel a lot of the info there is only going to make most people have a blinding amount of choice and arguments over things that practically don't matter
<Farooq>
Farooq: some segments of its seven segment don't light up
<Farooq>
I can open it up but what am I looking for?
<Farooq>
* I can open it up but what should I be looking for?
<i509vcb[m]>
Its like trying to pick a Linux distro in many ways
<ian_rees[m]>
clamp meters are surprisingly handy for diagnosing/fixing stuff that might be a bit peripheral to electronics hobby but IME tinkering is a great way to learn and apply skills
rafael[m] has joined #rust-embedded
<rafael[m]>
Farooq [Master Potato] I am pretty happy with JM-G3401, below 20€. Hobbyist here. Got additional cables from banana to alligator and banana to Dupont pin/slot on top, also very inexpensive. Do not expect wonders, but for my also beginner needs it does the job.
sroemer has joined #rust-embedded
sroemer has joined #rust-embedded
<M9names[m]>
<dcz[m]> "how does that work? I see a..." <- The mission statement for r-e-c explains it better than I could:
TiagoManczak[m] has quit [Quit: Idle timeout reached: 172800s]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
<Farooq>
Now my DEC 330 does not display anything :D
<Farooq>
but there wasn't any soldering or pin for the display
<Farooq>
there was something soft below it which was connected to pads on the main board
jsolano has quit [Quit: leaving]
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
RobinMueller[m] has quit [Quit: Idle timeout reached: 172800s]
<therealprof[m]>
<Farooq> "So yeah I need DC volt meter 1-4..." <- Just FYI (since we're on an embedded channel): Cheap meters typically suck when it comes to measuring low currents <100mA (and no, not even talking about tracing the sleep currents of MCUs here, just regular home gamer stuff), they're inaccurate **and** have a high burden voltage which skews measurements even more.
Ralph[m] has joined #rust-embedded
<Ralph[m]>
i'm no expert on multimeters, but for what it's worth i got a Voltcraft VC190 SE (i just realised that they don't make/sell them anymore and there's a much nicer looking new generation now available... luckily i don't feel compelled to replace mine in the next few years/decades 😅) and i think they're a pretty decent device for the price (i paid ~70$ back then for it and it covers all my needs). the times where i had a fluke in my
<Ralph[m]>
hands i wasn't sure what would make them better now for the standard things i was/am doing.
<therealprof[m]>
For usual embedded stuff you want to be able to at least be able to measure currents for typical embedded components like chips connected to peripherals and LEDs which are usually in the low mA area.
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
a good place to read to much info about current and past multimeter stuff would probably be the eevblog forum, also check out this link from a dedicated person how test to many different stuff: https://lygte-info.dk/info/indexDMMReviews%20UK.html
<vollbrecht[m]>
You can click on any multimeter for a somewhat dense info with high resolution photos etc.
<jason-kairos[m]>
s/but I'd like to hear if anyone else has done enough stuff work with bitfields/but I'd like to hear if anyone else has done enough stuff with bitfields to form an opinion/
<jason-kairos[m]>
s/but I'd like to hear if anyone else has done enough stuff work with bitfields/but I'd like to hear if anyone else has done enough stuff with bitfields to form an opinion about any of the crates out there/
<JamesMunns[m]>
In general, postcard focuses on "rust data goes in, rust data comes out, you don't need to worry about the details". It doesnt have any particular support for bit fields, you could pack them into integers or [u8] fields if you'd like.
<GuineaWheek[m]>
i like bilge but the lack of generated const ctors is annoying
<GuineaWheek[m]>
it also tends to muck up rust-analyzer in weird and unknown ways
<GuineaWheek[m]>
what i really want is pattern types lol
<GuineaWheek[m]>
<JamesMunns[m]> "In general, postcard focuses on..." <- something that does worry me a bit about postcard is what happens if i have to change my struct defns say across firmware versions
<GuineaWheek[m]>
im not 100% trusting of the stack to give me a mutually intelligible subset between two different versions of a schema to negotiate an OTA
<jason-kairos[m]>
GuineaWheek[m]: That's another things I ran into
<jason-kairos[m]>
I went so far as trying to modify BinarySerde to generate a stable across builds/toolchains unique type ID based on a hash of the name + fields + layout
<jason-kairos[m]>
* That's another thing I ran into
<jason-kairos[m]>
I went so far as trying to modify BinarySerde to generate a stable across builds/toolchains unique type ID based on a hash of the name + fields + layout
<jason-kairos[m]>
But it was too complicated
<GuineaWheek[m]>
how do i know that the enum indexes will remain stable
<jason-kairos[m]>
* That's another thing I ran into
<jason-kairos[m]>
I went so far as trying to modify BinarySerde to generate a stable type unique type ID across builds/toolchains based on a hash of the name + fields + layout
<jason-kairos[m]>
But it was too complicated
<jason-kairos[m]>
* That's another thing I ran into
<jason-kairos[m]>
I went so far as trying to modify BinarySerde to generate a stable unique type ID across builds/toolchains based on a hash of the name + fields + layout
<jason-kairos[m]>
But it was too complicated
<jason-kairos[m]>
* That's another thing I ran into
<jason-kairos[m]>
I went so far as trying to modify BinarySerde to generate a stable unique type ID across builds/toolchains based on a hash of the name + fields + layout
<jason-kairos[m]>
But it was too complicated. Detecting changes in struct layouts is hard.
<jason-kairos[m]>
* That's another thing I ran into
<jason-kairos[m]>
I went so far as trying to modify BinarySerde to generate a stable unique type ID across builds/toolchains based on a hash of the name + fields + layout
<jason-kairos[m]>
But it was too complicated. Detecting changes in struct definitions is hard.
<JamesMunns[m]>
In general, postcard demands you need to keep schemas mostly stable. There are other formats, like CBOR that allow for some compatible schema changes, but they are not free/transparent, in all of effort/size/speed.
<JamesMunns[m]>
Postcard-rpc has tools for _detecting_ when schemas have changed, and for supporting multiple versions of a schema at the same time, but you can't really have a "no cost but also flexible across schema changes" format.
<JamesMunns[m]>
> I went so far as trying to modify BinarySerde to generate a stable unique type ID across builds/toolchains based on a hash of the name + fields + layout
<JamesMunns[m]>
This is more or less what postcard-rpc does already.
<jason-kairos[m]>
<JamesMunns[m]> "> I went so far as trying to..." <- is that value accessible at compile time?
<JamesMunns[m]>
Yes
<jason-kairos[m]>
JamesMunns[m]: Is it possible to make it always emit a fixed size for a struct with ints?
<JamesMunns[m]>
jason-kairos[m]: You mean the type on the wire is a fixed size? Not in postcard where all multibyte ints are varints.
<jason-kairos[m]>
Oh well... (makes it hard to guarantee that everything fit in my situation, had hoped a middleware/flavor might have solved that - not a problem)
<jason-kairos[m]>
Looks like the hash looks at the type name/path, but maybe not at the contents of the type.
<jason-kairos[m]>
s/looks/used/, s/at//
<jason-kairos[m]>
s/looks/uses/, s/at//
<jason-kairos[m]>
* Oh well... (makes it hard to guarantee that everything will always fit in my situation, had hoped a middleware/flavor might have solved that - not a problem)
<jason-kairos[m]>
Looks like the hash uses the type name/path, but maybe not at the contents of the type.
<JamesMunns[m]>
I'm not sure what you mean by "contents of the type"
<jason-kairos[m]>
* Oh well... (makes it hard to guarantee that everything will always fit in my situation, had hoped a middleware/flavor might have solved that - not a problem)
<jason-kairos[m]>
Looks like the hash uses the type name/path, but maybe does not examine the contents of the type.
<JamesMunns[m]>
The hash is on the schema of a message, not the value of a message
<JamesMunns[m]>
It tells you if the type changes.
<jason-kairos[m]>
That makes sense
<JamesMunns[m]>
There's some ability to calculate an upper size for types using the schema message
<JamesMunns[m]>
Not if you send borrowed slices tho
<jason-kairos[m]>
(Postcard uses a schema and not a rust struct)
<jason-kairos[m]>
* rust struct to determine layouts)
<JamesMunns[m]>
(for a demo of how to calculate max size on the wire at const time)
<JamesMunns[m]>
jason-kairos[m]: Yes, the schema is derived on rust types
okhsunrog[m] has quit [Quit: Idle timeout reached: 172800s]
Max[m] has joined #rust-embedded
<Max[m]>
hey there! was wondering: is it really true that you cant have dynamic sized vecs with the basic tooling in embassy/rtic. all vec sizes need to be statically defined beforehand? no neat way to hold n-amount of midi messages dynamically as an example?
<GuineaWheek[m]>
Moore’s law died for SRAM ages ago
dav1d has quit [Ping timeout: 245 seconds]
dav1d has joined #rust-embedded
HumanG331 has quit [Ping timeout: 245 seconds]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
pcs38 has quit [Quit: leaving]
jfsimon has joined #rust-embedded
dav1d has quit [Quit: Ping timeout (120 seconds)]
dav1d has joined #rust-embedded
Mathias[m] has quit [Quit: Idle timeout reached: 172800s]
HumanG331 has joined #rust-embedded
Foxyloxy has joined #rust-embedded
<ian_rees[m]>
We've struck a somewhat-surprising issue while testing some new HAL code on SAMD21 (Cortex M0+) in debug mode: a read of an 8b register using code generated by svd2rust 0.33.5 appears to fail alignment checks `core::ptr::read_volatile<u8> (src=0x42004019)`. Wondering if this might be fixed by updating svd2rust, or if we're using it wrong?
<jason-kairos[m]>
(I am no expert but what exactly do you mean by fails alignment checks?)
<M9names[m]>
sorry, are you saying you have an unaligned byte? how is that even possible?
<JamesMunns[m]>
yeah, the alignment of u8 is 1, so it can't be mis-aligned. Are you hitting a debug assert somewhere?
<jason-kairos[m]>
most 8 bit registers are actually 32 bit
<ian_rees[m]>
in this case, it would be fine to read 0x42004018 and just keep the byte we're interested in, however this code is generated by svd2rust
jbeaurivage[m] has joined #rust-embedded
<jbeaurivage[m]>
Over at atsamd-rs, my hunch is a compiler regression
<jason-kairos[m]>
I think this debug assertion is probably nonsensical
<M9names[m]>
jason-kairos: i think throwing vibes at a problem like this isn't a good strategy if you care about correctness
<M9names[m]>
finding what the root cause is and either fixing or reporting it is the right thing to do. ignoring it just makes it someone else's problem.
<M9names[m]>
i reject the notion that the "is aligned" assertion in the core library is "nonsensical"
<jason-kairos[m]>
I think the key question is: what is it checking?
<jason-kairos[m]>
does cortex M0 allow for single byte load at that address?
<jason-kairos[m]>
and was this a regression that was fixed in a more recent version of the tooling?
<ian_rees[m]>
just ran a quick test with 1.77.2 - it doesn't blow up
<jason-kairos[m]>
I suppose that begs the question: what version causes the failure?
<ian_rees[m]>
yep, bisecting now
<M9names[m]>
> does cortex M0 allow for single byte load at that address?
<M9names[m]>
cortex-m0 allows single byte memory access across it's entire mapped memory range.
<M9names[m]>
that's kinda irrelevant to the problem at hand anyway - if you access memory in an invalid way you get an access fault from the hardware, not an assert from the software
<jason-kairos[m]>
I seem to recall some talk about the llvm internals changing in the most recently past few releases
<jason-kairos[m]>
s/recently/recent/
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
how're you getting that stacktrace?
<dirbaio[m]>
maybe_is_aligned_and_not_null doesn't have any asserts, it just returns a bool
<dirbaio[m]>
so it's not possible for maybe_is_aligned_and_not_null to crash
<ian_rees[m]>
running firmware with cargo-embed, gdb
<jason-kairos[m]>
nevermind, this commit is too recent
<ian_rees[m]>
is it sufficient to use eg rustup install --target thumbv6m-none-eabi 1.84.1 and DEFMT_LOG=debug cargo +1.84.1 embed --example=adc to check this behaviour in 1.84.1?
<M9names[m]>
should be fine yep
<ian_rees[m]>
IDK, I'm now unable to reproduce that issue...
<jason-kairos[m]>
The commit message makes it look like the ub_check might be an optional feature that must be enabled
<jason-kairos[m]>
I wonder if the might be different builds (patch versions) of rustc of whatever version you originally reproduced this on
<jason-kairos[m]>
s/the/there/
<jason-kairos[m]>
s/the/there/, s/of/for/
<jason-kairos[m]>
* I wonder if there might be different builds (or patch versions) of rustc for whatever version you originally reproduced this on
<ian_rees[m]>
I should've saved the elf that was failing, but unfortunately didn't. Pretty sure I'm back to the same compiler that produced the error though, rustup didn't download one when I switched back to stable
jfsimon has quit [Remote host closed the connection]