USB stack device task option

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

USB stack device task option

3,086件の閲覧回数
scottm
Senior Contributor II

I'm working on porting a project from the old Freescale bare metal USB stack v5 to the current SDK version mostly for the sake of improving compatibility with FreeRTOS (the v5 stack never had the OS support finished) and I've got it running, but I can't find the information I'm looking for on how it interacts with an RTOS.

I'm mostly interested in USB_DEVICE_CONFIG_USE_TASK.  Based on what I remember of the v4 stack and what I can see in the code, I think the option sets it up to use a queue so that the USB ISR just passes messages to a dedicated task.  Is this documented somewhere?

One of the things I'm looking for is the required stack size.  The example is set to 5000 bytes.  How much is required by the stack itself?  And I'm assuming that the application callbacks are made from this task.  Is that right?

I've skimmed through all of the USB stack user's guide, device reference manual, and composite device reference manual, and searched all over for details on the task setup, and I'm just not finding anything.  I've been at it for 12 hours today and I'm running out of steam.  If someone could point me in the direction of the appropriate documentation, I'd really appreciate it.  Or if it doesn't exist yet, that'd be good to know too and I can dive in to the source code and figure it out when I'm not so tired - I just can't take any more searching for documentation that might not exist tonight.

Thanks,

Scott

ラベル(1)
タグ(1)
7 返答(返信)

2,826件の閲覧回数
danielchen
NXP TechSupport
NXP TechSupport

Current SDK has USB support with FreeRTOS.  I would suggest you try the new USB stack.

Regards

Daniel

0 件の賞賛
返信

2,826件の閲覧回数
scottm
Senior Contributor II

Hi Daniel,

It's the new USB stack that I'm talking about.  The version I'm porting the project from is the bare metal v5 stack.  That stack has some issues, like a major bug in the composite device handling due to an uninitialized variable.

My question still stands - where can I find information on USB_DEVICE_CONFIG_USE_TASK?

Thanks,

Scott

0 件の賞賛
返信

2,826件の閲覧回数
danielchen
NXP TechSupport
NXP TechSupport

Hi Scott:

Sorry, the document not mention this macro. I will report this to the develop team.

If  USB_DEVICE_CONFIG_USE_TASK is 0    , it means CPU is in interrupted mode when USB Callback is servicing.

If  USB_DEVICE_CONFIG_USE_TASK is 1,  it means  CPU is in normal (not interrupt ) mode when USB Callback is servicing.

In other words, this macro is defined to check whether the callback is called  by a task, or by an interrupt.

Regards

Daniel

0 件の賞賛
返信

2,826件の閲覧回数
scottm
Senior Contributor II

I've got the new stack working with the USB_DEVICE_CONFIG_USE_TASK option enabled.  My understanding of its operation is this:  Set USB_DEVICE_CONFIG_USE_TASK=1 in your USB device configuration to configure the USB stack to use a dedicated task to process USB events.  You must create an OS task that calls USB_DeviceKhciTaskFunction() in a loop, and this function blocks indefinitely while waiting for messages from the USB ISR.  (This is important in case the user was planning to try to do anything else in that task loop.)  The USB stack makes all callbacks from this task.

Is that correct?  It'd still be nice to have a little more discussion on the architecture and the flow of messages, but I think this is the essential information I was looking for.

You've also provided an example of one of my most frequent complaints about the documentation:

If  USB_DEVICE_CONFIG_USE_TASK is 0    , it means CPU is in interrupted mode when USB Callback is servicing.

I can't imagine how difficult it must be to write technical documentation in a non-native language - I can barely ask for directions in any language other than English - but an experienced tech writer once gave me an easy piece of advice that lots of native speakers overlook: When describing an action, say who does what to whom.

To say "If x is 0, it means..." doesn't say who sets x.  The same words could describe a status bit rather than a configuration setting.  The phrase "it means" sounds more likely to describe a status than an action.  That's why my phrasing was "Set USB_DEVICE_CONFIG_USE_TASK=1 in your USB configuration to...", so the reader knows they're the one who sets it and what the result will be.

I think using active voice and imperative mood ("do this" vs "this is to be done") sounds rude or demanding in some languages, but honestly I'd be fine with the documentation calling me names and mocking my fashion choices as long as the important parts were clear and unambiguous.  :smileywink:

Even if there was a community-maintained wiki or something, that might be a start.  I'd be happy to share my notes there, where they might do some good for others, rather than complain about it here.

Thanks,

Scott

2,826件の閲覧回数
danielchen
NXP TechSupport
NXP TechSupport

Thanks you for correcting my English. About the USB_DEVICE_CONFIG_USE_TASK, your understanding is right. Please be kindly noted that there is an OSA folder in USB stack, this folder includes the adapter interfaces for various OSes. You can use it.

middleware\usb\osa\usb_osa_freertos.c

Regards

Daniel

0 件の賞賛
返信

1,838件の閲覧回数
scottm
Senior Contributor II

Hi,

I'm in the process of migrating a project from a Kinetis part to an LPC55S69 using SDK version 2.8.2 and once again I've run into the problem of lack of documentation for this feature. I can't find any examples that use the USB task mode.

I see that there's a macro for USB_DeviceLpcIp3511TaskFunction(). Like the KHCI and EHCI macros, it evaluates to USB_DeviceTaskFunction(). Do I just call this function from the task? Should I be calling USB_DeviceTaskFunction() directly? Is there an example?

Thanks,

Scott

0 件の賞賛
返信

2,826件の閲覧回数
danielchen
NXP TechSupport
NXP TechSupport

Hi Scott:

As far as I know, the usb stack v5 is integrated into MQX 4.2.

I think you can refer to the docs under the MQX 4.2 installation folder.

C:\Freescale\Freescale_MQX_4_2\doc\usb_v2

pastedImage_1.png

Regards

Daniel

0 件の賞賛
返信