La taille des choses [Arduino]

[Anonyme]

Dernièrement j’ai passé commande de composants électronique pour un projet autour de ma chaudière. J’en ai profité pour prendre un nouveau ESP8266. Chez GoTronic chez qui j’ai commandé, l’ESP8266 disponible était un modèle de chez Adafruit, le Huzzah.

Ce que j’ai découvert après de nombreuses heures de debug… c’est que c’est un modèle 32 bits ! (je n’ai pas checké le modèle Olimex) Et ça change tout. Voici une image qui explique les choses. Pour obtenir la taille d’un type de donnée, il suffit de faire un (exemple avec le type int) Serial.println(sizeof(int));
[attachment=0]arduino_size.jpg[/attachment]

Explication du tableau :

Sur la gauche, j’ai mis différent type classique que l’on utilise.

Les colonnes vertes concernent la version 16 bits.

Les colonnes rougeâtres concernent la version 32 bits.

Quand un type de donnée ne change pas de taille, je n’ai rien mis côté 32 bits.

ATTENTION, j’en ai peut-être oublié… par exemple je pense à long et unsigned long, à mon avis en 32 bits ça doit changer. Désolé, je n’ai pas testé, c’est en écrivant ce texte que ça me vient.

Enfin bref, l’idée est que vous vérifiez bien ce que vous manipulez.

Pourquoi se plonger là dedans ? Parce que si vous utiliser des librairies pour effectuer des transferts de données entre divers arduino, vous allez être confronté au problème ! Perso je l’ai rencontré entre mon Huzzah et un Arduino pro (au passage il est pas top celui là car il n’a franchement pas beaucoup de mémoire)

Le 1er souci rencontré

J’ai déclaré une structure avec 2 float et 1 double.

Code:

struct TOTO {
float var1;
float var2;
double var3;
}

Sur mon arduino pro, ça faisait 12 octets, sur mon Huzzah c’était 16 ! Du coup le transfert n’était pas vraiment ok…

Voilà, ça c’est fait. Maintenant, autre souci… bah oui, ça ne serait pas drôle autrement

2nd souci : optimisation du compilateur

En mode 32 bits ça devient important… l’accès à la mémoire se fait par paquet de 4 octets. Du coup, accéder à une mémoire qui n’est pas aligné sur une adresse en 4 octets, c’est toujours possible, mais c’est plus lent pour le processeur qui doit effectuer plus d’opérations… C’est là que le compilateur intervient, comme il sait tout ça, quand il génère le programme, il fait en sorte que ça tombe à des adresses multiple de 4. Sympa pour nous, ça va plus vite. … mais …

Je reprend ma structure TOTO de tout à l’heure en enlevant le cas du double que l’on a vu ci-dessus mais j’ajoute une variable de type uint8_t.

Code:

struct TOTO {
uint8_t nouvelleVariable;
float var1;
float var2;
}

Le compilateur va s’arranger pour que ‘nouvelleVariable’ tombe pile poil sur une mémoire multiple de 4. Et comme il est intelligent, il sait que ‘var1’ va donc être sur une adresse mémoire qui n’est pas multiple de 4. C’est carrément dommage, surtout que c’est une variable de 4 octets justement ! Donc il va aligner tout ça par multiple de 4.

Voici ce qu’il va générer :

adresse 4 (4 pour l’exemple, multiple de 4)

nouvelleVariable de taille 1 octet

vide de 1 octet

vide de 1 octet

vide de 1 octet

var1 de 4 octets

var2 de 4 octets

Soit une taille totale de 12 octets ! Sur un arduino 16 bits, ça ne fera que 9 octets.

On peut donner une directive au compilateur pour désactiver ce mécanisme, ça s’écrit alors comme cela :

Code:

struct __attribute__((packed)) TOTO {
uint8_t nouvelleVariable;
float var1;
float var2;
}

Et du coup la structure de données fait à nouveau 9 octets. Youpi !

[Anonyme]

J’ai également commandé une esp8266 (vu les soldes aliexpress, à 7€ la carte autant en profiter :p)

C’est très intéressant ce que tu racontes je vais lire ça de près

[Auteur]

Messages