Previously, I wrote a CMSIS-DAP implementation called "Dapper Miser" that utilized a very inexpensive PIC16F1454 microcontroller.
It was done under my (apparently misguided) belief that there would be interest in a development board for hobbyists and education that would provide significantly better functionality than existing incumbents like the Arduino, and do so at a fraction of the cost.
To aid that development, I wrote a USB bootloader for the PIC16F1454. Since there wasn't such an offering available (at least not in open-source form), I released the code.
The code was originally based on Microchip's USB Framework (aka MLA). The license terms for this are highly problematic for open-source efforts.
I've since recognized the virtues of M-Stack, an alternative open-source USB stack for PIC written by Alan Ott of Signal 11.
When I initially tried M-Stack, I incorrectly thought it was too inefficient in its use of the PIC's available flash memory. However, I've later come to realize that this is just an artifact of the way the example code is written.
Alan Ott has, admirably, written the examples with provisional hooks already in place for lots of USB functionality. This makes the M-Stack examples easier to adapt. It should be much easier to remove functionality from a M-Stack example than to try to add functionality to an ill-documented Microchip USB Framework example. (Knowing what to add is ambiguous; seeing what to remove is much easier.)
Microchip provides a free version of their XC8 compiler. In the Free version, it prints out the following rather amusing statement:
Running this compiler in PRO mode, with Omniscient Code Generation enabled, produces code which is typically 40% smaller than in Free mode.
Omniscient Code Generation could better be described as having more than no optimization. Most modern C compilers have at least rudimentary optimization; XC8 actively acts inefficiently in the Free version.
So, when the example code has an empty function, XC8 doesn't omit it; instead, it produces unnecessary code just to spite the user for not buying the option that costs $1295/year.
The compile is also wantonly inefficient in switch() statements. It is not enough, apparently, to have a design win for their chips; Microchip really wants to inconvenience users for not buying the expensive version.
The good news is that if one is willing to manually hand optimize one's C code, it seems possible to recoup some of the efficiency lost in the free XC8 version (and possibly also further improve upon the performance with the non-free XC8 variants).
What follows are some numbers on code size using my "mouseplay" example code that is available on the bootloader site. These are based on the free XC8 v1.21 compiler.
|2680||the prior implementation of "mouseplay" using the Microchip USB Framework (aka MLA) using a polled architecture. (MLA was never capable of reliably using interrupts.)|
|3912||mouseplay1: functional equivalent using M-Stack in its default interrupt-enabled mode|
|3357||mouseplay2: switched to polled architecture|
|3108||mouseplay3: removed GET_REPORT and SET_REPORT callbacks|
|3010||mouseplay4: removed GET_IDLE and SET_IDLE callbacks|
|2932||mouseplay5: removed GET_PROTOCOL and SET_PROTOCOL callbacks|
|2886||mouseplay6: removed SET_INTERFACE and GET_INTERFACE callbacks|
|2768||mouseplay7: removed remaining unused callbacks (SET_CONFIGURATION, GET_DEVICE_STATUS, ENDPOINT_HALT, OUT_TRANSACTION, IN_TRANSACTION, UNKNOWN_GET_DESCRIPTOR, USB_RESET)|
So, with a bit of manual effort, one can get M-Stack within spitting distance of the size of the Microchip USB Framework (aka MLA) implementation. I have no doubt that Microchip's example code that served as a basis for the original "mouseplay" was already stripped-down for marketing reasons to achieve the good numbers (even with the free XC8).
That Alan Ott of Signal 11 can achieve relative parity of Microchip's entire development team and also deliver documented code that is much more readable (and can be redistributed) is a testament to his skill.
Aside: it is my opinion that it would have benefited Microchip overall to make the advanced compiler features for free. I know there is a corporate compulsion to show income for each department to show that it is pulling its weight, but keeping the tiers of compilers is just stealing from Peter to pay Paul. The compiler is specific to their chips, so it can't benefit their competitors. If the more advanced optimization features were universally available, Microchip's example code wouldn't have to be hobbled to make impressive numbers for the marketing department, and I suspect this would ease the development effort of engineers considering a "design in" and thereby lessen the demand on Microchip's technical support department and discourage "design losses" so as to have more sales volume.
back to main page contact