How to configure 16-bit, free-running, 1 MHz timer/counter ?

I mean I want the timer to run at 1MHz.  That means it will roll over every 65536 uS.  The system clock is 80 MHz...

I'm not using Tivaware.  Registers please.

Sorry I asked.  I should have known this would devolve into a debate about coding methods.  I am trying to understand these peripherals; plugging into an API does not achieve that.  I do use some Tivaware for initialization and testing.  For those times I created a file of alias function names that actually look like C.  The only thing uglier than camel-case everywhere is Hungarian notation prefixed to camel-case everywhere.

The reason I don't just use a 32-bit, 80MHz counter is that I want a 1 MHz counter and 16 bits is plenty.

I would also add that I find Tivaware to be poorly planned and poorly executed.  The level of abstraction makes no sense and only serves to hide the peripherals behind a maze of function calls.   The idea of a single binary library for all targets is moronic and just asking for trouble.

Some may consider this series of (unwarranted) attacks upon vendor & its API, "bit much."

Perhaps a better use of that "venom" would be to solve the issue at hand - and (just maybe) direct venom at, "self-shortcomings."

Clark Leach said:

Perhaps I should rethink the methodology before my code base that uses it grows much more. Perhaps, having the "driver" return 'elapsed_uS' when passed the 'init_value' (which was returned by the 'counter_start' function).... that would work.

That's a way to approach it. Particularly if it has to work on multiple platforms. Just think of the TivaWare interface as a simplified register interface.

Here's what I'm using. First the init

    	/* Enable wide timer 0 to give use two 32 bit timers to act as our base 
	    clocks. */
    SysCtlPeripheralEnable(SYSCTL_PERIPH_WTIMER0);
    	/* Make sure peripherals are turned on before proceeding further */
    while(!(SysCtlPeripheralReady(SYSCTL_PERIPH_WTIMER0))){
         }
    
    	/* Set WTimer 0 B as a wrap around free running timer.  We will use this
    	   as our hardware clock. 
	   WTimer 0 A as a wrap aound 1mS timer.  This is our time base for
	   I/O updates.    */ 
    TimerConfigure(WTIMER0_BASE, TIMER_CFG_SPLIT_PAIR | TIMER_CFG_B_PERIODIC | 
    	TIMER_CFG_A_PERIODIC);
    TimerLoadSet(WTIMER0_BASE, TIMER_B, UINT32_MAX);
    TimerLoadSet(WTIMER0_BASE, TIMER_A, (SysCtlClockGet()*1u)/1000u);
    	/* Set up timer interrupt on peripheral and NVIC */
    TimerIntEnable(WTIMER0_BASE, TIMER_TIMA_TIMEOUT);

Second some related defines

typedef uint32_t TIME_CPU;	/* Fine grained time type. */
				
/*** TIMESTAMP - Get fine grained time. 
 *
 * Used when higher resolution is required or when multiple independent time 
 * sources need to be kept in sync.
 * 
 * NOTE!: The timer is a countdown timer.  
 ***/
#define TIMESTAMP()	((TIME_CPU)TimerValueGet(WTIMER0_BASE,TIMER_B))

	/* Convert from mS to Fine grained time. 53mS max*/
	/* ToDo: Make so lint can check argument */ 
#define MS_TO_TIME_CPU(x)	((TIME_CPU)((SysCtlClockGet()*(x))/1000u)) 

