Dan, I'd like to include your library or similar functionality into the core library, which is the built-in support that comes with Teensy. But doing this would involve changes... which might amount to rewriting much of it? I don't want to give you the impression I don't like what you've done. In fact, it's really nice. So please don't take these many suggestions the wrong way.
To be included in the core library, it needs to be MIT license. If this becomes part of the built-in support, of course your name will remain in the code as required by the license. I'll also mention you in 2 places on the website, the release notes on the download page, and on the
Timing page, where I'll add documentation about using these functions. I want to give you full credit for your work!
The core library is maintained by PJRC. Once included, there will be limited opportunity to change it. So we really need to get this to a final state before including it. There are a lot of changes I'd like to consider.....
First, I'd like to see the dynamic assignment work a little differently. Arduino has 2 conventions for objects, pre-instantiated (PITimer0, PITimer1, PITimer2) and user defined (myTimer, myOtherTimer, etc). Normally pre-instantiated objects represent fixed hardware resources, which is the model you're using now. I'd like to give users a more abstract model, where they create instances without specifying which hardware resource will be used.
Another strong Arduino convention is the use of begin() and end() functions, to start and stop actually using the hardware. I'd really like to see the object constructor do very little. The begin() function would dynamically assign available hardware to the object, either by inspecting the hardware registers for a timer not in use, or by using a static variable, probably a bitmask of which timers are in use, or by any other method you think is appropriate. Likewise, the end() function would release the hardware and mark it as available for other objects.
As a longer term goal, when a slow period that's an integer number of milliseconds is used, rather than using a PIT timer, the library could integrate with the main systick timer interrupt using a small table of callback pointers. Or it could possibly be written to share a PIT between multiple objects if they have the same period or periods that are integer multiples. A more abstract object which doesn't expose hardware details like PIT0, PIT1, PIT2, etc can facilitate all these things. The user just creates an interval timer, gives it a period and callback function, and how the library actually achieves the functionality is not something they need worry about. It can be ported to other chips with different types of timers, and has the flexibility to be implemented in many different ways.
A more generic name might be good. There's a strong convention on Arduino to use longer, plain English names. Perhaps "IntervalTimer" might be good? I'm open to ideas. Staying with PITimer might be ok too? But I'd really to give the user a model of an abstract interval timer, rather than a specific hardware resource.
Another design goal I'd like to see would be a minimalistic API. Currently it looks like there are 15 public functions. I know it's painful to take away functionality, but I really do believe a minimal API is much simpler to learn and use. It's also much easier to document. A really minimal approach might be only 2 functions: begin(period, function) and end(). A way to temporarily prevent/delay the function call without fully disabling interrupts (and without disrupting the interval) might be worthwhile? But I'd like to avoid providing access to the actual counter and multiple functions to access or change the period. However, it might make sense to have some of that stuff as protected variable or functions, which would allow a class that inherits from the simpler class to provide a more fully featured API.
I realize this is a LOT of stuff, perhaps changing almost everything in the library. Please let me know your thoughts?
