...ceci expliquerait que je n'arrive pas à gérer les infos "sollicitées"...@ suivre
Ce qui m'étonne est que dans la première version que j'utilisais, à 9600bauds on était sans arrêt en train de dialoguer avec l'elm.
Soit en coupant volontairement le flux reçu (et il fallait attendre que ce flux se tarisse), soit à cause d'un "buffer full".
On lançait alors une demande de masque, filtre et puis redemande du flux.
J'avais constaté que les demandes que l'on faisait partaient
en même temps que l'on continuait à recevoir, jusqu'à ce que l'elm soit informé de notre demande.
Ca marchait. Il fallait juste le faire dans la fonction Timer, pas dans ParseCanMessage ni dans MSCommCAN_OnComm, pour cause de ré-entrance qui faisait déborder la pile Vb6 au bout de pas mal de temps.
Si besoin je peux t'envoyer cette source.
Dois-je comprendre que tu redescend à un niveau + proche de l'Api windows, comme les proc en C ?
@Palm35: La question est d'importance:
Le prog PriusCanMonitor actuel fonctionne en écoute seulement. (Priusfan essaye de combiner le mode écoute et le mode sollicité)
Il reçoit plein d'infos. Chacune est identifiée par un code appelé Pid.
Il y a un Pid par exemple pour le niveau du réservoir.
Certains Pid sont parfaitement identifiés, càd que l'on est sûr de leur rôle.
Il en reste pas mal non identifiés, de plus parmi ceux qui sont connus il reste encore des infos non décodées.
On ne sait rien de manière sûre par exemple sur MG1 et MG2, leurs échanges. Mal la position du Vvti.
A de telles recherches ils peut y avoir deux conséquences:
-simple connaissance plus précise du fonctionnement du Hsd, savoir par exemple comment Toy a résolu les problèmes d'équilibre de couple au démarrage/arrêt du thermique tout enroulant, phénomènes brefs. Cette connaissance a par exemple permis de changer le Pid utilisé pour la vitesse.
-recherche d'améliorations sur la conduite pour réduire la conso. C'est cette 2° piste qui m'intéresse le +.
Pour l'instant j'utilise les ampères_batterie, les tours/mn, plus la température_thermique. Rien ne dit que les Tr/Mn soient la bonne piste.
Par exemple sur trajet plat le mode surmultiplié_électrique est-il plus intéressant pour la conso que le pulse&Glide, malgré une faible vitesse du thermique.
L'idéal serait de connaître le
rendement du thermique, de la partie électrique
en temps réel.
Par exemple en ayant le couple du thermique (on a déjà les tr/mn) et la conso (qu'on a déjà).
Pour la partie affichage c'est le rendre le plus simple et rapide à consulter en roulant en choisissant les infos qui manquent actuellement sur l'écran de la Prius et qui servent au quotidien. Et si c'est joli c'est encore mieux.
Pour la partie mémorisations elle permet par exemple de comparer deux manières de conduire sur un trajet ou de comparer deux conducteurs ou deux véhicules.
Au départ je souhaitais simplement connaitre la conso sur le trajet quotidien en choisissant plusieurs variantes de trajets. Celui-ci étant court il fallait quelque chose de précis, plus que l'odb.
En conclusion je citerais ma signature "et si?" c'est à dire qu'on ne sait pas encore ce qu'on va découvrir ni si cela servira. Mais c'est sûr on avance.
A+
Seule différence, il est en mètres, et pas en pieds. Mais s'il y a des puristes, je peux en faire un en pieds également !
