seek ( 0 ) puis print : la donnée s'écrit quand même à la fin du fichier

Bonjour,

Les questions les plus simples peuvent parfois ne pas être faciles à résoudre pour un débutant. Alors je me permets de vous demander un peu d’aide :

  1. dans les exemples que j’ai visualisés, on indique au départ les bibliothèques utilisées entre < > et parfois entre " ". Quelle est la différence ? ( exemple #include <SPI.h> #include <SD.h> #include “DHT.h” )

  2. Quelle est la différence entre Serial.println(“bonjour”); et Serial.println(F(“bonjour”)); car à l’exécution, je ne vois aucune différence : quel est le sens du F( ) ?

  3. Et après cet échauffement, un peu plus compliqué : je découvre l’écriture dans un fichier de carte SD. Je fais des appels successifs à un fichier et je voudrais à chaque appel aller écrire au début du fichier ( en effaçant progressivement les données écrites auparavant lors des appels précédents ). Pour cela, j’ai utilisé la fonction fichier.seek(0) en pensant qu’elle me repositionnait au début du fichier. Quand je vérifie par fichier.position(), il m’indique bien que je suis bien remonté au début du fichier. Néanmoins, quand je demande à écrire, il ne m’écrit pas ma donnée en début de fichier mais à la fin après les données déjà écrites.
    J’ai même trouvé sur le net un exemple qui illustrait cela et pourtant chez moi, cela ne se passe pas comme le site l’indique.
    Par exemple :

#include <SPI.h>
#include <SD.h>

void setup() {
  
Serial.begin(9600);
SD.begin(10); 

File fichier = SD.open("toto.txt", FILE_WRITE);

Serial.println(fichier.position()); // Affiche 0

fichier.println(F("Lundi"));

Serial.println(fichier.position()); // Affiche 7

fichier.seek(0);

Serial.println(fichier.position()); // Affiche bien 0 : le pointeur est donc bien remonté au début du fichier, non ?

fichier.println(F("Mardi")); // Mardi devrait donc s'écrire au début du fichier ( sur/à la place de lundi ) 

fichier.close();
}

void loop() {
}

Moi après 3 exécutions, j’obtiens :


Lundi
Mardi
Lundi
Mardi
Lundi
Mardi


Alors que je m’attendais à obtenir seulement :


Mardi


Pouvez-vous m’expliquer pourquoi malgré fichier.seek(0), il ne réécrit pas au début du fichier sur les données déjà écrites mais réécrit systématiquement à la fin des données déjà écrites ? ou m’expliquer ce que j’ai mal compris

Merci !

Pour 1 faites un petit coup de google... c’est super documenté...
Pour 2 regardez la doc de PROGMEM (tout en bas)

Pour 3 c’est plus subtil

SD.h définit FILE_WRITE comme cela

#define FILE_WRITE (O_READ | O_WRITE | O_CREAT | O_APPEND)

Le O_APPEND va forcer l’écriture à la fin même si vous faites un seek

Si vous ouvrez le fichier avec le mode O_READ|O_WRITE alors ça devrait fonctionner.

Pour 1 faites un petit coup de google… c’est super documenté…

  • J’ai eu ce problème, j’ai cherché google + include, je n’ai pas trouvé la réponse. Si on a la réponse on peut chercher, si on ne la pas on ne peut pas savoir ce qu’il faut chercher!
  • On a eu cette discussion il y a quelques mois, et visiblement tout le monde n’était pas d’accord. Ce qui veut peut être dire qu’on n’avait pas de référence explicite.

Bref, je prends pitié:

< > indique qu’il faut chercher la bibliothèque dans les répertoires des bibliothèques de l’arduino
" " indique qu’il faut chercher d’abord dans le répertoire de travail avant de chercher dans les répertoires des bibliothèques de l’arduino

Si on met au point une bibliothèque, ou si on ne veut pas installer une bibliothèque, on la met dans le répertoire de travail et on utilise les " ". si c’est une bibliothèque standard ou une que l’on a installée, on utilise < >

Si on met #include “SD.h”, cela doit fonctionner quand même, car ne trouvant pas SD.h dans le répertoire de travail, l’éditeur de liens va utiliser celle qui est dans le répertoire de l’Arduino.

Moi je trouve des milliers de réponse en tapant juste
c++ reference include double quotes vs angle brackets

Environ 1 320 000 résultats (0,70 secondes)

Voici la référence GCC

Et en français même sans le bon terme pour les chevrons ou <>
c++ #include guillemet versus accolades
Donne quand même environ une centaine de réponses et la première est la réponse…

bonsoir,

tu écris :

J-M-L:
Moi je trouve des milliers de réponse en tapant juste
c++ reference include double quotes vs angle brackets

Et en français même sans le bon terme pour les chevrons ou <>
c++ #include guillemet versus accolades

et je suis d’accord avec toi, mais c’est quand même Vileroi qui a raison : tu sais quoi chercher, et tu sais comment le chercher … mais pense aux débutants qui n’ont (encore) ni tes connaissances ni les méthodes que l’on t’a enseignées, avec certainement plus de pédagogie et d’humilité que toi.

Sérieusement Je pense que vous n’avez pas bcp essayé… qu’avez vous tapé dans Google ?

Explorer en tapant “ include guillemet <> c++ ” ne semble pas d’un niveau super élevé ?

Mais je vous donne le bénéfice du doute…

Moi je trouve des milliers de réponse en tapant juste
c++ reference include double quotes vs angle brackets

Et en français même sans le bon terme pour les chevrons ou <>
c++ #include guillemet versus accolades

Si je tape la recherche en français, je tombe en premier sur ce post d’openclassroom qui donne deux réponses. La première:

Les chevrons servent à spécifier un chemin qui part des répertoires d’include du compilateur. (avec gcc on les rajoutes avec -Ichemin)
Les guillemets permettent de spécifier un chemin qui part du répertoire du fichier qui l’inclut.

J’en aurai conclu que

  • cela parle d’un compilateur gcc, or j’avais un compilateur c++
  • il y aurait des répertoires d’include. Même aujourd’hui, je n’en connais que 2 mais qui ne s’appellent pas ainsi
  • je pense que la deuxième phrase est fausse.

Je n’ai eu aucune formation sur les moteurs de recherche, et bien souvent quand je cherche trois mots, j’ai des résultats qui en oublient un, du coup ma recherche n’aboutit pas. Et le fait d’avoir des centaines de réponses n’arrange pas les choses. Quand j’ai eu ce problème, j’aurais aimé chercher #include “” <>, mais je pensais que les symboles ne passaient pas. Ou peut être que je suis tombé sur une phrase du type:

Indique au préprocesseur de traiter le contenu d’un fichier spécifique, comme s’il figurait dans le programme source à l’emplacement où figure la directive.

Maintenant que j’ai écrit une bibliothèque, je comprends cette phrase, mais c’est vraiment du charabia pour celui qui utilise une bibliothèque pour les premières fois.

Quand je vois le niveau de français, je me dis aussi que consulter la doc anglaise ne doit pas être évident pour la plupart d’entre nous.

Moi je trouve des milliers de réponse en tapant juste
c++ #include guillemet versus accolades

Quand j’ai vu ça, j’ai demandé à ma compagne ce que voulait dire versus, et comme elle ne le savait pas non plus, c’est ce mot que j’ai cherché en premier!

Si je suis tombé sur la référence gnu, j’ai certainement vu:

This variant is used for system header files. It searches for a file named file in a list of directories specified by you, then in a standard list of system directories.

que j’aurais traduit par google en

Cette variante est utilisée pour les fichiers d’en-tête système. Il recherche un fichier nommé file dans une liste de répertoires que vous avez spécifiée, puis dans une liste standard de répertoires système.

Ce qui pour un débutant comme j’étais pose problème:

  1. c’est quoi un “fichiers d’en-tête système”? Maintenant, ce n’est pas très clair car j’utilise
    #include <PecheuxGraph.h>
    (Pecheux, c’est mon nom, et ce n’est pas moi qui ai écrit le système…)
  2. “Il recherche un fichier nommé file dans une liste de répertoires que vous avez spécifiée”
    Bien gentil, mais qui parmi nous spécifie une liste de répertoires? Ce serait " qu le système a spécifié", je comprendrait.

Bien souvent quand on a une réponse et que l’on ne comprend pas ni la première phrase, ni la deuxième,
on jette le lien on en trouve d’autres, et si tout est du même acabit, on peut estimer de n’avoir pas trouvé.

OK - comme dit plus haut, bénéfice du doute…

mais pour être honnête et transparent intimement convaincu qu’il n’y avait pas eu bcp de recherche dans ce cas - y compris sur le forum comme recommandé dans l’usage du forum. Tapez dans la loupe “ Include guillemets <> ” et faire une recherche dans le forum j’y ai vu la réponse aussi. Comme c’est un élément de syntaxe du langage, on peut aussi chercher sur Google “include c++ syntaxe”…

Pour versus, je peux rien pour vous - il faut bosser le latin alors en plus du C++ :)… blague à part je suppose que c’est un problème de génération.

