Timer "Input Capture" ?

Post here first, or if you can't find a relevant section!
racemaniac
Posts: 696
Joined: Sat Nov 07, 2015 9:09 am

Re: Timer "Input Capture" ?

Post by racemaniac » Thu Apr 21, 2016 2:54 pm

martinayotte wrote:All those directories structure is coming from the legacy code of LeafLab, they are not even consistent between STM32F1 and STM32F4, but we need to live with it.
Is that one of the reasons why there are people trying to create a new core to replace the libmaple core, so we can get rid of this legacy code?

User avatar
martinayotte
Posts: 1241
Joined: Mon Apr 27, 2015 1:45 pm

Re: Timer "Input Capture" ?

Post by martinayotte » Thu Apr 21, 2016 3:05 pm

The task is too huge for the moment, so nobody wish to brake existing hierarchy.
There also tons of sub-tasks we wished, such as putting much common code between platforms together, but again those are huge too.
Refactoring has always been difficult on any projects, especially when "time is the missing ingredient" ... :?

racemaniac
Posts: 696
Joined: Sat Nov 07, 2015 9:09 am

Re: Timer "Input Capture" ?

Post by racemaniac » Thu Apr 21, 2016 3:16 pm

martinayotte wrote:The task is too huge for the moment, so nobody wish to brake existing hierarchy.
There also tons of sub-tasks we wished, such as putting much common code between platforms together, but again those are huge too.
Refactoring has always been difficult on any projects, especially when "time is the missing ingredient" ... :?
As in all big projects, try to get there with small steps whenever you have some time ^^'.
With my recent projects i've been digging into the core, and i'm starting to get familiar with how the microcontroller works :). If i had a better view on what's currently needed in core development, it would be nice to be able to help out :).

Cesco
Posts: 26
Joined: Mon Apr 18, 2016 3:34 pm

Re: Timer "Input Capture" ?

Post by Cesco » Fri Apr 22, 2016 3:40 am

What i did (or what i can remember):

timer.c in STM32F1\system\libmaple\include\libmaple timer_set_mode()

Code: Select all

    case TIMER_INPUT_CAPTURE:
        input_capture_mode(dev, channel);
        break;
utilities, after output_compare_mode()

Code: Select all

static void input_capture_mode(timer_dev *dev, uint8 channel) {
    timer_oc_set_mode(dev, channel, 0, TIMER_CCMR_CCS_INPUT_TI1);
    timer_cc_enable(dev, channel);
}
Test

Code: Select all

void init_rx() 
{  
  pinMode(RX1, INPUT);
  
  Timer2.setPrescaleFactor(72); 

  Timer2.setMode(TIMER_CH1, TIMER_INPUT_CAPTURE);
  
  //TIMER2->regs.gen->CCMR1 = 0b010000001;
  //TIMER2->regs.gen->CCMR2 = 0b000000000;
  //TIMER2->regs.gen->CCER  = 0b000000001;
  
  Timer2.attachCompare1Interrupt(ppm_input);
}
A rename of attachCompare1Interrupt() into attachCapture1Interrupt would be nice but not necessary.
Note TIMER_CCMR_CCS_INPUT_TI1 should be correct for chan2,3,4 too. It means no cross-channel connection.
I may have enabled TIMER_INPUT_CAPTURE in timer.h as well, cant remember.

Missing: rewrite of timer_cc_enable() to allow polarity change

User avatar
RogerClark
Posts: 7683
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Timer "Input Capture" ?

Post by RogerClark » Fri Apr 22, 2016 7:06 am

Can you zip your files and attach them?

In the mean time I'm going to try to add the code you posted, but I don't think its complete

Edit

I looked at the code for

attachCompare1Interrupt(ppm_input);

and this function is deprecated.

HardwareTimer.h reads

Code: Select all

    /** @brief Deprecated; use attachInterrupt(TIMER_CH1, handler) instead. */
    void attachCompare1Interrupt(voidFuncPtr handler) {
        attachInterrupt(TIMER_CH1, handler);
    }
Edit.

Can you also post the code for how you are reading the ppm value from the timer in the callback

Do you just read

TIMER2->regs.gen->CNT ???


(Yes I could figure it out myself, but its quicker if I can just look at your code) ;-)

Thanks

Cesco
Posts: 26
Joined: Mon Apr 18, 2016 3:34 pm

Re: Timer "Input Capture" ?

Post by Cesco » Fri Apr 22, 2016 11:44 am

Reading inside interrupt handler:

Code: Select all

uint16_t act = TIMER2->regs.gen->CCR1;
Attaching interrupt handler (non deprecated)

Code: Select all

Timer2.attachInterrupt(TIMER_CH2, ppm_input);
I did realize "timer_cc_enable(dev, channel);" is not good. It doesent allow to set capture polarity / filter / prescaler. At lest the polarity should be settable. I will try to solve this and then zip the files.

User avatar
mrburnette
Posts: 2201
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Timer "Input Capture" ?

Post by mrburnette » Fri Apr 22, 2016 1:00 pm

