Discussion :

[cyb33]

Je désire transmettre un fichier d'un PC à un autre via le port série.
Ne voyant pas comment faire, y aurait-il une bonne âme qui me mette sur le bon chemin ?

Merci et A+
CYB33

[ALT]

Bonjour

Pour écrire ou lire sur le port série, il suffit du tableau port (Turbo Pascal) :
lecture du port
machin:=port[numéro]
écriture du port
port[numéro]:=machin

Quant aux numéros de port, ils sont, en général :
port COM 1 : $3F8
port COM 2 : $2F8
port COM 3 : $3E8
port COM 4 : $2E8
port parallèle 1 : $378...

Simple, non ?

NOTA : Les adresses réelles de chaque PC peuvent être retrouvées avec la commande DEBUG du DOS :
Taper DEBUG, puis D40:0 (la casse n'a pas d'importance. Donc, on peut taper d40:0).
On trouve les adresses des ports sur la première ligne : d'abord les ports série, puis (seconde partie de la ligne) les ports parallèles. Attention : sur les processeurs Intel, les octets sont inversés en mémoire. Donc au lieu de 03 F8, on lira F8 03...

Cordialement

[cyb33]

Merci Alt pour ta réponse,

et pour la culture... pauvre de moi qui n'ai pas de confiture !!!

[M.Dlb]

Désolé de te contredire, ALT, mais c'est pas aussi simple que ça ...
En effet, il existe une petite puce sur la carte mère des ordinateurs, qui contrôlent les états des ports communications COM1 et COM2 ( les ports de base ). Cette puce, elle s'appelle l'UART chip ( UART = Universal Asynchronous Receiver Transmitter; en francais Receveur Transmetteur Asynchrone Universel ). Asynchrone veut dire qu'il y a pas de synchronisation entre les ports des deux ordis en fonction du temps. Et ça, ça pose d'énormes problèmes. Ce qu'il faut savoir, c'est que pour gérer ces ports, on utilise généralement des interruptions détournées, en l'occurence les IRQ 3 et 4. Donc pour gérer tout le systèmes des interruptions, sans bug, il faut se lever tôt...
Ca veut dire que l'on ne peut pas envoyer des octets n'importe comment sur les ports série sans se préoccuper de l'UART... Et donc on ne peut pas envoyer des fichiers par cable COM1 sans gérer l'UART...
Dans la partie contributions de ce site, on trouvé l'unité de François Peigner qui permet d'envoyer une chaîne de caractères d'un ordi à un autre mais l'envoi de fichier n'est pas implémenté ( cela dit, on pourrait facilement faire évoluer cette unité pour qu'elle envoie des fichiers... )
a+

[ALT]

Bonjour

En effet, j'ai péché par optimisme en affirmant que tout était simple.
En fait, Cyb33 demandait à être mis sur la piste. Ce que j'ai fait.

Néanmoins, je ne suis pas tout à fait d'accord avec toi : il n'y a pas besoin de gérer les interruptions pour transmettre des données. On peut se contenter de temporisations entre chaque caractère. C'est simplement plus long & un poil moins sûr (car on ne sait pas si le récepteur était réellement prêt à recevoir.) Quoi que... On peut imaginer que le récepteur retourne systématiquement le caractère reçu. Et alors on peut être absolument sûr que la transmission a été bonne, & on peut réduire les tempo. de façon importante, voire les supprimer.

La seule fois où il faut gérer l'UART est si on veut utiliser une vitesse de transfert différente à la vitesse par défaut (9600 bits/s). Et, peut-être en début de transmission, pour préparer le circuit (là, ma mémoire fait défaut).

À titre anecdotique, j'ai déjà utilisé ce genre de méthode plusieurs fois avec succès.

Au fait, asynchrone ne signifie rien d'autre que les ports ne partagent pas la même horloge. C'est pourquoi le protocole RS232C prévoit des bits de début (=start) & de fin (=stop) de transmission d'un octet

Cordialement

[M.Dlb]

