Expériences sur les ports RS232 rapides

[BboCurieuxDeTous]

Bonjour,

J'essaye de réaliser sur une liaison RS232 sur quelques centimètres entre un PC et un µcontrôleur au travers d'un convertisseur FTDI.
l'objectif est une communication bidirectionnelle de peu de données, depuis le PC vers le microcontrôleur avec un format toujours identique de 7 octets en émission et 3 octets réponse.
La communication consiste à envoyer du PC au microcontrôleur un grand nombre d'ordres consécutifs (pouvant atteindre 1500) et un ordre est dans le format suivant :
Le PC Envoie 7 octets au micro contrôleur (à une vitesse de 460800 bauds), le microcontrôleur reçois ces octets et réponds quelques 10ene de µs plus tard et le pc est en attente de la réponse du microcontrôleur. De souvenir de l'envoie de l'ordre à la réponse du microcontrôleur il s'écoule dans les 350µs.

Cette communication doit être le plus rapide possible et nous somme à une vitesse de 480800 bauds (qui est pour le transfert des données) .
La partie informatique a été codée sous deux logiciels, Python et Delphi et la communication s'exécute sur deux pc au performances différentes, pour voir s'ils n'étaient pas la cause de mon problème. Mais nous rencontrons le même problème quel que soit le PC ou le logiciel utilisé pour coder les fonctions du port séries (pour info les deux fonctionnent sous Windows).

Ce problème est une durée entre la fin de la réponse du microcontrôleur et la lecture du port série par le PC, en mode synchrone nous avons une durée de 5 à 6 ms et en mode Asynchrone nous avons une durée de autour de 4 ms.
Pour ce genre de communication de petits "paquets" que je souhaite réaliser, cette durée dans le réception, me fait perdre tout l'avantage d'un liaison RS232 rapide (460800 bauds) et aussi l'utilisation de cette liaison.

J'ai essayé de jouer sur les délais, timeouts... des drivers utilisés, rien ne semble y faire pour diminuer ces durées en dessous de 4 ms, et ce qui est recherché est bien en dessous de la ms.

Peut être cela est il dû à l'établissement de la communication quand un changement de direction survient, mais je ne le constate pas quand je passe d'une lecture du port vers une écriture sur le port.

D'où les questions.

• Avez vous des idées bien sur ?
• Pensez vous que le convertisseur USB/FTDI puisse être en cause, il est donnée pour 2Gbis/s , mais sur les changements de direction .. y aurait il aussi une durée d'établissement !! ?
• Avez vous déjà utilisé un port série dans les conditions décrites ci dessus ?
• Ces délais étant vraiment identiques sur les deux machines, sauriez vous, si suite à une norme liée aux UART, ce délai sur la réponse est normé ? et dans ce cas impossible a diminuer ?
• Si je passai par une liaison "SPI", pourrai je rencontrer le même type de délai de lecture ?
• Auriez vous une solution a mon problème !?

merci a vous.

bonne soirée.
-----

[polo974]

