Tyler pit steppers

[Naitry]

fixes #10

Primary Changes

In this I use PITs (Periodic Interrupt Timer) to output pulses for stepper motor control rather than the previous strategy where it continuously checked if the period was up.

This technically limits the steppers to 4 using these specific timers.
The timer is setup in the stepper constructor and attached to a function to flip the pulse pin of the stepper.

This allows us to reduce the calls in the main loop to only be the call to parse serial input. and never block the motors, just flip them based on interrupts.

Minor Changes

I also made a few minor stylistic changes.

1. All header files were changed to .hpp extension vs .h.

   • Reason: Consistency. This is a c++ project, while any extension will work, hpp more effectively highlights that these headers belong to a c++ project.11

2. Header guard preprocessing statements were changed from #IFDEF style guards to #PRAGMA once

   • Reason: Performs the same task with any modern compiler, harder to cause unintended behavior with preprocessor statements. (Something like an #ENDIF accidentally being deleted)

Status:

built successfully but not tested in practice

[ethanholter]

You will have to walk me through the larger chunks of new code. Seems like you reference a lot of mysterious registers which I would like to know their purpose. some comments wouldn't hurt either, especially in cases where the code is not very self explanatory or uses niche info from the datasheet. other than that the code looks good. see if you can make any additional changes now because I'm still new to the built in code review process and would like to see how that works

[ethanholter]

see other comment

[Naitry]

-> #11 (comment)

My previous implementation directly wrote to the timer control registers for the PIT timers. While I have found several examples of this usage, I could not find it in the official ARM Cortex-M7 docs, so I opted to switch to the interval timer library made for the teensy. I have used this library before and trust it to work well.

Here is what they use to interface with the timers::
https://github.com/PaulStoffregen/cores/blob/master/teensy4/IntervalTimer.h
https://github.com/PaulStoffregen/cores/blob/master/teensy4/IntervalTimer.cpp

It's similar to what I was doing, but a little more intricate and flexible.

with commit 2fb7243 I have switched to this IntervalTimer implementation, hopefully clarifying what is happening.

I have also added comments throughout the IntervalTimers.hpp and Steppers.hpp files to explain my changes

[ethanholter]

this might be a problem. currently we are using every single one of these. If we want to add any more hardware then we will need to find more options. for now I think this is still a better way of doing things but its something to be aware of

[ethanholter]

https://www.pjrc.com/teensy/IMXRT1060RM_rev3_annotations.pdf

[Naitry]

I agree, It's not totally ideal.
We have a couple options if we want to add more steppers controlled with common anode pulses in the future::

• Utilize other types of timers that should be on the teensy. We would need to interact with registers directly as these timer types are regularly controlled by analogwrite functions on teensy:: https://github.com/PaulStoffregen/cores/blob/master/teensy4/pwm.c#L236. We just need to add the open drain configuration not regularly available with pwm.
• Use dedicated hardware, I think some LED drivers would be capable of creating up to 8 or even 16 or these signals originating from I2C or SPI commands, reducing connections to the teensy, and still not something that gets blocked by serial intake.
  If we are bored I think these would both be good upgrades, the dedicated hardware would allow for more full utilization of the teensy, imo

[Naitry]

The registers my first version was using via the docs you linked::

Chapters 51-55 have all the info we need on using the other timers available on the teensy if we want to take that route