electro575 a écrit 841 commentaires

Okey, je vais regarder ça dès que j'ai du temps.

En te remerciant, bonne journée à toi

J'ai remplacé mon code pere.cpp :

        char buf [10];

        FILE *pp;

        pp = popen("/home/jo-pc/Bureau/STAGE/Projet_spectro/pipe/test_3/fils", "r");

        if (pp == NULL)
        {
                perror("popen");
                exit(1);
        }
        printf("etape1");
        while (fgets(buf, sizeof(buf), pp))
                fputs(buf, stdout);
        pclose(pp);
        printf("etape2");
        printf("%s",buf);

Ainsi, j'ai :
etape1coucou
etape2coucou

Je pense donc que c'est correcte. popen créé un pipe entre les deux fichiers et lit sur l'entrée standard du process fils.

Autre méthode qui marche pour le pere.cpp via ce lien en utilisant les E/S standard : Texte du lien

#include <stdio.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>

#include <fcntl.h>
#include <sys/stat.h>

#include <iostream>
#include <string>
#include <fstream>

using namespace std;

//#define BUFSIZ 20

int main()
{
 /* create the pipe */
 int  fds[2];
 if (pipe(fds) == -1)
   {
     printf("pipe failed\n");
     return 1;
   }

 /* create the child */
 int  pid;
 if ((pid = fork()) < 0)
   {
     printf("fork failed\n");
     return 2;
   }

 if (pid == 0)
   {
     /* child */
     //char buffer[20];

     close(fds[0]);
     dup2(fds[1], STDOUT_FILENO);
     execl("/home/jo-pc/Bureau/STAGE/Projet_spectro/Projet_spectro_1/Test/Acquisition","Acquisition",NULL);
     close(fds[1]);


   }
 else
   {
     /* parent */
     waitpid(pid,NULL,0);
     char buffer[1000];

     close(fds[1]);
     dup2(fds[0], STDIN_FILENO);

     while (read(fds[0], buffer, 1000) != 0)
       printf("%s\n", buffer);

     close(fds[0]);

       //printf("%s", buffer);       printf("%s", buffer);       printf("%s", buffer);
    std::cout << buffer << std::endl;

   }

 return 0;
}

Ca fonctionne bien pour le moment. Je vais continuer d'exploiter ceci. Je fairais un retour. Merci beaucoup

Une solution à mon problème existe. La fonction popen, elle permet de créer un pipe entre deux fichiers et remplace les fonctions fork, execl, dup2, …

pere.cpp :

    int main()
{
        char buf [10];

        FILE *pp;

        pp = popen("fils", "r");

        if (pp == NULL)
        {
                perror("popen");
                exit(1);
        }
        while (fgets(buf, sizeof(buf), pp))
                fputs(buf, stdout);
        pclose(pp);

return 0;
}    

fils.c :

    int main()
{
        fprintf(stdout,"coucou\n");
        fflush (stdout);
    return 0;
}    

On obtient bien coucou de la part du fils sur la sortie standard (console)!
L’inconvénient c'est que je ne maitrise pas ce que je fais avec cette fonction.

Je ne sais pas si passer par la sortie standard c'est très approprié … ce n'est peut être pas très propre à la longue!
Je vais chercher du côté des redirection de tube ou de la mémoire partagée pour deux processus afin de garder la déclaration du descripteur pour le fils une fois execl dans le père lancé.

C'est tout à fait le genre de méthode que je voulais utiliser. Je viens de tester avec un execl vers mon acq.c pour écrire le fichier texte. Celui-ci ne s'écrit pas.

J'aurais tendance à croire que acq.c se termine sans même écrire le fichier texte alors que derrière interface.cpp attend la fin d'un processus fils!

C'est assez étrange. On m'a dit que pour l'écriture d'un fichier texte, l'écriture se fait en priorité assez basse. Du coup d'autres choses dans l'OS se font avant.

Une histoire de permission du processus fils pour écrire un fichier texte?

Solution :
-chercher une option pour forcer l'écriture sans attendre
-permission plus élevé pour le programme

