TS3633-CM1 sensor support, HW dual edge capture, 48MHz timing resolution, and more

[almostsquare]

This is a large pull request that is a rewrite of the existing CMP0 pulse width capture routine with a new FTM1 hardware managed dual-edge capture routine. The code is structured to run both concurrently, so you can test the validity of the code side-by-side. The new timer capture routines call the same pulse_process() with some downscaling of resolution to fit the old us timebase.

This is my first pull request, so please let me know any feedback you have on how best to structure this to integrate with the existing codebase. Thank you!

Changes

1. Improvement in time resolution by 48x using hardware timer to capture at 48 MHz ticks instead of micros system call (20.83 ns vs 1 us). This should allow for higher precision position fixes.
2. Improvement in edge jitter by using FlexTimer (FTM) dual edge capture hardware instead of CMP0 ISR.
3. Allow for active-high or active-low sensors. TS3633-CM1 sensor enabled by default.
4. Move process_pulse() out of fast ISRs to allow for faster interrupt servicing. This is in anticipation of servicing 4+ TS3633-CM1 sensors with FTM0 in a future hardware build.
5. Dynamic selection between old and new code to allow for side-by-side testing.
6. Stub functions and tests for a future PulseClassifier from @keir.

Hardware wiring
Wire sensor envelope signal to (existing) pin 12 and (new) pin 3 on Teensy 3.2 to allow side-by-side testing of old and new code.

Sensor selection
To use with your existing homebrew sensor, set sensor0_active_high to true in setup.cpp. To use with the TS3633-CM1 sensor, set sensor0_active_high to false in setup.cpp.

Dynamic selection
To toggle between the existing CMP0 interrupt routine and the new FTM1 dual-edge timer capture routine, send "h" over the serial port. You can check whether the pulse width measurement is done with the FTM1 dual-edge timer hardware by sending "a" over the serial port. The ISR count will be appended with a "*" if using the FTM1 timer hardware.

[ashtuchkin]

This is great. Took a glance and all seems reasonable. Will check it on my hardware when I come back home from vacation and will do a more through code review, likely on the weekend.

Meanwhile, why did you decide to write your own PulseClassifier? I already have some code in data_decoder.cpp that extracts the whole data frame (it's not that useful, though).

[almostsquare]

Thanks!

As a practical matter, the separate PulseClassifier stub is not needed in this PR. @keir and I are both working in the same repository, and his PulseClassifier and RingBuffer commits are interleaved with mine. However, I'm not good enough at Git to know how to cherry pick and remove specific changes (e.g. ba36d4a, 977ad5e, a5f5d19).

Your existing pulse processor, data decoder, and position solver code will work with this PR. The stubs are in place so that in the future the actual hardware implementation (whether CMP0/FTM1 today or FTM0 and auto-DMA memory transfers in the future) can be abstracted away from the downstream Lighthouse pulse processing code. This allows us to playback arbitrary pulse sequences into the PulseClassifier without needing the Teensy hardware and can be independent of the specific HW implementation.

[ashtuchkin]

In recent commit 631de22 I added support for the FTM timer input source with an adjustable time resolution and polarity, getting to feature parity with this diff.

While I won't be merging this code as the source tree is completely different now, I want to thank you @almostsquare for this diff because it pushed me to do a complete rewrite this project, hopefully making it better.

[abhijeetvhotkar]

I'm getting an error while I build using cmake ..

CMake Error at CMakeLists.txt:21 (add_firmware_targets):
Unknown CMake command "add_firmware_targets".
-- Configuring incomplete, errors occurred!
See also "/home/abhi/vive-diy-position-sensor/build/CMakeFiles/CMakeOutput.log".

Can you please help ? @almostsquare @ashtuchkin

Thanks