Hardware #83
Hardware #83
Conversation
There was a problem hiding this comment.
Pour les fichiers qui se situent dans jardiniot-emb, il ne vaut mieux pas créer un fichier rev1 et rev2. Cela va empêcher qu'on puisse differ facilement les vieilles versions du code avec les nouvelles versions. Habituellement, on créer des fichiers de revision quand la technologie/implémentation change complètement, donc lorsqu'il y a rien de pertinent à differ (ce que tu as fait dans hardware est bien par exemple).
Si on réimplémenterait le système en Rust par exemple, là on créerait un fichier rev2-rust par exemple, mais on ne bougerait pas l'ancien code. Quand cette nouvelle version serait aussi mature que l'ancienne implémentation, on effacerait l'ancienne. Je suggère qu'à la place, tu crées un répertoire nommé jardiniot-emb-v2 à la base du repo. Le code pour la nouvelle implémentation irait là-dedans.
|
Présentement, vous avez du code résident dans un Arduino UNO programmé en C/C++ avec le framework Arduino et un esp8266 programmé en C/C++ avec platformIO. L'adoption du contrôleur ESP32 est plus qu'un changement dans le hardware. C'est un changement qui nécessitera de porter le code existant dans 2 plateformes hétérogènes en une seule... Le nouveau contrôleur est un ESP32 programmé en C/C++ avec le framework ESP-IDF créé par le manufacturier de la board. L’ESP32 prend en charge le rôle des deux plaquettes de l'itération précédente. De plus, le framework ESP-IDF upload une version condensée de FreeRTOS dans le contrôleur : ce qui nous permet de le programmer en C/C++ en utilisant les librairies POSIX tel que :
Ces librairies ne pouvaient pas être utilisés avec le matériel des itérations précédentes ainsi que leurs frameworks respectifs. Je comprends qu'il faut construire sur ce qui est déjà fait, mais, il est impossible de garder le même code base, dans son entièreté, pour la prochaine itération en utilisant l’ESP32. Les changements n'impactent pas seulement le hardware. Ce sont des changements majeurs dans la technologie utilisée dans la partie embarqué qui affecte les outils logiciels à notre disposition. L'architecture logicielle restera la même car elle était bien faite au nouveau de l'organisation des données. Mais, l'implémentation changera assez pour, selon moi, justifier créer un nouveau répertoire pour la révision P.S.: Il y a des projets pour arranger ce problème mais ils sont loin d'être stable et prêts à une utilisation sérieuse. -V |
|
Apparently it's possible Build Rust environment for ESP32 -
http://quickhack.net/nom/blog/2019-05-14-build-rust-environment-for-esp32.html
Le sam. 21 mars 2020 17:02, Alexandre-Xavier Labonté-Lamoureux <
notifications@github.com> a écrit :
… Merged #83 <#83> into
hardware.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#83 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHO2FHF6ADXSOO2ZQX7BQLRIUTPZANCNFSM4LQW6KNA>
.
|
|
It's an official project to port llvm to xtensa (the architecture for esp32)
Le sam. 21 mars 2020 23:45, Michael Faille <michael.faille@gmail.com> a
écrit :
… Apparently it's possible Build Rust environment for ESP32 -
http://quickhack.net/nom/blog/2019-05-14-build-rust-environment-for-esp32.html
Le sam. 21 mars 2020 17:02, Alexandre-Xavier Labonté-Lamoureux <
***@***.***> a écrit :
> Merged #83 <#83> into
> hardware.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#83 (comment)>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAHO2FHF6ADXSOO2ZQX7BQLRIUTPZANCNFSM4LQW6KNA>
> .
>
|
|
La lib std rust n'est pas encore implémenté de manière stable pour esp32. Ce qui nullify tous les avantages d'utiliser un esp32 en premier lieu. C'est définitivement possible... mais je ne veux pas risquer de brick une board avec un compilateur experimental. |
|
Je vais quand même suivre le progrès de ces projets, j'aimerais voir le langage Rust briller dans le domaine des systèmes embarqués. |
|
Je conseille donc d'utiliser une chip dont le framework supporté en première classe c'est freertos. Alors que la ESP supporte plutôt un firmware propriétaire par defaut, le framework de Arduino ou Freertos ne sont pas supporté commercialement. Par example, RTL8710 est un option. Le CPU est supporté par rust depuis un bout par sa popularité (ARM Cortex M3). Alors, même pour le code en C, tu auras non seulement un meilleur support commercial pour la std mais aussi un meilleur de la communauté. Pour les syscall comme ceux de réseau, FreeRTOS est supporté en première classe par Realtek et son développement est ouvert contrairement au firmware réseau de la ESP. |
|
La différence de prix c'est : |
Par défaut, la toolchain du ESP32 ESP-IDF utilise FreeRTOS pour faire rouler des programmes sur l'ESP32. Attention, l’ESP32 n'est pas la même chose qu'un ESP8266. Dans un projet comme jardinIOT ou l'on désire donner la possibilité d'adapter ses propres capteurs aux clients, le RTL8710 limiterait les améliorations futures. Après une comparaison entre l'ESP32 et le RTL8710 : De base, L'ESP32 possède un clock de 160MHz alors que le RTL8710 (sans modification) roule à 83MHz. Après modification, le clock du RTL8710 peut se rendre près du clock speed du ESP32. Par contre, une fois modififé, le clock speed du ESP32 peut doubler ce chiffre et laisser le RTL8710 dans l'ombre. De plus, l'ESP32 possède 2 coeurs. Le RTL8710 a été produit pour compétitionner avec l’ESP8266, et non pas l’ESP32. Donc, il est simplement single core, tout comme son compétiteur l'ESP8266. L’ESP32 possède 2 DAC, ce qui est crucial pour un projet d'embarqué qui vise à augmenter son support pour différents capteurs. En choisissant le RLT8710, on se limiterait à des capteurs digitaux. L'ESP32 supporte le Bluetooth, une fonctionnalité qui manque sur le RTL8710. Le RTL8710 manque de GPIO dédiés. Cela rend inutilisable les broches dédiée pour SPI, I2C ... même si on ne les utilise pas. L'ESP32 permet de réassigner les broches utilisées par les bus comme GPIO si les bus ne sont pas utilisés. La décision d'utiliser un ESP32 est une de fonctionnalité et non pas de budget. C'est aussi une décision de professionnaliser, rétrécir le matériel et de produire des PCB produits professionnellement. Finalement, dans la proposition pour une nouvelle itération, il n'était jamais question de réimplémenter quoique ce soit en Rust. Si c'était le cas, j'aurais opté pour l'adoption d'un Raspberry pi car c'est une plateforme officiellement supportée qui ne requiert pas de build une version expérimentale de llvm et de rustc. Le raspberrry pi possède autant de bus et de GPIO que le RTL8710 et du ESP32, possède une mémoire vive qui n'est même pas comparables à ces deux modules ainsi qu'un meilleur processeur un clock speed un ordre de grandeur plus grand. Je n'ai pas choisi le Raspberry pi parce que c'est un contrôleur overkill. Son utlilisation est en conflit avec l'objectif de tout avoir sur le même PCB et augmente la complexité du projet. |
|
Intéressant ! D'abord merci pour ta réponse détaillé et bien expliqué ! Je comprend mieux ton raisonnement et en plus j'ai appris ! Après avoir fait une recherche sur les produit de Realtek et même les plus récents, je vois bien qu'ils n'ont pas de DAC mais à la limite un PWM ce qui ne donnerait pas d'aussi bon résultat qu'un traitement hardware pour du numérique à l'analogique. Aussi, j'aurais bien apprécié voir un cpu Risc-5 dans le projet de JardinIOT mais je n'en ai pas trouvé d'intéresant. Ça l'aurait été intéressant d'encourrager cette architecture. À la limite, il y aurait https://www.sifive.com/boards/hifive1-rev-b ça revient cher alors que j'avoue avoir apprécié le coût du ESP32. Finalement, le ESP32 semble tout indiqué en effet pour remplacer le esp8266 surtout que FreeRTOS sera beaucoup mieux supporté ! Par contre, pourquoi ne pas mettre le serveur web ET le le support des sensors sur une seule pièce de hardware (le RPI) ? |
Pour la nouvelle itération, mon objectif est de modifier le matériel avant tout. Les changements au niveau logiciel (embarqué) n'en sont qu'une conséquence. Je parle donc d'un point de vue matériel. Le contrôleur (hub pour les sensors) sera potentiellement exposé à des environnements humide et peu propice à du matériel informatique. Garder le serveur web hébergé ailleurs assure qu'un utilisateur ne sera pas laissé dans le noir dans le cas d'une panne matérielle.
C'est bien vrai, un PWM en sortie effectuerait la même chose qu'un DAC. Mais, les PWM ne fonctionnent seulement que comme output. Un PWM est très utile pour, par exemple, contrôler l'intensité des lumières ou même donner des instructions à certains types de servo moteurs. Pour obtenir des inputs analogique, il est essentiel d'avoir des ADC (que le RTL8710 manque et l’ESP32 possède). Un ADC est l'inverse d'un DAC dans le sens qu'il convertit une tension analogique en information que le contrôleur (souvent numérique) peut utiliser. C'est pour cela que les broches de lecture analogique sont identifiés différemment sur (par exemple) l'Arduino. Un GPIO normal est incapable de lire une tension analogique (valeur entre 1 et 0). Donc, un simple capteur de température comme un TMP36 qui fait varier sa tension de sortie selon la température ne pourrait pas être branché sur un projet utilisant un contrôleur manquant des ADC (RTL8710). Je tiens à retirer mon commentaire sur l'impossibilité d'utiliser Rust dans le futur. Cet après midi, après quelques heures de configuration et de build d'LLVM, j'ai réussi à installer une version de la toolchain capable de compiler pour les ESP32. J'ai suivi le guide posté plus haut ainsi que plusieurs autres. |
|
Est-ce qu'on peut faire rouler des programmes sur le ESP32 sans FreeRTOS comme on le fait présentement pour le Arduino et le ESP8266? Si c'est possible de faire rouler des programmes sans FreeRTOS sur le ESP32, c'est quoi les pours et les contres d'utiliser FreeRTOS ou pas? |
|
Freertos c'est bon surtout pour la gestion des thread, la gestion de TCP IP
et eu réseau en général. Ya ces features la qui me viennent en tête mais
yen a d'autres. Ça permet entre autre de standardiser l'exploitation du
matériel et d'apporter des couches plus haut niveau tel que la gestion des
connexions réseaux.
Le dim. 22 mars 2020 17:03, Alexandre-Xavier Labonté-Lamoureux <
notifications@github.com> a écrit :
… Est-ce qu'on peut faire rouler des programmes sur le ESP32 sans FreeRTOS
comme on le fait présentement pour le Arduino et le ESP8266?
Si c'est possible de faire rouler des programmes sans FreeRTOS sur le
ESP32, c'est quoi les pours et les contres d'utiliser FreeRTOS ou pas?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHO2FFMMFRIPPPZT4UIBPLRIZ4IVANCNFSM4LQW6KNA>
.
|
|
Les alternatives sont le framework de Arduino (ce qui a été utilisé dans la
v1 de jardin iot et ça l'est encore je crois) ou le framework propriétaire
de Espressif.
Le dim. 22 mars 2020 17:12, Michael Faille <michael.faille@gmail.com> a
écrit :
… Freeeros c'est bon surtout pour la gestion des thread, la gestion de TCP
IP et eu réseau en général. Ya ces features la qui me viennent en tête mais
yen a d'autres. Ça permet entre autre de standardiser l'exploitation du
matériel et d'apporter des couches plus haut niveau tel que la gestion des
connexions réseaux.
Le dim. 22 mars 2020 17:03, Alexandre-Xavier Labonté-Lamoureux <
***@***.***> a écrit :
> Est-ce qu'on peut faire rouler des programmes sur le ESP32 sans FreeRTOS
> comme on le fait présentement pour le Arduino et le ESP8266?
>
> Si c'est possible de faire rouler des programmes sans FreeRTOS sur le
> ESP32, c'est quoi les pours et les contres d'utiliser FreeRTOS ou pas?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#83 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAHO2FFMMFRIPPPZT4UIBPLRIZ4IVANCNFSM4LQW6KNA>
> .
>
|
|
Leur framework ainsi que son code source est disponible ici btw: https://github.com/espressif/esp-idf |
|
Concernant le framework propriétaire, je faisais référence à l'ancienne
génération du ESP
Le dim. 22 mars 2020 17:16, Vincent Perrier <notifications@github.com> a
écrit :
… Leur framework ainsi que son code source est disponible ici btw:
https://github.com/espressif/esp-idf
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHO2FFWH2O5I7S7XMB7DADRIZ54JANCNFSM4LQW6KNA>
.
|
|
Ce framework compile pour ESP8266 aussi. |
|
Bonne nouvelle ! |
|
C'est une question piège @AXDOOMER L'environnement Arduino est fait pour des débutants qui ont peur du terminal et du C. Les librairies ne sont pas standards et loin d'être POSIX. Même si on dirait qu'on n’utilise pas FreeRTOS avec le framework Arduino c'est le cas. L'exception est les plateformes AVR (les controleurs ATML e.g Arduino UNO), le framework Arduino compile en code assembleur AVR, puis upload le programme sur les plaquettes. Les plaquettes AVR n'utilises pas FreeRTOS. Si on décidait d'utiliser l'environnement Arduino pour programmer les ESP32, on utiliserait quand même FreeRTOS mais avec un niveau d'abstraction fait pour accomoder les débutants et cacher le fait que l'on utilise FreeRTOS. Nous serions alors barrés l'accès à des fonctionnalités POSIX intéressantes ainsi que la STL C++. |
|
Cette tricherie est dû au board manager de l'IDE Arduino qui s'occupe de gérer les toolchains à la place du programmeur. C'est comme cela qu'ils gardent l'illusion. |
|
Intéressant mec. Tu t'y connais !
Le dim. 22 mars 2020 17:25, Vincent Perrier <notifications@github.com> a
écrit :
… C'est une question piège @AXDOOMER <https://github.com/AXDOOMER>
Même lorsqu'on utilisait l'environnement Arduino pour l’ESP8266, on
utilisait FreeRTOS.
L'environnement Arduino est fait pour des débutants qui ont peur du
terminal et du C. Les librairies ne sont pas standards et loin d'être
POSIX. Même si on dirait qu'on n’utilise pas FreeRTOS avec le framework
Arduino c'est le cas.
L'exception est les plateformes AVR (les controleurs ATML e.g Arduino
UNO), le framework Arduino compile en code assembleur AVR, puis upload le
programme sur les plaquettes. Les plaquettes AVR n'utilises pas FreeRTOS.
Si on décidait d'utiliser l'environnement Arduino pour programmer les
ESP32, on utiliserait quand même FreeRTOS mais avec un niveau d'abstraction
fait pour accomoder les débutants et cacher le fait que l'on utilise
FreeRTOS. Nous serions alors barrés l'accès à des fonctionnalités POSIX
intéressantes ainsi que la STL C++.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHO2FAWJJSN5X5PLWKTWH3RIZ65VANCNFSM4LQW6KNA>
.
|
|
@Perceval62 Merci de l'explication. J'ai jamais vu aucune référence à FreeRTOS dans les libs. |
|
@mikefaille merci ;) |
|
D'ailleurs si on utilisait le framework Arduino, il faudrait installer le support pour l’ESP32 dans l'IDE. Cela s'installe à partir de ce repo officiel d'espressif. tools/sdk/include contient plein de références à FreeRTOS. Ce qui confirme que l'IDE Arduino ne fait qu'offrir un API boiled down et utiliser la toolchain "ESP-IDF" en arrière-plan |
|
@AXDOOMER Mon point reste car c'est le cas pour l'ESP32. Son SDK Arduino fait référence à FreeRTOS. |
|
Ma confusion venait du fait que le manufacturier Espressif a fait une toolchain permettant d'utiliser FreeRTOS sur ESP8266 même si ce n'est qu'un contrôleur single-core. J'ai assumer que le SDK pour Arduino l'utilisait. |
Travail de recherche de base.
Nous procédons avec un ESP32, j'ai commencé à travailler sur les fichiers CAD du PCB.
J'encourage les intéressés à lire le README.md dans le fichier jardiniot-emb/rev2 pour les informations sur l'installation de la suite de développement pour l'appareil.