Introduction aux MCU atTiny, partie 7

gestion de la consommation

Comme les micro-controlleurs sont souvent utilisés dans des gadgets fonctionnnant sur piles, les fabriquants tentent de réduire la consommation électrique au minimum. Les petits micro-controlleurs comme l'atTiny13a lorsqu'ils sont en mode power down consomment tellement peut qu'il n'est pas nécessaire de débrancher les piles. Dans cette chronique on va examiner les différentes méthodes pour réduire la consommation électrique.

Comme démo j'ai repris le jeux pong 1-D que j'ai réalisé sur un atTiny13a. voici le schéma:

Les LEDs sont montées en Charlieplexing sur PB0-PB3 et les boutons sont lus en ADC sur PB4. PB5 garde sa fonction de RESET.

Il s'agit d'une rangée de 8 LEDs et d'un bouton à chaque extrémitée. Une LED allumée qui circule d'une extrémitée à l'autre tiens lieu de balle que les joueurs se renvoient en pressant leur bouton respectif. Plus un joueur attend que la balle soit prêt de lui pour la renvoyer plus elle retourne rapidement réduisant d'autant les chances de l'adversaire de la frapper. La partie se termine lorsqu'on joueur a accumulé 15 points. Le pointage est affiché en binaire sur la rangée de LED. Les 4 LEDs de gauche indiquent le pointage du joueur de ce joueur et les autres celui de droite.

Économie d'énergie

code source tennis.c /* * NOM: tennis.c * DESCRIPTION: jeux linear pong. 8 LED en lignes. Une LED allumée * représante la balle et se déplace d'une extrémitée à l'autre. * À Chaque extrémité un joueur doit retourner la balle * à son adversare en pesant sur un bouton. * Il doit pesé sur son bouton avant que la balle dépasse * l'extrémitée. Mais il est préférable qu'il attende qu'elle * soit le plus près possible car la vitesse de retour * est inversement proprotionnelle à la distance qui la sépare * de lui. * Le premier joueur qui accumle 15 points gagne la partie. * * Au démarrage toutes les LED sont allumées pour débuter la * partie il faut qu'un des joueurs pèse sur son bouton. * Le choix du joueur qui a le service est aléatoire et est * indiqué par la LED qui clignote rapidement. * Il doit pesé sur son bouton pour lancer la balle. * L'autre joueur la retourne le plus tardivement possible. Le joueur * qui gagne l'échange acculume 1 point et prend le service. * * A la fin de la partie le pointage est indiqué en binaire * sur la rangée de LED. Le LED0 qui devrait-être à gauche * représente le bit de poids fort et le LED7 celui de poids * faible. Les LED 0-3 indique le pointage du joueur de droite * et les LED de 4-7 le pointage du joueur de gauche. Le pointage * reste affiché jusqu'à ce qu'un bouton soit enfoncé. Après quoi * une nouvelle partie peut débutée. * * AUTEUR : Jacques Deschênes * DATE : 2012-01-24 */ #define CLK_DIV 1 #define F_CPU 9600000UL/CLK_DIV //fréquence (9.6MHz/CLK_DIV) #include <avr/io.h> #include <avr/interrupt.h> #include <util/delay.h> // les 3 macros suivante (wdt_) ont été extraite de wdt.h et légèrement modifiées #define wdt_reset() __asm__ __volatile__ ("wdr":::) #define wdt_enable(value)\ __asm__ __volatile__ ( \ "in __tmp_reg__,__SREG__" "\n\t" \ "cli" "\n\t" \ "wdr" "\n\t" \ "out %0, %2" "\n\t" \ "out %1, %3" "\n\t" \ "out __SREG__,__tmp_reg__" "\n\t" \ "out %1,%4" \ : /* no outputs */ \ : "I" (_SFR_IO_ADDR(MCUSR)), \ "I" (_SFR_IO_ADDR(WDTCR)), \ "r" (_BV(WDRF)), \ "r" (_BV(WDCE) | _BV(WDE)), \ "r" ((uint8_t)(value & 0x6F))) #define wdt_disable()\ __asm__ __volatile__ ( \ "in __tmp_reg__, __SREG__" "\n\t" \ "cli" "\n\t" \ "out %0, %1" "\n\t" \ "out %0, __zero_reg__" "\n\t" \ "out __SREG__,__tmp_reg__" "\n\t" \ : /* no outputs */ \ : "I" (_SFR_IO_ADDR(WDTCR)), \ "r" ((uint8_t)(_BV(WDCE) | _BV(WDE)))) #define wdt_enable_interrupt() \ MCUSR &= ~(_BV(WDRF));\ WDTCR = _BV(WDCE) | _BV(WDE);\ WDTCR = _BV(WDTIE) | _BV(WDP0) | _BV(WDP3); #define led_off() DDRB &= 0xF0; #define read_adc() ADCSRA |= 1<<ADSC;\ while (ADCSRA & (1<<ADSC)); #if (CLK_DIV<8) #define CLKPS(x) (x/2) #else #define CLKPS(x) 3 #endif // constantes #define ANOD_LED0_1_2 PB0 #define ANOD_LED3_4_5 PB1 #define ANOD_LED6_7 PB2 #define CATH_LED0 PB1 #define CATH_LED1 PB2 #define CATH_LED2 PB3 #define CATH_LED3 PB0 #define CATH_LED4 PB2 #define CATH_LED5 PB3 #define CATH_LED6 PB0 #define CATH_LED7 PB1 #define BUTTONS PB4 #define LEFT_SWEEP -1 #define RIGHT_SWEEP 1 #define BTN_TRESHOLD 206 #define BTN_LEFT_MIN 185 #define BTN_LEFT_MAX 205 #define BTN_RIGHT_MIN 120 #define BTN_RIGHT_MAX 135 #define BTN_BOTH_MIN 105 #define BTN_BOTH_MAX 116 #define BTN_NONE 0 #define BTN_LEFT 1 #define BTN_RIGHT 2 #define BTN_BOTH 3 #define PLAYER_LEFT 0 #define PLAYER_RIGHT 1 #define BASE_SPEED 31 #define DEFAULT_SPEED 4*BASE_SPEED // vitesse de déplacement de la LED #define DLY_16SEC 2 // délais pour count_down 16 secondes // variables globales volatile uint8_t count_down=DLY_16SEC; // compte à rebours délais inactivité. uint8_t score[2]; // pointage des joueurs uint8_t player; // celui qui a le service uint8_t led_at_btn; //LED allumée lorsque le bouton a été enfoncé. void led_on(uint8_t led){// allume la LED désignée en argument uint8_t a=0,c=0; led_off(); PORTB &= 0xF0; switch (led){ case 0: c = 1<<CATH_LED0; a = 1<<ANOD_LED0_1_2; break; case 1: c = 1<<CATH_LED1; a = 1<<ANOD_LED0_1_2; break; case 2: c = 1<<CATH_LED2; a = 1<<ANOD_LED0_1_2; break; case 3: c = 1<<CATH_LED3; a = 1<<ANOD_LED3_4_5; break; case 4: c = 1<<CATH_LED4; a = 1<<ANOD_LED3_4_5; break; case 5: c = 1<<CATH_LED5; a = 1<<ANOD_LED3_4_5; break; case 6: c = 1<<CATH_LED6; a = 1<<ANOD_LED6_7; break; case 7: c = 1<<CATH_LED7; a = 1<<ANOD_LED6_7; break; default:; } DDRB |= a | c; PORTB |= a; } // led_on uint8_t delay_read_buttons(uint8_t msec){// delais en msec et leture boutons uint8_t smallest; read_adc(); smallest=ADCH; while (msec){ read_adc(); if (ADCH<smallest) smallest=ADCH; _delay_ms(1); msec--; } return smallest; } // delay_read_buttons uint8_t debounce_button(){ //20 lectures ADC consécutives identiques pour quitter. uint8_t previous, btn=0, count=0; read_adc(); previous=ADCH; while (count<20){ read_adc(); if (ADCH==previous) count++; else {previous=ADCH;count=0;} _delay_ms(1); } if (previous<=BTN_LEFT_MAX){ if (previous>=BTN_LEFT_MIN){ btn=BTN_LEFT; } else{ if (previous>=BTN_RIGHT_MIN){ btn=BTN_RIGHT; } else{ btn=BTN_BOTH; } } } return btn; } // debounce_button void display_byte(uint8_t byte){// affiche binaire de 'byte' sur la rangée de LEDs uint8_t led=0; while (delay_read_buttons(1)>BTN_TRESHOLD){ if ((byte & (1<<(7-led)))) led_on(led); else led_off(); led++; if (led>7) led=0; } while (delay_read_buttons(16)<BTN_TRESHOLD); } // display_byte uint8_t throw_ball(int8_t direction, uint8_t speed){//lancé de la balle vers l'autre joueur uint8_t hit, led, btn_val; if (direction==RIGHT_SWEEP){ led=0; } else{ led=7; } hit=0; while (led<=7){ led_on(led); btn_val=delay_read_buttons(speed); if (btn_val < BTN_TRESHOLD){ hit = 1; break; } led += direction; } if (hit) { led_at_btn=led; btn_val=debounce_button(); if (btn_val<=BTN_LEFT_MAX){ if (btn_val>=BTN_LEFT_MIN){ hit=BTN_LEFT; } else{ if (btn_val>=BTN_RIGHT_MIN){ hit=BTN_RIGHT; } else{ hit=BTN_BOTH; } } } if ((direction==LEFT_SWEEP && hit==BTN_LEFT) || (direction==RIGHT_SWEEP && hit==BTN_RIGHT) || (hit==BTN_BOTH)) hit=1; else hit=0; while (delay_read_buttons(16)<BTN_TRESHOLD); } return hit; } // throw_ball void wait_begin_signal(){// attend signal début partie uint8_t led; int8_t direction; led=0; direction=1; while (1){ led_on(led); if (delay_read_buttons(2)<BTN_TRESHOLD){ break; } if (led>7) direction = -direction; led += direction; } while (delay_read_buttons(16)<BTN_TRESHOLD); led_off(); if (led<4) player=PLAYER_LEFT; else player=PLAYER_RIGHT; } // wait_begin_signal void wait_service(){// attend le lancé du service uint8_t led, blink_cntr=0; if (player==PLAYER_LEFT){ led=0; } else{ led=7; } while (1){ if (blink_cntr<8) led_on(led); else led_off(); if (delay_read_buttons(16)<BTN_TRESHOLD) { if (debounce_button()==(player+1)) break; } blink_cntr++; blink_cntr &= 0xF; } while (delay_read_buttons(16)<BTN_TRESHOLD); led_off(); } // wait_service /* * une erreur c'est glissé dans iotn13a.h * BPDSE a été défini à la place de BODSE * BPDS a été défini à la place de BODS */ #define BODSE 0 #define BODS 1 ISR(WDT_vect){ // met le CPU en mode POWER DOWN après 16 secondes d'inactivité count_down--; if (!count_down){//power down led_off(); wdt_disable(); PORTB = 0 ; // désactivation des pullup BODCR = _BV(BODSE) | _BV(BODS); // désactivation Brownout dectect BODCR = _BV(BODS); ADCSRA &= ~(1<<ADEN); // désactivation ADC PRR |= _BV(PRTIM0) | _BV(PRADC); MCUCR = _BV(SE) | _BV(SM1); // mode power down __asm__ __volatile__ ("sleep":::); // les interruptions sont désactivées // un reset PB5 sera nésessaire pour redémarré. }else{ wdt_enable_interrupt(); } } int main( void ) { int8_t display, direction; uint8_t speed; // initialisation mcu CLKPR |= 1<<CLKPCE; CLKPR = CLKPS(CLK_DIV); // F_CPU 9.6Mhz/CLK_DIV // désactivation périphériques inutilisés ACSR |= _BV(ACD); // désactivation analog comparator DIDR0 |= _BV(ADC0D) | _BV(ADC1D) | _BV(ADC2D) | _BV(ADC3D); // désactivation entrées numériques inutilisées // initilasation watchdog timer wdt_enable((_BV(WDTIE)|_BV(WDP3)|_BV(WDP0))); // interruption sur timeout, diviseur 1024 sei(); // activation des interruptions // initialiation de l'ADC sur PB4 ADMUX= (1<<ADLAR) + 2; // résultat aligné à gauche, lecture canal 2. ADCSRA= (1<<ADEN) + 6; // activation ADC + diviseur=64 while ( 1 ) { // game loop wait_begin_signal(); if (player==PLAYER_LEFT){ direction=RIGHT_SWEEP; } else{ direction=LEFT_SWEEP; } speed=DEFAULT_SPEED; score[PLAYER_LEFT]=0; score[PLAYER_RIGHT]=0; wait_service(); while (1){ // throw loop wdt_reset(); count_down=DLY_16SEC; if(throw_ball(direction, speed)){ if (direction==LEFT_SWEEP){ speed=BASE_SPEED*(led_at_btn+1); } else{ speed=BASE_SPEED*(8-led_at_btn); } direction= -direction; } else{ if (direction==LEFT_SWEEP){ score[PLAYER_RIGHT]++; player=PLAYER_RIGHT; direction=LEFT_SWEEP; } else{ score[PLAYER_LEFT]++; player=PLAYER_LEFT; direction=RIGHT_SWEEP; } speed=DEFAULT_SPEED; wait_service(); } if (score[PLAYER_LEFT]==15 || score[PLAYER_RIGHT]==15){ // partie terminée. display=((int8_t)score[PLAYER_LEFT]<<4) + score[PLAYER_RIGHT]; display_byte(display); led_off(); break; } } } return 0; } // main

