Oui j'utilise ce terme à mauvais escient pour indiquer des personnes très expérimentées sur ce matériel
Après chacun son expérience et ses exigences. Personnellement je peux me tromper, mais vouloir faire de la programmation tout en étant contrarié par la modification d'un fichier JSON, cela ne rend pas simple l'apprentissage.
Ton fils a t-il regardé du coté de scratch ?
je crois aussi que Microchip studio, permet de gérer le framework Arduino.
Concernant le .ino, j'avoue que j'ai un peu de mal à comprendre ce qui te gêne.
Cela permet justement au débutant de ne pas ce prendre la tête avec l'ordre déclaration des fonctions et l'initialisation/déclaration nécessaire au microcontrôleur.
Pour moi ce passer de cette fonctionnalité et ce compliquer la vie, si cela n'est pas nécessaire.
Le .ino masque des choses qui pourtant se font très bien sans. Dés que l'on veut ajouter des fichiers (des .cpp et .h) alors il y a une notion de plus à expliquer, celle du ino n'ayant pas de raison d'être devient dés cet instant une gène.
Là où je vois le soucis c'est que quelqu'un qui connait rien à Arduino mais qui fait du C/C++ depuis des années (moi), doit réapprendre des trucs pour se faire à ce ino. Ça signifie que celui qui se apprendrait avec le ino aura à faire le désapprentissage plus tard pour se mettre à de la programmation plus normale, c'est du gâchis.
Pas de problème tant que le gamin n'a pas besoin de comprendre comment le ino fonctionne mais je ne le laisserai pas se déformer à comprendre le ino, trop spécifique.
De la même manière j'ai essayé de faire du multi-fichier dans ArduinoIDE mais outre que ce n'est pas pratique et effectivement "fait pour ceux qui ont du temps à perdre", on a alors besoin de comprendre ce que fait le ino, j'ai donc laissé tomber ; Il fera du multi-fichier plus tard avec un outil qui va bien, sans ino, sans s'adapter à une logique spécifique qui n'a pas lieu d'être.
Alors oui pour le grand grand débutant le .ino est très bien mais quand je vois à la vitesse où un enfant de 12 ans progresse et quand je vois l'immensité de ses envies/projets il faut vite prévoir la suite.
Mon fils à fait du scratch mais je crois que le code, le "je parle à la machine en écrivant des trucs trop cool" est tout aussi important que l’algorithmie or scratch ne propose que l'algo, il n'a pas accroché.
Je vais creuser vsc pour être plus à l'aise quand il voudra s'y mettre, il se mettra aux json encore plus tard quand il aura assez d'aisance pour avoir envie de bidouiller l'outil ; il m'a dit ne pas avoir envie de gratter/bidouiller encore, il s'éclate à apprendre le hardware et le code.
Comme je l'ai dit chacun son expérience et ses exigences, je pense un peu comprendre les tiennes, bien que étant dans le même cas que toi pour le C/C++, je ne partage pas du tout ton avis/ressentis.
Pour moi le ino, me simplifie la vie et n'est en aucun cas une gêne pour faire du multifichier.
Ne devant pas former d'enfant de 12 ans, je peux par contre avoir du mal à appréhender les problématiques avec le .ino. @pandaroux007 ayant cet âge je crois, ne semble pas avoir de problème particulier avec ce point là?
Oui le scratch était bien dans l'optique d'apprendre l'algorithmique.
Après il y a plein d'autre langage que le C/C++ de disponible sur les microcontrôleur, comme le Python ou le Lua(j'utilise avec les ESP8266), peut être cela serait-il une alternative à tes soucis.
Mais il n'y a pas de soucis avec le .ino tant qu'on a pas à le désapprendre pour programmer normalement, normal et tant mieux que ça ne pose pas de soucis aux pandas, lapins et autres jeunes apprentis.
C/C++ ne pose pas plus de soucis. Faire du Python sur microcontrôleur m'en poserait beaucoup plus vu que ce n'est pas adapté.
Peut être que mon soucis alors que je ne vois pas ce qu'il y a à désapprendre, le ino fait des choses en plus, une fois dit, que veut tu désapprendre?
Alors bien que je pense que c'est Python qui n'est pas adapté à la programmation, mais à pars de la provocation gratuite envers les adaptes de ce langage, franchement, je ne le trouve pas forcément inadapté, le Lua l'est du coup tout au temps, et effectivement bien que cela amène certaine limitation mémoire plus rapidement que le C, l'interpréteur est diablement efficace.
Donc je suppose que celui du Python l'ai encore plus.
Non ce n'est pas de la provocation.
Python, langage interprété, n'est pas fait pour de l'embarqué sur un petit machin 8bit qui a vocation à ne pas consommer. D'ailleurs sur une si petite machine Python ne peut être que l'ombre de lui même, en supposant qu'un interpréteur soit envisageable.
Je parlais de ma phrase indiquant que le Python n'est pas adapté à la programmation
Encore une fois, je ne pourrais pas parlé de Python que je n'ai pas testé, mais qui est "speudo" interprété. Mais pour ce qui est du Lua, sur des ESP8266, donc 32bits, c'est plus que envisageable et fait parfaitement tourner une station météo avec envoi en MQTT et un serveur WEB pour la configuration du WIFI.
Après ce n'est que mon expérience, je peux me tromper.
