I'm transmitting a buffer array from inbuilt USB of PIC 18F controllers and sending this to a GUI. I am able to detect the device properly (enumeration). But the GUI crashes some times, without any reason.
I assume it is a transmission/interrupt problem as whenever I'm sending a constant number it does not crash. But whenever I'm doing an ADC operation and sending the corresponding value via USB, it crashes.
This made up my assumption that USB transmission or interrupt handling needs to be handled properly.
I'm new to the USB protocol and tried with this working code.
I have no problem regarding enumeration, but when transmits the crashing occurs.
The format of the code is:
main()
{ usbinit(); // usb initialization
while(1)
{
x=do_adc();
UsbTasks(); // does usb works
yourtasks();//sends the buffer
}
}
I would like to understand what might be the cause behind this anomalous behavior.
As noted below in the comments the USB stack is set for polled configuration. How should I manage the ADC read?
If I do:
while(1)
{
UsbTasks(); // does usb works
x=do_adc();
yourtasks();//sends the buffer
}
Will it make any change? Or is this not the best way to send ADC values?
Answer
According to the USB CDC Class on an Embedded Device application note by Microchip which would mostly apply to other device classes as well:
The USBTasks routine may be used in a polled, cooperative manner as demonstrated. If so, nothing in the main loop should block for more than a few microseconds or events may be lost.
So the main two solutions that come to mind are:
Rather than wait for the ADC conversion to finish start the conversion and then use a conversion complete interrupt so that the main processing loop can continue while the ADC is taking a sample.
Set the USB stack to use the interrupt-driven mode to remove the requirements to call
UsbTasks
so often.
For most applications I'd say the latter is probably the easier solution so you don't have to worry so much if your main loop stalls a little while.
No comments:
Post a Comment