Non, en tout cas pas comme cela.
Quand tu fais: U8 tableau[48];
c'est comme si tu définissais un pointeur constant, donc impossible de modifier l'adresse de tableau.

La seule solution, c'est l'allocation dynamique, mais je doute que le compilateur l'autorise sur ces petits µContrôleurs.

Pour ce cas précis je ne pense pas car il y a vraiment risque de perte de donnée. Ca serait pareil en passant de double à float je pense.
Il doit y avoir moyen de paramétrer le niveau de warning ou quels sont les warnings qu'on veut éliminer, mais je ne le conseille pas.

Citation :Oui, ça s'appelle un cast, ou transtypage en français.
lors de l'évaluation de l'expression, le type du membre de droite de l'affectation va être transformée de pointeur de myStruc en pointeur de uint8_t (uint8_t est défini comme un unsigned char dans stdint.h).

Ca sert davantage en C++ où le compilateur est très strict sur la vérification des types. C++ a d'ailleurs bien évolué sur ce plan et la méthode que je t'ai donnée est à éviter en C++ "moderne". Il est demandé d'utiliser les mots clés tel que static_cast, reinterpret_cast, const_cast, dynamic_cast, mais j'avoue m'en taper un peu et je caste toujours à la C.

Citation :C'est juste pour "rassurer" le compilateur. Il faut évidemment que les 2 variables soient compatibles. Ici, ce sont des pointeurs, donc pas de problème pour caster à priori. Mais c'est le programmeur qui en prend explicitement la responsabilité.

Désolé, je n'avais pas vu ton message #11.

Charly t'a répondu. pas grand chose à ajouter.
Juste peut-être pour dire que si ta structure était définie comme un type, ça n'occuperait aucune place puisqu'un type est abstrait.
Mais chaque variable instanciée à partir de ce type va occuper physiquement la place nécessaire en RAM. Cette place peut être obtenue par l'opérateur sizeof (si, si, c'est bien un opérateur) comme Charly l'a évoqué.

Salut, mauvaise nouvelle, La virtualisation sous Windows pose encore pas mal de problèmes: soit je peux utiliser VMware, soit je peux émuler un terminal Android, et comme je m'essaie à Android pendant le confinement ...
Donc pas de machine virtuelle et pas de CodeWarrior.

J'ai tout de même fait quelques tests. Mais ce sera du code pour du PC. J'ai fait les tests grâce à WSL (Windows Subsystem for Linux, une distribution Debian en l'occurrence), donc compilateur gcc.

test1:

A la compilation: Citation :
C'est un warning, correspondant je pense au problème d'incompatibilité que tu as du rencontré. Mais l'exécutable est généré et l'affichage (en hexadécimal) donne: Citation : On reconnait bien les valeurs stockées dans la structure, avec l'alignement dont je parlais. Les "trous" sont comblés avec des valeurs non significatives.

J'applique la solution que je t'ai donnée hier pour supprimer le problème d'incompatibilité: Plus de warning à la compilation, donc à priori ça devrait aussi marcher pour toi.

Sinon, pour le problème d'alignement (que tu ne devrais pas rencontrer je pense), je l'ai supprimé avec un attribut au niveau de la structure:
. packed permet de compacter la structure et bouche les trous.
Résultat:Citation : Et là c'est tout bon.

A+

Qu'est-ce que tu utilises pour développer. Je devrais pouvoir retrouver une vielle machine virtuelle XP avec CodeWarrior encore installé au cas où.

C'est un compilateur C ou C++?

Sinon, en attendant, si tu fais:
tu ne te retrouves pas avec un tableau d'octets accessible avec p?
Au cas où ça coince encore, essaies ça:

Tu peux me montrer le code qui ne fonctionne pas avec l'erreur générée?

Non, ce n'est pas un problème d'endiannes, mais d'alignement:
Par exemple, tu crées une structure qui stocke un float, un char et un long int (32 bits). Si le compilateur se contente de se faire succéder les octets de ces 3 champs, ça va poser un problème sur un processeur 32 bits par exemple: le char faisant 1 octet, le long int qui suit va démarrer sur une adresse impaire et il faudra donc 2 accès mémoire pour le récupérer en entier.

Du coup, le compilateur va préférer aligner les champs sur des adresse multiples de 4 et le char prendra 4 octets même s'il n'y en a qu'un d'utile.

Avec un pointeur sur la structure, tu dois pouvoir accéder à n'importe quel octet.
Attention, certains compilateurs alignent les champs en taille pour favoriser la rapidité d'accès. Bon, avec un processeur 8 bits ça ne présente pas d'intérêt, mais je préfère préciser.