Le document traite du développement d'applications sous Linux embarqué, expliquant que les compétences acquises sur un système Linux ordinaire sont applicables. Il présente les langages de programmation couramment utilisés, notamment le C et le C++, ainsi que les bibliothèques associées. Enfin, il aborde les concepts de gestion des fichiers, des entrées/sorties, des scripts shell et de la hiérarchisation des fichiers dans un système Linux.

1. Linux embarqué
Développement d'applications dans
Linux embarqué

2. ➢
Un système Linux embarqué n'est autre qu'un système Linux normal, avec
généralement une petite sélection de composants.
➢
En termes de développement d'applications, développer sur Linux
embarqué est exactement le même que le développement
sur un Linux ordinaire.
➢
Toutes les compétences acquises peuvent être réutilisés , sans adaptation
particulière.
➢
Toutes les bibliothèques existantes peuvent être intégrées dans le système
Linux embarqué en tenant compte , bien sûr , de la limitation des systèmes
embarqués en termes de performances , du stockage et de la mémoire.
Linux embarqué

3. Langages de programmation
➢
Le langage de programmation par défaut des applications sous Linux est généralement
le langage C.
➢
La bibliothèque C est déjà présente sur le système, rien à ajouter.
➢
Le C ++ peut être utilisé pour des applications plus importantes ;
– La bibliothèque C++ doit être ajouté au système
– Certaines bibliothèques, y compris Qt, sont développés en C ++ elles ont ainsi besoin
de la bibliothèque C++.
➢
Les langages script peuvent également être utiles pour un rapide développement d'application
ou pour les applications Web.
– Mais ils ont besoin d'un interpréteur sur le système embarqué et ont généralement une plus
grande consommation de mémoire et on une performance légèrement inférieure.
➢
Langages: Python , Perl , Lua , Ada , Fortran , etc.

4. Bibliothèque C
➢
Pour de nombreuses applications , la bibliothèque C donne déjà un
ensemble relativement grand de fonctionnalités
– fichiers et périphériques d'E / S , le réseau, les threads et la
synchronisation, la communication inter-processus, etc...
– Largement décrites dans le manuel de la « glibc », ou dans tout
livre de programmation sous Linux

5. ➢
Sur un système Linux, la notion de fichiers est généralisée.
➢
Ceci permet de modéliser des concepts poussés (communications réseaux,
interactions avec un périphérique...) par le biais d'un fichier.
➢
Un système Linux modélise un certain nombre de concept abstraits par le
biais de fichiers.
– Ainsi un fichier Linux n'a pas forcément d'existence réelle sur le média
de stockage (disque dur...).

6. Accès aux fichiers en C
Pour accéder à un fichier en C, il faut d'abord l'ouvrir.
L'opération d'ouverture fait le lien entre un fichier désigné
par son chemin dans l'arborescence et une variable du
programme appelée descripteur de fichier.
Le descripteur de fichier sera ensuite passé en paramètre
de chaque fonction d'écriture ou de lecture dans le fichier.
Type du descripteur : int
Après l'accès, le fichier sera fermé par le programme.

7. Écrire dans un fichier
Déclaration d'un descripteur :
int fichier ;
1) Ouverture :
fichier = open( "toto.txt" , O_WRONLY | O_CREAT, 0644 ) ;
Cette opération :
1/ Crée un fichier vide (si le fichier n’existe pas) dont le chemin
est toto.txt.
On peut utiliser, soit le chemin absolu (par rapport à la racine /),
soit le chemin relatif par rapport au répertoire courant.
2/ Associe le descripteur fichier au fichier toto.txt.C'est la seule
ligne où va apparaître le chemin du fichier.
Ensuite c'est le descripteur qui sera utilisé pour accéder au fichier.

8. Fonction open
open
#include <fcntl.h>
int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t mode);
The open() system call opens the file specified by pathname. If the specified file
does not exist, it may optionally (if O_CREAT is specified in flags) be created
by open().

