PCM pour MBED

thierryb

Participant hyperactif
Inscrit
20 Janv. 2011
messages
1,968
Score de réaction
1,032
Localisation
Yvelines
Véhicule
Prius 2 sol pack ipa 2008 verte
Après avoir eu mon MBED grâce à priusfan, j'ai commencé un portage rapide de PCM.

Cela commence à marcher. Sauf que pour l'instant les données arrivent plus vite que je n'arrive à les traiter. Il faut que je change la façon de bufferiser les données. Car tant que le buffer est bas, tout va bien. Mais s'il grimpe de trop, alors il finit par exploser.

J'ai aussi à régler le cas des multitrames qui m'arrivent en une trame maintenant.

Donc il y aura bientôt un PCM pour MBED.

Ensuite je repars sur le projet TripMaster 2013. Le Rallye s'annonce. Et je suis dans la région (pour encore 2,5 semaines) pour faire des essais grandeur réelle. TripMaster 2013 sera indépendant de PCM, réécrit de zéro, et basé sur MBED pour la remontée des données de la Prius.
 
Je doute sur le décodage de cette trame
7EB2161CE6B800186368632863386318634863086338630862F86308631862E8632863300
planétaire, priusfan, ou un autre, pouvez vous me confirmer ?
cela concerne les 14 accus nimh

mon interprétation est que les 14 tensions commencent au 8636

qu'y a-t-il au début dans 6B8001 ?

Et pour priusfan :
ne trouves tu pas bizarre cette façon de répartir les requêtes ?
Code:
Line 15600: 7EB2161CE6B800186378632863386318634863086338631862F86318631862D8633863300
Line 15924: 7EB2161CE6B80018636863386308631863586308631863086328631863186318630863300
Line 16438: 7EB2161CE6B800186368632863386318634863086338630862F86308631862E8632863300
Line 42822: 7EB2161CE6B8080862B862A862B862E86258627862A862A86268626862A862C8627862A00
Line 43147: 7EB2161CE6B807F862B8628862C862C86278626862B862B86238627862B86298627862900
Line 43682: 7EB2161CE6B8080862B8629862C862C86298627862C862B86238626862B86288627862900
Line 47981: 7EB2161CE6A8001862B862C862E862B86298628862C862D86278629862C862E8629862C00
Line 48954: 7EB2161CE6A80098630862C862C862C862B862A862C8629862C862B862B862B862D862D00
Line 49599: 7EB2161CE6A80D5862B862886298628862A86268629862786298625862986258626862800
Line 64685: 7EB2161CE6A80008600003FFF0FA0000000000000008087416200800061605D5E6E008079
Line 64690: 7EB2161CE6A80008600003FFF0FA0000000000000008087416200800061605D5E6E0080797A4B4A01800000
Line 64693: 7EB2161CE6A80008600003FFF0FA0000000000000008087416200800061605D5E6E0080797A4B4A0180000000000000000000
Line 64699: 7EB2161CE6A80008600003FFF0FA0000000000000008087416200800061605D5E6E0080797A4B4A018000000000000000000000000000000000
Line 64789: 7EB2161CE6A8000862A86288627862C862886268629862B862686268629862A8622862900

elles sont réparties bizarrement.
et tu noteras que certaines sont malformées
il faudrait que je vérifies que j'en ai des mal formées en log 1 Pc
 
1ère remarque: il y a des lignes corrompues....

la découpe correspond à cela:

7EB 21 61 CE 6B 80 01 86 36 86 33 86 30 86 31 86 35 86 30 86 31 86 30 86 32 86 31 86 31 86 31 86 30 86 33

21 : nb octets (33 dec)
61 CE réponse à 21 CE
6B: SoC
80 01 courant
le reste 14 couples correspondant à la tension de chaque bloc

voir détail ici
pour info, Ian HAWKINS, le développeur de Torque, a utilisé ma méthode de décannage, mais a commencé à affecter les colonnes du tableau à partir des données utiles, càd que la variable A correspond à 6B etc...

