<michaeldesilva[m>
diondokter[m]: Hah just saw that. Sweet bytes()
<michaeldesilva[m>
#[doc(alias = "memset")]
<JamesMunns[m]>
Also, definitely benchmark before you start using unsafe because you think the safe code is slow. The optimizer is smart as hell, and using safe code makes it easier for the optimizer to be more aggressive
<JamesMunns[m]>
I bet you your code will get turned into a member anyway
<JamesMunns[m]>
s/member/memset/
<JamesMunns[m]>
The optimizer LOVES turning code into memcpy, memset, and memmove. If it can do that, it almost certainly will.
<diondokter[m]>
JamesMunns[m]: Yep. Using slice fill will very likely generate that. Using an iterator and doing it yourself will probably also result in a memset, but fill is probably easier for the optimizer
<JamesMunns[m]>
you're mutably aliasing the memory, you write it manually after giving the memory to the allocator, that's UB
<JamesMunns[m]>
like, after you give the full SDRAM memory range to the allocator, you should never touch/use it again. you should only use it through the allocator.
<JamesMunns[m]>
also I don't know why you are re-initializing sdram after the first time you do it?
<JamesMunns[m]>
it's likely you are corrupting the heap allocator's metadata, causing the segfault
<michaeldesilva[m>
JamesMunns[m]: ahh ignore that, I was being silly.
<JamesMunns[m]>
like, you are corrupting the memory the heap allocator "owns", and you are probably overwriting it's metadata
<michaeldesilva[m>
I was trying to figurer out why the drop was taking place
<JamesMunns[m]>
if the compiler didn't already do something crazy because it figured out what you are doing is UB
<michaeldesilva[m>
s/figurer/figurerout/, s/out//
<michaeldesilva[m>
s/figurer/figure/
<JamesMunns[m]>
drops happen when the item falls out of scope. you create a string in the loop when you call to_rfc2822, so it gets dropped when you leave the if let block
<michaeldesilva[m>
JamesMunns[m]: right but that shouldn't drop my allocator?
<michaeldesilva[m>
* my allocator? It's a global allocator....?
<JamesMunns[m]>
it doesn't but you've corrupted the allocatr
<JamesMunns[m]>
the ALLOCATOR is never dropped.
<JamesMunns[m]>
the STRING your allocator allocated is deallocated/dropped
<michaeldesilva[m>
JamesMunns[m]: where? the UB bit is commented out?
<michaeldesilva[m>
JamesMunns[m]: ahh
<JamesMunns[m]>
no, even HAVING ram_slice is undefined behavior
<michaeldesilva[m>
JamesMunns[m]: ahhhhh
<JamesMunns[m]>
you cannot have aliased memory - you "gave" it to the allocator, AND you kept it for yourself in `ram_slice`
<JamesMunns[m]>
having it is UB, reading from it (esp if it was not initialized) is UB, writing to it is SUPER UB and is probably corrupting the state of the whole allocator.
<xiugaze[m]>
That's the trait bound, I see it in the docs too but no obvious way to coerce
<xiugaze[m]>
I also tried using AdcPin as the parameter but that requires all these weird generics and where clauses, and those aren't allowed in task signatures anyway
marmrt[m] has joined #rust-embedded
<marmrt[m]>
I haven't actually used Embassy, so I might not know what I'm talking about, but I think the problem is that degrade() creates a generic pin which does not support ADC
<marmrt[m]>
You're basically trying to tell the HAL not to worry about which pin you\r're using, while the HAL wants to make sure you're using a pin with ADC functionality
<xiugaze[m]>
That's true, but in that case, what type is the pin supposed to be in the function signature?
<marmrt[m]>
PA0.into() might work, but again, I haven't looked at this hal
<AdamHott[m]>
<adamgreig[m]> "I've made this room actually, so..." <- Just sent you a DM on this one
linfax has quit [Ping timeout: 260 seconds]
KennethKnudsen[m has quit [Quit: Idle timeout reached: 172800s]
AdinAck[m] has joined #rust-embedded
<AdinAck[m]>
<xiugaze[m]> "image.png" <- what you can do is make your generic functions not a task, then make a task that runs your generic function as many times you want with as many pins you want
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
<MathiasKoch[m]>
Anyone strong in TLS, rustls or similar who would like to review my PR on `embedded-tls`, and might help provide some insights on why my `CertificateVerify` step is giving me `BadSignature`, see description here: https://github.com/drogue-iot/embedded-tls/pull/135#issuecomment-1944380767
<MathiasKoch[m]>
Anything is extremely welcomed, as I have now spend an entire day trying to compare with the rustls implementation in the rustcrypto provider
WSalmon has quit [Remote host closed the connection]
WSalmon has joined #rust-embedded
<MathiasKoch[m]>
<MathiasKoch[m]> "Anyone strong in TLS, rustls..." <- Finally found it!
<MathiasKoch[m]>
Client Certificate Authentication with x.509 certificates and private key is now working in `embedded-tls` 🎉
K900 has quit [Quit: Idle timeout reached: 172800s]
Averyshethey[m] has quit [Quit: Idle timeout reached: 172800s]
lulf[m] has joined #rust-embedded
<lulf[m]>
<MathiasKoch[m]> "Finally found it!..." <- Awesome MathiasKoch !!!
<lulf[m]>
lulf[m]: I'll try to get the review done tomorrow
<MathiasKoch[m]>
lulf[m]: Yeah, no hurry. I'll just continue my embassy-net endeavours with a patched embedded-tls 👍️
<MathiasKoch[m]>
s/hurry/rushurry/
<MathiasKoch[m]>
s/hurry/rush/
<MathiasKoch[m]>
MathiasKoch[m]: I still think some of the ergonomics around the `TlsVerifier` and this new `CryptoProvider` could be improved a bit, but I might look into that in a different PR, when I reach the point where I want to implement this on top of my ATECC crypto module
<MathiasKoch[m]>
* crypto module for seure certificate & key storage
<MathiasKoch[m]>
* crypto module for secure certificate & key storage