Retard Arduino

En général pour des retards du même ordre de grandeur que l'horloge du uC on ajoute des NOP puis on ajuste en mesurant. Des problèmes peuvent effectivement être causés "involontairement" par ton compilo s'il a des options d'optimisation qui "réarragent" ce qui se passe entre ton code source et le code machine généré.

Pour être sûr (et rester maître) de ce qui se passe, regarde le code machine après compilation et/ou supprime les options d'optimisation du compilo.

l'horloge du uC on ajoute des NOP puis on ajuste en mesurant.

Vi, c'est ce que j'ai fait avec mes instructions ;>)

regarde le code machine après compilation et/ou supprime les options d'optimisation du compilo.

La on est sur de l'Arduino alors la verif du source ou les options de compilation (surtout avec leurs instruction et routine) sont réduites au strict minimum ......... bon, si il faut passer par AVR studio autant tout faire par la .......... mais c'est moins pratique.

Pascal-J :

Vous parviendrez sans doute à obtenir la temporisation logicielle que vous souhaitez. Mais elle n'interviendra qu'ajoutée aux 0,85µs de la boucle. Or ce code de base peut contenir des comparaisons, branchements, qui feront que sa durée n'est pas constante. On peut généralement faire du code sans branches, mais ce n'est pas toujours simple. Et puis vous ne maîtrisez pas plus - par rapport au processus de compilation - cette partie utile que la partie temporisation, voir plus bas. Ce qui peut se passer c'est que ça fonctionne assez bien pour l'instant, mais que ça comporte en germe de futurs emmerdements. De plus c'est directement dépendant de la carte via la vitesse du processeur.

C'est tout à fait logique, le compilateur simplifie ce qu'il peut à partir de ce qu'il connait au moment de la compilation. Les #define, les constantes littérales sont remplacées par leurs valeurs et des calculs sont faits avant de générer du code machine. Les boucles courtes seront développées. Les variables, déclarées constantes ou non, sont étudiées de façon pas toujours évidentes pour le programmeur, en vue de déterminer si elles peuvent ou non changer de valeur entre deux points de code. Vous pouvez faire quelque chose de bien plus prévisible et reproductible en déclarant vos variables dummies en "volatile". En gros le compilateur considèrera que ces éléments peuvent changer de valeur à tout moment indépendamment du programme, et qu'elles peuvent également être consommées à tout moment. Il ne concluera pas qu'elles sont inutiles, comme il le fait parfois par exemple pour les variables de boucle qui disparaissent ou passent dans un registre. Il va générer du code machine au plus près de votre code C/C++ ou Arduino. Si déclarer "volatile" ne suffit pas, il restera à essayer un peu de code machine inline. Voyez lesquels de __asm__() et asm volatile () compile sur votre bouzin, lisez peut-être ici

"Pierre Maurette"

Sans compter les éventuelles interruptions qui tomberaient pendant la boucle, et rallongeraient d'autant (si elles ne sont pas masquées)

vous souhaitez. Mais elle n'interviendra qu'ajoutée aux 0,85µs de la boucle.

Pas de soucis, c'est qui etait demandé .............. et pi c'est fait ;>)

branchements, qui feront que sa durée n'est pas constante

Oui mais a l'operateur de se débrouiller pour que cela tombe juste. Sinon il ne reste plus qu'horloge et interuptions, mais pour 10 lignes d'instructions autant éviter

de compilation

C'est bien mon soucis, savoir un peu comment il compile leurs instructions de haut niveau

Oui mais la aussi, on en tient compte, c'est la base

reproductible en déclarant vos variables dummies en "volatile". En gros ..................... compile sur votre bouzin, lisez peut-être ici

Merci pour les pistes.

Bon, comme je l'ai dit le probleme est résolu, de toute façon ce n'est que pour de la bidouille perso.

la boucle, et rallongeraient d'autant (si elles ne sont pas masquées)

Vi aux deux.

J'ai dit que je débutait dans l'Arduino, pas que je filoutai .......... ou p'tiloutai je ne sais plus ;>)