I have now reached the stage where all electronic devices I own that are smarter than toaster have an USB port. The only device whose port is not usable in a cross platform fashion is the one of my electronic dictionary, a Ex-Word dataplus 2 by Casio. So I have started looking into writing some software to communicate to this device from my Mac. This is not an easy task, in many ways it is like solving a puzzle, or maybe doing archeology. The official Casio web site is useless, the dictionary is only present in the japanese site, and there is not a single mention of Mac OS X or Linux.
So what does the device tell on the USB port? Basically the device announce itself as a device named “CESG502” manufactured by Casio. It claims to draw its power from the USB bus (which is lie, the device runs on its own batteries) and draws 100 milli-amperes. The device has a single, vendor specific interface with three pipes: bulk-in, bulk-out and interrupt. Basically, this means that no standard driver, like USB mass storage will work. The only hint we have is this device name, “CESG502”.
Searching around on the web shows me that this string is also the name of a Windows driver used in various Casio devices with USB ports: Pocket Viewers and Graphing Calculators. I found some online documents about the protocol used:
- Communication Protocol For CASIO Digital Diary Version 3.8L. Be careful, Google claims this site is infected with malware, the document seems fine.
- CASIO fx-9860 Communication Protocol Speciﬁcation translated by Andreas Bertheussen.
I also found some open-source programs to communicate with such devices:
The last one has direct USB support and I managed to compile and run it on OS X. The problem is, the dictionary claims that this program uses an old protocol that is not supported and urges to switch to version 2.0. I get the same error message when running the Windows program for the French or the German dictionaries against my japanese model. Back to square one.
Time to go low level, I loaded a USB protocol sniffer and ran the Windows program for the japanese dictionary (the one that works) to get traces of the various operations. The first observation is that the functionality is very reduced, one can only upload text files and delete them, no download, and no other file format seems to be supported. The second observation is that the protocol is quite different from the one of the previous versions. Here is what I found out:
- The device link needs to be activated in the same way as in previous versions, this means sending a USB control message on the interrupt pipe with request type
0x41and request value
0x01without this the device does not response to any packet.
- Communication is still packet oriented, but the format used by the PC to send commands is different.
Byte 0 is the sequence number, byte 1 is the packet type, byte 3 is the length of the packet.
- Command packets have a type of form
0x8X. Byte 4-5 contains the number of 16 bit parameters that follow. The bytes following the integer parameters contains the command a string with 16 bit wide characters, the packet is terminated with one single byte field that contains zero. The string seems to be the actual command.
- Ack/Response packets start with byte
0xA0, byte 2 contains the length of the packet. A simple ack packet is three byte long, answers have the same structure, with a payload starting at byte 3.
- Nack packets have the same structure as Ack packets but start with
0xD0. As soon as an error occurs, the device sends a Nack packet, closes the connection and displays an error message.
- Here are some of the command strings I found:
_CryptKey(this is not good).
I have some rudimentary code that open the channel with the device and get some raw bytes, I’ll post more information once I made some more progress…