Je ne sais pas si vous avez remarqué mais les fabriquants donnent toujours la consommation d'énergie de leur MCU, en début de datasheet, au plus bas voltage de fonctionnement et à la fréquence de 1Mhz. Si on veut connaître la consommation à fréquence et voltage plus élevé il faut fouiller les données electrical characteristics à la fin du datasheet. Le fait est que la technologie CMOS a remplacé la technonologie NMOS du début 70's car elle consomme moins d'énergie. Sauf que la consommation augmente exponnentiellement avec la fréquence et le voltage.

Donc une des méthodes pour réduire la consommation d'un MCU est de le faire fonctionner à la plus basse fréquence que permet l'utilisation qu'on veut en faire. J'ai donc vérifier la consommation électrique du circuit à différentes fréquences et voltages. Voici le tableau des mesures obtenues:

Fosc	courant (Vdd=3.3V)	courant (Vdd=5V)	commentaire
9.6Mhz	7,00mA	14,68mA	sans désactivation périphériques
9.6Mhz	6,92mA	14,41mA	avec désactivation périphériques
4.8Mhz	6,11mA	13.21mA
2.4Mhz	5,37mA	11,9mA
1.4Mhz	5,03mA	11,3mA

Au lignes 345 et 346 je désactive les comparateurs analogiques et les entrées numériques qui ne sont pas utilisées dans cette application, ce qui permet de réduire à consommation d'à peine 270uA. Le fait est que dans cette application c'est le courant fourni à la LED allumée (il n'y en a jamais plus d'une à la fois) qui domine la consommation électrique. Ce n'est donc pas de cette façon qu'on peut réduire la consommation de façon significative. Par contre on constate que la réduction de la fréquence de l'oscillateur Fosc a plus d'effet ainsi que la réduction du voltage.

Dans ce cas particulié l'intérêt principal du power management est d'éviter que les piles se retrouvent à plat si on oubli d'éteindre le gadget. C'est là qu'entre en jeux les différents modes de mise en sommeil du MCU. Le WDT de l'atTiny13A possède un mode de fonctionnement appellé interrupt mode dans le datasheet. Dans ce mode lorsque la minuterie du watchdog timer expire une routine d'interruption est appellée plutôt que de produise un RESET du MCU. Je me sert donc de cette fonctionnalité. Le diviseur du WDT est programmé à 1024 ce qui donne un délais d'environ 8 secondes. De plus la variable count_down est utilisée pour prolonger ce délais en multiples de 8 secondes. l'ISR décrémente le compteur count_down et lorsque ce compteur arrive à zéro le MCU est mis en mode power down. Dans ce mode il ne consomme pratiquement plus de courant car tous les oscillateurs sont mis à l'arrêt. Mon multimètre indique que la consommation électrique passe de 14ma à 0,01ma (10uA). Je ne me fis pas trop à cette dernière lecture car elle est à la limite de résolution de mon multimètre. La consommation en mode power down avec une alimentation de 5 volts est probablement inférieur à 10uA et si le circuit était alimenté en 3 volt serait moindre.

Dans la procédure main il y a 2 boucles while (1) imbriquées. Dans le cycle de la boucle intérieure le WDT est réinitialisé ainsi que la variable count_down. Si les joueurs sont inactifs plus de 16 secondes la variable count_down tombe à zéro et le MCU est mis en mode power down. Le bouton RESET joue le rôle de power on et redémarre le MCU en mode normal.

Introduction aux MCU atTiny, partie 6

Travailler sous GNU/Linux

Dans cette chronique on va configurer les outils pour travailler avec les MCU AVR sous GNU/Linux. La version GNU/Linux que j'utilise est Ubuntu 12.04 mais ces instructions devraient-être valables sous d'autres distributions, considérant que beaucoup sont dérivées d'Ubuntu (Mint, Kubuntu, Xubuntu, etc).

L'installation est simple et rapide. Il suffit d'installer les 5 paquets suivants:

1. gcc-avr, le compilateur 'C'
2. binutils-avr, groupe de programmes utilitaires qui s'intallent dans /usr/bin et dont le nom commence par avr-.
3. avr-libc, librairie de macros et fonctions de bases.
4. avrdude, le logiciel qui contrôle le programmeur.
5. geany, editeur de texte et plus (IDE), (optionel)

Vous pouvez utilisez le gestionnaire de paquets graphique mais personnellement je préfère utiliser apt-get, faire <CTRL>+<ALT>+<T> pour ouvrir la console de commandes. Les commandes sont les suivantes:
sudo su - apt-get install gcc-avr binutils-avr avr-libc avrdude geany usermod -aG dialout user_name exit

Vous devez être membre du groupe dialout pour qu'avrdude soit capable d'ouvrir le port du programmeur. user_name est votre nom de login.
Il n'y a pas de pilote à installer pour le programmeur Pololu. Ce dernier utilise le pilote cdc_acm qui vient avec le noyaux Linux. Lorsque vous brancherez le programmeur Pololu, 2 nouveaux périphériques /dev/ttyACM? apparaîtront. S'il n'y avait pas ce type de périphérique avant que vous ne branchiez le programmeur Pololu alors les nouveaux seront /dev/ttyACM0 pour le programmeur et /dev/ttyACM1 pour le port sériel de configuration du programmeur.

Geany

Personnellement j'utilise geany comme éditeur car il permet de compiler et programmer l'atTiny en 1 seule opération sans sortir de l'éditeur. On peut donc dire que c'est plus qu'un éditeur, c'est un IDE au même titre que Atmel studio. La syntaxe est colorée, la liste des fonctions et des macros apparait dans une fenêtre et on peut s'y rendre simplement en double-cliquant sur le nom. Comme dans Atmel studio, le résultat de la compilation apparaît dans une autre fenêtre en bas de l'éditeur. Lorsqu'un saisie le nom d'un symbole une liste de choix apparait comme dans Atmel studio. Il existe peut-être d'autres IDE qui travaillent aussi bien que celui-ci, je n'ai pas fait de recherche à ce sujet.

Compilation et programmation

Il faut créer un fichier Makefile pour le projet et le placer dans le répertoire du projet.
CC=/usr/bin/avr-gcc TINY=13 CFLAGS=-g -Os -Wall -mcall-prologues -mmcu=attiny$(TINY) OBJ2HEX=/usr/bin/avr-objcopy PROG=/usr/bin/avrdude TARGET=BlinkLED program : $(TARGET).hex $(PROG) -c avrispv2 -p t$(TINY) -P /dev/ttyACM0 -e $(PROG) -c avrispv2 -p t$(TINY) -P /dev/ttyACM0 -U flash:w:$(TARGET).hex %.obj : %.o $(CC) $(CFLAGS) $< -o $@ %.hex : %.obj $(OBJ2HEX) -R .eeprom -O ihex $< $@ clean : rm -f *.hex *.obj *.o
Si vous ne connaissez pas l'utilitaire make il faudrait l'étudier un mininum en commencant par la page man make. Pour vous simplifier la vie vous pouvez utiliser l'exemple çi-haut et simplement modifier les paramètres spécifique à votre projet. TINY est le numéro de modèle de MCU utilisé ici 13 (valide aussi pour 13a). TARGET est le nom du fichier 'C' à compiler sans l'extension, ici BLinkLED. Chaque fois que $(symbole) apparaît dans le texte une substitution est effectuée, par exemple ici -mmcu=attiny$(TINY) devient -mmcu=attiny13.

Pour compiler et flasher le MCU à partir de geany allez dans le menu construire (icône bloc de béton rouge) et choississez l'item Make all. Le résultat de l'opération s'affiche dans la fenêtre du bas. S'il n'y a pas d'erreur de compilation avrdude sera lancé automatiquement et le MCU programmé.
Voici le programme BlinkLED pour vous exercer.
// F_CPU tells util/delay.h our clock frequency //#define F_CPU 8000000UL // Orangutan frequency (8MHz) #define F_CPU 9600000UL //atTiny13A frequency (9.6MHz) #include <avr/io.h> #include <util/delay.h> void delayms( uint16_t millis ) { while ( millis ) { _delay_ms( 1 ); millis--; } } int main( void ) { DDRB |= 1 << PB1; // set LED pin PD1 to output while ( 1 ) { PORTB &= ~( 1 << PB1 ); // LED off delayms( 900 ); // delay 900 ms PORTB |= 1 << PB1; // LED on delayms( 100 ); // delay 100 ms } return 0; }

Pour conclure lorsque vous branchez le programmeur Pololu dans le port USB et qu'il est relié correctement au MCU et que malgré tout la lumière rouge du programmeur clignote, ça peut vouloir dire que vous n'avez pas les droits d'ouverture du périphérique /dev/ttyACM0. Vous pouvez lancer quand même Make all et avrdude va afficher un message d'erreur s'il ne peut ouvrir le port. Si votre distribution GNU/Linux est Ubuntu ou un dérivé assurez-vous d'être membre du groupe dialout. Vous pouvez obtenir la liste de vos appartenances avec la commande groups dans la console de commandes. Je ne saurais dire si c'est le même groupe pour les autres distros. Réouvrez votre session après vous être ajouté au groupe dialout

