Problème politique d'ordonnancement sur RPi

[invite19e61be6]

Bonjour à tous,

j'aurais besoin d'un petit coup de pouce des experts internautes sur un petit projet que je code en C.
Alors, voilà je vous explique.

J'ai un capteur de température et hygrométrie, le DHT22 qui après l'envoi d'une requête par le RPi donne des informations codées grâce au temps. Par exemple, si le capteur maintient un niveau haut pendant 27 us, ça correspond à un 0, et s'il maintient le niveau haut pendant 70 us, cela correspond à un 1.
Le problème vient de l'absence de buffers sur les pins GPIO du RPi. En effet, pendant l'envoi des informations par le capteur, l'OS du RPi switche de processus et bloque l'exécution du processus lecteur. Ce qui résulte est que le RPi manque des informations dans le pire des cas, ou se trompe d'interprétation du signal dans l'autre cas.

Je recherche donc une bibliothèque permettant de manipuler les processus, et surtout une fonction qui dit à l'OS de ne pas switcher ce processus jusqu'à la fin de la lecture des informations. Je n'ai rien trouvé sur le net pour le moment, au début j'ai cru que wait() et waitpid() pourraient m'aider mais au final, cela n'a pas l'effet escompté.

Quelqu'un aurait une petite idée ?

Merci par avance pour votre lecture et pour toutes réponses éventuelles.

shinishi
-----

[JPL]

On laisse ici ou bien je le déplace en Électronique ?

[invite19e61be6]

Bonjour,

je pense que cela relève plus de la programmation dans la mesure où il s'agit d'intéragir avec l'OS bien qu'il s'agisse d'un programme qui a une finalité électronique.
J'avoue que je ne sais pas bien. Peut-être faudrait-il le laisser ici.

Merci

shinishi

[JPL]

On va voir ce qu'en pensent les autres.

[A voir en vidéo sur Futura]

[inviteb9f49292]

Difficile d'être affirmatif sans une idée succincte du code, mais ton analyse sonne juste. Vu les temps à mesurer (quelques dizaines de us), il faudrait utiliser une entrée type "timer" (pwm, external interrupt...), d'ailleurs en cherchant la datasheet du capteur je suis tombé sur ça.

Comme je suppose que l'OS est linux, il faut que ce soit gérer par un pilote de périphérique pour que la mesure du temps se face par le périphérique _ET_ en espace noyau. Donc éviter les changements de contextes par l'ordonnanceur (les switchs de context du scheduler pour google). Il y a peut-être un pilote pouvant déjà faire l'affaire, ou tu peux très certainement modifier un pilote existant pour faire le tien, il faut un bon niveau en C, mais il y a de le la doc à commencer par les sources du noyau.

Ou alors tu utilises un OS temps réel, plus facile sur une "bricole" comme l'arduino dont ils parlent dans le lien ci-dessus. Tu dois même en trouver pour le RPi.

[invite19e61be6]

Bonjour,

merci de votre réponse.
Malheureusement je ne suis qu'un amateur en C.
Je n'ai pas fini le code, il faut y ajouter une exception dans le cas où le programme reste bloqué dans une boucle mais sinon la logique est là.

#include <stdio.h>
#include "gpio.h"
#include "dht22.h"
#include <sys/time.h>

#define TEMPS_LIMITE 50 // 50 us
#define REQUEST_TIME 10000 // 10000 us
#define ENDER_SIGNAL_LIMIT 100//100 us
#define TAILLE_OCTET 8
#define PULL_UP 0x02
#define R_EDGE 0x01
#define F_EDGE 0x02
#define H_LEVEL 0x04
#define L_LEVEL 0x08


static void send_request(struct GPIO_control GPIO_ACCESS, unsigned int pin)
{
        GPIO_set_pull(GPIO_ACCESS,PULL_UP);
        GPIO_set_output(GPIO_ACCESS,pin);
        GPIO_set_low(GPIO_ACCESS,pin);
        usleep(REQUEST_TIME);
        GPIO_set_high(GPIO_ACCESS,pin);
}

