Discussion :

[Artemus24]

Salut à tous.

Je suis en train de me construire une bibliothèque 'C' de fonctions pour manipuler ma raspberry.
Afin d'accéder aux fonctionnalités de base, j'ai constaté qu'il est plus facile de le faire en assembleur qu'en 'C'.
Ce n'est pas toujours le cas, mais parfois, il est plus couteux de le faire en 'C' qu'en assembleur, en terme lignes à écrire.

Je cherche des conseils pour m'organiser autour de mes fonctionnalités de base en assembleur et comment les incorporer dans ma bibliothèque.

Cordialement.
Artemus24.
@+

[LittleWhite]

Bonjour,

Pouvez-vous donner un exemple de fonctionnalité que vous préférez faire en assembleur?
Le problème de l'assembleur, c'est que votre bibliothèque ne sera compatible qu'avec un Raspberry Pi donné (par exemple, le 4) et que si le 5 à un nouveau CPU, vous pourrez avoir des incompatibilités.

[chrtophe]

Vu que tu veux faire une bibliothèque C, le plus simple est de faire du code inline, mais voir tout d’abord la remarque de LittleWhite.

[Artemus24]

Salut à tous.

Pouvez-vous donner un exemple de fonctionnalité que vous préférez faire en assembleur?

J'ai développé un programme assembleur Bare Metal (sans système d'exploitation) pour tester le PWM de ma Raspberry Pi Zero W.
C'est ce petit programme que je désire transformer en fonctions afin de l'utiliser dans ma bibliothèque.

Il y a un autre sujet, celui de la gestion des interruptions.
Dans le cas d'un bouton poussoir, on peut se mettre à écouter le registre "EVENT" jusqu'à ce qu'il y ait une pression.
Actuellement, en 'C', j'utilise un Delay (fonction : nanosleep() pour échantiller les lectures.
Je préfère écrire cela en assembleur par la gestion des interruptions sans effectuer un échantillonnage comme je le fais en 'C'.

Le problème de l'assembleur, c'est que votre bibliothèque ne sera compatible qu'avec un Raspberry Pi donné (par exemple, le 4) et que si le 5 à un nouveau CPU, vous pourrez avoir des incompatibilités.

Ce n'est pas spécifique à une Raspberry Pi mais à toutes les Raspberry Pi.

Il s'agit de l'adresse de base d'implantation des GPIO, PWM ... qui peut être différent d'une Raspberry à une autre.
Sinon, les déplacements (offset) sont identiques.
Au cas où il y aurait des changement avec la futur Raspberry Pi 5B, je devrais faire du spécifique.
Par exemple, la gestion du pull-up / pull-down ne se fait pas de la même façon entre une Raspberry 3B+ et une 4B.

Ma question ne concerne pas ce qui est identique ou spécifique aux raspberry, mais dans l'écriture d'une bibliothèque 'C' avec des fonctionnalités en assembleur.
En Bare Metal, je sais faire, puisque l'on range l'exécutable assembleur à des adresses d'implantations spécifiques, en fonction du découpage adpoté.
Mais dans une bibliothèque, je ne l'ai jamais fait. Et du coup, je ne sais pas comment m'y prendre.

Le deuxième inconvénient de la bibliothèque concerne les autorisations d'accès aux mémoires particulières de la Raspberry Pi.
En Bare Metal, puisqu'il n'y a pas de système d'exploitation, j'ai accès à tout sans aucune restriction.
Dans une bibliothèque, ce n'est pas pareil car je ne sais pas comment m'attribuer les autorisations pour y accéder.

Vous allez me dire comment je faisais jusqu'à présent, en 'C'.
J'utilise plusieurs fonctions qui sont :

a) pour récupérer l'adresse de base en fonction du type de Raspberry Pi, j'utilise ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#include <bcm_host.h>
 
	 int base, size;
 
base = bcm_host_get_peripheral_address() + 0x200000;
size = bcm_host_get_peripheral_size();

Le résultat est spécifique à chaque Raspberry Pi.
Donc pas besoin de recompiler à chaque fois que je change de Raspberry Pi.

Cette fonctionnalité est spécifique à la Raspberry Pi.


b) pour m'autoriser l'accès à la mémoire de la Raspberry Pi, à partir de l'adresse de base, j'utilise :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#include <sys/mman.h>
 
void GPIO_Init(void)
{
		 int    base, size;
		 int    *map, fd;
 
	base = bcm_host_get_peripheral_address() + 0x200000;
	size = bcm_host_get_peripheral_size();
 
	if ((fd = open("/dev/mem", O_RDWR|O_SYNC) ) < 0)
	{
		printf("Open '/dev/mem' Error\n");
		exit(-1);
	}
 
	map = mmap(	NULL,
				size,
				PROT_READ|PROT_WRITE,
				MAP_SHARED,
				fd,
				base);
 
	close(fd);
 
	if (map == MAP_FAILED)
	{
		printf("Mmap Error : %8X\n", (int)map);
		exit(-1);
	}
 
	_gpio = (volatile uint32_t *)map;
}

