2010-07-20 6 views
0

J'ai actuellement un périphérique intégré connecté à un PC via un port série. J'ai des problèmes avec la réception de données sur le PC. Lorsque j'utilise ma carte de port série PCI, je peux recevoir des données immédiatement (sans délai). Quand j'utilise ma prise USB-To-Serial ou les cartes mères intégrées au port série, je dois retarder la lecture des données (40ms pour les paquets de 32 octets).Délai de transfert UART de transfert série

La seule différence que je peux trouver entre le matériel est l'UART. La carte PCI utilise un 16650 et la prise/carte mère utilise un 16550A standard. La carte PCI est configurée pour interrompre à 28 octets et la prise est configurée pour interrompre à 14 octets.

Je suis connecté à 56700 Bauds (si cela aide).

Le retard devient la majeure partie du cycle de service et augmente réellement le temps de transfert. (10min de transfert vs 1 heure de transfert).

Quelqu'un at-il une explication pour pourquoi je dois utiliser un retard avec la prise/carte mère? Quelqu'un peut-il suggérer une solution possible pour minimiser ou supprimer ce retard?

+0

Avez-vous activé le contrôle de flux matériel? Votre appareil intégré utilise-t-il un 16650? – nmichaels

+0

Non, le contrôle de flux matériel n'est pas activé. Je n'utilise actuellement que RX/TX et une ligne au sol. L'appareil embarqué utilise un atmel atmega 128L et un cristal 7,3728 MHz. Je suppose que cela est considéré comme "16650 compatible". Peter: Oui, je peux ajuster le point d'interruption de la carte mère. Cependant, sa portée est également de 1-14 octets en raison de l'utilisation d'un UART 16550 (tampon FIFO 16bytes). Le retard a effectivement aidé à minimiser les erreurs d'incompatibilité sur la connexion de la carte mère de centaines à moins de 10 pendant le transfert d'une heure. –

Répondre

2

Linux possède un indicateur ASYNC_LOW_LATENCY pour le pilote série qui peut aider. Quel que soit le pilote que vous utilisez peut avoir quelque chose de similaire. Cependant, la latence ne devrait pas faire de différence sur un transfert en masse. Il devrait ajouter 40 ms au tout début du transfert et c'est tout, c'est pourquoi les conducteurs ne s'en préoccupent pas en premier lieu. Je recommande de refactoriser votre protocole de transfert pour utiliser un sliding window protocol, avec une taille de fenêtre d'environ 100 paquets, si vous faites des paquets de 32 octets à ce débit en bauds et latence. En d'autres termes, vous ne voulez arrêter d'émettre que si vous n'avez pas reçu d'ACK pour le paquet que vous avez envoyé il y a 100 paquets.

+0

J'ai augmenté la taille de paquet de 32 octets à 256 octets et j'ai seulement besoin d'augmenter le délai de 40 ms à 65 ms. Cela a réduit mon temps de communication de 1 heure à 14 minutes. –

0

Vous trouverez probablement que différents convertisseurs USB-série produisent des résultats différents. Nous avons constaté que les interfaces FTDI fonctionnent bien pour parler avec des périphériques intégrés. Certains convertisseurs semblent tamponner les données pendant une longue période et/ou les fragmenter.

Je n'ai jamais vu de problème avec une connexion carte mère - je ne sais pas ce qui se passe là-bas! Pouvez-vous changer le point d'interruption pour le port série de la carte mère?

+0

Appuyé sur les convertisseurs série/USB. J'ai vu beaucoup de ce travail toute la journée pour les données ascii, mais les données binaires corrompues à des débits binaires élevés (115 200). – nmichaels

+0

Le convertisseur USB-série que j'utilise est le Trendnet TU-S9 qui utilise une puce Prolific. La carte PCI est une marque Sunix. –

0

J'ai un convertisseur série vers usb. Quand je le connecte à ma boîte de dérivation et que je crée un loopback, je peux envoyer/recevoir à près de 1Mbps sans problèmes. Le port série envoie des données binaires qui peuvent être traduites en données ASCII. En utilisant .Net, j'ai défini mon logiciel pour déclencher un événement sur chaque octet (ReceivedBytesThreshold = 1), même si cela ne veut pas dire que ce sera le cas.