static void wait_acquittement(struct GPIO_control GPIO_ACCESS, unsigned int pin)
{
        GPIO_set_input(GPIO_ACCESS,pin);
        GPIO_set_detect_setting(GPIO_ACCESS,F_EDGE,pin);
        GPIO_init_detect(GPIO_ACCESS,pin);
        while (!(GPIO_detect(GPIO_ACCESS,pin)))
        {
        }
        GPIO_set_detect_setting(GPIO_ACCESS,R_EDGE,pin);
        GPIO_init_detect(GPIO_ACCESS,pin);
        while (!(GPIO_detect(GPIO_ACCESS,pin)))
        {
        }
        GPIO_set_detect_setting(GPIO_ACCESS,F_EDGE,pin);
        GPIO_init_detect(GPIO_ACCESS,pin);
        while (!(GPIO_detect(GPIO_ACCESS,pin)))
        {
        }
}

static unsigned char receive_bit(struct GPIO_control GPIO_ACCESS, unsigned int pin)
{
        struct timeval up,control;
        GPIO_set_detect_setting(GPIO_ACCESS,R_EDGE,pin);
        GPIO_init_detect(GPIO_ACCESS,pin);
        while (!(GPIO_detect(GPIO_ACCESS,pin)))
        {
        }
        gettimeofday(&up,NULL);
        GPIO_set_detect_setting(GPIO_ACCESS,F_EDGE,pin);
        GPIO_init_detect(GPIO_ACCESS,pin);
        do
        {
                gettimeofday(&control,NULL);
        }
        while (!(GPIO_detect(GPIO_ACCESS,pin)) && (control.tv_usec-up.tv_usec)<ENDER_SIGNAL_LIMIT);
        printf("%d",((control.tv_usec-up.tv_usec)>TEMPS_LIMITE));
        return ((control.tv_usec-up.tv_usec)>TEMPS_LIMITE);
}

static unsigned char receive_octet(struct GPIO_control GPIO_ACCESS, unsigned int pin)
{
        unsigned char result=0;
        int i;
        for (i=0;i<TAILLE_OCTET;i++)
        {
                result|=receive_bit(GPIO_ACCESS,pin);
                result= result<<1;
        }
        return result;
}

static struct t_DHT22  receive_data(struct GPIO_control GPIO_ACCESS, unsigned int pin)
{
        struct t_DHT22 DHT22;
        unsigned char HG[2];
        unsigned char T[2];
        unsigned char CKS;
        do
        {
                send_request(GPIO_ACCESS,pin);
                wait_acquittement(GPIO_ACCESS,pin);
                HG[0]=receive_octet(GPIO_ACCESS,pin);
                HG[1]=receive_octet(GPIO_ACCESS,pin);
                T[0]=receive_octet(GPIO_ACCESS,pin);
                T[1]=receive_octet(GPIO_ACCESS,pin);
                CKS=receive_octet(GPIO_ACCESS,pin);
        }
        while (CKS != (HG[0] + HG[1] + T[0] + T[1]));
        DHT22.hygrometrie =(float) (short)HG/10.0;
        DHT22.temperature =(float) (short)T/10.0;
        return DHT22;
}

void DHT22_main(struct t_DHT22_main * DHT22)
{
        while (1)
        {
                DHT22->DHT22=receive_data(DHT22->GPIO_ACCESS,DHT22->pin);
        }
}

int main()
{
        struct t_DHT22 DHT22;
        struct GPIO_control GPIO_ACCESS=map_memory();
        DHT22=receive_data(GPIO_ACCESS,21);
        printf("Humidité : %f % \n Température : %f °C \n",DHT22.hygrometrie,DHT22.temperature);
        unmap_memory(GPIO_ACCESS);
        return 0;
}

Je dois avouer que je ne suis pas calé sur les drivers.
Mais c'est un défi intéressant.

