Driver zigbee

[invite6ae216d1]

Salut tout le monde,
je veux transmettre des donnés entre deux pc via des modules zigbee connectés à chaque pc via les ports séries RS232.
Pour cela, j'ai besoin de développer un driver pour ces modules en langage c. Je sais qu'il existe des fonctions bien définit en c qui font la communication avec le port RS232 mais à l'instant je l'ai pas trouvé encore. Aussi, la notion de driver zigbee me semble un peu flous, ce que j'ai compris est que dans le driver je vais définir les adresses des modules, faire l'encapsulation des donnés suivant le protocole zigbee, faire le controle de flux.
Je serais très reconnaissant si vous m'aidiez.
Merci d'avance
-----

[Xoxopixo]

Bonjour,

un driver est spécifique au système d'exploitation.
Windows ? Linux ?

Apres, c'est une histoire de protocole entre l'interface RS232 et le programme C.

Dans le programme C, on n'accede pas aux ports directement avec les versions modernes de windows.
Il faut donc passer par les "commandes" fournies par le systeme d'exploitation. (fourni dans les librairies systems)
Voir ici, par exemple:
http://msdn.microsoft.com/en-us/libr...erialport.aspx

Pour du plus rustique et comprendre le fonctionnement :
http://mc-computing.com/languages/serialio.htm

Sous linux je pense sans l'affirmer que cette interface peut être géré autrement. Un numero de peripherique virtuel ? Je connais assez peu.

[invite6ae216d1]

Salut,
d'abord merci d'avoir répondu à mes questions.
Bon, pour le système d'exploitation, il s'agit de Linux.
Maintenant je suis en train développer un code source en c pour émettre et recevoir les donnés à travers le port RS232.
J'ai étudier le UART et je veux accéder aux registres correspondants d'émission et de réception.
Aussi, j'ai trouvé les deux fonctions outport() et intport() mais j'ai pas réussit à les utiliser, j'ai pas trouvé la bibliothèque correspondante en c.
Si quelqu'un a une idée, je suis reconnaissant s'il m'aide.

[Xoxopixo]

Bon, pour le système d'exploitation, il s'agit de Linux.

Bon, ça simplifie peut-être.
Sachant qu'on a Inport et Outport, inutile de faire appel à une bibliotheque quelconque, en tous cas si linux permet l'ecriture directe à ces ports.
Il ne reste plus qu'à savoir adresser les ports, c'est à dire trouver les numeros du port UART, qui permettent certaines fonctions, puis dialoguer par le protocole du RS232.
Le driver pour ainsi dire existe déja de toute façon.
L'interfaçage en soi est standard. Il n'y a rien à faire.

Ici on programme plutot le handshaking, les deux interfaces reliées par un cable entre les deux PC dialoguent.

Le programme dialogue donc avec son port.
Ce programme doit être symetrique peut-être, il doit pouvoir initier le dialogue, comme en être averti.
Le programme peut donc se mettre en attente d'un evenement, pour linux je connais pas bien commen ça fonctionne.
Ou alors il interroge l'interface régulierement.
Il doit y avoir une interruption BIOS aussi quelque-part, je ne sais pas si c'est utile.

C'est la partie délicate peut être.

Il ne faut pas oublier de configurer les ports aussi.
Dans le principe ici, sans forcement utiliser l'objet ici TMsComm.

' Open the serial port
  MSComm1.CommPort = 2              ' Set the port number
  MSComm1.Settings = "56000,N,8,1"  ' Set UART parameters
  MSComm1.PortOpen = True           ' Required, might lock port
  MsComm1.Output = "Text string"    ' Send data
  Buffer$ = Buffer$ & MSComm1.Input ' Read data

http://mc-computing.com/languages/serialio.htm

Avec test de parité ou pas, et la vitesse de transmission, 56000 par exemple ici.
Je ne cache pas que pour programmer ceci il vaut mieux bien s'impregner du standard, voir comment le flux transite, et savoir quoi ecrire ou lire et quand, dans chaque port.
A voir donc ceci.

Transmitter and receiver timing signals (pins 15, 17, and 24) are used only for a synchronous transmission protocol. For the standard asynchronous 8-bit protocol, external timing signals are unnecessary.

IMPORTANT: Signal names that imply a direction, such as Transmit Data and Receive Data, are named from the point of view of the DTE device. If the EIA232 standard were strictly followed, these signals would have the same name for the same pin number on the DCE side as well. Unfortunately, this is not done in practice by most engineers, probably because no one can keep straight which side is DTE and which is DCE. As a result, direction-sensitive signal names are changed at the DCE side to reflect their drive direction at DCE. The following list gives the conventional usage of signal names:

http://www.camiresearch.com/Data_Com...#anchor1155404

Et bien comprendre que tout ceci est symetrique,dans le cas présent.

C'est un peu ancien le protocole RS232, me concernant, il faudrait que je me replonge dans le détail, mais je ne doit pas avoir été trop approximatif, j'espère.
On me corrigera si necessaire.

[A voir en vidéo sur Futura]

[Jack]

Je déconseille également l'écriture directe des registres.

Quelques conseils pour gérer un port série sous linux ici.

A+