How does the FPU affect context switching on a Cortex-M, and how is it handled?

If a task uses the hardware floating-point unit, the FPU registers (the S0-S31 / D registers plus FPSCR, roughly 17 extra 32-bit values) become part of its context and must be saved and restored on a switch, which significantly increases the per-switch cost. Cortex-M cores with an FPU mitigate this with lazy stacking: on exception entry the hardware reserves space for the FPU context but doesn't actually copy the FPU registers unless and until the handler (or the code it switches to) actually uses the FPU, so a switch between two tasks that don't touch floating point avoids the FPU save/restore entirely. The RTOS port must be configured to handle FPU context (FreeRTOS enables this when built for an FPU-equipped core), and you must ensure any ISR that uses floating point is accounted for. The practical implications: float-heavy tasks make context switches noticeably more expensive, so you factor that into the timing budget and stack sizing (the reserved FPU frame adds to stack usage); and a subtle bug class is using the FPU in code paths (like an ISR) where the port doesn't expect it, corrupting FPU state. So the FPU roughly doubles the context size when active, lazy stacking avoids paying for it when unused, and the port/configuration must explicitly support it.