getting a time reference for use in timestamping

Tim Coddington said:

need to capture a timestamp - relative timing of data - sub mS - and not a Timer! 

Pardon - but, "walks like, looks like, quacks like - but is "not" - employs same tortured logic displayed here in "defending" M3 demise. (NRND)   Of course you should use a Timer - that is their purpose/raison d'etre...

As Timers abound w/in most any M4 Cortex - very hard to "fathom" your quest for, "something more readily available!"   Say what? 

These Stellaris Timers may be clocked at System Clock rate (50MHz is safe speed) - which can resolve to a phenomenal 20nS.  Counting 50 such clocks yields 1uS, 500 yields a very usable 10uS - without unduly taxing the MCU.  Timer may generate an interrupt upon time-out - you may store this as a running count - and decode "after the fact" for analysis.  Timers may be read in sync with internal or external "event" - and that value may be stored as well.

If there really exists some justice for "timer avoidance" ARM/Stellaris provides a "simpler, scaled down version called SysTickTimer.  This is a 24 bit Timer - which again may be monitored and recorded - and used for your desired timestamp capture. 

Both MCU data manuals and SW-DRL-UGxxxx provide great detail re: care/handling/set-up of the various Timers & SysTick.  And StellarisWare\Examples provides decent, pre-coded routines to speed/simplify.

Appears that sometimes - a "Timer" (or a Duck) simply "jumps out" as, "ideally fit for purpose..."

I always add an external RTC as well to my sensor projects -- but typically for many sensor projects you have both RTC and Systick running -- so I capture both -- unless RTC has sub millisecond ability. 

You are the designer so this is really your choice. How fine a timing do you really need? That is a high level design question -- not a low level technical questions. I always map out what is necessary to give the desired results -- and a reserve in case we find that we need "deeper" results.

Of course you should have some justification for the timing -- like event re-construction as I do -- or your are just burning cycles for amusement -- not that I don;t do that occasionally too.

You can also use the internal timers to generate a clock. Look at the TI RTOS examples -- "BigTime" etc for a clock implementation -- not sure if that runs on Linux though.

Not sure if that helps -- but it's the way I approach this issue.

I should add that I capture the systick style events through the millisecond or the microsecond count function. So you have to implement this somehow.

I hope you feel better after this sorry display of ignorance and rudeness.  You totally misinterpreted my statement regarding "something more readily available.  I doubt explaining will clear anything up for you.  Fortunately, there were other who were more considerate.  If you are not going to be helpful you shouldn't reply.  

Dave R, thanks. 

I was hoping the answer might be an available TI/Stellaris library function, which is what I meant by "more readily available".  Apparently not and so your input will be helpful.

I often use the SysTick interrupt routine to keep a count of milliseconds / seconds. For something quick, take a look at the udma_demo for the LM4F120 - you could set the SYSTICKS_PER_SECOND to 1000 and the the ulTickCount would be directly in milliseconds. The SysTick interrupt needs to be properly setup for this to work, you'll need to also have the SysTickHandler listed in the appropriate startup_xxx.c.  

Also, take a look at utils/ustdlib.c -- there are some functions like ulocaltime, umktime - if you need to convert between seconds and dates.

For your MPU-9150 IMU - have you seen the code for the MPU-6050 IMU on the LM4F using Energia (Arduino like IDE)?

LM4F_mpu6050_library

launchpad_stellaris_energia

I purchased an 11DOF IMU that has a MPU-6050, but haven't had time yet to start talking to it with a Luminary.  I'd be curious to hear how you make out with the Launchpad + MPU-9150.

Good Luck.

Tim:

Please note the top posters on the forum and the point score. That tells you how many times they have at least tried to help... whether successful or not.

I hope you feel better after this sorry display of ignorance and rudeness.

I really don't see how you could interpret CB1 as you did. I was shocked at your response quite frankly. He supplied all the information you needed. I am surprised you did not see that. Now pull out your Stellarisware driver guide and verify that. My suggestions were a weaker alternate.

Also it may be worth your while to find your way to the launchpad course and follow the lessons if you have not done so.

Now if the above statement raises your ire due to your expertise note that I have been designing processors since the late 60s and was not the least bit embarrassed to follow several of the excellent course provided by TI. I suspect that the lessons would answer most of your remaining questions. They got me up to speed within a week.

CB1,

   I apologize for taking your repartee the wrong way.  I will try to be more careful next time and I will also consider your suggestions more seriously.  Thanks

Apology not required - sense of myself/others was that "heat of battle" + "your possible bad day" caused  over-reaction.  (you may consider better "calibrating" future attacks - to the magnitude of perceived offense...)

Should note that initial post provided (perhaps) extraneous detail - which contrasted sharply with the imprecise presentation of your quest. 

"More readily available than using a timer"  I really did interpret your goal as, "Timer Avoidance" - which I believed mistaken - and "gently chided."  BTW - law school teaches that rudeness is minimized/bypassed thru use of "Pardon" or by framing a statement as a question.

Special thanks (relayed earlier/elsewhere) to D. Robinson for his kindness in my behalf.  Providing fast/free/detailed tech-support - not always w/out pain/sacrifice.  Fortunately key others appreciate - and repeatedly demonstrate their satisfaction...

I continue in the belief that my answering post contained very much what you "needed" - and that most all follow-on posts proved derivative...

Rick Nardone said:

The LM4F microcontroller has a Hibernate Module

Is this really the case?   Our group has long had an LX4F (64 pin QFP) and - as best we can tell - does not include the hibernate peripheral and/or attachment.  We deliberately chose the device as we needed the maximum peripheral mix - and did not desire nor target "hibernate."

Perhaps only a subset of LX4F include - rather than all...

Hi cb1,

   Yes you are correct, it is an option on the LM4F family. 

    Best,

            Rick

Rick N,

   Just what I was looking for--thanks!    I had been through most of the workshop but stop short of Hibernation Module with plans to get to it later.  I didn't catch on that it had an RTC.  Thanks for pointing this out.  The Stellaris Launchpad lm4f120 is turning out to be a very good choice for my experiments.

Everyone has been very helpful.