La fonction "nmap" permet cela.

Ainsi j'ai l'adresse de base spécifique aux GPIO.
Le déplacement étant toujours le même, je n'ai pas besoin de faire du spécifique.

Si j'ai besoin d'accéder à PWM, je vais devoir faire un autre accès spécifique.

c) libération de la ressource.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
if (munmap(_map, _size) != 0)
	{
		printf("Munmap Error : %8X\n", (int)_map);
		exit(-1);
}
 
_map  =						MAP_FAILED;
_gpio = (volatile 	 int *)	MAP_FAILED;

Pour le §b) et le §c), ce n'est pas spécifique à la Raspberry et peut s'utiliser pour accéder à des fichiers.

Voici le problème que je rencontre. J'exécute mon programme avec le compte "root".
C'est normal que cela fonctionne car j'ai toutes les autorisations pour le faire.
Si je l'exécute avec le compte "pi", cela ne fonctionne plus et c'est normal.

Comment m'attribuer les autorisations nécessaire au fonctionnement du programme, si je me trouve dans le compte "Pi" ?
Je désire rester avec les autorisations du compte "pi" pour le programme.

Je pense que ma question concerne les aspects d'autorisations sous linux et non de spécifique à la Raspberry Pi.

Cordialement.
Artemus24.
@+

[chrtophe]

Comment m'attribuer les autorisations nécessaire au fonctionnement du programme, si je me trouve dans le compte "Pi" ?
Je désire rester avec les autorisations du compte "pi" pour le programme.

Je croyais que tu étais sans OS ?