carte de voeux musicale

De nos jours les cartes de voeux musicales sont virtuelles, on les envoie via internet. Mais il y a un certain nombres d'années, je ne sais pas si ça existe encore ou si ça a été une passade, on pouvait acheter une carte de voeux qui jouait de la musique lorsqu'on l'ouvrait.

Voici un projet qui démontre toute la simplicité de ce type de gadget. Il s'agit de créer le circuit d'une telle carte de voeux. Pour le développement on utilise un PIC10F200 en format PDIP-8. Mais s'il nous prenais la fantaisie d'assembler réellement une telle carte il suffirait d'acheter un PIC au format DFN, 1 piézo et une pile au lithium CR2012. Le piezo speaker constitue l'élément le plus mince et la pile avec 1,2mm d'épaisseur le plus épais. C'est 3 éléments montés à plat s'insèreraient dans une carte de voeux sans que se soit trop apparent. Il s'agirait en plus de bricoler un commutateur plat qui mettrait la pile en contact avec l'alimentation du MCU seulement au moment de l'ouverture de la carte. Si vous avez le désir de fabriquer une telle carte je laisse au soins de votre imagination de défi de créer un tel commutateur.

matériel requis

• 1 MCU PIC10F200, 0,62$CAN
• 1 piezo speaker, 6,15$CAN
• 1 pile CR2012, 1,29$CAN

circuit

code source

; NOM: carte-de-voeux-musicale.asm ; DESCRIPTION: reproduction des cartes de voeux musicale vendu commercialement. ; ne nécessitive que 3 éléments: ; 1 PIC10(L)F200 ; 1 piézo speaker ; 1 pile CR2012 ; De plus il faut fabriquer un contact qui va brancher la pile au ; MCU lorsque la carte est ouverte. ; Le MCU joue à ce moment "happy birthday" et tombe ensuite mode ; sleep. ;AUTEUR: Jacqes Deschênes ;DATE: 2013-01-15 ;REF: gamme tempérée: http://davbucci.chez-alice.fr/index.php?argument=musica/scala/scala.inc ;REF: happy birthday: http://en.wikipedia.org/wiki/File:GoodMorningToAll.svg #include P10F202.INC __config _WDTE_OFF & _MCLRE_OFF ;;;;;;;;;;;; constantes ;;;;;;;;;; ;durées notes WHOLE_NOTE EQU 0 HALF_NOTE EQU 1 QUARTER_NOTE EQU 2 HEIGHT_NOTE EQU 3 SIXTEENTH EQU 4 PAUSE_BIT EQU 7 ;;;;;;;;;;;; macros ;;;;;;;;;;;;;; #define AUDIO_P GP0 #define AUDIO GPIO, AUDIO_P audio_hi macro ; met la broche audio au niveau 1 bsf AUDIO endm audio_lo macro ; met la broche audio au niveau 0 bcf AUDIO endm enable_audio macro ; met la broche audio en mode sortie movlw H'FF' - (1<<AUDIO_P) tris GPIO endm disable_audio macro ; met la broche audio en haute impédance (mode entrée) movlw H'FF' tris GPIO endm delay_half_cycle macro ; délais demi-cycle pour générer une note comf freq_dly, W addwf TMR0 movfw TMR0 skpz goto $-2 endm skip_timeout macro ; délais durée de la note movfw freq_dly subwf delay_cntr, F skpnc goto $+7 movlw 1 subwf delay_cntr+1, F skpnc goto $+3 subwf delay_cntr+2, F skpnc endm ;;;;;;;;;;;; variables ;;;;;;;;;;;; udata delay_cntr res 3 ; compteur pour délais durée notes freq_dly res 1 ; délais demi-cycle pour produire la fréquence x note_idx res 1 ; index de la note dans la table melody temp res 2 ; registres de travail temporaire rst_vector org 0 clrf OSCCAL nop goto init scale ; table des notes échelle tempérée addwf PCL, F dt .239 ;do4 dt .225 ;do#4 dt .212 ;ré4 dt .201 ;ré#4 dt .189 ;mi4 dt .179 ;fa4 dt .169 ;fa#4 dt .159 ;sol4 dt .150 ;sol#4 dt .142 ;la4 dt .134 ;la#4 dt .126 ;si4 dt .119 ;do5 dt .112 ;do#5 dt .106 ;ré5 dt H'FE' ; pause duration ; table des durées en multiple de 8 microsecondes addwf PCL, F dt low .62500, high .62500, 0 ; WHOLE_NOTE dt low .93750, high .93750, upper .93750; WHOLE_NOTE. dt low .31250, high .31250, 0 ; HALF_NOTE dt low .46875, high .46875, 0 ; HALF_NOTE. dt low .15625, high .15625,0 ; QUARTER_NOTE dt low .23437, high .23437, 0 ; QUARTER_NOTE. dt low .7812, high .7812,0 ; HIEGTH_NOTE dt low .11718, high .11718, 0 ; HEIGTH_NOTE. dt low .3906, high .3906, 0 ; SIXTHEENTH_NOTE. dt low .5859, high .5859, 0 ; SXTHEENTH_NOTE. melody ; table de la mélodie 'happy birthday' ; bits 0-3 index de la note dans la table 'scale', 15=pause ; bits 4-6 index de la durée de la note dans la table 'duration' addwf PCL, F dt .82 dt .98 dt .20 dt .18 dt .23 dt .5 dt .82 dt .98 dt .20 dt .18 dt .25 dt .7 dt .82 dt .98 dt .30 dt .27 dt .23 dt .21 dt .20 dt .92 dt .108 dt .27 dt .23 dt .25 dt .7 dt H'FF' play_note ; joue une note ; note dans W ; bits 0-3 index de la note dans la table 'scale', 15=pause ; bits 4-6 index de la durée de la note dans la table 'duration' movwf temp movwf temp+1 swapf temp, F ; durée dans le low nibble movlw H'F' andwf temp, F ; ne garde que le low nibble bcf STATUS, C ; multiplication par 3 rlf temp, W addwf temp, F movfw temp call duration movwf delay_cntr ; octet faible incf temp,F movfw temp call duration movwf delay_cntr+1 ;octet intermédiaire incf temp, W call duration movwf delay_cntr+2 ; octet fort enable_audio movlw H'F' andwf temp+1, F xorwf temp+1, W skpz goto play_note01 disable_audio ; c'est une pause play_note01 movfw temp+1 call scale movwf freq_dly ; délais en multiple de 4usec. play_note02 audio_hi delay_half_cycle audio_lo delay_half_cycle skip_timeout goto play_note02 retlw 0 init ; timer clk=Fosc/4, diviseur=4 movlw H'FF' -(1<<T0CS) -(1<<PSA) -(1<<PS1) -(1<<PS2) option clrf note_idx main movfw note_idx call melody xorlw H'FF' ; marque la fin de la mélodie skpnz goto main02 xorlw H'FF' call play_note incf note_idx, F movlw .4*.16+.15 call play_note ; brève pause entre les notes goto main main02 sleep ; terminé met le MCU en mode sleep pour ménager la pile. goto $ end
Le code occupe 127 instructions, même pas la moitié du maigre 256 instructions de ce MCU. Il reste de la place pour ajouter 128 notes à la mélodie...

Le TIMER est configuré pour être contrôlé par Fosc/4 avec un diviseur de 4 ce qui donne 4usec par tick. Les valeurs de la table scale sont donc les valeurs représentant la durée d'un demi-cycle pour chaque fréquence en multiple de 4usec. Les valeurs ont été calculée à l'aide du tableur d'openOffice et arrondi à l'entier le plus proche.

Pour la durée de la note il a fallu prendre un compteur 24 bits même si les valeurs de la table duration sont elle calculée en multiple de 8usec, la première valeur étant de 125000. 8usec parce qu'on ne soustrait qu'une seule fois la valeur de freq_dly à delay_cntr par cycle alors que freq_dly est compter 2 fois par cycle.

Notez que la macro delay_half_cycle réinitialise le timer en ajoutant la valeur freq_dly à la valeur qui est déjà dans le compteur plutôt que par une assignation. Ceci est pour tenir compte du fait que le temps continue à s'écouler entre le moment ou 1 demi-cycle se termine et ou on réinitialise le timer pour le demi-cycle suivant. Ceci cré une onde parfaitement carré malgré le temps d'exécution supplémentaire encouru à la fin du 2ième demi-cycle par l'exécution de la macro skip_timeout et du plus la fréquence est plus juste.

Il n'y a pas grand chose à ajouter à propos de ce code qui est en définitive des plus simple dans sa réalisation.

Introduction aux MCU ATtiny, partie 5

configuration Atmel studio

En lisant le manuel du programmeur Pololu, j'ai découvert comment compiler et programmer avec la seule touche F5. Dans le menu view, cliquez l'item Available Atmel tools. Dans cette liste à part le simulateur il ne doit y avoir qu'un seul programmeur STK500, celui qui correspond à votre USB AVR Pololu. Ensuite chaque fois que vous créez un projet il faut aller dans les propriétés du projet dans l'onglet tools et s'assurer que ce programmeur est sélectionné pour la progammation.

A partir de là chaque fois qu'on presse la touche F5 le projet et compilé et le MCU est programmé.

Lien AVR libc

voici le lien vers la page du projet AVR libc. Très utile, toute la documentation est là.

Conversion numérique/analogique par PWM

Ajourd'hui on va voir comment créer et lire une table de données en mémoire flash et comment synthétiser une onde sinusoïdale en utilisant le périphérique PWM. Le circuit utilisé est le suivant.

R1, R2, C2 et C3 forme un filtre passe bas avec une fréquence de coupure à 5Khz et une pente de 12db/octave. La résistance R3 doit-être d'au moins 10 fois la valeur de R2 pour ne pas charger le filtre. La sortie peut alimenter l'amplicateur utitilisé en partie 4.

Code source, version 1

