http://forums.leaflabs.com/topic.php?id=794 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:06:15 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=794#post-4957 Fri, 03 Jun 2011 15:07:28 +0000 mbolivar 4957@http://forums.leaflabs.com/ <p>gbulmer,</p> <blockquote><p> None of this requires a timer class, or creating a timer instance. </p></blockquote> <p>I like that. Sounds like a good way to start moving forward. </p> http://forums.leaflabs.com/topic.php?id=794#post-4876 Sun, 29 May 2011 20:11:43 +0000 gbulmer 4876@http://forums.leaflabs.com/ <blockquote><blockquote>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?).</p> </blockquote> <p>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().</p> </blockquote> <p>Assuming this is restricted to an 'Arduino-like timer', with no alternate-pin-mapping (this is for quick, simple stuff and beginners). </p> <p>The timer carries the pre-scaler and 'autoreload' value, so that could be deduced from a pin number.<br /> Then timer output compare is unique to a pin for things like pwmWrite().</p> <p>I was thinking along the lines of the usual Arduino library function <code>pwmWrite(int pin, int value);</code><br /> With either overloading for a tastefully chosen class-type which represents the timer itself, or 'magic pin numbers' (could be negative or large pin numbers?)<br /> for timer-specific functionality like the counter prescaler or counter autoreload.</p> <p>I think a class-based timer is more complex than necessary for the purpose I'm suggesting.<br /> I don't need to introduce the idea of a timer which has multiple channels to a beginner. I just introduce pwm, and initially treat the frequency and range as fixed.</p> <p>A key problem with timer-class-based timer is it is an unnecessary level of indirection for beginners.<br /> Each timer has upto 4 output pins, how do folks get from timer 6 to the output pins?<br /> IMHO, that is extra complexity, and not KISS.</p> <p>IMHO, it is easier base it on the simple Arduino approach e.g. <code>pwmWrite(pin, value);</code><br /> The concept of a timer is only necessary when setting the prescaler or autoreload.</p> <p>That seems pretty simple to encapsulate in either 'magic' pin numbers, or a class, and derive a value from a pin number.<br /> <code>... pwmTimer = pin_to_pwm_timer(pin);</code><br /> <code>set_pwm_timer_prescaler(pwmTimer, 72);</code><br /> <code>set_pwm_timer_maxcount(pwmTimer, 1000);</code> // autoreload is a poor name</p> <p>None of this requires a timer class, or creating a timer instance. "Simples (squeak :-)" </p> http://forums.leaflabs.com/topic.php?id=794#post-4824 Thu, 26 May 2011 15:02:18 +0000 mbolivar 4824@http://forums.leaflabs.com/ <p>sorry, didn't answer your question.</p> <p>AdvancedTimer would be used to control TIMER1 (and TIMER8 on high-density boards). those are pretty awesome timers, with all sorts of cool functionality. for example, they can do complementary outputs with dead time insertion, and it may be worthwhile to include a Wirish API for that.</p> <p>however, that capability is limited to timers 1 and 8. similarly, timers 6 and 7 don't have capture/compare channels. i don't want to break the interface up just to make learning easier (although that's a great bonus). it's that there are actually three different kinds of timer hardware on the STM32, so it doesn't make sense to have one giant timer class that represents the union of all of their capabilities.</p> <p>anyway, limiting it to 3 is a little bit of an oversimplification as well, since timers 10, 11, 13, and 14 are given as "general purpose", but only have one capture/compare channel, unlike timers 2, 3, 4, 5, 9, and 12, which have 4. but as you say, i don't want the APIs to blow up and get completely out of control unnecessarily. instead, i was thinking the docs could just clearly state this sort of restriction on the less full-featured general purpose timers.</p> <p>edit: typo </p> http://forums.leaflabs.com/topic.php?id=794#post-4822 Thu, 26 May 2011 14:45:25 +0000 mbolivar 4822@http://forums.leaflabs.com/ <p>sure, HardwareTimer mostly just calls out to timer_foo functions. the point is that there are many of those, and their number is only going to keep growing. the complexity i'm saying we should hide is not the HardwareTimer wrapper, it's timer.h itself.</p> <p>having a SimpleTimer allows writing documentation which just presents those very basic pieces of functionality that will probably be enough for most people's purposes.</p> <p>personally, i often feel overwhelmed when i first open up a large API listing. it's sometimes enough to drive me away from the interface altogether. having a tiny SimpleTimer class with just the basics is more encouraging and beginner-friendly, at least in my mind.</p> <p>edit: spelling </p> http://forums.leaflabs.com/topic.php?id=794#post-4821 Thu, 26 May 2011 14:34:40 +0000 robodude666 4821@http://forums.leaflabs.com/ <p>I don't see the complexity behind the current <code>HardwareTimer</code> class. It's just a wirish class wrapper for the c functions libmaple has to control the different aspects of the timers. Most methods in the <code>HardwareTimer</code> class simply call one c function. The most complex one calculates the overflow/prescaler required to reach a certain period, which in itself is not very complex. I'm not understanding the benefit of breaking HardwareTimer into 3 different classes, making the API more complicated.</p> <p>In your <code>SimpleTimer</code> example you haven't done anything different than what <code>HardwareTimer</code> already can do very easily. Could you provide some examples of what the <code>BasicTimer</code> or <code>AdvancedTimer</code> would look like and how they'd be used? </p> http://forums.leaflabs.com/topic.php?id=794#post-4820 Thu, 26 May 2011 14:28:32 +0000 mbolivar 4820@http://forums.leaflabs.com/ <p>gbulmer,</p> <blockquote><p> 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.</p> <p>In the spirit of KISS 'keep it simple', I think that is all that the intersection of timer functionality contains.</p> </blockquote> <p>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.</p> <blockquote><p> I think that is enough for a lot of uses of timers.</p> </blockquote> <p>i very much agree. make simple things easy, after all.</p> <blockquote><p> 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?). </p></blockquote> <p>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 :).</p> <p>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.</p> <p>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):</p> <pre><code>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(); }</code></pre> <p>you may notice that this accomplishes the same goal as, but is far simpler than, the Arduino BlinkWithoutDelay tutorial example:</p> <p><a href="http://www.arduino.cc/en/Tutorial/BlinkWithoutDelay" rel="nofollow">http://www.arduino.cc/en/Tutorial/BlinkWithoutDelay</a></p> <p>i agree that the SimpleTimer interface should be extremely limited. these are the methods i think are appropriate:</p> <p>void setPeriod(milliseconds)<br /> void setPrescaler(prescaler)<br /> void setOverflow(overflow)<br /> void attachInterrupt(handler)<br /> void detachInterrupt()<br /> void refresh() [could also name this reset()]</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>as for the other two proposed classes:</p> <p>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).</p> <p>finally, the AdvancedTimer could add trigger and break inputs to the Timer interface, and perhaps a straightforward timer synchronization interface.</p> <p>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.</p> <p>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. </p> http://forums.leaflabs.com/topic.php?id=794#post-4818 Thu, 26 May 2011 05:48:30 +0000 gbulmer 4818@http://forums.leaflabs.com/ <p>mbolivar - I agree in principle to three new interfaces, but I am not sure I understand how it will work.</p> <p>Can you write a few use cases, or examples for each type of interface? It might be easier for people to understand and comment.</p> <p>I assume common features, which use common functionality will be the same across all types of timers?<br /> Are you thinking of a C++ Class-based interface, or C-function-Style, or both?</p> <p>Maybe there are 4. </p> <p>One of which is like the Arduino, which represents the intersection of functionality, and helps folks familiar with the Arduino, come up to speed. This may be the current HardwareTimer with a C-style function interface to make it easy for migrating Arduinauts (not sure what the right noun is:-).</p> <p>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.</p> <p>In the spirit of KISS 'keep it simple', I think that is all that the intersection of timer functionality contains. It is the basic timer with a pin-id. I think that is enough for a lot of uses of timers. 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?).</p> <p>(full disclosure: I am not a member of LeafLabs staff) </p> http://forums.leaflabs.com/topic.php?id=794#post-4786 Wed, 25 May 2011 10:56:15 +0000 Xavier 4786@http://forums.leaflabs.com/ <p>From what you wrote, i agree that having 3 different interfaces sounds good.<br /> No need to deal with complicated API if a simple one is enough.<br /> And smooth upgrade path.<br /> Many good reasons.</p> <p>Xavier </p> http://forums.leaflabs.com/topic.php?id=794#post-4780 Wed, 25 May 2011 03:26:42 +0000 mbolivar 4780@http://forums.leaflabs.com/ <p>i'm currently toying around with the idea of abandoning HardwareTimer altogether in favor of three separate interfaces for the basic, general purpose, and advanced timers.</p> <p>the advanced timers are awesome, but they're fairly complicated, especially if you're just starting out. in contrast, the basic timers (high density devices only, which limits it to RET6 Edition and Native for now) are great for getting started with the core idea of a prescalable counter which can interrupt on overflow -- and the fact that the basic timers have no capture/compare channels means that you can use them without worrying about messing up PWM and poring over the timer pin maps to make sure you've done everything right.</p> <p>having separate interfaces also means we can have separate documentation. this provides a smoother upgrade path for incrementally adding timer features to your bag of tricks; as soon as you've outgrown the basic timers, you can move on to general purpose ones, and from general purpose timers you can finally upgrade to advanced.</p> <p>for these and many other reasons, i think there's a strong case for deprecating HardwareTimer altogether.</p> <p>thoughts? </p>