Liaison entre programmes

Version imprimable

06/07/2006, 14h43
Charlock

Liaison entre programmes

Bonjour à tous !

J'aurais aimé savoir comment il était possible de transférer des données d'un programme vers un autre.

En fait, je souhaite réaliser un programme qui gére un réseau de train miniature par l'intermédiaire du port parallèle. Le PC est relié à une carte avec un PIC.
Le problème est le suivant : les données arrivent sur le port parallèle à une cadence donnée. Je pensais donc réaliser un programme synchrone avec cette cadence qui se contente d'enregistrer les données (que le PIC lit 3 par 3 et donc que le PC recoit 3 par 3) dans un tableau. Un autre programme s'occuperait de gérer les automatismes (ex: mettre un feu au rouge si tel train est passé à tel endroit) et enfin un dernier programme serait chargé d'envoyer les données à la carte (en gérant les données prioritaires par exemple, etc.).

Donc j'aurais voulu savoir comment faire communiquer ces trois programmes (écrits en C) entre eux...

J'espère avoir été clair :?

Merci !

Charlock
06/07/2006, 14h51
ronan99999

Par réseau tcp udp
Par fichier pipe etc...
Tu peux regarder autrement la MPI.
http://fr.wikipedia.org/wiki/Message_Passing_Interface

Mais peut etre faut'il que tu repenses ton programme en terme de processus légers, pourquoi trois exe différents, si ils sont sur la meme machine.
06/07/2006, 14h53
joellel

Sous quel système d'exploitation travailles tu?
06/07/2006, 14h57
Médinoc

Euh, là, on dirait que pratiquement toutes ces données sont partagées à un moment ou un autre.

Là, je te conseillerais de faire une seule application, mais multithreadée.
(Un processus, trois threads).
06/07/2006, 15h22
Charlock

Merci à tous !

Citation:

Mais peut etre faut'il que tu repenses ton programme en terme de processus légers, pourquoi trois exe différents, si ils sont sur la meme machine.

Bah justement c'est peut être là le problème !! C'était la première solution qui m'était passée par la tête.

Citation:

Sous quel système d'exploitation travailles tu?

Je sais pas encore sur quoi je vais le faire, vu qu'il faut que je me dégotte un PC de récup. Donc peut etre MS-DOS, ou Linux. Pas Windows en tout cas :P

Citation:

Euh, là, on dirait que pratiquement toutes ces données sont partagées à un moment ou un autre.

Là, je te conseillerais de faire une seule application, mais multithreadée.
(Un processus, trois threads).

Ca sonne bien ca :lol: Je vois l'idée mais je m'y connais pas du tout dans ce domaine. Tu peux expliquer un tout petit peu plus stp ?
06/07/2006, 15h41
Médinoc

Thread == processus léger.

Donc, dès le début de ton programme (le main() est le thread principal), tu crées tes buffers partagés, puis tu lances deux threads supplémentaires (avec pthread_create() sous unixoïde, _beginthreadex() sous Windows), comme ça tu te retrouves avec trois threads, qui peuvent tous les trois manipuler les buffers.
--> Un thread pour chacune des trois tâches.

Pour la copie des données reçues par le premier thread, tu devras sûrement utiliser un verrou (pour empêcher le premier thread de modifier pendant que le second lit, et permettre au second de vider le buffer).
Sous unixoïde, les verrous sont des mutex (pthread_mutex_init() ou pthread_mutex_create()), sous Windows, on utilise des CRITICAL_SECTION (InitializeCriticalSection()).
Note: le verrou doit être créé en même temps que les buffers partagés, pour être passés aux threads.
06/07/2006, 15h53
Charlock

OK merci beaucoup !

Je dois t'avouer que ca m'a l'air très très compliqué. Mais bon en reprenant ca au calme et après de plus amples recherches sur internet, j'ai bon espoir !
06/07/2006, 20h41
Emmanuel Delahaye

Citation:

Envoyé par Charlock

Je sais pas encore sur quoi je vais le faire, vu qu'il faut que je me dégotte un PC de récup. Donc peut etre MS-DOS, ou Linux. Pas Windows en tout cas :P

Windows, c'est le Diable !
http://www.dr-pepper.de/images/xp_bo...ilInside_s.jpg
06/07/2006, 20h49
Pragmateek

On peut aussi utiliser les "pthread" sous Windows.
07/07/2006, 10h22
Médinoc

Oui, mais pas sans bibliothèque.

Emmanuel : Je crois que c'est pour une question d'accès au port parallèle : La plupart des applications hors-imprimante utilisent le port parallèle à bas niveau, chose impossible sous WinNT à moins de développer un "kernel-mode driver".

Charlock : Par contre, tu peux utiliser un windows non-NT (mais il faut désactiver toute optimisation sur le source qui effectue les accès au port).
07/07/2006, 11h58
gnto

Citation:

Envoyé par Médinoc

Oui, mais pas sans bibliothèque.

Hum pour faire des thread il faut toujours utiliser une bibliothèque nan ?

Citation:

Envoyé par Médinoc

Emmanuel : Je crois que c'est pour une question d'accès au port parallèle : La plupart des applications hors-imprimante utilisent le port parallèle à bas niveau, chose impossible sous WinNT à moins de développer un "kernel-mode driver".

Il me semble que sous NT, c'est le HAL qui bloque la connexion car il faut certains droits. Faire un driver sous windows, il faut acheter le DDK(device driver kit) nan ?

Citation:

Envoyé par Médinoc

Charlock : Par contre, tu peux utiliser un windows non-NT (mais il faut désactiver toute optimisation sur le source qui effectue les accès au port).

ui, ca fonctionne :ccool:
07/07/2006, 16h58
Médinoc

Citation:

Envoyé par gnto

Hum pour faire des thread il faut toujours utiliser une bibliothèque nan ?

Pas sous Win32 en tout cas (à moins que tu ne considères l'API système comme une bibliothèque).
07/07/2006, 20h19
Pragmateek

Citation:

à moins que tu ne considères l'API système comme une bibliothèque

C'est le même principe:une interface de programmation rassemblant des fonctionnalités permettant un bon niveau d'abstraction.
Sinon quelles sont les différences notables?
08/07/2006, 14h11
Médinoc

Pour moi, l'API système a l'avantage suprême d'être toujours présente de base sur le système en question (et dans tous les SDK pour ledit système), surtout lorsqu'il s'agit des modules indispensables ne serait-ce qe pour lancer le programme (à commencer par kernel32.dll, qui justement est contient toute l'API pour les threads). Donc, dès qu'on programme sous Win32, on a le multithreading à portée de main.
De plus, sous Win32, tout est géré "au niveau thread" : Il n'y a pas de fonction d'attente bloquant un processus entier (j'ignore si c'est ou non le cas sous Linux)

À ce sujet, j'ai une petite question au sujet des pthreads sur linux: Dans le cas où les fonctions système d'attente de Linux bloquent uniquement le thread courant et non tout le process, c'est que Linux supporte directement les threads (comme Win32) et que libpthread.a n'est qu'une interface, non?

PS: C'est dans " Thread POSIX et gestion mémoire" qu'on voit l'utilité de gérer les threads (et le reste) par des handles...