• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 1863 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28069: atomic operations

evs
Genius 5910 points

Part Number: TMS320F28069

I have a ringbuffer that can be filled by main code and interrupts code. (interrupts can also be interrupt by other more imported interrupt).   Correct interrupt handling is real important!

To solve this I need a atomic operations  for my ringbuffer.

 index=buffer.next=(buffer.next +1) % 16;

So I can reserve a location(index) to fillup in my ringbuffer.

What is the best way to do this?

Thanks!

 EVS

  • 0
    Genius 5910 points
    To bad, no response.


    Is this a possible?

    _asm(" setc INTM")
    index=buffer.next=(buffer.next +1) % 16;
    _asm(" clrc INTM")

    How interrupt save is this? is it possible to lose interrupt in this way?
    Thanks
  • 0 in reply to evs
    Genius 3050 points

    Hello, evs

    Sometimes we use DINT/EINT for short atomic operations as you suggest. DINT and EINT are macrodefinitions for "_asm("setc INTM")" and "_asm("clrc INTM")".

    In this case you don't lose your interrupts, but they can be delayed, if an interrupt flag is set while "DINT" is present. The latency depends on duration of operations inside DINT ... EINT. In your case it is few cycles. Not scary.

    Also i suggest you to change "%16" operation to "&15" operation (bitwise AND). They have same effect in your case, but "&" operator will be faster.

    (I've checked in my project - %16 is translated to asm in same way as &15)

  • 0 in reply to Disona
    Genius 3050 points
    But I am also interested in TI reccomendations for such cases ;)
  • 0 in reply to Disona
    Genius 5910 points
    Disona,

    Thanks, for your insight of the subject.
    The lack of Ti response is disturbing. When you design a embedded controller you thing something like this through. So it should be a easy question. So why so little information?
  • 0 in reply to Disona
    TI__Genius 10845 points
    Hi evs,

    Sorry for the delayed response. Yes, you can use DINT/ INT for the short atomic operations as Disona & you suggested.

    In this case the interrupt would be pending and will propagate once enabled. For small operations you should not miss the interrupt but might miss, if another interrupt gets generated in the mean time. Hope this helps.

    You can check below link as well:
    e2e.ti.com/.../21489


    Thanks
    Vasudha
  • 0 in reply to Vasudha Bhadoria
    Genius 5910 points

    Vasudha,

     Thanks for the reaction. Can you please tell me if this is correct.

     When  _asm(" setc INTM") is set.

     Every new and pending interrupt is stored in  Interrupt Flag Register (IFR)
    only every second interrupt of the same number is lost. But that is not a problem when the duration of the disable is a couple of cycles long.

    Thanks,

    evs

  • 0 in reply to evs
    TI__Genius 10845 points

    Hi evs,

    Yes, future interrupts from the same line or same channel of a group(for peripheral interrupts) can be missed if INTM is set. It should not be a problem for short operations as yours.

    As you correctly mentioned, every new & pending interrupt is stored in IFR. If both IER & INTM are enabled, CPU approves the interrupt, clears IFR for future interrupts and services it further.

    If INTM is set, CPU cannot acknowledge the interrupt & hence IFR will remain latched and PIEACK will be set. Hence CPU might miss same kind of future interrupts.

    Once the INTM is cleared the pending interrupt is acknowledged by the CPU & IFR is cleared. Interrupt is acknowledged in ISR by clearing PIEACK. Only then the further interrupts can propagate to CPU.

    You can refer C28x CPU Guide  & device TRM for further details.

    Thanks

    Vasudha