As-tu des références qui pourraient m'aider ?

Merci par avance.

shinishi

[Jack]

J'ai trouvé ceci: http://www.airspayce.com/mikem/bcm2835/

On peut y lire:

Real Time performance constraintsThe bcm2835 is a library for user programs (i.e. they run in 'userland'). Such programs are not part of the kernel and are usually subject to paging and swapping by the kernel while it does other things besides running your program. This means that you should not expect to get real-time performance or real-time timing constraints from such programs. In particular, there is no guarantee that the bcm2835_delay() and bcm2835_delayMicroseconds() will return after exactly the time requested. In fact, depending on other activity on the host, IO etc, you might get significantly longer delay times than the one you asked for. So please dont expect to get exactly the time delay you request.

et juste après:

Arjan reports that you can prevent swapping on Linux with the following code fragment:struct sched_param sp;
memset(&sp, 0, sizeof(sp));
sp.sched_priority = sched_get_priority_max(SCHED_F IFO);
sched_setscheduler(0, SCHED_FIFO, &sp);

mlockall(MCL_CURRENT | MCL_FUTURE);

ce qui pourrait être une solution à ton problème.

[inviteb9f49292]

La bibliothèque que propose Jack peut peut-être faire l'affaire, coupler avec de la configuration système (jouer aver les swapiness, nice et autre cgroup), voir une petite recompilation du noyau (changer la politique d'ordonnancement, diminuer le tick...).
Ce n'est pas forcément la voix "académique", mais c'est de plus en plus pertinent, la puissance des machines augmentant, les temps de réponses diminuent et permettent de "faire croire au temps réel" (temps réel n'est pas vitesse mais garantie d'un temps de réponse borné).

Je dois avouer que je ne suis pas calé sur les drivers.
Mais c'est un défi intéressant.

As-tu des références qui pourraient m'aider ?

J'ai jeté un oeil rapide à ton code (mes remarques après), effectivement ton niveau en C risque d'être un peu bas pour du pilote de périphérique (il y a parfois des techniques C un peu évoluées, pas forcément évidente à comprendre à la lecture) mais pourquoi pas. Une bonne référence pour commencer est LLD3, il commence à dater un peu, il y a pas mal d'API qui ont dues changer entre temps, mais les mécanismes et concepts devraient toujours être pertinents. Ce site est également une bonne référence, et évidemment les sources du noyau, il y a un sous dossier "Documentation" rempli de choses intéressantes (parfois un peu obsolètes), et les sources sont très bien structurées, donc relativement facile à parcourir... Mais ça fait bien longtemps que je n'ai pas mis les mains dans le cambouis du noyau, il y a peut-être mieux depuis, je suis persuadé qu'en cherchant tu devrais trouver un tuto pour faire un pilote linux pour un périphérique du RPi (vu l'engouement que cette machine a eu). [PUB]et si tu as quelques dollars à mettre dans un bouquin, je conseille la collection O'Reilly, ils sont très souvent très bien, et la maison d'édition à une éthique[/PUB]. Un "détail", anglais obligatoire.

Les quelques remarques (liste non exhaustive):

- utilises un préfixe avec l'unité physique pour tes variables / symbole, par exemple "#define REQUEST_TIME_us 10000", (et mélanger anglais et français, je trouve ça de mauvais goût, mais ce n'est pas une considération technique)

- ton "receive_bit" renvoie un "unsigned char", j'imagine que tu espères optimiser, il vaut mieux "documenter" le code avec un type retourné plus "immédiat", si tu retournes une valeur de type vrai/faux, utilise un "int", c'est le plus efficace puisque c'est la taille native (je crois que le nouveau standard C11 préconise l'utilisation du "nouveau" type bool), attention la situation n'est pas la même pour "receive_octet" (arrrg du franglais), où le retour "unsigned char" me semble adéquat... à un détails qui est un peu de la zoophilie drosophile... Le char n'est pas garanti par le standard de faire 8bits, si tu veux utiliser une taille fixée il faut utiliser stdint.h avec int8_t et uint8_t, int16_t ....

