Utiliser python ?

Salut,

J'ai cru comprendre (je précise que débute) qu'on pouvait utiliser le langage python avec l'arduino...

Mais comment cela se passe au juste en interne ? Python étant un langage interprété je suppose qu'on ne peut pas programmer l'arduino directement avec ce langage, est-ce juste ?

Si la réponse est oui alors comment cela se passe dans ce cas ?

- J'ai vu un cas où on programme l'arduino en c++ pour envoyer régulièrement la tension sur le port série et alors on peut se servir d'un code en python pour lire le port série et traiter les données...

- J'ai vu un autre cas où charge un code en c++ ensuite on peut via une librairie spécifique communiquer avec l'arduino via un code en python mais là je ne sais pas comment cela se passe...

Bref, qu'en pensez-vous ? Y a-t-il d'autres moyens ? Quels sont les meilleurs ?

Merci.

Salut,

Citation:

---

Envoyé par Beginner.

Mais comment cela se passe au juste en interne ? Python étant un langage interprété je suppose qu'on ne peut pas programmer l'arduino directement avec ce langage, est-ce juste ?

---

Les micros des Arduino ne sont pas assez costauds (les UNO ou similaires en tout cas) pour faire tourner un interpréteur Python.
Il y a bien le protocole firmata. On téléverse un firmware dans l'Arduino, mais le programme Python tourne sur le PC qui envoie des commandes via la liaison série. C'est lent, mais ça peut suffire pour faire des tests.

Pour loger un interpréteur Python dans le micro, on peut se tourner vers les ESP. Voir ici ou là.

Citation:

---

Envoyé par f-leb

Il y a bien le protocole firmata. On téléverse un firmware dans l'Arduino, mais le programme Python tourne sur le PC qui envoie des commandes via la liaison série. C'est lent, mais ça peut suffire pour faire des tests.

---

Merci. Oui je crois que c'est une des deux manières que j'ai vues... Et c'est moins performant si j'ai bien compris, je m'en doutais un peu à vrai dire...

Citation:

---

Envoyé par f-leb

Pour loger un interpréteur Python dans le micro, on peut se tourner vers les ESP. Voir ici ou là.

---

Merci je vais regarder mais je crois que ce sera trop compliqué --->ce n'est pas seulement pour moi, c'est lié au nouveau programme scolaire, on doit utiliser l'arduino avec python...

Citation:

---

Envoyé par Beginner.

ce n'est pas seulement pour moi, c'est lié au nouveau programme scolaire, on doit utiliser l'arduino avec python...

---

Je vois bien de quoi tu parles collègue:), c'est pour quel niveau ? Seconde ?

Ah ben en fait nous on doit donner une initiation aux étudiants (futurs enseignants)... Je suppose donc qu'ils devront en savoir un peu plus que les élèves de lycée puisqu'ils devront l'enseigner...

Ah oui j'ai retrouvé le lien où j'avais vu ce dont tu m'a parlé : http://ww2.ac-poitiers.fr/sc_phys/si...age_python.pdf

Citation:

---

Envoyé par Beginner.

Je suppose donc qu'ils devront en savoir un peu plus que les élèves de lycée puisqu'ils devront l'enseigner...

---