racemaniac wrote: <...>
As in all big projects, try to get there with small steps whenever you have some time ^^'.
<...>

Respectfully, that is how we got to where we are ... baby steps. Much has been learned about how hardware, core files, libraries, and user sketch. Now, that Arduino IDE is a big player in the educational and hobby market, everyone wants to rework stuff. The problem is as it has been in the past - numerous distributed coders working toward a goal. STM and other companies take a different approach when they develop: it becomes a systems' approach to developing the abstraction layer(s) so that the hardware is handled most efficiently; this approach yields a set of components and libraries that are more akin to an OS: hardware drivers and higher-level API implementations.

The use of the term API in regard to Arduino products, is an oxymoron; there really is not a consistent API, rather there are object instantiation and passed variables/structures. To try and bring something like the STM methodology back to the Arduino implementation is extraordinary complex. Personally, while I applaud the results so far, progress is very slow and is more, I feel, about self-learning than product creation - more in the F4 area I would suggest.

What is needed if such an effort is successful with multiple coders is an architectural design, an implementation strategy, a cohesive and similar-mindset team with touchstone goals, regular and often communication, critical inspection of all software products in a peer review, and basic overall project management. This would be a huge effort for a fringe team such as the STM32duino group. The fact that we do not have a representative in the IDE development area is a huge disadvantage from an architectural prospective.

Of course, like Leaflabs, a small team of just a few brilliant software engineers could turn out a product significantly more quickly and with higher quality - but even Leaflabs had to put a stake in the ever-flowing IDE by taking a snapshot of the Arduino version and creating a static IDE of their own.

Coding is second to having an architecturally correct design and the two must be woven carefully to avoid holes in the fabric. Holes in the fabric let bits drop out which creates a really nasty mess to clean-up :D

Ray

User avatar
RogerClark
Posts: 7683
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Timer "Input Capture" ?

Post by RogerClark » Fri Apr 22, 2016 10:03 pm

Hi Ray

The more I look at the HALMX core, the more I appreciate what leaflabs managed to do with libmaple.

Libmaple now looks nimble compared with the vast array of files that are needed to support multiple boards in the HALMX.

Libmaple's USB Serial seems to take 8k but STMs version appears to take 20k ( of flash ).


But there is nothing to stop us improving, adding to, bug fixing and tidying up libmaple, while at the same time, people can work on HALMX if they want to.


Complaining about libmaple not using the CMSIS etc, seems to be a common sport, but I see hardly anyone doing anything to build anything better (@sheepdoll and @vassilis accepted)

User avatar
mrburnette
Posts: 2201
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Timer "Input Capture" ?

Post by mrburnette » Fri Apr 22, 2016 10:41 pm

RogerClark wrote: <...>
The more I look at the HALMX core, the more I appreciate what leaflabs managed to do with libmaple. Libmaple now looks nimble compared with the vast array of files that are needed to support multiple boards in the HALMX. Libmaple's USB Serial seems to take 8k but STMs version appears to take 20k ( of flash ). But there is nothing to stop us improving, adding to, bug fixing and tidying up libmaple, while at the same time, people can work on HALMX if they want to. Complaining about libmaple not using the CMSIS etc, seems to be a common sport, but I see hardly anyone doing anything to build anything better (@sheepdoll and @vassilis accepted)
Linus Torvalds took a monolithic architectural approach to Linux even as he took an OS architectural class that discredited such implementation. Architectural deficient, Linux is quiet successful.

One (me anyway because I am a cynic) has to wonder if the latest & greatest support implementation by the silicon designers is not driving simple implementations to a higher tier of silicon - and at a higher per chip cost and more profit for the sand peddlers.

IMO, there is nothing wrong with "core library" implementations. The approach has made Arduino famous by providing remarkable usability for a uC with just 2K of SRAM and 32K of flash - the Atmega328P. Useful, cheap, powerful, and still in widespread use. (And, yes, I know Arduino was implemented on the 328 predecessor, but IMO, the 328P made Arduino successful.)

The core approroach breaks IMO when the uC grows to have more complex design and more peripherial capability. It is a rare programmer that is competent is every single aspect of coding (those who are are in great demand and likely have no spare cycles for doing free open source efforts.) So the larger open source efforts become divided among a group and keeping such an effort on track is a real challenge.

I applaud those working on evolving the STM32F4 port... be inovative and bring into your effort the best of whatever is currently open source. But, the F1 is a bit long in the tooth and backporting the F4 code' may prove to have little return on the time investment. If the F4 effort can derrive a subset for F1 support that can be simultaneously supported - that would be valuable, IMO. Such effort could flush existing bugs and could knit uniform DMA support, etc. But I believe such a balancing act will be more complicated (than a pure F4 effort.)

Ray

alexandros
Posts: 75
Joined: Mon Oct 02, 2017 6:51 pm

Re: Timer "Input Capture" ?

Post by alexandros » Thu Jan 18, 2018 2:52 pm

sorry guys is that TIMER_INPUT_CAPTURE , avalable in the library ?
i want to use Input capture method , instead of AttachInterrupt i read that is faster MCU/2 speed.

Post Reply