Using delayed processing with FSL USB stack

[scottm]

I'm using Freescale's USB stack v4.1.1.  If you set it up manually you can configure it for delayed processing of class events.  I'm using it for a mass storage device, and delayed processing is important because access to the SPI bus is shared and I can't have the mass storage device class trying to use it in the middle of a transfer.  Instead, I call the periodic task in the main loop where I know access is safe.

As it is, it works great and I've been using it that way on Coldfire for about two years.  I'm porting the application to Kinetis and attempting to use the Processor Expert wrapper for the USB stack and it doesn't appear to have any way to configure delayed processing.

Disabling USB interrupts everywhere there might be a conflict is inconvenient and even then it seems dangerous.  Is there any way to use delayed processing with PE, or do I  need to rip it all out and set it up manually?

Thanks,

Scott

[marek_neuzil]

Hello Scott,

I am sorry the Freescale USB stack v4.1.1 is an obsolete product. You can use KSDK 1.3.0 (USB stack) and KDS 3.0.0. There is Mass Storage Device demo example with SD card, see for example KSDK_1.3.0\examples\frdmk64f\demo_apps\usb\device\msd\ (this project does not contain Processor Expert and components). You can see the example how the delayed processing is implemented by using KSDK 1.3.0 drivers (SD card is used). KDS 3.0.0 support also Processor Expert, i.e. you can create a new Kinetis project with Processor Expert and KSDK 1.3.0 and implement your application by using Processor Expert KSDK 1.3.0 USB components.

Best Regards,

Marek Neuzil

[scottm]

I find KDS to be ugly and cumbersome and I've already paid for CW 10 so I'm going to stick with it as long as I can.  I stuck with Coldfire rather than moving to Atmel's ARM-based parts years ago because I didn't like Eclipse, and Freescale immediately moved Coldfire support to an Eclipse-based CodeWarrior.  I finally got off CW 6.3 and paid for CW 10 for the sake of having one environment for HCS08, Coldfire, and Kinetis development and then Freescale announced that they were dropping support for Kinetis in CW.

I understand that Freescale can't compete with IAR and Keil in the ARM development tool market and there's no reason to duplicate the effort, but I'm not about to split my development efforts again.  If I have to switch again I'll look at other vendors entirely.  I started out with the 6800 and HC11 more than 20 years ago, and in the last 5+ years Freescale hasn't done much to earn my continued loyalty.  Maybe things will be better under the NXP regime, but I'm not sure I want to be in the middle of it.

Sorry for the rant, but I feel like Freescale keeps giving up on tools and support and small business customers are treated no better than hobbyists.

Since this says you're an employee, may I make a more productive suggestion?  The Freescale USB stack page simply says "archived content" and makes no reference to KSDK or any other suggested replacement.  Since it's still the most visible search result, it'd be useful to have it refer users to the current solution.  Also, under 'downloads', the downloads are shown oldest first and versions newer than 3.2.0 are hidden until you click 'more'.  It's not at all obvious at first glance that more recent versions exist.  Changing the sort order would be a good start.

As for the original problem, I went ahead and used 4.1.1 without PE so the ColdFire and Kinetis versions of the product can continue to share most of the code.  I've made some tweaks to the stack to reduce the RAM usage and interrupts and it's working fine on both platforms.

Regards,

Scott

[scottm]

To add to my answer - I did get 4.1.1 working with delayed processing but found out that it still apparently gets some class driver callbacks in interrupt context.  Not sure if this is intentional or not since I can't find any docs on the option.

My solution was to keep USB interrupts masked through most of the program's main loop, then unmask, call the MSC periodic task, and then re-mask the interrupts.  I'm not sure how long it'll tolerate going without the interrupts being serviced, but the loop in this case generally has a period in the hundreds of microseconds and most other functions are suspended while it's connected via USB so it's been working fine.

Scott