Writing reports to the device
Writing a report to the device is as simple as using the WriteFile Win32 API call to send the data. Here’s an example where I use the overlapped IO functionality to asynchronously write a 10 byte report to the device. The report data consists of the mandatory report ID number, which as you’ll remember from the previous paragraphs is #2 for OUT reports in my report descriptor.
// NB: _dataOutEvent and _exitEvent are manual reset CEvent classes.
DWORD dwWritten,retval;
OVERLAPPED overlapped;
HANDLE h[2];
ZeroMemory(&overlapped,sizeof(overlapped));
overlapped.hEvent=_dataOutEvent;
h[0]=_dataOutEvent;
h[1]=_exitEvent;
static const char *report="x02stm32plus";
if(!WriteFile(_deviceHandle,report,10,&dwWritten,&overlapped)) {
if(GetLastError()==ERROR_IO_PENDING) {
if((retval=WaitForMultipleObjects(sizeof(h)/sizeof(h[0]),h,FALSE,INFINITE))==WAIT_OBJECT_0) {
// IO has completed asynchronously (but we blocked waiting for it)
}
else if(retval==WAIT_OBJECT_0+1) {
// exit event has been signalled elsewhere in program - we should quit
}
}
else {
// real error - handle it
}
}
else {
// IO has completed synchronously
}Reading from the device is just the same workflow using an OVERLAPPED structure to indicate an event that should be signalled when the operation is complete.
Clocking a USB peripheral
The 12Mb/s USB data signalling rate is required by the standard to have an accuracy of +/- 0.25%. This is easily achievable with an external crystal but not so with the on-chip 8MHz oscillator used for many STM32 F0 applications as this has an accuracy of +/- 1%.
In my own measurements using an F051 device I found the internal 8MHz HSI clock to be ticking at 8.038MHz (about 0.5% off nominal) and to exhibit poor stability. In laymans terms that means the frequency was all over the place. The internal clock can be trimmed in 40kHz intervals and that may be one solution but a better one is to use the dedicated internal HSI48 clock and enable the clock recovery system (CRS) to have it automatically trimmed from the Start of Frame (SOF) packets sent to the device by the host every millisecond. On it’s own the HSI48 clock is trimmed by ST at the factory to about 3% accuracy at 25°C so using it without CRS is not an option. Another neat feature is that you can output the trimmed clock on the MCO pin which is available on the larger pin packages to clock other peripherals within your design.
I explain how to set up the HSI48 with the CRS in my previous article, A development board for the STM32F042 TSSOP package. Search down for the Testing USB heading to see the code and explanation.
That’s all
I hope you enjoyed this little walkthrough of one of the more difficult peripherals to program on the STM32. If you’ve any comments or short questions then please use the comments section below. For more involved questions then please use the forum.
Authored by Andy Brown.
Original article at his website.
[tps_footer][/tps_footer]