- "static struct t_DHT22 receive_data" celui-là j'ai un doute... Soit tu as le droit de retourner une structure d'une fonction (je ne pense pas que le standard autorise ça, sauf peut-être pour les structures limitées à un seul champs de type "primitif"), alors c'est "une connerie", car il va y avoir un empilement / dépilement, autant passer l'adresse de l'instance de la structure (le pointeur sur), mais là la fonction ne marcherai plus car une fois sortie du corps de la fonction, sa pile (stack) est libérée, et tout ce qui était alloué dedans également. Les solutions potentielles seraient de faire un allocateur, tu alloue l'espace nécessaire à ta structure sur le tas (heap) grâce à malloc, et tu renvoies l'adresse ainsi allouée, il faudra la libérer quand tu n'en auras plus besoin avec "free". Tu peux également déclarer de manière "static" l'instance de la structure, elle ne sera plus sur la pile, et du coup l'adresse renvoyée serait toujours valide une fois sortie de ta fonction (et toujours la même d'ailleurs), mais du coup ta fonction n'est plus réentrante. Ou tu peux passer une adresse de l'instance de la structure en paramètre de ta fonction, qui ne fera "que" la remplir, mais du coup peu d'intérêt à retourner l'adresse.

- je ne comprends pas l'intérêt de la fonction "DHT22_main", tu voulais faire du multithread ?

- et la structure "struct t_DHT22_main" ? Car le nom des 2 structures me laisse soupçonner qu'il y a de la "sur-structuration" dans l'air.

- tu mesures un temps avec gettimeofday et ce n'est pas bon car il pourrait y avoir des mises à l'heure entre les 2 prises de dates, et du coup le temps calculé sera faux, il faut que tu utilises clock_gettime avec l'horloge monotonique (man clock_gettime)

- il y a du positif, l'utilisation du "static" pour déclarer les fonctions "privées" du module, le découpage en sous-fonctions claires avec noms explicites

Voilà, bonne continuation.

[polo974]

c'est globalement impossible de faire du temps réel aussi hard sur un linux, même s'il est posé sur un truc genre xenomai (ce qui est déjà coton à mettre en place).

voir par exemple http://www.blaess.fr/christophe/2012...es-de-xenomai/

les latences (et surtout la dispersion de celles-ci) font qu'on ne peut rien faire sans mettre un petit bidule programmé entre.

du coup, ça relève de l'électronique programmée (pic ou arduino ou... à choisir selon la couleur des yeux de l'homme invisible).

[invite19e61be6]

Bonjour à tous,

je vous remercie pour vos réponses qui ne manquent pas d'intérêt.
Evidemment, je comprends qu'il sera difficile de réaliser ce que je souhaite faire.

J'ai testé la solution proposée par Jack mais (à croire que je m'y suis mal pris) cela n'a pas fonctionné.
La fonction dht22_main est en effet faite pour du multithread.
Je vais tenter de parfaire mes connaissances en C et sur les drivers avant de poursuivre, peut-être cela fonctionnera mieux après.
Je vous tiendrai au courant.

shinishi

[inviteb9f49292]

c'est globalement impossible de faire du temps réel aussi hard sur un linux, même s'il est posé sur un truc genre xenomai (ce qui est déjà coton à mettre en place).

