Coucou les copains,
Oui, je sais que les librairies ont donné suite à de nombreux sujets, mais … rien à faire, je coince sur deux où trois points particuliers et j’ai besoin de vos lumières.
J’ai réalisé une bibliothèque personnelle pour utiliser un afficheur LCD ST7565.
Elle fonctionne correctement et permet de tracer des droites, des rectangles, des cercles, des ellipses etc.
Maintenant je désire faire afficher des textes. J’ai développé des croquis bien au point, il me reste à les ajouter à ma bibliothèque. Le problème, c’est que je réalise un « générateur de caractère » sous la forme d’un tableau de 480 octets. Pour gagner de la place en mémoire dynamique, ce tableau est inscrit dans le haut de la mémoire EEPROM de l’ATmega328.
Pour pouvoir lire ces octets, il faut faire appel à EEPROM.H
Quoi que je fasse, quand j’ajoute #include <EEPROM.h> dans le fichier .h ou dans le fichier .ccp j’ai le message d’erreur : fatal error: EEPROM.h: No such file or directory
Rien à faire, j’ai tenté de remplacer les <> par des guillemets, placé différemment la directive dans le listage … toutes mes tentatives aboutissent à cette erreur.
Pourtant, <EEPROM.h> est bien disponible puisque mes programmes démonstrateurs y font appel et fonctionnent correctement.
SOS … --- … les copains, je suis bloqué de chez BLOQUÉ !
bonjour,
as tu essayé de placer la lib dans le même répertoire que ton ino?
Non, je vais tester, mais j'ai un doute, car mon démonstrateur.ino est dans un dossier "quelconque".
Bon, je teste et je te donne le résultat.
Dans l'ide arduino, les includes sont sensibles à la casse. Est ce que tua as bien mis #include <EEPROM.h> et non #include <EEPROM.H>
Ho que OUI j'ai fais méga attention, mais en fait je me contente de copier par bloc dans le croquis qui fonctionne, et transporte morceau par morceau dans la bibliothèque, ce qui évite les erreurs d'écriture.
J'ai enlevé la bibliothèque de l'endroit où elle était.
je l'ai recopié dans le dossier de mon programme de test.
J'ai réimporté cette dernière en indiquant le nouveau chemin.
Recompilation et ... c'est toujours pareil.
Ce qui est un peu fouf fouf fou, c'est que le programme.ino avec lequel j'ai développé le total fonctionne parfaitement, donc <EEPROM.h> se trouve bien où il faut.
As tu essayer de lire la datasheet ?
6 pages à lire (p20 à 26) dont seulement 2 vraiment utiles et 2 registres à manipuler pour écrire/lire des octets et exemple en C fournis
void EEPROM_write(unsigned int uiAddress, unsigned char ucData)
{
/* Wait for completion of previous write */
while(EECR & (1<<EEPE))
;
/* Set up address and Data Registers */
EEAR = uiAddress;
EEDR = ucData;
/* Write logical one to EEMPE */
EECR |= (1<<EEMPE);
/* Start eeprom write by setting EEPE */
EECR |= (1<<EEPE);
}
Faut-il aller s'embourber dans une classe EEPROM qui jusquà la Zero n'était qu'une ridicule encapsulation d'une macro Atmel eeprom_read_byte et eeprom_write_byte
cf : avr-libc: <avr/eeprom.h>: EEPROM handling
Au passage tu peux noter que bien d'autres types que l'octet sont disponibles mais Wiring/arduino les a snobé.
Fantastique fonction Wiring/arduino : évite d'écrire l'astérisque du pointeur !
Coucou les copains,
Bon, je vais prendre mon temps pour explorer tout ce que contient les osts #5 et #6 et surtout je vous remercie pour me consacrer gentiment du temps.
As tu essayer de lire la datasheet ?
6 pages à lire (p20 à 26) dont seulement 2 vraiment utiles et 2 registres à manipuler pour écrire/lire des octets et exemple en C fournis.
Ben ... j'imagine mal arriver à créer une bibliothèque qui fait des ellipses et des rectangles sans avoir lu un minimum la documentation constructeur. En fait, j'ai trouvé deux documents "en Anglais" ce qui ne m'arrange pas trop, mais globalement je crois en avoir compris le principal. Du moins c'est ce que je peux espérer, vu que le programme qui en a découlé fonctionne.
Faut-il aller s'embourber dans une classe EEPROM ...
J'avoue qu'avec tout ce que j'ai été en mesure de glaner ici et là, pour le moment ce qui m'a semblé le plus accessible, c'est d'utiliser <EEPROM.h> qui me permet d'écrire et de lire tout ce que je désire dans l'EEPRM, ce qui n'est pas si mal. Pour un naïf en programmation C cette bibliothèque me semble tout à fait appropriée.
Maintenant, pour les spécialistes il y a probablement mieux, mais je ne joue pas "dans la cour des grands" ...
OUPs, il faut que je me sauve, je reviendrais sur tout ça demain si je le peux.
Encore merci les copains.
Ce n'est pas du tout jouer dans la cour des grands, c'est copier mot à mots un exemple de 3 lignes fourni par Atmel qui en tant que concepteur et fabricant du micro est quand même celui qui connait le mieux le micro.
Cerise sur le gâteau c'est un exemple ultra simple pour commencer a utiliser les registres.
Cerise sur la cerise le code est plus petit, toujours bon à prendre, et beaucoup plus rapide.
Bonjour les Arduinautes,
Bon, ce matin j’ai repris le collier …
Dans un premier temps j’ai voulu tenter la « manipulation de pepe
Quand j’ai cherché le dossier contenant <EEPROM.h> j’ai constaté qu’il était dans une profondeur abyssale de sous répertoires.
Surtout, j’ai focalisé sur mon répertoire Arduino qui se trouve en < C:! ARDUINO>.
Souvent, quand je désire qu’un dossier passe en haut de la liste de l’explorateur, je commence par le caractère « ! ». Ce nom de dossier ne serait-il pas en cause ? ? ?
Autre observation : J’utilise (Utilisais) la version 1.6.1 il devenait pertinent de soupçonner aussi un problème de version du compilateur. Il devenait temps de passer à la nouvelle mouture de l’I.D.E. J’ai installé la 1.6.8 et remis le système en fonctionnement, avec cette fois pas de « ! » en tête du nom de dossier.
BEN … cette fois <EEPROM.h> est accepté et toutes mes routines d’affichage de texte et de nombres ajoutés dans la bibliothèque ont le comportement attendu.
Il y a juste un chmolduk : Le compilateur n’aime plus du tout ma procédure d’affichage de texte. Il me fait le message d’erreur suivant :
warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
à chaque appel du type LCD.Affiche_TEXTE(" BONjour ...");
Les caractères ordinaires sont correctement affichés, par contre les caractères spéciaux comme certains accentués ne sont plus traités correctement.
void PERSO_ST7565::Affiche_TEXTE(char TEXTE[21]) { // 21 caractères au maximum sur une ligne.
byte I, Code_ASCII; // Laisse PTR sur le prochain Octet de MEMOIRE.
I=0;
while (TEXTE[I] != 0) {
Code_ASCII = TEXTE[I];
if (Code_ASCII != 0)
{if ((Code_ASCII == 194) || (Code_ASCII == 195))
{I++; Code_ASCII = TEXTE[I]; if (Code_ASCII == 169) Code_ASCII = 92; // Traite le é.
if (Code_ASCII == 168) Code_ASCII = 96; // Traite le è.
if (Code_ASCII == 160) Code_ASCII = 94; // Traite le à.
if (Code_ASCII == 181) Code_ASCII = 126; // Traite le µ
if (Code_ASCII == 167) Code_ASCII = 127;} // Traite le ç.
else Code_ASCII;
Caractere(Code_ASCII,SURbrillance); if (PosX>127) CRLF(); I++;} } }
Vous avez une idée relative à ce changement de comportement S.V.P ?
Je profite de ce sujet pour "abuser un peu" de vos connaissances.
Outre le problème cité dans le message qui précède, il y a divers détails dont je n’ai pas vraiment compris la raison ou le comportement :
La notion de « Public » et « Private » par exemple. On trouve souvent l’information :
Les variables utilisées par la bibliothèque doivent être déclarées en « Private », mais pas la raison. Hors, même quand elles sont déclarées en public, elles sont inconnues dans le programme.ino qui inclut la bibliothèque. Vous pouvez m’éclairer sur ce point s’il vous plait ?
Les variables déclarées private ne sont accessibles que par les fonctions membres de la classe.
Les variables public sont accessibles aussi par des fonctions qui ne font pas partie de la classe.
Normalement si la déclaration de la classe est incluse dans ton fichier .ino, tu dois pouvoir accéder aux membres public.
J’ai tenté de modifier une variable Public en l'ayant déclarée Public: et ça ne fonctionnait pas. Le compilateur me disait que la variable en question n'était pas déclarée.
Suite à ton message, j’ai refais des manip et trouvé pourquoi :
Je me contentais de mettre comme identificateur celui de la variable.
Hors comme elle appartient à une classe il faut faire précéder de MaClasse. Suivi du nom de la variable. Chic alors, je crois avoir compris un « truc » de plus. Merci …
De toute façon, c'est un autre problème car si tu essaie d'accéder une variable privée le compilateur ne te dit pas qu'elle n'est pas déclarée, mais qu'elle n'est pas accessible.
OK 68tjs
Je vais analyser tout ça, c’est certainement très intéressant.
Mais quand tu parles de dataSheet, à quel document tu fais référence s’il te plait ?
C'est fait, j'ai à peu prés cerné les routines dont parle 68tjs.
Elles sont effectivement bien plus inintéressantes qu'utiliser <EEPROM.h>.
Non seulement on peut lire et écrire facilement des byte, int, Float, mais le code produit est plus court.
En résumé, <EEPROM.h> n'est absolument pas une panacée.
Encore merci les copains pour toutes ces informations.
Il serait judicieux je pense de mettre l’attribut "RÉSOLU" à ce sujet, mais je ne sais pas comment procéder. SOS ...