Feature/telemetry #341
Feature/telemetry #341
Conversation
Co-authored-by: Robert Jördens <[email protected]>
src/hardware/dac.rs
Outdated
| fn into(self) -> f32 { | ||
| // The output voltage is generated by the DAC with an output range of +/- 4.096 V. This | ||
| // signal then passes through a 2.5x gain stage. Note that the DAC operates using unsigned | ||
| // integers, and u16::MAX / 2 is considered zero voltage output. Thus, the dynamic range of | ||
| // the output stage is +/- 10.24 V. At a DAC code of zero, there is an output of -10.24 V, | ||
| // and at a max DAC code, there is an output of (slightly less than) 10.24 V. | ||
|
|
||
| let dac_volts_per_lsb = 4.096 * 2.5 / (1u16 << 15) as f32; | ||
|
|
||
| // Note that the bipolar table is an offset-binary code, but it is much more logical and | ||
| // correct to treat it as a twos-complement value. TO do that, we XOR the most significant | ||
| // bit to convert it. | ||
| (self.0 ^ 0x8000) as i16 as f32 * dac_volts_per_lsb | ||
| } |
There was a problem hiding this comment.
For special functions like these, what do you think about writing small unit tests for the max/min/zero cases to make sure we operate correctly?
There was a problem hiding this comment.
If you want, feel free.
In the case of single-branch mathematical formulas, for me it's faster and even less error-prone to review the formula than to review unittests for certain values of it. By a significant margin, because arguing the correctness of the unittest test values requires volumetrically more math than proving the correctness of the formula conclusively. Unittests are only second choice in math and don't replace analytical proofs.
This is obviously different for other things or once it's not a simple formula anymore (like the DSP stuff).
There was a problem hiding this comment.
There's some issues with placing tests in the stabilizer crate - specifically, Rust can't find the crate test. As such, I'm avoiding tests, but I think it would be value-added in the future to add some small sanity check tests (e.g. verify code of 0 equates to near our negative scale, code of 0xFFFF equates to near our positive scale).
src/hardware/dac.rs
Outdated
| fn into(self) -> f32 { | ||
| // The output voltage is generated by the DAC with an output range of +/- 4.096 V. This | ||
| // signal then passes through a 2.5x gain stage. Note that the DAC operates using unsigned | ||
| // integers, and u16::MAX / 2 is considered zero voltage output. Thus, the dynamic range of | ||
| // the output stage is +/- 10.24 V. At a DAC code of zero, there is an output of -10.24 V, | ||
| // and at a max DAC code, there is an output of (slightly less than) 10.24 V. | ||
|
|
||
| let dac_volts_per_lsb = 4.096 * 2.5 / (1u16 << 15) as f32; | ||
|
|
||
| // Note that the bipolar table is an offset-binary code, but it is much more logical and | ||
| // correct to treat it as a twos-complement value. TO do that, we XOR the most significant | ||
| // bit to convert it. | ||
| (self.0 ^ 0x8000) as i16 as f32 * dac_volts_per_lsb | ||
| } |
There was a problem hiding this comment.
If you want, feel free.
In the case of single-branch mathematical formulas, for me it's faster and even less error-prone to review the formula than to review unittests for certain values of it. By a significant margin, because arguing the correctness of the unittest test values requires volumetrically more math than proving the correctness of the formula conclusively. Unittests are only second choice in math and don't replace analytical proofs.
This is obviously different for other things or once it's not a simple formula anymore (like the DSP stuff).
|
bors try |
tryBuild succeeded: |
|
bors merge |
|
Build succeeded: |
This PR fixes #149
This PR adds the following:
SystemTimerused for RTIC scheduling (required for schedule periods > ~2 seconds)src/netdirectoryshared-bus)This must be merged after #352
Future Work:
src/net/shared.rsintoembedded-nalor some other separate crate.