FT232R USB de travail, mais est extrêmement lente

[MOS6502]

J'utilise un FT232R de télécharger des fichiers dans un projet que j'ai construit en utilisant un terminal (RealTerm). L'amende de télécharger des fichiers sans perte de données ou tout autre problème, même à des taux élevés Baud. Cependant, la vitesse du transfert est incroyablement lent. Le fichier que je télécharge est 160kb, à Baud de 115200 qu'il prend 1min 26sec et. Je pense qu'il ne devrait prendre que 14 secondes (163840 * 10 / 115200 = 14,2). J'utilise 8bits de données, sans parité, 1 bit d'arrêt et pas de poignées de main. Je ne suis que de passer les données dans une direction (du programme de terminal à mon projet), il devrait simplement être un flux continue de 160K octets. J'ai expérimenté avec la modification d'un temps de latence et la taille de transfert, mais de modifier ces paramètres ne résout pas le problème de la vitesse lente. Je voudrais vraiment savoir pourquoi cela prend si longtemps, c'est à cause de la façon dont le programme de terminal envoie les octets pour le conducteur FT232R? ou est-ce parce que je ne suis pas en utilisant handshaking? ou une autre raison? N'importe qui ont une expérience similaire à celle ou avez des idées ce qui pourrait être la cause?

 

[FvM]

c'est à cause de la façon dont le programme de terminal envoie les octets pour le conducteur FT232R?

Je suppose que oui. Envoi de fichiers texte avec un programme terminal est habituellement ralenti volontairement. En dehors de ce problème, il est peu fiable, sauf si vous parvenez à définir une séquence de démarrage unique. Binary méthodes de transfert de fichiers peuvent être appelés à travailler beaucoup plus vite, il ya certains qui ne sont pas ralentis par une poignée de main, par exemple YMODEM, que j'ai utilisé à la fois pour un maximum de téléchargements de logiciels de vitesse. Pour atteindre la pleine vitesse de l'interface disponible, peut écrire sur le port série dans un C ou C # programme.

 

[PaulHolland]

Salut, Qu'est-ce qui se passe, c'est que vous êtes très probablement appel à votre côté PC le driver UART (descripteur de fichier etc) octet par octet, cela se traduira dans l'appel système dans Windows octet par octet, ce qui se traduira par vous envoyant une trame USB qui, normalement, peut contenir des données 1K détenant uniquement un octet. Puisque les cadres USB sont prévues votre taux de transfert sera très lent. Qu'est-ce que vous avez à faire est d'envoyer un bloc de données, 128 octets par exemple!. Et vous envoyer ce pas en utilisant un terminal écrit pour un vrai UART. Ces anciens programmes sont toujours téléphoner et envoyer octet par octet depuis les puces UART vieux et les pilotes (dos) a travaillé comme ça. Envoi de vous-même à un port COM est très simple et pas beaucoup plus que d'écrire un fichier .

 

[MOS6502]

Merci les gars, qui ne font sens. Un autre problème que j'ai remarqué, c'est que quand je brancher ou débrancher le câble USB à mon projet que je reçois des données aléatoires de série. Est-ce normal ou prévu? Mon projet est en "configuration auto-alimentée», de sorte It'a déjà sous tension avant de me connecter ou déconnecter le câble USB. De gros, si j'ai le câble USB connecté avant de mettre mon projet, il fonctionnera bien, mais je voudrais que le projet soit capable de branchement à chaud le câble USB.

 

[PaulHolland]

Vous devriez toujours concevoir quelque chose de sorte qu'il est capable de récupérer des situations imprévues, cela signifie également que vous pouvez recevoir un bruit aléatoire (octets) avant que l'information réelle est reçue.

 

[horace1]

semble très lent, êtes-vous écrit au port série d'un octet à la fois, ou en cubes. Serait intéressant d'essayer en utilisant le matériel du port COM1 pour voir si c'est le FT232R ou quelque chose d'autre

<span style="color: grey;"><span style="font-size: 10px">---------- Message ajouté à 14h46 ---- ------ Le post précédent a été à 14:42 ----------</span></span>
"Un autre problème que j'ai remarqué, c'est que quand je brancher ou débrancher le câble USB à mon projet Je reçois des données aléatoires de série. Est-ce normal ou prévu? " J'ai le même problème avec un TTL-232R-3V3 - lorsque je débranche le câble du port USB que je reçois des caractères bizarres (que j'ignore) - sans doute quelque chose à voir avec le pilote FTDI USB

 

[FvM]

quand je brancher ou débrancher le câble USB à mon projet que je reçois des données aléatoires de série.

Le bouchage, cela peut être dû à des fenêtres de chercher à identifier une souris série au port série respective. La fonction peut être désactivée dans le Gestionnaire de contrôle du système, je pense. Fondamentalement, le problème serait résolu par la conception d'un protocole fiable, comme mentionné précédemment. Le fait de débrancher va générer des signaux parasites de toute façon.

 

[MOS6502]

Merci à tous pour tous les aider. Bonnes nouvelles, problème résolu, afin d'aider toute personne ayant le même problème, vous pouvez essayer ce qui a fini en le fixant pour moi. Placer un 100k tirer vers le bas sur la sortie 12MHz résolu le problème. J'utilise l'horloge d'12Mhz de la FT232R pour l'horloge UART, en l'absence de port USB est connecté, je tiens le FT232R dans la remise qui tristates les sorties. Je ne suis pas sûr à 100% pourquoi seulement causé un problème, tout en branchant le connecteur USB dans, mais il a été.

 

[luben111]

avis que l'USB a ce qu'on appelle "le temps du scrutin». USB n'est pas comme l'interface RS232 événement conduit (il n'a pas d'interruption sur de nouvelles données) et le PC ont de "sondage" les données. Donc, si vous utilisez le temps d'interrogation par défaut de Windows (10ms) et vous pouvez également demander les données en envoyant une commande, il peut être assez long. FTDI travaille vite si vous envoyez les données comme un flux incassable, mais une fois que vous démarrez données demande-réponse de la performance pourrait être très pauvres