9. Modes d'ouverture
Flags:
O_RDONLY : file read-only
O_WRONLY : write-only
O_RDWR : read/write
In addition, zero or more file creation flags and file status flags can be bitwise-or'd in flags.
The file creation flags are :
O_CLOEXEC, O_CREAT, O_DIRECTORY, O_EXCL, O_NOCTTY, O_NOFOLLOW,
O_TMPFILE, and O_TRUNC.
Mode : argument specifies the file mode bits to be applied when a new file is created.
u g o
User group others
1- r : read 2- w : write 3- x : execute

10. Modes d'ouverture

11. Écrire dans un fichier
L'opération d'ouverture d'un fichier peut échouer :
média protégé en écriture, disque plein, pas de droit
en écriture dans le répertoire, lecteur absent,...
Dans ce cas open retourne la valeur -1 (descripteur invalide).
Il ne faut alors pas tenter d'écrire sinon le programme plante.
if (fichier != -1 ) {
// écriture possible
}
else
{
// échec d'ouverture
// écriture impossible
}

12. Écrire dans un fichier
Après avoir ouvert le fichier et n'avoir pas obtenu -1,
on peut utiliser la fonction write pour écrire dedans.
write ( fichier , "bonjour !n", strlen( "bonjour !n")) ;

13. Écrire dans un fichier
Exercice :
Soit le code c suivant :
Éditer ce code en utilisant l’éditeur
de texte "geany". (le fichier sera
nommé "writefich.c")
Compiler et linker avec le
compilateur "gcc".
Exécuter le code dans un terminal
comme :
./writefich linux test.txt
Quel est le résultat.

14. Écrire dans un fichier
Sous linux il y a le répertoire :
/sys/class/leds/input4::capslock/
C’est un répertoire virtuel qui représente la
led de la touche majuscule sur le clavier.
Ce répertoire contient le fichier "brightness"
qui permet d’allumer ou d’éteindre cette
diode. L’appelle du fichier "writefich"
comme suit permet de l’allumer :
./writefich 1 /sys/class/leds/input4::capslock/brightness
Tester ce programme.
Note : cette action nécessite les privilège administrateur. On peut passer en mode "root"
en tapant la commande "sudo su" ou précéder la commande par "sudo".

15. Shell Script (langage interprété)
Le programme de l’exercice a été interprété et exécuté par un programme qui
fait partie du système d’exploitation c’est l’interpréteur de ligne de commande
« shell bash ». Ce dernier peut exécuter une seule commande (programme)
comme il peut exécuter un ensemble de commande dans un fichier dit script.
●
Shell script est un langage a part entière (boucles : for, while, tests : if, switch …)
●
Un fichier shell script doit avoir l’extension .sh ou .bash et doit commencer par
une ligne qui indique l’endroit où trouver l’exécutable "sh" ou "bash" de la forme
#!/bin/sh
Qui indique que le « sh » existe sous le répertoire /bin dans l’arborescence du
système d’exploitation Linux.

16. Shell Script (langage interprété)
Le fichier shell script possède la structure suivante :
#!/bin/sh
# ceci est un commentaire
Corps du programme
Pour continuer une ligne utiliser
Ceci est le début d'une ligne
exit 0

17. Shell Script
Rendre le fichier exécutable
chmod +x scriptfile.sh
Exécuter le programme
./scriptfile.sh
Afficher les entées lorsque lues
sh -v scriptfile
Afficher les commandes exécutées
sh -x scriptfile
Les programmes shell utilisent parfois des fichiers temporaires dans /tmp et envoient
les sorties non désirées au /dev/null

18. Shell Script
Exercice :
Placer l’exécutable "writefich" dans le répertoire /bin/ cela permet de
l’exécuter de n’importe quel endroit (sans le ./).
Dans l’éditeur "geany" saisir le code suivant (le fichier sera nommé
toggle.sh) :

