PIC lecture trame série 1200bd

[cubitus_54]

Bonjour,

J’essaie de lire les données issues d'un compteur électrique (Lanis Gys) avec un PIC 16F1847 pour affiché les informations de consommation.

Je pensais la manipe facile et finalement j'ai pleins de problèmes.

Le compteur générer une trame en continu à 1200 bd d'une longueur d'environ 140 octets

Le 1200 bd c'est lent et pour obtenir cette vitesse de transmission j'ai déjà du passer le PIC de 32MHz à 16MHz.

La trame fait dans mon cas 141 octets et il n’y a aucun temps mort entre deux octets transmis.

Je viens d'essayer un simple truc :
tant que 1
Lecture du mot série par fonction software (il n'y a qu'un usart dans le PIC) et renvois sur l'usart du PIC en 9600 bd
fin tant que

Les deux premiers mots sont corrects et la suite est fausse un peu comme s'il loupait un bit sur les 8 à transmettre...

Vous avez une idée pour résoudre ce problème ?
-----

[adipie]

Bonjour,
1200 bauds 7 ou 8 bits, avec parité paire ou impaire,sans parité et nombre de stop bits ?
Il semblerai que ce soit: 1200 bps, 7bits/caractères, parité paire et 1 bit de stop.
Télécharge Realterm sur un PC (vieux coucou avec port Com) et analyse la trame.

[cubitus_54]

Salut,

Oui c'est du 1200 7 E
J'ai mon scope pour analyser la trame...

Je viens d'essayer cela :
Lecture de la trame via l'uart hardware.
Masque 0x7F (l'uart est en 8 bits sans parité)
Émission en 9600 bd avec l'uart software

La trame semble correcte, mais cela me laisse peu de temps pour du traitement entre deux réceptions...

[kevin8z]

La trame semble correcte, mais cela me laisse peu de temps pour du traitement entre deux réceptions...

Il te faut obligatoirement toute les trames émises par ton compteur?
Sinon pourquoi ne pas faire l'acquisition de 140 octets, puis de faire du traitement, et une fois fini tu relis 140 nouveaux octets?

[A voir en vidéo sur Futura]

[cubitus_54]

Oui j'ai essayé...

La taille des variables est limitée par le PIC à quelque chose comme 90 octets d'un seul tenant.

La trame peut être plus longue selon les options du compteur heures creuses, heures pleines...
Je vais essayer de faire un tri à la volée.

Je suis en train d'essayer avec un afficheur intelligent piloté en série jusqu'à 115000 bd... a voir

[kevin8z]

La taille des variables est limitée par le PIC à quelque chose comme 90 octets d'un seul tenant.

La trame peut être plus longue selon les options du compteur heures creuses, heures pleines...

Et faire un tableau dont la taille sera le nombre d'octet maximum à recevoir?

[cubitus_54]

Oui ça peut fonctionner...

Je vais tester cela ce soir... c'est apm au boulot

[paulfjujo]

bonjour,

J'ai fait une appli pour lire mes donnees compteur EDF, et été confronté au probleme dû au tres faible delai inter trame
on dispose de moins de 100mS entre chaque trame emise à ~ 1seconde
et mon affichage sur nokia + stoclage sur eeprom + autres datas analogiques pour envoyer en BlueTooth
generait plusieurs problemes.
J'utilise donc 2 tables :
1 pour la reception en mode interrupt UART2 à 1200,7,E,1 L'IT Arme un flag sur la reception du car EOT que je teste dans le main
1 autre que je remplis avec les donnees de la 1ere ,auquel je rajoute mes autres donnees , puis affichage Nokia ..etc .. je dispose alors de 1000mS pour faire cela..
actuellement je stocke 1 trame par minute dans l'eeprom du PIC (trame de 128 octes)
et toutes les 8 minutes je transfert sur un fichier TXT sur SD CARD 2Go pour le suivi à long terme.(mise au point en cours..)

Details à disposition ICI

[cubitus_54]

Salut,

J'arrive à afficher les données, mais je ne suis pas encore bien satisfait du hardware...

Pour le programme j'ai fait comme toi j'ai mis deux tables de 80 octets.

Pour la mise en forme, j'ai utilisé un monostable 4528 avec une base de temps de 40µs

J'ai utilisé le seconde monostable pour détecter les 8ms entre deux trames .

Bref il y a encore du boulot pour optimiser et afficher tout cela bien propre sur le LCD couleur

[paulfjujo]

j'ai mis deux tables de 80 octets.

je suis en Mono 230V tarif normal, donc pas de donnees HC HP ou tarif special
Ma trame fait 125 octets de long ! (buffer de 128 car declaré en reception)

tu n'es pas trop juste avec 80 car seulement ?

8mS seulement entre les trames ?

ADCO 049801282083 D
OPTARIF BASE 0
ISOUSC 30 9
BASE 040302197 %
PTEC TH.. $
IINST 003 Z
IMAX 023 D
MOTDETAT 000000 B

[cubitus_54]

C'est le modèle ZCD126.01 V2.1

J'ai bien 141 octets
J'ai mis deux tables 80 +80 160 octets maxi
20150324_110605.gif

Je confirme 8ms entre deux trames..

MSO4014_20150324-130410.png

[paulfjujo]

C'est le modèle ZCD126.01 V2.1
J'ai bien 141 octets
J'ai mis deux tables 80 +80 160 octets maxi
Je confirme 8ms entre deux trames..

tu n'as donc qu'une seule table de reception trame EDF ( de taille 2x80car)...

J'utilise de mon coté 2 tables : 1 de 128 car pour la reception , l'autre que je remplis des la reception de EOT , par les datas utiles de la 1ere , pour ensuite laisser la 1ere en reception.(en moins de 2mS)
j'ai donc ~1 seconde - (125 * IT RX) pour faire tous les traitements annexes necessitant du temps MCU ( 3 mesures ANA + gestion Nokia + envoi du tout en ascii à 19200 bauds sur l'autre UART -> BlueTooth)

J'avais essayé le decodage temps reel de la trame EDF avec 1 seule table de reception , mais constaté de nombreux ecrasement ( l'autre UART est à 19200 bauds)
principalement du aux delais important necessaire à l'affichage LCD et acquisitions analogiques( quelques mS par ci ou par là)...
J'ai essayé aussi le buffer circulaire ..mais encore quelques problemes..
finalement l'usage d'une double table : 1 reservé à la reception et 1 (copie), pour le traitement ,donne un confort en temps utile de traitement..

il y a aussi la solution de ne capturer qu'une trame sur 2 !

[cubitus_54]

J'ai un peu avancé.

Finalement je traite une trame sur deux (1 trame dure 1,2s) et j'ai supprimé les deux tables...
Je fais l'acquisition à la volée en utilisant un index et je remplis les variables BASE, IINST, PAPP.
Exemple pour BASE
Si (index > 58) AND (index < 68) alors j'enregistre les 9 valeurs de BASE

Si j'ai trop de mauvaise valeurs j'exploiterais l'octet de checksum

Sur la seconde trame, je fais le traitement et l'affichage.