Yeah, this is pretty far from mspgcc, but still on topic for MSP430.
There are three timer read solutions I use in BSP430, depending on the
relative speed of the clocks:
* If the clock source is synchronous to mclk, just read the counter.
* If it's asynchronous and is significantly slower, read the counter
repeatedly until two consecutive values are equal.
* If it's asynchronous and is about the same speed or faster than MCLK
dedicate a capture/compare register configured to capture both edges and
keep CCIS1 set, then toggle CCIS0 in the CCTL register to latch the counter
value.
There's an amusing little gotcha in that last one: if the timer clock is
slower than MCLK and you have SCS set, the captured count might not be
correct (SCS delays the capture until the next falling edge of the timer
clock).
Take into account that sometimes you need to also record the CCTL value and
know that it's consistent with the CCR value you select. For example,
when trying to produce a 32-bit counter value you need to know whether an
overflow has been recorded. My belief in the case of the
two-consecutive-reads-that-match solution is that the CCTL value between
the two reads will be correct; unfortunately the MSP430 user's guides don't
give enough detail on exactly how the clock updates are done to guarantee
that.
And be careful about reading CCR from within an interrupt handler triggered
by CCIFG, because if you use the IV interface the value you read might not
be the one that triggered the interrupt (clearing CCIFG enables an
overwrite of the captured value that would otherwise be signalled by the
COV bit).
http://pabigot.github.io/bsp430/timer_8h.html#h_periph_timer_hpl has some
additional details. examples/platform/trxeb/timer_scs_test/main.c and
examples/misc/syncap/main.c both demonstrate some of the edge cases of
timer capture.
On Thu, Sep 19, 2013 at 3:08 PM, William Swanson <swanson...@gmail.com>wrote:
> On Thu, Sep 19, 2013 at 12:44 PM, Jesse Frey <jmf...@alaska.edu> wrote:
> > When I need to read a timer asynchronously do three consecutive reads
> and do
> > a bitwize majority function on them.
>
> Not to take this thread too far off-topic, but that approach doesn't
> work. For example, say your middle reading happens to catch the timer
> just as it is rolling over from 0xffff to 0x0000. Your three readings
> would then be:
>
> 0xffff
> 0xff00 /* meta-stable transition state */
> 0x0000
>
> Your bit-wise majority function would return 0xff00, which is still
> wrong. Since the whole point of taking multiple readings is to avoid
> these meta-stable transition states, a bit-wise majority isn't good
> enough. You need to compare whole values until you see two that match.
>
> -William
>
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