Je me rallierais plutôt à l’avis de J-M-L.
Le premier tuto qui tombe quand on recherche “tutoriel langage C” sur Google :

Pour inclure un fichier.h se trouvant dans le dossier où est installé votre IDE, vous devez utiliser les chevrons< >:

#include <stdlib.h>

Pour inclure un fichier.h se trouvant dans le dossier de votre projet, vous devez en revanche utiliser les guillemets :

#include “monfichier.h”

Le problème ne porte pas simplement sur les #include.
Les débutants commettent souvent l’erreur de démarrer un projet, ou d’en copier un pour le modifier, sans avoir pris le temps de parcourir un tutoriel.
Cela entraîne une méconnaissance catastrophique du langage.

Personnellement je ne réponds plus aux demandes où il apparaît clairement que le demandeur n’a pas pris la peine de se former. J’estime que je ne suis pas là pour apprendre les bases du langage aux débutants.

J.M.L:
blague à part je suppose que c’est un problème de génération.

La génération actuelle : tout, tout de suite, sans effort …

5_cylindres:
mais pense aux débutants qui n'ont (encore) ni tes connaissances ni les méthodes que l'on t'a enseignées, avec certainement plus de pédagogie et d'humilité que toi.

  1. Quand j’étais à l’école internet n’existait pas et C++ était à peine naissant... donc les méthodes de recherche c’est juste du bon sens et pas quelque chose que l’on m’a enseigné. Vous avez un langage de programmation, c’est structuré il suffit d’aller trouver sa doc. De mon temps fallait trouver un livre et le lire. Pas de recherche textuelle..

  2. J’ai pris de mon temps pour répondre sur 2 et 3 qui étaient plus spécifiques. Je note - même pas un merci, même pas un retour de test... C'est parfois frustrant et incite à ne plus répondre du tout quand l'information est dans le manuel.

  3. Bien noté ma pédagogie et humilité ne vous vont pas, je ne répondrai donc pas à vos questions si vous en avez

