I will tell my grandchildren about the time I wrote some resolver support code and it worked on the first try.
To provide support to the SPI resolver interface I based my code in benjamin's code for an SPI encoder IC which is not so different to our resolver chip, we just need some extra control signals. One is the SAMPLE that latches the current position so it can later be read over SPI. The other is RDVEL that selects between rotor position and velocity.
These extra firmware lines are only available when the project is configured for this board. (#define HW_VERSION_PALTA)
CLK looks funny because the logic analyzer sampling rate is near the 4MHz SPI CLK frequency.
Then you need to add a way to select this type of position detection within the GUI. For that you need to tweak a bit the GUI source, you just need to install Qt creator and clone vesc_tool repo. I used to be a competent Qt programmer in a previous life so I could find my way to adding the menu item and the motor configuration enum to the GUI. Something I did not take care of is hiding this extra resolver type when the user connects a regular VESC which obviously doesnt come with resolver support. I guess benjamin has a clever way to deal with that.
The position read requires a falling edge of the SAMPLE signal to latch the postion register. I assert that at the same time the ADC is sampled, because I want the picture of voltages, currents and position to be simultaneous. However, the current SPI implementation surprisingly is a bitbanging approach, super low performance and cpu consuming so I can't get the position read on time, it is always available in the next control loop iteration (50us later).
This is alright if accel is not really high, but migrating to a full DMA with 20MHz SCLK (1us readout) is high in my list of priorities so we can actually have simultenous V, I and postion. There is some position error estimation in place but I'd avoid that if I can.
DMA SPI is not an easy task, I'm used to work barebones but here the rtos manages these things and I'm not familiar with ChibiOS. I think that once I configure SPI3 the OS will handle it in a DMA-way.
So, in theory it is working. I say in theory because my 400Hz resolver is no good for this, scope captures of sin/cos look really bad, neither of those get close to 0Vpp in a full turn, but the digital interface is working well, and the IC properly detects DegradationOfSignal and LossOfTracking.
I'd call it a day and move on to the FPGA which I'm unboxing.