Communication RS232 avec un PIC via delphi

Version imprimable

01/08/2004, 15h12
JeanPh

Communication RS232 avec un PIC via delphi

Bonjour,

j'ai fait le tour des tutos, des faq et autres mais je ne trouve pas mon bonheur.

J'ai besoin de communiquer avec un PIC 16F876 interfacé avec un module RS232 pour récupérer les données stockées dans l'eeprom interne afin de traiter les résultats avec un programme delphi.

Je travaille sous delphi 7 et j'ai essayé avec la librairie .dll RSCOM de Burkhard Kainka, mais je n'arrive pas a communiquer avec mon PIC

Pour faire un test simple, j'ai programmé le PIC (en BASIC) avec un simple programme de réception (il attend un byte, ne fait rien d'autre qu'allumer une led si il a receptionné).

*************************
Define loader_used 1
Define OSC 20

recu var byte

main :

serin2 15,32,[hex recu]
high portb.1

goto main
**************************

D'autre part j'ai fait un petit programme delphi avec un bouton, lorsque j'appuie sur le bouton je fais simplement :

procedure TForm1.Button1Click(Sender: TObject);
begin
OpenCom('COM4: baud=19200 parity=N data=8 stop=1');
sendByte(5);
end;

J'ai bien vérifié la config du port 4, c le bon port et je travaille bien 19200 bauds sans parité avec huit bits et un stop bit. Avec un terminal, le pic receptionne et la led s'allume. Avec mon prog delphi ca ne fonctionne pas.

Que dois-je faire pour résoudre mon problème ?

Merci d'avance
01/08/2004, 15h57
Nono40

Je te conseil une série de composants tous faits. Certaines libraires ne fonctionne plus très bien sous 2000 et XP.

http://delphi.developpez.com/faq/?page=portseriepc
01/08/2004, 17h31
edam
salut
je pence que tu doit utiliser TComport cest mieu car il est donner avec la source
en plus
Code:

1 2 3 4 5 6 procedure TForm1.Button1Click(Sender: TObject); begin OpenCom('COM4: baud=19200 parity=N data=8 stop=1'); sendByte(5); end;
la tu férme pas votre port
soit tu louvre dans oncréate et tu le férme dans ondéstroye
jéspére que tu perd pas éspoir et jaime bien déscuter de sa
bonne chance
01/08/2004, 20h48
edam

en plus pourqoi le port série
il ya le port paralléle surtout que le port série utilise +-12v et le // 5v
voir http://perso.easynet.fr/~chrisg/mnu1.htm
01/08/2004, 22h13
petitcoucou31