Pour inclure un fichier.h se trouvant dans le dossier où est installé votre IDE, vous devez utiliser les chevrons< >:
#include <stdlib.h>

Je suis certainement tombé sur cette phrase il y a quelques mois. J’utilisais la biblioyhèque SD qui était dans le répertoire de l’IDE. Et j’ai essayé de remplacer les chevrons par des guillemets. Et surprise: cela fonctionnait quand même. Quand on travaille depuis un certain temps sur Arduino, cela peut sembler une évidence. Mais pour un débutant qui n’inclut pas un fichier mais une bibliothèque, cela peut sembler incompréhensible.

Je trouve les tutos d’openclassrom excellents, il peut y avoir des simplifications, mais je n’ai pas trouvé d’erreurs. Mais le tuto sur le C doit se lire plusieurs fois, la première fois, on en comprend à peine la moitié. Et pour un débutant, ce n’est pas facile de savoir ce qui s’applique au C++ et ce qui s’applique uniquement à leur outil. On parle de stdlib.h que je n’ai jamais inclus dans mes fichiers, mais qu’ils incluent sans arrêt.

les méthodes de recherche c’est juste du bon sens

C’est plus de l’habitude, de l’expérience, et il faut avoir une pensée logique, ce que tout le monde n’a pas, ou pas encore.

J’ai pris de mon temps pour vous répondre sur 2 et 3 qui étaient plus spécifiques. Même pas un merci, même pas un retour de test.

Si on conseille de lire PROGMEM, il faut lui laisser le temps de le lire et de le comprendre (voir de traduire). Pour peu qu’il ne sache pas la différence entre RAM et FLASH… Et cette différence n’existe pas sur PC. Mon fils enseigne l’informatique, mais je ne suis pas sûr qu’il comprenne l’intérêt de mettre les chaînes en mémoire programme plutôt qu’en mémoire donnée. J’étais dans le même cas jusqu’à ce que je fasse un programme important sur Uno. Et ce n’est pas avec le tuto de classroom qu’on peut comprendre cette différence

Quand j’ai un problème, si je fais des essais cela me prend plus de 24h. Plus d’une fois, j’ai un la réponse “c’était ça, maintenant ça marche, merci” avec des délais de 15 jours.

Quand j'ai un problème, si je fais des essais cela me prend plus de 24h. Plus d'une fois, j'ai un la réponse "c'était ça, maintenant ça marche, merci" avec des délais de 15 jours.

J'avais confondu 5_cylindres avec PierreM_Arduino.
corrigé mon message ci-dessus.

il faut avoir une pensée logique

oui... en programmation aussi... :slight_smile:
Mon expérience est que souvent "les jeunes générations" demandent sans vraiment avoir pris le temps de la recherche ou reflexion. Je suis d'accord avec Henri, c'est souvent du " tout, tout de suite, sans effort". Alors envoyer quelqu'un bosser un peu et voir ce qu'il en dit me semble justement pédagogique.

Certains sujets sont plus compliqués que d'autres à trouver pour des débutants, c'est pour cela que j'ai répondu à 2 et 3.

Je ne dis pas que j'ai raison dans l'absolu, juste que c'est ma vision des choses et que "bousculer gentiment" un petit peu de temps en temps est bénéfique pour l'apprentissage de l'autonomie. Je vois cela très souvent dans le club info / robotique où j'interviens - donc c'est assez ancré dans une réalité concrète.

@Vileroi

Quand tu cherches sur le Net des infos sur le C++, tu trouves des infos générales, pas limitées au cas Arduino. Je veux dire que l'environnement Arduino est un peu particulier.

Le C++ n'est bien sûr pas limité à l'arduino, la plupart des réponses que tu trouves s'appliquent très bien dans un contexte plus général (écrire un programme en C++ sous Linux, par exemple, ce qui concerne beaucoup plus de gens que le monde Arduino).

Le langage C a été inventé pour écrire des systèmes Unix. C'est son environnement de base. Dans ce système, les fichiers include (les .h) fournis par le compilateur (c-àd avec le système) se trouvent dans /include et /usr/include. Ce sont les chemins des fichiers .h dits "système", par opposition à ceux de l'utilisateur, qui est ici un programmeur.

Et, gcc signifie "GNU Compiler Chain", c'est le nom du compilateur C++ fourni avec Linux (et d'autres). C'est le nom d'un logiciel, pas celui d'un langage différend du C++ .
gcc est le C++.

Mon expérience est que souvent “les jeunes générations” demandent sans vraiment avoir pris le temps de la recherche ou reflexion. Je suis d’accord avec Henri, c’est souvent du " tout, tout de suite, sans effort". Alors envoyer quelqu’un bosser un peu et voir ce qu’il en dit me semble justement pédagogique.

+100

Goggle avec comme ‘mot clef’ include < " (c’est à dire les trois termes de la première question posée) donne chez moi 4 490 000 000 résultats (0,31 secondes)
l doit y avoir la dedans quelques infos claires et pertinentes pour qui se donne la peine de chercher.
Faut-il mobiliser les membres du forum pour produire des explications supplémentaires ?

Il est si difficile que ça de formuler cette requête ? ça fait appel à un savoir-faire exceptionnel ?

Goggle avec comme ‘mot clef’ include < " donne chez moi 4 490 000 000 résultats
Il est si difficile que ça de formuler cette requête ? ça fait appel à un savoir-faire exceptionnel ?

Quand je fais une recherche et que je trouve 4 490 000 000 résultats, j’estime que ma requête n’est pas bonne et j’en fais une autre. Sur l’ensemble il y a certainement des bons liens, mais il faut être capable de faire le tri. A raison de 10 secondes par page, il faut combien de temps pour trier?

Et ce n’est pas la requête qui est difficile, c’est de faire le tri entre ce qui est compréhensible. En plus il y a des explications qui sont fausses ou incomplètes. Si on connait le résultat, on peut trier. Pas forcément si on débute.

On lit les 3 ou 4 articles de la première page qui ressemblent à ce qu’on cherche et on refait éventuellement une autre recherche sur la base de ce qu’on a appris...

Mais bon si c’est comme cela pour vous - je veux bien vous croire...

vileroi:
Et ce n'est pas la requête qui est difficile, c'est de faire le tri entre ce qui est compréhensible. En plus il y a des explications qui sont fausses ou incomplètes.

Bin oui, c'est la jungle. Faut faire avec.

Si on connait le résultat, on peut trier. Pas forcément si on débute.

Plus on en connait et plus c'est facile. C'est la vie. Et c'est pas une mauvaise chose.

de la part de l'auteur ( débutant ) de ce "topic" :

Après avoir rédigé une longue réponse très complète, je préfère finalement me contenter de celle-ci :

Il serait fort souhaitable, lorsque que plutôt que de consacrer quelques courts instants à votre interlocuteur, vous ( les quelques personnes concernées devraient se reconnaitre même si on peut en douter ) préférez consacrer vingt fois plus de temps en torrents de mépris et même en insultes ( ! ), de créer à part une autre discussion spécifique, dans le but d'aller vous défouler ... mais ailleurs ... plutôt que de venir souiller de votre morgue la "discussion" initiale.

Je pensais trouver ici une possibilité d'entraide. Je croyais même que c'était le principal but d'un tel espace . Manifestement, c'est parfois tout autre chose. Et c'est à un tout autre spectacle auquel j'ai du assister ...

Du coup, tout propos concernant le sens du terme "débutant" me semble bien inutile. Et encore plus ma question initiale ...

Pour résumer

Ce forum a pour vocation d’aider à apprendre et à faire, pas faire pour vous à votre place. vous trouverez donc souvent des pistes et pas des réponses toutes faites. Souvent il y aura des dizaines de post pour essayer de guider quelqu’un vers une solution que les bénévoles qui participent peuvent résoudre en quelques minutes généralement.

J’ai estimé que vous pourriez trouver la réponse à #1 en faisant un peu d’efforts C’était volontairement Avec un objectif didactique et pédagogique - j’attendais de vous des questions si vous n’y arriviez pas.

J’ai estimé que les deux autres questions étaient plus difficiles pour un débutant et vous avez je pense des réponses claires et documentées.

Le débat d’idées en général (et sur le point 1) est toujours quelque chose de positif. Les remarques de chacun sont ancrées dans leur réalité, experience et perception. Il est bon de l’entendre. Je ne vois absolument pas cela comme un torrent de mépris... il faut toujours prendre un ou deux pas de reculs quand on lit, c’est plus difficile de voir l’état d’esprit que lorsque l’on a une conversation directe face à face.

Chacun sa lecture donc et ma longue expérience est alignée avec le proverbe, "quand un homme a faim, mieux vaut lui appendre à pêcher que de lui donner un poisson" (et ses variantes par exemple, on trouve aussi le proverbe africain "Si tu donnes un poisson à un homme il mangera un jour; si tu lui apprends à pêcher, il mangera toujours").

l'autonomie comme méthode est discutée par certains - en effet, il semble difficile de travailler de la même façon selon le type de public notamment - le bon sens nous dit qu'elle est néanmoins utile comme concept dans la formation sur objectifs spécifiques.

l'enseignant typique (un sage sur l’estrade qui débite son savoir) n'est pas LE modèle à suivre, c'est un guide / conseiller / coach; il n’est pas là pour faire des cours ou pour dire ce qu’il faut faire, mais plutôt pour donner des conseils, guider l’apprenant, analyser les objectifs, diagnostiquer certains problèmes, suggérer des méthodes de travail, expliquer les choses, etc.

il ne peut y avoir apprentissage sans objectifs et justement les objectifs doivent être le moteur de l'apprentissage;

apprendre à apprendre est un savoir-faire qui, une fois acquis, peut servir plus tard dans la vie pour continuer l'apprentissage (ou en initier d'autres).

(Tiré d’articles sur le thème d’enseignement)

Voilà mon point de vue - comme vous le voyez nous n’avons pas la même perception.