Attention à ne pas confusionner le primo-posteur... Il semble effectivement difficile de faire ça en espace utilisateur, même avec un linux temps-réel (et si je me rappelle bien xenomai, le temps réel ne se fait pas en espace utilisateur mais "en-dessous" du noyau). En revanche, j'affirme qu'une entrée type timer (et le driver qui va avec, pour rester en espace noyau), est nécessaire et suffisante pour faire ça, et pas besoin de linux temps réel. Soit le périphérique utilisé est capable de lancer et arrêter le compteur automatiquement sur fronts, auquel cas la précision est celle de l'horloge qui cadence ton compteur. Soit c'est une "interruption externe", et tu dois lancer / arrêter le compteur en routine d'interruption, la précision étant alors entachée par le délais entre l'apparition du front et le chargement en RAM de la routine d'interruption, ce délais n'étant pas borné ni même constant, mais il est dans un ordre de grandeur autour de la micro seconde (dépends de la vitesse du proc, de la taille des caches, de la charge ...). On est pas dans des délais de l'ordre de la ms intervenant dans les switchs espace utilisateur / espace noyau.

Evidemment, je comprends qu'il sera difficile de réaliser ce que je souhaite faire.

Je ne sais pas ce qui est imposé ou pas, ce dont tu as besoin dans le RPi ni même le projet globale, mais je pense comme Polo974 que le plus adapté pour ce genre de problème est un petit micro-controleur.

La fonction dht22_main est en effet faite pour du multithread.

Ouch...

[invite19e61be6]

Qu'y a t-il qui ne va pas dans cette fonction ?

[Jack]

Qu'y a t-il qui ne va pas dans cette fonction ?

Elle ne se termine jamais

[polo974]

je ne suis pas sûr qu'un driver (donc module kernel) puisse le faire sans louper quelques bits par-ci par-là.
mais je suis sûr que c'est impossible en userland sans risque (élevé) d'erreurs.

il est dommage que le DHT22 qui est fait pour une mesure toute les secondes (et encore) impose des contraintes de timing aussi dures.

il semble que ce soit un problème récurent: https://hackeandoelgenoma.com/2014/0...duino-por-usb/
(je n'ai pas lu)

mais on en voit qui font ça à l'ancienne (boucle de tempo, priorité haute, mono-tâche): http://www.instructables.com/id/Rasp...d-humidity-lo/
(j'ai survolé, et ce n'est pas beau...)

[inviteb9f49292]

je ne suis pas sûr qu'un driver (donc module kernel) puisse le faire sans louper quelques bits par-ci par-là.

Tout dépends du périphérique, si c'est un "vrai" timer, le compteur se lance et s'arrête automatiquement sur front, le pilote n'est là que pour récupérer la valeur lue depuis le compteur, il a 500ms pour le faire (si je me rappelle bien fréquence d’échantillonnage 2Hz).

Si c'est plutôt du genre interruption externe alors oui c'est plus tendu car il faudra que le compteur soit lu sur front par la routine d'interruption du pilote, donc une imprécision équivalente à la latence de l'interruption, à savoir si c'est compatible avec la précision nécessaire.

Si j'en crois mon expérience sous linux + PC classique (je monte de temps à autre des serveurs de temps asservi par PPS sur l'entrée CD de port série, et je surveille que ça marche), une latence inférieure à la 10aine de us n'est pas délirante si la machine n'est pas trop chargée. Sur un RPi, il est moins rapide _MAIS_ plus simple (enfin je pense, moins de cache, moins de pipeline et toutes ces choses qu'il faut vidanger), du coup je ne sais pas dans quel mesure c'est jouable.

mais on en voit qui font ça à l'ancienne (boucle de tempo, priorité haute, mono-tâche)

arf ces électroniciens qui se mettent au développement logiciel... Blague à part, si il n'y a pas de timer sur le RPi, je plussoie, une meilleure méthode pour un problème pareille me semble être une interface capteur <-> liaison série sous forme d'arduino, pic, msp430... et de traiter les mesures par la liaison série sous linux.
Le RPi a le cul entre deux chaises, c'est un micro-controlleur, il a donc toutes ces interfaces "bas niveau", et il est suffisamment puissant pour faire tourner linux, malheureusement linux n'est pas faire pour ce genre de chose, il faudrait un FreeRTOS ou autre eCos.

[sandrecarpe]

Salut,
J'utilise aussi une DHT22 avec mon rpi et j'ai jamais eu de soucis. J'ai juste utilisé la bibliothèque j'ai trouvé...je ne sais plus où x)
A la base elle était codé en C mais je l'ai refaite en C++ comme j'ai pu...D'ailleurs si y a des choses qui vous choque je les corrigerais avec plaisir

[inviteb9f49292]

D'ailleurs si y a des choses qui vous choque je les corrigerais avec plaisir

N'en demande pas trop tu pourrais y prendre goût...

Après une lecture très rapide, plusieurs choses plus ou moins choquantes (dans un ordre aléatoire):

-c'est du "polling", donc tributaire de la configuration et de la charge de la machine

-c'est du C++ (c'est toi qui a choisi, pas moi), il y a une classe mais de constructeur (ni de destructeur), ta méthode "init" devrait être un constructeur avec la pin utilisée en paramètre, et le fichier verrou pas en "static" mais membre privé. Et ton "close" c'est en gros le destructeur. Par la même occaz le "read" ne prends aucun paramètre, il met à jour des champs privés auxquels tu accèdes par des assesseurs (tu peux imaginer un historique...).... Enfin bref tout ce que tu veux mais PAS DE VARIABLES GLOBALES !!! (*)

-utiliser des uint8_t en indice est une fausse optimisation, si ce n'est pas silencieusement remplacé par un "int" à la compilation, ce sera pénalisant (code + gros et + lent) car tes registres sont 32 bits, il faudra convertir (cast). Utilise des "int" pour tous ce qui est général (éventuellement unsigned pour les indices), c'est le "format naturel" de la machine (donc le plus efficace en taille et en temps)

-plus généralement, je n'aime mélanger l'interface homme-machine (ton "PrintUsage" et tout ce qui utilise iostream ou presque) et la mécanique. (*)

-encore plus généralement, MAIS POURQUOI LE C++ ??? (*)

(* ces remarques s'appliquent plus ou moins suivant l'API qu'on t'impose)

[sandrecarpe]

Pour ton deuxième tiret c'est vrai que j'aurais du faire un constructeur (et destructeur) digne de ce nom ! Je fais ça à la va vite et pas bien et à partir du moment où ça fonctionnait je suis plus revenu dessus
Idem pour les variable global

Pour les uint8_t je n'avais pas changé le type codé de base, mais maintenant je prend en compte ta remarque.
J'ai choisis le C++ parce que je trouve ça beaucoup plus structuré et "jolie" que de C, c'est tout

Du "polling" c'est à dire le contraire d'un fonctionnement en interruption ?

[inviteb9f49292]

J'ai choisis le C++ parce que je trouve ça beaucoup plus structuré et "jolie" que de C, c'est tout

La langue importe peu aux poètes... Mise à part les considérations esthétiques, le C++ est beaucoup trop compliqué, alors que des concepts simples comme une vraie encapsulation opaque sont horriblement compliquées à faire. Pour tout ce qui est système (particulièrement unix), bas niveau, micro-contrôleur... le C est roi. Et tu peux faire de l'objet en C si c'est ce qui t'inquiète...

Du "polling" c'est à dire le contraire d'un fonctionnement en interruption ?

Oui

[sandrecarpe]

Je ne suis pas d'accord. Je trouve le C++ beaucoup plus simple, et cela grâce à sa façon de "mettre en forme" et d'organiser le code mais après tout je n'ai sûrement pas fait assez de C pour comparer.
En quoi trouves-tu le C++ compliqué ?

[polo974]

Tout dépends du périphérique, si c'est un "vrai" timer, le compteur se lance et s'arrête automatiquement sur front, le pilote n'est là que pour récupérer la valeur lue depuis le compteur, il a 500ms pour le faire (si je me rappelle bien fréquence d’échantillonnage 2Hz).

Si c'est plutôt du genre interruption externe alors oui c'est plus tendu car il faudra que le compteur soit lu sur front par la routine d'interruption du pilote, donc une imprécision équivalente à la latence de l'interruption, à savoir si c'est compatible avec la précision nécessaire.

