Was FManga’s assumption that CT16B0, CT16B1 and CT32B1 are free correct?
If so then originally I was going to hijack CT16B0 which aparently isn’t in use, so if my function had been fast enough then I assume that would have been possible and wouldn’t have been too much of an issue?
Fortunately I now know that I can do.
I know that I can userTicker (or even better use Timeout) by changing how I tackle the issue,
so I don’t need to worry about all the complicated stuff that comes without the HAL.
To be perfectly honest, I can’t answer that offhand. Before I can answer that, I need to step through the steps the mbed HAL takes in initialization, to make sure which timers are actually used.
What makes the situation difficult to follow is the mbed HAL. The way that it handles interrupts is rather peculiar. The NVIC is redirected to RAM and all timer and PWM interrupts are routed through one interrupt handler that essentially replicates a lot of the built-in PWM/timer functionality. I may remember some of the detail wrong but the main thing is that there is one software handler that works as a master.
Now, when you hijack one of the timers, the trick is when do you hijack it. If you just write the interrupt handler into the code, you can not be sure the interrupt gets redirected to the handler. The reason is simple. If the mbed HAL handler is initialized at a later stage, the NVIC vector will point to the general handler instead of your IRQ handler - even if it has been properly declared.
In summary: yes there are free timers. And yes they can greatly speed up things. But you almost need a hardware debugger to be able to set them up in such a way that you are able to debug exactly why something does not work if it does not work.
I don’t know if it’s worth me looking into it since I’ve already found a solution to my underlying problem,
but I might look into it at a later date for some reason.