Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
11 years, 4 months ago.
Why are counters as a peripheral avoided?
I would like to get access to the hardware counters of mbed-1768. I want a way to use them to manipulate pins directly, not as a result of a counter/timer software interrupt. A counter switches accurately at the programmed clock cycle, but a timer always has some software adjustment in it because it has to be programmed in us or ms.
All kinds of peripherals are defined in the peripherals.h, but not counters. Is that still in the mbed team's pipe line, or will it never come? It would be nice to select some configurations as WGM-modes like it is done wih AVR's.
Is it the only possible / easiest way / that I just have to access the reigisters directly? Like it is done here: http://mbed.org/users/Yo_Robot/notebook/how-to-generate-a-pulse-train-output/ (meaning I have to dig all the register names and their uses out of the handbook)
I did find this, but it is not for LPC1768, I think, because of #include <LPC11Uxx.h>: http://mbed.org/users/mbed_official/code/mbed/docs/a076018f59af/structLPC__CTxxBx__Type.html
2 Answers
11 years, 4 months ago.
No, we are not planning to add a counter specific API.
The mbed API should remain target independent. The most target independent usage of counters is for timing and PWM, hence the mbed library provides a timing and PWM API independently of the target counter implementation.
We'd love to be proved wrong. If someone in the mbed community is going to provide a target independent API for counters that can solve use cases not covered by our timing and PWM API we would consider including it.
Of course, independently of the mbed API you can target every specific resource of your specific target through the CMSIS-CORE API for your target:
Cheers, Emilio
11 years, 4 months ago.
I can understand that there is a conflict. Now the computer (mbed-software) is in control of the peripherals.
But to use the mbed-software as a slave of its hardware counter is a very honourable role I think. There is a good reason that these things are combined in a microcontroller.
I think the mbed system needs a way to combine these 2 (opposite) rolls.
What would I need it for? I have studied the idea for a direct stepper driven plotter, just a table and an arm like in a record player. Many years ago Elektor had this as project Tanbo. It is possible to plot lines and circles at constant speed with that. But then I need the counter as "ruler" with markers on it where to put each step. The "ruler" is clocked. The marker is the Capture contents that is directly coupled to a pin. After each step I calculate the next marker on the "ruler"; this calculation may involve severe math, for which the mbed is well equipped: better then an AVR for which I have worked out the idea. The counter driven approach guarantees that each stepper motor gets its step pulse exactly on the right time, if I want the plotter pen to move at a constant speed. This way I can linearize all kinds of non-linear motion systems. I can get rid of expensive linear guides, and get the freedom of rotating links. These are mechanically much simpler and easier to make free of clearance. It is also possible to connect a second counter and configure that in a way that it gives perfect linear acceleration/decelleration. This hardware can reliably model the mass movement of a giant bridge or a train. I would not trust easily the mbed timer for that...