Sous Linux, tu actives le bit setuid, ton exe s’exécutera alors avec les droits root. Dangereux pour la sécurité (mais si c'est sur ton propre raspberry ...)

Tu peux aussi créer un module contenant tes fonctions, il faudra alors le charger. En gros tu créée un driver.

[Artemus24]

Salut à tous.

Je croyais que tu étais sans OS ?

J'aurai dû être plus précis dans mes affirmations car je vais plein de tests avec mes Raspberry Pi.
Entre autre, j'ai développé en Bare Metal et en assembleur des programmes pour manipuler la Raspberry Pi Zero W.
Comme par exemple, faire clignoter des leds, faire varier par PWM deux leds, ou encore transférer par UART un message vers Windows.
Donc oui, dans ce genre de tests, je suis sans OS.

Pourquoi ai-je fait ses tests ?
Deux raisons à cela :
--> me remettre à l'assembleur, bien que celui-ci, l'ARM, je ne le connaissais pas.
--> les problèmes d'autorisations d'accès à la mémoire de la Raspberry Pi zero W. J'ai accès à tout !

La bibliothèque que je désire construire n'est pas pour le Bare Metal en assembleur, mais pour le langage 'C' sous Raspberry Pi OS.
J'essaye de regrouper tous mes tests, en une seule bibliothèque 'C' de fonctions, qui ne sont pas toutes écrites en 'C'.
J'espère que mes explications sont un peu plus clair sur mes intentions.

Sous Linux, tu actives le bit setuid, ton exe s’exécutera alors avec les droits root. Dangereux pour la sécurité (mais si c'est sur ton propre raspberry ...)

Je connais, mais ce n'est pas cette solution que j'avais envisager.

Sous "pi", faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
sudo chown root:pi pulse
sudo chmod 4550 pulse
./pulse

Comme tu le constates, il est indiqué "root" en tant que propriétaire.
Non, car je désire que le propriétaire soit bien "pi" et non "root".
Si par contre, le propriétaire est "pi", cette astuce ne fonctionne pas.

Tu peux aussi créer un module contentant tes fonctions, il faudra alors le charger. En gros tu crées un driver.

Je veux bien essayer mais dans ce cas, comment créer un driver ? Je n'ai jamais essayé de créer un pilote.

Question : qu'est-ce qu'un pilote (driver) par rapport au langage 'C' ?
Est-ce similaire à une bibliothèque ? Ou est-ce une structure complètement différence ?
Je n'ai pas tout dit, mais pour l'instant, ma bibliothèque est statique. J'aimerai qu'elle soit par le suite dynamique.

Cordialement.
Artemus24.
@+

[chrtophe]

Question : qu'est-ce qu'un pilote (driver) par rapport au langage 'C' ?

Un pilote est avant tout un code source comme un autre, (écrit en C ou autre). C'est les options de compilation qui vont générer le pilote (fichier .ko sous Linux ko pour Kernel Object).
Pour linux fais une recherche sur "Créer un module noyau", tu trouvera un squelette.

Avec un OS, tu as des limitations que tu dois respecter : tu ne peux pas faire les même chose en root qu'en utilisateur standard.

Exemple : l'appli passwd : tu peux l’exécuter sur un compte standard pour changer ton mot de passe, bien que ce compte n'est pas accès aux fichiers /etc/passwd et /etc/shadow. Parce que passwd possède le bit setuid et propriété root.
Même si ce n'est pas ce que tu envisageais, c'est comme ça que ça fonctionne.

[Artemus24]

Salut Chrtophe.

Avec un OS, tu as des limitations que tu dois respecter : tu ne peux pas faire les même chose en root qu'en utilisateur standard.

Ca, je le sais, mais cela ne répond pas à ma problématique.

Parce que passwd possède le bit setuid et propriété root.

Justement non :

Code linux :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
~> la /etc/passwd
-rw-r--r-- 1 root root 2032 17 avril 23:43 /etc/passwd
~>

Il n'est même pas exécutable !

Code linux :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
~> whoami
pi
~> /etc/passwd
bash: /etc/passwd: Permission non accordée
~>

Par contre, si je tape la commande "passwd", elle fonctionne :

Code linux :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
~> passwd
Changement du mot de passe pour pi.
Mot de passe actuel*:

Il faudra m'expliquer ce mystère !

Cordialement.
Artemus24.
@+

[chrtophe]

C'est la commande passwd qui a le setuid, pas le fichier /etc/passwd

[Artemus24]

Salut Chrtophe.

Code linux :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
~> la /usr/bin/passwd
-rwsr-xr-x 1 root root 45752  7 févr.  2020 /usr/bin/passwd
~>

Oui, en effet, je me suis trompé de fichier.

Dois-je comprendre que c'est la solution appliquée dans la raspberry ?

Il y quelque chose que je ne comprends pas.
L'erreur que j'ai, se produit au test l'ouverture de :

Code linux :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
if ((fd = open("/dev/mem", O_RDWR|O_SYNC) ) < 0)
{
	printf("Open '/dev/mem' Error\n");
	exit(-1);
}

N'y-a-t-il pas un oubli de ma part pour ne plus avoir ce problème ?

Cordialement.
Artemus24.
@+

[chrtophe]

Et que retourne l'erreur ? EACCESS je suppose.

Normalement /dev/mem est fait pour accéder à de la mémoire physique
/dev/kmem permet d'utiliser la mémoire virtuelle, et donc potentiellement les registres GPIO

Par contre, en regardant vite fait, c'est /dev/mem qui est utilisé ou /sys/class/gpio/

[Artemus24]

Salut Chrtophe.

En effet, je teste mes GPIO et en particulier le front montant (Rising Edge) et descendant (Falling Edge).
Cela se déclenche sur une interruption (Event). Voire l'autre sujet que j'ai créé.

J'utilise "/dev/mem" car cela me parait plus simple à gérer que "/sys/class/gpio".

J'en suis toujours au même point sur ces autorisations.

Cordialement.
Artemus24.
@+

[chrtophe]

Heureusement qu'il faille des autorisations pour tripoter /dev/mem.

D'ou l’intérêt d'utiliser une bibliothèque, c'est portable d'un modèle à l'autre et t'as pas à gérer ce genre de prob.

J'utilise "/dev/mem" car cela me parait plus simple à gérer que "/sys/class/gpio".

plus simple, mais peut-être plus contraignant vis à vis des droits par exemple.

Sur ce point précis, t'as peut-être intérêt à demander avis dans le forum raspberry.*

[Artemus24]

Salut Chrtophe.

Sur ce point précis, t'as peut-être intérêt à demander avis dans le forum raspberry.

Il n'y a plus d'activité dans le forum consacré à la Raspberry Pi, et c'est dommage.

En attendant de trouver mieux, je vais me contenter de la solution du bit setuid qui fonctionne bien.

J'ai repris mes tests, que j'avais arrêté depuis l'année 2020, sur les GPIO et le PWM.
J'ai déposé un message concernant les fronts montants et descendants du BP.
A leur actuel, j'ai toujours le plantage de l'OS, dont je ne comprends pas l'origine.
Il y a quelque chose que je dois mal faire, mais je ne sais quoi quoi.
Je m'inspire de la bibliothèque BCM2835. Or il se trouve que j'ai aussi le même plantage.
En assembleur, quand je crée un programme, qui est en réalité un sous-programme à l'OS, la première des choses que je fais, est une sauvegarde du contexte, et la dernière, la restitution du contexte.

Cela permet de ne rien casser !

La prochaine étape, qui est encore bien plus compliqué que les GPIO, est de gérer les interruptions.
Je vais essayer d'appliquer cela à l'Event des Rising Edge et des Falling Edge.
Sauf que je dois d'abord résoudre ce plantage.

Cordialement.
Artemus24.
@+

[Artemus24]

Salut à tous.

Je clôture le sujet même si le problème est partiellement résolu.

Cordialement.
Artemus24.
@+