• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 1137 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.

RTOS/TM4C123GH6PM: implicit posting for the events

Mohammed Fawzy
Expert 1905 points
Part Number: TM4C123GH6PM

Tool/software: TI-RTOS

Hello,

my platform is:

- EK-TM4C123

- tirtos_tivac_2_16_01_14

- xdctools_3_32_00_06_core

- running TI sample event_EK_TM4C123GXL_TI

i noticed that the explicit posting in the sample isn't causing the events to be queued while the implicit posting will cause the events to be queued?

and i will describe the behavior in term of pend/post

if the Event_post is invoked twice to post Event_Id_00, then i did only one Event_pend, the event mask will be cleared (No queuing for the event)

if the Mailbox_post is invoked twice, it will implicitly post "Event_Id_02", then i did pending with Event_pend, it will consume Event_Id_02 then once Mailbox_pend, i can see in the ROV that Event_Id_02 is appeared once again without any explicit/implicit posting. so it seems that the implicit event posting is queued with the mail box, Is this the correct behavior?

Thanks,

Mohammed Fawzy

  • 0
    TI__Guru**** 190806 points
    Hi Mohammed,
    Mailboxes are actual containers and you will need to specify the number of messages and the size of each message as illustrated in the Mailbox_construct() where 2 messages are specified. If you call writertask twice then it passes two messages to the mailbox and the readertask will consume these messages until the mailbox is empty.

    I will ask our TI-RTOS experts to provide additional comments.
  • 0 in reply to Charles Tsai
    Expert 1905 points

    Hi Charles,

    Thank you for the reply. but i know how the mailbox works and i have no problem with that. my problem is with the implicit event as i described early.

    simply, the first pending on the mail box will cause posting (very strange!!!) for the event flag Event_Id_02, and you can verify it easily using TI sample.

    Thanks and Best Regards,
    Mohammed Fawzy

  • 0 in reply to Mohammed Fawzy
    TI__Guru**** 190806 points
    Hi Mohammed,
    I'm not an expert in TI-RTOS. But this is what I can make out based on the example. In the writertask you try to write 3 messages but the mailbox is configured for only two messages. Therefore, the writetask will block/pend if the mailbox is full, waiting for the readertask to read the message. The writertask will implicitly post the event_Id_02. The readertask was pended based on the andMask of Event_Id_00 + Event_Id_01 and orMask of Event_Id_02. When the event_id_02 was posted it will first consume the first two messages. The Mailbox_pend grabs the messages until the mailbox becomes empty and becomes pend again waiting for a new message to be placed.

    So in a sense, you are right that the mailbox is like a queue where the three messages/events are getting queued. After the three messages are sent across from the writertask to the readertask, there is no more event to be generated by the writertask. The readertask can only unpend based on the Event_Id_00 + Event_Id_01. Since these two events are posted from the clock modules with different timeout values and only when both events are valid will it be able to unpend the readertask.

    Our RTOS expert can provide additional comments.
  • 0 in reply to Charles Tsai
    TI__Guru* 96960 points

    Hi Mohammed,

    I modified the Event example to have the writertask be higher priority than readertask. I also changed the writertask to simply do two Mailbox_post calls (and then exit the task). The readertask ran and Event_pend returned with the posted value indicating an Mailbox message was ready (Event_Id_02). When I looked in ROV, the Event->postedEvents was zero (it was 4 before the Event_pend call). Now comes the tricky part that we didn't document well....
    When the readertask calls Mailbox_pend, it will get the message, but it also resets the postedEvents back to 4 (this can be seen in ROV). The logic is that the kernel knows there is another message there (since the internal semaphore count is non-zero). So instead of forcing you to call Mailbox_pend until a failure, the event is repost, so you can call Event_pend again and have it return 4 again (which allows you to get the next mailbox message).

    Does that clear it up (or make it muddier)? I'm going to open an doc enhancement request so we can explain this in either the User Guide or the API Reference.

    Todd

  • 0 in reply to ToddMullanix
    Expert 1905 points

    Hi Tod,

    Thank you for your reply and i got your point but the behavior of the RTOS in my point of view is inconsistent between the implicit posting and the explicit posting, such that 100 of explicit event posting can be consumed with one event pending (of course if the pending wasn't available before the 100 post) while 100 of implicit posting needs 100 pending.

    anyway, currently, i understood how does it work but my concern is about the inconsistency in the behavior and in some case can be considered as a bug.

    Mohammed

  • 0 in reply to Mohammed Fawzy
    TI__Guru* 96960 points
    You can consume all Mailbox messages with one Event_pend. For example, the following pseudo code is okay

    Event_pend()
    do {
    rc = Mailbox_pend( &msg, NOTIMEOUT);
    // process msg
    } while (rc == TRUE)