/* * intro_ATtiny_adc_dac.c * * Created: 2013-01-11 11:36:12 * Author: Jacques * introduction ATtiny, partie 5 * conversion analogique/numérique et numérique/analogique * La conversion N/A se fait par PWM. * * REF: http://www.nongnu.org/avr-libc/ */ #define F_CPU 9600000UL #include <avr/io.h> #include <avr/interrupt.h> #include <avr/pgmspace.h> #include <avr/delay.h> #define AUDIO PORTB1 #define POT PORTB4 #define TABLE_SIZE 180 const uint8_t sine_table[] PROGMEM ={ // table de sinus, 180 échantillons 8 bits non signé. 128, 132, 136, 141, 145, 150, 154, 158, 163, 167, 171, 175, 179, 183, 187, 191, 195, 199, 202, 206, 209, 212, 216, 219, 222, 225, 228, 230, 233, 235, 237, 240, 242, 244, 245, 247, 248, 250, 251, 252, 253, 253, 254, 254, 254, 255, 254, 254, 254, 253, 253, 252, 251, 250, 248, 247, 245, 244, 242, 240, 237, 235, 233, 230, 228, 225, 222, 219, 216, 212, 209, 206, 202, 199, 195, 191, 187, 183, 179, 175, 171, 167, 163, 158, 154, 150, 145, 141, 136, 132, 128, 123, 119, 114, 110, 105, 101, 97, 92, 88, 84, 80, 76, 72, 68, 64, 60, 56, 53, 49, 46, 43, 39, 36, 33, 30, 27, 25, 22, 20, 18, 15, 13, 11, 10, 8, 7, 5, 4, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 2, 2, 3, 4, 5, 7, 8, 10, 11, 13, 15, 18, 20, 22, 25, 27, 30, 33, 36, 39, 43, 46, 49, 53, 56, 60, 64, 68, 72, 76, 80, 84, 88, 92, 97, 101, 105, 110, 114, 119, 123 }; uint8_t pas=1; uint8_t indice=0; ISR(TIM0_COMPB_vect){ OCR0B=pgm_read_byte(&(sine_table[indice])); indice += pas; if (indice>179) indice -= 180; } int main(void) { CLKPR= (1<<CLKPCE); // permet la modification du pre-scale CLKPR = 0 ; // pas de division. Le MCU fonctionne à la fréquence 9,6Mhz. DDRB |= (1<<AUDIO); // sortie audio TCCR0A = ((1<<COM0B1) | (1<<WGM00) | (1<<WGM01)); // FAST_PWM 3 sur sortie audio TCCR0B = (1<<CS00); // pas de diviseur sur CLKtn sei(); // activation interruptions TIMSK0 |= (1<<OCIE0B); // activation interruption sur output compare B while(1) { } } Le code est simple il suffit d'initaliser le périphérique PWM et de créer une ISR qui est déclenchée lorsque TCNT0 atteint la valeur du comparateur OCR0B. Cette ISR met le prochain échantillon de la table sine_table dans OCR0B et incrémente l'indice pour la prochaine valeur. Le programme utilise la variable pas plutôt qu'une constante pour incrémenter indice afin de pouvoir modifier la valeur de pas à l'exécution dans le but de changer la fréquence. Le programme utilise la canal PWM B dont la sortie est sur la broche 6. Le compteur TCNT0 est configuré pour fonctionner à la fréquence de 37500Hz, mode FAST PWM 3. Cette fréquence est la fréquence d'échantillonnage du convertisseur numérique/analogique.

Voyons ça plus en détail. le fichier pgmspace.h contient les macros nécessaire à la création de tables dans la mémoire programme et à leur utilisation. la macro PROGMEM informe le compilateur que les données qui suivent doivent-être enregistrées en mémoire programme plutôt qu'en RAM. La table sine_table est la valeur des échantillons pour recréer une onde sinusoïdale. Il y a 180 échantillons, donc 1 à tous les 2 degrés du cycle. Si on regarde la routine ISR on voit que pour lire le contenu de la table il faut utiliser la macro pgm_read_byte qui prend en argument l'adresse de sine_table[indice]. Si on écrivais simplement OCR0B=sine_table[indice] le compilateur compilerais le code comme si la table se trouverais en RAM et évidemment ça ne fonctionnerais pas.

Dans la fonction main il ne se passe rien à part les initialisations nécessaires. Tout le travail est fait par le périphérique PWM et l'ISR.

Donc la table est lue en boucle pour produire une onde sinusoïdale dont la fréquence est Fo=pas*(Fpwm/Ne)
où
Fo est la fréquence de l'onde sinusoïdale
Fpwm est la fréquence d'échantillonnage dans ce cas si 37500Hz
pas est la valeur d'incrément pour l'indice accédant la table.
Ne est le nombre d'échantillons dans la table ici 180.

pour pas=1 on a donc Fo=Fpwm/180=208Hz, en mettant pas=2 on double la fréquence et ainsi de suite. En théorie le pas maximal est de 90, mais bien avant d'atteindre cette valeur le procédé de numérisation produit un niveau de distortion inacceptable avec des sous-harmoniques.

On comprend qu'en augmentant le pas on réduit le nombre d'échantillons utilisés pour recréer l'onde sinuoïdale donc la distortion augmente. On peut le voir sur les captures d'écran oscilloscope suivantes:
Pour pas=1

pour pas=10

On voit bien que le sinuoïde est déformé.

Optimisation

Au départ j'avais écris l'ISR comme ceci: ISR(TIM0_COMPB_vect){ OCR0B=pgm_read_byte(&(sine_table[indice])); indice = (indice+pas) % 180; }
Mais il s'est avéré que la sous-routine de l'opérateur '%' prenais 100 octets de plus, le code faisant 456 octets au lieu de 356. Sans oublier le temps d'exécution supplémentaire. Il y a une contrainte sur le temps d'exécution de l'ISR. Ce temps doit-être inférieur à la durée d'une période PWM.

la variante suivante prend 362 octets:
ISR(TIM0_COMPB_vect){ OCR0B=pgm_read_byte(&(sine_table[indice])); indice = indice<179?indice+pas:180-indice-pas; }
Notez que lorsque l'indice dépasse 179 je ne le ramène pas à zéro mais à la valeur de dépassement. En principe lorsqu'on numérise, l'échantilloneur n'est pas synchronisé sur le début du cycle. En pratique, j'ai essayé l'autre façon de faire et ça ne semble pas avoir d'influence significative sur le signal en sortie. Donc dans la version suivante chaque cycle est resynchronisé sur le début de la table.

Code source, version 2

Il n'est pas nécessaire que le pas soit un entier. Évidemment il faut que le tableau soit indexé par un entier mais un pas fractionnaire signifie simplement qu'au lieu d'avancer à vitesse régulière dans la table on progresse de façon irrégulière. on pourrait écrire le code de l'ISR comme suis:
float somme=0, pas=0.35; uint8_t indice=0; ISR(TIM0_COMPB_vect){ OCR0B=pgm_read_byte(&(sine_table[indice])); somme += pas; indice += (int)(somme); if (indice>179){ indice=0; somme=0; } }

On pourrait penser que cette avance irrégulière va créé de la distortion mais celle-ci est constituée d'éléments haute-fréquence que le filtre passe-bas élimine en grande partie. Le problème avec cette sous-routine viens plutôt de l'utilisation du type float. Sur un petit MCU comme le ATtiny13A, le coût aussi bien en terme d'espace programme utilisé qu'en terme de vitesse d'exécution serait prohibitif. Il faut se contenter de travailler avec des entiers et utiliser des multiplications et divisions qui sont des puissances de 2. C'est tout à fait possible comme nous allons le voir dans la version suivante du code source.

Dans cette version un potentiomètre est utilisé pour contrôler la fréquence de sortie du sinuoïde. Le voltage du potentiomètre est lu à toutes les 20 msec et la valeur du convertisseur est utilisée comme valeur de pas.
/* * intro_ATtiny_adc_dac.c * * Created: 2013-01-11 11:36:12 * Author: Jacques * introduction ATtiny, partie 5 * conversion analogique/numérique et numérique/analogique * La conversion N/A se fait par PWM. * le voltage d'un potentiomètre branché sur l'entrée ADC3 est utilisé pour contrôler la fréquence du signal de sortie. * * REF: http://www.nongnu.org/avr-libc/ */ #define F_CPU 9600000UL #include <avr/io.h> #include <avr/interrupt.h> #include <avr/pgmspace.h> #include <avr/delay.h> #define AUDIO PORTB1 #define POT PORTB4 #define TABLE_SIZE 180 const uint8_t sine_table[] PROGMEM ={ // table de sinus, 180 échantillons 8 bits non signé. 128, 132, 136, 141, 145, 150, 154, 158, 163, 167, 171, 175, 179, 183, 187, 191, 195, 199, 202, 206, 209, 212, 216, 219, 222, 225, 228, 230, 233, 235, 237, 240, 242, 244, 245, 247, 248, 250, 251, 252, 253, 253, 254, 254, 254, 255, 254, 254, 254, 253, 253, 252, 251, 250, 248, 247, 245, 244, 242, 240, 237, 235, 233, 230, 228, 225, 222, 219, 216, 212, 209, 206, 202, 199, 195, 191, 187, 183, 179, 175, 171, 167, 163, 158, 154, 150, 145, 141, 136, 132, 128, 123, 119, 114, 110, 105, 101, 97, 92, 88, 84, 80, 76, 72, 68, 64, 60, 56, 53, 49, 46, 43, 39, 36, 33, 30, 27, 25, 22, 20, 18, 15, 13, 11, 10, 8, 7, 5, 4, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 2, 2, 3, 4, 5, 7, 8, 10, 11, 13, 15, 18, 20, 22, 25, 27, 30, 33, 36, 39, 43, 46, 49, 53, 56, 60, 64, 68, 72, 76, 80, 84, 88, 92, 97, 101, 105, 110, 114, 119, 123 }; volatile unsigned int delais=0; unsigned int pas=256, somme=0; uint8_t indice=0; ISR(TIM0_COMPB_vect){ OCR0B=pgm_read_byte(&(sine_table[indice])); somme += pas; indice = ((somme>>8)+((somme>>7) & 1)); if (indice>179){ indice = 0; somme = 0; // 180*256 } if (delais) delais--; } int main(void) { CLKPR= (1<<CLKPCE); // permet la modification du pre-scale CLKPR = 0 ; // pas de division. Le MCU fonctionne à la fréquence 9,6Mhz. //OSCCAL+=3 ; //optionel calibration fine des fréquences. DDRB |= (1<<AUDIO); // sortie audio TCCR0A = ((1<<COM0B1) | (1<<WGM00) | (1<<WGM01)); // FAST_PWM 3 sur sortie audio TCCR0B = (1<<CS00); // pas de diviseur sur CLKtn sei(); // activation interruptions TIMSK0 |= (1<<OCIE0B); // activation interruption sur output compare B ADMUX=3; // convertion analogue/numérique sur canal 3 Vref=Vcc ADCSRA = (1<<ADEN) | 7 ; // activation du convertisseur, CLKadc=CLKcpu/128 while(1) { ADCSRA |= 1<<ADSC; // débute une conversion; while (ADCSRA & (1<<ADSC)); // attend la find de la conversion. pas = 12 + ADCL + (ADCH<<8); /* la lecture du potentiomètre détermine la fréquence du convertisseur numérique/analogique PWM */ delais=750; while (delais); // délais de 20msec entre chaque lecture. } }
l'initialisation du convertisseur A/N est simple. Le canal est sélection dans le regsitre ADMUX, le diviseur pour le signal d'horloge est sélectionné dans ADCSRA. J'ai utilisé le plus gros diviseur (128). Et pour activer le convertisseur il faut mettre le bit ADEN dans ADCSRA à 1.

Dans la boucle while (1) la lecture du potentiomètre est démarrée en mettant à 1 le bit ADSC dans le registre ADCSRA. On surveille ce bit qui retombe à zéro lorsque la conversion est complétée. Le résultat se retrouve dans les registes ADCH et ADCL. je copie simplement cette valeur dans la variable pas en ajoutant 12 à ADCL pour une fréquence minimale de 10Hz, tandis que la fréquence maximale est d'environ 850Hz.

