Thus far, this has worked surprisingly smoothly, with fast I/O and enumeration through what is presumably well-optimized path on all systems tested and no privilege elevation. All data outside of the hard-wired I/O file sectors is reloaded into RAM at enumeration and ignored. The trick being to report the metadata for a FAT filesystem containing a hidden device I/O file, which the interface application then employs raw file unbuffered I/O to communicate through. Instead I am evaluating a scheme of impersonating a mass-storage device. HID is straightforward and flexible but has poor throughput aggrevated by MCU-specific limitations. This suggests the use of a standard USB device class. In part, due to the resources required to develop and sign custom drivers, and in part as third party drivers have proved a significant stumbling block for users. I am developing a USB-based peripheral device for use on Windows desktop systems and would prefer to avoid a driver installation step.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |