LeafLabs Garden » Topic: HardwareTimer refactor

LeafLabs Garden » Topic: HardwareTimer refactor http://forums.leaflabs.com/topic.php?id=153 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:16:17 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php bnewbold on "HardwareTimer refactor" http://forums.leaflabs.com/topic.php?id=153#post-1014 Sun, 05 Sep 2010 18:21:33 +0000 bnewbold 1014@http://forums.leaflabs.com/ I don't think we're going to make any modifications to the silkscreen any time soon, though we are putting together a reference card/cheatsheet that could indicate the mapping. I agree that a getHardwareTimer function would be very helpful. The C timers code is so large because it's crudely written with lots of case/switch branching, which results in additional code size with no speed gains. Regardless of changes to the C++ interface I will refactor this code (maintaining the C api) which should reduce code size. W/R/T the performance of table lookups, the performance penalty would be the same as with the other C++ pin-specific functions, and I think it's on the order of the function calls down to the C functions. If the either overhead is too great, advanced users can always use the C functions directly (especially when writing libraries, which seem to be the most performance dependent). I think the performance overhead of the table lookup is proportionally small, but I would benchmark this before committing to a new API. It's true that users would still have to check a table to make sure their timer-wide configuration isn't conflicting with any PWM configuration, but I think this amounts to much less "table checking". They don't need to know what the timer their chosen output-compare channel is on, just that it doesn't conflict with the PWM timer. I'll think this all through some more and post an actual proposal before changing the C++ API (feel free to propose your own!). gbulmer on "HardwareTimer refactor" http://forums.leaflabs.com/topic.php?id=153#post-991 Sat, 04 Sep 2010 08:07:53 +0000 gbulmer 991@http://forums.leaflabs.com/ sniglen, very good point, I wrote without enough thought. The important point to me is that the user can get much of the important information from the silkscreen on the board, and the functions are easy to use. PWM output is fine with pinMode(pin_num, PWM), and pwmWrite(pin_num, value). From my perspective that is very slightly better than analogWrite, which needs a bit of explanation about why it isn't the same as 'proper' digital to analogue conversion on an Arduino. So I agree with sniglen, the majority of the remaining timer functionality corresponds to the timer's and not the channels. There seems little point having an array of timers, e.g. Timer[1]. setCount(...) because some STM32F timers have different functionality, which may show up in different class interfaces. So, some of my issues would be fixed by adding to the silk screen the mapping from PWM pin to Timer. I don't mind how (very much), it could be an extra annotation next to each PWM pin, e.g. PWM(T1) or PWM(Timer1, ... or in a table. In the code, it might be useful to have a function, which returns the Hardware Timer which corresponds to a pin number, e.g.: HardwareTimer& getHardwareTimer(pin_num); or HardwareTimer* getHardwareTimer(pin_num); So I could write code like: <pre><code>pinMode(LED1, PWM); getHardwareTimer(LED1)->setOverflow(BLINKRATE); pwmWrite(LED1, BLINKRATE/4);</code></pre> Not perfect, but it gets the idea across I could even check in my code if pins might share a timer, and hence 'be in conflict': <code>if (getHardwareTimer(LED1) == getHardwareTimer(SERVO1)) { ... }</code> I'd be happy to have macros at compile time too, but I'd like the run time function, so that I can do dynamic stuff similar to my first LED1 example. There is still some channel related functionality, such as getting the captured value when using a pin as an input capture channel. IMHO, these should be done by pin, though they could also be done by Timer1/TImer2/ etc. methods too. Summary. I humbly withdraw my support for the change. Propose a small annotation on the silkscreen, to give pin_number to Timer documentation on the Maple itself. 'Nice to have' a function to map to the right timer from a pin. Channel related functionality, like input-capture to be at least pin_number based, could be timer based too. PS - why are the timers so huge? snigelen on "HardwareTimer refactor" http://forums.leaflabs.com/topic.php?id=153#post-984 Sat, 04 Sep 2010 02:53:09 +0000 snigelen 984@http://forums.leaflabs.com/ Hi, I understand what you mean by "Arduino-ish", but there is no way to do this in the "Arduino language" (Of course you can do "TCNT1 = 123", but thats a on lower level). And the > Timers.setCount(D12, 200); // Changed to D12, there is no PWM on D13 :-) construct gives the impression that a timer is bound to one pin, when it in fact can be bound to 0-4 pins. And it hides the fact that this statement will affect up to four pins. And it isn't really that hard to look up the timer to pin-map in the pwm documentation on this site. So I'm with CarlO here, keep it like it is now. Timers can be used for more things than just PWM. gbulmer on "HardwareTimer refactor" http://forums.leaflabs.com/topic.php?id=153#post-982 Fri, 03 Sep 2010 21:05:49 +0000 gbulmer 982@http://forums.leaflabs.com/ <blockquote>I'm thinking about refactoring the Timer system to be pin-based instead of timer/compare based. Having so many different functions is really clunky and it would be pretty easy to just lookup the necessary info in a table so that, for instance, you could write: <code>Timers.setCount(D13, 200);</code></blockquote> I like your proposal. The Timer1, Timer2, etc. is so clunky I am put off (and I read the STM32F manuals most days of the week, if I can't get to sleep:-). As you say the proposal is much more "Arduino-ish", i.e. key documentation is on the Maple's silkscreen for the pins, and users don't need to go digging through STM32F manuals, and trying to map to the Maple headers. Having said that, I do appreciate CarlO's point. I sometimes end up writing my own functions for the Arduino to get performance by side-stepping the framework. But, I can do that, and it's often quite easy when the library source code is available. It would be nice to have the two layers that CarlO describes, but if there is a near-term compromise, make the 'public', 'Arduino-like' interface simple and easy to use. My $0.02 CarlO on "HardwareTimer refactor" http://forums.leaflabs.com/topic.php?id=153#post-971 Fri, 03 Sep 2010 01:38:31 +0000 CarlO 971@http://forums.leaflabs.com/ bnewbold My vote would be to not break the current functions. Can't you wrap the current functions with higher level functions that can do the pin look-up and set pin modes etc? One of the things I have noticed on the Arduino, is that the abstraction to pin numbers comes at a cost in speed. It takes time to do the look-up and check/set the pin mode with every call. If for example you wanted to modify your timer count frequently in your sketch, every time you set the count to a new value, the framework code still has all the overhead of looking up the timer, setting the pin mode etc, rather than just setting a new value in the timer register. CarlO. bnewbold on "HardwareTimer refactor" http://forums.leaflabs.com/topic.php?id=153#post-963 Thu, 02 Sep 2010 19:46:52 +0000 bnewbold 963@http://forums.leaflabs.com/ I'm thinking about refactoring the Timer system to be pin-based instead of timer/compare based. Having so many different functions is really clunky and it would be pretty easy to just lookup the necessary info in a table so that, for instance, you could write: Timers.setCount(D13, 200); I could create macro aliases like TIMER2_COMPARE4 so one could still use timers without having to look up which pins are associated with timers. This would make it much clearer which pins would possibly be in conflict, and help save a huge amount of memeory (the timers are a few kb right now, most peripherals are a few hundred bytes). This also strikes me as more "Arduino-ish". Any thoughts? This change would break any code built on top of the HardwareTimer system right now, though it should be possible to release the current version as a library for compatibility.