Observez comment le délais est créé entre chaque lecture du potentiomètre. On utilise le fait que l'ISR est déclenchée à intervalle régulier pour compter le temps. Dans la boucle while (1) on initialise la variable delais à 750 et on attends qu'elle revienne à zéro. Si on examine l'ISR on voit qu'à la fin si delais est plus grand que zéro sa valeur est décrémentée. l'ISR est déclenchée 37500 fois par seconde donc pour obtenir un délais de 20 msec, delais=.02*37500=750.

Notez que la classe de la variable delais est volatile. Si on ne la définie pas comme volatile. le compilateur va considéré que cette variable n'est jamais modifiée et donc va compiler while (delais); comme si c'était une boucle infinie. En effet comme cette variable est initialisée à 750 juste avant la boucle et n'est pas modififiée à l'intérieure de celle-ci, le compilateur optimise le code en considérant qu'il s'agit d'une boucle infinie et compile la seule instrcution rjump .-4. la classe volatile informe le compilateur que cette variable peut-être modifiée par une prodécure qui s'exécute en dehors du flux normal du programme (ISR) et ne la considère plus comme constante.

Si vous lisez les 2 versions du code, vous constaterez une différence au niveau de l'ISR et de la variable pas. Dans la première version pas était de type uint8_t et dans la seconde est de type unsigned int. De plus la variable somme aussi de type unsigned int a été ajoutée. A l'intérieur de l'ISR la valeur haute de somme est utilisée pour initialiser indice, Ce qui revient à une division entière de somme par 256.

Vous vous demandez peut-être quel est la raison d'être de ce changement. En fait c'est une façon d'éviter d'avoir à faire des calculs en virgule flottante, tout en préservant la partie fractionnaire de pas. /p>

Voyons ça en détail.
pas = Fo*180*256/37500
Fo est la fréquence du sinusoïde.
180 est le nombre d'échantillons dans la table.
37500 est la fréquence d'échantillonage du PWM.
La multiplication par 256 permet de conserver la fraction qui serait autrement perdue.
Mais l'indice d'accès à la table lui est un entier variant de 0 à 179. Au lieu d'incrémenter l'indice directement avec pas. On additionne pas à somme et on ne garde que le l'octet fort de la somme (arrondi à l'entier le plus prêt) pour indicer le tableau. Ce qui revient à dire: indice = (int)((somme+128)/256). On a multiplié pas par 256 mais on redivise par 256 pour créer l'indice. Ainsi l'indice n'est incrémenté que lorsque l'addition de pas à somme produit un débordement dans l'octet fort de somme. L'octet fort se trouve à être la partie entière et l'octet faible la partie fractionnaire.

Conclusion

Si l'ATtiny13a possédait suffisamment de mémoire on pourrait lui faire jouer des fichiers WAV encodés en 8 bits non signés avec une fréquence d'échantillonage de 11025Hz. Mais comme il en manque on pourrait lui en donner en utilisant une eeprom à interface sérielle comme j'ai fait avec le PIC10F322 et une eeprom 24LC512 dans mon projet sonnette. Le PIC10F322 a un avantage cependant sur l'ATtiny13A. Son PWM a un résolution de 10 Bits au lieu de 8, ce qui m'a permis d'ajuster la fréquence pwm pour qu'elle concorde avec la fréquence du fichier WAV que j'ai utilisé. L'ATtiny13A a un autre mode FAST PWM, le mode 7. Dans le mode 7 OCR0A est utilisé comme limite supérieur pour le compteur TCNT0. C'est à dire que lorsque le compte dans TCNT0 atteint la valeur de OCR0A il retombe à zéro au lieu de continuer jusqu'à 255. Pour produite du PWM dans ce mode il faut utilisé le canal B. Ça permet d'ajuster la fréquence PWM mais la conséquence est que la résolution PWM diminue d'autant. Comme la résolution du PWM de l'ATtiny n'est que de 8 bits, si on veut jouer des fichiers WAV 8 bits il n'y a pas de jeux pour diminuer la résolution contrairement au PIC10F322. La seule autre façon d'ajuster la fréquence PWM sans perdre de résolution est de modifier la fréquence de l'oscillateur interne du MCU en modifiant la valeur dans le registre OSCCAL.

Dans cette série, je crois avoir présenté l'essentiel pour une introduction aux MCU ATtiny. Si vous avez lu cette série et bien compris vous devriez être en mesure maintenant de créer vos propre projets utilisant la famille de MCU ATtiny.

introduction aux MCU ATtiny, partie 4

Aujourd'hui je me suis un peut amusé dans l'électronique analogique car j'ai décidé que j'avais besoin d'un petit ampli audio pour la suite de ces chroniques car en plus d'une pulsation 3Hz j'ai ajouter une alarme audio double tonalité pour accompagner cette alarme visuelle. Voici le schéma de l'ampli.

L'entrée de l'ampli est branché sur la broche PORTB1. Même avec la résistance de 22K à l'entrée le son est suffisamment fort pour être entendu à la grandeur de la maison.

Interruption

L'un des concepts important de la programmation système et qu'il faut apprendre très tôt est celui d'interruption et c'est ce que nous allons étudier dans cette chronique.

Les micro-contrôleurs doivent répondrent à des événements extérieurs qui ne sont pas synchronisés avec leur horloge interne, donc qui peuvent survenir à n'importe quel moment dans l'exécution du programme. Il y a deux façon de répondre à ces événements, la première consiste à lire à intervalle régulier les entrées pour savoir quand l'une d'elle a changé d'état. C'est ce que fait la routine attend_pression_bouton présenté dans les chroniques précédentes. Mais cette façon de faire n'est pas très pratique pour plusieurs raisons. Premièrement elle demande beaucoup de temps CPU, temps pendant lequel les autres tâches sont misent en attendent. Si l'événement externe requiert une réponse rapide il faut vérifier l'entrée le plus fréquemment possible ce qui diminu d'autant le temps disponible pour les autres tâches. Cette technique dites de poling n'est vraiment pas efficace. Dans nos exemples précédent ça n'avait pas d'importance puisque le MCU n'avait aucune tâche à accomplir en attendant que le bouton soit enfoncé. Mais le plus souvent le MCU a plusieurs tâches concurrentes à accomplir et doit partager son temps le plus efficacement entre celles-ci.

C'est dans ces situations qu'on a besoin des interruptions. Une interruption comme son nom l'indique est un mécanisme par lequel le déroulement d'un programme est interrompu pour répondre à un événement qui s'est produit. Les sources d'interruptions peuvent-être interne ou externe. Par exemple une minuterie interne au MCU peut déclencher une interruption lorsqu'elle expire. Mais une interruption peut aussi être déclenchée lorsqu'une broche d'entrée a changée d'état, il s'agit alors d'un événement externe.

Dans un cas comme dans l'autre le MCU doit interrompre ce qu'il est en train de faire pour réponde à l'interruption. Les interruptions sont répondues par des routines spécifiques qui ne s'éxécutent pas dans le déroulement normal du programme mais seulement lorsqu'un événement qui les concernes c'est produit. On les appelle sans surprise les routines de service d'interruption, en anglais interrupt service routine, abrégé ISR.

Donc une interruption se produit et le MCU interrompt l'exécution normmale du programme. Mais ça ne peut se faire n'importe comment. D'abord il faut converser la valeur du pointeur d'instruction car lorsque l'ISR sera répondue il faudra revenir à l'endroit où le programme était rendu avant l'interruption. De plus tous les registres utilisés par la routine d'interruption doivent-être préservés. Toutes ces donnés sont conservées sur la pile. La même pile qui est utlisée pour conserver les adresses de retour lorqu'une qu'une sous-routine est appellée.

Ce n'est pas tout, le MCU doit savoir où se trouve la routine qui sert tel ou tel interruption. C'est le rôle de la table des vecteurs d'interruptions. Pour les MCU ATtiny cette table se trouve à l'adresse zéro de la mémoire programme. Chaque source d'interruption a un numéro qui correspond à un index dans cette table. Et le vecteur lui-même dans cette table est simplement une instruction de saut vers l'ISR requise. Pour le code d'aujourd'hui j'ai créé une ISR pour répondre au débordement du compteur TCNT0. Chaque fois que ce compteur retombe de 255 à 0 l'interruption no. 3 est déclenchée. voici de quoi à l'air la table des vecteurs et le code assembleur de la routine ISR.
00000000 <__vectors>: 0: 09 c0 rjmp .+18 ; 0x14 <__ctors_end> 2: 21 c0 rjmp .+66 ; 0x46 <__bad_interrupt> 4: 20 c0 rjmp .+64 ; 0x46 <__bad_interrupt> 6: 2b c0 rjmp .+86 ; 0x5e <__vector_3> 8: 1e c0 rjmp .+60 ; 0x46 <__bad_interrupt> a: 1d c0 rjmp .+58 ; 0x46 <__bad_interrupt> c: 1c c0 rjmp .+56 ; 0x46 <__bad_interrupt> e: 1b c0 rjmp .+54 ; 0x46 <__bad_interrupt> 10: 1a c0 rjmp .+52 ; 0x46 <__bad_interrupt> 12: 19 c0 rjmp .+50 ; 0x46 <__bad_interrupt> 0000005e <__vector_3>: 5e: 1f 92 push r1 60: 0f 92 push r0 62: 0f b6 in r0, 0x3f ; 63 64: 0f 92 push r0 66: 11 24 eor r1, r1 68: 8f 93 push r24 6a: 9f 93 push r25 6c: 80 91 60 00 lds r24, 0x0060 70: 91 e0 ldi r25, 0x01 ; 1 72: 89 27 eor r24, r25 74: 80 93 60 00 sts 0x0060, r24 78: 9f 91 pop r25 7a: 8f 91 pop r24 7c: 0f 90 pop r0 7e: 0f be out 0x3f, r0 ; 63 80: 0f 90 pop r0 82: 1f 90 pop r1 84: 18 95 reti
Comme on peut le voir l'entrée 3 de la table contient une instruction rjmp .+86 qui conduit à l'adresse effective 0x5e qui est le début de l'ISR pour l'overflow du timer0, c'est à dire du compteur TCNT0. Si on examine cette routine on constate que les premières instructions push consiste en l'empilement des registres r0 et r1. L'ISR va se servir de ces 2 registres donc elle en préserve le contenu en l'envoyant sur la pile et va les restaurer avant de quitter avec les instructions pop. Cette routine est très longue et pourtant elle ne fait que basculer la valeur d'une variable (adresses 0x6c à 0x74). Il n'y a que 4 instructions pour le code effectif toutes les autres ne servent qu'à préserver et restaurer le contexte du progamme qui a été interrompu.

