2010-07-15 17 views
0

J'ai une connexion de données à très faible vitesse sur la série (RS485): 9600 baud taux de transmission de données réelles est d'environ 25% de cela.Correction d'erreur robuste simple pour la transmission de ASICI sur série (RS485)

La ligne série traverse une zone de DME extrêmement élevée. Les fluctuations de pointe peuvent atteindre 3000 KV.

Je ne suis pas encore en mesure de forcer un changement dans le support physique, mais je pourrais facilement proposer de mettre en place un simple système robuste de correction d'erreurs sans voie de retour. Le schéma doit être facile à mettre en œuvre sur un micro série PIC18.

Des idées?

+0

Je développe avec des dispositifs PIC18 et utilise actuellement le compilateur MCC18 et le PICC18. J'ai remarqué il y a quelques semaines que les en-têtes périphériques pour PICC18 mappent incorrectement la macro de bibliothèque Busy2USART() au bit TRMT au lieu du bit TRMT2. Cela m'a causé de gros maux de tête pendant une courte période avant que je découvre le problème. Le code simple: – Nate

Répondre

1

This site revendique la mise en œuvre de Reed-Solomon sur le PIC18. Je ne l'ai jamais utilisé moi-même, mais peut-être que cela pourrait être une référence utile?

1

Recherche d'un algorithme CRC utilisé dans le protocole MODBUS ASCII.

0

Je développe avec les dispositifs PIC18 et utilise actuellement les compilateurs MCC18 et PICC18. J'ai remarqué il y a quelques semaines que les en-têtes périphériques pour PICC18 mappent incorrectement la macro Busy2USART() au bit TRMT au lieu du bit TRMT2. Cela m'a causé de gros maux de tête pendant une courte période avant que je découvre le problème. Exemple, une transmission simple:

putc2USART(*p_value++); 
while Busy2USART(); 
putc2USART(*p_value); 

Lorsque la Busy2USART() macro a été incorrectement mis en correspondance avec le bit de TRMT, j'attendais jamais pour les octets de quitter le registre à décalage parce que je surveillais le peu mal. Avant de réaliser le fichier d'en-tête inexact, la seule façon de transmettre avec succès un octet sur 485 était d'attendre 1 ms entre les octets. Mon débit en bauds était de 91912 et les retards entre les octets ont tué mon débit. Je suggère également de mettre en œuvre un moyen de détection de collision et des sommes de contrôle. Les checksums sont bon marché, même sur un PIC18. Si vous êtes capable d'écouter vos propres transmissions, faites-le, cela vous permettra d'être conscient des collisions qui peuvent résulter d'adresses dupliquées sur la même boucle et de timings incorrects.