Bon il est vrai que moi aussi, je suis allé un peu trop vite en besogne !
Je voulais dire par asynchrone, que les registres receveur et transmetteur n'étaient pas gérer en fonction de l'horloge, ils ne sont pas cadencés en fonction de l'horloge, donc on peut envoyer des octets quand on le désire sans consulter l'état de l'horloge.
Il est généralement deux façons de gérer les communications avec le port COM : soit avec la méthode énoncée par ALT, soit par interruption ! Il faut néanmoins noter que la méthode des interruptions est plus rapide car elle nécessite moins d'opérations ( le porgrammeur ne s'oocupe plus de surveiller les octets reçus car c'est la machine qui le prévient quand un nouvel octet arrive ).
L'UART est effectivement nécessaire pour régler la vitesse de communication ( si la vitesse par défaut est 9600 bits/s, on peut quand même aller jusqu'à 115200 bits/s, ce qui représente un peu plus que 14 ko/s, pas mal ! ). Cependant, l'UART est également nécessaire pour régler les paramètres de transmission ( bits de parité, de fin, utilisation du FIFO si possible, largeur du tampon mémoire, .......... ).

Voilà pour ces quelques précisions nécessaires !
a+

[LaGuimb]

Salut à tous,

Moi aussi ça m'intéresse le transfert par port série.
Je n'ai pas encore bien bossé le sujet, mais il est possible de
le programmer avec turbo pascal 7. J'ai pas mal de doc au niveau
des gestions des ports du PC (électronique)...

Par le port serie, les trames rs232 envoient des octets à un débit
défini, programmé dans l'uart. Il faut savoir qu'à des vitesses
trop élevées, on obtient des données éronnées. Je crois qu'il existe
des solutions pour ce problème...

Je vous en dirais plus bientôt! A+

[LaGuimb]

Si j'ai bien saisi, ton but est de connecter deux PC avec un cordon série croisé, pour tensférer des fichiers. Si tu souhaites réaliser un prog, je crois qu'il en existe déjà. Mais il est très intéressant de le faire soi-même! A+

[cyb33]

Salut à tous,

Merci beaucoup pour toutes ces réponses, j'ai moi-même aussi cherché sur Internet des renseignements complémentaires et j'ai trouvé un programme, comme le dit LaGuimb, mais il a un petit problème, il ne vide pas le buffer du programme receveur et lorsque celui-ci est plein, après 65536 octets, il bug.

Ce programme va très bien pour les transmissions courtes, mais pas pour transmettre de longs fichiers.

Salutations et A+, CYB33

[LaGuimb]

Salut Cyb,
Tu n'auras pas trop de mal à trouver un meilleur sur le net, si ce n'est pas déjà fait, enfin j'espère. Ce programme est déjà compilé apparemment, sinon il faut que je sache si tu as compilé des sources en Pascal avec TP ou BP..? Tu pourrais au moins me dire le nom de ce prog si tu n'as pas les sources, ça serait pratique pour cette question..! Essaye de voir si il possède des options de configuration au niveau de la transmission... Comme toi, je vais chercher si j'en trouve un mieux, je te le dirais. Mon problème est que je n'ai pas toujours 2 PC pour faire les essais. Si tu arrives à trouver un bon prog avant moi, j'aimerais que tu me l'envoi (si il est pas trop gros une fois zippé, ou plus directement le lien). j'ai déjà trouvé quelques liens intéressants... Mais pas encore de programme. Apparemment, il y en a que pour des modems, ou des interfaces, mais pas pour le câble standart! à+

[LaGuimb]

Effectivement, ce n'est pas aussi facile que ça, mais j'ai réussi à en trouver quelques programmes (soit pour port parallèle, soit pour port serie). Pour le port série, l'archive s'appelle XPORT21.ZIP - tu entres ce nom dans un moteur de recherche pour le trouver sans problèmes... Je ne l'ai pas encore tester, mais bientôt! A+

[cyb33]

Salut LaGuimb,

Sur le site développez.com j'ai récupéré le dossier "UNITE COM.ZIP" !
A l'intérieur tu trouvera l'unité qui gère l'UART et le programme de transmission/réception.

A+, meilleures salutations, cyb33

[cyb33]

Salut LaGuimb,

En ce qui concerne la compilation, j'ai compilé le programme en TP7.

Pour ce qui concerne ta transmission entre 2 PC, pour les tests tu peux les faire avec une seule machine uniquement, il suffit de relier ton port com1 avec le port com2 de ton PC avec le câble RS232, je t'assure que ça va très bien !

[LaGuimb]

