HP Prime/Linking Protocol

De TI-Planet Wiki
< HP Prime
Révision datée du 5 septembre 2022 à 10:19 par Adriweb (discussion | contributions) (Page créée avec « <div style='text-align: center;'>This is a slightly-updated backup copy of the article from the old "HPWiki" of TI-Planet (that only hosted HP Prime info)</div><hr> This p... »)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Sauter à la navigation Sauter à la recherche
This is a slightly-updated backup copy of the article from the old "HPWiki" of TI-Planet (that only hosted HP Prime info)

This page aims at providing information about the linking protocols of the HP Prime.

The TI-Nspire uses vendor-specific class and proprietary protocols which require specific drivers; the Casio Prizm uses MSD, and the HP Prime uses standard classes as well. Standard classes which do not require extra driver installs are a boon to users.

High-level USB behaviour

"Normal" mode

In normal mode, the Prime exposes itself as a Human Interaction Device (HID). That's a standard class, with built-in drivers in pretty much any USB-supporting OS, aimed primarily at mice, keyboards and joysticks; lots of manufacturers (ab)use that class for other purposes.

Click to see the USB descriptors dump : Details anzeigen

Reflashing mode

In reflashing mode, the Prime exposes itself as a Mass Storage Device (MSD), another standard-class with built-in drivers.

Click to see the USB descriptors dump : Details anzeigen

Lower-level USB behaviour

"Normal" mode

The protocol is being decoded, and a toolkit for communicating with Prime calculators (six basic operations, more in progress) is available from at https://github.com/debrouxl/hplp . Since 2013/11/03, the program has an interactive terminal-based UI, which makes it usable by a wider audience, though lack of a GUI is still an obvious showstopper for many.

There is another small implementation of the undocumented protocol, called PrimeComm [1] available at https://github.com/eried/PrimeComm , written in C# .NET 4.0.

USB headers and chunks[2]

The first chunk has the following structure:

Byte 0 1 2 3 4 5 6 7 8 9 10 11
Example 00 00 F7 01 00 00 00 B8 06 1C 94 DD
Description Start Start Type Items Size Name length CRC
Additional Count from last Size byte (7) until end Byte length

After the first chunk, the data does not fit in a "chunk" is sent using the following format:

Byte 0 1 2 3
Example 00 01 00 00
Description Start Chunk Data from here, up to the chunk end
Additional Goes back to 0×00 after 0xFF

Generating the USB chunks

After adding the main header to the data, the chunks contain 2 bytes less than the size of the chunk, to include the chunk number, so we can translate all this to:

Little C# code snippet [3] as example of this:

var fullData = new List(_header);
// Name
var nameBytes = Encoding.Unicode.GetBytes(name);
// Size
var size = BitConverter.GetBytes(data.Length + nameBytes.Length +5);
// Combining all fields
fullData.Add((byte) nameBytes.Length);
fullData.AddRange(new byte[] {0x94, 0xdd}); // CRC
var allBytes = fullData.ToArray();
int position = 0, chunk = 0;
        IEnumerable tmp = new[] { (byte)0x00, (byte)(chunk++ % byte.MaxValue) };
        Chunks.Add(tmp.Concat(allBytes.SubArray(position==0?2:position, Math.Min(chunkSize-2, allBytes.Length - position))).ToArray());
        position += chunkSize-(position==0?0:2);
    } while (position < allBytes.Length);

And we are already generating valid chunks to use.

Reflashing mode

Here is an analysis of the raw USB data for an upgrade to 0.30 firmware from 2013/08/09, captured by someone else.

Tools: USBpcap on Windows for capture; Wireshark and hte (or any other hex viewer/editor) on Linux for interpretation.

Additional information: SCSI_command‎ (Wikipedia) and pages linked from that one.

Details anzeigen