voui, je suppose que c'est mieux:mouarf:, mais si c'est pour des profs de physique, je suppose aussi que l'objectif n'est pas d'apprendre la programmation, mais l'arduino est un moyen de faire des expérimentations avec des capteurs. La solution firmata est sans doute suffisante dans ce cas (faut voir du côté vitesse d'échantillonnage par contre).

Par contre c'est dommage d'imposer l'Arduino. Un kit à base d'ESP32 avec un firmware micropython et un EDI Python très simple comme Thonny côté PC n'est pas plus compliqué à prendre en main il me semble avec le côté connecté WiFi ou Bluetooth en prime...

Mais il y a peut-être des versions d'Arduino avec des micro 32 bits et suffisamment de mémoire qui peuvent implémenter micropython maintenant, à voir...

Bonsoir à tous

Je trouve que enseigner de la sorte est particulièrement maladroit.
On veut faire de l'embarqué, mais on doit y adjoindre un PC pour faire le boulot et on est limité entre 1/10ème et 1/100ème de ce que la puce est capable de faire.

Au final dans ce cas d’utilisation l'Arduino n'est plus qu'un simple RTU. Car quand à faire de l'enseignement, autant dire clairement ce que l'on fait.

Bonne suite

Delias

Oui c'est bien ça c'est pour des futurs enseignants en physique et effectivement l'informatique n'est pas leur priorité...

Citation:

---

Envoyé par f-leb

Par contre c'est dommage d'imposer l'Arduino. Un kit à base d'ESP32 avec un firmware micropython et un EDI Python très simple comme Thonny côté PC n'est pas plus compliqué à prendre en main il me semble avec le côté connecté WiFi ou Bluetooth en prime...

---

Ben en fait ce choix n'est pas le mien mais je suppose que l’Arduino a été choisi car il est populaire, répandu... On ne prend pas de risque...

Citation:

---

AVERTISSEMENT : Cette configuration ne permet pas une utilisation à fréquence d’échantillonnage élevée de la carte Arduino : les manipulations type « générer un signal sonore » ou « mesurer une distance par ultrasons » ne sont donc pas possibles.

---

C'est quand même très embêtant pour des physiciens:?

Citation:

---

Envoyé par Delias

Au final dans ce cas d’utilisation l'Arduino n'est plus qu'un simple RTU.

---

Ah merci, je cherchais le bon terme.

Citation:

---

Envoyé par Delias

Je trouve que enseigner de la sorte est particulièrement maladroit.
On veut faire de l'embarqué, mais on doit y adjoindre un PC pour faire le boulot et on est limité entre 1/10ème et 1/100ème de ce que la puce est capable de faire.

Au final dans ce cas d’utilisation l'Arduino n'est plus qu'un simple RTU. Car quand à faire de l'enseignement, autant dire clairement ce que l'on fait.

---

Oui c'est vrai que cela peut paraitre étrange, j'avais aussi réagi comme cela, je m'étais dit dés le début qu'à priori Python n'était pas le meilleur langage pour programmer un microcontrôleur... Mais Python a la cote et figure au programme alors je suppose que c'est pour cela qu'il a été choisi... Apprendre un autre langage comme le C++ ça fait peut-être beaucoup pour des étudiants en physique pour qui l'informatique n'est pas la matière principale... En plus certains ont déjà du mal avec Python...

C'est la première année alors il n'y a pas encore de retour...

Citation:

---

Envoyé par f-leb

C'est quand même très embêtant pour des physiciens:?

---

Oui nous sommes d'accord c'est bien dommage... Je pense que ce sera juste pour faire découvrir après je suppose que ceux qui seront vraiment intéressés se spécialiseront...

PS : Je ne sais pas ce qu'est un RTU (le lien est-il bien correct ?) mais c'est vrai que lorsque j'ai expliqué cela j'avais dit que de cette manière on ne "fait pas vraiment de l'Arduino", le dispositif électronique pourrait très bien être autre chose (un multimètre ou un oscilloscope avec sortie série).

Ceci dit en physique on utilise bien des cartes d'acquisition avec le logiciel qui va avec (une sorte d’oscilloscope numérique sur pc...).

Je reviens sur ce point :

Citation:

---

AVERTISSEMENT : Cette configuration ne permet pas une utilisation à fréquence d’échantillonnage élevée de la carte Arduino : les manipulations type « générer un signal sonore » ou « mesurer une distance par ultrasons » ne sont donc pas possibles.

---

Je pense que c'est lent car on installe un firmware pour pouvoir ensuite programmer (d'une manière générale) l'Arduino en Python mais si on voulait que ce soit plus rapide ne pourrait-on pas charger un code C++ plus spécifique, un code qui ferait les mesures rapidement et les transmettrait via le port série pour être traiter (comme par exemple afficher la courbe) avec un code Python ?

Cela reviendrait à faire ce que l'on fait déjà en physique : utiliser une carte d'acquisition avec le logiciel qui va avec (une sorte d’oscilloscope numérique sur pc...).

Bonsoir

Voilà le lien est corrigé (problème au copier). En français cela doit être module d'entrée/sortie déporté, sans en être certain.

Cela me rappel cette discussion: Créer un son d'une fréquence déterminée avec un programme Python et Arduino. J'explique quoi faire pour aller plus loin!

En gros on est capable de commander en statique les sorties (allumer, éteindre ou valeur PWM pour celles qui le peuvent) de lire l'état (haut, bas ou valeur en analogique) et c'est tout!
Pas de fréquence, pas de référence temps un minimum précis donc pas de mesure de fréquence d'un signal de capteur, pas d'utilisation des bus de donnée.

Si je compare avec mes études (génie électrique) cela ne couvre même pas ce que l'on a fait au premier labo d'embarqué (en sachant que l'on a deux cours de 7 respectivement 14 labos, le premier en ASM sur AVR le deuxième en C sur DSP, c'était en 2002-2007). Avec nous il y avait également des futures ingénieur en génie mécanique et en matériaux, il ne faut pas me dire qu'ils ont de la facilité en informatique.

Et un autre point, être confronté dès le début à plusieurs langages force à séparer la logique (l’algorithme) de la syntaxe, c'est extrêmement formateur!

Delias

Merci pour la correction du lien et aussi pour le lien de la discussion, je vais regarder cela...

Sinon peut-être que le responsable de la formation changera d'avis sur la manière d'enseigner ce module...

Je trouve dommage d'utiliser Python pour programmer un Arduino. Autant utiliser les outils développés pour ce genre de carte et adaptés au microcontrôleur.

Citation:

---

Envoyé par Beginner.