...

En fait, il faut discriminer des temps entre (50+27)us et (50+70)us dans une trame...
Et il n'y a pas d' "input capture timer" disponible sur le rpi (voir ici).

Donc échantillonnage soft et temps de latence pouvant aller au-delà de 20us avec xenomai, alors dur-dur avec un kernel normal et pire en userland...

La rpi n'est pas un micro-contrôleur orienté pilotage fin de hardware, c'est un mini-ordi genre tablette mais sans l'écran (qu'on vous vend 2 fois plus cher qu'une tablette complète ). il manque cruellement d'entrées-sorties diverses et variées.
Pour ça, on peut regarder les cartes faites pour (il y a même un arduino 32 bits maintenant, on va pouvoir voir encore plus de code crade qui va bouffer 99.99% des ressources à attendre que le temps passe...)

arf ces électroniciens qui se mettent au développement logiciel...

Arrête de rigoler, je suis électronicien (enfin, à la base, car depuis, je ne sais plus trop...).

[inviteb9f49292]

Je ne suis pas d'accord. Je trouve le C++ beaucoup plus simple, et cela grâce à sa façon de "mettre en forme" et d'organiser le code mais après tout je n'ai sûrement pas fait assez de C pour comparer.
En quoi trouves-tu le C++ compliqué ?

C'est factuel, ce n'est pas une impression, la syntaxe du C++ est nettement plus compliquée que celle du C, il te suffit de comparer le nb de pages des 2 standards, et plus encore le nb d'"undefined behaviour" et autres "inconsistances"... D'ailleurs, tous les projets sérieux écrits en C++ n'utilisent qu'un sous-ensemble du langage (Qt en tête), alors que pour n'utiliser qu'un sous ensemble du langage en C c'est que tu fais de l'embarqué et/ou du critique... et bien souvent les limitations se limitent à "quelques" interdictions très localisées (fonctions variadiques et allocation dynamique en tête), pas à s'interdire un morceau complet du langage.

Et le problème de cette complexité est qu'elle se répercute sur la fiabilité du code que tu écris, tu verras le jour où tu te fera mordre par un constructeur par défaut, que tu devras reprendre du code où des opérateurs ont été surchargés... etc... Sachant que débugger du C++ ça fait vraiment mal avec le "name-mangling"...

Le langage est tellement compliqué que compiler un programme non trivial prends des plombes...

Et là je suis juste du côté du développeur, mais le pire doit se situer du côté des gens qui maintiennent les systèmes, parce que en C++ pas d'ABI... Donc compatibilité des codes objets / bibliothèques quasi impossibles (même entre deux codes compilés par le même compilateur de version différente...).

Mais ce que je trouve le plus ridicule dans le C++ est le sacrifice d'un aspect de la COO pour les autres (attention je ne suis pas CS, mais dev donc les termes ne sont peut-être pas les bons), il me semble que la COO c'est encapsulation (cacher l'implémentation) + héritage /polymorphisme (spécialisé/généralisé du code), en C la première est immédiate, la seconde pas bien compliquée... En C++ la 1ère devient ridiculement "difficile", la 2nde devenant triviale en "automatisant" le travaille du développeur (c'était formellement vrai pour les 1ère version du C++, je ne suis pas sûr que ce le soit toujours). Et c'est devenu de pire en pire, le C++ étant maintenant également un langage fonctionnel (aller hop un nouveau paradigme de programmation).

Mon avis est que le C++ ne se justifie plus. Il avait éventuellement une raison d'être il y a 30ans quand les machines ramaient et que tu devais faire du "haut-niveau" qui bourlingue (donc en gros calculs scientifiques / jeux vidéos...) sachant qu'on avait du mal à "mélanger" les langages, mais aujourd'hui... Soit tu hérites d'un projet en C++ et tu n'as pas le choix, soit tu commences un nouveau projet, tu fais le bas niveau en C et le haut niveau / la glue en n'importe quel langage scripté ou non (python, shell...). Il y a des projets bien écris et sérieux en C++, Qt me vient immédiatement à l'esprit, jette un oeil à leur code tu verras le format de code qu'ils imposent...