Merci beaucoups Cyb!
Je suppose que ton problème est maintenant résolu, en ce qui concerne le bug du buffer, non? Si c'est le cas, édite le titre du premier message, et met [resolu] devant. Je vais maintanant essayer l'unité du site, mais d'abord il faut que j'arrive à libérer un port COM, car la souris en a besoin d'un (Y'a toujours quelque chose pour me bloquer ). Je trouve une souris USB, et je fais mes essais. A+

[cyb33]

Salut LaGuimb,

hé non, je n'ai pas encore résolu le problème, pour l'instant j'essaye de modifier l'unité "COMLIB.TPU" qui est livrée avec le programme !

On verra après...

[LaGuimb]

Salut Cyb!
As-tu essayé le prog XPORT21..? Il peut faire l'affaire si il fonctionne (moi je suis bloqué pour les tests!). Si tu tiens à utiliser l'unité du site, je vais voir ce que je peux faire, mais il va me falloir un peu de temps. A+

[LaGuimb]

Salut Cyb!
J'insiste pour dire que pour les longs fichiers, c'est beaucoups trop lent! Même avec un débit de 115k, cela fait au max 11,5 Ko/sec! Je pensais donc essayer un transfert par l'USB, qui permettrait, en théorie et d'après ma doc perso, un débit maximal de 12 Mb/sec, soit environ 1,2 Mo/sec! Je ne sais pas encore si c'est déjà utilisé... Si ça se trouve, ce n'est pas possible juste avec un câble, il faut peut-être une interface électronique... Je vais me rensigner sur le sujet, déjà en posant la question sur ce forum... Si il faut faire soi-même son câble, ya que 4 fils (ou 2 fils pour rs232, Rx/Tx). Normalement, faut juste deux prises mâles et un bout de câble. A+

[LaGuimb]

ça serait mieux de le faire avec l'USB, non? Là je pourrais faire des tests, vu que mes deux ports sont libres. De plus, les ports COM sont souvent déjà pris par d'autres périphériques... Ou c'est l'inverse. Mais si tu veux que l'on continu avec le port série, sûrement, que pour résoudre le bug du buffer, la solution est de découper le fichier avant de le transférer, en plusieurs parties de 64k, et à la reception fusionner les blocs pour reconstituer le fichier original. Le problème viendrait du programme, et non pas de l'unité! Je vais maintenant voir ça de plus près...
Bon, je m'en doutais, DEMOCOM n'est pas fait pour transférer des fichiers! Je pense refaire deux progs: Un pour l'émission et un autre pour la reception. C'est préférable de ne pas mélanger les fonctions pour l'instant. Avant de poursuivre, je te demande...
As-tu essayé Xport21..[O/N] ?
Confirme-moi si tu veux que l'on fasse ces progs,
ou si tu préfères que l'on passe directement à l'USB! A+

[cyb33]

:o Salut LaGuimb,

Non je n'ai pas essayé xport21, je n'ai trouvé que l'éxécutable alors que je désire le code source afin de pouvoir le modifier si nécessaire. Je vais encore me lancer à sa recherche...

Concernant le port USB, pour moi je dois l'oublier, A part quelques postes en Win2000, la pluspart des utilisateurs travaillent sous NT4, donc pas d'USB !

Et j'ai effectivement besoin d'aide pour résoudre ce problème.

[LaGuimb]

Ok! Si tu trouves le temps, essaye-le, j'aimerais bien voir ce qu'il donne!
Surtout, il me faut un programme sûr qui marche bien sur mon PC, avec mon câble, pour pouvoir d'abord tester ma transmission, tu comprend? Si mon édition de programme ne marche pas, ce ne sera pas à cause d'un problème de transmission, mais d'une erreur de programmation!
Je pense démarrer avec l'unité que l'on a tous les deux trouvés sur ce site, COMLIB.PAS. Il faut donc faire 2 nouveaux progs, en partant de cette unité avec un buffer de 64k. Donc découper le fichier pour l'émission (avec BlockRead), et le reconstituer pour la reception: On commencera par le prog d'émission (garde bien ça en mémoire, pour ne pas les mélanger).

EMISSION:
1) Ouvrir et configurer le port COM Tx.
2) Tester et ouvrir le fichier source.
3) Copier un bloc de ce fichier (64k).*
4) Transférer ce bloc (on verra après pour la reception & controle des données).
5) Répéter les opérations à partir du 2) inclus, jusqu'à tous les blocs transférés.
6) Cloturer le fichier et le port.

Je prépare le vrai code en Pascal de ce premier programme, on en discute plus en détails après. A+