On va maintenant regarder comment on cré une interruption en 'C'.
/* * Intro_AtTiny.c * * Created: 2013-01-05 22:13:50 * Author: Jacques * Description: introduction aux MCU ATtiny * étape 1: allumer/éteindre un LED avec un bouton momentané. */ #define F_CPU 9600000UL // CPU à la fréquence maximale de l'oscillateur interne soit 9.6Mhz #include <avr/io.h> #include <util/delay.h> #include <avr/interrupt.h> // tout ne peut pas être fait en C alors on utilise des macros avec directive asm #define disable_interrupt asm("cli") #define enable_interrupt asm("sei") #define watchdog_reset asm("wdr") // définition est E/S #define BOUTON PORTB3 // bit 3 du PORTB entrée bouton #define LED PORTB0 // bit 0 du PORTB sortie LED #define AUDIO PORTB1 // bit 1 du PORTB sortie audio // délais pour l'anti-rebond 20msec. #define ANTI_REBOND 20 #define DELAIS_3HZ 1000 // délais tonalités #define TONE_500HZ 62 #define TONE_750HZ 42 #define LED_ETEINT 0 #define LED_MAX 255 // pré-scale pour le timer Fosc/256 #define PS_256 (1<<CS02) #define PS_1024 ((1<<CS02) | (1<<CS00) | (1<<WGM02)) // configuration pour le mode fast pwm 3 #define FAST_PWM3_A ((1<<COM0A1) | (1<<WGM01) | (1<<WGM00)) // configuration pour le mode FAST_PWM2, basculement sortie (toggle) #define FAST_PWM2_A ((1<<COM0A0) | (1<<WGM01) | (1<<WGM00)) //diviseur fréquence Fosc #define FOSC_MAX 0 #define FOSC_600KHZ 4 void WDT_off(void) // emprunté tel quel au datasheet de l'ATtiny13A, j'ai juste remplacé les macros { disable_interrupt; watchdog_reset; /* Clear WDRF in MCUSR */ MCUSR &= ~(1<<WDRF); /* Write logical one to WDCE and WDE */ /* Keep old prescaler setting to prevent unintentional time-out */ WDTCR |= (1<<WDCE) | (1<<WDE); /* Turn off WDT */ WDTCR = 0x00; enable_interrupt; } uint8_t bascule_tone=0; // variable indiquant la fréquence de la tonalité. ISR(TIM0_OVF_vect){ // routine de service pour les interruption sur débordement TCNT0 bascule_tone ^= 1; } int attend_pression_bouton(){ // lecture du bouton avec anti-rebond. Attend que le bouton soit relâché avant de sortir. unsigned int count; count=0; while (count<ANTI_REBOND){ // attend que le bouton soit enfoncé if ((PINB & 1<<BOUTON)==0){ count++; } else{ if (count>0) count--; } _delay_ms(1); } count = 0; while ((count <= DELAIS_3HZ) && ((PINB & 1<<BOUTON)==0)){// attend que le bouton soit relâché count++; _delay_ms(1); } _delay_ms(ANTI_REBOND); return count; } void alarme(){ PORTB|= (1<<AUDIO); if (bascule_tone) _delay_us(TONE_500HZ); else _delay_us(TONE_750HZ); PORTB&=(0XFF - (1<<AUDIO)); if (bascule_tone) _delay_us(TONE_500HZ); else _delay_us(TONE_750HZ); return; } int main(void) { WDT_off(); //désactivation du watch dog timer. enable_interrupt; CLKPR= (1<<CLKPCE); // permet la modification du pre-scale CLKPR = 0 ; // pre-scale mise à zéro. Le MCU fonctionne à la fréquence maximale. DDRB |= (1<<LED | 1<<AUDIO); // met PORTB0 et PORTB1 en sortie DDRB &= (0xFF - (1<<BOUTON)); // met broche BOUTON en entrée PORTB |= (1<<BOUTON); //active le pullup PORTB &= (0xFF - (1<<LED)); // eteint le LED OCR0A=LED_ETEINT; // contrôle de l'intensité de la LED uint8_t rapport_cyclique=0; uint8_t tone_count; unsigned int bouton_enfonce; //combien de msec le bouton est resté enfoncé. while (1) { bouton_enfonce=attend_pression_bouton(); if (bouton_enfonce>=DELAIS_3HZ){ // mode pulsation 3Hz CLKPR=(1<<CLKPCE); CLKPR=FOSC_600KHZ; OCR0A=96; TCCR0A=FAST_PWM2_A; TCCR0B=PS_1024; TIMSK0 |= 1<<TOIE0; // activation de l'interruption sur débordement TCNT0 while (((PINB & 1<<BOUTON)==0)){ alarme(); }; // on attend que le bouton soit relaché _delay_ms(1); // Fosc étant à 600Khz délais * 16 -> 16msec. while (((PINB & 1<<BOUTON)!=0)){ alarme(); }; // sortir de ce mode sitôt que bouton est enfoncé. TIMSK0 &= (0xFF - (1<<TOIE0)); // remettre l'horloge à sa vitesse maximale. CLKPR=(1<<CLKPCE); CLKPR=FOSC_MAX; TCCR0A=0; // désactivation PWM } else{ // mode normal ave contrôle d'intensité if (rapport_cyclique==LED_ETEINT){ rapport_cyclique=LED_MAX; // à ce point ci le PWM est désactivé. PORTB |= 1<<LED; // allume LED pleine intensitée. } else{ rapport_cyclique >>= 1; // diminue l'intensité de moitié. if (rapport_cyclique>15){ OCR0A=rapport_cyclique; TCCR0A=FAST_PWM3_A; // activation PWM TCCR0B=PS_256; } else{ rapport_cyclique=LED_ETEINT; TCCR0A=0; // désactivation PWM TCCR0B=0; PORTB &= (0xFF - (1<<LED)); //éteind LED } } } } } J'ai modifié plusieurs choses par rapport au code d'hier mais on va se concentrer sur la création de la routine de service d'interruption. J'avais besoin de cette routine car lorsque la lumière est en clignotement urgence 3HZ je l'accompagne d'un signal audio double tonalité, 500hz et 750hz. La fréquence bascule en même temps que l'état de la LED. Je devais donc savoir quand la LED change d'état. En mode 3Hz j'ai configuré le PWM en mode bascule. C'est à dire que la sortie change d'état à chaque fois que le comparateur confirme que OCR0A==TCNT0. De plus J'ai configuré le mode 7, c'est à dire que le compteur TCNT0 retombe à zéro en même temps qu'il atteint la valeur de OCR0A. Cette configuration me permet d'obtenir une onde carré à la sortie de PORTB0. Donc lorsque TCNT0 retombe à zéro l'interruption est déclenchée. Cette interruption ne fait que basculer l'indicateur booléen bascule_tone qui est utilisé par la routine alarme() et lui permet de savoir qu'elle fréquence faire entendre.

Si vous regardez au début du code j'ai ajouté la ligne #include <avr/interrupt.h>
Ce fichier défini les macros nécessaires à la création des routines d'interruptions. Plus bas vous apercevez la déclaration de la routine elle-même.
uint8_t bascule_tone=0; // variable indiquant la fréquence de la tonalité. ISR(TIM0_OVF_vect){ // routine de service pour les interruption sur débordement TCNT0 bascule_tone ^= 1; }
La macro ISR sert justement à déclarer les fonctions qui servent de routine de service d'interruption. En argument de la macro on donne un identifiant indiquant de qu'elle interruption il s'agit. Ces identifiants sont définis dans le fichier avr/io.h. Pour voir le contenu d'un fichier inclus, cliquez avec le bouton droit de la souris sur le fichier et choisissez l'item goto implementation dans le menu surgissant.

Comme vous le voyez cette ISR ne fait vraiment pas grand chose. En passant notez que la variable bascule_tone doit-être une variable globale pour être accessible aussi bien par l'ISR que par la fonction alarme().

Autre point à notez dans ce programme, c'est le changement de la fréquence de l'oscillateur système. Pour obtenir une fréquence suffisamment basse pour générer un PWM de 3HZ j'ai du diviser la fréquence de l'oscillateur par 16, ce qui fait que le core du MCU durant le mode alarme fonctionne à 600Khz au lieu de 9,6Mhz. J'en ai tenu compte lorsque j'appelle les fonctions _delay_ms() et _delay_us() en divisant les valeurs de délais par 16. La fréquence de l'oscillateur principal est remise à 9,6Mhz avant de quitter le mode alarme.

Voilà ce sera tout pour cette chronique. Le code prend maintenant 41% de l'espace programme. Et si on ajoutait une nouvelle fonction! Par exemple la lumière pourrait signaler un appel de détresse en envoyant le code morse international S.O.S.: ...---...

Introduction aux MCU ATtiny, partie 3

Un coup d'oeil dans les coulisses

Avant de continuer avec la présentation du code pour aujourd'hui on va d'abord jeter un coup d'oeil dans les coulisses. Atmel Studio et GCC nous rendent la vie plus facile en générant du code supplémentaire pour nous. Pour voir le code généré par GCC il faut ouvrir le fichier listing produit par le compilateur. Heureusement il n'est pas nécessaire de chercher bien loin. Il se trouve dans la fenêtre solution explorer dans output files Double-cliquez dessus pour l'ouvrir.

Pourquoi ce petit programme occupe-t-il 192 octets de flash? Moins de 90 aurait du suffire!. Si on regarde le listing on constate que GCC a initialisé 10 vecteurs d'interruptions. Mais notre programme n'utilise aucune interruption donc notre code pourrait commencé à l'adresse 0. 20 octets perdus.
La routine __ctors_end occupe 8 octets, elle initialise le registre R1 comme générateur de constante avec la valeur '0'. Ensuite elle initialise le pointeur de pile à l'adresse 0x9F. Rien à reprocher à cette procédure sauf qu'elle pourrait-être installée à l'adresse 0x00 plutôt que 0x14.
La routine __do_copy_data copie les variables globales initialisées au début de la mémoire RAM à partir de la mémoire flash. Mais notre programme n'utilise pas de variables globales initialisées. 22 octets perdus.
La routine __do_clear_bss initialise à zéro toutes le reste de la RAM c'est à dire celle qui n'a pas été initialisée par __do_copy_data. Notre programme n'utilise aucune variable RAM, cette routine est donc aussi inutile. 40 octets de perdus.
Pour le reste il n'y a rien à reprocher au code que nous avons écris et qui a été compilé efficacement. Ça fait quand même 82 octets perdus par rapport à ce qu'on aurais obtenu si on avait programmé en assembleur.

Mais c'est le prix à payer pour se rendre la vie plus facile par la programmation en 'C' plutôt qu'en assembleur.

Bug dans le code d'hier

Retour sur le code d'hier, il y avait un bug et la seule raison pour laquelle ça fonctionnait est du à une particularité des AVR. Le bug est le suivant, comme je programme rarement en 'C' j'avais oublié que l'opérateur '-' a précédence sur l'opérateur '<<'. La ligne:

DDRB &= (0xFF - 1<<BOUTON); // met broche BOUTON en entrée

aurait du être:

DDRB &= (0xFF- (1<<BOUTON)); // met broche BOUTON en entrée.

La conséquence de cette erreur est que la broche PORTB0 que j'avais configurée en sortie dans une instruction précédente était revenue en mode entrée. Lorsqu'une broche est en mode entrée sur les AVR et qu'on écris un '1' sur cette broche ça active le pullup. Le courant passant à travers le pullup était suffisant pour commuter le transistor en conduction et allumer la LED. Lorsque le programme remettait '0' sur la broche le pullup était retiré et le transistor cessait de conduire. Ainsi le bug est passé inaperçu. Jusqu'à ce que je veuille utiliser le PWM et que je me gratte la tête en me demandant: pourquoi ça ne fonctionne pas?

