- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am looking to improve my FreeRTOS Command Line Interface service. First a little background:
- My device is a composite USB device with a CDC/UART to which I have added two endpoints which service a HID device.
- The CLI engine is the FreeRTOS package available from Amazon under MIT terms - in other words the latest FreeRTOS 10 shell.
- The USB CDC is the virtual UART to which the CLI is attached and is used with a user's terminal emulator connected to the appropriate COM port.
- The application is really the HID, the CDC UART is just to provide a console for development.
- The present configuration has the FreeRTOS task which processes the CLI continuously checking USBUART_DataIsReady() and being preempted by higher priority tasks.
I would like to create a FreeRTOS semaphore to hold off the foreground CLI task. I do not care that the semaphore is 100% accurate, by this I mean if there is a callback which sometime indicates data could be ready and sometime does not (like perhaps a callback that just indicates something took place on the USB interface) I am OK with that - I can still have the foreground check that data is available with USBUART_DataIsReady() even when the foreground gets the semaphore.
The USBFS_DispatchCDCClass_CDC_WRITE_REQUESTS_Callback does not seem to do what I want. There is little documentation on what I am supposed to do, I can't find an example and the documentation that says "This callback function has to return USBFS_TRUE if request is recognized and handled and USBFS_FALSE otherwise." which implies to me I need to write code to handle data at a lower level that I want if I use this callback. If this is the appropriate place to release a semaphore, could I get a little help to know when I return USBS_TRUE and when I don't?
Would USBFS_EP_3_ISR_ExitCallback be a better place to release a semaphore to the foreground? Endpoint 3 is I believe the output from the host / input to the PSOC for my configuration.
Solved! Go to Solution.
- Labels:
-
PSoC Creator Software
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Macro Callbacks is a term defined in PSoC Creator to call user code from macros specified in a Component's generated code. These macros can be used by defining them in the user-defined header file named cyapicallbacks.h. This file will be included in all generated source files that offer callbacks.
A callback requires you to complete the following:
- class="Bullet1"
- class="Bullet1"
- class="Bullet1"
To complete the example, the cyapicallbacks.h file would include this code:
#define SimpleComp_1_START_CALLBACK
void SimpleComp_1_Start_Callback( void );
In any other user file, you could include cyapicallbacks.h and write the SimpleComp_1_Start_Callback() function.
This forum link may be useful in the requirement:
Looking for advice on using USBUART in an interrupt driven mannor on the PSoC5LP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Macro Callbacks is a term defined in PSoC Creator to call user code from macros specified in a Component's generated code. These macros can be used by defining them in the user-defined header file named cyapicallbacks.h. This file will be included in all generated source files that offer callbacks.
A callback requires you to complete the following:
- class="Bullet1"
- class="Bullet1"
- class="Bullet1"
To complete the example, the cyapicallbacks.h file would include this code:
#define SimpleComp_1_START_CALLBACK
void SimpleComp_1_Start_Callback( void );
In any other user file, you could include cyapicallbacks.h and write the SimpleComp_1_Start_Callback() function.
This forum link may be useful in the requirement:
Looking for advice on using USBUART in an interrupt driven mannor on the PSoC5LP