19. Shell Script
Rendre le fichier exécutable.
Exécuter le programme.
Utiliser la boucle "for" pour le langage script de syntaxe :
for i in {1 .. n}
do
command1
command2
commandX
done
Pour faire clignoter la diode 20 fois avec un délai de 1s entre l’allumage et l’extinction.

20. 20
Shell Script
Rendre le fichier exécutable
chmod +x scriptfile
Exécuter le programme
./scriptfile.sh
Afficher les entées lorsque lues
sh -v scriptfile
Afficher les commandes exécutées
sh -x scriptfile
Les programmes shell utilisent parfois des fichiers temporaires dans /tmp et
envoient les sorties non désirées au /dev/null

21. 21
Shell Script
Historique des shells Unix
●
Le 1ier
shell est le Thompson shell (en) : 1971 pour la première version d’Unix
– écrite par Ken Thompson l'un des créateurs d'Unix. Il a été remplacé par le Bourne shell, écrit
par Stephen Bourne, en 1977 pour la version 7 d'Unix.
●
En 1978, Bill Joy (étudiant à l'Université de Californie à Berkeley), crée csh (C shell) une évolution
du shell dont la syntaxe s'inspire de celle du langage C. Il permettait notamment la réutilisation de
l'historique des commandes. Une version plus moderne du Csh a été publiée sous le nom tcsh.
●
Le Korn shell (ksh) a été publié en 1983 par David Korn. Il est compatible avec le Bourne shell,
reprend certaines fonctionnalités de csh et ajoute des fonctions de scripts avancées disponibles
dans des langages plus évolués tel que le Perl.
●
Le Bourne-Again shell (bash) est apparu quant à lui en 1988. Il a été écrit par Brian Fox pour la
Free Software Foundation dans le cadre du projet GNU. C'est le shell de nombreuses
implémentations libres d'Unix, tel que les systèmes GNU/Linux. Il est compatible avec le Bourne
shell dont il se veut une implémentation libre.
●
Paul Falstad a créé Zsh en 1990 (étudiant à l'université de Princeton). Ce shell reprend les
fonctions les plus pratiques de bash, Csh, tcsh.

22. 22
Gestion des entrées/sorties et redirection
Redirection droite simple:
commande > fichier
Le résultat de l'invocation de la commande commande sera écrit dans le fichier fichier,
en écrasant le précédent contenu.
Exemple :
$: cat file
Welcome
$: echo "Hello world" > file
$: cat file
Hello world
Shell Script

23. 23
Gestion des entrées/sorties et redirection
Redirection droite double
commande >> fichier
Le résultat de l'invocation de la commande commande sera écrit dans le fichier
fichier, à la suite des données déjà présentes.
Exemple :
$: cat file
Welcome
$: echo "Hello world" >> file
$: cat file
Welcome
Hello world
Shell Script

24. 24
Gestion des entrées/sorties et redirection
Redirection gauche simple
commande < fichier
La commande commande va lire le contenu du fichier fichier au
lieu de lire sur l'entrée standard (clavier).
Exemple :
$: cat < file
Welcome
Shell Script

25. 25
Gestion des entrées/sorties et redirection
Redirection gauche double
commande << END
La commande commande va lire sur l'entrée standard jusqu'à ce que le mot suivant la
double redirection soit rencontré.
Exemple :
$: cat << TOTO
? foo
? bar
? moomoo
? TOTO
foo
bar
moomoo
Shell Script

26. 26
Gestion des entrées/sorties et redirection
Pipe
commande_1 | commande_2
Le résultat de la commande commande_1 va être redirigé dans l'entrée de la
seconde commande commande_2.
Exemple :
$:~/test$ echo "hello " > f2.tx $:~/test$ echo | (cat < f1.txt) >> f2.txt
$:~/test$ echo "world" > f1.txt $:~/test$ cat f2.txt
$:~/test$ cat f2.txt hello
hello world
$:~/test$ cat f1.txt
World
Shell Script

27. 27
Les variables d'environnement
Le shell utilise des variables d'environnement : (attention aux MAJUSCULES)
PATH : répertoires de recherche des exécutables ;
MANPATH : répertoires de recherche des fichiers de man ;
LANG : langue utilisée ;
HOME : dossier de base de l'utilisateur (appelé également home directory) ;
LOGNAME : nom de l'utilisateur ;
SHELL : shell utilisé ;
Shell Script

28. 28
Notion de fichier linux
TYPES DE FICHIERS
1) Les fichiers physiques : enregistrés sur le disque dur. Il s’agit des
fichiers que l’on a l’habitude de rencontrer ;
2) Les répertoires : sont des fichiers « noeuds » de l’arborescence pouvant
contenir des fichiers physiques ou d’autres répertoires.
3) Les liens : sont des fichiers spéciaux permettant d’avoir acces a un
fichier a plusieurs endroits de l’arborescence.
4) Les fichiers virtuels : ils n’ont pas de réelle existence physique; ils
n’existent qu’en mémoire. Ces fichiers, situés notamment dans le
répertoire /proc contiennent des informations sur le système (processeur,
disques durs, processus, etc…) ;
5) Les fichiers de périphériques : situés dans le répertoire /dev/,
correspondent aux périphériques du système (partition, cle usb, cdrom,
etc…).