J'ai vu un cas où on programme l'arduino en c++ pour envoyer régulièrement la tension sur le port série et alors on peut se servir d'un code en python pour lire le port série et traiter les données...

---

Oui, tu peux utiliser Python pour communiquer avec un Arduino. Le programme tournera sur ton PC. Il faudra veiller à régler les contrôles de flux (rts, cts) correctement en fonction de l'Arduino choisi.

@Delias, sous couvert de Beginner et f-leb qui sont dans l'enseignement,
L'éducation nationale en France a décidé t'introduire une langage de programmation à partir du lycée (Secondaire II en Suisse ?) afin de familiariser les futurs étudiants aux notions d'informatique/algorithmie et je crois que c'est une sorte d'initiation à la recherche si j'ai bien compris la circulaire que j'ai lu sur le site du ministère de l'éducation. La nuance c'est qu'il ne faut pas que ça se transforme en cours d'informatique car ce n'est pas le but, il faut que ce soit vu comme un outil d'apprentissage. Je crois comprendre que c'est le professeur de Physique qui est désigné pour apporter cet outil aux étudiants ? La question qu'est ce que le prof de Physique va bien pouvoir faire avec ses étudiants en Python ?

C'est sans doute pour cette raison que l'approche te semble bizarre.


@Beginner,
Faire du Python ou microPython sur un microcontrôleur (http://micropython.org/stm32/) est à mon avis une mauvaise solution car ça va amener un double problème; il faut apprendre le python + le microcontrôleur sans pour autant que le cours de Physique ne se transforme en cours d'électronique et d'informatique. A mons avis ça irait directement dans le mur :aie:

En revanche

Citation:

---

Envoyé par Beginner

ne pourrait-on pas charger un code C++ plus spécifique, un code qui ferait les mesures rapidement et les transmettrait via le port série pour être traiter (comme par exemple afficher la courbe) avec un code Python ?

Cela reviendrait à faire ce que l'on fait déjà en physique : utiliser une carte d'acquisition avec le logiciel qui va avec (une sorte d’oscilloscope numérique sur pc...).

---

C'est exactement l'approche qui a été choisi pour le module Scilab-Arduino de SciLab pour les classes prépas http://www.demosciences.fr/projets/scilab-arduino. Le pas d'échantillonnage est géré ! Quasi tout le boulot est fait côté Arduino, il faut "juste" mettre Python à la place de Scilab.

Citation:

---

Envoyé par f-leb

Citation:

---

AVERTISSEMENT : Cette configuration ne permet pas une utilisation à fréquence d’échantillonnage élevée de la carte Arduino : les manipulations type « générer un signal sonore » ou « mesurer une distance par ultrasons » ne sont donc pas possibles.

---

C'est quand même très embêtant pour des physiciens

---

C'est même catastrophique...
Avec un pas d'échantillonnage le prof de Physique peu apprendre a ses élèves comment faire l'intégrale approchée d'un signal par la méthode des rectangles, puis des trapèzes, puis par la méthode de simpson, il va pouvoir leur faire faire des dérivées approchées du signal, ... et démarrer l'analyses numériques.

Citation:

---

Envoyé par Auteur

Je trouve dommage d'utiliser Python pour programmer un Arduino. Autant utiliser les outils développés pour ce genre de carte et adaptés au microcontrôleur.

---

Tout-à-fait nous sommes d’accord...

Ah petite question : le langage dit "Arduino" c'est une sorte de C++ simplifié, non ?
Je me demandais aussi si dans le code C++ on pouvait mettre une portion de code en assembleur ?

Citation:

---

Envoyé par Auteur

Oui, tu peux utiliser Python pour communiquer avec un Arduino. Le programme tournera sur ton PC. Il faudra veiller à régler les contrôles de flux (rts, cts) correctement en fonction de l'Arduino choisi.

---

Ok merci c'est donc une piste à creuser...

Citation:

---

Envoyé par Vincent PETIT

@Beginner,
Faire du Python ou microPython sur un microcontrôleur (http://micropython.org/stm32/) est à mon avis une mauvaise solution car ça va amener un double problème; il faut apprendre le python + le microcontrôleur sans pour autant que le cours de Physique ne se transforme en cours d'électronique et d'informatique. A mons avis ça irait directement dans le mur :aie:

---

Oui j'ai pensé la même chose et d'ailleurs je l'ai dit au responsable de la formation... En fait comme c'est la première année il n'y a pas encore de recul même si certains soupçonnent déjà que cela ne pas fonctionner...

Citation:

---

Envoyé par Vincent PETIT

En revanche

C'est exactement l'approche qui a été choisi pour le module Scilab-Arduino de SciLab pour les classes prépas http://www.demosciences.fr/projets/scilab-arduino. Le pas d'échantillonnage est géré ! Quasi tout le boulot est fait côté Arduino, il faut "juste" mettre Python à la place de Scilab.

---

Ok donc c'est une piste à creuser... Merci pour le lien.

Il y a du monde par ici:mrgreen:

Citation:

---

Envoyé par Vincent PETIT

L'éducation nationale en France a décidé t'introduire une langage de programmation à partir du lycée (Secondaire II en Suisse ?) afin de familiariser les futurs étudiants aux notions d'informatique/algorithmie et je crois que c'est une sorte d'initiation à la recherche si j'ai bien compris la circulaire que j'ai lu sur le site du ministère de l'éducation. La nuance c'est qu'il ne faut pas que ça se transforme en cours d'informatique car ce n'est pas le but, il faut que ce soit vu comme un outil d'apprentissage.

---

En Maths on y apprend l'algorithmie, en Physique/chimie/Sciences et Vie de la Terre il y a des besoins d'expérimentation/mesures avec des capteurs, il y a maintenant des spécialités informatiques, etc., bref plusieurs disciplines. Je pense qu'il était judicieux de choisir un langage commun, avant que chacun ne parte de son côté avec son petit langage de prédilection. Et comme Python est adapté pour tout, même l'embarqué:aie:

Fixer un cadre était nécessaire, mais du coup, l'Ed Nat aurait pu (dû) s'autoriser cette petite entorse en programmant l'Arduino avec le langage du même nom qui est tout autant adapté au monde éducatif. Je ne connais pas les textes officiels en Physique, mais il y a des textes officiels qui en général n'imposent pas de langage ou de matériel particulier, et des personnes haut-placées qui interprètent les textes pour imposer leur point de vue:aie:

Bonsoir à tous

Secondaire, c'est l'avant-dernière année avant le bac?
Moi j'étais dans l'apprentissage de l'ASM d'un micro Siemens 8 bits:aie:. Après avoir fait du pseudo Turbo Pascal sur Delphi 1 au moyen de l'unité WinCRT l'année d'avant. (mais bon c'était un CFC, pardon un CAP, d'électronicien.)

Mais là c'est 1ère prépra, donc l'équivalent de la première du cycle Bachelor. Pour des futurs physiciens il y a quand-même des bases à avoir. À ses débuts, l'informatique fut développée par les physiciens avant de devenir une branche à part (du moins à mon école).

Citation:

---

Envoyé par f-leb

Et comme Python est adapté pour tout, même l'embarqué:aie:

---

Ouai bon je n'ai pas voulu réagir, mais c'est n'importe quoi. Comment un langage incapable de fonctionner sur plus de 50% des modèles de puces concernées peut être classé premier? Ou alors l'embarqué ce n'est plus que les micro-ordi avec OS et je passe pour un dinosaure?

Sur Arduino Uno, il est possible de faire de l'ASM (spécifique AVR), C et C++. On évitera pour autant de faire de la gestion mémoire dynamique (toutes les variables sont définie dans le code et reçoive une adresse par le compilateur, pas de malloc, free, etc.) et du polymorphisme (méthode virtuelle) car bien que admit par le compilateur il n'y a pas les protections de dépassement (pour la mémoire) et cela plombe les perfs.
Le langage Arduino c'est du C++ avec une bonne couche de bibliothèques et un code de base (le main() qui appel le setup() et le loop() et qui gère certains périphériques comme les timers).
L'ASM est intégrable dans le code mais le mélange avec le C/C++ est "difficile" (dans le sens qu'il faut avoir la doc sous les yeux et faire super gaffe) car l'architecture a 32 registres d'usage général, pas A et B comme sur x86. Il y a une application sheet d'Atmel là dessus (principalement c'est comment le compilateur C/C++ gère ces 32 registres pour interfacer proprement les données entre les parties et ne pas effacer quelque chose qu'il ne faut pas) voir ici également. C'est copieux. Pour des débutants c'est soit ASM soit C/C++, mais inutile de vouloir les mélanger. De plus on peut accéder à 100% des fonctionnalité de la puce en C/C++, inutile de faire de l'ASM sauf à vouloir gratter des pour mille de performance. Par contre faire en C ou en C++ au lieu de Arduino c'est minima 25% de perfs en plus.

Vous voulez faire de l'embarqué, alors faîtes de l'embarqué dans son langage. Arduino reste simple à comprendre.

La solution python c'est plus du genre "acquisition de signal" et là LabView c'est 1'000'000 fois mieux. Tout le traitement du signal peut être fait rapidement sans pour autant mettre les mains dans le cambouis. Et à mon avis la solution Python est plus compliquée et plus décourageante que l'Arduino ou LabView. (Mais LabView ce n'est pas pour la 1ère prépra, c'est pour plus tard).

Bonne suite

Delias

Citation:

---

Envoyé par Delias

Ouai bon je n'ai pas voulu réagir, mais c'est n'importe quoi. Comment un langage incapable de fonctionner sur plus de 50% des modèles de puces concernées peut être classé premier? Ou alors l'embarqué ce n'est plus que les micro-ordi avec OS et je passe pour un dinosaure?

---

Tout à fait d’accord, s’il faut l’utiliser de manière avancée en physique / au travers de plusieurs matières, c’est une décision dénuée de sens. Il serait bon de Clarifier l’objectif, définir les acquis que l’on souhaite obtenir et ensuite regarder les solutions possibles.

Citation:

---

Sur Arduino Uno, il est possible de faire de l'ASM (spécifique AVR), C et C++. On évitera pour autant de faire de la gestion mémoire dynamique (toutes les variables sont définie dans le code et reçoive une adresse par le compilateur, pas de malloc, free, etc.) et du polymorphisme (méthode virtuelle) car bien que admit par le compilateur il n'y a pas les protections de dépassement (pour la mémoire) et cela plombe les perfs.

---

Arduino c’est à la fois la carte et l’IDE. Il n’y a pas de «*langage*» arduino. L’IDE a choisi la programmation en C++ , c’est LE C++ standard avec un compilateur standard (bien sûr avec les contraintes matérielles, pas d’OS embarqué, peu de mémoire, pas de clavier, écran en standard etc)

L’environnement de développement offre des bibliothèques de fonctions et de classes (les fameuses ‘Libraries’). Je suis d’accord sur la recommendation d'être Plutôt en mémoire RAM statique car il y en a peu, mais bien géré le malloc() reste envisageable (plus sur ESP) même si déconseillé en général sur petit micro-contrôleur.

La notion de hiérarchie de classe cependant / polymorphisme etc n’apporte aucune réelle contrainte pour la majorité des applications et rend le code et sa maintenance plus simple, au final c’est entièrement compilé. Effectivement dans le cadre du run-time polymorphisme le compilateur rajoute du code pour identifier le pointeur sur la bonne fonction, c’est une indirection relativement courte pour trouver quelle fonction choisir, et ça ne plombe pas trop les performances pour l’essentiel des usages (qui se contente le plus souvent de juste la surcharge de fonctions ou opérateurs)

Il faut l’utiliser à bon escient, comme tout bon outil mais se passer des vertus de la programmation orientée objet et ses concepts associés c’est rater une opportunité de réflexion sur la bonne structuration d’un code et sa maintenabilité (et ça permet de comprendre ensuite les librairies et leur usage)

Un souci commun que je vois dans l’usage du python c’est le niveau d’abstraction très élevé fait que les apprenants ne comprennent pas ce qu’il se passe en dessous au niveau mémoire et performance. de même on voit tous les jeunes (et moins jeunes) utiliser abondamment la classe String sur petit arduino alors que c’est un risque pour le morcellement mémoire (allocation dynamique, pas de ramasse miettes), les performances et la taille du programme... le C ou C++ est bcp plus adapté à ces architectures embarquées, c’est tout...

Citation:

---

Pour des débutants c'est soit ASM soit C/C++, mais inutile de vouloir les mélanger. De plus on peut accéder à 100% des fonctionnalité de la puce en C/C++, inutile de faire de l'ASM sauf à vouloir gratter des pour mille de performance.

---

oui la phase d’optimisation du compilateur fait que bien souvent le code généré sur base de C++ sera plus performant que du code assembleur écrit à la main.

Citation:

---

Par contre faire en C ou en C++ au lieu de Arduino c'est minima 25% de perfs en plus.

---

Je pense que ce genre de phrase à l'emporte Pièce ne veut rien dire. Comme vous l’avez expliqué Arduino ce n’est pas un langage de programmation, donc vous mélangez les serviettes et les torchons. On fait du C++ même quand in appelle les fonctions et Libraries fournies dans le cadre de l’environnement de développement (IDE). Les auteurs de ces fonctions ayant voulu faire «*portable*» et «*ceinture bretelle*» , c’est clair que l’efficacité comparée à titiller en direct un registre n’est pas au rendez vous. En échange l’apprenant n’a qu’à se souvenir de digitalRead() ou digitalWrite() et ça fonctionnera sur ATMEGA, ESP,... sans avoir à se plonger dans la doc de référence de l’architecture du micro-processeur;

Citation:

---

Vous voulez faire de l'embarqué, alors faîtes de l'embarqué dans son langage. Arduino reste simple à comprendre.

La solution python c'est plus du genre "acquisition de signal" et là LabView c'est 1'000'000 fois mieux. Tout le traitement du signal peut être fait rapidement sans pour autant mettre les mains dans le cambouis. Et à mon avis la solution Python est plus compliquée et plus décourageante que l'Arduino ou LabView. (Mais LabView ce n'est pas pour la 1ère prépra, c'est pour plus tard).

---

1000% d’accord. On devrait apprendre à l’école à utiliser le bon outil au bon moment, dans le cadre d’une démarche scientifique d’analyse du besoin... sinon on tombe dans l’aphorisme appelé “Marteau de Maslow”:
« Si le seul outil que vous avez est un marteau, vous tendez à voir tout problème comme un clou »
Abraham Maslow (The Psychology of Science, 1966).

Cette tentation qui consiste à travestir la réalité d’un problème en le transformant en fonction des réponses dont on dispose, ou encore le fait de considérer qu’il n’y a qu’une réponse unique à tous les problèmes est une hérésie scientifique....

Il faut vite tuer cette idée pour le bien des futures générations et la santé mentale de nos profs de physique et maths...:calim2::(



EDIT: je voulais en avoir le coeur net sur le coût du "runtime polymorphism" pour les fonctions virtuelles, où le compilateur doit décider lors de l'exécution quelle fonction appeler. j'ai donc écrit ce petit bout de code, avec une classe et sous classe utilisant une fonction membre virtuelle et un tableau d'éléments du type de la classe de base mais contenant un exemplaire d'instance de la classe de base et un autre de la classe dérivée.
puis j'ai écrit une autre hiérarchie avec juste de la surcharge de fonction membre.
le code mesure (à la louche et aux interruptions près) en micro-seconde le temps d'exécution de l'appel (sachant que j'ai moins de 64 caractères dans le buffer série, donc la fonction print ne sera pas bloquante);

Code:

---

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 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70

class ClasseDeBaseVirtual { public: virtual void coucou() { Serial.println(F("Coucou de base ")); } };   class ClasseDeriveeVirtual: public ClasseDeBaseVirtual { public: void coucou() { Serial.println(F("Coucou de Derivee")); } };   class ClasseDeBase { public: void hello() { Serial.println(F("Hello de base ")); } };   class SousClasse: public ClasseDeBase { public: void hello() { Serial.println(F("Hello de SousClasse")); } };     ClasseDeBaseVirtual* liste[] = {new ClasseDeBaseVirtual, new ClasseDeriveeVirtual};   ClasseDeBase b; SousClasse s;   void setup() { Serial.begin(115200); unsigned long chrono; volatile size_t index;// pour éviter les optimisations du compilateur   Serial.println(F("----- RESOLUTION DYNAMIQUE AU RUNTIME -----")); index = 0; chrono = micros(); liste[index]->coucou(); Serial.println(micros() - chrono); delay(1000); // pour ne pas être impacté par les interruption du Serial.print   index = 1; chrono = micros(); liste[index]->coucou(); Serial.println(micros() - chrono);   Serial.println(F("----- RESOLUTION STATIQUE A LA COMPILATION -----")); delay(1000); // pour ne pas être impacté par les interruption du Serial.print   chrono = micros(); b.hello(); Serial.println(micros() - chrono);   delay(1000); // pour ne pas être impacté par les interruption du Serial.print chrono = micros(); s.hello(); Serial.println(micros() - chrono); }   void loop() {}

---

si vous exécutez ce bout de code sur un UNO, on voit dans le moniteur série (à 115200 bauds)

Citation:

---

----- RESOLUTION DYNAMIQUE AU RUNTIME -----
Coucou de base
148
Coucou de Derivee
136
----- RESOLUTION STATIQUE A LA COMPILATION -----
Hello de base
148
Hello de SousClasse
148

---

On voit donc que la résolution dynamique apporte une petite variation (136μs versus 148μs entre les 2 appels) alors que le temps est constant pour la partie statique ) 148μs

-> Sachant en plus que la résolution de la fonction micros() est de 4 μs on ne peut pas dire que le prix à payer soit exorbitant - les valeurs sont "comparables" en premier abord et à notez qu'on a en plus le prix d'un appel à micros() et le temps d'une soustraction sur un unsigned long en plus dans le temps calculé.. donc on n'est pas super précis..

Si on veut aller plus loin on pourrait basculer la valeur d'une pin avant et après l'appel de fonction et mesurer à l'oscilloscope (en déclenchant sur front montant) la durée de l'appel de fonction.

voici un nouveau code à peu près similaire mais dans lequel
- J'ai réduit la taille de ce qu'on imprime (ça génère des interruptions qu'on ne veut pas)
- J'ai augmenté le débit en baud pour minimiser les temps à attendre.
- J'ai viré le timing par calcul sur le nombre de microsecondes
- J'utilise le registre PINB (ça prend 1 cycle donc 62.5ns) pour basculer la pin 8

Code:

---

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 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71

class ClasseDeBaseVirtual { public: virtual void coucou() { Serial.write('1'); } };   class ClasseDeriveeVirtual: public ClasseDeBaseVirtual { public: void coucou() { Serial.write('2'); } };   class ClasseDeBase { public: void hello() { Serial.write('3'); } };   class SousClasse: public ClasseDeBase { public: void hello() { Serial.write('4'); } };     ClasseDeBaseVirtual* liste[] = {new ClasseDeBaseVirtual, new ClasseDeriveeVirtual};   ClasseDeBase b; SousClasse s;   void setup() { Serial.begin(1000000); pinMode(8, OUTPUT); // le pin 8 est sur le port B de mon UNO, sur le bit de poid faible digitalWrite(8, LOW); // on met la pin 8 au repos   delay(1000);   volatile size_t index;// pour éviter les optimisations du compilateur   index = 0; PINB = 0b00000001; // on active (bascule) la pin 8. cette instruction est 1 cycle d'horloge soit 62.5ns sur un UNO à 16Mhz liste[index]->coucou(); PINB = 0b00000001; // on désactive (bascule) la pin 8. cette instruction est 1 cycle d'horloge soit 62.5ns sur un UNO à 16Mhz delayMicroseconds(10); // pour ne pas être impacté par les interruption du Serial.write   index = 1; PINB = 0b00000001; // on active (bascule) la pin 8. cette instruction est 1 cycle d'horloge soit 62.5ns sur un UNO à 16Mhz liste[index]->coucou(); PINB = 0b00000001; // on désactive (bascule) la pin 8. cette instruction est 1 cycle d'horloge soit 62.5ns sur un UNO à 16Mhz delayMicroseconds(10); // pour ne pas être impacté par les interruption du Serial.write   PINB = 0b00000001; // on active (bascule) la pin 8. cette instruction est 1 cycle d'horloge soit 62.5ns sur un UNO à 16Mhz b.hello(); PINB = 0b00000001; // on désactive (bascule) la pin 8. cette instruction est 1 cycle d'horloge soit 62.5ns sur un UNO à 16Mhz delayMicroseconds(10); // pour ne pas être impacté par les interruption du Serial.write   PINB = 0b00000001; // on active (bascule) la pin 8. cette instruction est 1 cycle d'horloge soit 62.5ns sur un UNO à 16Mhz s.hello(); PINB = 0b00000001; // on désactive (bascule) la pin 8. cette instruction est 1 cycle d'horloge soit 62.5ns sur un UNO à 16Mhz }   void loop() {}

---

Voilà à quoi la capture écran de l'oscilloscope ressemble:
Pièce jointe 502905

On peut voir que le temps d'exécution de notre fonction avec résolution du pointeur de fonction au runtime est de l'ordre de réellement de 7μs (incomparable avec les 148μs ci dessus car pas le même texte ni usage de la macro F()) alors que le temps d'exécution de notre fonction au contenu similaire en résolution à la compilation est de l'ordre de 5.5μs. Pour être exact il faudrait enlever le temps d'indirection puisque je vais chercher les instances dans un tableau mais Il y a donc effectivement un impact de performance en pourcentage de l'ordre de 15% à 25% je pense - ce qui est beaucoup en absolu si on est pressé, mais en pratique on ne parle que de 1 à 1.5 micro-seconde d'écart, ce qui conviendra à une très grande majorité.

Bien sûr si on avait une hiérarchie de classes plus profonde ce serait un peu plus pénalisant, mais la majorité des cas que j'ai vu ne dépassent pas ce genre de construction à 1 étage et si c'est un truc au coeur d'une boucle critique ou chaque microseconde compte, alors on évitera effectivement les fonctions membres virtuelles

et.... c'est trop avancé de toutes façons pour des débutants :mouarf::mrgreen:

Citation:

---

Envoyé par Delias

Secondaire, c'est l'avant-dernière année avant le bac?

---

C'est ça et en France on veut même commencer à familiariser les étudiants à l'informatique à l'avant-avant dernière année avant le bac.

L'idée n'est absolument pas de faire de l'embarqué car il y a des spécialités pour ça et elles viennent plus tard sachant aussi que les étudiants ont la liberté de se réorienter après. Et entre nous, si le prof de Math doit en plus de son programme classique, doit aussi faire tout un programme d'informatique il est clairement mal. Pareil pour le prof de Physique.

La langage informatique doit permettre d'explorer les mathématiques différemment (comment je modélise un problème, comment je raisonne de manière logique, comment je visualise une distribution....) et pour la Physique, en choisissant un RTU assez simple, on peut donner encore plus de vie à cette science (TP plus vivant, comment j'applique ce que j'ai vu en math sur un problème très réel, comment mettre en oeuvre une convolution avec des vraies signaux pour donner encore plus de sens à ce que j'ai appris en math, ...)

L'étudiant doit voir le langage informatique comme une aide et un outil pour la suite de son parcours scolaire, quel qu'il soit. Mais il ne faut pas en faire un informaticien ni un spécialiste de l'embarqué.

Pour moi l'idée d'avoir choisie Python est bonne.
Le langage est assez facile à prendre en main et ne nécessite pas d'avoir des prérequis "spécialisés". Si on avait choisi le C ou le C++ ça démarrait mal car il le langage est typé (un char c'est 8 bit, un short c'est 16 bits etc...) et il faudrait commencer par aborder des notions d'électronique. En fait le niveau d'abstraction de Python est parfait pour se servir du langage comme "compagnon" de la discipline car c'est ça l'idée.

Citation:

---

Envoyé par Delias

La solution python c'est plus du genre "acquisition de signal" et là LabView c'est 1'000'000 fois mieux. Tout le traitement du signal peut être fait rapidement sans pour autant mettre les mains dans le cambouis. Et à mon avis la solution Python est plus compliquée et plus décourageante que l'Arduino ou LabView. (Mais LabView ce n'est pas pour la 1ère prépra, c'est pour plus tard).

---

Oui je suis d'accord, LabView, Scilab, Matlab aurait été des candidats parfaits quoi que tous sont un peu trop orientés système embarqué. L'étudiant qui continue dans le domaine des maths ne va pas être aidé avec Labview, c'est plutôt Scilab ou Matlab.

Citation:

---

Envoyé par Jay M

On devrait apprendre à l’école à utiliser le bon outil au bon moment, dans le cadre d’une démarche scientifique d’analyse du besoin... sinon on tombe dans l’aphorisme appelé “Marteau de Maslow”:
« Si le seul outil que vous avez est un marteau, vous tendez à voir tout problème comme un clou »
Abraham Maslow (The Psychology of Science, 1966).

Cette tentation qui consiste à travestir la réalité d’un problème en le transformant en fonction des réponses dont on dispose, ou encore le fait de considérer qu’il n’y a qu’une réponse unique à tous les problèmes est une hérésie scientifique....

Il faut vite tuer cette idée pour le bien des futures générations et la santé mentale de nos profs de physique et maths...:calim2::(

---

Oui il faut faire très attention à ça

Citation:

---

Envoyé par Vincent PETIT

Pour moi l'idée d'avoir choisie Python est bonne.
Le langage est assez facile à prendre en main et ne nécessite pas d'avoir des prérequis "spécialisés". Si on avait choisi le C ou le C++ ça démarrait mal car il le langage est typé (un char c'est 8 bit, un short c'est 16 bits etc...) et il faudrait commencer par aborder des notions d'électronique. En fait le niveau d'abstraction de Python est parfait pour se servir du langage comme "compagnon" de la discipline car c'est ça l'idée.

---

On est d'accord, mais il faut dans ce cas se cantonner au mac/pc et pas essayer d'appliquer cela à un arduino... on confond tout ensuite..

et sinon, introduire le code beaucoup plus tôt dans le cursus (à partir du primaire) serait une bonne idée à mon avis... comme ça arrivé en 1ère ou terminale, il y aurait un acquis plus important (et on aurait peut-être ainsi plus de vocations pour le métier d'ingénieur en informatique / électronique ... on en manque cruellement).

Citation:

---

Envoyé par Jay M

On est d'accord, mais il faut dans ce cas se cantonner au mac/pc et pas essayer d'appliquer cela à un arduino... on confond tout ensuite.

---

Mon avis là dessus c'est que si Arduino il y a, par exemple pour la physique à l'aide de Python, il faut qu'il ne serve qu'a acquérir une tension avec un pas d'échantillonnage - peut être avec la possibilité de choisir la Vref interne - et que personne ne le programme ni même le voit (il est juste une centrale d'acquisition) et comme tu le dis, afin que le travaille d'initiation à l'algo et au Python ne se fasse que sur un PC.

Citation:

---

Envoyé par Jay M

et sinon, introduire le code beaucoup plus tôt dans le cursus (à partir du primaire) serait une bonne idée à mon avis... comme ça arrivé en 1ère ou terminale, il y aurait un acquis plus important (et on aurait peut-être ainsi plus de vocations pour le métier d'ingénieur en informatique / électronique ... on en manque cruellement).

---

100% d'accord


- Réflexion très personnelle -
Pour ce que tu écrivais avec le Marteau de Maslow, je crois (et j'en suis intimement persuadé) que Arduino à l'école c'est très casse gueule même si il a été développé dans un but pédagogique. Il y a un trop grand risque d'illusion :

de faire de l'électronique alors que principalement on connecte des cartes électroniques
de concevoir des projets très aboutis sans rien avoir réellement choisie ou dimensionné
de produire des logiciels pointus à l'aide de copier/coller

Le risque d'illusion est d'autant plus fort que les chances de réussite sont quasiment de 100% même en tombant dans les 3 pièges que je viens de noter. Arduino pourrait être perçu comme une solution a tous les problèmes dans les systèmes embarqués.

Ça me fait penser à STM32CubeMx qui permet de configurer visuellement les registres des micro ARM de chez STM32. Cet outil fait gagner un temps de fou et en plus il génère une couche d'abstraction matérielle qui permet finalement de s'affranchir du microcontrôleur. Mais si tu mets ça à l'école, tu créais des promotions complètes d'étudiants qui se retrouveront en grande difficulté face à d'autres microcontrôleurs. Quand ça fait gagner trop de temps et que c'est trop simple, il faut se méfier (surtout si c'est pour de l'apprentissage... lorsqu'on est du métier par contre là je reconnais que ça aide).

Salut,

Je continue de lire les liens que vous m'avez indiqué...
Encore merci.

Je vais ouvrir d'autres fils car du coup je me pose d'autres questions...