This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/TM4C1294NCPDT: Clock tick period setting

Part Number: TM4C1294NCPDT

Tool/software: TI-RTOS

Hi,

I am using TIRTOS 2.16.0.14.

I need  a system timer with a resolution of 1us or finer. I set clock tick period as 1us in the configuration file and  the clock construct is done as shown below.

Clock_Params clkParams;

Clock_Params_init(&clkParams);

clkParams.period = 1000;

clkParams.startFlag = TRUE;

/* Construct a periodic Clock Instance with period = 1 system time units */

Clock_construct(&clkStruct, (Clock_FuncPtr)clkFxn, 1, &clkParams);

While I set 1 for the clock tick period inside configuration file, the code is not executing properly. When I set 10, it worked. I tried by changing clkParams.period also. What may be the reason for this issue?

Please help to solve this.

Regards

Sandra

  • A 1uS tick interrupt in an RTOS is going to take a very large percentage of the micro. Usually the default tick for the RTOS timer is 10mS. I would not be surprised if the overhead was consuming all of your processor time.

    So why do you need 1uS resolution?

    • If you are just measuring time there are other easier ways to do it.
    • If there is a periodic event, then perhaps using a timer to trigger the event directly w/o the overhead of the RTOS system timer would be better.

    1 uS is not very much time, you have to keep your task small and focused.

    Robert

  • Hi Sandra,

    In addition to Roberts fine input;

    Are you aware adding clock module into RTOS configuration file allows SWI module to execute semaphores?
  • So good to see "Poster's unexplained/unjustified desires" - receive "PC approved - light yet detailed" (i.e. proper) challenge.

    As posters land here, "Not knowing the answer" - can it be SO wrong to request that they (somewhat) justify their "desires" - especially when those desires - stray (so far) from "normal/customary."    (i.e. 1µS - via RTOS - proves a "very bad" idea - even worse - its "alleged need" is, "Nowhere presented!"

  • I desire Arby's large mocha shake with smoked brisket sandwich topped with crispy onions. The odds of that occurring today are 1 in a million unless drive through speaker is listening before bed time.
  • That's, "Gotten me hungry!"

    Might we "top that sandwich" w/several of your "decomposing FETs" ... (rescued) from your (barren - to be kind) "rear yard"/FET/asbestos burial ground...

    (My tooth implant has (almost) stopped glowing - after partaking of your past "back-yard seasoned" - food offerings... ... Still working on that Twitch/Tic!)

  • I highly recommend you don't set the Clock period to 1uS. On each clock tick, the kernel does house management (e.g. determines if any threads need to be made ready, see if any Clock functions are scheduled to be called, etc.). It does most of this processing in a Swi. So the Hwi runs, posts a Swi and the house management occurs.

    If you want something with a uS granularity you should use a dedicated timer for it and leave the kernel's timer at the default (1mS).

    And...no comment on Arby's but a shake does sound tasty.

    Todd

  • ToddMullanix said:
    a shake does sound tasty.

    Nice to see vendor staff in "full & complete agreement" w/"outsider swarm."     (how rare that?)

    Might it be (still) noted that, "Posters coming to "conclusion" (i.e. 1µS clock) - minus ANY justification for such - "escapes vendor comment!"     By such avoidance - is not "tacit approval" bestowed?

    As to your "tasty shake" - if provided by BP - fear not the metal (believe they're lead) bits - you may chew (carefully) around them.     The "feeling" w/in your tongue & lips - and sense of taste - (my experience now) - usually returns w/in several weeks...     Drink up!    (but "only" at intervals - far in excess - of poster's (unjustified) 1µS!)

  • Hi Todd,

    My task needs to sleep in increments of 1uS or finer. so that other tasks/application continue to use the cpu. 

    how can I achieve this. do you have any example project?

    Regards

    Bala

  • Bala, Todd's point and mine were that the overhead of the RTOS clock makes this infeasible. I would, in fact, be cautious about making the RTOS clock tick faster than 1mS (and 10mS would be better).

    What are you trying to do that requires 1uS precision?

    It borders on fantastical that everything in your project requires that. If we have an idea of what you are attempting we can suggest alternate approaches. I'm sure many here have built systems that required some uS response times (or lower), I doubt any have used an RTOS with a 1uS clock (it's possible they have but maybe on a more powerful system)

    Robert

  • *** LIKE ***

    Again - as so often arrives here - poster "choice & judgement" (never/ever justified) proves "off-mark" and delaying - may in fact OFTEN CAUSE their "reported issue." Some "justification" of poster choice/desire should be requested - and enforced by esteemed forum agents...
  • Hi Robert,

    my application needs to get the timestamp in increment of 1 uS and also need to start/stop my application task execution in microseconds.

    Right now I am using Clock_getTicks() for timestamp and Task_sleep() for suspend my application for an while.

    but both of this API uses the Clock ticks configured in .cfg file which is right now set default one i.e. 1000 uS. so I am getting the time in terms of 1mS.

    If RTOS tick cannot be used, what is the alternate to fulfil my requirement. currently my system is running in 120MHz.

    Regards
    Bala
  • Balasubramani C said:
    my application needs to get the timestamp in increment of 1 uS

    This part is easy, you just need a free running timer with resolution of 1uS or better, you have a large number of timers on the processor to make use of for that purpose.

    Balasubramani C said:
    also need to start/stop my application task execution in microseconds.

    You need to provide some additional information.

    Starting a task to within a uS might be doable, it depends on what else is being done in the system. Long interrupts will prevent you from doing this. Remember at 120MHz you only have 120 instructions within 1uS and you have to finish up anything that may delay the response before you can start your task.

    This kind of timing would normally be the result of an interrupt. From an interrupt you can either perform the task directly or set a semaphore to start up the task in the RTOS. Which is preferable depends more detail than you have provided. IE is your task periodic, how long does your task take to complete, what other tasks are present (and what is their frequency?).

    This cannot be done ad-hoc.

    Robert

  • "at 120MHz you only have 120 instructions within 1uS" ... what was meant was 120 system clocks w/in that 1µS.
    Indeed - the "case" for such need has been "far from made" - and experience teaches - most always is non-existent...
  • cb1_mobile said:
    "at 120MHz you only have 120 instructions within 1uS" ... what was meant was 120 system clocks w/in that 1µS.

    Umm, what he said.

    For some reason I was thinking this was a single cycle/instruction machine (barring stalls due to branches and interrupts), It's good but not quite that good.

    cb1_mobile said:
    Indeed - the "case" for such need has been "far from made" - and experience teaches - most always is non-existent...

    And that it should (all) be done in SW.

    At least we've progressed from everything must be timed to the uS to (I hope) one task must be.

    Robert