Version 1.3, Thu, 24 Dec 2020 12:00:00 +0100
Nowadays, USB HIDs are widely used to connect hotplug devices to a computer without the need to provide a device driver. In order not to be rejected, such a device meticulously answers all requests from the host, but formulates the descriptors so that the host cannot determine what the device is intended for. The device is available in that way, but cannot be accessed by the operating system. It is therefore immediately available in the user space if the application in question has the necessary rights. It is further of secondary importance whether the user space application then uses the standard HID interfaces or proprietary vendor USB interfaces for the actual work.
Regardless, creating a properly functioning USB HID is not that easy. It is therefore sensible to publish the code of a standard-compliant and quite complex device one time in order to give beginners or interested parties a reasonable start. The code below passed both the Chapter 9 Tests and the HID Tests provided through the USB 2.0 tool USB2CV 1.5.4.2 with 0 aborts, 0 fails and 0 warnings each. So it is no wonder that the presented USB HID is so compatible that it also works perfectly with optical USB 3.0 extension cables on SuperSpeed USB interfaces.
As of June 2, 2022, the phrase Writing to the flash program memory has not yet been tested no longer applies. With the completion of the implementation of a remote update program and its successful execution, it is clear that writing to the flash program memory is working fine. So everything that had to be done has been done.
For the change log click Changelog.
The file mainusb.c-DIFF (click here for download) shows the output of the last diff.
Comments, bug reports, and better ideas are welcome.
The file mainusb.c (click here for download) contains the source code of a particular USB HID. The present code controls the bare silicon without any library. In addition to the fact that this code impressively shows how asynchronous peripherals are operated at a very low level, the first time dealing with the Harvard architecture leads to very special insights. The device control here does without the use of generic pointers for reasons of efficiency. So much more caution needs to be exercised, for example, with cast operators applied to pointers. On the other hand, it becomes clear that the strict separation of the different memory areas has to be somehow undermined in order to cope with such an architecture as a whole. What is missing on this website is the small startup file, which cannot be displayed for licensing reasons. Startup files in assembly language are usually located in the development system used. The so-called cruncher found is the actual payload application that accepts and delivers a character string per call. The cruncher can only be seen here as a stub. The following photos show two candidates for the underlying hardware. The one on the left is a platform based on the 24 MHz C8051F346 microcontroller, as offered by Crossware in the past. The one on the right, based on the 48 MHz C8051F342 microcontroller, is the platform that Seidl Technologies is currently using as the successor to the Crossware device. D3 at P0.0 and D5 at P0.2 are green LEDs, and D4 at P0.1 is a red one. The remaining circuitry follows the example and the recommendations for SiLabs ToolStick Basic Adapter C8051F342 daughter cards with C2 pin sharing. See also the corresponding documents SiLabs AN124 and AN127.
That's it.