usb_read_sync_timeout ne lit rien
Posté le 27/01/2024 16:00
Je suis en train d'essayer d'utiliser libfxlink avec gint, et et j'arrive pas à envoyer un message PC->calto proprement, car usb_read_sync_timeout timeouts(avec -8), mais usb_fxlink_handle_messages marche bien correctement, et reçoit l'header, mais juste pas les données.
Voici le code côté calto:
/* [envoi de message vers PC, avec usb_commit_sync à la fin etc...] */
if (!usb_fxlink_handle_messages(&reply)) return;
dclear(C_GREEN);
dprint(1, 1, C_WHITE, "message(%s/%s), %d B (per %d blocks)!", reply.application, reply.type, reply.size, reply.transfer_size); /* ici, les bonnes infos sont retournées */
dupdate();
buffer = malloc(reply.size + 1);
buffer[reply.size] = '\0';
int r = usb_read_sync_timeout(in, buffer, reply.size, false, &tm); /* in réfère au port PC->calto */
dclear(C_GREEN);
dprint(1, 1, C_WHITE, "read %d B", r); /* r est -8, donc timeout */
dupdate();
getkey();
/* [...] */
Voici le code côté PC:
/* [recu le message de la calto correctement et son application/type est correct] */
if (buffer) /* buffer est bien non-nul, et a taille bufsize */
{
printf("sending %lu B to calculator\n", bufsize);
fxlink_device_start_bulk_OUT(
device,
"test", "test", buffer,
bufsize, true
);
}
/* [...] */
Citer : Posté le 27/01/2024 19:25 | #
Après un peu de tests(en remplacant le read sync par un read async, -12 est retourné (qui est donc USB_READ_IDLE, donc il n'y a rien à lire (??) )
EDIT:
Corrigez moi si j'ai tort, mais fxlink_device_start_bulk_OUT n'envoie pas les données directement, et seulement les headers, pas vrai (si cela serait le cas, ca expliquerait bien mon problème) ?
Ah non.
EDIT 2:
Prétendre être fxlink côté PC (en envoyant un message de type fxlink/command) marche bien, la calto reçoit la commande parfaitement et y répond bien. Je suppose que c'est juste un probleme de timing, car le code dans usb_fxlink_handle_messages est censé lire les contenus de la même manière (mais sans timeout)
Citer : Posté le 28/01/2024 12:16 | #
Bon, copier le code de usb_fxlink_handle_messages pour le modifier(accepter directement mes requêtes) marche
Je sais pas pourquoi, et à ce point là, je vais pas continuer à débugger pour le savoir.
Citer : Posté le 29/01/2024 11:00 | #
J'ai pas encore eu/pris le temps de tester, désolé. Je peux déjà clarifier quelques trucs.
USB_READ_IDLE signifie qu'il n'y a aucune transaction en cours sur le pipe. La « transaction » est définie par ce qui est envoyé côté PC, spécifiquement la taille indiquée dans le transfert libusb. Donc si tu regardes le code de fxlink tu verras qu'une première transaction est faite avec juste le header, et ensuite dans le callback (juste au-dessus) fxlink essaie d'envoyer tout le reste des données sous la forme d'une seule autre transaction, mais peut le faire en plusieurs transactions si jamais l'envoi est incomplet pour une raison ou une autre.
Du coup avec ce protocole il n'y a pas de garantie que ton message fxlink arrive en une seule transaction. Donc le USB_READ_IDLE est tout à fait possible ("normal") si tu fais l'appel après avoir obtenu le header (ce qui, vu la façon dont c'est fait, termine automatiquement la transaction associée) mais avant que la transaction suivante ne démarre. Pour éliminer cette incertitude il faut utiliser le flag USB_READ_BLOCK ou directement une lecture synchrone.
Tout ça pour dire que le code d'erreur sur la lecture async ne révèle a priori pas de problème par rapport à la lecture sync.
J'allais te dire d'essayer la commande, puisque ça marche y'a déjà une base. L'API pour les messages personnalisés est testée mais pas beaucoup donc il est possible que quelque chose m'ait échappé.
Deux détails stupides : in c'est quoi exactement ? tm tu le recharges bien régulièrement ?
Je serai plutôt occupé cette semaine donc si tu peux me donner une archive testable (même si y'a d'autres trucs autour dans le programme) ça me permettrait de gagner du temps pour comprendre ce bug, par rapport à reconstruire un add-in et un exemple côté PC à la main.