Conversation
fd4eca1 to
7eb937e
Compare
hawkw
left a comment
There was a problem hiding this comment.
Neat, I had wanted to do something like this last time I was looking at this code but decided to defer it at the time. I had some very minor nitpicks but no real concerns.
a27d9e8 to
2d6751c
Compare
|
@hawkw I switched to an array of |
588cbe9 to
7010013
Compare
|
I did a quick |
7010013 to
c64bf6a
Compare
labbott
left a comment
There was a problem hiding this comment.
LGTM I love shrinking stacks 😎
hawkw
left a comment
There was a problem hiding this comment.
Okay, I like the new approach with Cells, but I did leave a few small nitpicks, mostly about docs etc.
| } | ||
| } | ||
|
|
||
| mod temperature_array { |
There was a problem hiding this comment.
Nit, take it or leave it: I wonder somewhat if a higher level theory of operation for the relationship between the RawTemperatureArray, OptionalTemperatureArray, and TemperatureArray types could be included in the module-level docs for this?
task/thermal/src/control.rs
Outdated
| /// Temperature state iterator with `TemperatureReading` values | ||
| impl TemperatureArray { | ||
| pub fn zip_temperatures<'a>( |
There was a problem hiding this comment.
I think the doc comment is meant to be on the method
| /// Temperature state iterator with `TemperatureReading` values | |
| impl TemperatureArray { | |
| pub fn zip_temperatures<'a>( | |
| impl TemperatureArray { | |
| /// Temperature state iterator with `TemperatureReading` values | |
| pub fn zip_temperatures<'a>( |
There was a problem hiding this comment.
also, why are there two separate impl blocks here?
There was a problem hiding this comment.
Stuff got shuffled around, both things are now fixed
| /// Returns an iterator over tuples of `(sensor_id, value, thermal model)` | ||
| /// | ||
| /// The `values` array contains static and dynamic values (in order); | ||
| /// this function will panic if sizes are mismatched. | ||
| /// | ||
| /// Every dynamic input is represented by an `Option<DynamicInputChannel>`. | ||
| /// If the input is not present right now, it will be `None`, but will | ||
| /// continue to take up space to preserve ordering. | ||
| /// | ||
| /// In cases where dynamic inputs are not present (i.e. they are `None` in | ||
| /// the array), the iterator will skip that entire tuple. |
There was a problem hiding this comment.
i feel like some of this documentation could also be included on the public OptionalTemperatureArray::zip_temperatures, but 🤷♀️ --- we never build API docs for this stuff (see #2422), so putting it on private functions is probably fine.
There was a problem hiding this comment.
I didn't want to repeat this on both OptionalTemperature::zip_temperatures and TemperatureArray::zip_temperatures, so I figured this was the right place (since as you said we don't actually build docs) 🤷🏻♂️
8e2c3a1 to
234e459
Compare
234e459 to
323f754
Compare
I tried to make a change to
thermaland the stack complained. I then realized thatmain's stack inthermalis huge:This PR shrinks it down to a more reasonable size by moving temperature data arrays into a static buffer:
There's a little bit of trickery here: we store a single
[Option<TemperatureReading>; TEMPERATURE_ARRAY_SIZE]array, then wrap it in a special type when it's guaranteed that all the values areSome(..).We also have to (unfortunately) add a
ThermalControlState::Empty, because we need a valid temporary value to put into thestateposition while modifying + replacing it.