Le FT232R et ses modes BitBang

[invitef1d1ec65]

Bonjour,
J'envisage d'utiliser un FT232R pour, entre autres, interfacer des composants en SPI. Je sais que ce n'est pas une bonne idée (le FT2232R est plus indiqué pour cela d'après le constructeur), mais je m'entête.
Evidemment, il y a la solution bète et méchante : le mode CBus BitBang ...
Mais ça suppose qu'on envoie un seul bit pour deux appels à la DLL FTDI (puisqu'il faut simuler SDI, CLK "à la main" et aussi CS) . C'est trop lent.
L'autre solution consiste à utiliser le mode BitBang synchrone (D0 à D7), et, pour simuler CLK du SPI, à configurer une des lignes CBusX (0 à 4) pour qu'elle véhicule en sortie les strobes de lecture (BitBangRDn). Dans ce cas, il reste le problème épineux du signal /CS qui doit passer en niveau haut sur une horloge à son niveau bas.

On peut essayer de simuler CS avec une ligne Dx (D0 à D7). Mais ça ne fonctionne pas : en mode synchrone, le signal BitBangRD# passe toujours en niveau haut immédiatement avant l'émission de la nouvelle configuration des lignes. Or, la spécification SPI impose une CLK à son niveau bas quand CS remonte.

On peut se dire qu'il n'y a qu'à utiliser les strobes BitBangWR# à la place. Mais là aussi, on a un problème : BitBangWR# n'est presque jamais au niveau bas ... et il n'est en aucun cas à son niveau bas au moment ou une nouvelle donnée vient configurer le bus D.

Donc, on élimine l'option "CS simulé sur une ligne du bus D".

On peut essayer de simuler CS avec une ligne du CBus. Dans ce cas, on se propose de passer en mode CBus BitBang pour abaisser la ligne CBUSx qui sert de CS, puis on repasse en mode BitBang synchrone et on transmet une suite de bit sur la ligne de bus D qui nous sert de sortie SDI et enfin, on revient en mode CBus BitBang pour remonter notre ligne CS.

Mais là il y a une inconnue qui se profile ... et c'est l'objet de ce post dans le forum : qu'advient-il des lignes du Bus D quand on active le mode CBus BitBang ? (est-ce que les lignes restent configurées comme précédemment ? ou y a-t-il une sorte de remise en mode tristate qui est fait ?)
Deuxième question : qu'advient-il des lignes du bus C quand on active le mode "synchronous Bit Bang" ?

Si les lignes restent inchangées, je pense qu'on peut faire de la communication SPI efficace avec un FT232R. Sinon, je pense que je m'orienterai (à regrets) vers une autre solution.
-----

[invitef1d1ec65]

Evidemment, je n'ai pas mentionné la solution du "tout en bus D" qui consiste à simuler à la fois CLK, CS, SDI et SDO sur 4 lignes du bus D et en BitBang synchrone ... c'est assez efficace mais l'ennui est qu'on doit transmettre 2 octets (sur le Bus USB) par bit émis sur le bus SPI (deux octets identiques mis à par le bit CLK qui passe de 0, dans le premier octet, à 1 dans le second). Il faut aussi lire 2 octets par bit émis (puisque la doc précise que rien n'est émis si le buffer de lecture est plein) et le bit de donnée SDO est plutôt à chercher dans le premier octet lu.

Plus précisément, on construit une trame ainsi (on suppose qu'entre deux envois sur le bus SPI, les lignes sont configurées en [SDI haut, CLK haut, CS haut]) :
Pour gérer l'abaissement de CS sur CLK bas, on commence par émettre un octet abaissant l'horloge [SDI = premier bit à émettre, CLK à 0, CS à 1]. Puis un octet abaissant CS [SDI premier bit, CLK à 0, CS à 0] et enfin un troisième octet pour réarmer le signal d'horloge avant envoi du bit suivant [SDI premier bit, CLK à 1, CS à 0].
CS restera alors à 0 jusqu'à la transmission du dernier bit.
Les bits suivants se traduisent par un octet [SDI bit n, CLK à 0, CS à 0] suivi de [SDI bit n, CLK à 1, CS à 0].
A la fin de la trame utile (quand tous les bits sont émis), on ajoute un octet [SDI inchangé par rapport à l'octet précédent, CLK à 0, CS à 0] puis un second octet [SDI inchangé par rapport à l'octet précédent, CLK à 0, CS à 1]. Ensuite, si on a vraiment un composant esclave lent, on ajoute un octet [SDI inchangé par rapport à l'octet précédent, CLK à 0, CS à 1] pour respecter le temps de désactivation du bus SPI par le composant esclave. Et on finit par un octet [SDI à 1, CLK à 1, CS à 1] pour revenir à notre configuration inter-trame économisant l'énergie dissipée dans les pull-ups. Au final, ça nous fait beaucoup d'octets transmis : pour envoyer une trame de n bits, on a besoin de lire/écrire n * 2 + 5 octets (et il faut découper ces trames en blocs de 128 octets, sinon le buffer de lecture sature).

[invitef1d1ec65]

A titre de comparaison, si les lignes configurées en GPIO/sortie du Bus C restaient inchangées même quand on repasse en BitBang synchrone (et inversément, si les lignes du bus D restent inchangées quand on passe en CBus Bit Bang), alors on peut se contenter d'une trame de n octets pour n bits transmis sur le bus SPI (mais, il est vrai, au prix de deux changements de mode du FT232R ... ce qui n'est pas forcément plus rapide si on a de petites trames ... en SPI, on peut vraiment booster sans problème la vitesse au maximum de 153600 octets par seconde, soit environ 9 Ko de données SPI utiles par seconde avec ma technique sur bus D)