Meilleur moyen de copier des données du pilote du noyau vers le pilote de l'espace utilisateur

Question

J'ai un pilote de noyau qui lit actuellement les données d'un capteur. Maintenant je dois écrire une application d'espace utilisateur qui appellera l'API sensor_read() du noyau et enverra des données au nuage.

Comment puis-je exposer l'appel sensor_read() du noyau à l'espace utilisateur et lire ces données depuis l'espace utilisateur? Les données sont d'environ 10 octets.

Answer 1

Vous pouvez utiliser les appels IOCTL (ioctl/read) pour accéder aux fonctions du noyau à partir de l'espace utilisateur.

lien ci-dessous pour Référez échantillon: http://www.tldp.org/LDP/lkmpg/2.4/html/x856.html

Answer 2

Comment puis-je exposer appel noyau sensor_read() à l'espace utilisateur et lire ces données depuis l'espace utilisateur? Il est fort probable que vous utilisiez la structure de noyau IIO, car elle est spécialement conçue pour l'écriture de pilotes de capteurs. IIO expose les fichiers nécessaires pour votre pilote (dans /sys/bus/iio/ et /dev/iio*). Vous pouvez read() ces fichiers, ou poll() eux (pour gérer les interruptions). La documentation officielle est disponible here. Vous pouvez également utiliser certains pilotes existants comme référence, regardez ici: drivers/iio/.

Avant l'introduction du framework IIO, il était courant de fournir des fichiers sysfs pour les pilotes manuellement. Donc, si vous utilisez un noyau assez ancien, cela devrait être le moyen d'écrire le pilote: gérer votre bus (comme I2C) et les fichiers sysfs manuellement. Mais encore, le meilleur moyen est d'utiliser le nouveau noyau et IIO.

Je travaille sur un capteur Gyro + Accel. Le pilote Linux enverra des événements de type EV_MSC pour les deux

Il n'est pas inhabituel que la puce ait plus d'un capteur. Dans ce cas, vous devez créer deux pilotes différents: un pour l'accéléromètre, et un pour le gyro. De cette façon, vous aurez deux fichiers différents, un fichier par capteur.

Par exemple, regardez comment il est fait pour la puce LSM330DLC (accéléromètre + gyroscope):

• pilote Accel: drivers/iio/accel/st_accel_core.c
• pilote gyroscopique: drivers/iio/gyro/st_gyro_core.c

Les deux pilotes appellent iio_device_register() fonction de la fonction de sonde du pilote, qui crée les fichiers correspondants (que vous pouvez lire/interroger). Reportez-vous au documentation pour plus de détails. Selon ma compréhension, j'ouvrirai les deux périphériques d'entrée depuis l'espace utilisateur et je l'ajouterai ensuite à la liste des FD que nous voulons interroger. Alors, quand il y a un nouvel événement, comment puis-je déterminer si cet événement vient de Gyro ou d'Aceel?

Si vous êtes curieux de savoir comment gérer deux /dev/input/event* fichiers dans l'espace utilisateur, vous avez deux choix:

• en utilisant le blocage d'E/S: vous pouvez lire/les interroger dans les différentes discussions
• en utilisant des E/S non bloquantes: vous pouvez ouvrir ces fichiers comme O_NONBLOCK et seulement read() dans le même thread; si les nouvelles données ne sont pas encore disponibles - il retournera -1 et errno sera défini sur EAGAIN; vous pouvez faire les lectures en boucle infinie, par exemple

This réponse contient exemple de la façon de traiter le fichier d'entrée en C. Et here vous pouvez lire sur le blocage/non-blocage des E/S.

Answer 3

Il y a plusieurs façons d'accéder aux données des capteurs de l'espace du noyau vers l'espace utilisateur

1. Vérifier pilote approprié du capteur que vous avez utilisé. Vérifiez s'il supporte/fournit le support de sysfs.

2. vous pouvez lire les données de /sys/class/ interfaces. Vous devez vous assurer que les paramètres pertinents ont été exportés vers sysfs. Par exemple: Les capteurs de température doivent avoir des valeurs de température exportées (facteurs équivalents) dans l'entrée sysfs.

   Exemples (exemples ci-dessous sont des fictions seulement)

   cat /sys/class/hwmon/tempsensor/value

   cat /sys/class/hwmon/tempsensor/min_value

   cat /sys/class/hwmon/tempsensor/max_value

3. Dans certains pilotes, vous pouvez les lire ioctl/read/write APIs pour lire/données de capteurs d'écriture.