linfax has quit [Read error: Connection reset by peer]
linfax has joined #rust-embedded
linfax has quit [Remote host closed the connection]
<AdamHott[m]>
I'm working through this example to connect an ESP32c3 to a HiveMQ MQTT broker. I setup the cluster in HiveMQ but I need a client ID, which I think is the Username when creating a credential pair. Can anybody confirm if the client ID is the Username of the credential pair?
lulf[m] has joined #rust-embedded
<lulf[m]>
No, the mqtt client id is an identifier of the client that you choose. It's mostly relevant when it comes to persistent sessions.
<lulf[m]>
* The mqtt client id is typically an identifier of the client that you choose. It's mostly relevant when it comes to persistent sessions.
<lulf[m]>
(But I'm not familiar with HiveMQ terminology...)
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<korken89[m]>
Repost from the RTIC channel
<korken89[m]>
We've released RTIC 2.1.0 🎉 which fixes a soundness bug in the lock implementation. We recommend all to `cargo update` RTIC to v2.1.0. (Note: we have yanked affected versions)
<korken89[m]>
Included in this release is also the `stable` support so RTIC does not require `nightly` anymore.
<dirbaio[m]>
stable async everywere, here we gooo 🚀
<AdamHott[m]>
<mabez[m]> "I can't recall if you're using..." <- this is the one I'm using actually
<AdamHott[m]>
That repo had a few errors in it, so I tried a different route and landed on this:
<sparky[m]>
oh well... not like i plan to regularly read from serial anyways
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
<AdamHott[m]>
I'm definitely not a rust expert, there may be a way I don't know of
holo[m] has joined #rust-embedded
<holo[m]>
In [example](https://github.com/embassy-rs/embassy/tree/main/examples/boot) i see option where bootloader is flashed and is responsible for moving image from DFU to ACTIVE and aplication is writing binary to DFU (or im missing sometihng?). How second option, bootloader as library, can be used and what additional configurations are available thanks to it?
<holo[m]>
"The bootloader can be used either as a library or be flashed directly if you are happy with the default configuration and capabilities."
<thejpster[m]>
yeah it appears defmt has no hints for f32 and f64 formatting.
<thejpster[m]>
Also as a general rule I recommend {=f64} (or whatever) instead of {} so it can be packed more efficiently.
<thejpster[m]>
You can do {=u32:#08x}, so apparently we care more about embedded devs who speak hex than devs who speak IEEE-754 float.
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
hi @room, meeting time again! agenda is https://hackmd.io/-u0QJ3xDQxunspS_XOrwfw, please add anything you'd like to announce or discuss and we'll start in a few mins
<dirbaio[m]>
o/
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
👋
<AdamHott[m]>
Hi Bart!
<adamgreig[m]>
ok, let's start! first quick announcement is svd2rust 0.32 and svdtools 0.3.10 released
<adamgreig[m]>
the embedded wg is part of the "launching pad" team in rust-lang and that team is represented on the rust council by someone we elect from time to time
<adamgreig[m]>
currently thejpster, who happens to also be in the wg (though other wgs are in the launching pad team and could also nominate people)
<thejpster[m]>
:/
<thejpster[m]>
* o/
<adamgreig[m]>
anyway, that position is now up for re-election; as I understand it, the plan is to run an election
<adamgreig[m]>
if anyone from the wg is interested in being our representative to the rust council, now's the time to say so, I think; thejpster is there a particular process for nominations yet?
<thejpster[m]>
Nell Shamrell-Harrington is volunteering to lead the election process.
<thejpster[m]>
(from TWIR)
<adamgreig[m]>
I read that but I'm not sure what someone would do if they were interested atm
<dirbaio[m]>
I imagine it'd be good to let the rep be from another WG this time tho 😅
<thejpster[m]>
Talk to Nell?
<thejpster[m]>
ok, the first think you need to do is object to Nell if you don't want her to take the role. If there are no objections, Nell gets the role.
<thejpster[m]>
Then Nell can spell out the process for submitting nomination.s
<thejpster[m]>
But you can't submit nominations until we have someone to run the election.
<adamgreig[m]>
thejpster[m]: the role of running the election, that is?
<thejpster[m]>
correct
<thejpster[m]>
I am likely to re-nominate myself, but I don't want that to put anyone else off.
<adamgreig[m]>
dirbaio[m]: yea, though no harm in having nominees from embedded-wg too
<dirbaio[m]>
embedded wg all the way 🦀
<thejpster[m]>
Also, can I ask people to check with Zulip more often? It's there the project stuff happens.
<thejpster[m]>
I post stuff in t-launching-pad from time to time and it's just #crickets
<cr1901>
Since you asked nicely, I'll see about making an acct
<AdamHott[m]>
Just signed up for the Zulip chat!
<thejpster[m]>
s/there/where/
<dirbaio[m]>
I lurk a lot, but rarely participate becuase I usually don't have anything to say 🤣
<thejpster[m]>
you can read it without signing in, and you can SSO using github
<dkhayes117[m]>
I've finally decided to start my rust embedded podcast, [Rusty Bytes](https://media.rss.com/rustybytes/feed.xml) It's a smol podcast where I'll discuss current events with the WG, major crate releases, etc. Typical run time will 10-20 min per episode.
<dkhayes117[m]>
If anyone has any announcements and such that they want included, just DM me here.
<adamgreig[m]>
oh cool, looking forward to it!
<AdamHott[m]>
awesome
<bartmassey[m]>
What streams in the Zulip chat are important to watch? I find the thing a firehose (and I'm a heavy Zulip user).
<thejpster[m]>
t-launching-pad - you can mute the rest :rofl:
<thejpster[m]>
I skim it and hit MAAR regularly.
NickStevens[m] has joined #rust-embedded
<NickStevens[m]>
As for the item discussing fixedvec - I wanted to float here the idea of deprecating the library. When I wrote it there wasn't anything quite like it, but now there are much better and more modern alternatives like heapless. Thoughts?
<NickStevens[m]>
It still has regular downloads on crates.io but hasn't had any significant code updates in years
<NickStevens[m]>
Alternatively it should be updated if not deprecated 😅
<bartmassey[m]>
If deprecated, it would be great to include fairly detailed instructions in the README about how to migrate to some other recommended crate.
<adamgreig[m]>
is there anything you can't do with heapless::Vec?
<NickStevens[m]>
No, changing over should just be using heapless::Vec I believe, but would want to confirm that
<adamgreig[m]>
we use it in the discovery book iirc so that might want updating too
<NickStevens[m]>
therealprof[m]: Settle for "maintained"?
<NickStevens[m]>
* for "maintained"? 😆
therealprof[m] has joined #rust-embedded
<therealprof[m]>
heapless and modern? 😅
<therealprof[m]>
I just noticed that the crates.io site still points to japarics GH repo.
<NickStevens[m]>
In any case both libraries are trying to accomplish the same thing and it's probably worth making the choice easier. I can investigate more and come back, I mainly wanted to see if there would be outcry over deprecating.
<adamgreig[m]>
no objection to marking it deprecated, archiving the repo, and suggesting people move to heapless. would you push a new release so crates.io/docs.rs update to also say deprecated, or just leave it as-is?
<NickStevens[m]>
adamgreig[m]: Yes definitely
<NickStevens[m]>
> <@adamgreig:matrix.org> no objection to marking it deprecated, archiving the repo, and suggesting people move to heapless. would you push a new release so crates.io/docs.rs update to also say deprecated, or just leave it as-is?
<NickStevens[m]>
* Yes definitely push update to crates.io
<adamgreig[m]>
existing users can keep using it as long as they want after all, but newcomers who find it will presumably have a better time if they are pointed to heapless instead
<NickStevens[m]>
I think that's all I needed to make a concrete plan. Thanks!
<therealprof[m]>
<therealprof[m]> "I just noticed that the crates...." <- Hm, the metadata in Cargo.toml is correct... Not sure why crates.io didn't pick that up.
<thejpster[m]>
we keep going around the loop, but I'm not sure where we track our latest thinking on "dereferencable things can't be volatile"
<dirbaio[m]>
nobody knows :P
<cr1901>
"The proglang equivalent of quantum mechanics"
thalesfragoso[m] has joined #rust-embedded
<thalesfragoso[m]>
thejpster[m]: There's currently a workaround in rustc that makes UnsafeCell not dereferenciable
<dirbaio[m]>
I think latest conclusion was "it's not guaranteed *by the memory model*, but today's *implementation* can't insert spurious reads because `&` references are not marked as dereferenceable if they contain unsafecell"
<dirbaio[m]>
so it's still unsound in theory
<adamgreig[m]>
working through that is on my list of "might be a good topic for rustnl"
<thalesfragoso[m]>
dirbaio[m]: Only refs to UnsafeCell, I would think
<thalesfragoso[m]>
dirbaio[m]: Not sure how they will get around that problem in the Arc implementation
<thejpster[m]>
mmmm. on the unconf list maybe we should also review allllllll the stuff in our github and work out if there is any other old or weird stuff we should deprecate
<dirbaio[m]>
IMO we should stop using and deprecate all the crates using `&` references to volatiles. vcell, volatile_register etc
<thalesfragoso[m]>
Either they will create a new type to avoid dereferenciable directly or will keep the workaround with UnsafeCell
<dirbaio[m]>
the alternative is using raw pointer math, which is clearly sound beyond all possible doubts
<dirbaio[m]>
so why not just use that
<thalesfragoso[m]>
dirbaio[m]: That makes sense, yes.
<cr1901>
"b/c pointers bad"
<thalesfragoso[m]>
Just saying that removing the workaround won't be an easy thing for rustc
<thejpster[m]>
svd2rust did at least recently change to make you do p.PERIPHERAL.register().read() instead of p.PERIPHERAL.register.read().
<thejpster[m]>
actually it's now p.peripheral.register().read(). Which is better, but is going to really upset everyone.
<dirbaio[m]>
yeah, why so many breaking changes? 😬
<thejpster[m]>
because in your application Uart::new(p.UART0) has to change to Uart::new(p.uart0).
<thejpster[m]>
register() is a pre-requisite for deleting the volatile cell
<bartmassey[m]>
Can we have the conversation with the lang team about canonizing the current implementation in the memory model?
<cr1901>
Why the decapitalization?
<thejpster[m]>
afaik
<adamgreig[m]>
the case of the peripheral names is a config option, so pacs can choose to keep the old style too
<thejpster[m]>
because struct Peripherals { UART0: UART } is weird and wrong.
<thejpster[m]>
It's always been struct Peripherals { uart0: Uart } in all other rust code
<cr1901>
(Also, I find it a bit suspicious that for all the complexity of rustc, soundly doing volatile and references together is one thing that's "too complicated, use raw pointers as the only escape hatch")
<dirbaio[m]>
bartmassey[m]: there's already lots of work in defining a memory model (see the Stacked Borrows, then the Tree Borrows efforts, strict provenance APIs on raw pointers, etc). According to these `vcell`, `volatile_register` are unsound IIUC. They're not going to canonicalize the current *implementation* into the memory model.
<thejpster[m]>
hmmm, maybe we should remind the spec people of this problem.
<thejpster[m]>
they seem to be talking about abstract machines and memory models a lot
<dirbaio[m]>
the implementation is always more lenient than the memory model (ie there's things the memory model says are UB, but the implementation doesn't exploit for optimizations)
<thalesfragoso[m]>
cr1901: The problem isn't the volatile operations, but the non-volatiles ones that can be inserted
<bartmassey[m]>
I am aware of the existing memory model work. But UnsafeCell was supposed to be the escape hatch to get the behavior right?
<thalesfragoso[m]>
dirbaio[m]: Well, you can put std::sync::Arc on that list too then
<thalesfragoso[m]>
bartmassey[m]: No, UnsafeCell is included in the model.
<dirbaio[m]>
Arc is also part of the implementation (the stdlib, bundled with rustc), so it's fine for the stdlib to rely on implementation details. it's not fine for us.
<dirbaio[m]>
UnsafeCell is an escape hatch to relax some restrictions of the model, but not all.
<thalesfragoso[m]>
dirbaio[m]: Touché
<cr1901>
Why would Arc be unsound?
<bartmassey[m]>
But we might be able to get the lang folks to add our thing to the UnsafeCell list of rules? I guess I don't see why not, but I'll have to talk to my language friends.
jannic[m] has joined #rust-embedded
<jannic[m]>
Regarding the pac update, adding all these `()` to rp2040-hal when upgrading svd2rust was mostly mechanical busywork, so not too bad. But there was one footgun: Mechanically adding these `()` to `&self.device.sspdr as *const _ as u32` leads to `&self.device.sspdr() as *const _ as u32` which compiles but is wrong.
<thejpster[m]>
dirbaio: I forgot about that ticket. Thank you for the reminder.
<dirbaio[m]>
from rereading that ticket
<dirbaio[m]>
> I'm an outsider here and totally happy with not having VolatileCell, if the domain experts say that the status quo is totally sufficient.
<dirbaio[m]>
IMO the status quo is sufficient, we can use raw pointers just fine
<thejpster[m]>
jannic[m]: what should that have been?
<cr1901>
thalesfragoso[m]: (that Arc q was meant for you)
<dirbaio[m]>
seems the situation is "it's currently unsound, please let us know if this is a problem and we might try to adjust the memory model to make it sound
<dirbaio[m]>
* it sound"
<dirbaio[m]>
but I don't think it is a problem
<jannic[m]>
thejpster[m]: Remove the `&`.
<dirbaio[m]>
the only "downside" is you have to do .register() instead of .register
<dirbaio[m]>
which is fine
<jannic[m]>
The function already returns a reference.
<thejpster[m]>
ah ha ha ha
<thejpster[m]>
ouch
<dirbaio[m]>
yeah that's a fun footgun
<jannic[m]>
I only found the reason why the on-target tests failed by disassembling the binary and comparing old and new versions.
<adamgreig[m]>
really there should probably be a better way to get the pointer/address
<thejpster[m]>
this is getting the address of the MMIO register to give to a DMA engine, right?
<jannic[m]>
adamgreig[m]: There is. `.as_ptr()`.
<jannic[m]>
But it wasn't used before.
<dirbaio[m]>
in the chiptool API it'd be `self.device.sspdr().as_ptr() as u32`
<dirbaio[m]>
but `&self.device.sspdr() as const _ as u32` also compiles fine and does the wrong thing 🤣
<adamgreig[m]>
the other time you need it is for registers where the write size matters, like SPI DR
<bartmassey[m]>
I don't like the potential unsoundness here (offhand): (a) it isn't unsound in practice, which seems like a clue, and (b) the unsoundness leads to easy creation of bugs that won't be caught by the compiler and won't be evident until someone changes the implementation.
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
"unsound" is a property of a piece of code against the memory model
<dirbaio[m]>
the code IS unsound
<bartmassey[m]>
Yes, it is unsound, so either the memory model or the code (or both) has to change.
<thejpster[m]>
another brutal blow for the struct model
<cr1901>
Right *mut doesn't have aliasing problems like in C
<adamgreig[m]>
I'm not sure if svd2rust would generate the correct sized accesses even if the svd had them, but perhaps it does
<thejpster[m]>
dirbaio: stop kicking it, it's dead already
<dirbaio[m]>
lol
<dirbaio[m]>
well now we "just" need someone to PR the change to svd2rust to switch to pointer math 🫠
<dirbaio[m]>
and cortex-m...
<dirbaio[m]>
to actually kill it
<JamesMunns[m]>
Oh man please tag me if there is unsafe pointer shenanigans review
<JamesMunns[m]>
I've learned more cursed knowledge this week.
<therealprof[m]>
I only specialise in cursed C pointer math.
<thejpster[m]>
all C pointer math is cursed. There's no other kind.
<whitequark[cis]>
<adamgreig[m]> "svd2rust always performs a 32..." <- oh man, I've been arguing against misuse of bitfields in C for *so long*
<whitequark[cis]>
(aliasing a register with a bitfield struct in C creates the same issue, gcc picks a memory access width for you basically at random)
<adamgreig[m]>
oh what!
<adamgreig[m]>
that's like the opposite issue
<therealprof[m]>
thejpster[m]: Indeed. But I only do it in C. ;)
<whitequark[cis]>
I think I first hit that in 2011, and C people still think they know what C compilers will do in this case
<adamgreig[m]>
our problem here is svd2rust always generates the same sized access even when you wanted smaller ones
<adamgreig[m]>
having the compiler itself occasionally make different sizes depending on which field is nuts
<whitequark[cis]>
so what gcc would do is it'd generate a byte access to read the lsb, an aligned word access to read the 1st byte, an aligned dword access to read the 2nd byte
<adamgreig[m]>
bitfields are horrifying
<whitequark[cis]>
I designed my C BSP for STM32F100 entirely around bitfields and then had to scrap that design and redo it
<whitequark[cis]>
shortly after I decided to write my own low-level language which wouldn't do stupid shit like that
<whitequark[cis]>
and shortly after that I deprecated it in favor of this new obscure upstart called Rust
<adamgreig[m]>
man, doing no_std binaries in those days was a pita though
<adamgreig[m]>
we sure have it easy now :P
<bartmassey[m]>
This seems like a good Rustconf talk idea. Please consider submitting.
<whitequark[cis]>
I think I wrote that while sitting in an underground train in [redacted] just going back at forth on a single line because going back home would have been deeply unsafe, with the STM32F103VLDISCOVERY devkit sticking out of in my bag, hoping that no one on the train will think anything wrong of that bare PCB with a USB cable plugged into my netbook
<whitequark[cis]>
bartmassey[m]: wait really?
<adamgreig[m]>
iirc that's also how a bunch of gdb stm32 stuff happened? or something like that...
<whitequark[cis]>
whitequark[cis]: I wonder if I still have the devkit? I don't think so to be honest. I do have the DIY micro-USB cable I made like 15 years ago that was plugged into that devkit still, somehow
<bartmassey[m]>
Yes really. Your experience moving from hardcore C embedded dev to Rust embedded dev sounds fun to hear in detail.
<whitequark[cis]>
adamgreig[m]: yes, I wrote gdb support for texane/stlink on the same train line
<whitequark[cis]>
simultaneously with that library
<thalesfragoso[m]>
<cr1901> "Why would Arc be unsound?" <- Basically, dereferenciable marks function arguments, then the argument can be deref for the whole function. Turns out that is a problem in the ref counting in Arc, since the atomic can be deref-ed only up to the point is decremented
<thalesfragoso[m]>
But the compiler as free to add reads after that (and before the function end)
<whitequark[cis]>
bartmassey[m]: ^^; I don't even think of it as hardcore!
<whitequark[cis]>
I think the first time I've been bitten by bitfields was when I was writing this x86 kernel in high school and wrote down the GDT structure as a bitfield and then the compiler inserted padding and I spent days or even weeks trying to figure out why it doesn't boot
<whitequark[cis]>
I was so upset when I found out about that and attribute((packed))
<whitequark[cis]>
* I was so upset when I found out about that and __attribute__((packed))
<whitequark[cis]>
top 10 anime betrayals
burrbull[m] has joined #rust-embedded
<burrbull[m]>
<jannic[m]> "There is. `.as_ptr()`." <- bump msrv to 1.76?
<thalesfragoso[m]>
* Basically, dereferenciable marks function arguments, then the argument can be deref for the whole function. Turns out that is a problem in the ref counting in Arc, since the atomic can be deref-ed only up to the point it is decremented
<thalesfragoso[m]>
s/as/is/
cbjamo[m] has joined #rust-embedded
<cbjamo[m]>
Is the whole top 10 just different ways C lies about memory layout?
<whitequark[cis]>
haha maybe
<whitequark[cis]>
anyway, more on topic, with Amaranth SoC, you actually would not be able to soundly alias registers with a *mut u32 or something because for registers larger than the addressable unit (eg 32-bit registers if the bus is 8-bit addressable), the CSR infrastructure requires the reads and writes to happen in a particular order for atomicity
<whitequark[cis]>
basically, you can define a register that's 6 bytes wide with a 8-bit (or 32-bit) CSR bus, and you will get atomic accesses that look like a single-cycle access to the whole register to the peripheral in both cases, with no tearing
<whitequark[cis]>
however, you have to do both reads and writes in specifically the 0-1-2-3-4-5 order, or you will get results that make no sense
<whitequark[cis]>
internally, when you read the 0th byte, the other 5 are latched and held, and when you write the first 5 bytes, they are latched and held until the 6th is written too
<adamgreig[m]>
how do you handle concurrency?
<adamgreig[m]>
some multi-word timer peripherals in e.g. real-time clocks and ethernet ptp peripherals do this: reading the first field locks the rest, so you can read them all in sequence and get an atomic read
<adamgreig[m]>
which is great until you want to access the field from two places at once, and then it's terrible :P
<therealprof[m]>
Track the origin of the request?
<cr1901>
Reminds me a bit of MIPS HI/LO needing to be invalidated on context switch
<whitequark[cis]>
adamgreig: CSRs are aggregated into register groups (where a single bank is just any amount of registers behind a single CSR bridge) and registers within a single group follow what is basically the Rust ownership model: exactly one piece of firmware code that owns the register group can access it
* Ralph[m]
was hoping that https://github.com/rust-embedded/embedded-hal/issues/576 could be discussed today, but i guess it'll have to wait for next week? (i'd like to finally get the PR merged in my lib and am waiting for an official statement on this)
<whitequark[cis]>
this is actually not solely for this feature, this is a general usage model that's going to be formalized rather than just implied
<cr1901>
thalesfragoso[m]: since the atomic can be deref-ed only up to the point it is decremented <-- eww
<whitequark[cis]>
we will also encourage splitting of the peripheral into register groups in such a way that you can concurrently access features of the peripheral that are independent, for example cutting the UART into an UAR and UAT
<therealprof[m]>
UAR and UAT. 🤣
<adamgreig[m]>
I'm excited to try it out!
<AdamHott[m]>
what would be the process if I wanted to join the resources team? is there a vote for that? I was hoping to help with the Discovery Book.
<adamgreig[m]>
the process is to open a PR adding yourself to the team list, but usually that happens after making some PRs and contributions
<therealprof[m]>
Create a PR to add yourself to the list.
<adamgreig[m]>
you don't need to be in the team to make changes to the book, just to review/merge other people's changes
<whitequark[cis]>
adamgreig: interestingly, this will result in having a pair of baud rate registers, since the baud rate generator can't really be shared anyway, the one in the receive half has to be resynced on start edge
<AdamHott[m]>
ok sounds good!
<whitequark[cis]>
and it's not like we're going to run out of register address space if we add checks notes one address
<adamgreig[m]>
no reason for uart baud rates to be symmetric anyway :P
<whitequark[cis]>
that too
<whitequark[cis]>
it does go against the common knowledge about how an UART peripheral should look like though
<whitequark[cis]>
so I'm wondering how many people are going to look at the docs, decide that it's too weird and close it
<whitequark[cis]>
of course we'll have a 16550 compatible register map too, but where's the fun in that
<therealprof[m]>
There're worse problems to have than configuring a baud rate generator twice...
<adamgreig[m]>
therealprof / dirbaio / other HAL team: do you think https://github.com/rust-embedded/embedded-hal/issues/576 is worth writing up in the migration guide or otherwise having a stance on, or just see what driver authors end up doing?
<therealprof[m]>
whitequark[cis]: Awww, that throws me back 30 years.
<dirbaio[m]>
adamgreig[m]: we discussed this a few weeks ago, iirc conclusion was recommendation is to pass errors up with generics?
<dirbaio[m]>
I do think it'd be valuable to have some docs and examples on how to do that
<dirbaio[m]>
perhaps it's more of a "book" materal, how to write an embedded-hal driver
<therealprof[m]>
adamgreig[m]: What @dirbaio:matrix.org said...
<dirbaio[m]>
but as usual, someone will have to go and write it
<dirbaio[m]>
.. :D
eldruin[m] has joined #rust-embedded
<eldruin[m]>
adamgreig[m]: that problem actually predates the 1.0 release. We can definitely add some docs with guidance on how to do it and _what you can do now after 1.0_ but I think that would be better somewhere in the general docs, not only in the migration guide
<adamgreig[m]>
could you stick that in a comment on the issue, at least?
<dirbaio[m]>
so i'm not sure what the OP in that issue is expecting from us
<dirbaio[m]>
to write the book page as a response on the issue thread? :P
<adamgreig[m]>
or just "yes, drivers should pass errors up by using generics"
<jannic[m]>
therealprof[m]: Hah, what a great day, replacing that 16450 by a 16550 and finally getting more than (what was it? 1200bps?) without losing bytes.
<Ralph[m]>
FYI: i put the issue back on today's agenda because there was no final conclusion on the issue itself. while there seems to be a consensus of those who had already answered there, i have no guarantee that it's "the proper/official thing" to do in drivers.
<Ralph[m]>
i'm fine with just having an official statement in the issue in a first step, then i can go ahead with the PR on my driver to finally move to e-h 1.0 (with the fallible pins) and release that.
<dirbaio[m]>
I don't think there should be an official statement saying "you MUST pass up errors, and you MUST do it THIS way"
<dirbaio[m]>
* THIS way" though
<eldruin[m]>
wrapping the error and passing it with generics is the best thing you can do. That was the approach that motivated the whole Error trait ErrorKind mechanism. With that drivers can interpret an error and an application can see through it.
<dirbaio[m]>
passing up errors is a general Rust best practice, so it follows from that that it's what you should do in an embedded-hal driver
<dirbaio[m]>
but still there's many different use cases, and what's best might depend on the use case
<dirbaio[m]>
for example for no-std+no-alloc drivers if you want to pass up the errors you must use generics
<dirbaio[m]>
but for a driver using std+alloc it might be easier to use anyhow/thiserror
<dirbaio[m]>
perhaps the driver already needs std or alloc due to other reasons, in that case going through the pains of using generics to return errors might not be worth it
<dirbaio[m]>
etc etc
<whitequark[cis]>
<whitequark[cis]> "anyway, more on topic, with..." <- (my general observation is that the only unconditionally correct way to manipulate CSRs is with small inline assembly snippets that perform the bus cycle in question, which also completely eliminates the reliance on `volatile` or similarly poorly defined operations)
<whitequark[cis]>
(this also lets you mark reads as side-effectful and non-side-effectful so that you can get optimizations on things where the read can be discarded and don't let the compiler break your code where it can't be)
<whitequark[cis]>
CSRs aren't really memory in almost any practical sense and trying to use high level memory operations to use them eventually will result in pain, the question is just how far down the road and how bad the workaround will be
<bartmassey[m]>
To be fair, because C more modern chips have tried to make CSRs look more like memory 😀
<whitequark[cis]>
there are some chips that make CSRs much more C-friendly, this is true
<whitequark[cis]>
old-school PICs like PIC16F628A would often alias two different registers on the same address, one for read, one for write (like UART RX/TX but worse, since you could reasonably want to read from the register that's write-only just for address space conservation purposes) and that was bad even in assembly
<adamgreig[m]>
and then bank switch on top o fthat
<bartmassey[m]>
Thanks for the PIC PTSD flashback 😀
<whitequark[cis]>
like you can't bitbang anything with bit set/clear commands because your PORT (pin input/output) register doesn't support RMW cycles. At all
<whitequark[cis]>
bartmassey[m]: this was my first embedded target ever. I was in high school. I don't think I ever recovered
<bartmassey[m]>
Ikr?
<whitequark[cis]>
this is why I'm like this
<bartmassey[m]>
We used to scatter PICs through our freaking rockets. Such a bad idea. The hardware folks love them if someone else writes the software.
<whitequark[cis]>
you know what's the most infuriating part? you can't even switch from bank 0 to bank 3 in one instruction, and the goddamn thing would take 4 cycles to do a bit flip on the bank register. FOUR CYCLES, BART.
<whitequark[cis]>
* CYCLES, BART. AT SIXTEEN MHZ
<bartmassey[m]>
😆
<whitequark[cis]>
I am sure whoever designed that thing to be taped out on like 250nm with, presumably, rubylith, straight edge, and a pencil felt very accomplished
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
My first embedded target was the PIC10F200 because I found out that you could buy them for 20 cents each. I was way over my head, but I think it did get one to blink an led eventually
<whitequark[cis]>
however, we as a society have outlived the need for PICs. No More Eight Bit MCUs (unless it's a 8051)
<bartmassey[m]>
You can now get an ARM for under a dollar… with floating point!!
<whitequark[cis]>
(mainly because if we stop using 8051s the entirety of industry on this planet will collapse instantly)
<whitequark[cis]>
bartmassey[m]: have you seen that chip which has 8051, G-class RISC-V and a Cortex-A simultaneously, with a hard strap choosing between C906 and A53?
<adamgreig[m]>
250nm?? they were >>1µm for the early PICs iirc
<whitequark[cis]>
adamgreig: huh I should decap one
<whitequark[cis]>
I don't have a microscope but I could probably take decent die shots with a loupe
<whitequark[cis]>
* a microscope (not anymore) but I
<whitequark[cis]>
> <@po8:matrix.org> You can now get an ARM for under a dollar… with *floating point*!!
<whitequark[cis]>
* have you seen that chip which has 8051, G-class RISC-V and a Cortex-A simultaneously, with a hard strap choosing between C906 and A53?
<whitequark[cis]>
actually it seems like it has two RISC-V cores, so you could have a 8051, a C906, and an A53 on the same bus?
<whitequark[cis]>
whitequark[cis]: > <@whitequark:matrix.org> have you seen that chip which has 8051, G-class RISC-V and a Cortex-A simultaneously, with a hard strap choosing between C906 and A53?
<bartmassey[m]>
I have a bunch of Milk-V boards, but haven't had time to play with them. They are weird and weirdly cheap.
<AdamHott[m]>
I forgot, who all is working on updating the Discovery Book? I know dirbaio , anyone else?
<bartmassey[m]>
I think @dirbao might be the only one currently working on the transition to the Embassy ecosystem.
<bartmassey[m]>
Once I get some stuff done with `nrf52833-hal` and `microbit`, I hope to update the current book in minor ways soon.
<bartmassey[m]>
I'm way behind on this compared to where I want to be right now.
<bartmassey[m]>
s/dirbao/dirbaio/
<adamgreig[m]>
Catherine looks like a lot were 1.2µm, can't find a size for the early PICs though
<bartmassey[m]>
There's a whole long discussion to be had in the next week or two on how to stabilize the nrf-hal and microbit crates in a good place. I would like to get updated versions onto crates.io in a shortish timeframe.
<bartmassey[m]>
In the meantime, look over the issues there and ping me here or on the nRF Rust matrix
<AdamHott[m]>
ok what's the nRF matrix room?
<AdamHott[m]>
can you send me the link?
<bartmassey[m]>
Working on it. One sec. Matrix is hard.
<AdamHott[m]>
ok
<whitequark[cis]>
whitequark[cis]: that 20um scale bar is 265 px, and the smallest feature I can find is 22 px. so... 1.66um?
<whitequark[cis]>
not exactly a scientific measurement admittedly ^^;
<bartmassey[m]>
Done.
<whitequark[cis]>
oh, reading the page, it says 700nm
<bartmassey[m]>
I am wondering if we need a separate Microbit space, honestly. We'll see what the traffic is.
<bartmassey[m]>
Catherine: That is *so* sub-micron 😀
<bartmassey[m]>
GTG all, things to be done.
<AdamHott[m]>
bartmassey[m]: ok
<whitequark[cis]>
I really want to get an ASIC made with one of my designs but I feel like I'm more ambitious than what TinyTapeout can do, and also too busy to negotiate it with a shuttle or anything. though, weirdly enough, people have already taped out my cores before, which I only learned after the fact
<whitequark[cis]>
the really strange world of open hardware when you never hear about your design being used in an ASIC because it works well enough there's no reason to complain
<whitequark[cis]>
s/when/where/
<thejpster[m]>
My MPW3 arrived this week
<whitequark[cis]>
what design is it?
<thejpster[m]>
Mine was Zube - a Z80 compatible Tube style interface
<thejpster[m]>
just a couple of FIFOs on a Z80 bus interface which the risc-v can talk to. But I think MPW3 is really broken though.
<whitequark[cis]>
yeah, IIRC they ignored a bunch of hold time violations and nothing works
<whitequark[cis]>
STA: Turns Out It's Important After All™
<bartmassey[m]>
I think Google is providing free shuttles for OpenHW projects? I'd have to find the link to the program.
<whitequark[cis]>
I actually work for a company which provides a commercial platform and shuttle runs as a service
<bartmassey[m]>
Ah. Nice.
<whitequark[cis]>
except I'm too busy maintaining the frontend to have any nontrivial amount of time left to build a design ^^;
<whitequark[cis]>
classic example of toolmaker's curse
<bartmassey[m]>
Yeah. Time is always the limiting resource.
<whitequark[cis]>
it would also feel pretty weird to take a vacation on which I would ... still use the commercial product of the company I work for, that I maintain
<bartmassey[m]>
Yeah, that would be a non-starter for me.
<bartmassey[m]>
Really need to go. Hope to talk again soon. 👋
<whitequark[cis]>
ttyl
<thalesfragoso[m]>
<cr1901> "thalesfragoso: Btw, you mean..." <- Yes.
barafael[m] has quit [Quit: Idle timeout reached: 172800s]
<vollbrecht[m]>
Hope they don't read [cve-rs](https://github.com/Speykious/cve-rs) :D Its just funny that even in safe rust there is no 100% bullet proof'nes with respect to memory safety. I mean its to be expected as any sufficient complex system will have its edge cases. I still love rust and don't want to trade it in.
<vollbrecht[m]>
Though one never should just build blindly on a promise. Still in 99.9% it works perfect.
<NickStevens[m]>
Rust: takes extremely deep knowledge to create memory unsafety. C: takes extremely deep knowledge to "create" "memory safety".
<vollbrecht[m]>
its nice to be able to cast lifetime 'a to a lifetime 'static. Its just like in C where you just can cast anything to void as an rough analogy. That opens up so much possibility's :D