Note that to get a uS resolution timestamp just needs (I haven't tested or linted this, typos and logic errors may be present)

/* No round off as long as the clock speed is a multiple of 1MHz */
#define CPU_CLK_PER_US ((TIME_CPU)(SysCtlClockGet()/100000u))

#define TIMESTAMP_US() (TIMESTAMP()/(CPU_CLK_PER_US))

    /* Order of subtraction reversed to account for countdown. Note do not use TIMESTAMP_US to avoid any possibility of wrap around issues. This also
     * reduces round off errors in the event that the clock is not a 1MHz multiple. */
#define ELPASED_TIMESTAMP_US(first, last) ((((first)-(last))/(CPU_CLK_PER_US))

/* Alternate version of TIMESTAMP_US that wraps on a 16 bit boundary */
#define TIMESTAMP_US_16b() ((TIMESTAMP()/(CPU_CLK_PER_US)) & 0xFFFFu)

Note if performance is a consideration the SysCtlClockGet can be replaced with a constant. With a little bit of work I think you could also reverse the time stamp result so it appeared to be counting up. I've never found that it mattered.

Robert

I'm an outsider too - sometimes use Register Level (DRM) yet am firmly against such usage when it fails - and then posters land here - and cry for help.

Users surely have the right to employ their method of choice and operate w/in their comfort level.  

Yet - does not the forum staff (and out-board helpers) have rights as well - and central in that is the strong push toward the API?   You wrote (harshly & inaccurately I believe) that some are "summarily told to use the API" - and that's untrue.  Almost always - vendor staff & we outsiders - (avoid) the curse of your (summarily) by identifying these overwhelming advantages of the API:

• API is long tried/true/tested by thousands (perhaps tens of thousands)
• API is broken into easily viewed & disciplined "Peripheral Groupings"
• API includes hundreds of well commented & effective, known-good, working examples
• API source code (almost uniquely) is presented (warts & all) so that users - if they desire - may gain insight or "tweak" to their satisfaction
• API is far easier & quicker for (both) vendor staff & outsiders to read, comprehend & troubleshoot

And - often - if the switch to API is rejected and time, effort, & comprehension allows - the Register Methods ARE employed.   ("summarily" proves a gross over-statement (bashing) then - does it not?)

Thus - from an MCU forum perspective - can there be any doubt that forum's central role is to benefit the many (via the mature API) - rather than the few (those expert enough to employ registers - yet not expert enough to succeed!)

Both Register-Favoring (demanding?) posters here appear very new to this forum - I'd suspect that w/time they'd come to a far better appreciation of the value, time-savings & safe-guards which the, "time-tested, known good" API provides!

Mes Amis, (Robert et Amit)

Descending into "fine detail" is NOT required.

Both Register favoring posters have failed in their Register efforts. Landed here - insist on help - yet (only) on their (narrow) terms.

Now - if the earth (or forum) tilted upon its axis - and DRM was to predominate - just (how soon) could each/every (register only) [failing poster] be accommodated? The ability to answer properly & quickly (both wonderfully handled under the API) would instantly be destroyed!

And this "tilt" is necessitated to satisfy (little more) than the "whims" of those seeking, "personal preference" over a far superior, long-proven, API. That is a clear statement of reality - indisputable!
 
Had either of our register experts been versed in business - or history - they'd have noted that "LMI" - originator of these MCUs - noted the "stellar" role which the API played in driving this present vendor to its ARM MCU acquisition! (excessive time/effort - spent in "register hunt/searching" - is (well) known for negatively impacting (other) vital investigatory areas...)

Hello Clark,

Absolutely. It is a forum to ask question for TM4C Hardware and Software.

While you have rejected TivaWare outright, you have also not considered using TivaWare to extract the DRM approach as suggested earlier. We could have got both to co-exist. Why we do not recommend DRM is

1. As the code size grows, it makes it difficult to maintain it and debug it (especially for the next person in the chain)

2. If there is an issue, we would be slightly more inclined to the fact that while there is no errata on the module being used, that could have caused it not to work, it must be a software issue rising from an improperly coded DRM access.

Regards

Amit

My friend - you (do) tend to vast over-statement - do you not?

First you use the word summarily - and then (shrink) from its defense.   And now you (exaggerate [again]) by grossly misquoting, "Just use the bloody API!"   Those words are yours - and yours alone - never/ever thought or uttered here.

Is this not proof positive that your arguments are (so) empty that you must resort to "over-statement" and clear "misrepresentation" - to make your (flawed) point?

We note that you "duck & cover" to (evade) the extra time/effort and expanded response time which your (desired) "Register Only" response demands.   You mention the ST forum - I'm active there too - and note the (absence) of vendor staff - which you fail to note...   In stark contrast - this forum is superbly attended - and proper care/consideration must be paid to forum staff.   (vendor's Amit is beyond excellent - & poster Robert provided a very full sample program - only the "most" self-centered would "protest.")

No one seeks to "deny your programming pleasure" or NY Times x-word challenge - enjoy them.

The attitude here - if there is one - is to guard & protect the excellent standards w/in this forum - and much credit is due to the powerful API.  

The initial poster - then you - landing w/in his, "my way or high-way" foot-prints - seek to draw the forum into your highly personal preference - which (unduly) taxes forum staff and we (few) outsiders.   

We responding have advised that the API (rather uniquely) includes the full source code - you can examine register usage (and sequencing) to your heart's content - and on YOUR OWN TIME/EFFORT!

Both "Register & Only register" posters have been here ~20 minutes - is that time sufficient to (hack) the forum from its long & successful path?   I very much doubt that.    Personal preference must bow to, "Greatest Good!"    And both "Register ONLY" seeking posters clearly KNOW that!

Hello Jerry,

I could have agreed with the Analogy, only and only if TivaWare was going to be released tomorrow.

I cannot comment on STM and NXP forums. May be they would prefer users to go through DRM and not improve on their software delivery, Again I cannot comment on why STM and NXP do what they do. There are reasons why we would like to avoid DRM and my last post has given the 2 reasons why. I believe you made the second one in your quest sir.

EDIT: And what good is a forum if no one responds or suggest within reasonable bound of a debate an alternative with clear reasons. No one responded harshly to anyone and if they would, moderators respond or the poster can raise it up in a concerned forum/ or to TI.

Regards
Amit