In file usb_dev.c, lines 276-278, I find the following:
if((event->direction == USB_RECV) && (event->buffer_ptr != NULL))
OS_dcache_invalidate_mlines((void*)event->buffer_ptr,event->len);
service_ptr->service(event,service_ptr->arg);
In file adapter_bm.h, line 64, I find the following:
#define OS_dcache_invalidate_mlines(p,n)
The combination of these lines looks, to me, suspiciously like one of those old-time cartoon bombs, with the big,black sphere, and the fuse sizzling away. The hapless customer who attempts to use the library on bare metal, without MQX, is likely to find himself chasing an interesting problem. Once the preprocessor does its thing, the compiler will see:
if((event->direction == USB_RECV) && (event->buffer_ptr != NULL))
service_ptr->service(event,service_ptr->arg); /* indentation added to emphasize issue */
which is probably not exactly what is wanted, if the direction happened to be USB_SEND.
May I respectfully suggest the following modification?
if((event->direction == USB_RECV) && (event->buffer_ptr != NULL))
{
OS_dcache_invalidate_mlines((void*)event->buffer_ptr,event->len);
}
service_ptr->service(event,service_ptr->arg);
Solved! Go to Solution.
Firstly thanks for your raising the problem and help us improve the USB’s stack’s quality. Since there is a “;” , the combination of these line by compiler will be to:
if((event->direction == USB_RECV) && (event->buffer_ptr != NULL))
;
service_ptr->service(event,service_ptr->arg);
So it will not impact the functionality of code. But I appreciate your code that you suggest change to. Such code is more clear and unambiguous. We accept it and change it in our stack.
Firstly thanks for your raising the problem and help us improve the USB’s stack’s quality. Since there is a “;” , the combination of these line by compiler will be to:
if((event->direction == USB_RECV) && (event->buffer_ptr != NULL))
;
service_ptr->service(event,service_ptr->arg);
So it will not impact the functionality of code. But I appreciate your code that you suggest change to. Such code is more clear and unambiguous. We accept it and change it in our stack.
Thank you very much for the clarification.
I missed the semicolon. You're right, the semicolon makes it safe. It still bothers me.
Thank you for accepting the change suggestion.