Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/telemetry #341

Merged
merged 43 commits into from
May 10, 2021
Merged

Feature/telemetry #341

merged 43 commits into from
May 10, 2021

Conversation

ryan-summers
Copy link
Member

@ryan-summers ryan-summers commented Apr 20, 2021

This PR fixes #149

This PR adds the following:

  • A SystemTimer used for RTIC scheduling (required for schedule periods > ~2 seconds)
  • A refactor of the src/net directory
  • Addition of network stack sharing via proxy (identical to implementation from shared-bus)
  • Addition of a telemetry task

This must be merged after #352

Future Work:

  • move src/net/shared.rs into embedded-nal or some other separate crate.
  • Investigate removal of shared network stack by making smoltcp sockets owned and interrupt-safe

src/bin/dual-iir.rs Outdated Show resolved Hide resolved
src/net/telemetry.rs Outdated Show resolved Hide resolved
src/net/telemetry.rs Outdated Show resolved Hide resolved
src/bin/dual-iir.rs Outdated Show resolved Hide resolved
src/bin/dual-iir.rs Outdated Show resolved Hide resolved
src/bin/lockin.rs Outdated Show resolved Hide resolved
src/hardware/system_timer.rs Outdated Show resolved Hide resolved
src/hardware/system_timer.rs Show resolved Hide resolved
src/net/telemetry.rs Outdated Show resolved Hide resolved
@ryan-summers ryan-summers requested a review from jordens May 7, 2021 11:05
src/hardware/dac.rs Outdated Show resolved Hide resolved
src/hardware/adc.rs Outdated Show resolved Hide resolved
src/hardware/dac.rs Outdated Show resolved Hide resolved
Co-authored-by: Robert Jördens <[email protected]>
src/hardware/configuration.rs Outdated Show resolved Hide resolved
src/hardware/configuration.rs Outdated Show resolved Hide resolved
Comment on lines 78 to 91
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
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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/net/mod.rs Outdated Show resolved Hide resolved
Copy link
Member

@jordens jordens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple fixes for off-by-one errors and documentation consolidation.

src/hardware/adc.rs Outdated Show resolved Hide resolved
src/hardware/adc.rs Outdated Show resolved Hide resolved
src/hardware/configuration.rs Show resolved Hide resolved
src/hardware/dac.rs Outdated Show resolved Hide resolved
Comment on lines 78 to 91
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
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

src/bin/dual-iir.rs Outdated Show resolved Hide resolved
src/bin/dual-iir.rs Show resolved Hide resolved
src/hardware/dac.rs Outdated Show resolved Hide resolved
@ryan-summers ryan-summers requested a review from jordens May 10, 2021 09:55
@ryan-summers
Copy link
Member Author

bors try

bors bot added a commit that referenced this pull request May 10, 2021
@bors
Copy link
Contributor

bors bot commented May 10, 2021

try

Build succeeded:

@ryan-summers
Copy link
Member Author

bors merge

@bors
Copy link
Contributor

bors bot commented May 10, 2021

Build succeeded:

@bors bors bot merged commit 3354979 into master May 10, 2021
@bors bors bot deleted the feature/telemetry branch May 10, 2021 11:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MQTT settings/status/telemetry framework
3 participants