electro575 a écrit 828 commentaires

Merci à toi

Je pensais peut être qu'avec la description suivante, que je puisse utiliser la fonction udev_monitor_filter_add_match_tag(struct udev_monitor *udev_monitor, const char *tag);

TAG : Attach a tag to a device. This is used to filter events for users of libudev's monitor functionality, or to enumerate a group of tagged devices. The implementation can only work efficiently if only a few tags are attached to a device. It is only meant to be used in contexts with specific device filter requirements, and not as a general-purpose flag. Excessive use might result in inefficient event handling.

Par contre, j'aurais dit comme ceci la syntaxe mais je ne suis pas sur :

ATTRS{idVendor}=="", ATTRS{idProduct}=="", SYMLINK+="", TAG:="essai", MODE:=""

Liens :
LibUdev
Syntaxe_rules

Oui j'ai lu cette page mais pas entièrement.

L'outil udevadm est bien utile.

Je connais déjà le subsystem et le devtype de mon appareil grâce à un programme, je cherche plutôt à mettre un TAG ou alors créer un groupe dans le .rules afin de noter plusieurs périphériques particuliers dont j'aimerais noter les caractéristiques dans mon interface.

Pour le TAG j'ai :
udev_monitor_filter_add_match_tag (struct udev_monitor *udev_monitor, const char *tag);

Pour Subsystem et Devtype j'ai :
udev_monitor_filter_add_match_subsystem_devtype (struct udev_monitor *udev_monitor, const char *subsystem, const char *devtype);

Avec d'autres paramètres je ne peux rien faire. Comme ajouter un groupe je ne sais pas si ça va changer Devtype par exemple…

Voila le lien de la libudev : libudev

Avec ce lien, je ne pense pas qu'il existe de bibliothèque Qt permettant la discussion par USB sur toutes les platformes.

Texte du lien

Problème : la lib qui récupère les infos de mon matériel n'est pas compilable en C++

Solution :
-soit faire un programme pour la gestion de l'USB sous Linux
-soit utiliser une bibliothèque QtCreator pour l'USB, peut être QSerialPort pour gérer l'USB pour toute les platforme et appeler ensuite le programme qui va interroger le matériel.

La deuxième solution serait l'idéal.

Ha ben j'ai pas penser directement passer par une lib Qt pour discuter depuis tous les OS en USB mais effectivement …

Je vais me diriger vers cette option multiplatforme.

Un grand merci, je vous ferais un retour dès que ça fonctionne!

Bonne fin de semaine à vous tous

Solution, connaitre le PID sous le processus lancé de l'interface.cpp !

Peut être que j'arriverai à faire quelque chose et encore c'est pas trop sur

Je comprends ce qu'il veut faire sauf pour monusb.sh et la ligne de code suivante :

/bin/stty -F /dev/$1 57600

fichier /etc/udev/rules.d/70-monusb.rules :

    UBSYSTEMS=="usb", KERNEL=="ttyUSB?",
    ATTRS{interface}=="??",MODE="0666", SYMLINK+="monusb", RUN+="/bin/monusb.sh %k"**

fichier /bin/monusb.sh :

    #!/bin/bash

    sleep 1

    /bin/stty -F /dev/$1 57600
    /bin/stty -F /dev/$1 -icanon
    /bin/stty -F /dev/$1 min 1

L'inconvéniant est que sous QtCreator, je sais lancer un processus en parallèle (ou fils) et lire la sortie standard du processus fils avec l'entrée standard du processus père.

Maintenant, je veux bien lancer un script depuis le .rules avec la commande RUN+="…"
Le souci c'est que je ne sais pas comment créer un tube entre le processus lancé depuis le .rules et le processus père (interface.cpp)

Désolé pour l'affichage … c'est du copie colle!

Pour l'USB dumping, je ne connais pas le langage python mais peut être que je vais m'y mettre.

Je viens de le décompresser !

Des astuces pour compiler tout ça ? comment on se sert des fichiers pythons

Après une lecture du site d'ubuntu à propos de Udev et de la syntaxe des fichiers .rules, je pense qu'il suffi de surveiller avec un démon si un fichier se créé au chemin /dev/truc et après lancer les commandes à partir d'un fichier.

Je ne sais pas si surveiller en permanence si un fichier existe peut poser problème, ou s'il se créé !

En te remerciant. Je vais regarder tout ça ce matin

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