29. 29
HIERARCHISATION DES FICHIERS
HIERARCHISATION DES FICHIERS
Pour assurer la compatibilité et la portabilité, les systèmes Linux respectent
l’unique norme FHS (File Hierarchy Standard). La hiérarchie de base est la
suivante
:
–
/
:
Racine du système
–
/
bin : contient des exécutables essentiels au système, employés par tous les
utilisateurs (par exemple, les commandes ls, rm, cp, chmod, mount, …)
–
/
boot : contient les fichiers permettant à Linux de démarrer
–
/
dev : Ensemble de répertoires et de fichiers système décrivant les
périphériques ce sont des vecteurs de communication entre le système et ses
périphériques
.
–
/
etc : Fichiers de configuration
–
/
home : Répertoires personnels des utilisateurs
.

30. 30
HIERARCHISATION DES FICHIERS
–
/
lib : Répertoire contenant les bibliothèques partagées utilisées par les
programmes du système et les logiciels
.
– /media : Contient les points de montages pour les médias amovibles.
– /mnt : Point de montage pour monter temporairement un système de fichiers.
– /proc : Ce répertoire représente le point de montage du pseudo système de
fichiers du noyau. Ce dernier contient des fichiers permettant d’accéder aux
informations sur le matériel, la configuration du noyau et sur les processus en
cours d’exécution.
– /root : Répertoire personnel du super-utilisateur
– /sbin : contient les exécutables système essentiels (par exemple la commande
adduser).
– /srv : Données pour les services du système

31. 31
HIERARCHISATION DES FICHIERS
– /tmp : contient les fichiers temporaires.
– /usr : Hiérarchie secondaire : Répertoire contenant les fichiers du système
partageables en réseau et en lecture seule. Le répertoire /usr contient de
nombreux sous-répertoires. On retrouve presque la même organisation que
sous la racine, mais le contenu est destiné aux utilisateurs plus qu’au système
lui-même.
– /var : Répertoire contenant toutes les données variables du système, celles
pouvant être modifiées à tout moment lors d’un fonctionnement courant du
système ou des applications qu’il supporte.
– /opt : Paquets pour applications supplémentaires, installées hors
gestionnaire de paquets.

32. 32
Interface GPIO du noyau Linux
Sur le plan interne, le noyau Linux implémente l'accès aux GPIO via un modèle
producteur/consommateur :
✔
pilotes qui produisent des lignes GPIO (drivers de contrôleurs GPIO)
✔
pilotes qui consomment des lignes GPIO (clavier, écran tactile, capteurs, etc.).

