Hej Anders! Anders Rundgren wrote: > maybe could reuse the standard mass memory interface
I'm extremely sceptical towards using MSC. I would encourage you to go for a vendor specific interface at least for prototyping, but possibly also for deployment. A device class is not mission critical, good device drivers are. If there was any ever doubt then dealing with years of libusb users has wiped it out; just stay away from existing device classes unless your application actually benefits from the standardized interface. Vendor specific means that you have complete freedom in the USB communication, which keeps software development efforts to a minimum both on the target and on hosts with a decent operating system. When digging into USB it quickly becomes evident that HID is the only simple way of communicating with USB devices on Windows - but please don't make the mistake of going down that route, unless you know for sure that you will never want your device to work anywhere else than on Windows systems! The only good reason to implement an MSC device would be that you explicitly want the user interface to be in form of files, since it naturally fits the purpose of the device. If another workflow is intended then I strongly recommend avoiding MSC or any other USB device class which is not perfectly suited to the use case. > Java and be 100% platform independent. I don't quite understand the purpose of the Java program, but I'll rant anyway and maybe it'll apply. :) Java is a huge dependency and resource hog on every platform except maybe Java cards. I think C is the lowest common denominator for all popular platforms today, so I think it's a better choice for abstracting platforms. > The (anticipated) development system: > http://mbed.org My head hurts when I hear or read "cloud" or "in the cloud" so I would look elsewhere for hardware. One very concrete thing that struck me on the mbed web site is the lack of technical detail about the hardware. Maybe it's on purpose, and maybe it works for the intended market of the mbed board, but it doesn't resonate well with me for developing an open device. >From the photo I can make out the NXP logo on the controller, I think that's a good thing. There's a lot of good documentation for NXP parts. The mbed hardware looks like a nice development board (are the schematics available?) but I find the price a little high. I recently started using another NXP microcontroller, LPC2148, it is an ARM7TDMI and it also has USB. I built gcc and gdb for it, openocd, downloaded some examples, polished up the openocd config and the examples, and away it went. The board[1] was EUR 39, so about half the price of mbed, but then the 1768 can go up to 100MHz and the 2148 only to 60. > Comments? You got 'em. :) //Peter [1] http://www.olimex.com/dev/lpc-h2148.html _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
