See the end of the post for download links.

Over the past few weeks, as mentioned at http://tiplanet.org/forum/viewtopic.php?f=55&t=13240 and http://ourl.ca/19769 , I've been working on a toolkit for communicating with HP Prime calculators, strongly inspired by libti* for TI calculators, and unsurprisingly dubbed libhpcalcs. It can be downloaded from https://github.com/debrouxl/hplp .
Thanks to critor's USB dumps and tests (EDIT: and later, other persons' tests), we believe the code now works well enough for being beta-tested used by a wider public (on Windows, Linux and MacOS X)
While neither critor, nor I, believe that anything can make a significant dent into TI's market share because TI is too entrenched and has lobbying power, we're nevertheless trying to do something with the Prime... as it's clear that if nobody bothers, the Prime won't stand a chance to get widely used (chicken-and-egg problem).


"Toolkit for communicating with HP calculators" means that it's a library backend for people to build GUIs on top of it, but libhpcalcs itself is a GUI-less library, and its terminal-based test program is currently the only UI for using libhpcalcs...

Excerpt from the README about the library's current capabilities:

The code base does:
* support communication with a single Prime calculator connected to the computer. The communication is known to work with the "SDKV0.30" firmware version from mid-August 2013, but might not work with other older or newer versions, if HP performs backwards-incompatible changes in the protocol (like TI does);
* implement six operations (without _known_ bugs): ready check, get calculator information, receive screenshot, send file, receive file, receive backup, set date and time;
* provide a terminal-based UI: the test program "test_hpcalcs".

The code base doesn't:
* perform color conversion on PNG screenshots (libhpcalcs should depend on libpng to uncompress the files, and recompress them after mangling);
* provide a way to select one of multiple HP calculators (probing USB devices);
* provide a user-friendly GUI for the above, but a GUI can definitely build upon the library easily enough;
* implement _proper_ conversion from UTF-16 LE to other charsets on its own: that's a task for libicu, Qt or other libraries;

What's next ?
* first of all, making sure that people are interested in the work in the first place. I'm clearly not going to keep spending most of my free time (as I did over the past week) on something people do not find useful ! [EDIT a couple weeks later: seems that some people are interested ]
* fixing bugs which are bound to be reported, none are known right now but there certainly are some
* implementing several extra features from the TODO list embedded into the README, starting with probing devices;
* implementing a GUI for the program (with Qt, which has become the main choice for a portable, good-looking, fast UI toolkit and software abstraction layer)... but I don't plan on doing it by myself, although I'll obviously gladly support anyone trying to do so.
* implementing 39gII support ?
* certainly more... again, iff people are interested.


Go forth and test, thanks in advance


Development source code: https://github.com/debrouxl/hplp (master branch is stable, master2 contains changes for testing, which may be rewritten before integration to master).
Ready-made install script: https://raw.github.com/debrouxl/hplp/master/install_hplp.sh . Unless your distro packages hidapi (Debian and derivatives do not), you'll have to compile it yourself (autotools-based program, so configure && make && sudo make install).
Latest Windows binaries + source tarball: http://tiplanet.org/beta/libhpcalcs-0.0.1-package.zip .

Also, I'm looking for 39gII users who can tolerate command-line tools, for providing me USB dumps (usbpcap) from their Windows computers when running the HP Connectivity Kit, the way critor did for the Prime.

[latest EDIT: 2013/11/16]

I will probably try to test it when I have some time, providing that it isn't command-line based,

test_hpcalcs is terminal-based, though interactive.
There's mild point in spending time developing a GUI for some code backend nobody cares about in the first place - and so far, hardly anybody cares about libhpcalcs: no reply on TI-Planet (where I posted a week ago), no reply on Cemetech, only your reply here, and a single beta-tester (besides critor) so far.

isn't a major PITA to install and doesn't require 2000 dependencies

Well, I provided ready-made Windows binaries, just unzip the ZIP file attached to my previous post
libpng needs to be added as a dependency at some point... but only if the program has actual users. For now, that's not a given.

Sounds pretty good to me. Since I'm on Linux and I plan on getting a Prime, it's a no brainer for me. I'm willing to help develop a GUI for it once it's matured, but a set of CLI progs in the titools style would be cool too.

I have fixed several bugs reported on TI-Planet, and performed large changes on error codes, which I had started before the bug reports. The code base doesn't seem to be completely broken, according to critor's tests (upwards propagation of errors was already mostly done).
For now, until further testing, changes were pushed to a new "master2" branch. You need to pull and explicitly checkout the branch to be able to test the new changes.

New Windows binaries + source tarball (hopefully) attached.

Thanks in advance

[EDIT: removing extraneous file, I attached it twice]

Thanks.

3: in fact, the calculator produces only PNG images, and one needs to enter 8, 9, 10 or 11 to get screenshots in two resolutions and color depths (all of which need unimplemented color conversion). But only the source code tells that story...

6: could you send me the "trace.txt" file which was created in the same folder ?
Lack of user feedback about operations which are longer than a second or two is a major utilisability no-no, but I haven't implemented any form of progress callbacks yet. When I do, the callback system will be different from that of upstream (EDIT: I mean libticalcs).
Finally, backuping a calculator is slow, due to HID being slow, I can't do anything about that.

In fact, test_hpcalcs is only a test client (derived from test_ticalcs_2), aimed at making small tests and showing how to use the library's functions. If it were to stay the only user-facing tool, it would badly need some documentation indeed. The library aims at being the backend for higher-level GUI and CLI tools; I just hope someone will take on the task of writing a GUI for a backend which largely works...


Offline, I have started implementing error messages and i18n, but I don't think i18n actually works yet, and I think I know why.

The trace shows that there have been a number of silent packet losses during transfer. Besides being fundamentally slow due to usage of HID and delays (even if seemingly still too fast for Windows' crappy USB stack on your computer - maybe some driver or anti-virus is interfering, as Tim Wessman doesn't witness slowness to the extent you do ?), the protocol used by HP isn't robust wrt. packet losses...
The computer sends increasing first bytes, but the calculator does not, so packet losses are harder to detect when the calculator is the sender (more precisely, it's basically impossible detect where data was lost, without more intimate knowledge of formats).

This means that I'll have to rewrite recv_backup functionality.
While triggering recv_file in a loop works most of the time, it falls apart if there are any packet losses. Receiving as much data as the calculator sends, then attempting to split it after the fact, would make it possible to salvage more data, though the heuristics might fail in very infrequent cases.
Another usability problem with the current recv_backup implementation is that in case of an error, it destroys any data received from the calculator before returning to the caller. Users would probably rather have partial, corrupted backups than nothing


To reduce the risks of your largest programs being lost as a result of a combination of transfer failure (induced by packet losses, statistically more likely on large programs) + calculator-side bugs (some of which require erasing stuff through the maintenance menus), you'll have no choice but to split them somehow. I don't know how.

On a side note, I might try to get new batteries to put in my 39gII so if you need an USB dump and have good instructions on how to do it, I think I have three days off this weekend so maybe I could do one.

This is in response to http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/forum.cgi?read=256650#256650 , but since I am unable to register there, I had to reply here.

Due to Lionel being now banned from Omnimaga, further comments about HPLP adressed to the author will have to be posted on TI-Planet in the matching topic:
http://tiplanet.org/forum/viewtopic.php?f=69&p=152761#p152761

Don't worry, all the team speaks english there too