gbulmer,
For example, pwmWrite would stay, and add its counterparts for setting the counter prescaler, overflow/reload and resetting it. It would have an interrupt service routine too. This would be an Arduino-like C-function interface.
In the spirit of KISS 'keep it simple', I think that is all that the intersection of timer functionality contains.
that's an interesting idea, and one that i hadn't thought of. that seems like it would make an excellent first step on the learning curve.
I think that is enough for a lot of uses of timers.
i very much agree. make simple things easy, after all.
I think a nice solution would use both the Arduino output pin-number method to identify the channel (no I/O remapping supported), and expose the timer itself as a thing (a little bit of overloading?).
sorry, not sure what you mean here. are you saying that e.g. we would control the capture/compare value for a channel via the pin number that the channel is attached to? i'm not sure that that's distinct enough from pwmWrite(). as far as input capture is concerned, i do think it's a cool idea to extend pulseIn() via some overloading magic into a pulseIn(pin) that used timers for extra precision (the arduino implementation just busy-waits and uses micros()). so if that's in line with what you're suggesting, i like it :).
you're right that i should be more clear in what i've been imagining might make a better interface. i was thinking of at least three separate timer classes; which for the purposes of this post i'll call SimpleTimer, Timer, and AdvancedTimer, corresponding respectively to basic, general purpose, and advanced STM32 timers.
i was imagining that SimpleTimer would contain the basic interface that you described. for instance, you'd be able to make the following blinky sketch (on the RET6 edition):
SimpleTimer timer(6); // grab a SimpleTimer wrapper around TIMER6
void setup() {
// Configure LED
pinMode(BOARD_LED_PIN, OUTPUT);
// Configure prescaler and overflow for 10 ms period
timer.setPeriod(10);
timer.attachInterrupt(handler);
}
void loop() {
}
void handler() {
toggleLED();
}
you may notice that this accomplishes the same goal as, but is far simpler than, the Arduino BlinkWithoutDelay tutorial example:
http://www.arduino.cc/en/Tutorial/BlinkWithoutDelay
i agree that the SimpleTimer interface should be extremely limited. these are the methods i think are appropriate:
void setPeriod(milliseconds)
void setPrescaler(prescaler)
void setOverflow(overflow)
void attachInterrupt(handler)
void detachInterrupt()
void refresh() [could also name this reset()]
i think even pause()/resume() [actually, stop()/start() would probably be better names] are overkill for this "primer" interface, but i'm willing to hear arguments to the contrary.
this is essentially the functionality you were suggesting should be on their own as C functions (i've added setPeriod() since prescalers in particular seem to be a common stumbling block). i'm not sure which of classes and distinct functions is preferable, pedagogically. having a class encourages thinking about the methods as interrelated, and makes it easier to view the more featureful/complicated classes as later steps in the same progression.
having distinct functions is syntactically simpler and certainly doesn't preclude presenting them together. however, because of the way our documentation is structured, this would imply having a separate docs page which referenced all of the related function API pages. these aren't major drawbacks in my mind, and the extra simplicity may turn out to be a big enough win that it's worth it.
one neat trick that having three separate classes allows is that since the SimpleTimer interface is the intersection of the capabilities of all the timers, you could construct a SimpleTimer wrapper around any of the available timers (since an instance just wraps a libmaple timer_dev), instead of requiring that you treat TIMER1 as an advanced timer.
as for the other two proposed classes:
i imagine that Timer would look something like HardwareTimer. once you're familiar with SimpleTimer, adding the concept of capture/compare interrupts is a straightforward extension of the idea of basic overflow interrupts. that gives you a toe-hold into the extra complexity. once that's understood, you can work your way up to output compare and input capture, using the already familiar concepts of pwmWrite() and pulseIn() (though the latter has yet to be included with libmaple, the Arduino implementation will almost certainly port unchanged).
finally, the AdvancedTimer could add trigger and break inputs to the Timer interface, and perhaps a straightforward timer synchronization interface.
i think it would be better to leave the timer DMA capabilities out. DMA is a nice feature, but it's conceptually unrelated, and i think putting it in to the timer interfaces would muddy the waters too much to be worthwhile. i think there should be a separate, class-based DMA controller interface for handling all of that.
there are of course other timer capabilities which we could include, but to me they don't seem like such killer apps that including them merits violating KISS. for instance, timers 6 and 7 are useful for controlling the DAC, but i think it would be better to have a separate DACTimer interface for doing that which extends the SimpleTimer interface, and is documented to only work for timers 6 and 7.