Selon ma logique les opérateurs '<<' et '>>' devraient avoir la précédence sur les opérateurs '+' et '-' parce que se sont des opérateurs de multiplication et division par puissance de 2. Mais il semble que Kernighan et Ritchie, les auteurs du language 'C', non pas la même logique que moi.

Le code modifié pour aujourd'hui

Comme je l'ai expliqué à la fin de la chronique précédente il s'agit d'ajouter 4 niveaux d'intensité à la LED en utilisant un périphérique PWM. Tous les ATtiny même le plus petit ATtiny4 ont des périphériques PWM implantés. l'ATtiny13a possèdes 2 canaux PWM fonctionnants sur la même minuterie. Nous n'en utiliserons qu'un seul. Puisque pour cette application la fréquence PWM pourrait être aussi basse que 70hz sans que l'oeil ne percoive de scintillement on aurait tout aussi bien put le faire entièrement en software. Allons-y quand même pour la version hardware.

Modulation en largeur d'impulsion

Puisque cette série de chroniques est une introduction et que les périphériques Pulse Width Modulation (PWM) sont des plus utilisés sur les microcontrôleurs je vais expliquer ce que c'est, comment ça fonctionne et à quoi ça sert.

Les sorties numériques des MCU, comme leur nom l'indique, n'ont que 2 niveaux de tensions, soit la sortie est à 0 volt, soit elle est à Vdd, Vdd étant la tension d'alimentation du MCU. Donc si on commute cette sortie entre ces 2 niveaux on obtient une onde rectangulaire. La modulation PWM ou en français Modulation en largeur d'impulsion consiste à faire varier le rapport de durée entre la partie haute et la partie basse de l'onde. Par exemple si la partie haute a la même durée que la partie basse on obtient une onde carrée. En anglais le rapport entre ces 2 alternances du cycle s'appelle le duty cycle que reverso traduit par rapport cyclique. Donc si la partie haute dure 25% la partie basse durera 75% du cycle.

Presque tous les MCU ont un périphérique PWM. Voici comment ça fonctionne dans sa forme la plus simple. Un compteur binaire appellé timer reçoit un signal d'horloge qui incrémente le compte à chaque tick. Dans le cas du ATtiny13a ce compteur s'appelle TCNT0 et c'est un compteur 8 bits. Il peut donc compter de 0 à 255. Lorsqu'il arrive à 255 il retombe à zéro et le cycle recommence. De plus il faut un registre qui lui sert à déterminer le rapport cyclique. Dans le cas du ATtiny13a il y en a 2 parce qu'il y a 2 cannaux PWM, OCR0A et OCR0B. Supposons qu'on utilise OCR0A et qu'on met la valeur 0x7F dans ce registre. A chaque tick de l'horloge qui alimente TCNT0 la valeur de TCNT0 est comparée à celle de OCR0A et si TCNT0 égale OCR0A l'état de la sortie est inversée. Donc supposons qu'au départ TCNT0 a la valeur zéro et que la sortie est à 1. lorsque le compte dans TCNT0 atteindra 0x7F la sortie passera à zéro et le restera jusqu'à ce que TCNT0 débute un nouveau cycle. Le rapport cyclique de la sortie dépend donc de la valeur de OCR0A. Si ce dernier contient zéro la sortie sera toujours à 0 mais si la valeur de OCR0A=0xFF la sortie sera toujours à 1. On peut donc faire varier le rapport cyclique de 0 à 100% par incrément de 1/256.

Maintenant à quoi ça peut servir. Si presque tous les MCU en ont au moins 1 c'est que justement c'est très utile. On peut s'en servir pour positionner un servo-moteur, contrôler la vitesse d'un moteur en rotation continue, dans les circuits régulateurs ou convertisseurs de tension. Comme convertisseur digital/analogique ou encore pour contrôler l'intensité d'une LED comme nous allons faire.

Si on veut que la LED est une intensité de 75% il suffit de mettre le rapport cyclique à 75% donc on mettra dans OCR0A la valeur int(75/100*256). Il suffit que la période du cycle soit supérieur à 70Hz pour que l'oeil ne se rende pas compte du clignotement de la LED. En fait à partir d'environ 20Hz l'oeil ne perçoit déjà plus un clignotement mais un scintillement. A 60Hz on peut percevoir encore un léger scintillement si on observe du coin de l'oeil. A 70hz il n'y a vraiment plus de scintillement perçu même si le rapport cyclique est très bas, on perçois une LED toujours allumée mais à faible intensité.
Voici une capture d'écran prise à l'oscilloscope de la sortie PWM sur PB0. A gauche le rapport cyclique est de 12% et à droite de 50%.

code source

Voilà ce que notre programme va faire, il va faire clignoter la LED très rapidement et on va faire varier le rapport cyclique de 100% en diminuant la valeur de OCR0A de moitié à chaque étape. J'ai testé plusieurs variantes, voici celle que j'ai retenu.
/* * Intro_AtTiny.c * * Created: 2013-01-05 22:13:50 * Author: Jacques * Description: introduction aux MCU ATtiny * étape 1: allumer/éteindre un LED avec un bouton momentané. */ #define F_CPU 9600000UL // CPU à la fréquence maximale de l'oscillateur interne soit 9.6Mhz #include <avr/io.h> #include <util/delay.h> // tout ne peut pas être fait en C alors on utilise des macros avec directive asm #define disable_interrupt asm("cli") #define enable_interrupt asm("sei") #define watchdog_reset asm("wdr") // définition est E/S #define BOUTON PORTB3 // bit 3 du PORTB #define LED PORTB0 // bit 0 du PORTB // délais pour l'anti-rebond 20msec. #define ANTI_REBOND 20 #define LED_ETEINT 0 #define LED_MAX 255 // pré-scale pour le timer Fosc/256 #define PS_256 (1<<CS02) // configuration pour le mode fast pwm 3 #define FAST_PWM3 ((1<<COM0A1) | (1<<WGM01) | (1<<WGM00)) void WDT_off(void) // emprunté tel quel au datasheet de l'ATtiny13A, j'ai juste remplacé les macros { disable_interrupt; watchdog_reset; /* Clear WDRF in MCUSR */ MCUSR &= ~(1<<WDRF); /* Write logical one to WDCE and WDE */ /* Keep old prescaler setting to prevent unintentional time-out */ WDTCR |= (1<<WDCE) | (1<<WDE); /* Turn off WDT */ WDTCR = 0x00; enable_interrupt; } void attend_pression_bouton(){ // lecture du bouton avec anti-rebond. Attend que le bouton soit relâché avant de sortir. int8_t count; count=0; while (count<ANTI_REBOND){ // attend que le bouton soit enfoncé if ((PINB & 1<<BOUTON)==0){ count++; } else{ if (count>0) count--; } _delay_ms(1); } while (count>0){// attend que le bouton soit relâché if ((PINB & 1<<BOUTON)==(1<<BOUTON)){ count--; } else{ if (count<ANTI_REBOND) count++; } _delay_ms(1); } return; } int main(void) { WDT_off(); //désactivation du watch dog timer. disable_interrupt; CLKPR= (1<<CLKPCE); // permet la modification du pre-scale CLKPR = 0 ; // pre-scale mise à zéro. Le MCU fonctionne à la fréquence maximale. DDRB |= (1<<LED); // met PORTB0 en sortie DDRB &= (0xFF - (1<<BOUTON)); // met broche BOUTON en entrée PORTB |= (1<<BOUTON); //active le pullup PORTB &= (0xFF - (1<<LED)); // eteint le LED OCR0A=LED_ETEINT; // contrôle de l'intensité de la LED uint8_t rapport_cyclique=0; while (1) { attend_pression_bouton(); if (rapport_cyclique==LED_ETEINT){ rapport_cyclique=LED_MAX; // à ce point ci le PWM est désactivé. PORTB |= 1<<LED; // allume LED pleine intensitée. } else{ rapport_cyclique >>= 1; // diminue l'intensité de moitié. if (rapport_cyclique>15){ OCR0A=rapport_cyclique; TCCR0A=FAST_PWM3; // activation PWM TCCR0B=PS_256; } else{ rapport_cyclique=LED_ETEINT; TCCR0A=0; // désactivation PWM TCCR0B=0; PORTB &= (0xFF - (1<<LED)); //éteind LED } } } }

notes sur l'optimisation du code

Le compilateur a beau être optimisant le programmeur doit aussi faire ça part. Voici quelques commentaires à ce sujet.

Cette variante utilise 222 octets de mémoire flash et aucune mémoire RAM. J'ai constaté que lorsqu'on défini une variable globale (variable en dehors des fonctions), cette variable est stockée dans la RAM plutôt que dans la banque de registres ce qui a des conséquences sur la taille du code et la vitesse d'accès à cette variable. Donc autant que possible on défini les variables à l'intérieur des functions. De toute façon c'est une bonne pratique en programmation de réduire les variables globales au mininum. Autre considération, notez que la variable rapport_cyclique est de type uint8_t. Les variables de type int sont de 16 bits donc occupent 2 octets et de plus augmente la taille du code car les AVR étant des processeurs 8 bits doivent manipuler les entiers 16 bits en 2 opérations plutôt qu'une seule. Deux instructions pour l'affectation d'une valeur. Deux instructions pour la copie d'une variable, etc. Donc encore une fois en autant que c'est possible utilisez les types int8_t ou uint8_t.

Pourquoi est-ce que j'ai utilisé une variable rapport_cyclique au lieu de manipuler la valeur directement dans le registre OCR0A? J'ai essayé les deux variantes. La version avec variable réduit le code de 6 instructions. En effet la variable étant enregistrée directement dans la banque de registres il n'est pas nécessaire d'aller la cherchée pour manipuler sa valeur, tandis que pour OCR0A il faut une instruction in pour transférer son contenu dans un registre avant toute manipulation et un out pour retourner le résultat dan OCR0A.

J'ai lu quelque part qu'il était plus efficace de créer une boucle infinie en utilisant l'instruction:

for (;;){}

plutôt que:

while (1){}

C'est faux le compilateur GCC est en mesure de reconaître que dans les 2 cas il s'agit d'une boucle infinie et les compile de la même manière par une instruction rjmp à la fin du bloc d'instructions.

Qu'avons nous appris

• Ce qu'est un périphérique PWM et comment l'utiliser dans sa version la plus simple, ce qui est suffisant pour une introduction.
• Dans les expresssions il vaut mieux mettre plus de parenthèses pour grouper les sous-expressions que moins. Les parenthèses ne coûtent rien à la compilation et ça évite les bugs du à une erreur d'interprétation des précédences des opérateurs.
• Le programmeur même s'il progamme en 'C' doit lire le datasheet et bien comprendre le fonctionnement du micro-processeur sur lequel il travaille. Chaque détail compte.
• Le programmeur ne peut compter sur le compileur seul pour optimiser le code, là aussi il doit faire sa part.

prochaine étape

On va ajouter une fonction de clignotement à 3Hz pleine intensité. Ça va nécessité une modification à la fonction attend_pression_bouton() car la lumière va entrée dans ce mode seulement si le bouton est maintenu enfoncé plus de 2 secondes.

introduction aux MCU ATtiny, partie 2

