openinverter forum

After playing with the F4 a bit I thought it would be pretty neat to be able to use floats on the F1. Yes it will be soft-float but that should be ok for the slower 10 & 100ms tasks. I would like to restrict the fixed-point math to the 8.8 kHz control ISR only.

Problem so far has been that using any sort of float operation would result in a hard fault. That is because gcc by default uses the "wrong" libgcc.a.

I have forced it to use one with floating point implemented by changing LDFLAGS from
to

-Llibopencm3/lib -L/usr/lib/gcc/arm-none-eabi/11.1.0/thumb/v7+fp/softfp -T$(LDSCRIPT) -nostartfiles -Wl,--gc-sections,-Map,linker.map
There is probably a better way to do this, i.e. not having an absolute path in there.
UPDATE: there is. Just specify -march=armv7

I think this is particularly interesting for the ZombieVerter project as that has no fast loops at all.

Now the plan for porting to float:
1. Add a function Param::GetFloat()
2. Port modules like Throttle, VehicleControl etc. to float
3. At some point actually store parameters as float, while being able to load legacy fixed point parameters

Ok, sine project ported up to step 2, take a peek here: https://github.com/jsphuebner/stm32-sine/tree/float

Binary size increased by 4k.

Successfully tested in Touran CPU usage is unchanged I think, 33%

Thanks for this Johannes. I am concerned by your work on the F4. If you can run a car with foc on an F1 using only 33% of its run time then what will you do with all that spare horsepower in an f4?? Oh wait! CCS of course

yes lets bitbang PLC with one of the DACs to get rid of that Qualcomm rubbish
The F4 project will be sending and receiving some CAN. Hope it won't quit work because of bore-out.

Drove around with the float firmware a bit and somehow it's not as smooth as before. Cruise control started stuttering on an uphill. Must be still some scaling issues.