Pourquoi rs232 (pb de distance ? Je ne crois pas vu qu'il est question de spi...)

Sinon, de memoire, le bus USB sous w, il y a de la latence...
Par ex:
http://www.loadstarsensors.com/asset...ncy-timer.html
Mais il peut y en avoir d'autres cachées ailleurs.

[Vincent PETIT]

Bonsoir,
L'USB n'est malheureusement pas temps réel, comme polo je pense qu'il y a de fortes chances que le problème de latence vienne de là. Côté PC il faut aussi s'assurer qu'il n'y a pas de thread/processus qui viennent ralentir les choses.

Je ne sais pas s'il existe des cartes PCIe UART ? La latence devrait être très différente.

[BboCurieuxDeTous]

bonsoir ,

@Polo974 : pourquoi en RS232 ,car cela était le plus simple pour moi à mettre en œuvre. Je parle de SPI (toujours depuis un connecteur USB) en pensant supprimer ou optimiser mon problème.

@Vincent petit : malheureusement je dois aussi utiliser des portables pour mon application, d'où les cartes additionnelles impossibles.
C'est ce qui à conditionnée le choix des connecteurs USB , ils sont partout.

Si le problème vient de la latence de l'USB et qu'il n'est pas possible de le réduire, je suis grillé avec tous les protocoles séries existants passant par ces ports/connecteurs USB.

merci pour vos réponses.

bon dimanche.

[A voir en vidéo sur Futura]

[Vincent PETIT]

Concernant l'USB tu as des modes de transfert https://ftdichip.com/wp-content/uplo...hat-is-USB.pdf

- Bulk
- Interrupt
- Isochronous

Avec des caractéristiques différentes en terme. Je ne sais pas si ton driver CDC permet d'avoir accès au mode de transfert mais ça vaut le coup de jetter un œil.

[paulfjujo]

bonjour,

je n'ai utilisé que 115200bds max ,à l'heure actuelle..
Transfert de fichier WAV PC<-> MCU via l'UART..
avec gestion RTC CTS..

le probleme est-il dùement identifié coté PC ou coté MCU ?
Quand on voit le nombre de services actif sur un PC Windows ....!
il faut peut arreter ceux qui sont inutiles

Coté PC, Utiliser une appli ecrite en ASM ..

liaison RS232, certes
mais avec un protocole ? Hardware RTS CTS ?
coupleur FTDI TTL/USB 4 pins ou 6 pins
quel MCU ?

46080 bytes/sec !
21µS/ byte
7 bytes 147µS
MCU Fosc 64MHz -> cycle 0.0625µS
c'est jouable ..mais que fait d'autre le MCU
autre interrupts à traiter ..
MCU avec quartz ou oscillateur interne ajustable à +-3% ?

cette vitesse est-elle optimum ?
le mieux est l'ennemi du bien ...

[Piefra]

Bjr,

A l’epoque du dos , oui un prog en asm fesait la difference , notament avec une gestion en interruption et un buffer ad’hoc

Maintenant sous windows et port com over usb , il est illusoire que le asm apporte un benefice si on garde le pilote usb standard et son emulation port com

Ca reviendrait a reecrire le pilote usb du ftdi pour le rendre plus prehemtif sur windows , que ce soit en asm, delphi, c++ ou autre
Redessiner la chaine de traitemment complete du harware du pc jusqu’au logiciel de tratement
Toutes les couches d’abstraction harware layer entre le hard , les pilotes win , win , api , logiciel frontal , logiciel final ne font que rajouter de la latence

Si vous maitrisez delphy ( oubliez python qui est ce qu’etait le basic au dos ) vous pouvez avoir de l’executable pur et ecrivez un soft qui prehemte un ctrl usb et le ftdi , donc sans passer par les api win , et hors ctrl usb des peripheriques necessaire au reste du pc, qui gerera directement la reception des paquets

Bref c’est pas gagne

Une autre piste serait de trouver une carte pci / port com , qui monte au debit voulu , comme ca se faisait il y a longtemps et eviterai un passage par l’usb et le ftdi et avec un connecteur rs232 en prime

Cdlt

[polo974]

Attention avec les carte pcie rs232, car le pcie inclut un bus usb, et donc, oups, souvent, on se retrouve encore avec un usb/serie.

Doc ftdi:
https://www.ftdichip.com/Documents/A...atencyFlow.pdf

La latence usb, c'est pénible.

Et en plus ils ont triché avec le nom du mode de transfert "interrupt" qui n'est pas "interruptif"... juste des paquets plus petits...

Ah, aussi, il faut connaître ses bus usb sur le pc, car il vaut mieux isoler le port série des autres périphs usb (peut-être visible dans le gestionnaire de periph, mais pas sûr.

[Piefra]

Bjr,

Pour connaitre l’architecture usb utilise par un periph usb sur une prise identifiee , dans le gestionnaire de periph win, selectionner le periph en question et passer en mode affichage par connection et voir la hierachie des periph

Cdlt

[Seb.26]

Tu peux changer et ne plus utiliser 'UART ? ... car les modules USB<-->FIFO sont bien plus rapides et fiables (FT240XQ par exemple)

[Seb.26]

J'ai essayé de jouer sur les délais, timeouts... des drivers utilisés, rien ne semble y faire pour diminuer ces durées en dessous de 4 ms, et ce qui est recherché est bien en dessous de la ms..

-> Alors l'USB n'est probablement pas la bonne solution !

[Seb.26]

Mais intrinsèquement, pour moi tu tentes de faire du temps réel rapide sur un système qui n'est pas du tout prévu pour ... donc repense ton architecture.

[BboCurieuxDeTous]

Bonjour,

La seule vrai raison de passer par un port USB, est que c'est la seule connectique encore existante sur un pc portable (excepté Ethernet et encore beaucoup passe aussi par des convertisseurs USB/ETH).

La finalité de cette liaison rapide en Rs222 au travers de l'USB est le pilotage d'une machine, qui l'est à ce jour via un port parallèle converti en RS485. Oui je sais que passer de parallèle en série parait fou, cette liaison étant très courte, nous pensions attendre les vitesses de 460800 bauds, voir 920..., ce qui était suffisant pour notre cas.

Comme vous l'avez compris nous ne traitons que des ordres envoyés sur 7 octets et sa réponse, donc un dialogue bidirectionnel intense et non des mégaoctets d'un coup !.
MAIS dans mon calcul de transfert, je n'ai tenu compte que de la vitesse en bauds de la transmission et pas de cette latence présente. Qui de mon point de vue ne permet en aucun cas d'atteindre les vitesses annoncées en bidirectionnel.

J'allais faire des essais sur un port série non USB demain, mais comme indiqué par polo974, même les carte PCI passe aussi par de l'USB.

pensez vous que le problème de latence serait identique avec un adaptateur USB/SPI ?

Merci a vous pour votre intérêt!

[umfred]

FTDI propose aussi des câbles USB-RS485 dans leurs gammes
Tu utilises quel driver pour le pilotage? ils proposent 2 pilotes le Virtual COM port (VCP) pour utilisation comme un port série, mais aussi le driver USB D2XX.

D'après ce blog https://iosoft.blog/2018/12/02/ftdi-python-part-1/ , en passant en mode MPSSE (soit SPI/I2C), on éviterait le problème de timing

You can implement quite complex protocols using simple I/ O commands; write-cycles can be chained to output complex sequences, but there is quite a speed-penalty every time a read-cycle has to be interleaved. In recognition of this, many FTDI chips have a more complex capability, which they call MPSSE (Multi-Protocol Synchronous Serial Engine);

ce qui mène vers l'article 3 de sa série https://iosoft.blog/2018/12/05/ftdi-python-part-3/

[jiherve]

bonjour
du temps réel et un OS non prévu pour (vraiment préemptif) est illusoire.
JR

[Seb.26]

Si tu donnes ton besoin, une autre piste est peut-être plus réaliste, non ?
Tu as chois de faire le micro-pilotage depuis le PC, est-ce vraiment nécessaire ?
Un système plus adapté peut gérer les instructions bas niveau et ton PC le haut niveau.

exemple au pif : tu veux envoyer 700 ordres <bouge d'un cran à droite> avec 10ms entre 2 ordres
... ton PC sous windows en est incapable ...
Mais il peut envoyer la demande [ fais moi 700 ordres <bouge d'un cran à droite> + <avec 10ms d'attente> ] à un système adapté (genre Arduino, pico pi ou autre)

Mais on sait pas ce que tu veux ...

[polo974]

Je n'ai pas dis que pcie/rs232 passait systématiquement par l'usb, c'est fréquent, mais il existe aussi de vrais chip pcie/rs232.
Il aut juste faire attention à ce qui est proposé.

Sinon, attention, un PC peut allez "voir ailleurs" carrément en-dehors de l'os, passer du temps à gérer des "System Management Interrupt", très difficile à éviter sans risquer de faire fumer le PC...