That is surprising... if using Arm hard float (VFP) - the default - then, assuming you are not using float in IRQs, then the only side effect should really be more use of stack space (automatic lazy floating point state preservation)
You can try setting FPCCR.ASPEN=0 on the CPU to prevent the use of stack if you know you don't need it, though i would be surprised if that is the problem.
It could be related just to the code change/layout, particularly stuff being/not being in flash.
it would be helpful to know if the FP code is running on the same core as the video stuff - particularly there may be some things related to IRQ latency? Again, i don't imagie there is a huge change here unless the FP registers are indeed being stacked.
I assume you mean `pico_float_dcp` not `pico_dcp`
It is also surprising that the choice of float implementation with double would have much effect, unless you are actually doing a bunch of float/double ocnversions you weren't aware of/didn't mean to
You can try setting FPCCR.ASPEN=0 on the CPU to prevent the use of stack if you know you don't need it, though i would be surprised if that is the problem.
It could be related just to the code change/layout, particularly stuff being/not being in flash.
it would be helpful to know if the FP code is running on the same core as the video stuff - particularly there may be some things related to IRQ latency? Again, i don't imagie there is a huge change here unless the FP registers are indeed being stacked.
I assume you mean `pico_float_dcp` not `pico_dcp`
It is also surprising that the choice of float implementation with double would have much effect, unless you are actually doing a bunch of float/double ocnversions you weren't aware of/didn't mean to
Statistics: Posted by kilograham — Mon Apr 21, 2025 4:20 pm