33. 33
Interface GPIO du noyau Linux
Sur le plan interne, le noyau Linux implémente l'accès aux GPIO via un modèle
producteur/consommateur :
✔
pilotes qui produisent des lignes GPIO (drivers de contrôleurs GPIO)
✔
pilotes qui consomment des lignes GPIO (clavier, écran tactile, capteurs, etc.).
fournit une API aux pilotes qui
tournent dans l'espace noyau et aux
applications de l'espace utilisateur.

34. 34
Interface GPIO du noyau Linux
Sur le plan interne, le noyau Linux implémente l'accès aux GPIO via un modèle
producteur/consommateur :
✔
pilotes qui produisent des lignes GPIO (drivers de contrôleurs GPIO)
✔
pilotes qui consomment des lignes GPIO (clavier, écran tactile, capteurs, etc.).
✗
Attribution du GPIO non liée à aucun processus => plusieurs
processus peuvent accéder à la même ligne GPIO.
✗
L’écriture sur plusieurs broches nécessiterait des opérations
open()/ read()/write()/close() à un grand nombre de fichiers
(exportation, direction, valeur, etc.).
✗
Interruptions des lignes GPIO pas fiable.
✗
Pas d'interface pour configurer la ligne GPIO (open-source,
open-drain, etc.).

35. 35
Interface GPIO du noyau Linux
Sur le plan interne, le noyau Linux implémente l'accès aux GPIO via un modèle
producteur/consommateur :
✔
pilotes qui produisent des lignes GPIO (drivers de contrôleurs GPIO)
✔
pilotes qui consomment des lignes GPIO (clavier, écran tactile, capteurs, etc.).
Chaque contrôleur de GPIO (gpiochip) aura un fichier caractères dans /dev =>
opérations (open(), read(), write(), ioctl(), poll(), close()) pour gérer et interagir
avec les lignes GPIO:
✔
Attribution du GPIO lié au processus qu'il utilise => améliorer le contrôle des
lignes GPIO utilisées par les processus de l'espace utilisateur.
✔
Possibilité de lircture/écriture sur plusieurs lignes GPIO à la fois.
✔
Possibillé de trouver les contrôleurs GPIO et les lignes GPIO en utilisant le
nom.
✔
Possibilité de configurer l'état de la broche (open-source, open-drain,...).
✔
Le processus d'interrogation pour détecter des évènements (interruptions à
partir des lignes GPIO) est fiable.

36. 36
Interface GPIO du noyau Linux
Sur le plan interne, le noyau Linux implémente l'accès aux GPIO via un modèle
producteur/consommateur :
✔
pilotes qui produisent des lignes GPIO (drivers de contrôleurs GPIO)
✔
pilotes qui consomment des lignes GPIO (clavier, écran tactile, capteurs, etc.).
Pour utiliser cette nouvelle interface il existe une bibliothèque et
un ensemble d'outils fournis par le projet libgpiod.

37. 37
Interface GPIO du noyau Linux

38. SSH
Une des grandes forces de Linux est que l'on peut s'en servir même si l'on est à
des centaines de kilomètres de la machine. Ce fonctionnement date de l'époque
d'Unix où il était nécessaire d'administrer des machines à distance.
Ce genre de manipulation est désormais possible grâce à l'internet

39. SSH
Configuration non sécurisée

40. SSH
Criptage
Décriptage

41. SSH
Configuration sécurisée

42. SSH
Connexions à distance : Secure Shell
➢
SSH est un protocole, devant sécuriser les communications
➢
En fait, SSH chiffre et compresse un tunnel de session qui sécurise les
données transmises (permet d’éviter les sniffers Réseaux)
➢
Non seulement le mot de passe est chiffré lors de la connexion, mais les
informations circulant sur le réseau entre les deux machines le sont aussi.
➢
SSH est composé d’un ensemble d'outils permettant des connexions
sécurisées entre des machines. Ces outils ont pour but de remplacer les
utilitaires de connexions classiques n'utilisant pas de chiffrage.
➢
Remplace : rcp, rlogin, rsh, telnet (ftp par sftp en SSH V2)

