problem with FreeRTOS and USB

[anhhuy0701]

Posted on February 26, 2014 at 16:37

hello everyone

today I have a problem but I don't have any solution for that my problem: with USB per 1(ms) send 1 interrupt to system and if not solve this interrupt, the data will be broken                      with freeRTOS if the Systick is 1(ms) the overhead will be high and it not good, I want to increase Systick be 10(ms), but if I do like that, that's not compatible with USB. How can I solve this problem? (I really want to keep the Systick is 10(ms)) (My skill English is not good, if you want more clearly or information, I will provide) Thank and regard!

[chen]

Posted on February 26, 2014 at 17:39

Hi

I do not know what you have done but I have FreeRTOS running with systick at 1ms interval. We also have the USB stack running OK. ''my problem: with USB per 1(ms) send 1 interrupt to system and if not solve this interrupt, the data will be broken'' I do not understand what you are saying here. ''with freeRTOS if the Systick is 1(ms) the overhead will be high and it not good, I want to increase Systick be 10(ms), but if I do like that, that's not compatible with USB. '' Not true!

[anhhuy0701]

Posted on February 26, 2014 at 18:10

[Tesla DeLorean]

Posted on February 26, 2014 at 18:32

again, do you understand my mean?

No, not really. Why do you let FreeRTOS interfere with the USB interrupt? What's the USB interrupt doing? Is it independent of the FreeRTOS, or are you making it dependent on it in some way? Can you give the USB interrupt preemptive priority so other long running ''interrupts'' don't block it? If you can't explain in English, then show your code, or get your teacher to explain it.

[chen]

Posted on February 26, 2014 at 18:40

''

with USB: 1(ms) it send an interrupt request to system, in 1(ms) if the system not solve that request, it will be lost data

'' I do not understand what you mean. What part of the USB stack sends at regular 1ms intervals?

[dthedens23]

Posted on February 26, 2014 at 18:45

There is no problem.  Systick is the interval where the RTOS inspects whether or not it needs to do some task switching.  But an interrupt may force the RTOS to switch before Systick expires.  If USB sends data to the system every 1ms, then the USB interrupt may force a context switch.  It is somewhat wasteful, so maybe buffer up a few USB packets before asking the RTOS to switch context

[anhhuy0701]

Posted on February 26, 2014 at 18:51

hi Ad

I'm newbie in freeRTOS and embedded system, that problem teacher give me to look for the solution and I don't write any code. wait for my thinking and I will be back as soon as I have good way to explain thank.

[anhhuy0701]

Posted on February 26, 2014 at 19:05

dear rocketdawg

assuming

Systick is 10(ms), when systick expire, context switch one task to another task. but at per 1(ms), usb send 1 interrupt, and with this interrupt I have to stop the task which is doing to receive or send data of usb, and how can I do like that? and FreeRTOS support any

mechanism

for my problem? If my problem is not true? can you explain for me what point wrong thank so much.

[Tesla DeLorean]

Posted on February 26, 2014 at 19:10

Interrupts don't have to let the RTOS perform a context switch, and normally don't.

[jpeacock2399]

Posted on February 27, 2014 at 01:08

okay, let's assume you have some kind of completion routine that triggers on the USB SOF (1ms).  To acheive the highest thruput you need to service the USB class immediately, highest priority, so you want FreeRTOS to preempt the current task in order to complete the USB endpoint transfer.

Assuming it is NOT handled in the interrupt then a completion task is set up to handle the USB request.  When the SOF arrives the interrupt handler sets a FreeRTOs completion flag whihc unblocks the USB completion task.  A task pre-emption occurs at the end of the interrupt, so the USB is always highest priority and is immediately serviced. Att he end of the USB comlpetion work the task blocks, waiting for the next flag.  FreeRTOS performs a context switch to continue with the rest of the tasks in the remaining time.  If the USB completion consumes all the 1ms slice then you have no time left to do anything else. It's straightforward real time design, prioritized serving but you have to be sure there's enough resources for it to work.  Seems odd to interrupt on a USB SOF instead of an endpoint request though.  The other side of the USB connection may not be able to handle 1ms per data transfer.   Jack Peacock   Jack Peacock