dans le programme de mbed, je te suggère de modifier la trame de FlowControl et d'utiliser:
char msg_Continue[8] = { 0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; // Continue Receiving Additional Data
cela supprimera des tempos inutiles...
 
Je verrai pour le flow control.

Pour l'instant j'ai PCM qui fonctionne pour 90 % des données. Ma gestion de la communication avec le MBED ne me plait pas encore même si je n'ai plus le problème que j'avais hier. Je donnais trop la priorité à la récupération des données du mbed, par rapport à l'utilisation des données. En faisant l'inverse, j'ai maintenant quelques trames corrompues, en particulier quand j'atteins la limite du buffer du port comm de Windows qui semble être à 8000 caractères. Pour l'instant, j'arrive à détecter suffisamment les trames corrompues pour éviter que PCM plante. Je serais d'avis de mettre un caractère de contrôle comme sur les trames passives. Mais il faudrait aussi que je trouve le bon algorythme , et surtout le bon rythme, de communication avec le mbed par rapport à celui de l'utilisation des données reçues.

J'ai aussi réglé un autre problème, la bonne fermeture du port com avec le mbed, sinon il fallait faire de la gymnastique avant de pouvoir se reconnecter.

priusfan, je suis tombé sur un autre os : si on met plus de 15 filters, on a un buffer overflow dès le 16 ème du coté du mbed
 
1
dans le programme de mbed, je te suggère de modifier la trame de FlowControl et d'utiliser:

cela supprimera des tempos inutiles...

c'est l'équivalent de ça ?
Emet_Pid(&HE0, &H30, &H0, &H0)

Pourquoi mettais-tu un 8 avant ?
 
au sujet du FC, il y a eu une discussion à partir de ce post
j'avais procédé à plusieurs tests et laissé cette valeur de 8.

0 marche (au moins) aussi bien pour moi...


au sujet de la limitation en nb de filtres, je n'ai pas été confronté à ce pb, car en gen3, il y a fort peu de besoins.
je vais procéder à une recherche sur les filtres du CAN sur LPC1768, mais sans grand optimisme, Yoshi était le premier et le seul à adapter un truc pour mbed.
il me semble toutefois qu'on pourrait en installer au moins jusqu' à 128...

edit: en fait, il ne s'agit peut-être pas d'un pb de filtre, mais tout simplement d'une saturation, càd pas le temps de traiter suffisamment rapidement les trames acceptées.
est-ce reproductible? est-ce que cela arrive également en ajoutant des filtres sur des trames à faible périodicité?
 
ajouter n'importe quelle trame semble créer le problème.
mais je vais vérifier

j'ai un autre problème, difficile à détecter, mais le pid 230 le permet. J'ai des trames qui s'inversent (ce pid ne devrait qu'augmenter)

Line 26612: 2303E7402000000ED
Line 26629: 2303E7602000000EF
Line 26644: 2303E8202000000FB<---
Line 26647: 2303E7702000000F0<---
Line 26665: 2303E8302000000FC
Line 26684: 2303E8402000000FD
Line 26702: 2303E8602000000FF
Line 26720: 2303E870200000000
Line 26738: 2303E890200000002
Line 26757: 2303E8B0200000004
Line 26775: 2303E8C0200000005

cela m'arrive très fréquemment
est-ce du à ma lecture par PCM du MBED, ou à ce que moi j'envoie du MBED, ou aux données que je récupère dans le MBED pour les envoyer ? il me reste à investiguer.
il faudrait que je regarde si j'en ai en log = 1
 
curieux ton truc de séquence non respectée...

avec le 230 (un des rares communs entre gen 2&3), je suis certain de ne pas avoir rencontré ce pb.
en effet, j'ai passé pas mal de temps à l'analyser, à partir de logs brutes issues de mbed, pour vérifier les hypothèses de kinetik.

amha, un petit souci de vidage de buffer avec windaube
 
pour être plus sur, je vais ajouter au moment de l'envoi sur bluetooth à partir du MBED un index de trame sur 2 octets, et un CRC sur 2 octets pour les trames supérieures à 0x400, car en dessous elles en ont un par défaut. Comme cela j'en aurai le cœur net coté PC.
 
j'ai aussi modifié l'usage de la led4 qui reste éteinte, sauf en cas de buffer overflow.
et elle s'éteint à nouveau à la fin (sleeping == true)
 