Acq devrait prendre des parametres oui.

Pour le moment je n'en ai pas mis pour simplifier le tout.

Pour execl c'est ce que je fais avec un fork lorsque je suis dans le processus fils.

Le souci c'est que je dois pouvoir appuyer sur un bouton via une interface graphique interface.cpp codé en C/C++ pour faire des acquisitions en continue.

1-fichiers textes -> ne fonctionne pas car le fichier texte n'est pas créé par le fils
2-tube nommé -> bloque le fils et le pere en etat de processus sommeil S
3-tube classique -> si execl remplace le processus, je perds le descripteur du tube peut être

Des threads peut être?

Interface.cpp doit envoyer des paramètres d'acquisition à acq.c afin de faire une acquisition sur un matériel.
Acq doit retourner les valeurs du matériel.

J'ai essayé de faire le lien avec de simple fichiers texte sans lancer les processus "en même temps". Ceci fonctionne mais ça n'est pas ce qui est voulu.
Une interaction temps réel serait nécessaire.

La commande execl permet de remplacer le processus fils par acq.

Pour les fichiers textes, j'ai essayé mais le fichier acq.c ne créé par le fichier texte et le processus père continu. Apparement pour le fichier texte, la solution ne fonctionne pas.
1-fichiers textes
2-tubes nommés
3-tubes classiques
…

Les tubes nommés sont bloquants. Je m'en sors pas :/

Si lorsqu'on remplace le processus fils par celui d'acq avec execl, le contenu déclaré depuis le début dans affichage.cpp est toujours valable, le processus fils saurait trouver le tube créé dans le père. Ca je ne sais pas.

Ben j'ai juste l'appel du programme acquisition.c qui ne fonctionne pas.

Si je lance les deux programmes separement ca fonctionne.

Le tube nommé est écrit par acq.c et lu & affiché par interface.cpp

Merci pour ta precision

Je m’intéresse à ça pour mon stage plutôt. J'ai besoin d'un .c pour récupérer des données depuis un matériel mais sa bibliothèque n'est pas compatible avec g++ …
Du coup je dois scinder mon travail ! Quelle chance^, ça me retarde un peu mais j'en apprends également.

Je cherche a récupérer des données d'un fichier acquisition.c.
1-Pour cela j'envoie des arguments depuis le programme interface.cpp vers acquisition.c avec la commande execl. Ça m'évite de créer un tube nommé et de traiter la chaine de caractères, en plus cette méthode ne fonctionne pas très bien malheureusement.
2-Le programme acquisition.c fait l'acquisition des données et créé un tube nommé et écrit dessus.
3-Le fichier interface.cpp vient lire le tube nommé.

CODE :

Syntaxe de execl :
execl("chemin d'accès/prog","prog","arg1","arg2",…,NULL);

Programme :

    #include "mainwindow.h"
    #include "ui_mainwindow.h"

    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>

    #include <iostream>
    #include <string>
    #include <fstream>

    #include <qwt_plot_curve.h>
    #include <QColorDialog>

    #include <fcntl.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <sys/stat.h>
    #include <sys/types.h>

    using namespace std;

    //CONSTRUCTEUR
    MainWindow::MainWindow(QWidget *parent) :
        QMainWindow(parent),
        ui(new Ui::MainWindow)
    {
        ui->setupUi(this);
    }

    //DESTRUCTEUR
    MainWindow::~MainWindow()
    {
        delete ui;
    }

    void MainWindow::on_pushButton_clicked()
    {
        execl("/home/jo-pc/Acquisition","Acquisition",temps_integration,NULL);

    //lecture du tube :
    double tmp2=0;
    cout << "essai3" <<endl;
    int fd2;
    FILE *fp2;
    cout << "essai4" <<endl;
    char *nomfich2="/home/jo-pc/Bureau/test2.txt", chaine2[50];
    cout << "essai5" <<endl;
    fd2 = open(nomfich2, O_RDONLY); /* ouverture du tube */
    cout << "essai6" <<endl;
    fp2=fdopen(fd2, "r"); /* ouverture du flot */
    cout << "essai7" <<endl;
    fscanf(fp2, "%s", chaine2); /* lecture dans le flot */
    cout << "essai8" <<endl;
    //tmp2 = strtod (chaine2,NULL);
    cout << "essai9" <<endl;
    cout << chaine2 << endl;
    cout << "essai10" <<endl;
    //printf("%lf\n",tmp2); /* affichage */
    unlink(nomfich2); /* fermeture du flot */
    cout << "essai11" <<endl;

    }

