<chrysn[m]>
Hmpf, I had hoped to announce a first demo of my server+client CoAP stack that is async, no_std, no_alloc and builds on embedded-nal -- but after running into an ICE I rather let it sit a night and see whether the right branch of rustc fixes things tomorrow :-/
Guest7221 has left #rust-embedded [Error from remote client]
IlPalazzo-ojiisa has quit [Ping timeout: 245 seconds]
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
wose has quit [Server closed connection]
wose has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
hi all, I'm having trouble with a HAL crate that I'm writing, and trying to use `riscv-rt` to test it on real hardware. got it to the point where I can load the binary into ram from u-boot, but even a "hello world" app with just a spinning loop traps on an "Illegal Instruction" fault
<rmsyn[m]>
do `ricv-rt` binaries need to be loaded at a specific address?
<rmsyn[m]>
have also tried loading the binaries into qemu using the riscv64 `virt` machine (real hardware is the VisionFive2), and when I attach `riscv64-elf-gdb` it just shows garbage, no symbols (for debug and release binaries)
<rmsyn[m]>
similar when I attach gdb-over-JTAG with openocd, just garbage output
<rmsyn[m]>
fairly new to embedded dev, so probably doing something dumb. any help is greatly appreciated
nadja has quit [Server closed connection]
nadja has joined #rust-embedded
thejpster[m] has joined #rust-embedded
<thejpster[m]>
<rmsyn[m]> "do `ricv-rt` binaries need to be..." <- Yes, the address you told the linker you were loading it at.
<thejpster[m]>
Also it sounds like you are booting with OpenSBI and so you probably need to enable the s-mode feature in riscv-rt. otherwise itβll do an illegal instruction trying to find out how many harts there are.
<diondokter[m]>
Hmmm yeah, googling around I can't find anything. I could easily make it 15-bit by just stripping off a bit and do odd parity with that
corecode has quit [Server closed connection]
corecode has joined #rust-embedded
cyrozap has quit [Server closed connection]
cyrozap has joined #rust-embedded
<adamgreig[m]>
<diondokter[m]> "Hmmm yeah, googling around I can..." <- I would just special case encode 0 as 1 and ffff as fffe, I think it will be stronger overall than truncating to 15bit and adding odd parity
<diondokter[m]>
adamgreig[m]: I guess, with 15-bit everything is half strength yeah instead of just 1 and 2
exark has quit [Server closed connection]
exark has joined #rust-embedded
richardeoin has quit [Ping timeout: 240 seconds]
richardeoin has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
<dirbaio[m]>
you can do a 32bit crc and (crc_u32 % 0xFFFD) + 1
<dirbaio[m]>
that spreads out the bias
<dirbaio[m]>
s//`/, s/0xFFFD/0xFFFE/, s//`/
<diondokter[m]>
Hmmm, yeah that might work too
<dirbaio[m]>
(also, 0xFFFE, not 0xFFFD)
<diondokter[m]>
I saw in ekv that you made your own crc implementation. Is that just to avoid the lookup table?
<dirbaio[m]>
yeah, because the "typical" 8bit lookup table gets too big for 32bit crcs (1024 bytes)
<diondokter[m]>
Ah ok... Hmmm, I wanted to use the CRC crate, but they do use a table
<dirbaio[m]>
there's a way to do a 4bit lookup table, which makes the table 64 bytes
<diondokter[m]>
for crc16 it's a 256 byte table
notgull has quit [Ping timeout: 260 seconds]
<dirbaio[m]>
which I think is a better size/speed tradeoff
<dirbaio[m]>
but I couldn't find a ready-made impl and was lazy so I just did it bit by bit
<dirbaio[m]>
diondokter[m]: isn't it 512b? 256 entries 16bit each
<diondokter[m]>
Ah, you're right
<diondokter[m]>
Mind if I copy your impl then? :P
<adamgreig[m]>
What properties do you want exactly? I'd be wary of truncating a 32bit CRC and hoping to guarantee the normal properties of a crc16
<dirbaio[m]>
sure
<adamgreig[m]>
Plus that mod operation is expensive, as is computing a 32b crc vs a 16 bit one
<diondokter[m]>
Well, most flash is slow anyways, so I don't mind a bit of compute tbh
<diondokter[m]>
It's just a checksum
<adamgreig[m]>
But it's just wasted afaict
<diondokter[m]>
To check if what's stored in flash is probably ok
notgull has joined #rust-embedded
<adamgreig[m]>
If you just want 16 bits that check you probably didn't get errors, I'd just compute a 16 bit crc, serially if you want to avoid the lookup table, then check if the output was 0 or ffff and replace with 1 or fffe, it's super cheap and quick and just as good as anything else you do with the same output properties
<diondokter[m]>
Yeah, that's what I just made
<adamgreig[m]>
If you have space for a 32 bit crc that's much better, depends on how long the data being protected typically is
<adamgreig[m]>
But if you're using 16 bits I don't think any other construction will be more protective than just computing a crc16, but they probably will be way more work to compute, so...
<diondokter[m]>
Typically short (though the user decides).
<diondokter[m]>
I want 16-bit because it's stored next to a 16-bit length field. That way it neatly fits in a 4-byte flash word
<diondokter[m]>
Actually, a length of 0 doesn't make sense. So that way I can allow 0xFFFF for the crc
<adamgreig[m]>
hmm
<adamgreig[m]>
don't forget erased flash is 0xFFFF
<diondokter[m]>
Yes, that's why. My header consists of len + crc.
<diondokter[m]>
If they are all FF, then it's erased.
<diondokter[m]>
But I can subtract 1 from len, so max len is not FFFF.
<adamgreig[m]>
nice
<adamgreig[m]>
why can't you allow 0 for crc?
<adamgreig[m]>
(will the checksum be erased without erasing the length?)
<diondokter[m]>
Because I want to be able to erase an entry. This only works for multiwrite flash
<diondokter[m]>
Yes
<adamgreig[m]>
ah, so you want to be able to keep the length to know how long the deleted entry was, but set the crc to all-0 to mark it as deleted?
<diondokter[m]>
How'd you choose that polynomial though?
<JamesMunns[m]>
You could bitwise invert the len
<diondokter[m]>
JamesMunns[m]: I guess. Makes it more difficult to debug though...
<JamesMunns[m]>
So FFFF would be zero, and then yeah a (u16, u16) that is guaranteed never to be FFFFFFFF
<adamgreig[m]>
it's a more or less random choice. this example computes crc16-ccitt with bytes processed LSbit-first, which is more or less irrelevant for flash storage
<adamgreig[m]>
it's the same as the 0x1021 polynomial you see often
<JamesMunns[m]>
Are your blocks 16KiB including the checksum and Len?
<diondokter[m]>
No, excluding
<diondokter[m]>
And up to. I think most users will only store up to say 200 bytes in an entry
<adamgreig[m]>
yea, this example was originally written to match the crc poly in hardware in some micro, you could do better if you know something about the typical length of your inputs
<adamgreig[m]>
I like 0xa2eb for messages typically around 256 bytes
<cr1901>
Is there a reason for why 0xa2eb is better for short msgs (just curious)?
<adamgreig[m]>
it's more or less the same goodness as 0x1021 for messages longer than 11 bytes really
<adamgreig[m]>
both will detect any 1, 2, or 3 bit errors in up to about 16kB messages, but 1021 doesn't guarantee to ever detect a 4 bit error, while a2eb will detect all 5 bit errors up to 11 bytes
<adamgreig[m]>
so if you have sometimes quite short things to protect like headers, but also sometimes longer things where you at least want the 3 bits, it's nice
<adamgreig[m]>
though when I said 16kB I should have said 4kB, not sure what happened in my head there lol
<adamgreig[m]>
conversely 1b2b will detect 2 bits up to 65kbit which is better, but only detects 3 bits up to 1149 bits, which is worse
<cr1901>
I know what hamming distance is, but I don't remember what that means in the context of "message appended with CRC"
<diondokter[m]>
adamgreig[m]: Yep, but that's the one I just went with
<cr1901>
is that just a way of saying "if hamming distance is 1 up to incl 4, doing the polynomial division w/ that CRC is guaranteed to be nonzero/wrong?
<adamgreig[m]>
cr1901: it refers to the HD of the set of codewords, which are message appended with CRC, and if you have HD=3 then all 2-bit error patterns will definitely be detected
<cr1901>
Ooooh okay
<adamgreig[m]>
HD=3 means there exist two codewords (ie valid message+crc combo) that are only 3 bit flips away from each other
<adamgreig[m]>
but no less
<adamgreig[m]>
therefore any two bit flips will always generate an invalid codeword
<adamgreig[m]>
only for codeword lengths up to that bit length
<cr1901>
And what I said re: "CRC division being nonzero" is a conseqeunce of that
<adamgreig[m]>
yea
<JamesMunns[m]>
Adam will correct me if I'm wrong, but naiively you assume that a 16-bit crc would get a false positive at a rate of 1/65536, but if HD=3, it means that ALL 3-bit errors will be detective, basically better than 1/65536
<adamgreig[m]>
so 1b2b gets you all 2-bit errors up to 65519 bits, but only all 3-bit errors up to 1149, while a2eb gets you all 2-bit and 3-bit errors up to 32751 bits, and all 4-bit and 5-bit errors up to 93 bits
<cr1901>
CRC16s can detect all burst errors of up to 16 bits, 17 bits with a false pos of 2/65536 and 18+ bits with 1/65536
<adamgreig[m]>
yea, the 1/2^n probability is the degenerate case when you've had a shitton of bit errors and you're just hoping you don't get a random collision
<adamgreig[m]>
cr1901: no, it's more complicated
<JamesMunns[m]>
*will be detected, not "will be detective" lol
<adamgreig[m]>
you can detect all bursts up to 16 bits long, any pattern of (HD-1) single bits anywhere in the message (non-burst), and then a false pos of 1/65536 for more bit flips after that
<adamgreig[m]>
the middle property is often the most important
<diondokter[m]>
The website doesn't mention HD 2. Why is that? Or can a CRC16 detect any 1 bit error in infinite data?
<adamgreig[m]>
yes (like parity)
<diondokter[m]>
Right
<cr1901>
adamgreig[m]: I _did_ say burst error :P. I.e. not the middle property
<cr1901>
I proved that once. I was so proud of myself... and then I looked at the proof I wrote a few months ago and I didn't understand what I wrote :(
<adamgreig[m]>
hah, fair, everything you said was true but missed the important detail of small number of non-burst bits being detected too
<cr1901>
indeed :D
<cr1901>
17 bits is a weird case; IIRC the false pos rate is 2/65536, but only for 17 bits
<cr1901>
but I could be wrong
<adamgreig[m]>
for most CRCs they guarantee to detect all odd-numbered bits in error too
<adamgreig[m]>
so 17 bits would always be detected
<adamgreig[m]>
(it depends on the polynomial)
<cr1901>
Ahhh that's true. I think I must've proved it for a "generic" CRC, not the ones with the zero bit set
<adamgreig[m]>
it's just not very useful to think about because you generally can't be sure you'll only get an odd number of bit errors, but sometimes this fact has funny implications with other coding layers, like if you're using 8b10b which has a running disparity
<cr1901>
Oh?
<adamgreig[m]>
8b10b will detect any single-bit error, but if you have more than one error in the 8b10b code it instead decodes incorrectly, which can give you more errors in the data that the crc is checking than you actually got in the physical layer
<adamgreig[m]>
but the number of errors you can get is bounded within each byte by the coding in a way that had some implications for wanting to choose a crc polynomial that did detect all odd-numbered error patterns
<cr1901>
Where can I learn more about this? :o
<cr1901>
Sounds neat!
<cr1901>
Tbh, I would figure Benford's Law would in general make it more likely that zero bit errors are more common than one bit errors are more command that two bit errors are more...
<cr1901>
common*, jeez I'm operating at like 20% today
<adamgreig[m]>
honestly idk, if you find anything good let me know, I couldn't find much public research :P there's various interest in crc interactions with coding layers (koopman did a lot of it), but specifically 8b10b seems rarer
<adamgreig[m]>
my job involves a lot of crcs but not enough crcs :p
<cr1901>
Just append a CRC onto the CRC
<adamgreig[m]>
i haven't done anything more than read those things and think briefly about it, i would love to either find or do more thorough work into 8b10b+crc (it is relevant for work)
<adamgreig[m]>
but the consensus seems to be "it's probably good enough, yolo"
<cr1901>
I'll add them to my personal wiki to study later
<adamgreig[m]>
the first link, the email, is the most succinct explanation for specifically 8b10b and ethernet with its 32bit crc
<cr1901>
Cool, I saved the links/relevant part of the convo. And now my hyperfocus of sending out emails/msgs to ppl I need to contact has subsided.
<cr1901>
For some reason the CRC talk also got caught up in my hyperfocus this morning
<cr1901>
adamgreig[m]: What time is the meeting in UTC? I think I need to adjust my alarm but Idr
<adamgreig[m]>
1900 UTC
<adamgreig[m]>
I think now that europe and us are in winter time it should be the same time as normal
<cr1901>
Ahhh right
<cr1901>
Although that doesn't excuse my absence last week lol
<cr1901>
(Not that you care, it's not like I'm not-contactable. I just notify you out of courtesy)
romancardenas[m] has joined #rust-embedded
<romancardenas[m]>
Has anyone been using RustRover for embedded?
diagprov has quit [Server closed connection]
diagprov has joined #rust-embedded
<fu5ha[m]>
Has there been discussion in here before about changing readback buffer arguments in `e-h` that are currently in the form of `&mut [u8]` to `&mut [MaybeUninit<u8>]`?
NishanthMenon has quit [Server closed connection]
NishanthMenon has joined #rust-embedded
<ryan-summers[m]>
Honestly, I'm very much so against that idea. MaybeUninit just ends up being so unwieldy in my opinion. It's supposed to be painless, but I find it anything but
<cr1901>
Can you even easily convert &mut [u8] to &mut [MaybeUninit<u8>]?
<ryan-summers[m]>
Trying to navigate what is and is not okay as defined by the compiler ends up being really complex and it becomes easy to add in undefined behavior
<ryan-summers[m]>
> Moreover, uninitialized memory is special in that it does not have a fixed value (βfixedβ meaning βit wonβt change without being written toβ). Reading the same uninitialized byte multiple times can give different results. This makes it undefined behavior to have uninitialized data in a variable even if that variable has an integer type, which otherwise can hold any fixed bit pattern:
<fu5ha[m]>
cr1901: You can always convert a `&mut [u8]` to a `&mut [MaybeUninit<u8>]` by just casting it. The problem is that you can do stuff with the `&mut [MaybeUninit<u8>]` that would make it invalid to view that buffer as a `&mut [u8]` again afterward
<fu5ha[m]>
So yes, it's definitely hazardous, and that is a definite downside. But, the downside of requiring `&mut [u8]` everywhere is you need to zero the whole buffer before passing it through
<fu5ha[m]>
* to zero-init the
<ryan-summers[m]>
Yeah, exactly. Hence my utter aversion to it at every possible moment. Zero-initializing smaller buffers of i.e. 128 bytes are essentially zero-cost anyways
<ryan-summers[m]>
If you need that much perfomance out of your system, you're likely not using trait abstractions anyways
<diondokter[m]>
Has anybody looked if the compiler optimizes the memset away? Because, it might
<ryan-summers[m]>
Hmm interesting point, since it will obviously see the redundant writes to the addresses from the data regs of the peripheral. Haven't looked myself though
<fu5ha[m]>
It definitely can in certain situations but it's not reliable especially when you need it to actually monomorphize 4 generics and inline a stack of 5 trait function calls to be able to prove it can
<fu5ha[m]>
I'm sure it will in some cases though
<cr1901>
>The problem is that you can do stuff with the `&mut [MaybeUninit<u8>]` that would make it <-- there's an "assume_uninit"? I thought once you assume_init, there's no going back
<cr1901>
> by just casting it <-- yea I meant w/o transmuting it :P
<fu5ha[m]>
What I mean is, let's say you have a valid fully initialized buffer of u8, i.e. an `&mut [u8]`. Then you reborrow-cast it to a `&mut [MaybeUninit<u8>]` and pass it to a function that knows it can now write padding/de-initialize parts of that buffer since it's dealing with `MaybeUninit<u8>`s. But then once that function is over, the reborrow drops and you can go back to using it as the original `&mut [u8]`, but now there's uninit
<fu5ha[m]>
bytes inside and bam, UB
<cr1901>
How do you write padding/de-initialize parts of a &mut [MaybeUninit<u8>]?
<cr1901>
(I thought an array of u8 will have no padding between elements. Are you saying "use the &mut [u8] as storage for something that's _not_ an array of u8"?)
<cr1901>
fu5ha[m]: Do you have a playground snippet? I can't visualize what you mean
<fu5ha[m]>
""use the &mut [u8] as storage for something that's _not_ an array of u8" Yes, that would be one way. Or you just write a `MaybeUninit::<u8>::uninit()` directly into a slot in the original slice :P Of course that seems like a silly thing in isolation but it could happen in some more complex scenario. We could solve this by making the trait implementation unsafe and guaranteeing to the user that the implementation is not allowed to
<fu5ha[m]>
de-initialize any pieces of the buffer that were already initialized though, only to write valid u8s at arbitrary locations within it.
tafa has quit [Server closed connection]
tafa has joined #rust-embedded
<fu5ha[m]>
One other problem is we'd need a way to tell the user which part(s) are guaranteed to be initialized upon return. I.e. on error they can't be sure that any of it is initialized, or on success it's guaranteed at least as long as XXX based on the inputs or something.
<ryan-summers[m]>
Or we leave it as is and don't touch any of this cursed behavior
<ryan-summers[m]>
* cursed behavior. This just sounds like pointing a gun at your foot
<ryan-summers[m]>
What's the desire behind it specifically? It can't be for smallish buffers being zero initialized
<fu5ha[m]>
Yeahhhhhhh. Probably it's best to leave it to drivers/applications to try to optimize any large buffers they have like this and make sure the pieces they're sending through the hal are actually initialized
<ryan-summers[m]>
It's exceptionally rare to have super large SPI/I2C buffers for transmission/reception in my opinion. Small ICs generally don't have memory spaces large enough to support big buffers of data
<ryan-summers[m]>
Generally its a small amount of data read cyclically, which is usually handled via DMA instead of via large buffers
<fu5ha[m]>
The desire was to be able to pass a `[MaybeUninit<u8>; 512]` through spi read/transfer without initializing it
<fu5ha[m]>
> t's exceptionally rare to have super large SPI/I2C buffers for transmission/reception in my opinion
<fu5ha[m]>
Heh, I'm probably dealing with the two most common of those. SD cards and display drivers with internal framebuffers
<ryan-summers[m]>
Is the 512 bytes actually causing problems for initialization? You can always just move it to static so it initializes before main() and then never again afterwards
<ryan-summers[m]>
Which solves 99% of the problem with zero work
<fu5ha[m]>
Well, I can't quite just do that here because the 512 byte block buffers are being created inline on the stack in the sdmmc driver
<ryan-summers[m]>
Ah gotcha
<fu5ha[m]>
Though to be fair I have not actually benchmarked this nor inspected the assembly to see whether this is actually my problem. I'm also being a bit dumb with initialization of the larger buffer I'm reading things into, which was the original thing I set out to fix, but got a bit carried away trying to pipe it down as far as I could haha
<adamgreig[m]>
I mean, if it's a &[u8; 512], can you just create it on the stack as maybeunint and then assume_init() π
<fu5ha[m]>
π€―noooooo hahaha, that's like, the biggest gonna blow up in face way to do this
<adamgreig[m]>
fu5ha[m]: right, do this first :P
<cr1901>
"use the &mut [u8] as storage for something that's _not_ an array of u8" <-- hmm can you even do this without insta-UB, even with transmute?
<cr1901>
https://doc.rust-lang.org/std/mem/fn.transmute.html says "If the code just wants to store data of arbitrary type in some buffer and needs to pick a type for that buffer, it can use MaybeUninit.", but doesn't elaborate
<cr1901>
the examples in transmute use arrays, not references/slices
<fu5ha[m]>
Yes, you can us a `&mut [MaybeUninit<u8>]` as storage for anything that is <= size of that slice. But! You do need to verify alignment. But let's just say the caller promises to align the base pointer of the slice properly for your `T`, you can just cast the `&mut [MaybeUninit<u8>]` to a `&mut MaybeUninit<T>` and then write a `T` into that with `MaybeUninit::write`
<fu5ha[m]>
s/us/use/, s/<=/\<=/
<fu5ha[m]>
Let me playground it with miri, one sec
<cr1901>
Please take your time, I appreciate the example
<cr1901>
actually, won't the transmute fail b/c sizeof(&[T}) != sizeof(&T)?
<cr1901>
(slices carry size info)
pronvis has joined #rust-embedded
<fu5ha[m]>
Yes, that's why you don't want to use transmute directly (transmute is very very rarely the right tool for the job even when you're doing direct type punning like this)
<cr1901>
*mut MaybeUninit<T> as *mut MaybeUninit<u8>" <--- ahhh. I didn't know you could do that.
<cr1901>
And indeed Miri doesn't bitch... very cool!
<JonathanDickinso>
no aliasing, no problems
<cr1901>
Indeed, but I'm still scared enough of using unsafe for type punning that I think it's insta-UB when I even _think_ about it :D
<cr1901>
Anyways re: MaybeUninit in embedded-hal, I'm not particularly fond of how E-hal traits don't play nice w/ static buffers (or interrupts). That seems to be related to your issue of "I don't want sdmmc to own/initialize the block buffers".
<cr1901>
Assuming I understand " because the 512 byte block buffers are being created inline on the stack in the sdmmc driver" correctly
cr1901 has quit [Server closed connection]
cr1901 has joined #rust-embedded
andresovela[m] has joined #rust-embedded
<andresovela[m]>
Off topic: what matrix client is everybody using? Iβm currently using Element but I find it very glitchy. Not sure if there are better alternatives out there
<andresovela[m]>
Iβm pretty much using it just for rust stuff
<andresovela[m]>
So Iβm not very familiar with that ecosystem
<cr1901>
The IRC bridge works fine :P
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
<JamesMunns[m]>
> *mut MaybeUninit<T> as *mut MaybeUninit<u8>
<JamesMunns[m]>
fwiw, you can also just do `ptr.cast::<MaybeUninit<u8>>()`
<JamesMunns[m]>
I uh, do a lot of unsafe type punning. IMO tho I really prefer keeping "do stuff with safe rust and references" and "do stuff with unsafe rust and pointers" as separate as possible. Most of the UB I've seen comes from mixing pointers and references, and having references accidentally invalidate other ones, etc.
<JamesMunns[m]>
basically: once you need a little unsafe, it's usually best to entirely switch to pointers, do what you're gunna do, and then move back.
<JamesMunns[m]>
also, I'd probably be more supportive of including maybe-uninit style interfaces in e-hal if the work towards "write only" references gets done/stabilized. Otherwise I'd agree it's probably a little too footgunny for standard usage.
<JamesMunns[m]>
(that's still "vague dreams" stage, more than stable, iirc tho)
<JamesMunns[m]>
(maybe it was `&uninit`? basically it would allow you to *write* but never *read*, and ideally let you convert back to a normal reference safely if it could tell you did a full valid write)
<JamesMunns[m]>
I know tokio's Bytes type wants this for the same reason: skipping initialization of large buffers you (or the OS) are immediately going to write into.
<firefrommoonligh>
<andresovela[m]> "Off topic: what matrix client is..." <- Element is slow, nags about updates/verifies, then makes that tough to do, and is glitchy
<firefrommoonligh>
I'm also open to alternatives
<vollbrecht[m]>
on desktop i currenlty trying nhkeo, on mobile there is a new version of element called element-x that is build against the matrix2.0 protocol
<vollbrecht[m]>
s/nhkeo/nheko/
dne has quit [Server closed connection]
dne has joined #rust-embedded
jessebraham[m] has joined #rust-embedded
<jessebraham[m]>
I recently installed Element-X on my phone and it's quite a bit nicer than the old version, but I can't really tell which channels have unread messages? Not sure what's up with that haha
<andresovela[m]>
I just installed Element X as well and it does seem better
<andresovela[m]>
Iβll try it out for a few days
<vollbrecht[m]>
i just stoped using nheko :D its ultra cursed it seams, i thould directly stoped when i saw that its a c++ codebase. It literally killed my machine. It freezed everything i could not even stop it via a root-shell via a new tty
<vollbrecht[m]>
directly removed goodbye forever
<vollbrecht[m]>
* stoped using my nheko, * nheko test:D its
<JamesMunns[m]>
I use beeper and it's pretty nice, it's a fork of element (pre-x), and still electron, but never freaks out
<vollbrecht[m]>
* i just stoped using my nheko test:D its ultra cursed it seams, i should directly stoped when i saw that its a c++ codebase. It literally killed my machine. It freezed everything i could not even stop it via a root-shell via a new tty
<dirbaio[m]>
for today's meeting:
<dirbaio[m]>
maybe we could set a target release date for embedded-hal 1.0
IlPalazzo-ojiisa has quit [Read error: Connection reset by peer]
<jessebraham[m]>
This is happening to repos in the `esp-rs` org right now too
<jessebraham[m]>
GHA seems to be having issues (again)
<dirbaio[m]>
it's just GHA sucking, restart it and it'll work
Guest7221 has left #rust-embedded [Error from remote client]
<emilgardis[m]>
i'll wait a bit then, already reran it
<adamgreig[m]>
@room it's meeting time again! agenda is https://hackmd.io/RRFucgrPRry38X_l2sQnYA, please add anything you'd like to announce or discuss and we'll start in a couple minutes
<adamgreig[m]>
ok, let's start! a few short announcements from me, first welcome jessebraham to the working group and the riscv and triage teams! π
<adamgreig[m]>
ok, that's enough confetti :p final announcement is rust 1.74 is out thursday, the final version before stable AFIT :o
<dirbaio[m]>
love how the highlight is the feature it doesn't have yet
<adamgreig[m]>
the newly stable Saturating type (like the existing Wrapping) might be of interest to embedded users
<firefrommoonligh>
That is one of those libs I don't use, but consider it part of my tool kit to use when apt. Ie I'll know when the time is right. My favorite part is how it's syntax is similar to the std collections syntax, so it's easy to drop in
<firefrommoonligh>
* it's syntax and API is similar
<JamesMunns[m]>
Ah! Not waiting on anything but me remembering
<JamesMunns[m]>
should be able to do tonight, unless anyone has opinions on naming, I'll probably go with __exceptions
<adamgreig[m]>
rip __sexceptions
<adamgreig[m]>
let's hold off on naming discussions about the c-m-pac-interface thing til later, I think the two new points are worth discussing first
<adamgreig[m]>
thejpster, do you wanna talk about yours?
<thejpster[m]>
Give me a moment
<thejpster[m]>
sorry was just switching from my phone to my PC
<thejpster[m]>
So, working groups were never supposed to live forever. Arguably the work the Embedded Working Group was supposed to do kind of got done around 2018.
<thejpster[m]>
But you all keep being awesome! So you need to stick around.
<thejpster[m]>
However, that's not what this is about. That's another thing.
<thejpster[m]>
This was about - should there be a no-std team (maybe even getting their own checkboxes) who can hold a repository of knowledge about what it's like to cram Rust into these tiny weird embedded devices and who can have opinions on compiler changes.
<JamesMunns[m]>
thejpster[m]: We truly are the Unincorporated Territory of the Rust Project
<thejpster[m]>
A no-std team.
<thejpster[m]>
I haven't asked The Project yet, as I figured I should ask you what you think first. Because if we think there should be a no-std team, it'll need people on it.
<thejpster[m]>
And that means you. Or some of you. Most of you? I don't know.
<thejpster[m]>
See also parallel discussions about wg-async becoming, or at least forming, a team.
<thejpster[m]>
fin
<dirbaio[m]>
I remember some Zulip discussion about "should there be a nostd wg/team"
<thejpster[m]>
It's almost certainly not an original thought on my part.
<dirbaio[m]>
iirc the outcome was "it's unclear what it'd do"
<thejpster[m]>
it would be called upon to review PRs
<cr1901>
I am for a no-std team, although I think I want to focus my b/w on msp430. It could also serve as a portability team.
<dirbaio[m]>
wasm does support std
newam[m] has joined #rust-embedded
<newam[m]>
A no_std group would also include those interested in WASM I imagine.
<newam[m]>
Oh, I didn't know that
<adamgreig[m]>
it's not clear to me what it would be responsible for, in the way that libs, lang, compiler etc all have an obvious responsibility
<adamgreig[m]>
would it be stepping on t-compiler toes about compiler features, or t-libs about what goes in core, or t-lang about how we want more unsafe static shit, or...
<thejpster[m]>
it is a horizontal rather than a vertical, to borrow Yoshua's terminology
<cr1901>
"we complain when upstream breaks our code b/c they're focusing on the big OSes" :P
<thejpster[m]>
it is a place t-compiler and t-libs can go to ask "hey, does this seem OK to you considering the weird stuff you do?"
<thejpster[m]>
because currently there's no real reason for t-compiler or t-libs to know REWG exists, or the knowledge it has within it
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
What's the difference between a no_std WG and just reforming the Embedded WG?
<adamgreig[m]>
does that obviously serve a purpose beyond wg-embedded? I can see how the focus is more inwards on rust rather than outwards on applications, but seems like it might be the same people
<thejpster[m]>
teams don't do crates, as a general rule. Nor promotion of the language.
<thejpster[m]>
teams make the toolchain
<adamgreig[m]>
yea, fair, I can totally see how it's different to the current wg
<thejpster[m]>
(yeah community team is a thing ... honestly it's all real fuzzy and there's a council committee looking at it)
<adamgreig[m]>
do you think there's a need for it? would it do development beyond being consulted with?
<thejpster[m]>
it would be a great place to do work with t-libs on making core::fmt less sucky
<adamgreig[m]>
it seems like libs team do a great job of getting stuff into core when it's useful, and lang team at thinking about gnarly memory problems, etc
<thejpster[m]>
"we see no reason for a no-std team to exist because t-compiler and t-libs have it covered" is a totally valid position to take
<JamesMunns[m]>
it has been discussed in the past "just make wg-embedded-core a full compiler team"
<thejpster[m]>
I think a no-std team is useful because otherwise there's no guaranteed representation of no-std interests in either t-compiler or t-libs. The might be excellent today, but that's perhaps largely by accident.
<adamgreig[m]>
do you imagine wg-embedded would go under t-nostd or stay under launching pad?
<thejpster[m]>
I think an async-team is useful for similar reasons. It says "here is a place where experts live and they will answer questions and have useful feedback on things that matter to them". Whether they show up unannounced or get paged to weigh in is not something I worry about right now.
<thejpster[m]>
a no-std team would not be a parent to a working group
<thejpster[m]>
I think the working group as a whole needs a different answer, but that's TBD.
<thejpster[m]>
(see also wg-async, wg-cli, etc)
<thejpster[m]>
wg-gamedev.
<thejpster[m]>
The working group needs to continue doing its thing to promote the language in this use-case and developing excellent foundational software that binds the community together instead of it fracturing.
<thejpster[m]>
But maybe it needs a new name and a new place in the project.
<thejpster[m]>
But step one is, mark out a place in The Project where the knowledge can live so people can give opinions on PRs.
<thejpster[m]>
In my view. Other opinions are available.
<adamgreig[m]>
I'm not necessarily against the idea of a t-nostd, but I wonder if you could serve the same goals by just reminding t-lang/t-libs that they can ping wg-embedded if they want opinions on how some new feature will interact with embedded use cases
<adamgreig[m]>
rather than having to spin up and maintain a team whose job seems to be primarily answering questions about no_std?
<adamgreig[m]>
like, it might drive the need for a light-weird fmt option, but surely the implementation of such a thing would be t-libs
<thejpster[m]>
yeah, but if wg-embedded moves that might be more difficult.
<thejpster[m]>
to say that wg-embedded is the place where the knowledge lives limits our options on where it can go
<thejpster[m]>
the project is built around teams
<thejpster[m]>
you can come back to me and say "magic fairy, we want to be a team" and I'll go have that discussion.
kevlan[m] has joined #rust-embedded
<kevlan[m]>
It seems a bit odd to have a team where the mission would be "internally advocate for features that are important to embedded/no-std" but isn't actually responsible for implementing those features. That's an odd charter for a team.
<thejpster[m]>
but y'all don't look like a team
<adamgreig[m]>
I mean, perhaps the discussion can be on what a team looks like, then
<thejpster[m]>
kevlan: but what features do we need? I saw this more as maintaining the status-quo, where rust on cortex-m actually works kinda nice right now.
<adamgreig[m]>
I don't think anyone's clamouring for us to be a team (though shout if you are...), because being a working group seems to fit us pretty well
<thejpster[m]>
if suits you (us) well, but it's not right because that's not what a WG is
<adamgreig[m]>
I'm not sure here though, I don't get as involved in rust team stuff as others, I don't know if there are in fact some situations or work recently where people would prefer if we had more official say
<kevlan[m]>
I'm not even sure there are features we need in which case it does become the "advocate that the status quo isn't broken" which is an even worse charter.
<adamgreig[m]>
I guess that also raises the question of who exactly goes on this new team, if it's anyone from the wg, if anyone would want to, and if not anyone from the wg, what the relationship is between the two
<cr1901>
I think I don't understand enough about Rust governance to actually have an opinion, tbh
<cr1901>
>I'm not even sure there are features we need <-- I think that's mostly b/c embedded ARM is as close to hosted dev that embedded can get
<cr1901>
there are certainly things I want in msp430 land that aren't getting done not _just_ because of _my_ lack of bandwidth
jannic[m] has joined #rust-embedded
<jannic[m]>
A memory model where we actually know how volatile and atomic accesses to memory mapped registers work would be a nice thing to have :-)
<cr1901>
(big one being "stabilized interrupt calling convention", which Cortex-M avoids by having an interrupt controller which implements the C calling convention)
<thejpster[m]>
cool, sounds like that outside of my field of expertise, there things a no-std team could work on
<thejpster[m]>
> raises the question of who exactly goes on this new team
<thejpster[m]>
How does anyone get on any Rust team? They turn up, do good work, and get invited. Or, I guess as this one starts empty, some people who are already showing up and doing good work volunteer themselves.
<kevlan[m]>
For those sorts of features would the team role be laying out the need and defining requirements around it and then handing off to the compiler/libs teams to implement?
<thejpster[m]>
maybe? people can be on more than one team, right?
<adamgreig[m]>
it sounds like it might be worth seeing what rust project people think of the idea of a team that exists mainly to work with several other teams / be a place to ask questions about a particular cross-cutting topic, indeed like the horizontal teams in Yoshua's blog
<adamgreig[m]>
it's not like the team would be a part of this wg, but I guess the hope is some wg members may wish to join
<adamgreig[m]>
it doesn't sound like anyone here is desperate for it to exist, but perhaps a few useful things it could do have been suggested, like core::fmt, work on abis for interrupt handlers and such for smaller platforms
<adamgreig[m]>
ok, thanks thejpster! let's revisit next week if there are any updates too, but I want to get the last topic in the final 15min; dirbaio do you wanna talk about embedded-hal 1.0?
<dirbaio[m]>
yea
<dirbaio[m]>
maybe we could set a target release date for embedded-hal 1.0
<dirbaio[m]>
I think by now everyone who wanted to update already has
<dirbaio[m]>
and as the linked comment mentions
<dirbaio[m]>
if we set a target release date, and a more visible "promise" that no chagnes are expected between 1.0-rc1 and 1.0, that could push a few more people to try out 1.0-rc1
<adamgreig[m]>
do you think it would be worth some push to get a exercise any remaining cobwebs from the current design, in drivers and hals and such?
<adamgreig[m]>
and are we tracking any of the concerns that have come up about the current design anywhere on the repo? mainly thinking of questions around the spidevice but for sd cards or lcd displays or whatever where various alternatives were needed
<dirbaio[m]>
adamgreig[m]: push by who? to existing maintainers, or by us?
<dirbaio[m]>
personally I've already updated everything I care about, and don't have much time for more
<dirbaio[m]>
but IMO it doesn't apply because SpiDevice is intended only for "standard" SCK+MOSI+MISO+CS spi devices
<dirbaio[m]>
also, display-interface is already updated. (they do tiny 1-byte transactions though, toggling CS each time...)
<dirbaio[m]>
* updated. (they ended up using SpiDevice instead of implementing the suggestion I made in the above issue, so they do tiny
<adamgreig[m]>
ποΈ
<adamgreig[m]>
I guess update the 1.0 tracking issue with the intention to release as-is on dec 28th (or whatever) and invite people to raise any final issues or concerns there?
<dirbaio[m]>
so at this point I'm not sure if we gain much by waiting more
<dirbaio[m]>
my proposal is December 28, when rust 1.75 is released with stable AFIT, so we can release both embedded-hal and embedded-hal-async
<dirbaio[m]>
so HALs can do 1 bump instead of 2 (embedded-hal, and later embedded-hal-async)
<thejpster[m]>
do we have volunteers to run the release (it is during Christmas holidays?)
<thejpster[m]>
because I basically do not leave the sofa between dec-25 and jan-02.
<dirbaio[m]>
I'll do the release
<dirbaio[m]>
we just need another t-HAL menber to approve the PR :P
<vollbrecht[m]>
dirbaio[m]: is this the christmas gift for you, hitting the release button π₯°
<vollbrecht[m]>
* release button? π₯°
<dirbaio[m]>
yes!!!! π
<kevlan[m]>
Newsletter headline had better be "New Year, New Embedded HAL"
<dirbaio[m]>
stable AFIT, and embedded-hal 1.0
<dirbaio[m]>
can't think of a better christmas gift!
danielb[m] has joined #rust-embedded
<danielb[m]>
<dirbaio[m]> "also, display-interface is..." <- wait we do WHAT?
<adamgreig[m]>
TAIT π
<chrysn[m]>
TAIT is the even bigger thing to celebrate for me -- simplifies so many things that used to have 2-line-long types.
<chrysn[m]>
Speaking of minor announcements: The CoAP traits family now also has [traits for the client side](https://crates.io/crates/coap-request), full async, with an alpha-quality (yes I mean it, but it's small fixes until it's "just an early thing") [server-and-client](https://crates.io/crates/embedded-nal-coap) based on embedded-nal-async.
<chrysn[m]>
Oh right -- s/TAIT/RPIT/ is what's getting me rid of the types. (Them being unnameable is unfortunate for some use cases, but then TAIT it is).
<JamesMunns[m]>
Good day for making computers talk to computers :)
<cr1901>
RPIT?
<chrysn[m]>
RPITIT argh damnit
<chrysn[m]>
* argh damnit ... don't do acronyms on tired
<cr1901>
How it it related to "then TAIT it is"
<cr1901>
?
<adamgreig[m]>
that's time for the meeting, thanks everyone!
AdamHott[m] has joined #rust-embedded
<AdamHott[m]>
Thanks! Just a quick note - I'm still wrapping my head around probe-rs and rtt!
<danielb[m]>
<danielb[m]> "wait we do WHAT?" <- dirbaio: can you elaborate on this a bit?
<dirbaio[m]>
danielb[m]: lol
SergioGasquez[m] has joined #rust-embedded
<SergioGasquez[m]>
AdamHott[m]: There was an item on the agenda regarding the book, maybe it should cover probe-rs
<chrysn[m]>
cr1901: It's related in my case b/c the two-line types I'm producing are typically coming out of implementing a trait and returning something there. So far I had to name it, meaning that I went through some mental gymnastics to make them namable Chain<Filter<Map<...>>, Map<>> monstrosities. Now that RPITIT is a thing I can just switch there to returning impl trait and improve code readability a lot. But that has the downside that
<chrysn[m]>
for the few cases where someone needs to store my type in some static, they're left in the realms of unstable features because they'll need to TAIT a new type that they can then store, with the RPITIT being the defining use.
<SergioGasquez[m]>
SergioGasquez[m]: And things like rtt and defmt would also be very helpful
<adamgreig[m]>
SergioGasquez[m]: that's exactly it - Adam Hott has kindly volunteered to help update the book to mention probe-rs, rtt, defmt etc
<dirbaio[m]>
danielb[m]: depending on how you use embedded-graphics it can do many tiny writes tho
<dirbaio[m]>
dirbaio[m]: toggling CS for each
<danielb[m]>
dirbaio[m]: I know
<dirbaio[m]>
danielb[m]: but that was probably the case for embedded-hal 0.2 too
<dirbaio[m]>
dirbaio[m]: sorry for the confusion
<SergioGasquez[m]>
adamgreig[m]: Thats awesome news, thanks! Recently I did a small update of the Rust on ESPs debugging section (https://github.com/esp-rs/book/pull/128) and it would be very good to have such things covered in the book so I can just refer to them
<danielb[m]>
dirbaio[m]: :) I guess I'll have to read your comments on the linked issue better, current update is a low-effort "just make it work" job
<dirbaio[m]>
RPIT = return-position `impl Trait`
<dirbaio[m]>
RPITIT = return-position `impl Trait` in traits
<dirbaio[m]>
TAIT = type alias `impl Trait`
<dirbaio[m]>
danielb[m]: I had read the code fast and misunderstood it
<danielb[m]>
dirbaio[m]: fyi embedded-graphics will spit out iterators so most likely D-I will chunk into 64 bytes
<danielb[m]>
* embedded-graphics will mostly spit out
<AdamHott[m]>
SergioGasquez[m]: I'm working through a debug example with the Micro:bit V2 right now.
<AdamHott[m]>
AdamHott[m]: I need a bit more time to research
<geky[m]>
If you imagine xor is polynomial addition (of binary vectors), then pmul is polynomial multiplication (of binary vectors). Gets you lots of cool stuff
<cr1901>
(I was doing the milkshake duck template badly, whoops)
<cr1901>
interesting that pmul of two 4 bit numbers gets you a 7-bit number at max
<geky[m]>
Oh yeah, it's also symmetrical, which gets funny
<cr1901>
Hmmm wait that's actually true for regular poly multiplication too (degree is one less than the number of terms)
<dirbaio[m]>
no one from t-hal was in the meeting other than me
<dirbaio[m]>
I guess I probably shouldn't just go and announce "release date is 28th dec" yet?
<dirbaio[m]>
π
<fu5ha[m]>
<danielb[m]> "fyi embedded-graphics will..." <- I want to look into that more -- since iterators are the main way the embedded-graphics ecosystem works atm, it's the main way d-i is used too, but there's way more overhead than you'd want there to be ... Want to benchmark whether it's down to unideal chunking or I'm now suspecting it's more likely the fact that the iterators are dynamic dispatch. But going from using an iter to a
<fu5ha[m]>
slice of the same flavor is like 5x speedup... Which is quite important for this kind of code. I feel like the `DataFormat` enum is maybe the wrong solution to the problem but idk
<dirbaio[m]>
eldruin therealprof ryankurte mabez
<JamesMunns[m]>
> the iterators are dynamic dispatch
<JamesMunns[m]>
Wait who has dynamic dispatch?
<danielb[m]>
dirbaio for BDFL
<dirbaio[m]>
fu5ha[m]: yeah the display-interface api always has felt weird to me
<dirbaio[m]>
dirbaio[m]: using `dyn` is not great
<danielb[m]>
dirbaio[m]: don't shoot the messenger, I just ported to newer embedded-hal :) also don't forget some users do e-g into framebuffer and dump using d-i
<JamesMunns[m]>
TIL D-I uses dyn dispatch
<danielb[m]>
James talking out of thread again, of course π
<dirbaio[m]>
james writing out of the thread as always π
<danielb[m]>
* for those who don't understand, James, * James is talking out
<JamesMunns[m]>
oh no
<JamesMunns[m]>
i've done it again
<JamesMunns[m]>
beeper is a good matrix client
<dirbaio[m]>
danielb[m]: yea
<dirbaio[m]>
dirbaio[m]: I wonder if we need some kind of "BufferedSpi" where you can enqueue bytes and it'll send them in the background
<dirbaio[m]>
dirbaio[m]: concurrently with the cpu enqueuing enqueuing more bytes
Guest7221 has joined #rust-embedded
<firefrommoonligh>
Thx will check it out
<firefrommoonligh>
I was kinda not enthused about Matrix in general given the problems I hit almost immediately with the official client.
<danielb[m]>
dirbaio[m]: some esp project implemented their own buffering D-I adapter that buffers into a 4KiB array
<danielb[m]>
danielb[m]: there's need for making the buffer configurable for sure, if nothing else
<fu5ha[m]>
danielb[m]: Of course, not blaming at all!! It's really awesome this stuff exists at all in the first place, and I don't fault it :D just wanna make it better haha
<danielb[m]>
fu5ha[m]: you can do that of course :)
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
<mabez[m]>
<dirbaio[m]> "no one from t-hal was in the..." <- Sorry I missed today's meeting, but 28th sounds good to me! I'm more than happy to approve the PR once its ready π
IlPalazzo-ojiisa has quit [Remote host closed the connection]
Guest7221 has left #rust-embedded [Error from remote client]
crabbedhaloablut has quit []
<StephenD[m]>
Ah geez, so my spawn_after in RTIC seems to be off by exactly a factor of for. If I set it to 1s it takes 4s; if I set it to 10s it takes 40s. Sounds like a clock issue, but my clock is def set right because USB FS works
<StephenD[m]>
Anything obvious I might want to check?
Guest7221 has joined #rust-embedded
<JamesMunns[m]>
> my clock is def set right because USB FS works
<JamesMunns[m]>
Depends on your chip, timers and USB might be on significantly different clocks with different scalers
<dirbaio[m]>
to go as fast as possible on f411 you want systick=100, hclk=100, pclk1=25, pclk2=50
<adamgreig[m]>
same with pclk1 and pclk2, they need to be obtainable from hclk with integer division, so 21MHz or 42MHz
<adamgreig[m]>
can you do that and still have 48MHz PLL48CK?
<adamgreig[m]>
oh, probably, it is a separate divider in the pll
<StephenD[m]>
I actually want to downclock it so I'm going to set it all to 24MHz
<StephenD[m]>
Is that peachy?
<adamgreig[m]>
if you want it all 24MHz you need a sysclk that's a multiple of 24MHz
<adamgreig[m]>
so like 96MHz
<StephenD[m]>
Can I make the sysclk 24mhz as well?
<dirbaio[m]>
adamgreig[m]: then systick=96, hclk=96, pclk1=24, pclk2=48
<dirbaio[m]>
s/systick/sysclk/
<dirbaio[m]>
s/systick/sysclk/
<adamgreig[m]>
dirbaio: I think you have have sysclk=100 hclk=100 etc and still have pll48ck at 48MHz though, if you wanted
<adamgreig[m]>
and yea, you could make sysclk==hclk==pclk1==pclk2==24MHz if you want
<JamesMunns[m]>
fwiw Stephen D, using stm's CubeMX tool is usually a good way to check "what should my clocks be"
<dirbaio[m]>
adamgreig[m]: lcm(100, 48) is 1200 which is outside the pll vco range (max 432mhz)
<dirbaio[m]>
dirbaio[m]: I tried the other day on a blackpill
<StephenD[m]>
Is that tool FOSS?
<dirbaio[m]>
dirbaio[m]: couldn't figure out how to hit 100mhz with usb
<dirbaio[m]>
dirbaio[m]: maybe i'm missing something, it's odd that ST would design a cpu where you can't hit max freq if you want to use one of the main features
<dirbaio[m]>
dirbaio[m]: but it's ST so...
<dirbaio[m]>
dirbaio[m]: Β―\_(γ)_/Β―
<adamgreig[m]>
dirbaio[m]: ah, that's annoying, I was just hoping the pll could sort it out
<adamgreig[m]>
adamgreig[m]: 1200 is a big ask for the pll vco
<adamgreig[m]>
it's not, but it is free
<StephenD[m]>
Okay I'll pass on it then, but ty for the advice and help!
<adamgreig[m]>
the reference manual for your chip has all the details you need to check it yourself too
<dirbaio[m]>
the ST chip itself is not FOSS either π
<StephenD[m]>
dirbaio[m]: True, but it's not running on my personal computer either. Apples and oranges
<adamgreig[m]>
RM0383 from ST's site, section 6 for clocks, in particular 6.3.2 and 6.3.3 have the relevant constraints, but it's a bit more reading to do
<StephenD[m]>
adamgreig[m]: Yeah this is what I've been relying on
<StephenD[m]>
My USB no longer works now that I've clocked everything to 24MHz but I'll deal with that tomorrow