la piste du bufferoverflow (BO pour la suite) est probablement la bonne:
aprés un BO , comme rien n'est réinitialisé, on va exploiter le RingBuffer n'importe comment car les pointeurs de remplissage et vidage sont HS.

suggestion: 2 possibilités en bas de BO:
a) on arrête tout.
b) on le signale et on réinitialise le buffer et ses pointeurs.


ce qui est tout de même curieux, c'est ce pb de BO que je ne rencontre pas.
bonne idée d'utiliser la led4 (la led1 aurait également convenu).
 
Je confirme j'ai le BO tout de suite. Je le sais grâce au Led4 ;)
J'envoie aussi une trame avec le pid 001
Et je suis d'accord, c'est pas géré pour continuer. Néanmoins, il se débrouille pas si mal, puisqu'il m'a fallu le pid 320 pour m'en rendre compte.
Mais je vais le gérer. Je commence à comprendre le code. L'avantage, c'est qu'il n'y a pas beaucoup de lignes.

J'ai ajouté dans la trame envoyée en bluetooth l'heure en microseconde de la lecture de la trame, je l'écris en hexa sur 6 caractères ; et j'ai ajouté un CRC à la Can pour les trames supérieures à 0x3FF.

J'ai un problème avec mon slate 500, il lit trop lentement le buffer bluetooth. J'ai pas le problème avec le Ep121. Encore un autre problème à régler. Au pire je m'achète un dongle bluetooth pour voir si cela résoud le pb.
 
salut priusfan, peux-tu me dire à quoi sert le wdc?

J'ai un BO dès trois trames passives quand j'envoie mes données en bluetooth. Est-ce à cause du fait que je lis trop lentement de l'autre coté, ou est-ce que le débit est trop rapide coté CAN ? à suivre.

En attendant, je viens d'augmenter le ring buffer de 128 à 1024. C'est le max compte tenu de la mémoire du mbed. On va voir l'impact.

Je suis en train de voir comment mieux gérer le BO. Cela ne m'empêchera pas de rater des trames. Mais cela évitera qu'il m'envoie à l'arrêt de la prius des trames inutiles. La led4 m'aidera à savoir à chaque fois que j'ai un BO. Cela voudra dire 1024 trames (la taille du buffer) de perdues.
 
Concernant le watchdog, c'est cette partie que je ne comprends pas à quoi elle sert :

