FT232HL FTDI problème de retard d’octets SPI consécutifs

ggadde29

FT232HL FTDI problème de retard d’octets SPI consécutifs


J’ai un problème avec le FT232HL FTDI ic.

L’application Windows envoie les données à la puce via USB et la puce envoie les données avec un canal SPI.

J’ai vérifié avec un analyseur logique, les octets sont correctement envoyés et l’horloge SPI correspond aux paramètres. Cependant, entre chaque octet, il y a un retard de 64uS, ce qui signifie que quelle que soit la hauteur de l’horloge SPI, le transfert de données prend des minutes au lieu de secondes.

J’imaginais que peut-être jouer avec le channelConf.LatencyTimer aiderait, mais cela ne montre aucune différence quelle que soit la valeur utilisée (10, 128, 255), le retard reste 64uS entre octets consécutifs.

Il doit y avoir quelque chose à corriger car il existe de nombreux exemples de personnes atteignant des taux de transfert élevés. En outre, le délai entre les octets devrait être un paramètre quelque part.

J’ai utilisé un exemple de code fourni avec sample-dynamic.c Le flux d’octets est envoyé avec un seul appel à p_SPI_Write () avec une longueur totale de 2048 octets. J’ai essayé d’autres longueurs (256, 8192, etc.) sans changement. Voici la configuration utilisée:

 channelConf.ClockRate = 5000*1000; channelConf.LatencyTimer= 10; channelConf.configOptions = SPI_CONFIG_OPTION_MODE0| SPI_CONFIG_OPTION_CS_DBUS3/*|*/ ; channelConf.Pin = 0x00000000; /* FinalVal-FinalDir-InitVal-InitDir (for dir: 0=in, 1=out) */ 

Système d’exploitation: Windows7 X64 Compiler: bibliothèque GCC et code depuis: http://www.ftdichip.com/Support/SoftwareExamples/MPSSE/LibMPSSE-SPI.htm

FYI: J’ai contacté le support FTDI, ils m’ont demandé de mettre à jour les bibliothèques à la dernière (ce que j’ai fait), puis ils ne fourniraient plus de support.

Toute aide appréciée. Je vous remercie.

Chris Stratton

Comment livrez-vous les données aux chauffeurs? Dans quelle taille de morceaux? Les périphériques USB peuvent ralentir jusqu’à une exploration s’ils n’obtiennent qu’un octet ou quelques déplacés par image. Au tout début, avant que les gens ne comprennent les problèmes, l’ajout d’un convertisseur série USB à quelque chose qui fonctionnait bien sur un port série de bus local pouvait complètement casser son utilisation. C’est souvent maintenant compris, mais le SPI peut impliquer une coordination avec d’autres signaux comme les sélections, il est donc facile d’imaginer être entravé par le tramage du bus et incapable de tirer parti du débit de données théorique qui s’appliquerait à des transferts plus importants.

ggadde29

Bonjour. Comme indiqué sur le message, quel que soit le nombre d’octets envoyés simultanément, le délai est le même. J’envoie généralement 2048 octets par appel p_SPI_Write (). De plus, j’utilise le mode maître spi, en écriture seule, il ne devrait pas y avoir de prise de contact. Je vous remercie.

Ale..chenski

Êtes-vous sûr que le côté USB envoie les données assez rapidement? Pourquoi ne regardez-vous que du côté SPI de votre pont?

ggadde29

Je n’ai aucune idée de la vitesse à laquelle l’USB transmet les données. Je vérifie le côté SPI car c’est la fin de la ligne et je peux facilement vérifier avec l’analyseur logique. Je ne vois pas comment le transfert USB pourrait être plus lent que 16 Ko / sec de toute façon. J’ai entendu les gars de FTDI, ils suggèrent que je n’utilise pas leur bibliothèque (mais ils n’ont pas clairement dit que leur bibliothèque était buggée). Je suis toujours surpris que certaines personnes puissent atteindre des vitesses de transfert élevées hors de la boîte et en utilisant la bibliothèque fournie. Commence à être trop compliqué pour un travail de transfert USB <> SPI simple.

Réponses


 techdude

Je travaille généralement avec la puce FT2232H, mais j’ai creusé une puce FT232HQ juste pour que je puisse vérifier ce problème que vous rencontriez. C’est la même puce que la puce FT232HL que vous avez, juste dans un package QFN au lieu d’un QFP.

J’ai essayé de recréer le problème que vous décrivez, mais je n’ai pas pu exactement. Voici à quoi cela ressemblait sur mon analyseur logique lorsque je produisais 6 octets à la fois à une fréquence d’horloge de 5 MHz. Il y a un petit délai entre les octets, mais loin d’être aussi important que 64us.

Exemple de transmission multioctets à 5 MHz

Voici quelques éléments à vérifier.

  • Le minuteur de latence ne devrait vraiment pas avoir d’importance car il s’agit simplement d’un délai avant que l’USB n’envoie un paquet incomplet. Je l’ai réglé sur 255, mais souvent pour les choses sensibles au timing, je l’ai plus bas (2 -10)
  • Essayez d’abord une fréquence d’horloge plus lente juste pour tester et vous assurer que l’appareil communique correctement (je suppose que vous l’avez fait, j’ajoute simplement ceci au cas où quelqu’un d’autre n’aurait pas encore essayé).
  • Les directions des broches n’ont pas d’importance sauf pour GPIO car elles sont écrasées par la librairie SPI.
  • Au lieu de p_SPI_Write() , utilisez SPI_Write() . Si vous effectuez un seul appel, ajoutez les indicateurs d’activation et de désactivation de puce appropriés (voir ci-dessous). Si vous effectuez plusieurs appels, assurez-vous d’ajouter les indicateurs de sélection de puce aux premier et dernier appels de la série.
  • Assurez-vous de transmettre le nombre d’octets à transmettre et définissez l’indicateur SPI_TRANSFER_OPTIONS_SIZE_IN_BYTES .
  • S’il s’agit d’une carte personnalisée ou si vous avez acheté une carte adaptateur FT232H à prix réduit, assurez-vous qu’elle a la bonne fréquence d’horloge système. Ce délai entre les octets est basé sur le temps qu’il faut à la puce pour déplacer l’octet suivant de sa mémoire tampon interne vers les registres à décalage de sortie. Si la puce est cadencée lentement, cela apparaîtra aux fréquences plus élevées comme un plus grand écart entre les octets. Notez que pour SPI, peu importe si l’horloge est étirée un peu ici et là car elle est basée sur les fronts du signal d’horloge (lus sur un front, se propagent sur l’autre). Sondez le cristal ou la puce de cristal CMOS et assurez-vous qu’il obtient 12 MHz.

Voici un exemple de code rapide sur la façon d’envoyer plusieurs octets de données au cas où cela aiderait.

 uint32 sizeToTransfer = 0; uint32 sizeTransfered = -1; uint8 buffer[256]; //Must be large enough for what you are sending. FT_STATUS status; //add data buffer[sizeToTransfer++] = 0x20; //First data byte (can be what you need) /* * More bytes added.... */ buffer[sizeToTransfer++] = 0x00; //Last data byte (can be what you need) status = SPI_Write(*handle, buffer, sizeToTransfer, &sizeTransfered, SPI_TRANSFER_OPTIONS_SIZE_IN_BYTES | SPI_TRANSFER_OPTIONS_CHIPSELECT_ENABLE | SPI_TRANSFER_OPTIONS_CHIPSELECT_DISABLE); //Don't forget to check status. It should equal FT_OK if everything went well 

 

#de, consécutifs, d’octets, FT232HL, FTDI, Problème, retard, SPI

 

google

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *