Reprise du message précédent :

Oui, Transceiver=Transmitter+Receiver.

Je n'ai fait que survoler la doc pour l'instant, mais il me semble que c'est du half-duplex, donc pas de RX et TX en même temps. Mais si les quantités de données sont faibles on peut toujours alterner entre les deux, ça revient presque à la même chose.
 

Les commentaires n'ont aucune influence sur la taille du code compilé.

d'accord merci

La mémoire programme tu t'en fout.
La mémoire vive par contre en gros le compilateur ne peut pas prédire exactement quelle quantité sera utilisée.
 
Exemple à la con, si tu fait la fonction récursive suivante:

 
A l’exécution ça reviens à minima à allouer sur la pile la taille d'un int à chaque appel de recursive(), or vu que c'est récursif si ton count est grand tu risque de dépasser la taille maximale autorisée pour la pile donc de planter ton micro.
 
Et bien sur ici vu que count viens d'une valeur extérieure, le compilateur à beau détecter la récursion et le risque de dépassement de pile, vu qu'il ne sait pas quelle sera la valeur maximale que l'utilisateur attends il ne pourra pas dire grand chose.

Merci, j'en ai commandé 5 pour tester.

Je pense que je vais t'emboîter le pas, ça m'a l'air pas mal du tout pour mon besoin

Par contre, j'ai pris la version normale. J'ai pas compris la différence avec la version "SMD".

Tout le monde devrait avoir des kilos de NRf24L dans ses tiroirs...

T'as opté pour quelle solution ?  
Je suis tombé sur le module VL53L0X si jamais ça peut t'aider.

C'est juste le branchement, sur la version normale tu as un connecteur, la version SMD se soude directement sur un PCB.

 
merci de l'explication
 
Dans mon code j'ai pas de fonctions comme ca, je fais joujou avec du gps + j'écris sur une carte sd + affichage sur écran lcd i2c 20x4 (sera très surement remplacé par un 3.2" en uart, à voir comment je fais fonctionner ce truc)

Il y a un post qui recense les réalisations perso des participants du topic ou un tag quelconque ?
ça m'interesse de voir ce que chacun a pu réaliser.

Y a pas mais c'est vrai que ca serait bien.

Pensez-y pour le futur, comme sur le topic des maker, un tag et un CR. ça peut etre très sympa à parcourir ensuite.

Je suis en train d'interfacer un minitel, et j'utilise la lib suivante : https://github.com/Lefinnois/Minitel
 
Ça fonctionne très bien avec une UNO, mais je voulais essayer d'utiliser un ESP8266 et là d'un coup c'est moins bien… Je vois quand même ce que je suis censé voir dans le programme d'exemple, mais il y a des décalages dans les lignes/position du curseur, et certains caractères ne sont pas corrects (carré blanc à la place d'une lettre par exemple).
 
Au début j'ai cru que ça venait du fait que l'ESP est en 3,3V, mais j'ai à peu près le même résultat en passant par un level shifter (sachant que je repompe le 5V depuis la sortie VUSB de l'ESP).
 
De quoi d'autre ça pourrait venir ? De la vitesse de la liaison série ?

Salut,

J'ai un petit soucis avec un datalogger sur arduino.
J'ai un datalogger tout ce qu'il y a de plus commun, avec une fonction RTC, mais c'est pas le sujet a priori.

Initialement, tout se passer bien. Mais problème : si j'arrache la carte, le programme ne semble se rendre compte de rien avec le programme par défaut. Il continue de boucler comme si de rien n'était. Il semblerait que la fonction SD.open("file.txt" ) ne vérifie pas si la carte est bien connectée après un SD.begin(pinNumber) ok.

Des idées ?
Il n'y a pas moyen de pallier à une carte arrachée (au moins détecter qu'elle l'est ?)

Modifier la bibliothèque ? Genre si y'a bien une fonction au tout début qui vérifie la présence d'une carte, la rappeler de temps en temps quand il y a écriture ?

SD.open retourne un booléen qui vaut faux si le fichier ne peut pas être ouvert.
 
Tu rajoute un test comme ici : https://www.arduino.cc/en/Tutorial/ReadWrite

sauf que SD.open bouge pas quand la carte est arrachée... me demande pas pourquoi, ça me semble illogique aussi (j'ai vérifié avec différent temps de délai, histoire que ça ne soit pas un problème de temps de réaction)

J'ai toutefois trouvé une possible solution ici : https://forum.arduino.cc/index.php?topic=566739.0
Il est indiqué qu'une sortie CD sur le shield doit indiquer la présence de la carte dans le lecteur, j'ai vérifié, ça fonctionne bien. ça m'oblige à tirer un fil de plus, mais ça peut être une possible solution.

Et en testant SD.exists(filename) ça te fait la même chose ?

ah, j'ai pas essayé exists, bonne idée, je check immédiatement.

edit : pas mieux pour SD.exists, il retourne 1 sur la carte est branchée au démarrage, 0 si la carte n'est pas branchée, mais rien ne change si arrachage de la carte.

En environnement Arduino par défaut t'as pas de préemption donc c'est possible qu'il reste à attendre en boucle infinie qu'une donnée vienne de la carte ou autre sans possibilité de timeout.
 
Si l'objectif est que ça reboote tout seul dans ce genre de situation il doit peut être avoir moyen d'activer le watchdog timer : https://tushev.org/articles/arduino [...] hdog-timer

En fait, j'ai pas vraiment de hang-out. ça continue de tourner comme si de rien n'était alors que de toute évidence, ça ne peut plus fonctionner.
 
Je vais essayer avec de fonctionner avec le retour "CD" qui m'indique si effectivement une carte est insérée dans le lecteur du shield.

Bon, je confirme, problème résolu via l'utilisation d'une sortie "CD".  
Soit disant HIGH quand la carte est absente... en l'occurrence, sur ma bouse chinoise, à l'air libre, mais heureusement effectivement à la masse quand la carte est insérée.

T'as qu'à activer le pullup intégré pour cette entrée.

Je veux bien, comment on fait ?

En language Arduino je sais pas, demande au moteur de recherche.

Tu configures ton entrée en mode INPUT_PULLUP.

J'ai compris !

je savais pas que c'était possible

Bonjour topic

avant de me lancer dans le projet à l'arrache, je voulais voir un peu si c'était faisable ou bien trop galère.

En gros, je veux fabriquer une petite serre qui me permettra de faire démarrer/pousser mes différentes graines (Piments, herbes, etc...)
Je voudrais controler l'hygrométrie du semis en actionnant une petite pompe à eau ainsi que "l'ensoleillement" par un ruban à LED (rouge/bleu). Une sonde de température ambiante viendrait compléter le tout.

L'idée que j'ai actuellement serait de piloter tout ça (actionnement de la pompe en fonction de la sonde d'hygrométrie; ON/OFF des LED, relevé de température ambiante) par un arduino puis d'envoyer le tout sur mon serveur Domoticz qui tourne sur Raspberry. Pour le lulz, j'aimerai ajouter un  écran LCD avec touche pour actionner la pompe.

Est-ce que l'arduino est tout much dans l'affaire et alors je fais tout sur le RPi ou bien c'est tout à fait faisable de tout piloter par l'arduino (que j'ai déjà mais qui est toujours dans sa boite) et d'envoyer les infos sur le RPi ?

(edit : et je tiens au RPi car j'ai déjà la température de ma cave à vin qui remonte sur Domoticz et j'aimerai installer une webcam en plss ur ce serveur )

Très bonne idée de dédier un Arduino à la serre puis de remonter les infos vers le serveur de domotique.
Tout est réalisable sans soucis avec l'Arduino, tu peux facilement rajouter un LCD et des boutons.

Il est top ce petit projet.
 
Ça suffit les LED bleu/rouge pour les plantes ?

Il faut juste que je trouve la rampe LED (ou ruban) avec les LEDs qui émettent à la bonne longueur d'onde : 630 nm/470 nm et que je trouve le bon ratio entre les 2.
Je continue ma recherche d'info mais je pense que je reviendrais d'ici peu ici car j'ai encore jamais touché à l'Arduino

Les rubans led spécial plantes ça se trouve à la pelle  

Je m'étais lancé dans un projet comme ça il y a quelques temps et pour la couleur des leds j'étais partit sur du blanc car visuellement ça rend mieux que le rouge recommandé pour la croissance des végétaux.

 
 
Pardon, je sors.  
 
Sérieusement, un petit Arduino dédié c'est bien et tout à fait faisable.

De mon côté, j'suis bloqué par la mémoire de l'arduino uno... En gros, j'avais des erreur à la sauvegarde sur ma carte SD.  
 
J'ai passé une journée sur les interruptions, pour comprendre que finalement, c'est un problème mémoire lié à l'utilisation d'une librairie graphique pour afficher sur un LCD ce que je mesure.
 
Le pire, c'est que ça passe pas à quelques dizaines d'octets prêt à priori
 
j'étais prévenu pourtant :
 

 
Même pas Je suis pas fan
Si j'y arrive, je ferais un post avec photo du bouzin

Tu n'as plus qu'à passer au 2560 qui a 8k de ram.

 
Ca m'est déjà arrivé et généralement on y arrive en reprenant calmement son code.
La première source d'optimisation pour moi ce sont les variables, c'est peut etre différent pour toi. Mais par exemple l'habitude de coder les variables avec un simple int (par défaut sans autre information il prend 2 octets) alors que la variable ne sert qu'à faire du oui ou du non, ou alors qu'elle ne peut prendre qu'un petit nombre d'état. Dans ce cas utiliser plutot u_int8 pour les déclaration ou du booléen.
Regarder s'il n'est pas possible de passer des variables type déclaration de pin en Define pour éviter de prendre de la place en mémoire pour rien, elles ne sont remplacés à la compilation directement.
 
Ensuite la deuxième optimisation c'est le code lui même, notamment la déclaration des boucles qui est gourmand en mémoire dynamique. Mais c'est plus chiant à optimiser.

C'est pas possible de souder une barrette de 16 Go de RAM sur un Arduino ?