cela grâce à sa façon de "mettre en forme" et d'organiser le code

Il me semblait que c'était le développeur qui met en forme et organise le code, pas le langage...
Nous sommes d'accords que la syntaxe d'un langage peut simplifier l'écriture d'un idiome, donc oui l'héritage est plus rapide et compacte à écrire en C++ qu'en C, par contre pour l'organisation tu repasseras, mélanger interface et implémentation par la définition de la classe, qui doit se faire dans l'entête (donc côté interface)... Jette un oeil au code source du noyau linux, ou à gtk tu verras du code objet, organisé, écrit en pure C.

Demande à google si il connaît des "C++ hater", tu devrais croiser des critiques mieux détaillées que la mienne sur la pieuvre à 19 tentacules...

[inviteb9f49292]

Et il n'y a pas d' "input capture timer" disponible sur le rpi (voir ici).

Comme je ne fais pas confiance au code écrit par un électronicien, je fais encore moins confiance à l'interprétation électronique d'un informaticien... Bref j'irai jeter un oeil sur la datasheet de la CPU parce que je trouve ça un peu étonnant quand même...

Donc échantillonnage soft et temps de latence pouvant aller au-delà de 20us avec xenomai, alors dur-dur avec un kernel normal et pire en userland...

Ce n'est pas un chiffre que je trouve rédhibitoire pour cette appli car les temps moyens de réponse d'un scheduler sont en moyenne bien plus élevés qu'un scheduler normal, mais ils sont bornés. Mais bon sans timer matériel ça restera (si ça fonctionne) c'est une solution bricole...

La rpi n'est pas un micro-contrôleur orienté pilotage fin de hardware, c'est un mini-ordi genre tablette mais sans l'écran (qu'on vous vend 2 fois plus cher qu'une tablette complète ). il manque cruellement d'entrées-sorties diverses et variées.

Où trouves-tu des tablettes à 25$ ça m'intéresse, parce que ma RPi je l'ai payé 50$ à l'époque... Mais j'avoue, je préfère bricoler ma bagnole que le RPi, il est en train de "pourrir" dans un tiroir, du coup je n'ai pas vraiment fait le tour de ses périphériques...

Arrête de rigoler, je suis électronicien (enfin, à la base, car depuis, je ne sais plus trop...).

Personne n'est parfait...
Mais je vais te faire une confidence, quand on me demande ce que je fais je dis électronicien, parce qu'en disant informaticien les gens t'imaginent en train de programmer un jolie PC, alors que le plus puissant avec lequel je joue en ce moment est un arm9... (et puis un peu marre aussi de passer pour un con devant un PC sous windows...)

[Bluedeep]

Où trouves-tu des tablettes à 25$ ça m'intéresse, parce que ma RPi je l'ai payé 50$ à l'époque...

Je pense qu'il fait référence au prix de l'écran "officiel" du RPi (et c'est vrai qu'il est plus cher qu'une tablette d'entrée de gamme type "archos").

[polo974]

en effet, je parlais du prix de l'écran tactile (comparé aux tablettes 1er prix).

pour le rpi, la puce est taillée pour un smartphone ou une tablette, donc strict minimum coté timer et i/o, ce n'est pas un mille-patte genre stm32f407 mais il a une puissance de feu "multimédia" incomparable.

bien sûr, on peut faire la mesure en la répétant x fois et rejeter les cas où le timing n'a pas été respecté.
si la bête n'est pas trop chargée, ça va passer, par contre, c'est une incertitude qui planera en silence sur le projet, et le jour où on ajoute une charge inattendue sur le bourricot, ça ne marche plus, et plus personne ne se souvient de cette bidouille...