bonjour voilà je crée une nouvelle discussion pour mon problème de programmation
depuis la lecture de vos commentaire dans
[Autre] besoin de renseignement pour créer une empreinte sous Kicad
je penses m'orienter vers un autre type d'µC l'ESP32 ou le Raspberry et travailler sous Python qu'en pensez vous
je crois que je vais enterrer picaxe , paix à son âme .
sur ce je vais faire un peu de lecture avant de tomber dans les bras de morphée
avant de partir une question
comment ce passes le chargement du programme dans l'µC il faut un câble spécifique je suppose , la mise en oeuvre est 'elle facile pourriez vous me faire une liste du matériel à commander
oui je sais ça fait beaucoup
Bonjour.
Une solution simple et économique est d'utiliser une carte Raspberry Pi Pico (RP2040).
Le prix est inférieur à 10€, et il existe un micro python adapté à cette carte.
https://www.raspberrypi.com/products/raspberry-pi-pico/
https://www.raspberrypi.com/document...co-series.html
Il suffit d'un câble USB relié à un PC pour programmer.
Les tutos ne manquent pas.
Bonjour.... et au revoir.Envoyé par Torre 13200
Peut être à plus tard...on sait jamais
MM
Si il y a des erreurs ci dessus, c'est que je n'ai pas eu le temps de les corriger...
Je confirme : le RP2040 est un monstre de rapport prix/possbilités.
Je ne le connais qu'au travers du SDK C/C++ mais je n'ai pas lu/entendu du mal du micropython, ça semble sérieux.
Et venant de Raspberry PI, je serais étonné que ce soit décevant, super sérieuse cette boutique !
https://github.com/micropython/micropython/wiki
Bien évidement, tout est open-source : https://github.com/raspberrypi
( si un jour tu veux aller corriger toi même un bug ou ajouter une fonctionnalité quand tu seras un grand guru du micropython !)
<< have fun >>
[Edit] et le jour ou tu es limite avec un pico, il y a le pico 2 qui est aussi supporté en Tier1 par micropython
Dernière modification par Seb.26 ; Hier à 08h59.
<< In a world without walls and fences, who needs Windows and Gates ? >>
Micropython est interprêté non ?
L'électronique c'est comme le violon. Soit on joue juste, soit on joue tzigane . . .
Non, je pense qu'il est compilé ou au moins pré-compilé, mais comme c'est un langage de très haut niveau, bien loin des registres d'un CPU, donc à mon avis du C++ doit aller bien plus vite, mais est-ce vraiment pénalisant pour faire clignoter 2 led quand une porte s'ouvre ??
NB: par contre je pense (j'éspère) que les librairies d'accès aux périphériques sont en C++.
Mais je n'y connais pas grand chose en micropython !!! ...
Dans ce tuto, il parle bien d'interpréteur micropython : https://passionelectronique.fr/progr...n-micropython/
[Edit] ici https://stm32python.gitlab.io/fr/doc...thon/firmware/
ils parlent de compilation dans un pseudo langage-machine : le bytecode, donc c'est entre les 2 AMA, c'est compilé pour un CPU virtuel en bytecode et exécuté par un interpreteur dans la machine réélle.
Dernière modification par Seb.26 ; Hier à 10h22.
<< In a world without walls and fences, who needs Windows and Gates ? >>
Oui, compilé en bytecode interprété comme Python mais une version différente compte tenu des contraintes des microcontroleurs, 10 à 100 fois moins rapide que du C.
https://docs.micropython.org/en/late.../quickref.html
micropython donne accès aux PIO des RP**** ! ...
Et tu peux écrire des modules micropython en C/C++ si ça doit turbiner ( https://docs.micropython.org/en/late.../cmodules.html )
Donc le fonctionnel haut niveau en uPython "pseudo-compilé" et les modules en C/C++ en binaire natif.
<< In a world without walls and fences, who needs Windows and Gates ? >>
Il n'y a pas de python sur micro mais du micropython. Ça ressemble, c'est pas exactement pareil, bien sûr il y a pas 16 giga de mémoire donc il n'y a pas toutes les libraries, mais ça fait excellement bien le taf.
C'est beaucoup plus lent que le C++ et non adapté au temps réel dur à cause du garbage collector mais c'est hyper pratique et simple à développer, et suffisant pour de nombreuses applications.
ESP32
Choisir ESP32 si tu as besoin de la radio : WiFi, Bluetouf, Zigbee, etc. L'ESP32 a des défauts, comme un ADC dégueulasse et pas assez de GPIO, et il y en a trop c'est chiant à choisir, mais au niveau radio c'est le meilleur.
Une fonction super pratique c'est le pinmux, tu peux mettre n'importe quelle fonction sur n'importe quelle broche. Le PWM LEDC est très bien pour contrôler des LED aussi.
À noter que de nombreux modules ESP32 sont équipés de AMS1117 qui est une merde, à remplacer par un LDL1117 si tu veux pas que ça crash, il faut aussi remplacer le condo tantale par un céramique.
Pi Pico 2 avec RP2350
C'est l'idéal pour tout le reste tant que t'as pas besoin de périphériques que tu trouves que sur un STM32.
Tu branches en USB, tu lances l'IDE Thonny, tu tapes ton code, et tu cliques sur "Envoyer" et voilà le code est dans la puce et ça marche. La console python s'affiche dans la fenêtre, tu peux taper des commandes et les exécuter directement, c'est super simple et pratique.
Il y a une version avec une puce Ethernet qui marche super bien en python (conso 100mA ethernet actif). Il y a une version avec une puce WiFi mais elle est pas stable, déconseillée. Pour le WiFi, ESP32.
Le micro a une grosse RAM, une grosse flash, une puissance démente pour le prix, ce qui fait que python marche très bien. Le gros avantage du RP2350 c'est le PIO, en gros il y a 12 minuscules processeurs dispo pour gérer les GPIO donc ça peut faire à peu près n'importe quel protocole. Contrairement au STM32 il n'y a pas une orgie de périphériques, mais ceux qu'il y a sont hyper bien pensés, il y a genre 24 PWM.
L'esprit des deux est différent : l'ESP32 est un micro "comme d'hab" c'est-à-dire un immense bordel (pas autant qu'un STM32 mais pas loin du genre t'as une chiée de timers mais ils sont tous avec une interface un peu différente) tandis que le RP2350 est très simple à utiliser, très "poli" et uniforme, t'as 12 timers c'est tous les mêmes, etc.
RP2040 qui est l'ancienne version est aussi une bonne puce mais le RP2350 est mieux et le prix est quasiment le même.
Sinon pour le reste il y a STM32 pour la richesse des périphériques et les ADC, mais plutôt en C++ et il faut faire sa carte.
Pour faire ça point besoin d'un ESP32 et de toute l'infrastructure qui va avec !. . . pour faire clignoter 2 led quand une porte s'ouvre ??
L'électronique c'est comme le violon. Soit on joue juste, soit on joue tzigane . . .
Comme tu as l'air de connaitre : tu peux exploiter les 2 cœurs du CPU en uPython ?
<< In a world without walls and fences, who needs Windows and Gates ? >>
Je ne suis pas sûr. En tout cas, c'est pas la philosophie : si python n'est pas assez rapide, au mieux, en doublant les coeurs tu irais 2x plus vite, alors qu'en remplaçant le bout de python qui pose problème par du C++ tu iras 100x plus vite...
Mais tu n'en auras probablement pas besoin.
En micropython la limitation c'est plus les interruptions qui n'ont pas le droit d'allouer de la mémoire, or le python est un langage dynamique, donc quasiment tout alloue de la mémoire. Donc on ne peut pas faire grand chose en interruption, mais bon, ça suffit. Il y a aussi une latence d'interruption plus importante qu'en C.
Si le but recherché dans l'apprentissage d'un nouveau langage est de se tourner vers quelque chose de "polyvalent" : développer aussi bien pour de l'embarqué que pour des applications PC / client / serveur plus classique, alors pourquoi pas le Python.
Si c'est juste pour faire de l'embarqué (microcontrôleur) alors le C/C++ est un meilleur choix, aussi bien en terme de "puissance" que de polyvalence des cibles possibles. (Le [micro]python est limité à quelque µC qui ont un interpréteur, et ceux pour qui c'est pas natif ça se fait au détriment des performances)
En gros, si c'est pour se retrouver avec les mêmes travers et les mêmes limitation que le picaxe, autant rester sur les picaxe...
A noter aussi, que, sans apprendre un nouveau langage, il existe des compilateurs basic pour certains microcontrôleur (swordfish pour les PIC18 par exemple https://www.sfcompiler.co.uk/swordfish/) c'est passé de mode depuis Arduino et son C/C++ mais c'est toujours dispo, et c'est gratuit.
Tout projet flou conduit à une connerie précise !
Bonjour,
Faut pas le décourager..Si notre ami veut tâter du Python, qu'il le fasse.
Son projet est pour ce que j'en ai compris est de comparer des entrées par groupe de 4. Je ne sais pas si le Python est plus pratique pour le faire.
Qu'il essaie.
MM
Si il y a des erreurs ci dessus, c'est que je n'ai pas eu le temps de les corriger...
D'après le TIOBE, python est le 1er langage de programmation devant C et C++ (même réunis), donc il va naturellement porter uPython pendant longtemps encore.
--> AMA uPython a de l'avenir, surtout avec la puissance des uCPU qui explose.
<< In a world without walls and fences, who needs Windows and Gates ? >>
Le seul intérêt de µpython est la programmation dynamique (pas besoin de recompiler après un µchangement) et un environnement facile à maîtriser par un débutant.
Mais j'en ai vu s'arracher les cheveux sur des bug, selon les versions du logiciel ou du matériel. C'est peut-être passé ?!
L'électronique c'est comme le violon. Soit on joue juste, soit on joue tzigane . . .
C'était ce que l'on disait de Arduino ... et force est de constater qu'il y a un énorme besoin exactement là.
<< In a world without walls and fences, who needs Windows and Gates ? >>
Il y a des bugs, ça s'améliore. C'est toujours mieux que Arduino. Les HAL de quasi tous les fournisseurs de mcu sont buggés aussi lol.
Pour moi les plus gros intérêts sont :
1) Ne pas devoir compiler. J'ai une carte à ESP32, avec un firmware dessus utilisant l'environnement arduino (déjà une erreur lol). Eh ben récemment j'ai voulu changer le code : impossible de le recompiler, en seulement quelques années ils ont changé suffisamment d'API pour que juste recompiler le truc demande un effort de probablement plusieurs jours. Donc, la prochaine fois que je fais du C++ embarqué, il faudra que je garde une VM avec un environnement de dév "gelé" sans aucune mise à jour et donc capable de recompiler le logiciel qui qu'il arrive...
2) Ne pas devoir compiler : on peut envoyer du code sous forme de texte et ça marche, y compris par ethernet ou wifi, ce qui est incroyablement pratique si on veut faire un truc flexible. De même on n'a pas besoin de fichier de config parce qu'une appli python utilise un fichier de config en python. Par exemple dans Tasmota, ils ont fini par mettre un interpréteur de langage de script (Berry) mais c'est merdique comme langage vu qu'il gère pas les coroutines.
Comment on poste l'état d'un capteur sur MQTT avec ?
Est-ce que c'est le besoin?Comment on poste l'état d'un capteur sur MQTT avec ?
Bonjour,
En règle générale, il est judicieux de retenir la démarche inverse, choisir l'outil compatible avec les moyens disponibles.
Faute de quoi, vous allez vers un monde inconnu nécessitant de s'adapter en permanence jusqu'à l'impossibilité.
C'est ce que j'ai fait avant de choisir un type de µP/
La première question à se poser, cerner le besoin en puissance de calcul, l'estimation de la taille des programmes, les ressources internes (E/S, interruptions etc)
Donc, avant de décider, il faut connaitre un peu mieux le projet.
MM
Si il y a des erreurs ci dessus, c'est que je n'ai pas eu le temps de les corriger...
Mon frangin maîtrise assez bien et il m'a confirmé qu'on pouvait exploiter les 2 coeurs ou même choisir de mettre µPython sur un seul coeur, laissant l'autre de libre pour faire autre chose. C'est parfois utile quand dans le soft il y a une partie critique (en C) et une partie plutôt orienté interface homme machine (microPython).
Mon avis perso est que je suis mitigé car même si moi aussi j'ai constaté la souplesse qu'offre le REPL (l'interpréteur) ; tu tapes des instructions et elles s'exécutent en live sans compilation, je trouve que à la fin, microcpython ne rentre souvent plus dans les cases.
Besoin de temps réel => Pas adapté.
Besoin de rapidité => Pas adapté
Besoin de ni l'un, ni l'autre => Adapté mais pour des projets comme "gérer un système de fichier depuis un clé USB ou mini serveur web" qui tendent vachement vers l'informatique.
Néanmoins Python est un langage à connaître ne serait-ce que pour tous les algorithmes et les démonstrateurs, exemple ici https://view.pathsim.org/?model=%2Fe...scillator.json où ils sont en train de refaire un Matlab. Un autre exemple : commander des instruments en SCPI ou LXI, c'est assez simple en Python.
Là où il n'y a pas de solution, il n'y a pas de problème.
Ho put...n de m...e je viens de choper un sacré mal de crâne à tout lire et je ne suis toujours pas fixé je vais prendre le temps de tout décanter
merci pour votre implication
Ceci dit, j'ai vraiment du mal à comprendre pourquoi on coderait à la main de nos jours. C'est pire que de faire de l'assembleur.
Et quand on ne code plus à la main, ces questions de langage deviennent totalement secondaires.
bonsoir
j'ai cru comprendre que Torre 13200 bricole surtout en modélisme ferroviaire.
ses questions concernent principalement de la logique d'états.
avec picaxe ou arduino, les résultats des équations se feront relativement rapidement pour ce genre d'utilisation.
le choix d'un picaxe 40x2 était fonction du nombre d' E/S
un arduino méga 2560 a assez d'E/S pour ce genre de projet.
les 2 ont une programmation assez simple et documentée sur le web.
pourquoi démarrer sur une nouvelle formation python à ce stade ?
pour le plaisir d'y passer des jours d'essais ?
contrôler 24 entrées et décider de l'état de 4 sorties en fonction, ce n'est pas sorcier, et assez rapide, même avec un code peu avancé.
mais ce n'est que mon avis..
pour info, Torre 13200 ce musée est à vendre, le patron ne trouve pas de repreneur...
https://www.youtube.com/watch?v=e4zUOA5WYVg
Pascal
Sur un PC c'est vrai, sur un microcontrôleur ce n'est pas la même histoire.
Le micro tourne lentement, choisir un langage interprété peut même rendre ton projet impossible.
Exemple : tu as un ADC qui échantillonne à fréquence fixe, un DMA se charge de prendre les valeurs lues par l'ADC et les places dans un buffer circulaire. A ce moment précis le temps t'es compté pour faire ton traitement, souvent du filtrage mais pas que ça peut être plus complexe, car si tu n'es pas assez rapide par rapport au buffer circulaire, les infos sont perdues.
Autre exemple : Ton microcontrôleur doit gérer des interruptions, disons qu'il doit gérer différents capteurs de fin de course pour faire simple, si le code est trop lent par sa complexité, le temps qu'il s'exécute l'interruption générée par le capteur suivant peut ne pas être détectée.
En réalité avec les microcontrôleurs c'est souvent le timing le vrai problème, arrêter un moteur suffisamment vite, acquérir un signal suffisamment vite, ...
Là où il n'y a pas de solution, il n'y a pas de problème.
Oui mais ce n'est pas ce que je voulais dire, j'aurais du être plus clair : on fait coder par l'IA et dans ce cas justement, aucun intérêt de passer par Python.
On code directement en C++. Ou si on veut vraiment, on prototype en Python puis on fait convertir en C++ avec tests comparatifs.
On peut même faire du Rust même si c'est plus compliqué.
encore une vidéo pour Torre 13200:
https://www.youtube.com/watch?v=3qoKxH1AxIY
je connais bien cet endroit et je ne m'en lasse pas.
Pascal
