Add Tle5012 encoder support

[Teslafly]

Provides support for the Tle5012 hall encoder using the ssc interface (spi but with combined bidirectional miso/mosi)

Uses software bitbanging but supports both the hall sensor port and hw spi pins (useful if hall port has filters you cant remove) As sensor transactions use 48 bits for communication I have slowed down the update rate to 4khz vs the usual 10khz to save cpu time. Though using the lisp cpu poll status it shows ~1-2% cpu usage.

I intend to eventually support native dma hw spi/ssc as well. But bitbanging works for now.

https://www.infineon.com/dgdl/Infineon-TLE5012B_Exxxx-DataSheet-v02_01-EN.pdf

[vedderb]

Nice work!

The lisp cpu-meter does not show you how much the encoder is using, it shows how many of the total cycles available for threads (excluding interrupts) are used by lispbm. You would have to measure how many cycles are spent in the encoder timer isr. I'm thinking of making that isr into a thread with high priority instead, which makes it much easier to see how much cpu the encoders are using.

About the implementation, I think that even hw spi would take some cycles, especially with all the checks and the crc-implementation that uses a nested loop instead of one loop and a lookup table.

[Teslafly]

I had noticed that another sensor used a lookup table for crc but the current version was working at the time and didn't want to figure out if that method was portable to my sensor. I could switch to the table based version if that would be significantly faster. The current crc check here is straight out of their example code.

I was thinking that the main cpu time consumer was doing the bit banging. On my scope it runs at around 1mhz clk and needs 48 bits to read the angle. 16 bit command +2x 16 bit reads. With some delays in there it tends to take around 70us where cs is asserted. Running back to back with no downtime in just the data transfer that would be 1/70us=14khz.

I can take a stab at making the crc faster. But if I can't get to it then it would be great if this was merged before the December release. Or this can just be merged and I'll make a new pr for crc improvements.

[Teslafly]

Ah, already merged. Great.

[Teslafly]

I'm thinking of making that isr into a thread with high priority instead, which makes it much easier to see how much cpu the encoders are using.

How would that work with the encoders that use hw spi and dma with a spi function callback? I don't think that would be able to capture a good idea of encoder cpu usage for that case?

[vedderb]

If the callback-function is short for those encoders I think it is ok to just assume that the cpu-usage is not a problem. It is more important for the software encoders.

I'm working on it now, I think I will change it to use a thread instead. Then we can see how much it uses.

[vedderb]

I just pushed some updates where I also moved the routine into a thread. The problem with measuring relatively short routines like that is that the the system time does not increase while it runs (although the time in the idle thread decreases, which gives some indication).

I hope my changes didn't break anything, would be great if you can give it a try as I can't test it.

[Teslafly]

Just pulled your code changes and tested them. encoder still works fine and spins the motor at a cursory try.

I am using this board to mount the sensor. It's little more than a breakout, but makes mounting and connecting convenient. And matches up 1:1 with the vesc hall connector pinout. https://github.com/Teslafly/TLE5012-Hall-Encoder-Module