Ce sujet est résolu.
| 1 | |
| Auteur | Messages |
|---|---|
| Oliv' | #1 Posté le 17/5/2010 à 20:42:00 |
| Bonjour, je débute en gambas et je tente de développer une application permettant de gérer le Mir:ror de chez violet connecté en usb. J ai d abord tenté d'utilser la libusb depuis Gambas grâce aux fonctions Library et Extern. Pas de souci pour les premières fonctions (initialisation), mais ça se complique fortement dès que l'on a besoin d 'utiliser les structures : pas le temps (ni les compétences) de tenter de créer une interface. J ai donc décidé d abandonner la gestion de l usb et je tente maintenant de récupérer les info qui m intéresse depuis le fichier système créé dans /dev. En effet lorsque je connecte le mir:ror, le système le détecte et crée le fichier /dev/hidraw0. En lançant en console un "hexdump /dev/hidraw0" je peux "voir" les infos transmises par le lecteur RFID (mir:ror). Je tente donc de lire ce fichier binaire via un " read #mon_flux, ma_variable" (après avoir ouvert le flux avec open). Jusque là pas de problème. Mon souci, c'est que je dois capturer 16 octets dans le flux. En utilisant un "long", j' arrive à capturer 8 octets (bien sûr). La fonction READ ne me permet pas d'utiliser directement un tableau de long (READ #mon_flux, mes_long[] me retourne une erreur !!). Si je lis deux fois le flux, j ai un message d 'erreur "fin de fichier". J'ai tenté de rediriger mon flux dans un PIPE, mais ça ne marche pas (je crois que j'ai blairé là ;-) ). J'ai également tenté de redirigé mon flux vers un pointeur (après lui avoir alloué 16 octet), mais impossible ensuite de lire le pointeur. une solution est sûrement l'exploitation d'un flux généré par le hexdump via un shell, une autre serait d'utiliser une interface en C, mais je préfèrerai une solution plus propre. D'où ma question (pas trop tôt hein ??) : comment puis-je récupérer 16 octets dans un flux que je ne peux à priori parcourir qu'une fois ??? Merci d'avance | |
| spheris | #2 Posté le 18/5/2010 à 09:35:00 |
 | Oliv', Un simple : dim recuptext as string EXEC ["hexdump", "-n",16] to recuptext te renverra l'info souhaitée sous forme de string.  |
| gambix | #3 Posté le 18/5/2010 à 12:21:00 |
Faire simple ! | tu les récupère dans une chaine et ensuite tu les converti ... non ? Read #flux, sChaine, 16 dans une chaine de charactère de moin de 127 caractère chaque caractère occupe 1 byte ... il te reste plus qu'a convertir la chaine en hexa ensuite Moins de texte dans une signature c'est agrandir son espace. |
| Oliv' | #4 Posté le 18/5/2010 à 12:32:00 |
| Merci Sphéris pour cette réponse rapide. C était bien une de mes hypothèses de solution de secours. Cependant, par "propreté de code" et puis pour etre sur que mon programme fonctionne sur un maximum de distributions différentes, je préfèrerais que le traitement ne soit pas lié à une commande shell (qui n est pass forcément présente sur tous les systèmes). Y a t il une solution 100% Gambas? | |
| gambix | #5 Posté le 18/5/2010 à 13:10:00 |
| Faire simple ! | a tu essayé ce que je viens de proposer ? Moins de texte dans une signature c'est agrandir son espace. |
| Oliv' | #6 Posté le 18/5/2010 à 13:59:00 |
| salut Gambix, j ai testé ta solution au départ, mais comme il s agit d un fichier binaire, l utilisation de variables de type string ne renvoie rien !! Ce fichier système reste en permanence à 0 octet. | |
| gambix | #7 Posté le 18/5/2010 à 14:13:00 |
| Faire simple ! | et Read #flux, sChaine, -16 ? c'est bizzard, ce n'est pas dépendant du type de donnée chargée mais d'un nombre d'octet recupéré.... donc il semblerait que tu n'ais jamais 16 octet Moins de texte dans une signature c'est agrandir son espace. |
| Oliv' | #8 Posté le 18/5/2010 à 14:37:00 |
| j ai un peu tout essayé pendant 2 jours, meme la fonction seek ne marche pas : quand je récupère les données dans un long (ce qui fonctionne pour les 8premiers octets) et que je déplace le curseur avec seek sur un flux équivalent, je récupère toujours les memes 8premiers octets (alors que hexdump m en renvoie bien 16). Pour ce qui est des fichiers binaires il me semblent bien avoir lu quelque part que l on ne doit pas utiliser de variables string dans le read : de toute façon ça ne marche pas. J avoue que je bloque franchement. Je vais peut etre rééssayer avec un pipe. | |
| gambix | #9 Posté le 18/5/2010 à 19:23:00 |
| Faire simple ! | essais de demander a Benoit Minisini via la mailing list fr Moins de texte dans une signature c'est agrandir son espace. |
| gambix | #10 Posté le 18/5/2010 à 19:30:00 |
| Faire simple ! | tu as de la chance ... car on viens juste d'aboder le sujet sur la mailing list mdr... bon je ne sait pas si ça peut t'aider : /read?fr]http://gambasdoc.org/help/comp/gb/byte[]/read?fr dim aMyBytes as Bytes[] Bytes.Read(#Flux,, 16) J'avoue que je n'avait pas connaissance de cette fonction car je ne l'ai jamais utilisée... comme quoi on en apprend tout les jours :)... même avec Gambas Moins de texte dans une signature c'est agrandir son espace. |
| Oliv' | #11 Posté le 19/5/2010 à 10:11:00 |
| merci Gambix, c'est exactement la fonction qu'il me fallait. Je l'ai finalement un peu adaptée en travaillant avec des short plutot que des bytes. Pour la déclaration il faut en fait instancier dynamiquement un objet : DIM aMyShort AS NEW Short[8] puis dans le traitement : aMyShort.Read(mon_flux,, 16) Et voilà je peux capturer autant d'octets que de besoin dans mon flux. Encore Merci à tous. | |
| 1 | |