Bonjour à tous et merci d'avance à ceux qui répondront malgré le hors sujet. Mais je ne suis que sur ce forum et l'on m'a toujours correctement guidé.
Seulement voilà, la plateforme Arduino m'a beaucoup aidé et j'ai pu (aussi grâce à vous) concevoir des projets utilisés en milieu industriel (je sais Arduino dit qu'il ne faut pas).
Mais mes nouveaux projets s'orientent vers le besoin d'utiliser plusieurs codes en parallèle (Multi thread).
Je compte rester sur le C++ mais sur des Pi Zero.
Ma question est simple et je sais que Arduino n'est pas un langage , mais n'ayant utilisé que ce dernier, face à quelles différences vais je me retrouver entre le C++ et le C++ que j'utilise sur l'IDE, si des différences existes ?
Techniquement, il n'y a aucune différence entre le C++ que vous utilisez dans l'IDE et celui que vous utiliserez pour programmer vos Pi Zero. En revanche il y en a une entre le C++ d'"Arduino" et le C++ sur un micro-ordinateur/ordinateur tout court comme la Pi Zero.
En effet la manière de coder sur Arduino est limitée en grande partie par la quantité de mémoire disponible - 2ko de RAM sur une UNO (de tête), contre 512 Mo pour la Pi Zero.
Sur Arduino, ce que nous appelons par un léger abus de langage du C++, ressemble en réalité à du C (le papa du C++) modifié pour être orienté objet (on peut utiliser des classes sur son Arduino, chose normalement inexistante en C). Le C étant très bas niveau, avec la possibilité (et même le devoir) de gérer manuellement la mémoire (pointeurs), il est adapté aux systèmes embarqués.
On dit (trop) souvent que le C++ c'est du C avec des classes - c'était probablement vrai au début du langage (je n'étais pas là pour vérifier ). Cependant aujourd'hui le C++, même si ressemblant au C en apparence, est en fait différent, avec une manière de programmer différente.
Donc lorsque vous programmez en C++ sur un ordinateur (sans avoir à trop vous soucier de la mémoire disponible - faut quand même pas tout faire péter, hein, mais c'est un problème moindre ), vous pouvez vous permettre d'utiliser des méthodes, des syntaxes ou des conventions, avec une couche d'abstraction (la bibliothèque standard) en plus, apportant à la fois plus de sécurité (notamment sur la gestion de la mémoire), et plus de clarté (donc normalement plus facile à maintenir)
Prenez un exemple tout bête, les string (les chaînes de caractère). Sur le forum on dit souvent, lorsqu'un demandeur à un problème avec un code énorme qui utilise beaucoup la classe String, qu'il devrait essayer de passer au c-string (comme leur nom l'indique, ce sont les chaînes de caractères venues du C).
Les c-string, ce sont des tableaux de caractères (char texte[20] = "foo bar"), terminés par un caractère de fin de chaîne (dit nul - \0), que l'on gère avec les fonctions du langage C, comme strcmp, strcpy, strcat, et autres...
C'est long, fastidieux, peu lisible, et assez dangereux puisqu'il faut gérer sois même la mémoire, le caractère nul. Même si la classe String existe sur Arduino, elle consomme beaucoup de mémoire, ce qui rend son utilisation difficile.
En C++, sur un micro-ordinateur comme la Pi Zero, ou un ordinateur classique, tout deux avec de la mémoire à foison, se trouve dans la bibliothèque standard (en-tête string) le "type" string, qui permet de gérer une grande partie de ces problèmes - que n’énumérerai pas ces bienfaits ici, cela prendrai trop de temps En tout cas usez et abusez de cette bibliothèque standard
➜ Bref, tout ça pour dire que c'est une manière de coder différente, même si en soi le langage ne change pas beaucoup en apparence.
(Et ce que l'on peut éventuellement reprocher à Arduino, c'est de ne pas (assez) faire cette différence entre le C/C++ qu'ils utilisent et le C++ sur ordinateur/micro-ordinateur... Après ça fait des développeurs C++ qui codent en C, faut tout réapprendre - en tout cas moi c'est ce que je ressens maintenant que je fais aussi du C++ sur ordinateur, j'ai des pratiques instinctives pas terribles... )
En espérant vous avoir été utile et ne pas avoir dit trop de bêtise ,
Cordialement,
Pandaroux007
PS : pour faire du multi-threads, sauf à ce que votre projet soit vraiment conséquent en mémoire, vous pouvez vous orienter vers l'ESP32 - cela vous permettra, en plus d'une consommation électrique moindre par exemple, de rester sur le C/C++ que vous connaissez...
Tout dépend de quoi on parle.
Avec ARDUINO IDE on utilise une chaîne de cross-compilation C/C++ AVR-GCC (arm-none-eabi-gcc) qui permet de générer du code AVR à partir d'un PC.
Avec une PI ZERO la chaîne de compilation GCC est native (pas cross). La compilation se fait sur la RPI et la cible est également la RPI.
Pour ce qui est du langage, il s'agit bien de C++ dans les deux cas. Cela ne fait aucune différence.
Désolé pandaroux007 nous ne sommes pas d'accord. Le C++ ARDUINO n'est pas du C modifié pour être orienté objet. Le compilateur est le même, seule la cible diffère.
Par contre pour ce qui concerne les librairies cela fait une énorme différence.
La librairie standard C est présente dans les deux cas. Elle fournit les fonctions classiques C (sprintf(), strcpy(), malloc() et bien d'autres).
Sur RPI, les fonctions ARDUINO (digitalWrite(), analogRead(), etc.) n'existent pas nativement. Si tu désires en profiter il faut que tu installes une librairie, par exemple WiringPI.
Je n'ai pas parlé d'IDE.
Tu peux bien sûr installer ARDUINO IDE sur une RPI, mais cela ne t'avancera pas à grand chose, puisque tu ne pourras pas adresser, à ma connaissance, la cible RPI ZERO.
Soit tu installes un IDE Linux, Geany par exemple, soit tu travailles avec un simple éditeur et un Makefile.
Du boulot sur la planche ...
Il n'y a pas de mal, effectivement je me suis trompé dans la formulation - on pense la même chose il me semble
En effet le compilateur est le même. Mais comme la plateforme qui va recevoir le code est différente (un Arduino avec une faible quantité de mémoire dans un cas, un micro-ordinateur de l'autre), la manière de coder change beaucoup!
Les pratiques acquises lorsque l'on fait de l'Arduino sont plus proches de celles utilisées en C que celles du C++ moderne, bien que ce soit le même langage, ce qui impacte, par exemple, les méthodes utilisées (vector, string, etc...)
Bonsoir,
Je rejoins totalement ce que dit @pandaroux007
ou la pi pico
Pi Zéro est plutôt faite pour utiliser un système embarqué comme Linux ce qui n'en fait pas l'outil idéal pour le multithreading ou le temps réel. Il faut en plus créer une chaine de compilation croisée avec un IDE comme VSCode parce qu'a ma connaissance il n'y a pas d'outil tout fait.
ESP32 ou Pi pico utilise un RTOS comme FreeRTOS adapté au multithreading ou au temps réel. Les deux disposent d'un outil tout fait, ESPIDF et Pi Pico qui fonctionnent avec VSCode et permettent un démarrage rapide sans connaissances particulières.
Pour le langage je rejoins aussi @pandaroux007 la manière de coder est totalement différente mais rien n'oblige l'utilisation du C++ le C convient parfaitement aux projets "industriels" Du reste ESPIDF et Pi Pico sont des librairies C.
Quand je dis cela je parle de langage, donc uniquement de syntaxe, pas de temps réel ou de librairie.
Or ce que l'on appelle langage ARDUINO n'est que du c++, rien d'autre ...
Voici un petit bout de code (je sais peut mieux faire) :
En l'état peut il fonctionner. Le but étant que ce code ne sera qu'une fonction d'un automate gérant d'autres choses en parallèle.
Concernant le stockage dans EEPROM je pense que je devrais faire cela directement dans un fichier texte.
int main(void)
{
setup();
for (;;) {
loop();
}
return 0;
}
Ensuite à toi d'écrire setup() et loop() comme d'hab.
Pour ce qui concerne ton code, une PI ZÉRO ne me paraît pas justifiée.
En général on adopte une RPI lorsque l'on a besoin de ressources particulières et gourmandes en mémoire, une base de données par exemple, ou un serveur à écrire en PHP, gérer un écran de grandes dimensions, etc.
Là je ne vois pas ...
Deuxio, il ne faut pas t'imaginer que coder avec des périphériques sur une RPI est aussi simple.
Pour info voici la liste des devices supportés par WiringPi : https://github.com/WiringPi/WiringPi/tree/master/wiringPi
Tu pourras remarquer que c'est très limité, et que LiquidCrystal est absent.
Ce besoin pourrait être couvert en adoptant un ESP32 + FreeRTOS, ce qui serait plus proche d'une cible ARDUINO, bien que je ne sois pas persuadé qu'en mono-thread tu ne puisses pas réaliser ce que tu désires faire.
Attention, le multi-thread n'est peut être pas aussi simple que tu ne l'imagines.
PS : en général, quand on pose une question il est préférable de décrire le projet, ce qui manque dans ton premier post. J'ai donc répondu strictement à la question que tu posais.
En l'absence de description précise, impossible de faire plus.
Tu aurais pu faire l'effort d'adopter un afficheur avec module I2C, du genre PCF8574, plus facile à câbler (2 fils + VCC + GND).
Et là on trouve une librairie :
Pour décrire le projet je souhaite gérer un ensemble porte+pont hydraulique+cale de roue.
Jusque là les machines état m'ont bien aidé, mais juste concernant la fermeture de la porte je suis limité à utiliser des fins de courses mécaniques.
Si j'utilise un encodeur pour connaitre la position de la porte (c'est souvent le cas sur les portes industrielles) :
Lors de la descente, je dois constamment lire l'encodeur (RS485), mais aussi les différentes sécurités (Cellules infrarouges, palpeur résistif etc)
J'ai peur que mon Arduino soit en train de lire l'état d'une sécurité au moment où il passe la position basse et donc que la porte descende trop bas.
Après je viens de lire un peu sur ESP32+FreeRtos et je vais peut être tenté par là.
Quel est la vitesse de ta porte et quelle précision tu as réellement besoin d'avoir ?
Comme tu semble avoir une machine à état, normalement ta réactivité et du même ordre que le pire temps d'exécution d'un tour de boucle de ta machine à état.
Ce choix paraît assez logique, l'ESP32 avec ses deux cores permet de faire du multithreading performant.
Tu as la possibilité de continuer avec Arduino, VSCode et PlatformIO ou VSCode avec l'outil Espressif. Tout dépend de l'investissement temps que tu veux passer pour commencer et du résultat final que tu recherches
Il ne faut pas se buter sur le langage, si on connaît C++ le C ne pose aucun problème et le C++ bien que possible dans tous les IDE ne présente quasiment aucun intérêt
En sortie de réducteur j'ai en moyenne 24t/min, à savoir que les encodeurs font 1 tour lorsque le moteur en fait 25.
Et une porte descend à environ 0.2m/s.
On peut tolérer un écart de 10mm car un joint rattrape l'étanchéité en bas de porte.
Oui en effet je vais aussi regarder concernant le C, prendre quelques tutos pour voir si je m'y acclimate.
Après c'est un projet pour une finalité dans 3 ou 4 ans. Je ne suis pas pressé, mais le multi threading m'intéresse aussi car il sera (à mon avis) plus apte à répondre à certaines évolution auxquelles ma carte devra faire face.
Merci à tous pour vos réponses, j'ai pas mal tourné le sujet dans tout les sens et je pense que je vais faire les deux en parallèle. C'est à dire : Tester un prototype Arduino classique et me former à coté sur le multithreading. Et si mon prototype a des failles pour les raisons évoqués plus haut je passerais donc sur esp32 + FreeRtos. Me sortez pas une solution miracle maintenant je viens de passer commande de plusieurs Arduino Mega.
Je n'ai pas pu répondre plus tôt, mais j'ai vu quelques réponses qui ont été déplacé dans d'autres sections.
Sachez que certains ayant répondu à ce post et qui se sont pris le bec, ont grandement contribué à mon évolution sur Arduino. Des réponses de @hbachetti et de @pandaroux007 par exemple sur des posts d'autres utilisateurs m'ont permis de corriger mes erreurs ou encore le gros tuto de @J-M-L sur les machines états qui sont devenu une encre de mes connaissances . Ayant arrêté tôt les études (oui je fais pleins de fautes) et n'ayant qu'internet pour seule école, considérez vous comme mes professeurs.
Vous êtes tous très compétents et heureusement que la communauté francophone vous à pour répondre aux apprenants. Je me doute que certains sujets doivent créer la discorde mais ceux à qui vous avez appris beaucoup, devront à leur tour apprendre à d'autres. Inutile de leur apprendre à ce disputer sur le sujet du C vs C++, ils trouveront bien d'autres sujets de discorde eux mêmes .
Désolé pour ces quelques lignes hors sujet. Merci encore pour vos réponses, à ce posts et aux futurs.