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) Smile
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:
Quote:
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 Smile]
* fixing bugs which are bound to be reported, none are known right now but there certainly are some Smile
* 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 Wink

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 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 in posts on Omnimaga and TI-Planet.

Thanks in advance Wink
Will you be adding a permanent file somewhere that will get updated so I don't have to play forum attachment tag? That was something that always frustrated me about Simon Lothar's Prizm documentation; I had to follow about 20 links through Omnimaga posts to make my way to the latest attachment.

This is superb work, Lionel; I'm glad that you undertook it!
Quote:
Will you be adding a permanent file somewhere that will get updated so I don't have to play forum attachment tag?

I guess so, when there are more versions.

Quote:
This is superb work, Lionel; I'm glad that you undertook it!

Thanks. For now, usage among actual users is slow to take off. I know it would take off faster if:
* I announced it on historical HP calculator message boards (but it's too early to do so, the code base still it's not completely ready yet);
* there were a GUI (but it's hard to justify spending extra time writing a GUI for something only very few people would use anyway).
Keep in mind that the MoHPC forums are filled with engineer types...

I'd post it up there at least, looks like a lot of people playing with the Prime there, that would be open to playing around with tool dev stuff.
KermMartian wrote:
That was something that always frustrated me about Simon Lothar's Prizm documentation; I had to follow about 20 links through Omnimaga posts to make my way to the latest attachment.


I know this is completely offtopic, but just in case you didn't know, Simon now hosts it at Casiopeia, in the archives section:
http://www.casiopeia.net/forum/downloads.php?view=detail&df_id=72

By the way (and still offtopic), a library like this one but for the Casio Prizm would be nice. It supports some interesting USB modes besides mass storage...
Lionel Debroux wrote:
* there were a GUI (but it's hard to justify spending extra time writing a GUI for something only very few people would use anyway).
Have you gotten to compare it to the functionality of the tools HP offers (or at least what GT Springer told me they will have)? If your offered a fast, small, cross-platform subset of those features, I could see it being quite popular indeed.
I think libhpcalcs already has the subset most Prime users care about (and provides it on Windows, Linux, MacOS X; FreeBSD could work, hidapi is supposed to work there as well):
* receiving files from the calculator;
* sending files to the calculator;
* receiving backups (even if the code could be made to salvage more data upon packet losses, it works);
* receiving screenshots (even if they need some post-processing, which is not implemented yet);
* synchronizing time with the computer's;
* getting some information about the calculator (including the firmware version), but the actual contents of the data packets are not decoded yet. I'd expect them to contain the amount of free RAM and free Flash, at least if the contents are similar to those of similar packets from TI graphing calculators.

With packet dumps from a 39gII, we could certainly add support for the 39gII to libhpcalcs. The libti* architecture is flexible enough to deal with e.g. a non-silent TI-85 through BlackLink / $4 cable, ParallelLink / $5 cable or GreyLink, and a Nspire through DirectLink, so it would be quite extraordinary if the libti*-inspired libhpcalcs (where I kept all of the layering) could not be made to deal with both the Prime and the 39gII.

libhpcalcs is now officially announced on MoHPC, BTW: http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/forum.cgi?read=256047#256047 .
The day before yesterday, CompSystems relayed a video of someone doing third-party communication with the Prime, so I tipped about libhpcalcs yesterday evening, in another topic. This morning, the other tool was officially announced by its author. It's written in C#, implements very little protocol, but has a rudimentary GUI.
I add my interest to this project; I may not have an HP Prime or other HP Calc, but I do plan on getting one in the near future. Keep up your awesome work, Lionel!
The code base is still progressing, slowly.

On the plus side:
* two new operations: 1) remote control of the calculator (though no header file documents each individual key code yet - basically, 0-50 for keys from top left to bottom right; add 51 for SHIFT + key, 102 for ALPHA + key, 153 for SHIFT + ALPHA + key), 2) sending chat to the calculator (not yet receiving chat);
* several bugs have been fixed;
* the README file has been improved with detailed instructions for Debian/Ubuntu/Mint and derivatives, courtesy of Jonathan Cameron on MoHPC.

On the minus side, among others:
* for now, users need to manually edit .hpprgm files to strip the metadata before "EXPORT <...>" at the beginning of the file (if any), otherwise the file is corrupted on the calculator side;
* no PNG color conversion;
* no 39gII support: higher-level protocol is largely the same, but lower-level protocol is different, and I haven't figured out how to send packets;
* no probing (well, not a problem until more than one model is supported, but probing will have to be added...)
* no GUI.

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 - see the README for a step by step procedure for Debian/Ubuntu/Mint and derivatives).
Latest Windows binaries + source tarball: http://tiplanet.org/beta/libhpcalcs-0.0.1-package.zip .
Sounds like very cool stuff, good work!
I'm bumping this thread (as well as the github repo) as I now have an HP Prime ready for developing on.