Maintenant que Atmel studio est installé ainsi que le programmmeur Pololu USB AVR, on peut commencer. tous les documents concernant cette série de chroniques seront enregistrés ici. Mais avant de programmer un MCU il faut évidemment étudier sa strcuture interne. Le core AVR 8 est très différent de celui des PIC mais il ressemble à celui de la majorité des microcontrolleur moderne, que ce soit les MSP430, ARM, MIPS en ce sens qu'il utilise un bloc de registres appellé en anglais general purpose register file alors que les PIC n'ont que le registre W. Toutes les opérations arithmétiques et logiques utilisent le contenu d'au moins 1 de ces registres comme argument et le résultat est retourné dans l'un de ces registres. Cependant comme les PIC l'ARV core est basé sur une architecture Harvard, c'est à dire que la mémoire programme est séparée de la mémoire des données. Le register file du AVR8 contient 32 registres de 8 bits pour la majorité des ATtiny sauf pour les petits ATtiny4,5,9 10 qui n'ont que 16 registres. Voici une représentation interne du AVR core 8.

À gauche c'est la structure général et à droite c'est la représentation du register file avec ces 32 registres. Notez que les 6 registres R26 à R31 ont une fonction spéciale. Utilisés par paire ils forment 3 registres d'indexation de 16 bits, X, Y et Z. C'est l'équivalent des registres FSR des PIC mais en plus puissant. D'abord parce qu'ils ont 16 bits il peuvent pointés jusqu'à 64K de RAM et deuxièmement parce qu'ils permmettent des modes d'adressage indexé, indexé relatif et incrémentation automatique. Chez les MCU PIC on ne retrouve ce genre de fonctionnalité que dans les familles enhanced mid-range (PIC12F1xxxx/PIC16F1xxxx) et extended (PIC18Fxxxx).

Ces registres peuvent aussi être utilisés comme registres d'usage général mais ce n'est pas recommendé à moins que vous n'ayez pas besoin de 3 registres d'indexation.

Autre différence avec les PIC la pile des retours est en RAM et non un mémoire dédiée comme c'est le cas avec les PIC. La dimension de la pile est donc limité seulement par la mémoire RAM disponible et de plus le pointeur de pile peut-être manipulé et on dispose d'instructions push et pop. Cette architecture facilite grandement la création d'un compilateur pour les languages de haut niveau comme le 'C' et permet donc un compilation plus facilement optimisée.

En ce qui concerne l'accès au périphérique c'est le même principe que sur tous les MCU que je connais, c'est à dire que dans l'espace d'adressage RAM il y a des registres spéciaux qui contrôlent la configuration des périphériques. Rien pour être dépaysé. Comme on va programmer en 'C' l'accès aux registres spéciaux se fera par affectation à des variables. C'est à dire que chaque SFR (Special Function Register) a un nom symbolique et que lorsqu'on veut écrire dans un registre on utilise simplement une affectation du genre:
CLKPR = 0 ; // désactivation du diviseur
et pour lire un SFR on fait comme si c'était une variable:
if (PORTB & 1<<4 == 1<<4)... // est-ce que le bit 4 du PORT B est à 1?

Modification au circuit

J'ai légèrement modifié le circuit présenté en partie 1:

Création d'un nouveau projet

J'ai préparé un document au format OpenOffice 3 expliquant les étapes pour la création d'un nouveau projet dans Atmel studio.

Lorsque vous branchez le programmeur Pololu au port USB si le pilote est installé correctement, dans le gestionnaire de périphérique de Windows vous verrez 2 nouveaux ports COM. Celui qui nous intéresse s'appelle Pololu USB AVR programmer Programming Port (COMx). Notez le nom du port COM. Il faut configuré Atmel studio pour l'utilisation de ce PORT.

Dans la barre de menu d'Atmel studio vous verrez l'item tools et dans le menu déroulant de celui-ci il y a add STK500.... Cliquez dessus, sélectionnez le port de votre programmeur Pololu et faite apply.

Maintenant si vous suivez les instructions du document pour créer un nouveau projet GCC vous devriez vous retrouver face à la fenêtre de l'éditeur avec le squelette de l'application en place. On peut maintenant écrire le code.

Pour cette première version de notre application ce sera très simple, on va utiliser le bouton pour allumer et éteindre le LED. A chaque pression du bouton l'état du LED va basculer.

code source /* * Intro_AtTiny.c * * Created: 2013-01-05 22:13:50 * Author: Jacques * Description: introduction aux MCU ATtiny * étape 1: allumer/éteindre un LED avec un bouton momentané. */ #define F_CPU 9600000 // CPU à la fréquence maximale de l'oscillateur interne soit 9.6Mhz #include <avr/io.h> #include <util/delay.h> // tout ne peut pas être fait en C alors on utilise des macros avec directive asm #define disable_interrupt asm("cli") #define enable_interrupt asm("sei") #define watchdog_reset asm("wdr") // définition est E/S #define BOUTON PORTB3 // bit 3 du PORTB #define LED PORTB0 // bit 0 du PORTB void WDT_off(void) // emprunté tel quel au datasheet de l'ATtiny13A, j'ai juste remplacé les macros { disable_interrupt; watchdog_reset; /* Clear WDRF in MCUSR */ MCUSR &= ~(1<<WDRF); /* Write logical one to WDCE and WDE */ /* Keep old prescaler setting to prevent unintentional time-out */ WDTCR |= (1<<WDCE) | (1<<WDE); /* Turn off WDT */ WDTCR = 0x00; enable_interrupt; } void attend_pression_bouton(){ // lecture du bouton avec anti-rebond. Attend que le bouton soit relâché avant de sortir. int8_t count; count=0; while (count<20){ // attend que le bouton soit enfoncé if ((PINB & (1<<BOUTON))==0){ count++; } else{ if (count>0) count--; } _delay_ms(1); } while (count>0){// attend que le bouton soit relâché if ((PINB & (1<<BOUTON))==(1<<BOUTON)){ count--; } else{ if (count<20) count++; } _delay_ms(1); } return; } int main(void) { WDT_off(); //désactivation du watch dog timer. CLKPR= (1<<CLKPCE); // permet la modification du pre-scale CLKPR = 0 ; // pre-scale mise à zéro. Le MCU fonctionne à la fréquence maximale. DDRB |= (1<<LED); // met PORTB0 en sortie DDRB &= (0xFF - (1<<BOUTON)); // met broche BOUTON en entrée PORTB |= 1<<BOUTON; //active le pullup PORTB &= (0xFF - (1<<LED)); // eteint le LED while(1) { attend_pression_bouton(); /* if ((PINB & (1<<BOUTON))==0) PORTB |= (1<<LED); else PORTB &= (0xFF - 1<<LED); */ PORTB ^= (1<<LED); //commute l'état de la sortie LED } }
J'ai commenté le code pour que chaque étape soit limpide.

compilation et programmation du MCU

Pour compiler le code pressez la touche F7 ou encore cliquez l'icône build solution ou encore allez dans le menu build et cliquer le premier item. Le résultat s'affiche dans le fenêtre output en bas de l'éditeur. Cliquer sur un message d'erreur nous ramène à la ligne en faute dans le texte.

Lorsqu'il n'y a plus d'erreur on programme l'ATtiny en utilisant l'icône device programming qui est représenté par un C.I. avec un éclair par dessus. On peut aussi aller dans le menu tools.

Dans la fenêtre device programming

1. Sélectionnez votre programmeur dans la liste déroulante sous tool
2. cliquez apply
3. cliquez read sous device signature
4. allez dans memories et sélectionnez le fichier .hex qui correspond à votre programme.
5. finalement cliquez sur program. L'état de l'avancement apparait plus bas dans la fenêtre. Si tout est ok il n'y a rien d'autre à faire.

ATTENTION!

Ne faites pas ça. Si vous programmez le fusible RSTDISBL le programmeur Pololu ne pourra plus utiliser ce chip. Seul un programmeur haute-tension peut reprogrammer un chip dont le RESET a été désactivé. C'est pour ça que j'ai modifié le circuuit et mis le bouton sur PORTB3 plutôt que PORTB5.

Ce que j'ai appris

Voici ce que j'ai appris dans cette deuxième étape.

• Ne pas programmer RSTDISBL quand on utilise un programmeur basse tension comme le Pololu USB AVR. OOPS!
• Comment désactivé le Watchdog timer
• Un AVR ce n'est pas un PIC pour connaître l'état d'une entrée on ne lit pas le registre PORTx mais le registre PINx.
• #include <interrupt.h> ne fonctionne pas. Le compilateur ne trouve pas le fichier... C'est pourquoi j'ai réécris les macros, plutôt que de perdre mon temps à chercher la solution. A voir plus tard.
• Trop de clicks pour flasher le MCU. Dans MPLABX il suffit d'un seul.
• Même si on cré un nouveau projet, le fichier HEX qui est indiqué dans device programming, section memories est le dernier sélectionné dans un projet précédent. ARGH!!

prochaine étape

Contrôler l'intensité du LED en utilisant le périphérique PWM.

1. LED éteint on pèse sur le bouton, le LED allume à 100%
2. on repèse l'intensité baisse à 75%
3. A chaque pression l'intensité devra diminuner de 25% jusqu'à l'instinction.

Introduction aux MCU ATtiny, partie 1

Cette chronique est la première d'une série consacrée à un tutoriel d'introduction au microcontrôleurs ATtiny d'Atmel. Dans cette première partie je vais décrire les logiciels et le matériel nécessaire pour réaliser les expériences décrites dans cette série. En fait il va s'agir d'un seul projet auquel je vais ajouter des fonctionnalités à chaqe chronique. Toute la progammation va se faire en C.

Environnement de travail

L'environnement de travail sera le même que celui que j'ai utilisé pour ma chronique intitulée premiers pas avec MCU Atmel AVR.

Logiciels

• Environnement Windows XP/vista/7
• Atmel studio 6.0
• manuel de l'utilisateur et pilote pour le programmeur USB Pololu AVR

Bien sur vous pouvez utiliser un autre programmeur que celui de Pololu. Mais celui de Pololu a l'avantage de pouvoir être contrôlé directement à partir d'Atmel studio.

Liste de matériel requis

• 1 programmeur Pololu AVR
• Une platine de prototypage sans soudure
• 1 microcontrôleur ATtiny13A format PDIP8
• 1 résistance de 75 ohm 1/4 Watt.
• 1 résistance de 2K
• 1 résistance de 10K
• 1 LED blanche
• 1 transistor de commutation NPN,exemple: ZTX649
• 1 bouton à contact momentané.
• 1 condensateur céramique 100nF
• 1 porte pile 3xAA et 3 piles AA ou bien une alimentation régulé 5Volt.

Les liens vers les sites de Digikey et Robotshop ne sont que des suggestions.

Schéma électronique

Voici le montage qui sera utilisé pour toute la série.

installation d'Atmel Studio

Je n'ai rien trouvé en français sur l'installation d'Atmel studio 6.0 seulement ce vidéo en anglais produit par Atmel. En fait il y a plusieurs vidéo sur l'utilisation du studio. Je n'ai pas l'intention de faire une présentation sur la configuration et l'installation de l'environnement de travail. Vous devrez vous débrouiller par vos propre moyens pour ça.

Dans la prochaine crhonique je vais présenter le core AVR 8 et la première expérience que nous ferons avec l'ATtiny13A.