if (wdc < 10) {
sleeping = true;
firsttime=true;
led1!=led1;
wait(0.5);
 
wdc est le WatchDogCounter
en gros: c'est le compteur de trame traitées par seconde.

si ce nombre est faible, cela veut dire que le contact est coupé.
car,en fait, il y a toujours une activité résiduelle (au moins pendant un moment) sur le bus.

la partie de code qui t'intrigue a pour rôle d'utiliser un timer avant de retester plutôt que passer son temps dans la boucle.
quand le contact est coupé, en attendant de mettre un système de coupure automatique et complete de l'alim, j'ai mis ce truc pour diminuer la conso...
 
finalement ça coince à 1024, le max semble être autour de 400 pour que le mbed boote. Donc j'ai mis 256.
 
Je comprends de mieux en mieux le programme. Je gère maintenant correctement le buffer après initialisation, mais pas après le "sleeping" (arrêt de la voiture et réception des dernières trames). Mais cela devrait être réglé demain.

Avec 5 trames passives (030, 038, 039, 03B, 0B4), j'explore le ring buffer de 256 entrées, toutes les 150 trames envoyées en bluetooth, ou toutes les 600 trames envoyées en usb. Si je fais tous les calculs mais n'envoye rien, pas de pb de buffer (où je n'ai pas attendu suffisamment longtemps), et même en rajoutant les autres trames passives (j'en ai encore 10 autres).

Bref le goulot d'étranglement est là. Il n'est même pas dans la lecture de l'autre coté (coté PC).

Il faudrait que je vois si en réduisant la longueur des trames cela peut suffire, mais j'en doute fortement. L'autre solution est de sauter des trames : quoi faire par exemple de la connaissance du % de la pédale de frein toutes les 6 ms. Peut-être qu'une fois toutes les 500 ms devrait suffire, non ?

J'envisage soit de sauter des trames, soit mieux : faire la moyenne, en comptant sur combien de trame, et en faisant que cela s'adapte en fonction du nombre de trames passives demandées, ou mieux de la place restant dans le buffer.

A demain.
 
l'appli sur mbed n' a pas été conçue au départ pour simplement faire suivre des trames, mais pour envoyer/logger seulement des infos prédigérées; je n'ai donc pas été confronté à cette saturation.

je pense que le goulot d'étranglement actuel serait l'usage extensif d' opérations sur les strings: il parait que cela est assez consommateur en C
 
C'est codé. Il ne reste plus qu'à tester.
Mais pas de wifi ou de 3G près de la voiture.
Danc des nouvelles plus tard.
J'ai aussi installé sur le Pc un compilateur MBED offline, gcc4mbed. Cela devrait être pratique pour corriger en roulant (non, je plaisante)
 
un peu HS (mais pas trop)
j'ai contacté Gary GIDDINGS qui est assez actif sur le forum leaf http://www.mynissanleaf.com/ et qui a développé un interface à base de mbed
Bonjour Gary
hello from France
I contact you because I started also a project with mbed for extracting data on Prius Gen3.
I use only one CAN, but I make a lot of requests (110 / sec) and I receive multiframe answers.
I use a ring buffer and filters.
I use an external file for the parms.

the results can be stored on SDCard &/or sent using BT to any listening app.
or sent to a serial LCD (4x20) or a smartgpu

this app works fine and some friends are trying to adapt it for prius gen2

I will receive within 2 days an EV car; it is a Peugeot Ion (same as Mitsubishi i-Miev)

and I am planning to use my mbed platform to do the same kind of thing you did with the leaf.

I attach my mbed project; as I am not a C / C++ developer, maybe you will see strange things....



If you made a board, maybe some friends would be interested for buying.

excuse my bad english and sorry if I disturbed you
[FONT=Times New Roman, Times]François-Xavier MOYA [/FONT]
et voici sa réponse:
[FONT=Times New Roman, Times]François,
[/FONT]Merci for sharing your Mbed project.
I will look at it when I get more time.

Exciting to get an EV, when does it arrive?

My Mbed project reads from two CAN buses, but does not
send any requests to the LEAF. Mostly, that is because
most of the send-and-reply information is not (yet) known to us.

I do not have experience with the MiEV, but there is a Quick Charge
station at the Mitsubishi Headquarters about 30 miles from me.

Keep in touch and we might be able to help each other.

In my Mbed program, I can write a log file to a Flash Drive or an
SDHC card in a USB adapter (on the D+ D- USB port).
I can also send the CAN-Log data to my CAN-D0 application
on the PC, via the mini-USB plug of the Mbed.

What I would like to do in Mbed is use a hub on the USB (D+/-) port,
and support writing to the Flash/SC and read from a USB
virtual serial-comm-port GPS device (about $30 from Amazon).

CAN-Do already supports the GPS to add selected GPS data to the Log file
as pseudo-CAn messages.

Are you using CAN-Do to read your Prius Log files?
CAN-Do is not LEAF specific, but it is CAN oriented.

Please try it with the sample Logs (from the LEAF) from
www.wwwsite.com/puzzles/cando/

Thanks for the contact.
The more working, the more fun it is.
Cheers, Gary
@suivre
 
Bien, bien, bien

CA MAAAARCHE

Pour pcm, j'ai besoin de pas mal de pid.
En enlevant les octets inutiles, j'arrive à faire passer 800 trames par seconde. Je pourrais même monter à 1200 trames. Après buffer overflow assuré.

Le MBED lit ces trames à la vitesse de 1 toutes les 8 microsecondes, mais pour la traiter et la renvoyer il lui faut, avec la meilleure version de mon calcul, 703 micro secondes.

J'avais un problème avec ta routine d'économie d'électricité (wait 0.5), car attendre 500000 microsecondes faisait remplir le buffer. Cela faisait 400 trames si je n'avais pas de chance. Bon il est vrai que mon premier calcul était aussi responsable, il prenait 2200 microsecondes par trames, et ne permettait de passer que 450 trames par secondes pour 800 qui arrivait. Buffer overflow assuré.

J'ai souffert. Mais je suis content.
 
...
Le MBED lit ces trames à la vitesse de 1 toutes les 8 microsecondes, mais pour la traiter et la renvoyer il lui faut, avec la meilleure version de mon calcul, 703 micro secondes.
... J'ai souffert. Mais je suis content.

Super. :youpi: 8 microsecondes c'est hyper-super-méga rapide. S'il ne faisait que cela il passerait son temps à attendre, on n'a "que" 1600 trames passives par seconde !

Pour accélérer les calculs on trouve toujours des astuces. Cela peut par exemple aller jusqu'à dupliquer des instructions plutôt que de boucler.
On augmente la taille du programme au profit de la vitesse d'exécution.
 
Super. :youpi: 8 microsecondes c'est hyper-super-méga rapide. S'il ne faisait que cela il passerait son temps à attendre, on n'a "que" 1600 trames passives par seconde !

cela ne servirait surtout à rien. Car si c'est pour les jeter ensuite, car le buffer ne tiendrait meme pas 0,3 seconde.

Mais effectivement, heureusement qu'il passe peu de temps là, car il m'en reste suffisamment pour les renvoyer en bluetooth.
 
Nouvelle version: je stocke quelques données en local. Pour l instant, une ligne par démarrage/arrêt : distance, litre, température. Je vais ajouter d autres données sous peu comme la 12v au démarrage, le Soc au démarrage, ...
 
ajouter n'importe quelle trame semble créer le problème.
mais je vais vérifier

j'ai un autre problème, difficile à détecter, mais le pid 230 le permet. J'ai des trames qui s'inversent (ce pid ne devrait qu'augmenter)