Le choix du port serie est simple car si mes souvenirs sont bon le pic que tu utilises possede lui meme une interface serie integrés ( sinon dommage d'utiliser ce pic !! ) , donc tu as besoin des + et - 12v qui ne sont pas sur le port parrallele . Autrement il y a bien sur des composants qui adaptes les signaux si tu veux passer par le port parallele . mais a mon avis il est plus simple de faire du 5v avec du +12 , que le contraire :lol:
01/08/2004, 22h58
-Yoann-

Bonjour,

Je te conseil en effet d'utiliser la DLL de B. Kainka pour plusieurs raisons :
- Compatible Windows 98 et XP.
- Contrôle de "pratiquement" (pas la broche RXD) toutes les brôches du port série. La plus part des composants se basent sur le protocole RS232, tu ne peux donc pas faire ce que tu veux.
- L'auteur de la DLL a une expérience en électronique et pourra répondre à tes questions. Il a écrit un livre "Les interfaces de mon PC sous Windows" avec Delphi et Visual Basic.

Tutorial : http://delphipage.free.fr/portserie.html

Cordialement.
02/08/2004, 12h51
JeanPh

Yoann,

c'est via ton tutoriel que j'ai téléchargé la dll. J'ai fait le tuto et ca fonctionne. Mais quand je veux envoyer un byte a mon PIC, ce dernier ne recoit rien. hors avec le terminal ca fonctionne. Le pic attend juste un byte en rs232.
02/08/2004, 17h23
JeanPh

En fait, quelqu'un pourrait-il simplement me dire comment je dois faire pour envoyer un byte au PIC ? Le résultat doit etre le meme que quand j'envoie qqch avec un terminal.

SendByte n'a pas l'air de fonctionner (je ne comprends pas d'ailleurs). Quelle procédure dois-je utiliser ??

Help :(
02/08/2004, 19h29
-Yoann-

Essaye d'utiliser la broche TXD :

Code:

TXD(1);

PS: Si tu n'y arrives pas, envois moi ton prog.

Ca ne marche pas mieux.

J'ai repris le code de l'exemple avec la led et je l'ai modifié un peu, donc quand je pousse sur connection, c'est sensé envoyé la valeur 5 au pic mais il ne réceptionne que dalle.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
implementation
 
{$R *.DFM}
 
//Importe les procédures et les fonctions de la DLL que l'on a besoin
function OPENCOM(OpenString:PChar):Integer; stdcall; external 'RSCOM.DLL';
procedure CLOSECOM(); stdcall; external 'RSCOM.DLL';
procedure TXD(d:WORD); stdcall; external 'RSCOM.DLL';
 
procedure TForm1.FormCreate(Sender: TObject);
begin
SortieClgn:=1; //Initialise la variable "SortieClgn"
end;
 
procedure TForm1.Button1Click(Sender: TObject);
begin
OpenCom('COM4: baud=9600 parity=N data=8 stop=1'); //Ouvre et paramètre la connexion sur COM1
{On peut également faire ceci : "OpenCom('COM1:9600,N,8,0');" mais la notation recommandée par l'auteur (Burkhard Kainka) de la DLL pour toutes les versions de Windows est la première}
Timer1.Enabled:=True; //Active le timer
end;
 
procedure TForm1.Button2Click(Sender: TObject);
begin
Timer1.Enabled:=False; //Désactive le timer
Label1.Visible:=False; //Enlève le label
TXD(5); //Envoi la valeur "0" vers la sortie pour que la LED soit allumée
CloseCOM; //Libère le port
end;
 
procedure TForm1.Timer1Timer(Sender: TObject);
//Var i:integer;
begin
//Alterne les "0" est les "1"
if SortieClgn=0 then
SortieClgn:=1
else
SortieClgn:=0;
//TXD(SortieClgn);
Label1.Visible:=True; //Affiche le label
end;
 
procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
if Timer1.Enabled=True then //Si le Timer n'est pas arrêter alors on se déconnecte avant de quitter le programme
Button2Click(Sender)
end;
 
end.

Ce que je veux juste faire, c'est vraiment communiquer en RS-232 à l'image des commandes "serin" et "serout" en basic. J'ai essayé avec les composant TComPort mais j'arrive pas non plus.

Je comprends pas ce que je dois faire.

Quelqu'un pourrait-il me donner un exemple ?

Balises CODE rajoutées par subØ

03/08/2004, 14h39
lil_jam63

Salut, pense a mettre ton code entre les balises code, il sera plus lisible.
04/08/2004, 12h06
Le Lézard

Yo !

Est-ce que ton problème ne viendrait pas simplement de la (non) gestion du contrôle de flux hardware ???
Je pense aux signaux DTS, RTS, CTS et DTR.

Si cela fonctionne à partir d'un terminal, je te conseille de vérifier l'état de ces signaux lorsque ton terminal est connecté. Ensuite, tu fais en sorte que ton logiciel les positionne identiquement avant d'envoyer ton byte.
04/08/2004, 16h56
JeanPh

ok je vais regarder. Mais comment je peux avoir accès à ces signaux ? Via le terminal ? Ou bien dois-je utiliser un voltmètre ?

Merci pour les précisions
04/08/2004, 17h42
petitcoucou31

Avec un voltmetre tu ne verra rien , les signaux sont pas tous statiques donc trop rapide pour un voltmetre.
je te conseille d'utiliser un de ces petit conecteur equipé de led qui s'insere en serie avec ton port de communication et qui visualise les signaux de la rs232 .
Par contre as tu deja fait tourner ton petit programme dans le pic en autonome pour etre que que c'est pas de chez lui que viens ton probleme , le port du pic est il bien initialiser ...
04/08/2004, 18h14
JeanPh

Pour apporter encore une petite précision : entre le pic et le connecteur j'ai un circuit HIN232CP. Je sais pas si ca change qqch au probleme mais comme ca je le signale.

J'ai fait tourner le programme sur le pic et j'ai envoyé un byte par le terminal. C'est ca que tu entends par "en autonome" ou tu penses a autre chose ??? Merci de m'éclairer
05/08/2004, 02h09
Le Lézard

Citation:

Envoyé par petitcoucou31

Avec un voltmetre tu ne verra rien , les signaux sont pas tous statiques donc trop rapide pour un voltmetre.

Si, c'est jouable avec un voltmètre. Il faut connaitre les états stables de ces signaux une fois le terminal connecté. Donc un voltmètre peut remplacer une jonction éclatée.
05/08/2004, 10h58
JeanPh

Ok je vais tenter avec un voltmètre.

Autre chose, concernant le flow control, si je travaille en 'flow control : none' , je ne dois me soucier que de Tx et Rx non ?
05/08/2004, 14h56
Le Lézard

Ce n'est pas si simple que ça. Ca dépend également de la conf de l'UART du PIC. L'idéal est réellement de recopier la conf d'une solution qui fonctionne : Le terminal.

Pour info, sur une jonction V24 :
- état 1 (SET) : -12v
- état 0 (RESET) : +5v

Pour le brochage, tu peux jeter un coup d'oeil ici : http://mgc99.free.fr/Lserie.htm

Bon, sur le connecteur qui est sur ma carte avec le PIC, je mesure, et ce, que le terminal soit connecté ou pas :

Broche 1 : CD : 0 V
Broche 2 : RD : -7.62 V
Broche 3 : TD : -7.62 V
Broche 4 : DTR : -8.41 V
Broche 5 : GND : 0 V (encore heureux :) )
Broche 6 : DSR : 0 V
Broche 7 : RTS : 0 V
Broche 8 : CTS : -8 V
Broche 9 : RTS : 0 V

Ca correspond pas aux valeurs dont tu parles mais ce qui m'intrigue le plus c la différence entre les différentes broches négatives. Soit.

J'ai donc vite fait le petit prog Delphi tout bete suivant (en utilisant le composant TComPort):
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 implementation {$R *.dfm} procedure TForm1.Button1Click(Sender: TObject); begin ComPort1.Open; ComPort1.SetDTR(true); ComPort1.SetRTS(false); end; procedure TForm1.Button2Click(Sender: TObject); begin ComPort1.WriteStr(Edit1.Text) end; end.
Et j'ai constaté que quand j'appuie sur le bouton 1 qui ouvre le port et établit la connection, la seule différence est que la broche 2 RD est à + 7.62 V.

C'est la seule différence avec le terminal. Ensuite si j'appuie sur le bouton 2 pour envoyer le byte, ca ne fonctionne pas. Avec le terminal bien. Que faire ?????

Je sens qu'on est pas loin de la solution, mais je suis un peu dans le vent sur ce qui ne va pas.

06/08/2004, 00h10
petitcoucou31

Pour ce qui est du pavé HIN232CP il devrait pas y avoir de problemes c'est un transmetteur de ligne RS232 qui adapte les signaux , au cas ou ils y auraientt plusieurs port rs232 de connecter , en l'occurance ce pavé possede deux port serie . et en plus qui ne necessite que d'une alimentation 5v.

Quand je parte d'autonome : un pic a deux utilisation , soit de faire une tache "complexe" et d'envoyer les resultats de son operation au pc , soit de fonctionner en autonome , a la mise sous tension il gere tout le processus a executer ( sans pc.. ).

je te demandais cela pour etre sur que le programme que tu as dans le pic soit fonctionnel , mais il semble que oui , puisque il marche avec ton terminal .

En fait c'est koi ton terminal , aussi un pc ? , une maquette qui pilote le pic ? ...
quand tu fais ta manip tu change juste la prise du port serie , elle passe du terminal au pc , ou tu utilise un autre cordon ... ( çà semble bete que je dise çà mais des fois..!! )

j'ai pas le datasheet de ton pavé ( HIN232Cp) sous la main pour l'instant
ni meme du pic que tu utilise ( je suis en vacances :D ) , mais je doute que ce soit un probleme d'adaptation ..

par contre une idée bete qui me passe par la tete !! ah tu essayé de faire dialoguer simplement ton programme delphi avec le terminal tout deux possede aussi des port serie !! et peut etre plus simple a visualiser le probleme que dans le pic ..
06/08/2004, 11h45
Le Lézard

Une autre chose très importante : Les notions ETCD et ETTD (ou DCE et DTE in english...).

Il faut que tu définisses le type de tes equipements terminaux (un terminal est généralement ETTD)

Si tes 2 equipements (PC et PIC) sont du même type, il te faut un câble croisé, s'ils sont de type différent, il te faut un câble droit.
Le câble croisé est également appelé NULL MODEM.

Je n'ai pas le schéma sous la main, mais tu le trouveras sans problème sur le net...
06/08/2004, 17h46
JeanPh

Alors le terminal que j'utilise, est un programme terminal genre l'hyperterminal (mais ce n'est pas l'hyperterminal).

Il est donc sur mon PC et j'utilise le même cable et le même port COM.

En ce qui concerne le type de cable, la j'ai un cable PIC vers PC qui est mâle-femelle mais, j'utilise un adaptateur série-USB, donc je ne sais pas si il est croisé ou direct.... m'y connais pas du tout.

Si quelqu'un a une autre idée ou une autre suggestion pour m'aider il est le bienvenu :D
09/08/2004, 22h56
JeanPh

Ok c'est résolu. Le problème se situait au niveau du programme du PIC qui n'attendait pas le bon type de variable. (Enfin ca c'est l'explication en gros parce que ce n'etait pas aussi clair que ca en à l'air :? , fallait voir l'utilisation de la commande serin en basic, soit....)

Toujours est-il que je remercie tous ceux qui ont essayé de m'aider !! :D