jfsimon has quit [Read error: Connection reset by peer]
jfsimon has joined #rust-embedded
crabbedhaloablut has quit [Quit: bye]
crabbedhaloablut has joined #rust-embedded
Koen[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
japaric: any interest in different backends for yada? i find the focus on high performance quite attractive
xnor has joined #rust-embedded
RoyBuitenhuis[m] has joined #rust-embedded
<RoyBuitenhuis[m]>
Why would inline(never) increase .text size on (async) fn's with const generics? Could this be because the compiler can't optimize how they are being used? Trying to optimize for code-size, but so far only getting small steps.
diondokter[m] has joined #rust-embedded
<diondokter[m]>
RoyBuitenhuis[m]: Yep, not inlining can disable some optimizations
<diondokter[m]>
For example, say your function checks if an option is None or not. When inlined, the compiler may already know that it's always Some and omit the check
<diondokter[m]>
So inlining optimizes better, but at the cost of less code reuse. So sometimes it can make things smaller, but sometimes also bigger
<RoyBuitenhuis[m]>
It makes more sense now, thanks
Foxyloxy_ has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 240 seconds]
sroemer has quit [Quit: WeeChat 4.5.2]
bozgi[m] has joined #rust-embedded
<bozgi[m]>
how can i make a keypad switches easily programmable, ie. they can be changed to any other key by the user using eg. a desktop app interface
<diondokter[m]>
bozgi[m]: You'll need to store a config in flash or other nonvolatile storage
<diondokter[m]>
There are some nice crates to help you there, namely my sequential-storage or dirbaio's ekv
<bozgi[m]>
thanks, how can i write that data through usb without being in the dfu mode
<bozgi[m]>
diondokter[m]: really nice, will check it out, ty
<diondokter[m]>
bozgi[m]: You'll have to find a way to set up communication through one of the many usb protocols
<bozgi[m]>
any suggestions? i am new to all this stuf
<diondokter[m]>
I can recommend looking at postcard-rpc for that
<bozgi[m]>
s/stuf/stuff/
<diondokter[m]>
I don't actually know which usb protocol that uses
<diondokter[m]>
You can make something custom too with ACM (usb serial)
<bozgi[m]>
thanks!
jason-kairos[m] has joined #rust-embedded
<jason-kairos[m]>
I've got a silly question about CRCs. I notice that a certain 32 bit CRCs algorithm does not "appear" as random as I thought it would be. Would using the lower 32 bits of a 64 bit CRC be likely to be any different?
<jason-kairos[m]>
This is probably totally unnecessary, but would make me "feel better." Not sure if it is totally irrational or not.
<jason-kairos[m]>
s/This is probably totally unnecessary, but would make me "feel better." Not sure if it is totally irrational or not./This is probably totally unnecessary, but having it "look random" make me "feel better." Not sure if it is totally irrational or not./
<jason-kairos[m]>
s/This is probably totally unnecessary, but would make me "feel better." Not sure if it is totally irrational or not./This is probably totally unnecessary, but having it look more "random" make me "feel better." Not sure if it is totally irrational or not./
<jason-kairos[m]>
* unnecessary, but having it look more "random" would make
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]>
are you using it as a seed for something?
<jason-kairos[m]>
just a check code on some data sent over a network
<JamesMunns[m]>
I don't think CRC particularly optimizes for avalanche characteristics
<jason-kairos[m]>
specifically a ~200 byte structure containing settings that are mostly zeros, to check if they are the expected value or not
KevinPFleming[m] has joined #rust-embedded
<KevinPFleming[m]>
They aren't intended to be random.
<jason-kairos[m]>
CRC zoo suggests it's fine, so it probably is.
Socke has quit [Ping timeout: 240 seconds]
Socke has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
limpkin has quit [Quit: limpkin]
limpkin has joined #rust-embedded
timokrgr[m] has joined #rust-embedded
<timokrgr[m]>
<jason-kairos[m]> I've got a silly question about CRCs. I notice that a certain 32 bit CRCs algorithm does not "appear" as random as I thought it would be. Would using the lower 32 bits of a 64 bit CRC be likely to be any different?...
<timokrgr[m]>
* weakens the error detection capabilities, * detection capabilities of a CRC in unpredictable
<jason-kairos[m]>
hmm... is using a CRC to detect the difference between two sets of settings misusing CRC? In my mind, it seems very similar to error detection, but the difference is that the Hammond distance could easily be thousands of bits.
<jason-kairos[m]>
Is there a better way to use 32 bits to represent the difference between two same-sized chunks of data. (~200 bytes)
<jason-kairos[m]>
maybe if it was truly random it would be "better" at doing its job?
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
Why do you want to check for differences by comparing the crc instead of the actual data? 200 bytes is not much data
<whitequark[cis]>
CRCs are good enough for xilinx to detect random errors in 1..100 MB of bitstream
<whitequark[cis]>
but i want to stress that the things most likely to happen there are "uncorrelated bitflips" and "skipped clocks"
<whitequark[cis]>
there are absolutely patterns of data corruption which, if you're likely to have them, you shouldn't use CRCs. i am not an expert in this domain though so if your thing is important you should ask someone who are
<jason-kairos[m]>
* (I maybe could spare 5 bytes, but would it really make any difference? I'd rather use it for useful/application related stuff)
<jason-kairos[m]>
* (I maybe could spare 5 bytes instead of 4, but would it really make any difference? I'd rather use it for useful/application related stuff)
<whitequark[cis]>
can you transmit a "number of changes to the data"?
<whitequark[cis]>
e.g. every time you find that the data doesn't a copy of the data on the device (or a cryptographic hash), you increment a counter
<whitequark[cis]>
whenever the device tells you the counter is incremented you know something has changed
<whitequark[cis]>
this would detect 100% of errors, assuming no overflows
<whitequark[cis]>
(so the real likelihood of missing a corruption would depend on the size of your counter and error rate)
<dirbaio[m]>
yeah! make the server track a "config version number", increase it on changes
<whitequark[cis]>
* error rate in data at rest in the wild)
<jason-kairos[m]>
I've got confirmed acknowledge that thing changed. But not that a programming error caused a state mismatch between what they "thought the asked for" and "what they actually got"
<jason-kairos[m]>
* I've got confirmed acknowledge that things like settings have changed. But not that a programming error caused a state mismatch between what they "thought the asked for" and "what they actually got"
<whitequark[cis]>
how often is the device reprogrammed vs how often do you want to verify it?
<jason-kairos[m]>
* I've got confirmed acknowledge that things like settings have changed. But that doesn't detect that a programming error caused a state mismatch between what they "thought the asked for" and "what they actually got"
<jason-kairos[m]>
Once per month. I need to know every time a change occurs before it is commanded to proceeds to the next step.
<whitequark[cis]>
that's ambiguous
<whitequark[cis]>
* that's an ambiguous answer to my question
<jason-kairos[m]>
And due to the pervasiveness of things like javascript as a server side web programming language, certain types of programming error are very likely
<jason-kairos[m]>
* I've got confirmed acknowledge that things like settings have changed. But that doesn't detect that a programming error caused a state mismatch between what they "thought they asked for" and "what they actually got"
<jason-kairos[m]>
s/proceeds/proceed/
<jason-kairos[m]>
whitequark[cis]: I'm not sure I understand. Every uplink and downlink matters and contains various types/layers of sanity checking + confirmation/acknowledge.
<whitequark[cis]>
so, you have two operations: "program the device with a new 200 byte blob", and "verify the 200 byte blob is what you expect without fully retransmitting it", is that correct?
<jason-kairos[m]>
Yes
<jason-kairos[m]>
I can receive more data than I can transmit.
<whitequark[cis]>
how often do you do operation 1 and operation 2?
<whitequark[cis]>
by receive do you mean host to device or device to host?
<KevinPFleming[m]>
Why not just use a CRC-32 or even CRC-16?
<jason-kairos[m]>
KevinPFleming[m]: I am using a CRC-32. It seems 'kind of meh' lots of very similar looking values. The linked article makes me think I might be misusing CRC and maybe should use a hash instead?
<jason-kairos[m]>
I guess different types of check codes have different properties, and maybe (I am not really confident) CRC optimizes for something different that what I might have expected.
<jason-kairos[m]>
* a CRC-32 currently. It
<KevinPFleming[m]>
CRCs are for detection of changes, not for comparing values or correcting changes. They are a type of hash but not one that is useful for cryptography or bucketing.
<jason-kairos[m]>
* I am using a CRC-32 currently. It seems 'kind of meh' lots of very similar looking values. The linked article makes me think I might be misusing CRC and maybe should use a hash or even AES-128 instead?
<jason-kairos[m]>
I guess different types of check codes have different properties, and maybe (I am not really confident) CRC optimizes for something different that what I might have expected.
<KevinPFleming[m]>
There are trillions of bytes sent around networks every day which use CRCs for corruption detection.
<jason-kairos[m]>
I need to learn more about the comparing values usecase, because more than just a few bits can change
<jason-kairos[m]>
* can change at once
<jason-kairos[m]>
I feel like it should be 'more random'
<jason-kairos[m]>
but I am not really equipped with the knowledge/background/tools to confidently measure or reason about what properties actually matter for that type of use
<jason-kairos[m]>
this almost makes me think it might not matter despite the warnings about abusing CRC-32 for things it was never intended for
<jason-kairos[m]>
* The following almost makes me think it might not matter despite the warnings about abusing CRC-32 for things it was never intended for
<whitequark[cis]>
<jason-kairos[m]> Budget for once per month on 1. And the same frequency for 2....
<whitequark[cis]>
are you trying to detect corruption in transit or at rest?
<jason-kairos[m]>
Catherine: not necessarily corruption so much as the value being completely different
<jason-kairos[m]>
I don't understand what you mean by in transit or at rest. It gets sent a ~200 byte request, and it gives a ~4 byte response. (ignoring all the extra protocol/header/encoding stuff)
<whitequark[cis]>
ok so, we have point A and point B one month apart. you program the device at point A and B. do you care about the configuration becoming corrupted in the interval between sending it at A and receiving it at A, or in the interval between sending/receiving it at A and the device continuing to do nothing until B?
<jason-kairos[m]>
Point A and B are several minutes apart.
<jason-kairos[m]>
I care about the programmer sending a command (a set of settings) that produces a different result from what they expected. The expected/value outcome value being tied to the 32 bit check code.
<jason-kairos[m]>
Also worried about value silently wrapping, saturating, clamping, etc. in the background without anyone noticing.
<jason-kairos[m]>
* of settings, etc.) that
<jason-kairos[m]>
* I care about the programmer sending a command (a set of settings, etc.) that produces a different result from what they expected. The expected/value outcome value being tied to the 32 bit check code.
<jason-kairos[m]>
Also worried about values silently wrapping, saturating, clamping, etc. in the background without anyone noticing.
<jason-kairos[m]>
* I care about the user/programmer sending a command (a set of settings, etc.) that produces a different result from what they expected. The expected/value outcome value being tied to the 32 bit check code.
<jason-kairos[m]>
Also worried about values silently wrapping, saturating, clamping, etc. in the background without anyone noticing.
<KevinPFleming[m]>
So the sender is going to precompute an expected response value and then compare it to the actual response value?
<jason-kairos[m]>
Correct
<KevinPFleming[m]>
And what will happen if they don't match?
<jason-kairos[m]>
Everything stops, they try figure out what went wrong. Likely retry.
<jason-kairos[m]>
They typically only mismatch due to a programming/logic/conceptual error.
<KevinPFleming[m]>
I'd say that a CRC over the bytes representing the state should be fine then.
<KevinPFleming[m]>
An MD-5 or SHA-1 would be better but also much larger.
<jason-kairos[m]>
Hopefully it might be.
<jason-kairos[m]>
If there were not so many combinations, I simply brute force my way to a conclusion. Unfortunately, no PC is fast enough to compute even a CRC-32 on every possible combination. Nor every plausible combination of settings/etc.
<jason-kairos[m]>
* combinations, I'd simply
<KevinPFleming[m]>
2^1600 is definitely a big number.
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
You could also assign a unique id (random, sequential, or a crc/hash) to a configuration when you send it from the host
<GrantM11235[m]>
Then the device doesn't need to hash the configuration, it just needs to store the unique id along with the config data
jfsimon has quit [Remote host closed the connection]