Marlin: Temperature values now int instead of float (RC8 to 1.1.1)?

[040medien]

Hi!

Congrats on the release! I distinctly remember that temperature readings used to be reported with one decimal place accuracy with RC8. Now that I run 1.1.1 however they are reported as ints. Am I crazy or did you change something? I use a Rumba board if that makes any difference.

Thanks,

Frederik

[Roxy-3D]

For right now... They are int's. But it is possible they go back to float's. Mostly, the change was driven by the fact the 32-bit processors can't do floating point operations inside an interrupt routine.

[Tannoo]

Isn't that odd.

[Roxy-3D]

I think it was an optimization issue in GCC. They decided not to save all the floating point processor unit's registers at interrupt time (in order to save time). But what that means is you can't do any floating point math at interrupt time. And my guess is... they were also concerned if a floating point operation was in progress when the interrupt happened. Because they would have to spin and wait for that to complete before they could save the registers.

With that said... Double's are done entirely in a software library and if we really need floating point math, we can do it as double's on the 32-Bit processors.

PS.
@Tannoo I just loaded 2 of my printers with the current firmware today. I didn't see the merge notice but I saw your stuff in the LCD Display. I haven't had a chance to play with it yet, but I did run through the menu. It looks very well organized!

[040medien]

I appreciate that you have a brand new stable release and that some hard choices are necessary around launch. I hope that this regression is only temporary since it affects the bulk of your users while 32 bit is probably a minority (for now).

[teemuatlut]

But.... The readings are not stored as floats. They are uint16 as raw readings and then again stored as int16 (I don't know why the conversion). They are only converted to floats when manage_heaters() is called. Is there something I'm missing?

[p3p]

@Roxy-3D It not a case of 32bit micro-controllers not supporting floating point operations in ISRs, but that hardware floating point support is more like a co-processor and has extra complications that need to be handled, it has extra registers that need to be context saved, how data is passed to it, increases interrupt latency unless micro can use lazy stacking, ect. (Detailed overview for Cortex-M4(F))

The easiest solution is to disable it, Marlin doesn't really need it and it only works for single precision anyway, so you have to be very careful with type promotion during calculations. If you, and the libraries you use, handle it properly it should be fine, I didn't notice any issues with the STM32 libraries perhaps it was a 32bit Arduino issue, a limitation of that specific micro? or .. I never hit the exact situation that causes the problem.

[bobc]

My hope with 32 bit support was not to have any impact on AVR code. The
issue with floats in ISR is a "bug" specific to ESP32, which uses a quite
obscure 32 bit core, with GCC support cobbled together by the vendor.
Personally, I think the ESP port should workaround the problem, and not
cause effects elsewhere.
If we make changes every time we find a quirk in a particular processor
core/compiler, then the Marlin code is going to end up a real mess.

On 14 May 2017 at 11:34, Chris Pepper [e-mail] wrote:

@Roxy-3D https://github.com/roxy-3d It not a case of 32bit
micro-controllers not supporting floating point operations in ISRs, but
that hardware floating point support is more like a co-processor and has
extra complications that need to be handled, it has extra registers that
need to be context saved, how data is passed to it, increases interrupt
latency unless micro can use lazy stacking, ect. (Detailed overview for
Cortex-M4(F)
http://infocenter.arm.com/help/topic/com.arm.doc.dai0298a/DAI0298A_cortex_m4f_lazy_stacking_and_context_switching.pdf
)

The easiest solution is to disable it, Marlin doesn't really need it and
it only works for single precision anyway, so you have to be very careful
with type promotion during calculations. If you, and the libraries you use,
handle it properly it should be fine, I didn't notice any issues with the
STM32 libraries perhaps it was a 32bit Arduino issue, a limitation of that
specific micro? or .. I never hit the exact situation that causes the
problem.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/6728#issuecomment-301303693,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA7VRyMhhlyF3DG0_PRJ-u-No9NawpvGks5r5tifgaJpZM4NaOx-
.

[p3p]

Thanks for clearing up what caused this change, I was a little confused with Roxys response.

[thinkyhead]

Merged #6811, which restores degHotend and degBed to returning float.