43. SSH

44. SSH

45. SSH

46. SSH

47. SSH

48. SSH

49. SSH

50. SSH

51. SSH

52. SSH
Connecter beaglebone black

53. Compilation croisée

54. Compilation croisée
Download and uncompress
gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf.tar.xz
Export PATH
export "PATH=/dir/of/gcc-linaro:$PATH"

55. Compilation croisée
Compile :
arm-linux-gnueabihf-gcc -Wall -c file.c
Build :
arm-linux-gnueabihf-gcc -Wall fileexec -o file.o
Send via scp :
scp fileexec root@192.168.7.2:/root
Execute remotly via ssh:
ssh root@1921.168.7.2 '/root/fileexec'

56. Compilation croisée

57. Espace noyau vs espace utilisateur
L'accès à la mémoire de l'ordinateur et aux ressources du processeur se font
généralement selon deux modes :
1. le mode « superviseur » : «espace noyau » ,
2. le mode utilisateur : « espace utilisateur ».
L'architecture x86 permet d'utiliser 4 niveaux d'accès au matériel, mais en
pratique deux sont utilisés :
●
ring 0, pour le noyau
●
ring 1, non utilisé
●
ring 2, non utilisé
●
ring 3, pour l'espace utilisateur

58. Espace noyau vs espace utilisateur
En mode superviseur, dédié au
fonctionnement du noyau, il y a un
accès direct à la mémoire et au
matériel, il faut donc un
fonctionnement sans failles.
L'espace utilisateur est contrôlé : les
ressources mémoires sont bornées et si
un dépassement mémoire apparaît, le
noyau va prévenir celui-ci, en
terminant le processus fautif.
Linux : monolithique avec chargement
de modules :
tout le code est dans l'espace noyau,
mais certaines parties du matériel sont
prises en charge par des modules qui
sont chargés dynamiquement.

59. Modules noyau
Ensemble d’outils pour manipuler les modules
=> modutils :
●
lsmod : listage des modules chargés dans le noyau,
●
insmod : insertion manuelle d’un module dans le noyau,
●
rmmod :extraction manuelle d’un module dans le noyau,
●
modprobe : insertion et extraction automatique d’un module dans le
noyau avec résolution des dépendances (chargement des autres modules
nécessaires),
●
modinfo : informations générales sur un module (ex : auteur, description,
paramètres...),
●
depmod : génère la liste des dépendances d’un ensemble de modules.

60. Compilation d'un module
Makefile

61. Compilation d'un module
Makefile
Le système kbuild va construire <hello1.o> à partir de
<hello1.c>,et après édition des liens, le résultat est <hello1.ko>.

62. Compilation d'un module
Makefile
Syntax :
make -C $KDIR M=$PWD [target]
$ KDIR fait référence au chemin d'accès au répertoire de la source du noyau
-C $KDIR
Le répertoire où se trouve la source du noyau."Make" va effectivement aller au répertoire
spécifié lors de l'exécution et va revenir quand il aura terminé.
M = $ PWD
Informe « kbuild » qu'un module externe est en cours de construction. La valeur donnée
à "M" est le chemin absolu du répertoire où le module externe (fichier kbuild) est situé.
$(shell uname ­
r) est utilisé pour construire le module en concordance avec le noyau en cours
d'éxécution.

63. Compilation d'un module
Makefile
Sibles :
make ­
C $KDIR M=$PWD [target]
modules :
La cible par défaut des modules externes. Elle a la même
fonctionalité si aucune cible n'est spécifiée
La valeur par défaut va construire le (s) module (s) situé (s) dans
le répertoire courant, donc aucune cible n'a besoin d'être spécifiée.
Tout les fichiers de sortie seront également générés dans ce répertoire

64. Compilation d'un module
Makefile
Sibles :
make ­
C $KDIR M=$PWD [target]
Clean :
Supprime tous les fichiers générés dans le répertoire du module
uniquement.

