Forum-passionnement

Cela m'étonnerais que j'ai des choses a t'apprendre sur la programmation Arduino.

Si si !
Parce que tu utilise des trucs que je n'avais jamais utilisé et réciproquement .
C'est tout l’intérêt des échanges . On progresse !

Par exemple ?

De ton coté, j'ai appris qu'il y avais la possibilité d'utiliser des onglets (ce que je ferais dans mon prochain projet ou voir même celui-la quand il sera terminé).

J'ignorais que les pins analogiques (A4 et A5 dans ton programme) pouvaient être utilisées en sortie .

Et je vais me pencher (sans tomber ) sur la lecture-écriture des SDcard .

De mémoire, toutes les bornes de l'Arduino sont utilisable en ENTRE ou en SORTIE a l'exception de 4 ou 5 réservé au communications serial (0 et 1) ou i2C (A4 et A5).

Certaines autre sont en pwm dans les deux sens.

Sur l'UNO, la 10 est pour la carte SD par exemple.

oui, d'ailleurs, il y a un truc que je ne pige pas .
Puisque tu utilise A4 et A5 en sortie, où branches-tu ton écran I2C . En plus, tu n'utilises pas la librairie Wire.h pour communiquer en I2C avec ton écran . . . pige pas . . .

Pour l'écran i2C, j'utilise la bibliothèque. " <LiquidCrystal_I2C.h> "

Et (pour le programme mis plus haut) l'écran est branché sur les bornes réservées a l'i2C de la carte MEGA qui ne sont pas les même que sur la carte UNO.

Quand je basculerais le programme pour une UNO, il me faudra redistribuer les bornes et adapter le programme en conséquence.

Car sur la UNO, les borne i2C et les bornes pour la carte SD ne sont pas les mêmes (A4 & A5 pour i2c et la borne 10 pour la SD).

Il y a des tableaux de correspondance que je vais faire et poster car il est vrais que l'on s'y perd facilement.

Ok, pigé ! ! !
Je pensais que tu utilisais déjà l'UNO .
Par contre, je pensais qu'avec la bibliothèque. " <LiquidCrystal_I2C.h> " il fallait aussi utiliser <wire.h> . . . . Apparemment pas . . . .

Et bien non, cela fonctionne très bien sans.

Une ligne de moins à taper !

Deux tableaux très pratique.

. .


.
Pour ne pas se perdre.

Bonne idée .

Tu pourrais peut-être faire aussi le tableau pour l'I2C, mais . . . ce serait peut-être abuser . . . bon,

Ce n'est pas abusé, et op ....

J'ai regroupé les tableaux ici ==> page des tableaux.

Ce sera plus facile pour s'y référer plus tard.

Petit point.

J'ai "arranger" le programme pour qu'il s'intègre a une carte UNO.

Ça passe et je dirais que cela fonctionne, a un point prêt, la mémoire restant étant insuffisante, le programme tourne, mais ne peut pas faire tourner le moteur n'ayant pas assez de place pour travailler sur les variables.

Et comme je n'ai pas l'intention de me prendre la tête a optimiser a 2000% ce programme, je resterais donc sur une carte MEGA (j'en ai 2 en stock et une est déjà montée en volant sur l'ascenseur), donc je vais pouvoir continuer et y ajouter un fin de course de contrôle sur le servo taquet.

Après ce sera mise en place et essais en live.

Le seul doute qui subsiste est la puissance du moteur. Il se pourrait que je soit obligé d'en mettre deux en parallèle. Comme j'en ai en stock, cela ne me posera pas de soucis.

Voici le prototype de mise au point ....
.

. .

Le principe de fonctionnement est simple.

Avec le bouton rotatif on choisi le niveau où ont souhaite aller, on clic dessus, le taquet s'ouvre, le moteur tourne ... s'arrête, le taquet se referme.
.

. .

Il y a en tout :

- le niveau réseau tout en haut. Niveau équipé d'un fin de course initialisant le point d'altitude "0",
- 5 niveaux en sous sol,
- Un taquet de verrouillage qui bloquera le plateau pour en éviter toute dérive et équipé d'un fin de course vérifiant la bonne levé du taquet,
- Un relai donnant ou coupant l'alimentation moteur pour éviter toute surchauffe et destruction de la carte moteur,
- Une LED rouge et une LED verte pour indiquer l'autorisation ou non de bouger les trains se trouvant sur le plateau,
- Une carte micro SD sur laquelle se trouve un fichier de sauvegarde des altitudes de chaque niveau et accessoirement une sauvegarde du programme au cas où.

Vidéo a suivre.

Alors Christian on ne doit pas avoir la même définition du mot simple.
J'avoue être totalement inculte en matière d'automatisme, programmation etc.
J'avais lu il y a environ 2 ans des articles qui présentaient l'Arduino comme quelque chose d'assez simple. Mais vu tout ce que j'ai lu dans ton post je reste dubitatif.
En tout cas bravo à vous tous les amis qui maitrisez ces différentes techniques.

En fait Alain, c'est très simple.

Pour tout projet, tu expose le principe de fonctionnement sur une feuille de papier.

Ensuite tu détaille chaque action.

Par exemple :

1) j'appuie sur le bouton x,
2) j'éteins la LED verte et allume la rouge,
3) je ferme la porte,
4) j'ouvre le robinet,
5) je cherche le bouchon
6) j'inonde la maison
7) j'appel les pompiers
8) ce soir je couche a l'hôtel
9) je retourne au point n°1


Pour chacun de ces points (de 1 a 9) correspond a un bout de programme qui, mis bout à bout, donne un grand programme.

Tu vois, c'est la simplicité même.

Avec toutes ces précisions notre ami Alain va pouvoir se lancer...

La petite vidéo qui vas bien avec.
.


.

Le pcb où se trouve la carte nano, avec tous les dominos verts autour, c'est du spécifique ou tu l'as fait toi-même?

C'est du spécifique pour la carte MEGA. Il existe la même chose pour la carte UNO et pour la NANO.

Pour la mise au point c'est l'idéal.

Ensuite tu peut prévoir ton propre shields.

A la limite c'est mieux que les: breadboard

Parfois sur ces derniers les connexions sont aléatoires...

D'où mon choix de travailler là dessus.

Il n'y a rien de plus énervant que d'avoir des fils qui se barre de la breadbord.

Là, ça tient. La breadboard me sert essentiellement pour l'alimentation des éléments.

Et je pense que je vais me faire une barrette pour cela.

C'est bon à savoir, lorsque je me remettrai à l'arduino....