roofi[m] has quit [Quit: Idle timeout reached: 172800s]
<dygear[m]>
Anyone having a problem with rust-analyzer? Keep getting "Client Rust Analyzer Language Server: connection to server is erroring. Shutting down server." I think it's because I'm starting to build a lib and it's choking because I have to many functions that return with the `todo!()` magic macro. Is that a known bug?
zignig has joined #rust-embedded
zignig has left #rust-embedded [#rust-embedded]
GuineaWheek[m] has joined #rust-embedded
<GuineaWheek[m]>
is there a good linalg library that lets me not use libm....running into perf issues with its sqrt and cos/sin implementations
bomb has joined #rust-embedded
bomb has quit [Remote host closed the connection]
bomb has joined #rust-embedded
<JamesMunns[m]>
<GuineaWheek[m]> "is there a good linalg library..." <- Check out micromath and idsp
<GuineaWheek[m]>
micromath is too inaccurate and doesn't use the fpu for things like sqrt
<JamesMunns[m]>
JamesMunns[m]: Or maybe cmsis_dsp
<JamesMunns[m]>
if those three don't work, maybe someone else has a better idea, but those are the three I'm aware of :)
<ryan-summers[m]>
<GuineaWheek[m]> "is there a good linalg library..." <- https://crates.io/crates/idsp is a crate that provides fast, fixed-point math for cossin with analyzed accuracy documented in the crate
<ryan-summers[m]>
We use it for high throughput DSP, can't remember how it compared to CORDIC coprocessors though
<ryan-summers[m]>
I think the cordic was better with throughput if you have lots of continuous data, but has a higher latency for single sample
cr1901 has quit [Ping timeout: 260 seconds]
<GuineaWheek[m]>
that might depend on how your hardware cordic behaves though? idk probably holds true even for chinese stm32 clones
<GuineaWheek[m]>
also, is there a way to see what instructions something from `core::intrinsics` generates (e.g. `core::intrinsics::copysignf32`)
<GuineaWheek[m]>
oh i figured out that you can just put the correct --target and stuff into godbolt
<ryan-summers[m]>
Yeah was about to say, use godbolt. But yeah this was a comparison with the STM32H743ZITx (M7 core) that we use, obviously other processors may have different characteristics
<GuineaWheek[m]>
hmm how do i get godbolt to show me the compiled output for x % y -- for some intrinsics it seems to branch to a label that doesn't show up in godbolt
mameluc[m] has joined #rust-embedded
<mameluc[m]>
James Munns: any way to make postcard ignore serde container attributes like `#[serde(tag = "type")]`? I need to go struct -> binary -> json and Id like to use tag for the json representation
<JamesMunns[m]>
No, afaik, other than like `#[cfg_attr(feature = "do-json-stuff", serde(...))]`
<mameluc[m]>
JamesMunns[m]: I tried feature gating it but my decoder needs to decode binary and encode json and cargo doesn't allow me to have two copies (with different features) of the same crate
<mameluc[m]>
error: the crate decode v0.1.0 (...) depends on crate model v0.1.0 (...) multiple times with different names
<JamesMunns[m]>
ah, yeah, nothing to do there, unfortunately.
<JamesMunns[m]>
(at least as far as I know).
<mameluc[m]>
ok ty, I need to figure out another way then. Probably have to use two models or write some macrony
bomb has quit [Remote host closed the connection]
bomb has joined #rust-embedded
dav1d has quit [Ping timeout: 255 seconds]
dav1d has joined #rust-embedded
bomb has quit [Quit: 💣]
AtleoS has joined #rust-embedded
ragarnoy[m] has joined #rust-embedded
<ragarnoy[m]>
Has there been any interest over making a PolarFire hal ?
<JamesMunns[m]>
<ragarnoy[m]> "Has there been any interest over..." <- Isn't polar fire an fpga? Does it have hard cores inside?
<JamesMunns[m]>
Ah, riscv app cores maybe?
<ragarnoy[m]>
yeah, the riscv component of the polarfire
<ragarnoy[m]>
(maybe i'm wrong though)
avery71[m] has joined #rust-embedded
<avery71[m]>
I'd quite like to see rust on the NIOS II soft core CPU platform, but no chance that is happening until GCC supports rust (and even then)
cr1901 has joined #rust-embedded
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
I'm still interested in this (byte-serializing) space; I wonder if using Serde is interesting. I tried to get a macro-based approach working, with almost, but not good enough results. Postcard isn't applicable directly unless you control both ends of the protocol.
<firefrommoonligh>
Basically, I'm not a fan of the amount of syntax involved in transcribing structs to/from byte arrays, which I do regularly
<firefrommoonligh>
Just today I am writing code to parse Remote ID drone packets. It's doable, but the code is kind of ugly and verbose, as is all my code to [de]ser byte arrays
<dirbaio[m]>
repr(C) and transmute :P
<firefrommoonligh>
That might actually not be worse than the alternative...
<dirbaio[m]>
i'm not joking
<firefrommoonligh>
Btw, the single-byte fields aren't too bad, but the multi-byte ones are a pain, especially if converting to/from enums
<ryan-summers[m]>
There's also the encode crate (can't remember the exact name) that exposes Encode and Decode macros
<JamesMunns[m]>
dirbaio[m]: (this is one of those "works really well if you're really careful and you'll have no indication if you're doing something subtly wrong")
<firefrommoonligh>
I may actually try it, although I haven't... (the repr(c)
<dirbaio[m]>
there's many protocols out there that work extremely well as repr(C) structs
<dirbaio[m]>
mostly because the impls out there are using C and pointer casting :P
<firefrommoonligh>
(Plus "to_bytes" with a reverse")
<JamesMunns[m]>
like, don't get me wrong, it's not necessarily incorrect to use repr(c). but like I've said before, I think it's a horrific idea to promote to folks as a first option.
<dirbaio[m]>
repr(C) is free to serialize/deserialize. your logic can work directly with the struct.
<firefrommoonligh>
ryan-summers[m]: Have not heard. That sounds like it could work. My gut says the solution will indeed be in the form of a macro.
<firefrommoonligh>
JamesMunns[m]: But is it better than what I just posted?
<dirbaio[m]>
if you serialize/deserialize to a repr(Rust) struct you are generating glue code that does nothing of value, just moves data around
<JamesMunns[m]>
firefrommoonligh: better in what way? It's less to type
<dirbaio[m]>
rust doesn't let you take references to fields in repr(packed) structs. only copy in/out
<JamesMunns[m]>
fair!
<JamesMunns[m]>
then that point is one you don't have to worry about!
<JamesMunns[m]>
I'
<JamesMunns[m]>
I'm saying:
<JamesMunns[m]>
* it's also very easy (and subtle) to get wrong
<JamesMunns[m]>
* it's very possible to get right
<dirbaio[m]>
1 UB down, 99 possible UBs left 🥳
<firefrommoonligh>
I am probably misreading the example mfor encdec, but it looks like perhaps you still have to manually encode/decode, but it provides a wrapping trait?
<dirbaio[m]>
just the event deseriaiization in the bluetooth-hci crate is already ~35kb
<dirbaio[m]>
no logic, just deserialization
<firefrommoonligh>
JomerDev[m]: YOu know, I think I've used this before for dealing with bit-alignment... never thought to apply it when that's not required, but it may work...
<dirbaio[m]>
something that would literally be 0kb if you used repr(C)
<ryan-summers[m]>
It operates like serde, where each object needs to implement Encode/Decode. You can implement it for custom types, but its impl'd for the core types
<JamesMunns[m]>
dirbaio[m]: I'm worried about the folks that will read this and go "oh never use serde always repr(c) transmute forever okay thanks I'll repeat that on forums for the next 5 years"
<dirbaio[m]>
there's some crates out there with proc macros that ensure repr(C) transmutes are safe automatically for you
<JomerDev[m]>
firefrommoonligh: It should work well for the example you posted
<dirbaio[m]>
bytemuck
<JamesMunns[m]>
bytemuck, zerocopy, yep
<dirbaio[m]>
so I don't agree with this "the way to go is serde or equivalents, repr(C) is 🤮"
<dirbaio[m]>
it's literally the best way, lowest cost and fastest as long as your protocol allows for it (for example no varints etc)
<dirbaio[m]>
and you can make it safe with bytemuck etc
<JamesMunns[m]>
I don't think those are the two only options.
<dirbaio[m]>
* repr(C) is literally the best way, lowest cost and fastest as long as your protocol allows for it (for example no varints etc)
<JamesMunns[m]>
And I do think that in most cases, without exhaustive regression testing of all platforms you use, repr(c) casting is 🤮. In localized uses, it can be fine.
<JamesMunns[m]>
but inexperienced users don't know where those boundaries are, and even experienced users make oversights.
<dirbaio[m]>
there's 2 main ways of doing it:
<dirbaio[m]>
A- Make your logic work with the same layout as the wire
<dirbaio[m]>
B- Make your logic work with different layout as the wire
<dirbaio[m]>
serde, encdec, bincode, json, yaml, cbor, whatever are B
<dirbaio[m]>
repr(C) is A
<dirbaio[m]>
and A will always be cheaper and faster than B (as long as your protocol is suitable for it)
<JamesMunns[m]>
"Make your logic work with the same layout as the wire", for some values of "your logic".
<firefrommoonligh>
Oh, looks like I got a little too exccited with the example!
<dirbaio[m]>
JamesMunns[m]: typically you have some "business logic" that does "stuff" with the data you're receiving/sending. that's what I mean with "logic"
<dirbaio[m]>
e.g. the bluetooth stack itself, in the case of HCI
<dirbaio[m]>
HCI is designed so that the entire bluetooth stack can work with the repr(C) structs directly
<JamesMunns[m]>
dirbaio[m]: yeah, and I mean if you have a 16-bit big endian CPU and a 32-bit little endian CPU the code will only work if you transmute THEN do endianness swaps
<dirbaio[m]>
so you can skip the serialize/deserialize steps entirely
<JamesMunns[m]>
if you only care about your one target, or only little endian targets, or the only two used for your product in your stack, yes, you can skip those steps
<dirbaio[m]>
who uses big endian cpus anymore???
<JamesMunns[m]>
sure, or who uses usize?
ivmarkov[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
and why should I bloat my little-endian binary to support big-endian if I don't personally care about big-endian?
<firefrommoonligh>
Btw, does anyone else use ChatGPt for writing macros? I can't seem to get teh syntax to stick. Probably just need to try more...
<JamesMunns[m]>
anyway, I think you understand my concerns, and aren't interested in them, so i'll leave it!
<dirbaio[m]>
it's the same async vs blocking debate as yesterday :P
<firefrommoonligh>
James Munns: I hear your concerns about repr(c), but also dirbao's how it can be OK here, although I am thinking it is not my favorite
<JamesMunns[m]>
it can be fine until it isn't!
<dirbaio[m]>
"you've coded your library in a bad way, it only supports X, I want to use it with Y. You must do extra work to support Y even if you personally don't care about it"
<firefrommoonligh>
JamesMunns[m]: Oh sweet; hadn't heard of that
<JamesMunns[m]>
that's the point
<dirbaio[m]>
where X=async, Y=blocking
<dirbaio[m]>
or X=little-endian, Y=big-endian
<JamesMunns[m]>
i'm not saying YOU should stop, dirbaio.
<dirbaio[m]>
I knowww :D
<JamesMunns[m]>
im saying "struct transmutes are a common source of logic and program errors, with a dash of UB"
<JamesMunns[m]>
and that it's irresponsible to recommend them, EVEN IF they are often a useful tool, unless you're willing to do the legwork to make sure they don't get improperly used.
<JamesMunns[m]>
THATS my point.
<JamesMunns[m]>
they are a tool with no safety cage and a slippery floor.
<firefrommoonligh>
My thought mainly is that I would misalign that repr(c) struct in a heartbeat, or spend too much time qcing alignment
<firefrommoonligh>
I think my ideal solution would have to have manual byte index specification on all fields
<dirbaio[m]>
firefrommoonlight: did you know you can hover a field to see the offsetof? and a type to see the size?
<dirbaio[m]>
you can write the struct, then quickly check the offsets are what you expect
<dirbaio[m]>
with rust-analyzer
<cr1901>
diondokter[m]: I'm trying to see what I can use from sequential-storage for 24x series EPROMs. Under what conditions will that crate reset NOR Flash back to 0xff (or close to it- I noticed that you don't look exactly for 0xff)?
<cr1901>
24x EEPROM* doesn't have an erase operation, so I don't think I can't use the crate directly, unless I do needless writes to reset 16-byte pages back to 0xff
<cr1901>
(the writes perform an implicit erase)
<dirbaio[m]>
yeah the erase is supposed to set the sector to 0xFF
<dirbaio[m]>
if you want to emulate that on EEPROM you have to do a write filling it with 0xFF
blaine[m] has quit [Quit: Idle timeout reached: 172800s]
<diondokter[m]>
Yeah, it does depend on stuff being 0xFF after erase. It's baked in the trait definitions.
<diondokter[m]>
Idk, maybe a future version could be peeled off of the traits and support other things too
<cr1901>
diondokter[m]: By any chance, must values in an embedded storage Map fit into a single page?
<diondokter[m]>
Any one item cannot be bigger than a page or 2^16
<diondokter[m]>
But you can use multiple pages
<cr1901>
Okay, I'm not violating that
<cr1901>
For some reason, after the first item, I fail with "StorageFull", which I think should be impossible.
<cr1901>
(I have a MCVE if you're willing to take a look)
<diondokter[m]>
Hmmmm
<diondokter[m]>
Yeah shouldn't be
<diondokter[m]>
Yes please!
<JamesMunns[m]>
I'm AFK so can't participate too much, but I just sent out a newsletter with some of the hardware design progress of the boards I'm going to use for my RustNL workshop, as well as a little bit of a preview of what postcard-rpc can do: https://onevariableappliedresearch.cmail19.com/t/y-e-xuukyll-ihlyuksly-ir/
<cr1901>
diondokter[m]: Please gimme a second to minimize further and commit
<diondokter[m]>
Np, I'm getting a visitor in 10 mins, so I probably can't look at it straightaway anyways
<JamesMunns[m]>
(also if you're going to be at RustNL and want to meet up for a chat, lemme know! I'm excited to see people in person again!)
<cr1901>
Ack. And for all I know my 24x EEPROM emulator/mock could be badly written
<adamgreig[m]>
hmm, hackmd won't let me log in 🥲
<dirbaio[m]>
isn't there a mock in the sequential-storage repo already?
<diondokter[m]>
Yep
<cr1901>
Is it available as a public export?
<diondokter[m]>
Though not really as an open API but for just experiments you could enable the _test feature flag
<cr1901>
yea that's fine, this isn't a crate meant for release
<JamesMunns[m]>
<dirbaio[m]> "https://github.com/tweedegolf/..."; <- This is neat! I wrote basically this for a project, I should use this in the future
<adamgreig[m]>
ok, let's start! just one announcement from me this week, embedded-hal-bus 0.2 was released last week with the new AtomicDevice struct
<adamgreig[m]>
any other announcements? the first agenda item otherwise is also about AtomicDevice :P
<adamgreig[m]>
it uses CAS atomic methods from portable-atomic, which fail to compile on v6 unless you either enable the critical-section feature (and provide a cs impl) or enable unsafe-assume-single-core feature on portable-atomic
<adamgreig[m]>
but since most users of e-h-b won't necessarily have portable-atomic in their direct dependencies anyway, they end up having to add it and add some features just to use e-h-b, which seems annoying
<adamgreig[m]>
...or at least it should be documented
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Oh man, how could we miss that. 🫣
<adamgreig[m]>
short of feature-gating AtomicDevice, I'm not sure if we can easily make this compile? ideally it would fail to compile when you actually use atomicdevice but succeed if you don't use it
<adamgreig[m]>
we could conceivably feature-gate atomicdevice but enable the feature on non-v6 platforms but ugh
<adamgreig[m]>
yea, separately the CI probably should include v6...
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Add a feature to e-h-b to turn on the unsafe portable-atomic feature?
<thejpster[m]>
I think it just needs docs.
<thejpster[m]>
also, I have an announcement. Sorry I'm late. Come back to me when you're ready.
<adamgreig[m]>
bartmassey[m]: this would at least make it easier to use e-h-b
<jannic[m]>
As I understand it the main reason this is annoying is that compilation breaks even if you don't use AtomicDevice. So "solving" it with docs means that the docs can't be on AtomicDevice, they must be on the top level, basically stating "if you use embedded-hal-bus on armv6m, you need to do ....."
<dirbaio[m]>
since AtomicDevice is a bit niche I personally favor feature-gating
<dirbaio[m]>
* favor feature-gating it
<adamgreig[m]>
is it too cursed to enable it on v7 but leave it feature-gated-default-off on v6?
<adamgreig[m]>
you could have its feature be enabled by either of the portable-atomic proxy features too i suppose
<adamgreig[m]>
yea, we could add the p-a feature proxies (and have them enable atomic-device feature) for v6 users
<bartmassey[m]>
Yeah, gate off on v6 unless proxy feature sounds pretty good to me
<adamgreig[m]>
I guess the problem is I'm casually saying v6/v7 but obviously it's more complicated than that
<adamgreig[m]>
not sure if we can robustly figure out in a build script whether the target has atomic cas
<JamesMunns[m]>
You can, but you cant effect feature settings for other crates
<adamgreig[m]>
that's fine, we don't need to
<jannic[m]>
Given that it's only been released one week ago, would it be too bad to accept the breaking change, release 0.3 and yank 0.2?
<adamgreig[m]>
if it's got atomic cas we don't need to touch p-a, it will just work
<adamgreig[m]>
if it's not got atomic cas we don't force-enable atomic device, the user can manually enable it with our feature (and must also enable a p-a feature, either through our proxies or directly)
<thejpster[m]>
you need to push upstream for a proper cfg flag for "this system can do fetch_add and compare_and_swap"
<JamesMunns[m]>
We could fail the build with a more helpful error message, but we can't enable a p-a feature
<dirbaio[m]>
and target_has_atomic_cas doesn't exist 🤦♂️
<adamgreig[m]>
if we can use the feature to make it available by default when cas is available, and the feature gate is for non-cas targets, it's not even a breaking change 👀
<adamgreig[m]>
...because it's already broken for non-cas targets and would keep working for the rest :P
<dirbaio[m]>
> it's already broken for non-cas targets
<dirbaio[m]>
no, it's not broken if you do enable the right feature in portable-atomic
<dirbaio[m]>
gating it would break those projects
<bartmassey[m]>
I would still like the proxy features, because I'm worried about version skew between e-h-b and user-included portable-atomic. Am I wrong? (probably)
<dirbaio[m]>
I think portable-atomic is supposed to stay 1.0 forever... but yeah it's a valid concern
<thejpster[m]>
(brb)
<adamgreig[m]>
dirbaio[m]: oh boo. yes I guess there are now one or two projects for whom they have now enabled p-a feature to unbreak it and a 0.2.1 would break it again until they enabled our feature (or our p-a proxy features)
<adamgreig[m]>
still.....
<dirbaio[m]>
all embassy examples for thumbv6 chips do setup portable-atomic, for example
<adamgreig[m]>
yea, oh well
<thejpster[m]>
(back)
<adamgreig[m]>
so does that sound like a good plan? add atomic-device feature, enable AtomicDevice if feature is enabled or cfg(target_has_atomic..), add atomic-critical-section and atomic-unsafe-assume-single-core (or portable-atomic-...?) which proxy to p-a and also enable atomic-device, document this
<adamgreig[m]>
release as 0.3, i don't think we'd need to yank 0.2
<therealprof[m]>
That's what you get for being clever. 😛
<dirbaio[m]>
SGTM
<adamgreig[m]>
cool
<jannic[m]>
crates.io doesn't show a single dependency on embedded-hal-bus 0.2. So I don't think jumping right to 0.3 will hurt many.
<adamgreig[m]>
thejpster: announcement?
<thejpster[m]>
ok two things
<thejpster[m]>
1. last call for comments on the arm target PR
<thejpster[m]>
it's been a labor of love
<thejpster[m]>
2. it is with regret that I have to step down from the embedded working group due to ongoing health issues. This will also remove me from the leadership council and trigger another election. It's not ideal that it happens so soon after the last election, but, well, I need to take care of some things.
<adamgreig[m]>
it's looking really good!
<thejpster[m]>
I will still be in RustNL next week.
<thejpster[m]>
Then VECS the week after. Then Oxidize two weeks after that.
<bartmassey[m]>
Sympathies
<adamgreig[m]>
great timing
<thejpster[m]>
then I will sleep for a month
<adamgreig[m]>
hope you're doing ok!
AdamHott[m] has joined #rust-embedded
<AdamHott[m]>
sorry to hear
<adamgreig[m]>
let me know if you need a hand with any admin stuff, I guess someone from the leadership council will handle getting ready for a new election?
<thejpster[m]>
deleting zulip will help. You should all check out zulip more. A lot goes on there.
<thejpster[m]>
launching pad will need to select someone to run the election. Nell did it last time. That's launching pad's job, not council's job.
<jannic[m]>
Whatever it is: Taking care of yourself is definitely more important than the wg!
<thejpster[m]>
oh I guess announcement 3 - I'd like to make time next week to talk about the future of the Embedded Devices Working Group and where it fits in with the Rust project. I'm sorry I won't be able to push that conversation along after it happens.
<bartmassey[m]>
I think a lot of us will be at RustNL next week?
<thejpster[m]>
My takeaway from the leadership summit was that the project kind of wants to concentrate on toolchain delivery, rather than the usages of the toolchain. That's not universally accepted, but that was the vibe I got.
<therealprof[m]>
Same ol...
<thejpster[m]>
yeah but now there's questions like "we have money to give Rust Project developers", which begs questions like "who exactly is a Rust Project developer"
<adamgreig[m]>
yep, I'm not sure what we should do for next week's meeting, whether we want to run it as usual on matrix or postpone a week given many of us are at RustNL
<thejpster[m]>
and the EDWG looks reeeeeally weird on the org chat
<thejpster[m]>
I suggest we postpone it
<thejpster[m]>
s/chat/chart/
<adamgreig[m]>
works for me
<AdamHott[m]>
yea postpone I agree
<bartmassey[m]>
I have to leave a bit early for next meeting. When we're ready, can we skip ahead a bit for a quick chat about STM Discovery Book?
<AdamHott[m]>
all good to me
<adamgreig[m]>
go for it bartmassey
<bartmassey[m]>
I've been reviewing DB PRs.
<bartmassey[m]>
Some older ones are for STM DB.
<bartmassey[m]>
One issue there is that there's now a newer version of the board, which would need book updates.
<bartmassey[m]>
The other is that most of the newer PRs and issues seem to be MB2
<adamgreig[m]>
a new f3discovery? 💀
<bartmassey[m]>
I really hate to deprecate the STM DB, but I'm not sure how much effort maintaining it would be or is worth?
<bartmassey[m]>
(I'm assuming that we would port the missing MB2 DB content before any deprecation.)
<bartmassey[m]>
Yeah, not that new. The post-pandemic one switched LSM303 versions, which broke some stuff.
<adamgreig[m]>
at the time we merged the new MB book we decided to keep the old f3disco book up because a) it might still be of use to people with that hardware b) no hardship keeping it live, but I think without much plan to perform much maintenance there. if it's got to the point where you can't even buy compatible hardware I wouldn't mind retiring it completely, or keeping it hosted but more severely marking it as archived/read-only/deprecated
<bartmassey[m]>
Yeah, I think we should at least keep it hosted.
<dirbaio[m]>
how did the board change so much? wtf
<bartmassey[m]>
But we might choose to clearly mark it as sketch
<bartmassey[m]>
The changes to bring it up to date are probably not that big. So it's kind of a difficult call.
<adamgreig[m]>
because it's so targeted at beginners I think it makes more sense to put all available effort into the new mb book really
<therealprof[m]>
Fair.
<bartmassey[m]>
That's my slight inclination, but I thought I should check off before heading in that direction. The biggest to-do that needs to be done anyway is porting the extra chapters of STM DB to MB2 DB
<AdamHott[m]>
that makes sense
<bartmassey[m]>
I'll work on that RSN™. (Help appreciated ofc)
<AdamHott[m]>
Would appreciate anyone to raise an issue on github
<AdamHott[m]>
things to add, emphasize, things to remove, downsize
<AdamHott[m]>
right now it's just the basics
<adamgreig[m]>
nice, thanks! do you think you could structure it as a PR against the book repo? that might make it easier to see in context and make specific suggestions/review comments/etc
<AdamHott[m]>
yes definitely, I couldn't find the book's repo though :/
<adamgreig[m]>
the rusty-probe section is a bit unusual too, it might make more sense to have a "Debug Probes" section that explains what a probe is, how it works, and lists some examples (including rusty-probe, but probably also st-link, j-link, maybe mcu-link, and so on)
<bartmassey[m]>
Ikr?
<AdamHott[m]>
great!
<AdamHott[m]>
yes!
<bartmassey[m]>
:wave: See some of you next week!
<bomb>
OpenADHD
<dirbaio[m]>
yeah, would be good to explain the "category" of what each thing is
<dirbaio[m]>
for example gdb is both a "protocol" and a "program". you can use gdb both with probe-rs and openocd (and others) because they both have a gdb server
<dirbaio[m]>
* gdb server speaking the gdb protocol
<AdamHott[m]>
land openocd is a software tool
<AdamHott[m]>
s/land/and/
<dirbaio[m]>
yea
<AdamHott[m]>
ok, excellent feedback thanks!
<dirbaio[m]>
like, it can give the impression you have to use probe-rs OR gdb OR openocd
<AdamHott[m]>
that's true, it does read that way as it stands
<dirbaio[m]>
while the reality is you have to pick a probe (rusty-probe, cmsisdap, jlink, stlink..) AND software to drive it (probe-rs, openocd) AND a debugger (gdb, or the probe-rs vscode extension)
<therealprof[m]>
... or LLDB...
<AdamHott[m]>
🤯
<sourcebox[m]>
I would really emphasize to use probe-rs except for the cases when OpenOCD is the only choice.
<therealprof[m]>
... or you can use a BMP which is a debug probe with a gdb driver built-in...
<JamesMunns[m]>
therealprof[m]: Maybe it'll support `load` some day!
<therealprof[m]>
(but I definitely would not recommend that, just saying that this exists)
<dirbaio[m]>
yea the BMP is so odd. does it work well in practice?
<therealprof[m]>
No idea, never got warm with it.
<JamesMunns[m]>
dirbaio[m]: From what I've seen the people that like it like it a lot, but I think it's also a reaction to openocd being Not Great for so long.
<AdamHott[m]>
ok thanks everyone, I have to run!
<AdamHott[m]>
I'll revise this based on the suggestions then open a PR
<adamgreig[m]>
thanks, seeya!
<adamgreig[m]>
I used the BMP from like 2007 until maybe 2018 and still a bit today at work, they work really well
<adamgreig[m]>
before probe-rs it was so good for the same reason: no openocd
<therealprof[m]>
JamesMunns[m]: Hm, usability is not great but it's a swiss army knife.
<cr1901>
Wait... BMP has been around since 2007?!
<therealprof[m]>
... if the target is supported and correctly implemented that is.
<adamgreig[m]>
hmmm that can't be right
<JamesMunns[m]>
therealprof[m]: Yeah, classic Unix tool: it sucks until you get used to it then it's fine and basically the only game in town.
<JamesMunns[m]>
Especially when so many chips required patched forks
<adamgreig[m]>
yea, lol, more like 2012
<adamgreig[m]>
(that's all for the meeting, thanks everyone! remember, no meeting here next week, we'll be back on the 14th)
<adamgreig[m]>
maybe even see you at st pancras :P
<cr1901>
"cargo run" and enjoy your panic :)
<therealprof[m]>
therealprof[m]: Not a problem if you're working with a brand new chip which needs a boatload of custom poking anyway before getting it to work.
<JamesMunns[m]>
therealprof[m]: Yeah, it's more reasonable today than 5 years ago.
<cr1901>
I can't tell whether I'm doing something wrong with miniconf/sequential-storage or I found a bug w/ miniconf/sequential-storage
<cr1901>
(probably the former)
<therealprof[m]>
LOL, I remember rescuing dead systems with a FTDI chip adapter (sans MPSSE), poking a flash chip via the CPU in a JTAG chain...
<therealprof[m]>
Just fixing a 128kB u-boot image can take a whole night. :D
<therealprof[m]>
<JamesMunns[m]> "Maybe it'll support `load..." <- What's wrong with target modules load?
<RobertJrdens[m]>
cr1901: ` SettingsKey(p.unwrap().get() as u8),` should get `into_lsb()`. Better yet: don't "as u8" and postcard the NonZeroUsize as key.
<RobertJrdens[m]>
* don't ".get() as u8"
<cr1901>
I've changed SettingsKey to NonZeroUsize. At least the key has more breathing room to grow now
<cr1901>
Still doesn't fix the panic, so I'll have to wait for further guidance
<JamesMunns[m]>
<therealprof[m]> "What's wrong with target modules..." <- Maybe I'm out of date, but for a long time lldb didn't support the "load" command to do the actual flashing of devices over gdb/openocd
<therealprof[m]>
Not a big user of that feature but I think that should work.
<therealprof[m]>
It didn't with the BMP though, since BMP decidedly only implements whatever makes gdb happy and ignored all other debugging software. Not sure whether that has changed.
<therealprof[m]>
Found this in a jiffy if someone has the ambition to try it out...
<whitequark[cis]>
lldb has had serious flaws in embedded/bare-metal target support for a very long time
<whitequark[cis]>
i'm not sure if it improved but i never found it actually usable
xiretza[cis] has joined #rust-embedded
<xiretza[cis]>
I really like some of its UI choices and it feels like it might be less of a crashy mess than gdb, but yeah, haven't had much luck with it for embedded
<M9names[m]>
<adamgreig[m]> "at the time we merged the new MB..." <- I had a newbie on discord this week asking whether to buy the the f3disco or microbit - they were going to get the f3 if they had no guidance.
<M9names[m]>
Whatever we do with the books themselves, I think we should have a section (up front and large) telling people to buy the MB2 if they have a choice.
<M9names[m]>
And preferably a SKU number so they don't mess it y
<cr1901>
diondokter[m]: Ack. I only have 1kB of EEPROMs.
<diondokter[m]>
4 pages of 256 bytes would also work much better than 16 :)
<cr1901>
I'll have to see what eprom24x supports; the write pointer will not incr across a page, so any write > 16b will be multiple i2c xactions
<cr1901>
But better than "no support at all" :P
<cr1901>
>However, it's unlikely that a pagesize of 16 bytes will ever be useful with this library. <-- Maybe I can look at ItemHeader and propose an ItemHeaderJr at some point
<cr1901>
thanks for looking into it!
<diondokter[m]>
Right, that'd have to split up a bit then. Basically you get some bytes and an address
<diondokter[m]>
cr1901: Well... maybe? The item header used to be smaller and I reluctantly made it bigger because I had to to be able to do corruption repair and not get too many crc collisions
<diondokter[m]>
But feel free, any feedback is welcome :)
<cr1901>
(Name of "ItemHeaderJr" subject to change)
<cr1901>
diondokter[m]: FWIW, I'm trying to store a 22 byte heapless::String, so I figured that would be able to span 4 pages, even with the horrific overhead
<cr1901>
>Any one item cannot be bigger than a page or 2^16 <-- ooooooh
<cr1901>
"cannot be bigger than a page" I missed that first part. I thought objects _could_ span pages
<diondokter[m]>
cr1901: Ah, no. In theory that support could be added, but it'd make things super complex
<diondokter[m]>
And worse performance
<cr1901>
Coupled with "[13:49:15] <diondokter[m]> But you can use multiple pages"
<cr1901>
I misparsed your answer as "items must be less than 2^16, but they can span multiple pages"
<cr1901>
oops
<dirbaio[m]>
ekv does split things across pages
<cr1901>
"ekv works best for datasets with large amounts of keys (>1000)", my dataset is empathetically not that :P
<dirbaio[m]>
because otehrwise it's possible that garbage collection actually makes things bigger, losing more space instead of reclaiming 🤣
<dirbaio[m]>
yeah ekv won't work on a 1kb flash, don't even try 😅
<cr1901>
not with that attitude it won't :D
<dirbaio[m]>
dirbaio[m]: this is because GC merges multiple files into one. it's possible the original two files pack nicely into pages, but the result of the merge doesn't
<dirbaio[m]>
I don't think that's the case for sequential-storage though since it doesn't 'merge' (?)
<dirbaio[m]>
it was a fun (not) discovery... i'd have preferred to not have to split things across pages 😭
<cr1901>
Oh, so ekv GC == "packing" in git parlance
<dirbaio[m]>
dunno? it's more like "merge" as in "merge-sort"
<dirbaio[m]>
it has multiple "files" of sorted records, GC merges two files into a bigger sorted file (on duplicates, it can drop the "old" value, that's what causes it to reclaim space)
<diondokter[m]>
<cr1901> "Coupled with "[13:49:15] <..." <- Yeah, definitely need some better docs on this. I can see where the confusion came from!
<cr1901>
>If the dataset fits in RAM, you could read/write it all at once. <-- realistically, this is a perfectly valid solution for my use case. I just like the idea of only loading data that I need when I need it lol.