Quelques warnings :

mainwindow.cpp:86: avertissement : deprecated conversion from string constant to 'char*' [-Wwrite-strings]
         char *nomfich2="/home/jo-pc/Bureau/test2.txt", chaine2[50];
```                 ^

Je compile avec g++ 64 bits sous QtCreator.

Voila voila

Pour le moment le programme se termine "subitement". Le programme s’arrête à l'affichage d'essai 7. Il ne passe pas cette ligne :     fscanf(fp2, "%s", chaine2); /* lecture dans le flot */

Tu as raison oui, c'est ce que j'ai fait par la suite.

Bonne journée à toi

Merci pour la documentation, je note ton site internet pour regarder ça.

Bonne journée à toi

C'est plus par "habitude" pour le sudo car parfois quelques commandes ne s'exécutent pas autrement qu'avec les droits de l'administrateur.

Le module nécessaire était présent mais il fallait en fait changer deux paquets de ligne de code pour que mon adaptateur soit reconnu et pour enlever une erreur.

Merci pour ta précision pour lsusb.

J'ai réussi à faire fonctionner le driver mais en règle général tout se compile avec des makefile car on a trop de dépendance entre les fichiers. Desfois ça peut être utile de savoir comment créer un makefile.

Bonne journée à toi et merci

include linux/version.h
//include linux/config.h
ifdef CONFIG_USB_DEBUG
define DEBUG
endif
include linux/module.h
include linux/kmod.h
include linux/sched.h
include linux/init.h
include linux/netdevice.h
include linux/etherdevice.h
include linux/ethtool.h
include linux/workqueue.h
include linux/mii.h
include linux/usb.h
include linux/crc32.h

J'essai de faire la cross compilation d'un driver que j'ai trouvé et qui devrait je pense bien marcher.

Lorsque j'essai de faire une cross-compilation du driver, il me demande les .h nécessaire !!!

jo@008:~/Bureau/embedded/projet_elektor/AX88772B_772A_760_772_178_LINUX_Driver_v4.4.1_Source$ sudo arm-linux-gnueabi-gcc -o asix asix.c
asix.c:29:26: erreur fatale: linux/module.h : Aucun fichier ou dossier de ce type
compilation terminée.
jo@008:~/Bureau/embedded/projet_elektor/AX88772B_772A_760_772_178_LINUX_Driver_v4.4.1_Source$

Je pense prendre ceux du noyau linux embarqué mais je ne sais pas ou les prendre

Le problème c'est que j'ai juste fait une commande :

make zImage -> /driver/net/usb/asix.c créé

make modules -> /drover/net/usb/asix.ko créé

Autrement je ne sais rien de plus. Juste qu'ils utilisent une chaine d'outils armv5-qte-5.0 à l'aide de ce script :

P1=/opt/eldk-5.0/armv5te/sysroots/i686-oesdk-linux/usr/bin/armv5te-linux-gnueabi/
P2=/opt/eldk-5.0/armv5te/sysroots/i686-oesdk-linux/bin/armv5te-linux-gnueabi/

export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
export PATH=$P1:$P2:$PATH

Oui tu as raison, j'aimerais compiler le driver fourni par le constructeur en cross compilation pour ma carte linux elektor mais je ne sais pas trop comment m'y prendre et quelles étapes lancer.

En fait j'utilise le noyau qu'ils ont donné pour le projet pour le moment. J'ai trouvé un driver mais il faudrait que j'arrive effectuer une cross compilation avec pour ma carte linux elektor.

Malheureusement je ne sais pas trop comment procéder.