Firstly, tests fail on my calc. Action 1 fails. Action 2 fails with a 388, first 13 bytes are constant, after that change each send. Action 3 seems ok. Action 4 hangs. Action 5, 6 untested. Action 7 fails with a 388. Action 8, 9, 10, 11 works.

I'll be poking around the code, seeing what I can do with it. Do you know if there is a spot where the commands are detailed in terms of what is know about the HID-based protocol?

Version info:
DATA Version: V0.032.6030
OS Version: V0.032.6030
Released Version: V1.04
RCB VErsion: 00
Touch IC FW Ver: 26
Serial No: 4CY41701NS
ARMUboot: V16
Well, the best existing public documentation about the protocol is the libhpcalcs source code...
It's been over a year since I last used my own Prime (real or virtual) for the purposes of communicating with it through libhpcalcs. The changes for improving communication support with the firmware from May 2014 were contributed by Daniel Mewes.

One easy operation whose binary value is known, but is not provided by libhpcalcs, is the "switch from HID mode to the firmware download mode", because the latter is entirely unsupported by libhpcalcs. It requires full-blown libusb for the detection and transfer.
A sub-page of https://tiplanet.org/hpwiki/index.php?title=HP_Prime contains the only existing, incomplete documentation of the firmware transfer protocol.

* it's odd that Ready and Get Info don't work, they are pretty basic commands which worked from the get go;
* get screenshot is only partially implemented. One would need to use libpng (1.2 API only, for compatibility: Debian still only has 1.2) to uncompress the PNG to raw pixels, swap two color components, and rewrite a PNG with proper colors;
* send file needs to be made to strip the program header, which is a chunked binary: (size of chunk, contents of chunk) pairs. I got a partial patch for this on the master2 branch.
* receive backup can fail all too easily due to those frequent packet drops. It needs to be made more robust, by reading as much data as possible, then salvaging the contents if possible, and providing per-file integrity information to the caller. I also got a partial patch for this on the master2 branch.

Testing against the Prime Virtual calculator is an invaluable help. You'll find a broken patch for communicating with it through a named pipe... on the master2 branch, you guessed it Smile
The reading/writing behaviour was reverse-engineered through a locally patched Wine. Using ReadFile is a relative pain. Flushing doesn't occur properly in case of an error, or closing libhpcalcs, requiring a restart of the virtual calculator.
Prime rebooted, action 1 works. I need to investigate, but the USB packet is different now (seems correct, before the packet was much longer, but didn't record it). I'm setting up wiki pages documenting the packet format and hopefully commands.

For MSD, do you know if there is a dump of communications from usbpcap? I want to look into this part.

Also, do you know how to get the calc to enter MSD mode?
Quote:
For MSD, do you know if there is a dump of communications from usbpcap?

Yes, but not publicly available right now. It's also over two years old and multiple firmware revisions back, so my advice would be to obtain a fresh dump of the firmware transfer protocol from the latest Connectivity Kit version, and to proceed documenting that Smile

Quote:
Also, do you know how to get the calc to enter MSD mode?

Command 0xE8, AFAICS in another dump file.
I have a pcap dump of the reflashing progress, showing 0xe8 issued.

Also, commands may be queued on-calc as I see the conn. kit sends the set of initial commands as fast as possible, no waiting for replies.

I won't post the dump of the firmware flashing because, well, that has ROMs, but I'll analyze it and test the calc. I can post the other dumps that I have been capturing (besides what I have posted on the talk pages on my wiki).
Sounds good.

One of the things currently missing from the libhpcalcs code base, besides progress information, is an infrastructure for logging and dissecting packets. Both progress information support and logging / dissection support should be improved from what's available in libti*.
Are there any known issues with the latest OS and libhpcalcs? Calc probing is failing with my Prime now (Ok with Conn Kit). I see it registers as a USB HID with dmesg, so that looks ok, will have to look at the probing code.
AHelper wrote:
I'm setting up wiki pages documenting the packet format and hopefully commands.

Good thing you mention that, your account still needed (oops) to be validated on the hpwiki website. It's now OK Smile
adriweb: Wait, I already got an email and was editing pages on there o_O Anyways, account looks good to me Smile

Anyways, I'm trying to think about a cross-platform firmware flashing tool. I'm thinking of having a Python script issuing reads/writes to the calc. Possibly reading in a file that specifies how to flash it (Like, read n bytes from x offset into abc.ROM to LBA=0xABCD1234, etc.) that would let installing a new OS easy.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement