π
<-
Chat plein-écran
[^]

libhpcalcs: a toolkit for communicating with Prime calcs...

Nouveautés, projets, mises à jour.

libhpcalcs: a toolkit for communicating with Prime calcs...

Unread postby Lionel Debroux » 03 Nov 2013, 22:15

See the end of the post for download links.


Over the past few weeks, as mentioned at viewtopic.php?f=55&t=13240 and http://www.omnimaga.org/index.php?topic=17172.0 , 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/ma ... ll_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]
Attachments
libhpcalcs-0.0.1-package.zip
OUTDATED Package containing Windows binaries and source tarball of the first public version OUTDATED
(485.23 KiB) Downloaded 42 times
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
User avatar
Lionel DebrouxModo.G
Niveau 14: CI (Calculateur de l'Infini)
Niveau 14: CI (Calculateur de l'Infini)
Level up: 5%
 
Posts: 6375
Joined: 23 Dec 2009, 00:00
Location: France
Gender: Male
Calculator(s):
Class: -
GitHub: debrouxl

Re: libhpcalcs: a toolkit for communicating with Prime calcs

Unread postby Lionel Debroux » 04 Nov 2013, 22:24

Je sais que je n'ai pas pris le temps de traduire en français, mais ce n'est pas comme ça que critor et moi allons pouvoir penser que les gens considèrent le code comme utile ;)

Enfin bref... http://www.hpmuseum.org/cgi-sys/cgiwrap ... 792#254792 et la réponse de Tim Wessman parlent du fait que le HP Connectivity Kit met l'heure de la calculatrice à jour. Le HPCK envoie toujours trois commandes quand il démarre, et vu que ce n'est ni le job de la commande 0xFF d'un seul octet (baptisée "check ready" dans libhpcalcs), ni le job de la commande 0xFA d'un seul octet ("get infos" dans libhpcalcs), c'est donc le job de la commande 0xE7, qui n'est pas encore documentée.

J'ai demandé à critor de dumper les paquets pendant qu'il ferme et ouvre plusieurs fois le HP Connectivity Kit. Voici ce que les paquets contiennent:
Code: Select all
00 e7 01 00 00 00 0a 00 00 54 1e 0d 0b 04 15 37 28
00 e7 01 00 00 00 0a 00 00 54 1e 0d 0b 04 15 38 1c
00 e7 01 00 00 00 0a 00 00 54 1e 0d 0b 04 15 38 38
00 e7 01 00 00 00 0a 00 00 54 1e 0d 0b 04 15 39 19
00 e7 01 00 00 00 0a 00 00 54 1e 0d 0b 04 15 39 29


Je n'interprète pas encore 00 00 54 1e, mais pour le reste, vu le moment auquel critor a fait les tests, et par comparaison avec des dumps plus vieux qui contenaient également des paquets 0xE7, les 6 derniers octets sont clairement [année - 2000] [mois] [jour] [heure] [minute] [seconde], tous les digits étant hexa.
Et l'opération va donc s'appeler set_date_time.
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
User avatar
Lionel DebrouxModo.G
Niveau 14: CI (Calculateur de l'Infini)
Niveau 14: CI (Calculateur de l'Infini)
Level up: 5%
 
Posts: 6375
Joined: 23 Dec 2009, 00:00
Location: France
Gender: Male
Calculator(s):
Class: -
GitHub: debrouxl

Re: libhpcalcs: a toolkit for communicating with Prime calcs

Unread postby Lionel Debroux » 09 Nov 2013, 22:26

persalteas a fait quelques tests sous Linux (qui m'ont permis de savoir qu'il y avait apparemment un problème, que j'ai corrigé) et m'ont rappelé indirectement qu'il n'y avait pas encore de script d'install ( c'est maintenant réparé, https://raw.github.com/debrouxl/hplp/ma ... ll_hplp.sh ), mais pour le reste, les gens s'en foutent pas mal, de la Prime, hmm ?
Je sais que pour avoir une chance d'avoir plus d'utilisateurs, il faut un GUI - mais si ça continue comme ça, personne ne fera de GUI pour un programme inutile.


Par ailleurs, je cherche des utilisateurs de 39gII qui peuvent tolérer les outils en ligne de commande, pour me fournir des dumps USB (usbpcap) depuis leur ordinateur Windows quand le HP Connectivity Kit communique avec la machine, comme critor l'a fait pour la Prime.
Attachments
libhpcalcs-0.0.1-package.zip
Nouveaux binaires Windows + tarball source
(491.27 KiB) Downloaded 39 times
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
User avatar
Lionel DebrouxModo.G
Niveau 14: CI (Calculateur de l'Infini)
Niveau 14: CI (Calculateur de l'Infini)
Level up: 5%
 
Posts: 6375
Joined: 23 Dec 2009, 00:00
Location: France
Gender: Male
Calculator(s):
Class: -
GitHub: debrouxl

Re: libhpcalcs: a toolkit for communicating with Prime calcs

Unread postby wawachief » 10 Nov 2013, 09:12

Bonjour et merci pour ce travail. Etant sous Linux ou Mac, c'est le seul moyen dont je dispose pour le moment pour dialoguer avec ma hp prime.
J'ai du coup installé la librairie et essayé test_hpcalcs.
J'ai réussi à récupérer une sauvegarde totale de la machine, à récupérer un screenshot, à envoyer un fichier.

Voici mes premières impressions :
- Lors de l'envoi du fichier du PC vers la prime, (un programme en l'occurence), un caractère a été ajouté en première position sur la prime qui provoquait une erreur de syntaxe. En le supprimant, le programme envoyé a fonctionné.
- Je n'ai pas réussi a récupérer un programme de la prime vers le PC avec Receive File : Je met le nom de mon programme sans l'extension, puis le type "PRGM" mais je récupère un fichier vide avec un nom bizarre.
- Lors de mes tests, j'ai planté totalement la prime qui ne répondait plus au clavier (même ON-Symb). J'ai du la relancer avec le bouton reset au dos. Il n'y a pas eu de perte de données. Je n'ai pas réussi à reproduire le phénomène donc je ne sais pas trop ce qui a provoqué ça.
- Dans le Get screenshot, quand il demande le format, si on rentre PNG, le programme devient un peu fou... J'ai du regarder les fichiers d'entête pour voir la liste des formats attendus.

Je vais maintenant essayer de compiler tout ça sur Mac...
Merci pour ce travail.
User avatar
wawachief
Niveau 4: MC (Membre Confirmé)
Niveau 4: MC (Membre Confirmé)
Level up: 50%
 
Posts: 44
Joined: 10 Nov 2013, 08:57
Gender: Not specified
Calculator(s):

Re: libhpcalcs: a toolkit for communicating with Prime calcs

Unread postby Lionel Debroux » 10 Nov 2013, 09:28

Bonjour,

Merci pour tes tests. Je sais qu'il y a des utilisateurs de Prime sous Linux ou MacOS X. Je toucherais un public plus intéressé sur MoHPC, mais vu que le programme est encore mal testé sous Linux (et que les tests montrent des bugs, sans surprise), je ne peux pas l'annoncer trop largement dans la communauté HP pour l'instant.

Lors de l'envoi du fichier du PC vers la prime, (un programme en l'occurence), un caractère a été ajouté en première position sur la prime qui provoquait une erreur de syntaxe. En le supprimant, le programme envoyé a fonctionné.

Ca veut dire que la longueur du nom du fichier est mal calculée, ça devrait assez vite se corriger. Quel était le chemin complet du programme, et quel était le caractère ajouté à tort au début ?

- Je n'ai pas réussi a récupérer un programme de la prime vers le PC avec Receive File : Je met le nom de mon programme sans l'extension, puis le type "PRGM" mais je récupère un fichier vide avec un nom bizarre.

Peut-être la manifestation du problème de lecture que je craignais avec scanf("%ls") :(
Il va falloir faire autrement...

- Lors de mes tests, j'ai planté totalement la prime qui ne répondait plus au clavier (même ON-Symb). J'ai du la relancer avec le bouton reset au dos. Il n'y a pas eu de perte de données. Je n'ai pas réussi à reproduire le phénomène donc je ne sais pas trop ce qui a provoqué ça.

Ca peut être dû au fait que la machine fait des bêtises si on lui parle mal... mais ça voudrait dire que le code de HP n'est pas bien plus solide que celui de TI (sur certains modèles du moins) :)

- Dans le Get screenshot, quand il demande le format, si on rentre PNG, le programme devient un peu fou... J'ai du regarder les fichiers d'entête pour voir la liste des formats attendus.

La machine ne produit que des screenshots PNG, en effet, et aucune conversion n'est implémentée pour l'instant.
test_hpcalcs, comme les autres morceaux, contient du code destiné à gérer les entrées clavier qu'il ne comprend pas, mais ça veut dire que ce code est insuffisant (il doit manquer un flush de stdin sur erreur) :D
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
User avatar
Lionel DebrouxModo.G
Niveau 14: CI (Calculateur de l'Infini)
Niveau 14: CI (Calculateur de l'Infini)
Level up: 5%
 
Posts: 6375
Joined: 23 Dec 2009, 00:00
Location: France
Gender: Male
Calculator(s):
Class: -
GitHub: debrouxl

Re: libhpcalcs: a toolkit for communicating with Prime calcs

Unread postby wawachief » 10 Nov 2013, 10:38

Ca veut dire que la longueur du nom du fichier est mal calculée, ça devrait assez vite se corriger. Quel était le chemin complet du programme, et quel était le caractère ajouté à tort au début ?


Mon programme de test est dans le dossier courant et s'appelle TestTux.hpprgm. J'ai donc tapé TestTux.hpprgm" sans préfixe de chemin. Au passage, sur la prime, je récupère l'extension également, donc dans la liste des programmes, j'ai TestTux.hpprgm au lieu de voir seulement TestTux.
Sur la prime, le caractère ressemble à un espace mais un dump hexa sur le PC montre que l’intrus est un "FF FE" en début de fichier.

Peut-être la manifestation du problème de lecture que je craignais avec scanf("%ls") :(
Il va falloir faire autrement...


C'est peut-être moi qui m'y prend mal. Voici le retour de console quand je fais un receive file

Code: Select all
Your choice: 5

Enter input filename (without computer-side extension): TestTux
Enter file type:PRGM
hpfiles DEBUG: prime_str2vartype: returning 6
hpfiles INFO: prime_send_data: q:0      r:12
hpfiles DEBUG: Dumping OUT packet with size 13
hpfiles DEBUG:     00 00 F8 01 00 00 00 06 06 02 69 56 54
hpfiles INFO: cable_prime_hid_send: wrote 13 bytes
hpfiles INFO: prime_send: send succeeded
hpfiles INFO: prime_send_data: send remaining succeeded
hpfiles INFO: cable_prime_hid_recv: read 64 bytes
hpfiles DEBUG: Dumping IN packet with size 64
hpfiles DEBUG:     FF 00 00 00 20 B4 6F 31 00 00 00 00 00 00 00 00
hpfiles DEBUG:     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
hpfiles DEBUG:     00 00 00 00 00 00 00 00 98 D7 68 31 4C EC 6C 31
hpfiles DEBUG:     B0 91 6C 31 2C 92 6C 31 CC 57 66 31 8C 58 66 31
hpfiles ERROR: prime_recv_data: skipping packet starting with 0xFF
hpfiles INFO: cable_prime_hid_recv: read 0 bytes
hpfiles INFO: prime_recv_data: breaking due to short packet (1)
hpfiles INFO: prime_recv_data: shortening packet from 0 to 0
hpfiles INFO: read_vtl_pkt: empty packet
hpfiles INFO: calc_prime_r_recv_file: packet is too short: 0bytes
hpfiles INFO: hpcalcs_calc_recv_file: recv_file succeeded
hpcalcs_calc_recv_file finished
Receive file success
hpfiles INFO: Displaying var entry 0x400af9
hpfiles INFO: Name: hpfiles INFO: Type: 0 (00)
hpfiles INFO: Size: 512 (200)
hpfiles INFO: Data: 0x2000000
hpfiles DEBUG: prime_byte2fext: returning

Au final je recois dans mon dossier un fichier de taille nulle dont le nom est "___r_________e___f______r_________________e___________d______________________s____7____4_____5"
User avatar
wawachief
Niveau 4: MC (Membre Confirmé)
Niveau 4: MC (Membre Confirmé)
Level up: 50%
 
Posts: 44
Joined: 10 Nov 2013, 08:57
Gender: Not specified
Calculator(s):

Re: libhpcalcs: a toolkit for communicating with Prime calcs

Unread postby Lionel Debroux » 10 Nov 2013, 11:04

J'ai donc tapé TestTux.hpprgm" sans préfixe de chemin. Au passage, sur la prime, je récupère l'extension également, donc dans la liste des programmes, j'ai TestTux.hpprgm au lieu de voir seulement TestTux.

Je l'avais corrigé pour Windows, celui-là. Mon code non-Windows doit être incorrect. La manipulation du nom du fichier fait partie des morceaux de code spécifiques plate-forme...

Sur la prime, le caractère ressemble à un espace mais un dump hexa sur le PC montre que l’intrus est un "FF FE" en début de fichier.

Ah, alors ce n'est très probablement pas un problème dans libhpcalcs. Un FF FE au tout début d'un contenu UTF-16LE est certainement la BOM: http://www.unicode.org/faq/utf_bom.html#BOM .
Dans l'immédiat, puisque cette BOM n'a pas l'air de plaire à l'interpréteur de la Prime, trouve un moyen de demander à ton éditeur de texte de ne pas l'enregistrer, ou supprime-la avec un éditeur hexa avant l'envoi. Je viens de marquer dans la TODO list qu'il faudrait filtrer une éventuelle BOM UTF-16LE au début du fichier pour certains types.

Voici le retour de console quand je fais un receive file
[...]
hpfiles DEBUG: 00 00 F8 01 00 00 00 06 06 02 69 56 54
[...]
Au final je recois dans mon dossier un fichier de taille nulle dont le nom est "___r_________e___f______r_________________e___________d______________________s____7____4_____5"

Les traces montrent que 1) je n'envoie pas le bon nom de fichier, 2) le cas où la calculatrice ne renvoie rien n'est pas correctement géré, 3) l'espace de stockage pour la variable n'est pas entièrement mis à 0 (ou bien il est redéfini plus tard).
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
User avatar
Lionel DebrouxModo.G
Niveau 14: CI (Calculateur de l'Infini)
Niveau 14: CI (Calculateur de l'Infini)
Level up: 5%
 
Posts: 6375
Joined: 23 Dec 2009, 00:00
Location: France
Gender: Male
Calculator(s):
Class: -
GitHub: debrouxl

Re: libhpcalcs: a toolkit for communicating with Prime calcs

Unread postby wawachief » 10 Nov 2013, 11:52

trouve un moyen de demander à ton éditeur de texte de ne pas l'enregistrer, ou supprime-la avec un éditeur hexa avant l'envoi. Je viens de marquer dans la TODO list qu'il faudrait filtrer une éventuelle BOM UTF-16LE au début du fichier pour certains types.


Tu as en effet raison, c'est mon éditeur (kate) qui a du ajouter le BOM en début de fichier car si je fais un transfert dans les deux sens sans éditer le fichier, je n'ai pas de caractère parasite.
User avatar
wawachief
Niveau 4: MC (Membre Confirmé)
Niveau 4: MC (Membre Confirmé)
Level up: 50%
 
Posts: 44
Joined: 10 Nov 2013, 08:57
Gender: Not specified
Calculator(s):

Re: libhpcalcs: a toolkit for communicating with Prime calcs

Unread postby wawachief » 10 Nov 2013, 12:57

Pour la compilation sur Mac, en utilisant Macports, je bloque sur le message d'erreur suivant :
Code: Select all
In file included from hpfiles.c:32:
./hpfiles.h:47:5: error: unknown type name 'char16_t'
    char16_t name[FILES_VARNAME_MAXLEN+1];
   
1 error generated.

Il semble qu'il ne connaisse pas le type char16_t mais ne vois pas trop quelle option passer pour régler le pb :(
User avatar
wawachief
Niveau 4: MC (Membre Confirmé)
Niveau 4: MC (Membre Confirmé)
Level up: 50%
 
Posts: 44
Joined: 10 Nov 2013, 08:57
Gender: Not specified
Calculator(s):

Re: libhpcalcs: a toolkit for communicating with Prime calcs

Unread postby Lionel Debroux » 10 Nov 2013, 13:01

Avec GCC et Clang, il faut utiliser -std=c1x (-std=c11 si ta version est suffisamment récente), comme le fait install_hplp.sh :)

Si ton compilo ne connaît pas cette option, ou qu'il la connaît mais ne sait toujours pas que char16_t existe, il faudra upgrader ton environnement de développement. Ca fait déjà un petit moment que GCC et Clang (ce dernier étant maintenant le compilo préféré d'Apple pour des raisons de licence) gèrent cette partie-là du C11, j'avais vérifié le support C11 pour ne pas (trop) embêter les utilisateurs :)
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
User avatar
Lionel DebrouxModo.G
Niveau 14: CI (Calculateur de l'Infini)
Niveau 14: CI (Calculateur de l'Infini)
Level up: 5%
 
Posts: 6375
Joined: 23 Dec 2009, 00:00
Location: France
Gender: Male
Calculator(s):
Class: -
GitHub: debrouxl

Next

Return to Actualités

Who is online

Users browsing this forum: No registered users and 0 guests

-
Search
-
Featured topics
Concours TI-Planet-Casio de rentrée 2019. 3 défis pour plus d'une 15aine de calculatrices graphiques et nombre de goodies sortant de l'ordinaire ! :D
Comparaisons des meilleurs prix pour acheter sa calculatrice !
12
-
Donations / Premium
For more contests, prizes, reviews, helping us pay the server and domains...

Discover the the advantages of a donor account !
JoinRejoignez the donors and/or premium!les donateurs et/ou premium !


Partner and ad
Notre partenaire Jarrety 
-
Stats.
424 utilisateurs:
>391 invités
>28 membres
>5 robots
Record simultané (sur 6 mois):
6892 utilisateurs (le 07/06/2017)
-
Other interesting websites
Texas Instruments Education
Global | France
 (English / Français)
Banque de programmes TI
ticalc.org
 (English)
La communauté TI-82
tout82.free.fr
 (Français)