Go Down

Topic: lancement de fonctions en différé (Read 4828 times) previous topic - next topic

bricoleau

Bon, là, je tombe sur le c*l! je lis dans quelques docs techniques AVR :
 à traduire par
"Ceci est différent du compilateur C qui utilise le type int par défaut afin d'évaluer les constantes entières".

Ca veut dire que dans "for (byte i=0, i<3, i++){}", i (un entier 8 bits à la base) sera converti en int (16 bits signé), car 3 est une constante et que par défaut, une constante est un int 16 bits signé. Ca veut dire que pour la comparaison "i<3" et l'incrémentation "i++", ça se fera en 16 bits signé. Je comprends maintenant pourquoi je trouve partout dans mon code asm des calculs en 16 bits avec des conversions signées qui prennent 6 cycles d'horloge, alors que finalement, en 1 cycle, on fait la même opération en 8 bits... Je sens qu'il y a de l'optimisation à faire! ou alors travailler avec un AVR 16 bits...

peut-être que faire un "for (byte i=(byte)0, i<(byte)3, i++){}" résoudrait la chose, mais bonjour l'illisibilité du programme...
Dans ce cas, le plus simple est peut-être de séparer tes constantes et tes instructions.
Par exemple :
Code: [Select]
  const byte imax = 3;
  const byte zero = 0;
...
for (byte i=zero; i<imax; i++){}


Ces const seront évalués uniquement au moment de la compil. Cela ne conviendrait-il pas?

Tutoriels arduino : http://forum.arduino.cc/index.php?topic=398112.0

Super_Cinci

#16
Oct 23, 2015, 12:09 am Last Edit: Oct 23, 2015, 07:15 am by Super_Cinci Reason: ajout d'infos
J'ai peur que ça fasse le même foirage en passant en int... plus j'en lis sur le compilateur, moins j'ai confiance...

sacré boulot en tout cas, mais c'est sûre que le compillo n'optimise pas tout en fait j'utilise pas mal les byte au lieu de int quand cela est nécessaire mais ça sert à rien vu que les comparaisons sont sur des int ! je ne pige pas tout encore en C moi lol

Je viens de lire aussi que lors d'un appel à une fonction déclarée genre "void fonction (byte a, byte b){}", bas le compilo va transmettre les paramètres a et b sur deux paires de registres, donc ça bouffe 4 octets pour n'en transmettre que deux... complètement débile. limite à se dégoûter de la prog!

Autre surprise, bah AVR-GCC ne veut pas d'assembleur! Ah non, mais pourquoi se sont-ils fatigués à aller nous pondre une doc avec l'assembleur du µC si on peut pas s'en servir?

Bon, il y a l'assembleur inline, mais (comme quoi nous vivons dans un drôle de monde) le compilateur se permet de modifier le code assembleur à sa guise, puisqu'il compile...

Ca n'empêche pas de quand même tenter la chose.

j'ai trouvé ça, ça à l'air d'être une bonne piste :

Code: [Select]
;The C declaration is volatile unsigned char samples[255].
ldi r30, lo8(samples) ; use ldi for a pointer
ldi r31, hi8(samples)
ldi r18, 0x05
add r30, r18
adc r31, r1 ; compiler enforces r1 = 0 ; curent array point now in Z
ld r19, z  ; r19 now contains samples[5]


EDIT :

Je viens de trouver (dans l'aide en ligne d'ATMEL) que l'on peut palier au problème des int en 16 bits par défaut en utilisant l'option :
Quote
-mint8

Assume int to be an 8-bit integer. Note that this is not really supported by avr-libc, so it should normally not be used. The default is to use 16-bit integers.
Bon, super, si c'est "pas vraiment supporté par avr-libc"... Reste à coller cette option quelque part.

rvrostaing

Benh moi qui cherchait une fonction timeout je suis servis !
Merci pour vos échanges, je n'ai pas le niveau, mais vos morceaux de codes vont beaucoup m'aider :-)

Go Up