65. Code C d'un module

66. Code C d'un module
Fonction d'initialisation (hello_init).
Appelée lors du chargement du module.
Elle ne prend pas d'argument et renvoie un entier :
●
0 pour indiquer que tout s'est bien passé,
●
un nombre <0 pour indiquer une erreur
(le module n'est alors pas chargé).
La macro module_init(<fonction>) permet de déclarer
la fonction servant de fonction d'initialisation.
Par convention, on nommera la fonction d'initialisation
<module>_init.

67. Code C d'un module
fonction de nettoyage (hello_cleanup).
Appelée lors du déchargement du module.
Ne prend aucun argument et ne renvoie pas de valeur.
Comme précédemment, la macro
module_exit(<fonction>)permet de déclarer cette
fonction.
Par convention, son nom est <module>_exit.
Si aucune fonction de nettoyage n'est déclarée,
le module ne pourra alors pas être déchargé.

68. <
linux/gpio.h>
Documentation/gpio/gpio-legacy.txt
static inline int gpio_request(unsigned gpio, const char *label)
gpio doit être un nombre valide si non gpio_request retourne un
message d'erreur.
La fonction retourne 0 si succès, un nombre négatif en cas
d'erreur.

69. <
linux/gpio.h>
Documentation/gpio/gpio-legacy.txt
static inline int gpio_direction_input(unsigned gpio)
Configure gpio comme entrée logique.
La fonction retourne 0 si succès, un nombre négatif en cas
d'erreur.

70. <
linux/gpio.h>
Documentation/gpio/gpio-legacy.txt
static inline int gpio_direction_output(unsigned gpio, int value)
Configure gpio comme sortie logique avec value comme
valeur initiale.
La fonction retourne 0 si succès, un nombre négatif en cas
d'erreur.

71. <
linux/gpio.h>
Documentation/gpio/gpio-legacy.txt
static inline void gpio_free(unsigned gpio)
Libère gpio, ainsi d'autres modules (ou une application
dans l'espace utilisateur) peuvent l'utiliser

72. <
linux/gpio.h>
Documentation/gpio/gpio-legacy.txt
static inline int gpio_to_irq(unsigned gpio)
Associe un signal d'interruption à gpio préalablement
configuré comme entrée logique.
Retourne la valeur de l'interruption assigné à gpio

73. <
linux/gpio.h>
Documentation/gpio/gpio-legacy.txt
static inline void gpio_set_value(unsigned int gpio, int value)
Assigne à gpio la valeur value.
static inline int gpio_get_value(unsigned gpio)
Retourne l'état du gpio

74. <
linux/irq.h
>
int request_irq(unsigned int irq,
void (*handler)(int, void *, struct pt_regs *),
unsigned long flags,
const char *dev_name,
void *dev_id);
unsigned int irq
This is the interrupt number being requested.

75. <
linux/irq.h
>
int request_irq(unsigned int irq,
void (*handler)(int, void *, struct pt_regs *),
unsigned long flags,
const char *dev_name,
void *dev_id);
void (*handler)(int, void *, struct pt_regs *)
The pointer to the handling function being installed.

76. <
linux/irq.h
>
int request_irq(unsigned int irq,
void (*handler)(int, void *, struct pt_regs *),
unsigned long flags,
const char *dev_name,
void *dev_id);
unsigned long flags
A bit mask of options related to interrupt management.

77. <
linux/irq.h
>
int request_irq(unsigned int irq,
void (*handler)(int, void *, struct pt_regs *),
unsigned long flags,
const char *dev_name,
void *dev_id);
const char *dev_name
The string passed to request_irq is used in /proc/interrupts to show the owner of the
interrupt.

78. <
linux/irq.h
>
int request_irq(unsigned int irq,
void (*handler)(int, void *, struct pt_regs *),
unsigned long flags,
const char *dev_name,
void *dev_id);
void *dev_id
This pointer is used for shared interrupt lines.