Using the Timer Counter Block of the Arduino Due as a hardware counter

[pklaus]

Adding support to use the Timer Counter Block of the Arduino Due as a hardware counter with the TCLKx pins as clock input for the counters.

This pull request is not finished in the way that you should pull it right away, I just created it to move our discussion from the specific commit to this pull request because the commit&comment might get lost as I'll continuously rebase the branch on the current upstream master (thus auto-creating new commits). So @ivanseidel, please post your comment here again.

[ivanseidel]

I wouldn't change the Main DueTimer class. Instead, creating a TimerCounter class that extends DueTimer is the best solution, to avoid a class with thousands of methods. But, it's good to add the pin and Channel to the Timers configuration array.

What I suggest:

• Implementing a new class called TimerCounter that extends DueTimer
• Implement methods: getValue, setValue.
• Override start method to run setUpCounter protected method and do others modifications to work properly

[pklaus]

I can perfectly understand that you want to keep the API of DueCounter clean.
Don't you think that it would be better for the Timer and the Counter classes to inherit from a common base class? The timer and the counter implementation are just so fundamentally different that I don't think they would share much code.

I'm not a C or C++ expert (I'm more the Python guy), so I cannot say how this is done best.

Also @colombod's comment sounds sensible to me.

BTW: In gist:5743872 I show how I'm using the Timer Counter as a hardware counter already. It needs the modified library version of this pull request. It counts using T0, ..., T5 and uses T8 as a timer to read out the counter values.

[ivanseidel]

Here is what I pretend to do: Milestone V2.0

What I suggest, is that we cancell this pull, and start working on the V2.0 Branch, so that until we are not REALLY finished with modifications, the master branch still working.

[colombod]

I just think that having a good abstraction that is going to be implemented for specific platforms can be helpful and more towards the feature of 1.5.x libraries. Still quite annoyed by the fact that libraries have to be installed via the arduino IDE. to be honest the IDE should be integrated with git to pull libraries straight from there into proper locations.

Anyway .. the point is that if we agree on such a more object oriented design with a good eye on SOLID principles it would make life a lot easier for adopters. Specially people like me with not so great experience in low level programming co close to the metal. What do you guys think ? Should we think of moving towards a new release and put in place all this great suggestions and also the new library layout thing? (will it work with current IDE?)

Agree with you guys, totally.

Just can we avoid having DUE in the name and maybe use it as part of namespace naming?

Are you familiar with Git-Flow? I am using SourceTree as client for GIT repositories and it supports git-flow, sounds quite a great process to handle releases/patching steps

[pklaus]

@colombod You can also edit your comments. So just to add one more sentence, you don't need to post a new one. 😄 It's the first time I hear about the SOLID principles :) I'm using the command line git plus the SourceTree.app. I don't really get the difference / advantage of Git-Flow though.

@ivanseidel Sure, we can close this pull request now and work on the development branch for the upcoming release (I would use v2.0 as a tag, not as a branch). We should open a new issue to discuss the design for the upcoming release though: the milestone definition can only be changed by you, ivanseidel. For instance, I would recommend to not use the Github Wiki as I prefer to either have a gh-pages branch with its own HTML documentation (see Github Pages) or keeping the documentation directly in the library folder (in the folder extras for 1.5.x libraries as proposed here). The Github Wikis are sometimes not visible enough to be found by the end users.

[ivanseidel]

I have opened a new Issue to discuss about this.

I'm closing this pull. This will be used on the new version, but as a new Class to keep organized.