Line 26612: 2303E7402000000ED
Line 26629: 2303E7602000000EF
Line 26644: 2303E8202000000FB<---
Line 26647: 2303E7702000000F0<---
Line 26665: 2303E8302000000FC
Line 26684: 2303E8402000000FD
Line 26702: 2303E8602000000FF
Line 26720: 2303E870200000000
Line 26738: 2303E890200000002
Line 26757: 2303E8B0200000004
Line 26775: 2303E8C0200000005

cela m'arrive très fréquemment
est-ce du à ma lecture par PCM du MBED, ou à ce que moi j'envoie du MBED, ou aux données que je récupère dans le MBED pour les envoyer ? il me reste à investiguer.
il faudrait que je regarde si j'en ai en log = 1

J'avais évoqué ici des trames inversées, il me semble que j'ai aussi des trames en double et des trames manquantes. Ceci pourrait expliquer la bizarrerie concernant la consommation évoqué dans une autre thread (celle sur l'arrondi de la conso). Est-ce comme l'évoque Priusfan un pb de buffer en lecture coté Windows PCM ou est-ce un bug ou une limitation coté MBED CAN ? Ou encore un bug que j'aurais créé dans le ring buffer coté mbed en voulant contrôler le buffer overflow ? à suivre

Voici des traces du pid3C8 modifié, où j'ai entre autre mis à la fin les 6 derniers octets du timestamp en microseconde enregistré coté MBED au moment de la lecture du CAN.

3C8000000000000A049
3C8000000000001A052
3C8000000000002A12B
3C8000000000008A098
3C8000000000004A070
3C8000000000005A07A
3C8000000000006A085
3C800000000000CA323
3C8000000000008A098
3C8000000000009A0A4
3C800000000000BA0B9
3C8000000000012A296
3C800000000000DA0CC
3C800000000000EA0D7
3C8000000000015A11E
3C8000000000010A0EA

le désordre est évident
on voit qu'il manque une entre celle à 2A12B et à 4A070, celle à 3AXXX, car ces trames arrivent toutes les 64 ms (0x10000)
cette trame semble être remplacée par une arrivant plus tard, la 8AXXX, qui du coup serait en double.
mais par contre la AAXXX, est manquante, et pas remplacée.

maintenant que je peux écrire sur la sdcard, je vais logguer un peu coté MBED ou faire au moins des tests.
 
Pages vues depuis le 20 Oct 2005: 308,349,118
Retour
Haut Bas