Bonjour à tous
suite au post d'un jeuneICI
je me suis intéressé de plus près au timer 1 du 328 d'ATMEL
pouvez vous me dire si l'un d'entre vous à réussi à écrire une valeur supérieure à 0xFF dans OCR1A
et si oui, comment?
perso, je le fais en assembleur sous AVR STUDIO 7, les tests me montrent que des valeurs telles que 0x3344 par exemple sont bien prises en compte et que TCNT1 compte bien jusqu'à cette valeur avant de faire basculer le sortie correspondante ( OC1A en toggle).
sous ide 18.1.9, pas moyen d'écrire une telle valeur directement en C
même en incorporant mon assembleur dans le C, la compilation se passe bien, mais OCR1H reste toujours à zéro.
hello
je me réponds
tout dépends de l'ordre dans lequel on ecrit dans les registres
si j'ecris: OCR1A=0xFFFF; TCCR1A=0x43;TCCR1B=0x1D;
le Serial.print du registre OCR1A me donne :
alors que si j'écris:
TCCR1A=0x43;TCCR1B=0x1D;OCR1A=0xFFFF;
le Serial.print du regstre OCR1A me donne:
hi,
et à la prochaine révision , il faut le réécrire dans l'autre sens ?
il n'y a , amha , aucune logique à ceci , les registres de config ne doivent pas avoir d'influence sur le registre de capture !
il eût fallu ouvrir un 'issue" , mais comme c'est une vieille version ... (et de + tu te serais fait engirlander pour ne pas utiliser le noble API)
Je pense que l'explication est au moins en partie dans le datasheet si on adresse en C un registre 16 bits en une fois sur un micro 8 bits il faut forcément utiliser une technique spécifique.
oui , mais ça , (depuis le temps) , le compilo est sensé le savoir !
quand on fait cette écriture (ou cette lecture) en c sur 16 bits , il doit faire les opérations qui vont bien ;
un coup ça marche , un coup pas , c'est un bug
hello
en ce moment, un gars est sur un µ328 PB
étant un peu curieux, je suis allé voir la data sheet, et comme je pense accès aux registres en 16 bits,
j'ai regardé ce qu'il en est dit dans la data sheet du 328PB
Bonsoir dfgh.
Votre pugnacité ma rappelle le bon temps, datasheet sous les yeux pour maîtriser des ATtiny ou des ATméga avec un langage bas niveau.
Quelle est la stratégie du fabricant d'inverser l'ordre d'écriture lecture LB et HB entre les versions PB et PU de ce 328 concernant ce registre TCNT1 et registres de comparaison OCR1A et B?
Je pense que nous n'aurons jamais la réponse.
Cordialement.
Your above discussion is barking up the wrong tree. In fact, the compiler will always generate the correct write order, and developers don't need to worry about this. Instead, you actually need to pay attention to page 142, 145 and 154 of the Datasheet:
The OCRnx Register is double buffered when using any of the twelve Pulse Width Modulation (PWM) modes. For the Normal and Clear Timer on Compare (CTC) modes of operation, the double buffering is disabled. The double buffering synchronizes the update of the OCRnx Compare Register to either TOP or BOTTOM of the counting sequence.
When the double buffering is enabled, the CPU has access to the OCRnx Buffer Register, and if double buffering is disabled the CPU will access the OCRnx directly. The content of the OCR1x (Buffer or Compare) Register is only changed by a write operation (the Timer/Counter does not update this register automatically as the TCNT1 and ICR1 Register). Therefore OCR1x is not read via the high byte temporary register (TEMP).
To summarize, when the lower two bits of TCCRA are not all zeros, OCRA is controlled by PWM mode and cannot exceed the number of bits allowed by PWM (8, 9 or 10 bits). Therefore, before setting OCRA to a larger value, you must first set the lower two bits of TCCRA to 0.
hello ebolachan.
désolé de cette réponse tardive, comme tous les retraités, je manque de temps....
"Pour résumer, lorsque les deux bits inférieurs de TCCRA ne sont pas tous des zéros, OCRA est contrôlé par le mode PWM et ne peut pas dépasser le nombre de bits autorisé par PWM (8, 9 ou 10 bits). Par conséquent, avant de définir OCRA sur une valeur plus élevée, vous devez d’abord définir les deux bits inférieurs de TCCRA sur 0."
tout dabord, merci de l'intéret que tu portes à cette question.
ta réponse est intéressante, mais je te renvoie à mon post #2
tout dépends de l'ordre dans lequel on ecrit dans les registres
si j'ecris: OCR1A=0xFFFF; TCCR1A=0x43;TCCR1B=0x1D;
le Serial.print du registre OCR1A me donne :
alors que si j'écris:
TCCR1A=0x43;TCCR1B=0x1D;OCR1A=0xFFFF;
le Serial.print du regstre OCR1A me donne:
je suis daccord pour le fait que les bits 0 et 1 doivent etre à 1 pour etre dans un mode qui accepte une valeur telle que 0xFFFF.
ce que je faisais remarquer, c'est qu'il faut dabord écrire à 1 les bits 0 et 1 de TCCR1A puis écrire 0XFFFF dans OCR1A . le compilateur ayant été prévenu en premier de la valeur de TCCR1A, il va gérer correctement OCR1A.
mais si le compilateur ne sait pas la valeur de TCCR1A, il ne va pas la voir avant de gerer OCR1A.
il y a donc bien un ordre d'écriture à respecter pour que le compilateur sache quoi faire.
Indeed, I ignored the second half of the table. When WGM3 is set (in TCCRB), the limit on OCRA bits is also removed. But this also means that the TCCRA setting in your code won't help - setting only the TCCRB WGM3 bit is enough to remove the OCRA restriction. Otherwise, you must still set the lower two bits of TCCRA to 0.
