Temperature code updates

[Ralim]

• Please check if the PR fulfills these requirements

• The changes have been tested locally
• There are no breaking changes

• What kind of change does this PR introduce?

Key updates:

1. Unify all temperatures to be stored and managed in a common type
2. Smaller fixups for comments
3. Slight improvement to temperature regulation on Pinecil V2
4. Fix fast/slow speeds on PinecilV2
5. Re-tune PinecilV2 to handle (4)

• What is the current behavior?

• What is the new behavior (if this is a feature change)?

• Other information:

[discip]

@Ralim
Good morning,

1. as I read V2 and temperature, I needed to see if anything improved, so I did test this on both the Pinecil_V2 (short tip) and the TS80P, but I have to say that the temperature-fluctuation is still present on the V2. It doesn't even come close to the behavior of the TS80P or V1.

As you know, I have no real idea how the internals responsible for heating work, but isn't the algorithm that makes the TS80P and V1 maintain their temperatures respectively (sandmanRO) the same in the V2?

2. Besides that, what should I expect / look out for when testing this PR?

btw:
Seems you missed the last comment in #1718.
Any chance that the S60P (photos of internals) will be supported alongside the S60?

thanks in advance

[Ralim]

The TS80 series will always look "nice" due to both their tip construction and their limted output power. Any small excursions will just not show up as much there as they cant dump a large wattage into the tip. As the tip wattage increases it becomes harder to solve.

This was mostly aimed at stopping the larger oscillations which this damps down a bunch.

Probably next step in making things look nicer is to add a filter before the user sees the temperature information or speed up the measurement cycles. Both have downsides which is why I havent done them. Another option is to just let users adjust the two tuning values themselves; but that adds yet more overhead everywhere, for the very small number of people who would use it.

The algorithm is the same for them all but they all have different tuning. I went for a branch for a day to move back to a PID and had much better success with performance but it needs a lot more work to tune it in for different units. Its biggest downfall is I can tune it perfectly for one tip, but then its less stable for other ones with different masses. The current system works fairly well for all but not optimal for any.

So really I'm just looking for improvement to help make it perform a little better.
Otherwise this code just stops a few edge cases where things could overflow maths-wise.