none
How can I adjust time slice or quantum or each thread to microsecond intervals in WEC 7? RRS feed

  • Question

  • My system implements Real-time signal manipulation that needs to handle events within 10s to hundreds "microseconds".

    This is perfectly OK when I only have single thread executing. However, when I introduce a second thread with the same priority, only one thread gets to execute. The other thread never gets an event.

    I dug deeper on this and found out that in Compact 7 the minimum quantum for each thread is only 1 millisecond. But since my thread gets interrupts in just microseconds interval, it seems that the next thread with the same priority does not get serviced in round-robin scheduling in CE because by the time the first thread's quantum/ time slice expires, a new event is already available for it to be serviced.

    Further to my question, I would like to seek advise if there are any other API that I can use to make sure the round-robin scheduling does not get caught up a single thread especially those with same priorities will be able to execute simultaneously.

    Any thoughts on this?

    Monday, September 16, 2013 4:48 PM

All replies

  • First off, assuming that you can change the quantum to microsecond intervals from 100ms that could cause longer running threads to cause the scheduler to run more frequently by a factor of 100 to 100000 depending on the new Quantum selected.  CeSetThreadQuantum (which I have never used) has an API that will not let you set it below 1 ms as you have discovered.

    I would be very hesitant about setting the thread quantum that low as you will cause the scheduler to be interrupting your threads a lot.  Even if you only set the thread quantum for your two threads that low it can still be blocked up in another thread in the system that runs at the same priority level or higher.  This means that you would have to set quantum globally if you need to ensure that your IST interrupt event gets triggered in time.

    Perhaps there may be a different way to accomplish the same goal?

    If we assume that you are getting interrupts every microsecond (that don't always require processing) then I would write an ISR to receive that interrupt and determine if further processing is required.  If further processing is required I would have it send it off to the IST for further processing.  The IST may be delayed in its execution depending on the system load, priorities, thead quantums, etc...

    If what is important is registering / storing that data every microsecond but not the rate at which the data is utilized I would probably write an ISR receive the interrupt, store the required data and send an event to the IST for later processing so that there are fewer updates to the IST where it can run a longer uninterrupted time-slice.  The ISR can actually store up more than one sample here to improve efficiency.  When the next interrupt occurs (even mid IST) it should be able to run and store more data without requiring the IST to give up its remaining time slice.

    If what is important is that the system must assert a GPIO into a certain state x us after receiving a state change on an interrupt but it does not require the actual data I would probably just do that inside the ISR itself.

    Again, I am unfamiliar with your system requirements and whether one of the above suggestions would work.  From your post it does seem that you have a requirement that you must respond to an interrupt (that you cannot miss and handle later) that may need to be dealt with via an ISR and IST instead of just an IST.

    Good Luck,

    Brad

    Monday, September 16, 2013 6:57 PM
  • MJ,

    What is the second thread doing? 

    Why does it need to be at the same priority? 

    Are the two threads related to each other, or are they for completely different features of your system?

    What is the thread priority?

    Why would you want an interrupt driven thread to be run in round robin with the other thread?  By definition, the interrupt driven thread should run when the interrupt occurs, given that higher priority threads are not running.  This is necessary in a real-time OS.


    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman

    Eurotech Inc.
    www.Eurotech.com

    Monday, September 16, 2013 7:19 PM
    Moderator
  • Thanks for the replies.

    In our system, we will be driving several motors which needs to run at the same time. We use PWM to drive these motors. The motor PWM specs is within microseconds interval.

    There is no problem driving the motors one at a time, we can get interrupts in each required say 30us interval and trigger the next one and still get an interrupt in our IST after 30us.

    We set the thread priorities of each motor IST to 11. And looking through kernel tracker, there are no other threads that have higher priorities than these.

    Each motors serves the same purpose, therefore the thread priorities are set to same value. And our expectation is because CE implements round robin for same priority threads, the other thread should be able to get its time slice. But seems this is not happening and only the first thread get to execute.

    As for the ISR, my question is this. If we are actually able to driver a motor within 30us intervals of pulses, doesn't this already support that IST is sufficient for our needs?


    Tuesday, September 17, 2013 2:34 AM
  • I would to add another question. Is there an API that allows a thread to yield before it's time slice is over?

    I don't think WaitForSingleObject actually yields right away. Or is this a wrong assumption?

    Tuesday, September 17, 2013 2:38 AM
  • Sleep(0);   // Allow other threads at same priority to run

    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman

    Eurotech Inc.
    www.Eurotech.com

    Tuesday, September 17, 2013 12:34 PM
    Moderator
  • That is certainly going to depend on a number of factors including:

    1. CPU speed

    2. Interrupts - other interrupts will use time in ISR

    3. Efficiency of your code

    Do you not have any hardware driven PWMs in your system?  If you do, then use them and use your interrupt to change the output when needed.


    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman

    Eurotech Inc.
    www.Eurotech.com

    Tuesday, September 17, 2013 12:39 PM
    Moderator
  • An ISR will have lower latency than an IST and will be more efficient especially if you have many interrupts firing and needing to be serviced.  Whether you HAVE to use an ISR or can use an IST will depend on the performance of your system and your timing requirements as well.

    If an IST is sufficient for your system requirements you could just use that.  The main reasons for using an ISR over an IST is for efficiency, shared interrupts and when the IST latency is too high.

    If you are trying to drive your PWM frequency and duty cycle off of a GPIO and are using an interrupt from some sort of timer to control the clocking rate you should consider what your requirements are for your PWM output and how inaccurate it is allowed to be before you no longer meet the requirements of your system.  Even though you are running in an IST/ISR, other interrupts can interrupt your execution depending on their priority and your system.  I would suggest measuring your PWM output to ensure it is within your system limits when the code is complete.

    If your clocking rate is the same for all PWM outputs you could probably run all PWMs off of the one interrupt to give them all the same frequency but different duty cycles.  This of course assumes your interrupt is used to clock your software-based PWM.

    After re-reading your original post is your problem that your second thread "NEVER" gets woken up or that it does not get woken up in time?  Up to this point I've been assuming that your second thread doesn't get woken up in time.

    Tuesday, September 17, 2013 11:33 PM