programmateur d'eeprom i2c

Pour un projet sur lequel je travaille j'avais besoin d'un programmateur de mémoire eeprom sériel avec interface I2C mais en regardant sur le site de Microchip et celui de digikey.ca le prix m'a fait reculer. Avec les coûts de transport et les taxes j'aurais du débourser plus de 80$ pour un appareil qui ne me servira probablement que très rarement. J'ai donc entrepris de fabriquer mon propre programmateur. Ce programmateur est conçu pour les mémoires eeprom sérielles avec interface I2C de Microchip. Le projet comprend 2 parties, le montage électronique avec le firmware pour le MCU qui contrôle la programmation eeprom et le logiciel hôte qui tourne sur le PC. Pour le logiciel PC j'ai choisi de l'écrire en python pour qu'il puisse être utilisé aussi bien sous Windows que Linux ou même OSX.

Matériel requis

Qt	No.Pièce	description	prix $CAN	fournisseur
2	A100204-ND	embases DIL-8	0,20	Digikey.ca
1	RB-Ada-30	perma-proto 1/4	8,95/pqt de 3	Robotshop.com/ca
3	P5148-ND	condensateur électrolytique 10uF/25V	0,21	digikey.ca
2	445-8421-ND	condensateur céramique 100nF	0,32	digikey.ca
1	2N3904-APCT-ND	transistor NPN 2N3904	0,45	digikey.ca
1	2N3906-APCT-ND	transistor PNP 2N3906	0,45	digikey.ca
1	PIC12F1822-I/P-ND	Microcontrolleur Micropchip PIC12F1822	1,50	digikey.ca
1	1N4148-TAPCT-ND	diode 1N4148	0,25	digikey.ca
1	P2.0KBACT-ND	resistance 2K/0,25Watt	0,10	digikey.ca
1	CF14JT4K70CT-ND	resistance 4K7/0,25Watt	0,09	digikey.ca
3	CF14JT10K0CT-ND	résistance 10K/0,25Watt	0,09	digikey.ca
5	609-3466-ND	contact pin	0,11	digikey.ca

schéma électronique

Le programmateur communique avec l'ordinateur via un port série à 115200 BAUD, 8bits, pas de parité et 1 stop. La partie à droite du schéma, constituée de Q1 et Q2 est un convertisseur de niveaux de tension pour le RS-232. C'est le même circuit que j'ai déjà présenté sur ce blog. Le MCU PIC12F1822 communique donc avec le PC à travers ce circuit et d'autre part avec l'eeprom via les broches 2,3 et 5. La broche 2 est la sortie SCL et la broche 3 est l'E/S pour SDA du protocole I2C. La broche 5 contrôle le WP de l'eeprom et est gardée au niveau haut sauf pendant l'écriture de données dans l'eeprom. Les eeprom 24LCxxxx ont 3 entrées d'addressage A0-A2, qui servent à sélectionner le circuit intégré sur le bus I2C. Puisqu'il y a 3 bits d'adresse on peut mettre jusqu'à 8 I.C. sur le même bus I2C. Sur le schéma du programmateur j'ai mis A2=A0 à Vdd, l'adresse est donc 0b111. Pour les 24LC1025 il faut que la broche A2 soit à Vdd car le bit de la commande qui correspond à A2 dans les eeprom de plus de 64KB est utilisé pour sélectionner le block de 64K, la mémoire étant divisé en 2 block de 64KB.

montage

Pour le montage j'ai utilisé une platine produite par Adafruit et distribuée par Robotshop.com. C'est la première fois que j'utilise ce produit et je suis très satisfait. La qualité est bonne, les oeillets de soudure sont passant donc on peut soudé du côté composant sans avoir à retourner la platine. Le dessus de la platine est une représentation exacte d'une platine sans soudure. Donc pour faire le montage pas besoin de refaire un schéma de montage il suffit de recopier simplement ce qu'on a fait sur la platine sans soudure. Le montage a été plus rapide que si je l'avais fait sur une platine à grille de points 100mil. C'est un produit intéressant que je recommande.
Côté cuivre de la platine entre les contacts TX et RX j'ai coupé la trace du circuit imprimé pour isoler les contacts l'un de l'autre puisqu'il sont montés sur la même rangée.

firmware PIC12F1822

En ce qui concerne le firmware du PIC12F1822 ça a été assé simple. Pour la communication avec le PC comme le MCU a un périphérique USART incorporé le travail au niveau logiciel a été très simple. Le gros du travail c'est fait au niveau de l'interface I2C avec l'eeprom, mais pas de quoi s'arracher les cheveux.

code source firmware PIC12F1822
; NOM: eeprom-prog.asm ; DESCRIPTION: programmeur pour eeprom i2c Microchip série 24AAxxx/24LCxxx/24FCxxx ; interface PC RS-232, communication semi-duplex. ; format des paquets: ; CNT CMD DATA CHKSUM ; CNT est un octet indiquant le nombre d'octets dans le paquet ; excluant CNT ; CMD indique le type message: ; 00 Débute transaction écriture eeprom, 4 octets ; 1 octet cmd ; 2 octets adresse début, (les nombres sont en format en little indian.) ; 1 octet checksum ; 01 data à envoyer à l'eeprom, maximum 16 octets de données ; 1 octet cmd ; 1-16 octets données ; 1 octet checksum ; 02 commande l'écriture des données reçues. ; 1 octet cmd ; 1 octet checksum ; 03 commande début lecture eeprom ; 1 octet cmd ; 2 octets adresse ; 1 octet checksum ; 04 commande lecture n octets suivants ; 1 octet commande ; 1 octet nombre à lire maximum 16 ; 1 octet checksum ; 05 demande version firmware ; 1 octet cmd ; 1 octet chksum ; 06 met à 1 l'indicateur de block F_BLOCK ; 1 octet cmd ; 1 octet chksum ; 07 remet à zéro l'indicateur de block F_BLOCK ; 1 octet cmd ; 1 octet checksum ; 08 fermeture des transactions, retour à l'état IDLE ; 1 octet cmd ; 1 octet chksum ; ; CHKSUM est le complément de 2, de la somme % 256 de tous les ; octets qui précèdent ; ; protocole: ; au départ le programmeur est IDLE et attend un ENQ du PC ; s'il est prêt à recevoir des paquets il répond par un ACK ; Lorsque le PC envoie un paquet il attend un ACK du programmeur. ; Le programmeur traite le paquet avant de répondre ; si le traitement est sans erreur il envoie un ACK ; sinon il envoie un NAK suivit d'un code d'ereur. ; ; codes d'erreurs: ; 00 pas d'erreur (envoyé à la suite d'un ACK) ; 01 erreur checksum sur le paquet reçu ; 02 erreur de communication avec l'eeprom ; 03 commande inconnue ; ; Le programmeur ne sais rien de l'eeprom avec laquelle il est en ; communication. C'est au programme sur le PC de s'assurrer ; que les paramètres de l'eeprom sont respectés: ; - dimension des pages ; - éviter de tenter d'écrire en chevauchement de 2 pages. ; - respect de la capacité mémoire. ; ; MCU: PIC12F1822 ; DATE: 2012-12-16 ; AUTEUR: Jacques Deschênes #include <P12F1822.INC> #include "..\include\pic12f1822_m.inc" #include "..\include\stack.inc" default_config #define DEBUG ;;;;;;;;; constantes ;;;;;;;;;;;;;;;;;;;;;;;; FOSC4 EQU OSC_FREQ_16M FIRMWARE_VERSION EQU H'10' ; high nibble major, low nibble minor BAUDRATE EQU D'115200' FREQ_CLOCK EQU D'16000000' BUFF_SIZE EQU D'66' ; dimension io_buffer ; type de paquet envoyés par le PC PQT_WRITE EQU 0 ; début de programmation eeprom PQT_DATA EQU 1 ; données à programmer PQT_FLASH EQU 2 ; fermer la transaction écriture, flash la rangée. PQT_READ EQU 3 ; débute la lecture de l'eeprom PQT_RDN EQU 4 ; fait la lecture des n octets suivants PQT_VER EQU 5 ; demande version firmware PQT_SETB EQU 6 ; met à 1 F_BLOCK PQT_CLRB EQU 7 ; met à 0 F_BLOCK PQT_EOT EQU 8 ; fermeture des transactions retour à l'état IDLE ;communication UART PC/programmeur ENQ EQU 5 ; le PC envoie un ENQ et attend un ACK du programmeur ACK EQU 6 ; le programmeur répond qu'il est prêt envoyant ce code NAK EQU D'21' ; le programmeur informe le PC qu'il s'est produit une erreur. ; codes d'erreur renvoyés au PC ERR_NONE EQU 0 ; pas d'erreur ERR_CS EQU 1 ; erreur checksum ERR_EE EQU 2 ; erreur communication eeprom ERR_CMD EQU 3 ; commande inconnue. ERR_SYNC EQU 4 ; l'octet reçu n'est pas synchronisé avec l'état du programmeur. ; commandes eeprom ; les eeprom 24LC102x ont 2 blocks de 64KB ; le block est sélectionné par le bit 3 dans la commande. ; pour les eeprom <=64KB le block B1 est sélectionné par défaut car la broche A2 est à V+. ; pour les eeprom 128KB le block B0 est sélectionné par défaut. EE_CTL_WR_B0 EQU H'A6' ; envoie vers EEPROM commande block 0 EE_CTL_RD_B0 EQU H'A7' ; réception de EEPROM commande block 0 EE_CTL_WR_B1 EQU H'AE' ; envoie vers EEPROM commande block 1 EE_CTL_RD_B1 EQU H'AF' ; récepion de EEPROM commande block 1 ; indicateurs booléens F_BLOCK EQU 1 ; indicateur de block pour eeprom > 64KB F_RCVD EQU 2 ; réception paquet UART complétée F_UIDLE EQU 3 ; uart en état idle, attend ENQ F_URDY EQU 4 ; uart prêt à recevoir un paquet F_UPEND EQU 5 ; réception d'un paquet en cours. F_EERD EQU 6 ; lecture eeprom en cours F_EEWR EQU 7 ; écriture eeprom en cours ;;;;;;;;; macros pré-processeur ;;;;;;;;;;;;; ;interface RS-232 avec PC #define TX_P RA0 #define RX_P RA1 #define TX PORTA, TX_P #define RX PORTA, RX_P ;interface eeprom #define WP_P RA2 #define SCL_P RA5 #define SDA_P RA4 #define EE_WP PORTA, WP_P #define EE_SCL PORTA, SCL_P #define EE_SDA PORTA, SDA_P ;;;;;;;;; macros mpasm ;;;;;;;;;;;;;;;;;;;;;; ee_stop macro ; met l'interface i2c à l'état idle ; bank PORTA doit-être préalablement sélectionnée bcf EE_SDA bsf EE_SCL goto $+1 ;delais minimum 600nsec goto $+1 bsf EE_SDA goto $+1 ; délais minimum 1300nsec goto $+1 nop endm ee_start macro ; signale à l'eeprom le début d'une transaction ; bank PORTA doit-être préalablement sélectionnée bsf EE_SDA bsf EE_SCL goto $+1 bcf EE_SDA goto $+1 ; délais minimum 600nsec nop bcf EE_SCL endm ee_read_cmd macro ; prépare l'eeprom pour une lecture séquentielle ; appellée à la suite de: ; call ee_set_address banksel PORTA ee_start movlw EE_CTL_RD_B1 btfss flags, F_BLOCK movlw EE_CTL_RD_B0 pushw call ee_send_byte endm ee_write_cmd macro ; envoie la commande écriture à l'eeprom banksel PORTA ee_start movlw EE_CTL_WR_B1 btfss flags, F_BLOCK movlw EE_CTL_WR_B0 pushw call ee_send_byte endm ee_wr_enable macro ; désactive la broche WP sur l'eeprom ; bank PORTA préalablement sélectionnée bcf EE_WP goto $+1 nop endm ee_wr_disable macro ; active la broche WP sur l'eeprom ; bank PORTA préalablement sélectionnée bsf EE_WP goto $+1 ; délais hold time minimum 1300nsec goto $+1 nop endm ee_send_bit macro ; envoie un bit sur l'interface i2c de l'eeprom ; le bit à envoyé est dans le Carry du registre STATUS ; bank PORTA préalablement sélectionnée bcf EE_SDA skpnc bsf EE_SDA nop bsf EE_SCL goto $+1 ; délais hold minimum 600nsec. bcf EE_SCL endm ee_rcv_bit macro ; reçoit un bit de l'interface i2c ; en sortie le bit est dans le Carry ee_sda_dir SDA_INP bsf EE_SCL goto $+1 ; délais minimum 900nsec nop bcf STATUS, C btfsc EE_SDA bsf STATUS, C bcf EE_SCL goto $+1 ee_sda_dir SDA_OUT endm constant SDA_OUT=0 constant SDA_INP=1 ee_sda_dir macro dir banksel TRISA if dir==SDA_OUT bcf TRISA, SDA_P else bsf TRISA, SDA_P endif banksel PORTA endm case macro val, target ; si W==val goto target ; remet W à la valeur initiale pour le case suivant xorlw val skpnz goto target xorlw val endm ;;;;;;;;; variables ;;;;;;;;;;;;;;;;;;;;;;;;;; udata io_buffer res BUFF_SIZE ; buffer données RS-232 et I2C udata_shr flags res 1 ; indicateurs booléens ee_adr_start res 2 ; début d'adresse pour l'écriture uart_buffer_ptr res 1 ; pointeur buffer uart uart_bytes_cntr res 1 ; compteur pour les octets à recevoir par UART ;;;;;;;;; segment de code ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; code rst_vector org 0 goto init ;;;;;;;;;;; routine de service des interruptions ;;;;;;;;;;;;;;; isr_vector org 4 banksel PIE1 btfss PIE1, RCIE retfie banksel PIR1 btfss PIR1, RCIF retfie ; interruption sur réception uart btfss flags, F_UIDLE goto test_rdy banksel RCREG movfw RCREG xorlw ENQ skpz goto isr_exit movlw ACK movwf TXREG bcf flags, F_UIDLE bsf flags, F_URDY goto isr_exit test_rdy btfss flags, F_URDY goto receive_byte movlw low io_buffer movwf uart_buffer_ptr movwf FSR1L banksel RCREG movfw RCREG movwf uart_bytes_cntr movwf INDF1 incf uart_buffer_ptr, F bcf flags, F_URDY bsf flags, F_UPEND goto isr_exit receive_byte btfss flags, F_UPEND goto bad_sync clrf FSR1H movfw uart_buffer_ptr movwf FSR1L banksel RCREG movfw RCREG movwf INDF1 incf uart_buffer_ptr, F decfsz uart_bytes_cntr,F goto isr_exit bcf flags, F_UPEND bsf flags, F_RCVD goto isr_exit bad_sync movlw low io_buffer movwf FSR1L movlw NAK movwf INDF1 movlw ERR_SYNC movwi 1[FSR1] movlw 2 pushw call uart_send_buffer ee_stop clrf flags bsf flags, F_UIDLE bsf flags, F_BLOCK isr_exit banksel PIR1 bcf PIR1, RCIF retfie ee_send_byte ; envoie un octet sur le bus i2c ; start condition préalablement activée. ; entrée: (octet -- ) ; sortie: Carry=0 ok, Carry=1 erreur movlw 8 xchg pushw ; (octet, cntr -- ) ee_send_byte02 rlf STKP, F ee_send_bit decarg 1 skpz goto ee_send_byte02 drop 2 ee_rcv_bit ; receive ack return ee_send_buffer ;envoie une série d'octets vers l'eeprom ;ee_set_address déjà appellé. ;start contidion préalablement activée ;commande EE_CTL_WR déjà envoyée. ;entrée: (compte -- ) ; compte nombre d'octets à envoyer. ; FSR1 pointe sur le début du buffer ;sortie: Carry bit, 0=succès, 1=échec movfw INDF1 pushw call ee_send_byte skpc goto ee_send_buffer04 ee_stop drop 1 return ee_send_buffer04 addfsr FSR1, 1 decfsz STKP, F goto ee_send_buffer drop 1 return ee_rcv_byte ; reception d'un octet de l'eeprom ; start condition préalablement établie ; commande EE_CTL_RD préalablement envoyée ; entrée: aucun argument ; sortie: octet dans W ee_sda_dir SDA_INP movlw 8 pushw clrw pushw ; (octet_reçu, compteur -- ) ee_rcv_byte02 bsf EE_SCL goto $+1 nop bcf STATUS, C btfsc EE_SDA bsf STATUS, C rlf STKP, F bcf EE_SCL decarg 1 skpz goto ee_rcv_byte02 ee_sda_dir SDA_OUT bcf STATUS, C ee_send_bit ; send ACK popw drop 1 return ; ee_rcv_byte ee_read_bytes ; lit un certain nombres d'octet de l'eeprom ; préalable: ; ee_set_address déjà appellé ; commande EE_CTL_RD déjà envoyée. ; FSR1 pointe au début du buffer ;entrée (compte -- ) ; compte nombre d'octets à lire ;sortie: Carry -> 0=succès, 1=erreur call ee_rcv_byte skpc goto ee_read_bytes02 ee_stop drop 1 return ee_read_bytes02 movwf INDF1 addfsr FSR1, 1 decfsz STKP, F goto ee_read_bytes drop 1 return ee_set_address ; initialise le registre d'adresse de l'eeprom ; entrée: ( high_byte, low_byte -- ) ; sortie: état opération dans Carry: 0=succès, 1=erreur ; s'il n'y a pas d'erreur l'eeprom est prêt à recevoir des données. ee_write_cmd skpc goto ee_send_high_byte drop 2 goto ee_nack_error ; no ack received ee_send_high_byte call ee_send_byte skpc goto ee_send_low_byte drop 1 goto ee_nack_error ; no ack received ee_send_low_byte call ee_send_byte skpc return ; ack received ee_nack_error ee_stop return ; ee_set_address ee_end_read ; termine une série de lecture ; comme ee_rcv_byte termine toujours par un ACK ; il faut terminer la transaction en lisant un dernier octet ; suivit d'un stop movlw 8 pushw ee_end_read02 ee_rcv_bit decfsz STKP, F goto ee_end_read02 ee_stop drop 1 bcf flags, F_EERD return ee_wait_ready ; attend que l'eeprom est terminé son cycle d'écriture ee_write_cmd skpnc goto ee_wait_ready ee_stop return clear_buffer ; met à zéro tous les octets du buffer ; entrée (compte -- ) ; FSR1 pointe au début du buffer clrf INDF1 addfsr FSR1, 1 decfsz STKP, F goto clear_buffer drop 1 return uart_send_buffer ; envoie le contenu bu buffer au PC ; entrée ( compte -- ) ; FSR pointe au début du buffer ; sortie ( -- ), BSR préservé. movfw BSR xchg pushw ; (compte bsr -- ) banksel TXREG uart_send_buffer02 movfw INDF1 movwf TXREG btfss TXSTA, TRMT goto $-1 addfsr FSR1, 1 decfsz STKP, F goto uart_send_buffer02 drop 1 popw movwf BSR ; restore BSR return compute_checksum ; calcule la somme de contrôle des octets dans io_buffer ; entrée: le premier octet du buffer indique le nombre d'octets dans le buffer ; sortie: FSR1 pointe au début du buffer ; le compte du nombre d'octets a été incrémenté de 1 pour inclure le checksum movlw low io_buffer movwf FSR1L incf INDF1,F ; 1 octet de plus pour include la somme de controle movfw INDF1 pushw ; nombre d'octets dans buffer compute_cs_loop addfsr FSR1, 1 decfsz STKP, F goto $+2 goto compute_cs_exit addwf INDF1, W goto compute_cs_loop compute_cs_exit comf WREG incf WREG ; comlément de 2 movwf INDF1 movlw low io_buffer movwf FSR1L drop 1 return checksum_control ; vérifie si le checksum du message est valide ; sortie: si checksum correcte W=0 clrf FSR1H movlw low io_buffer movwf FSR1L movfw INDF1 pushw ; nombre d'octets reçu incf STKP,F cs_loop addfsr FSR1, 1 decfsz STKP, F goto $+2 goto cs_exit addwf INDF1, W goto cs_loop cs_exit drop 1 return process_msg ; traite le message reçu du PC bcf flags, F_RCVD call checksum_control xorlw 0 skpz goto checksum_error movlw low io_buffer movwf FSR1L moviw 1[FSR1]; id du message case PQT_WRITE, begin_eeprom_write case PQT_DATA, data_msg case PQT_FLASH, flash_msg case PQT_READ, begin_eeprom_read case PQT_RDN, read_next_bytes case PQT_VER, version_msg case PQT_SETB, setblock_msg case PQT_CLRB, clearblock_msg case PQT_EOT, eot_msg unknown_command movlw ERR_CMD pushw movlw NAK pushw goto send_answer checksum_error movlw ERR_CS pushw movlw NAK pushw goto send_answer eeprom_comm_error ee_stop bcf flags, F_EEWR bcf flags, F_EERD movlw ERR_EE pushw movlw NAK pushw goto send_answer send_ack movlw ERR_NONE pushw movlw ACK pushw send_answer ; (ack/nak err_code --) clrf FSR1H movlw low io_buffer movwf FSR1L popw movwf INDF1 popw movwi 1[FSR1] movlw 2 pushw call uart_send_buffer ;(compte -- ) bsf flags, F_URDY return begin_eeprom_write ; 4 octets: cmd, adresse, checksum moviw 2[FSR1] ; low adresse pushw moviw 3[FSR1] ; high adresse pushw call ee_set_address skpnc goto eeprom_comm_error bsf flags, F_EEWR goto send_ack data_msg ; 3-18 octets: cmd, data, checksum btfsc flags, F_EEWR goto data_msg02 data_msg01 movlw ERR_SYNC pushw movlw NAK pushw goto send_answer data_msg02 movlw 2 subwf INDF1, W pushw addfsr FSR1, 2 call ee_send_buffer ; (compte -- ) skpnc goto eeprom_comm_error goto send_ack flash_msg ; 2 octets cmd, checksum btfss flags, F_EEWR goto data_msg01 ee_wr_enable ee_stop call ee_wait_ready ee_wr_disable bcf flags, F_EEWR goto send_ack begin_eeprom_read ; 4 octets: cmd, adresse, checksum moviw 2[FSR1] pushw moviw 3[FSR1] pushw call ee_set_address skpnc goto eeprom_comm_error ee_read_cmd skpnc goto eeprom_comm_error bsf flags, F_EERD goto send_ack read_next_bytes ; 2 octets: cmd, nombre, checksum moviw 2[FSR1] ; nombre d'octets à lire dans l'eeprom movwf INDF1 addfsr FSR1, 1 pushw call ee_read_bytes skpnc goto eeprom_comm_error call compute_checksum incf INDF1, W pushw call uart_send_buffer bsf flags, F_URDY return version_msg ; 2 octets cmd, checksum movlw ACK movwf INDF1 movlw FIRMWARE_VERSION movwi 1[FSR1] movlw 2 pushw call uart_send_buffer bsf flags, F_URDY return setblock_msg ; 2 octets: cmd, checksum bsf flags, F_BLOCK goto send_ack clearblock_msg ; 2 octets: cmd, checksum bcf flags, F_BLOCK goto send_ack eot_msg ; 2 octets: cmd + checksum btfss flags, F_EERD goto eot_02 call ee_end_read goto eot_04 eot_02 ee_stop eot_04 clrf flags bsf flags, F_BLOCK bsf flags, F_UIDLE banksel TXREG movlw ACK movwf TXREG btfss TXSTA, TRMT goto $-1 clrf TXREG btfss TXSTA, TRMT goto $-1 return ;;;;;;;; initialisation MCU ;;;;;;;;;;;;;;;;;; init clear_ram ; et par la même occation initialise le stack pointer FSR0=0xC0 banksel ANSELA clrf ANSELA banksel WPUA bsf WPUA, RA3 ; weak pull sur broche reset set_clock_freq FOSC4 set_io_dir SCL_P, OUT set_io_dir SDA_P, OUT set_io_dir WP_P, OUT banksel PORTA ee_wr_disable ee_stop enable_uart_tx enable_uart_rx set_uart_baudrate FREQ_CLOCK, BAUDRATE bsf flags, F_UIDLE bsf flags, F_BLOCK enable_uart_rx_int enable_periph_int enable_interrupts call ee_wait_ready ;;;;;;;; routine principale ;;;;;;;;;;;;;;;;;; main btfss flags, F_RCVD goto main call process_msg goto main end

programme hôte

Comme je l'ai mentionné en introduction j'ai écris le programme en python. Je ne l'ai pas testé sous Linux mais en principe il devrait fonctionner sans modification. Il s'agit d'une application ligne de commande mais l'utilisation est simple.
i2cprog.py port_série mode fichier nombres_octets [-l opp] [-f32]
port_série est le nom du port utilisé pour la communication avec le programmateur.
Sous windows c'est quelque chose comme com3 alors que sous linux ça ressemble à /dev/ttyS0 ou encore /dev/ttyUSB0.
mode est p pour programmer l'eeprom ou r pour lire le contenu de l'eepom.
fichier est le nom du fichier qui contient les données à programmer ou pour le mode r le fichier dans lequel les données seront enregistrées.
nombres_octets est le nombre d'octets à programmer ou lire.
-l opp n'est utilisé que pour la programmation et indique le nombre d'octets par page de l'eeprom. Ce paramètre est essentiel pour la programmation et se retrouve dans le datasheet de l'eeprom utilisée. Par exemple pour 24LC512 ce paramètre est 128.
-f32 n'est utilisé que pour la lecture et sert produire un fichier au format Intel HEX32 plutôt que d'enregistrer les données en binaire brute.
Notez qu'en mode programmation i2cprog.py reconnais les fichiers Intel HEX32 et peut donc en extraire les données pour la programmation. I2cprog.py reconnait aussi les fichiers audio *.WAV 8 et 16bits non compressés. Donc si le nom du fichier se termine par .wav i2cprog.py en extrait le nombre d'octets contenu dans le segment data et l'inscris au début (4 premier octets little indian) ensuite il inscris tous les echantillons dans l'eeprom. J'ai ajouté cette fonctionnalité car c'est exactement ce que j'ai besoin pour mon projet actuel qui sera plublié bientôt sur ce blog.

code source i2cprog.py
#NOM: i2cprog.py #DESCRIPTION: Ce programme est la partie hôte du programmeur eeprom-prog que j'ai créer dans le but de programmer des eeprom à interface # I2C des séries 24AAxxxx/24LCxxxx/24FCxxxxx de Microchip. Pour en savoir plus sur ces mémoires eeprom à interface sériel # visitez le site: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2697 # Ce programme permet aussi de lire le contenu de ces mémoires et de le sauvegarder dans un fichier. # Le programmeur lui-même est un dispositif qui se branche sur un port série de l'ordinateur hôte et communique # avec en configuration 115200,8,N,1 (115200 baud, 8 bits, pas de parité, 1 stop bit). Aucun contrôle de flux matériel. # Le contrôle de flux se fait par le dialogue entre ce programme hôte et le firmware du programmeur. # #AUTEUR: Jacques Deschênes #DATE: 2012-12-28 import argparse import serial import time import wave import sys # NOTE: python ne permettant pas de définir des constantes # dans ce qui suis les variables en LETTRES_CAPITALE en tiennent lieu. ENQ=5 ACK=6 NAK=21 ERR_NONE=0 ERR_CS=1 ERR_COMM_EE=2 ERR_CMD=3 ERR_SYNC=4 ERR_FLASH=100 ERR_FWAR=101 ERR_UNKNOWN=-1 EE_WRITE=0 EE_DATA=1 EE_FLASH=2 EE_READ=3 EE_RDN=4 EE_VER=5 EE_SETB=6 EE_CLRB=7 EE_EOT=8 MAX_BYTES=64 # nombre maximum d'octet envoyés/reçus par transaction. ACCEPT_FIRMWARE=0x10 # version du firmware programmeur reconnue par cette application. class ProgError(Exception): #erreur programmeur def __init__(self, code, msg): self.err_code=code self.msg=msg Exception.__init__(self, 'erreur programmeur {0:d}, {1}'.format(code, msg)) def int2hex(i,width): # converti un entier en chaîne hexadécimale h='' while i>0: n=i%16 if n<10: h=chr(ord('0')+n) + h else: h=chr(ord('A')+n-10) + h; i=int(i/16) while len(h)<width: h = '0'+h return h #enddef int2hex def bytes_to_hex(bytes): # transforme une séquence d'octets en chaîne hexadécimale. s='' for i in range(len(bytes)): s+= int2hex(bytes[i],2) return s #enddef bytes_to_hex def int2chr(bytes): # converti une liste d'octets en chaîne de caractères hexadécimal s='' for i in range(len(bytes)): try: s+=chr(bytes[i]) except ValueError: quit() return s #enddef int2chr def check_prog_error(s): #contrôle la réponse du programmeur signale une exception si erreur if len(s)==2 and ord(s[0])==ACK: return True elif len(s)==2 and ord(s[0])==NAK: if ord(s[1])==ERR_CS: raise ProgError(ERR_CS,'Le programmeur signale une erreur somme de contrôle') elif ord(s[1])==ERR_COMM_EE: raise ProgError(ERR_COMM_EE,'le programmeur signale une erreur comminication i2c') elif ord(s[1])==ERR_CMD: raise ProgError(ERR_CMD,'Le programmeur n\'a pas reconnu la commande') elif ord(s[1])==ERR_SYNC: raise ProgError(ERR_SYNC,'le programmeur n\'est pas en phase avec l\'hote') else: raise ProgError(ERR_UNKNOWN,'Une erreur inconnue s\'est produite') else: raise ProgError(ERR_UNKNOWN,'Une erreur inconnue s\'est produite') #enddef check_prog_error def checksum(bytes): # calcule la somme de contrôle d'une sequence d'octets. cs=0 for i in range(len(bytes)): cs += bytes[i] cs = 0xFF & (~cs + 1) return cs #enddef checksum def send_to_eeprom(ser, data): #envoie le data à l'eeprom et attend la réponse if data[0]==EE_RDN: expect=data[1]+2 else: expect=2 l=len(data)+1 data = [l] + data cs=0 for i in range(len(data)): cs += data[i] cs = (~cs+1) & 0xFF data += [cs] ser.write(int2chr(data)) s=ser.read(expect) if len(s)>2: data=[] for i in range(len(s)): #conversion chaine en liste octets data+=[ord(s[i])] return data elif data[1]==EE_VER and len(s)==2 and ord(s[0])==ACK: return ord(s[1]) return check_prog_error(s) #enddef send_to_eeprom def enquery(ser): # initialise une transaction avec le programmeur ser.write(chr(ENQ)) c=ser.read(1) if not (len(c)==1 and ord(c[0])==ACK): raise ProgError(NAK, 'Pas de reponse du programmeur') fversion=send_to_eeprom(ser,[EE_VER]) if fversion==ACCEPT_FIRMWARE: print 'version firmware programmeur: {0:d}.{1:d}\n'.format(fversion>>4 & 0xF, fversion &0xF) return True else: raise ProgError(ERR_FWAR, 'La version firmware {0:d}.{1:d} du programmeur n\'est pas supporte'.format(fversion>>4 & 0xF, fversion &0xF)) #enddef enquery def send_eot(ser): #fermeture de la transaction avec le programmeur ser.write(chr(2)+chr(EE_EOT)+chr(0xF6)) s=ser.read(2) if len(s)==2 and ord(s[0])==ACK: return True else: print len(s) raise ProgError(ERR_COMM_EE,'Pas de reponse du programmeur au message EE_EOT') #enddef send_eot def read_wave_file(file_name): global byte_count try: wf=wave.open(file_name,'r') except IOError: print 'Echec ouverture du fichier', file_name return None params=wf.getparams() print 'file format:' print 'canaux:', params[0] print 'bits:',params[1]*8 print 'bits/sec.:', params[2] print 'nbre echantillons:', params[3] data=wf.readframes(min(byte_count,params[3])) if params[1]>2: print 'n\'accepte que les fichiers 8 ou 16 bits' return None bytes=[params[3]&0xFF,params[3]>>8 &0xFF, params[3]>>16 &0xFF, params[3]>>24 & 0xFF] for i in range(len(data)): bytes+=[ord(data[i])] print len(bytes), 'echantillons lus' wf.close() byte_count=min(byte_count,len(bytes)) return bytes #enddef read_wave_file def hex_to_int(hex): # conversion chaine hexadecimal en entier n=0 for i in range(len(hex)): if hex[i]>'9': n= n*16 + ord(hex[i])-ord('A')+10 else: n= n*16 + ord(hex[i])-ord('0') return n #enddef hex_to_int def parse_line(line): # extrait les données du texte hexadécimal bytes=[] if line[0]!=':': return None # erreur format ligne i=1 while i<len(line)-1: bytes += [hex_to_int(line[i:i+2])] i+=2 if checksum_ok(bytes): return bytes else: return None #enddef parse_line def read_hex_file(file_name): global start_address, byte_count try: hf=open(file_name,'r') except IOError: print 'Echec ouverture du fichier', file_name return None data=[] done=False state=0 while not done: line=hf.readline() if len(line)>0: bytes=parse_line(line) if bytes: addr=bytes[1]+bytes[2]*256 rtype=bytes[3] if state==0: if rtype==4: high_address=bytes[4]+bytes[5]*256 state=1 else: done=True #erreur format fichier hex elif state==1: if rtype==1: done=True elif rtype==0: start_address=addr + high_address<<16 state==2 data += bytes[4:-1] else: done=True # erreur format fihcier hex elif state==2: if rtype==1: done=True elif rtype==0: data += bytes[4:-1] elif rtype==4: continue else: done=True if len(data)>=byte_count: done=True else: done=True else: done=True hf.close() if len(data)>byte_count: data=data[:byte_count] print 'Nombre d\'octets lus:', len(data) return data #enddef read_hex_file def init_eeprom_write(ser,address): global byte_count high_address=0xFFFF & address>>16 low_address=0xFFFF & address if byte_count>65536: if high_address>0: send_to_eeprom(ser,[EE_SETB]) else: send_to_eeprom(ser,[EE_CLRB]) if not (len(c)==2 and c[0]==ACK): ok=False send_to_eeprom(ser,[EE_WRITE,low_address&0xFF,low_address>>8 & 0xFF]) return #enddef init_eeprom_write def program_eeprom(): global byte_count, file_name ok=True file_name=file_name.lower() if file_name[-4:]=='.wav': data=read_wave_file(file_name) if data==None: ok=False elif file_name[-4:]=='.hex': data=read_hex_file(file_name) if data==None: ok=False else: try: fi=open(file_name,"rb") except IOError: print 'echec ouverture du fichier:', file_name ok = False raw=fi.read(byte_count) fi.close() data=[] for i in range(len(raw)): data+= [ord(raw[i])] if ok: if len(data)!=byte_count: print len(data), 'octets lus dans le fichier' else: print 'Echec lors de la lecture du fichier', file_name if not ok: return i=0 address=start_address init_eeprom_write(ser,address) count=0 chunk_size=min(row_size,MAX_BYTES) while i<len(data): count=min(chunk_size,len(data)-i) bytes=[EE_DATA]+data[i:i+count] send_to_eeprom(ser,bytes) i+=count address+=count if i%row_size==0: sys.stdout.write('*') send_to_eeprom(ser,[EE_FLASH]) init_eeprom_write(ser,address) if i+count%row_size!=0: send_to_eeprom(ser,[EE_FLASH]) print '\nverification programmation:' ee_data=read_eeprom() print '\nlecture completee, nombre d\'octets lus: {0:d}'.format(len(ee_data)) for i in range(len(data)): if ee_data[i]!=data[i]: raise ProgError(ERR_FLASH,'Erreur verification eeprom, offset {0:d}'.format(i)) return #enddef program_eeprom def checksum_ok(s): cs=0 for i in range(len(s)): cs+=s[i] cs = 0xFF & cs if cs==0: return True else: return False #enddef checksum_ok def write_hex32(data): #génère un fichier Intel HEX32 little indian try: fo=open(file_name,"wb") except IOError: print 'echec creation du fichier', file_name return fo.write(':') high_address=start_address>>16 & 0xFFFF low_address=start_address & 0xFFFF bytes=[2,0,0,4,high_address&0xFF,high_address>>8 &0xFF] cs=checksum(bytes) bytes += [cs] fo.write(bytes_to_hex(bytes)+'\n') # les 16 bits les plus fort de l'adresse i=0 while i<len(data): count=min(16,len(data)-i) bytes=[int(count),low_address&0xFF,low_address>>8 & 0xFF,0] for j in range(i,i+count): bytes+=[data[j]] fo.write(':') cs=checksum(bytes) bytes += [cs] fo.write(bytes_to_hex(bytes)+'\n') i+=count low_address += count if low_address>65535: fo.write(':') high_address += 1 low_address &= 0xFFFF bytes=[2,0,0,4,high_address&0xFF,high_address>>8 &0xFF] cs=checksum(bytes) bytes += [cs] fo.write(bytes_to_hex(bytes)+'\n') # les 16 bits les plus fort de l'adresse fo.write(':00000001FF') fo.close() return #enddef write_hex32 def init_eeprom_read(ser,address): high_address = address>>16 & 0xFFFF low_address = address & 0xFFFF if byte_count>65536: if high_address>0: send_to_eeprom(ser,[EE_SETB]) else: send_to_eeprom(ser,[EE_CLRB]) return send_to_eeprom(ser,[EE_READ,low_address&0xFF,low_address>>8 & 0xFF]) #enddef init_eeprom_read def read_eeprom(): print 'debute la lecture eeprom\n' data=[] i=0 address=start_address block=0 if address>65535: block=1 #eeprom > 64KB init_eeprom_read(ser,address) ok=True while ok and i<byte_count: count=min(MAX_BYTES,byte_count-i) if block==0 and address+count>65536: count=65536-address if i%128==0: sys.stdout.write('.') c=send_to_eeprom(ser,[EE_RDN,count]) if len(c)==count+2 and checksum_ok(c): data += c[1:-1] else: ok=False break i+=count address+=count if block==0 and i<byte_count and address>65535: block=1 address=0 send_eot(ser) enquery(ser) init_eeprom_read(address+0x10000) send_eot(ser) return data #enddef read_eeprom def read_arguments(): global device, op_mode, out_format, file_name global byte_count, row_size, start_address parser=argparse.ArgumentParser(description='programme hôte pour la programmation des eeproms i2c de Microchip, à l''aide du prorammmeur i2cprog', usage=""" i2cprog.py com_port p|r file size [-l page_size] [-s start_address] -i32 <com_port> Est le nom du port serie. <p> Invoque le mode programmation. <r> Invoque le mode lecture. <file> En mode programmation c'est le nom du fichier contenant les octets a programmer. Le programme reconnait les extensions: .HEX et.WAV Un fichier se terminant par .HEX doit-etre un fichier au format intel HEX32. Un fichier se terminant par .WAV est considere comme un fichier Microsoft RIFF avec enregistrement WAVE non compresse. Dans ce cas toutes les donnees suivant le mot clef 'data' qui se trouve dans l'entête du fichier sont envoyes a l'eeprom incluant le compte des octets qui est un entier non signe de 32 bits suivant le mot clef 'data'. Si le fichier contient plus d'octets que <size> les octets supplémentaires sont ignores. Les autres fichiers sont lu sans interprétation et les donnees envoyees au programmeur sans alteration. En mode lecture c'est le nom du fichier dans lequel seront enregistrees les donnees. <size> Est le nombre d'octets a lire ou programmer. Le suffixe K peut-êre utilisé pour Kilo (1024). <-l page_size> Ce parametre est inutile pour la lecture mais indispensable pour la programmation. Le 'page size' ou encore 'row size' est specifie dans le datasheet du composant. <-s start_adresse> est optionel et determine a quelle adresse la programmation va debutee. Par defaut elle commence a zero. <-f 32> Par defaut les donnees lues sont sauvegardees dans un format binaire (RAW) mais cette option permet de les sauvegarder au format intel HEX32 lisible dans un editeur de texte. exemple 1: Programmation d'une eeprom 24LC512 qui contient 64KB avec un page_size de 128 i2cprog.py com3 p data.raw 64K -l 128 exemple 2: Lecture d'une eeprom 24FC256 qui contient 32KB. Le contenu est envoye dans eeprom.raw i2cprog.py com3 r eeprom.raw 32K """) parser.add_argument('com_port', help='nom du port serie') parser.add_argument('mode', help='mode programmation/lecture') parser.add_argument('file_name',help='nom du fichier lu/ecris.') parser.add_argument('bytes',help='Nombre d\'octets lus/ecris.') parser.add_argument('-l', help='octets par page') parser.add_argument('-s',help='adresse debut') parser.add_argument('-f',help='format de sortie intel hex32') arguments=parser.parse_args() device=arguments.com_port # port série utilisé par le programmeur op_mode=arguments.mode #programmation 'p' ou lecture 'r' #nombre d'octets à lire ou écrire. if arguments.bytes[-1:]=='K' or arguments.bytes[-1:]=='k': byte_count=1024*int(arguments.bytes[:-1]) else: byte_count=int(arguments.bytes) if op_mode=='p' and arguments.l==None: print 'en mode programmation l''argument <-l> est obligatoire' quit() else: if arguments.l: row_size=int(arguments.l) if row_size==0: print 'parametre <-l> incorrect.' quit() file_name=arguments.file_name out_format=arguments.f if arguments.s: start_address=int(arguments.s) return #enddef read_arguments # ************** main ************************* op_mode=None file_name=None out_format=None start_address=0 row_size=-1 byte_count=0 device=None read_arguments() print 'port serie:', device, 'BAUDRATE: 115200, 8 bits, pas de parite, 1 stop\n' if op_mode=='p': print 'programmation eeprom' print 'fichier source: ' , file_name print 'nombre d\'octets a lire: ', byte_count print 'octets par page: ', row_size else: print 'lecture eeprom' print 'fichier en sortie:', file_name print 'Nombre d\'octets a lire: ', byte_count if out_format==None: print 'format du fichier: binaire' else: print 'format du fichier: Intel HEX32' print 'adresse de debut: ' , start_address print '\nouverture du port' try: ser=serial.Serial(device,115200,timeout=2) except IOError: print 'echec ouverture du port serie' quit() try: enquery(ser) except ProgError, exc: print exc.msg ser.close() quit() if op_mode=='p': try: program_eeprom() except ProgError, exc: print 'une erreur c\'est produite lors de la programmation\ncode={0:d}, {1}'.format(exc.err_code, exc.msg) else: try: data=read_eeprom() if out_format==None: fo=open(file_name,"wb") for i in range(len(data)): fo.write(chr(data[i])) fo.close() else: #out_format==Intel 32HEX write_hex32(data) print '\n', len(data), 'octets lus\n' except ProgError, exc: print 'une erreur c\'est produite lors de la lecture\ncode={0:d}, {1}'.format(exc.err_code, exc.msg) ser.close() #endof i2cprog.py

tous les fichiers du projet sont disponibles ici.

découverte archélogique

Ce soir en fouillant dans le débarras au sous-sol j'ai fait une découverte archéologique. Le 3ième ordinateur personnel que j'ai possédé était un TRS-80 color computer 2 (coco 2). J'ai donné cet ordinateur il y a très longtemps mais j'avais encore en ma possession l'enregistreuse à cassette qui me servait à sauvegarder mes programmes et mes données. Sans surprise après 30+ années d'inactivité elle ne fonctionne plus. Les courroies de catoutchouc du moteur et du cabestan sont éventées. Cependant il y avait aussi une cassette qui a servie à enregistrer des données. Comme l'enregistreuse à un compteur, j'indiquais sur l'index la position de début et fin de chaque enregistrement.

1. compers 0-6
2. trie-rapide 10-15
3. pascal32 20-32

Pour récupérer un enregistrement il fallait faire une avance rapide FAST-F jusqu'à la position désirée avant de peser sur PLAY/CLOAD pour débuter le chargement. Évidemment pour ajouter un enregistrement il fallait dérouler jusqu'après le dernier. Il semble qu'on était pas pressé dans ce temps là.

J'ai encore un lecteur de cassette sur ma chaîne stéréo. J'ai écouté la cassette par curiosité et j'ai reconnu le son caractéristique de ce genre d'enregistrement qui le plus souvent utilisait un standard appellé KCS pour Kansas City Standard. A l'époque il se vendait des cassettes dites numériques qui supposément assurait une meilleure fiabilité des enregistrements, ces dernières coûtaient évidemment plus cher que les cassettes audio standard. Mais comme on peut le voir sur la photo ci-bas. Je me servais de cassettes audio bas de gamme achetées chez Canadian Tire et je n'ai jamais eu de problème. Je suis même confiant que si j'avais encore mon coco 2 je pourrais recharger les données contenue sur celle-ci.

premiers pas avec MCU Atmel AVR

Ça faisait déjà plus d'un mois que j'avais acheter un programmeur Polulu AVR. Ajourd'hui j'ai décidé qu'il était temps de m'y mettre en commencant par le plus simple.

La première étape est de télécharger et installer Atmel studio 6.0.
Il faut ensuite installer le logiciel de Polulu pour le programmeur.

Je dois dire que j'avais préalablement acheter et lu le datasheet du AtTiny13A que j'ai utiliser pour programmer une variante de la LED qui clignote.

Atmel studio 6.0

En suivant les instructions du manuel de démarrage du programmeur Polulu. Ça a été simple de me retrouver dans Atmel studio et d'écrire la première version du programme en C. En effet le studio installe le compilateur avr-gcc ce qui permet de programmer en 'C' dès le départ. J'ai donc branché une LED RBG au AtTiny13A comme suit:

et j'ai relié le programmeur au MCU comme ceci:

Le programme que j'ai écris cycle entre les 3 couleurs du LED RGB et le code source est le suivant:

#define F_CPU 9600000
#define DLY 200
#include <avr/io.h>
#include <util/delay.h>

int main(void)
{

CLKPR= (1<<7);
CLKPR = 0 ; // désactivation du diviseur
PORTB |= (1<<PORTB5); // pullup sur RESET
DDRB |= (0x11<<DDB3|1); // met PORTB broche 0, 3 et 4 en sortie
PORTB &= ~(0x11<<PORTB3|1) ; // eteint tous les LED
while (1){ //boucle infinie

PORTB |= (1<<PORTB3); // allume le LED sur PB3
_delay_ms(DLY);
PORTB &= ~(1<<PORTB3); // éteint le LED sur PB3
PORTB |= (1<<PORTB4); // allume le led sur PB4
_delay_ms(DLY);
PORTB &= ~(1<<PORTB4); // éteint LED sur PB4
PORTB |= 1; // allume LED sur PB0
_delay_ms(DLY);
PORTB &=0xFE ; // éteint LED sur PB0

}

}

Ce programme compilé occupe 164 octets sur les 1K de mémoire flash du ATTiny13A.
Je voulais comparé ça avec le code écris en assembleur. Comme je n'ai jamais programmé en assembleur pour les AVR j'ai fait une recherche rapide dans google pour trouver des exemples et me suis inspiré de ce que j'ai trouvé.

/*
* BlinkRGB.asm
*
* Created: 2012-12-13 13:10:32
* Author: Jacques
* REF: http://jaxcoder.com/Projects.aspx?id=912541054
* http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=94232
* DESCRIPTION: une LED RGB est branché sur PB0,PB3 et PB4 le programme cycle les 3 couleurs
*/


.NOLIST
.include "tn13adef.inc"
.LIST

.equ DLY = 500 ; 500 msec
.equ F_OSC = 9600000 ; 9.6Mhz
.equ LED1 = PORTB0
.equ LED2 = PORTB3
.equ LED3 = PORTB4


.cseg
.org 0

rjmp init

.org 0x20 ; les 32 première addresses sont réservée aux vecteurs d'interruption.
init:

ldi r16, LOW(RAMEND)
out SPL, r16 ; initialisation du pointeur de pile.
ldi r16, 1<<7
ldi r17, 0
out CLKPR, r16
out CLKPR, r17 ; pas de diviseur sur horloge cpu
ldi r16, 1<<PORTB5
out PORTB, r16 ; pullup sur PORTB5 (reset)
ldi r16, (1<<LED2|1<<LED3|LED1)
out DDRB, r16 ; broche LED1,LED2 et LED3 en sortie
ldi r16, ~(1<<LED2|1<<LED3|LED1)
out PORTB, r16 ; éteint les 3 LEDs

main:

sbi PORTB, LED1 ; allume LED1
rcall delay_ms
cbi PORTB, LED1 ; éteint LED1
sbi PORTB, LED2 ; allume LED2
rcall delay_ms
cbi PORTB, LED2 ; éteint LED2
sbi PORTB, LED3 ; allume LED3
rcall delay_ms
cbi PORTB, LED3
rjmp main

delay_ms:
/* sous-routine de délais
count=(dly/Tboucle)=~(dly/Tcy*nbreCycles)
count=(dly/(nbreCycles/F_OSC))
count=(dly*F_OSC/nbreClycles)
*/

ldi r16, 0xFF & (DLY*F_OSC/4000) ; initialise le compteur délais
ldi r17, 0xFF & (DLY*F_OSC/4000)>>8
ldi r18, 0xFF & (DLY*F_OSC/4000)>>16

dly_loop:

dec r16 ; 1tcy
nop ; 1tcy
brne dly_loop ; 2tcy
dec r17
brne dly_loop
dec r18
brne dly_loop
ret

Le code assembleur occupe 68 octets ce qui représente 41% de la version 'C', mais avec un programme plus gros cet 'overhead' paraîtrait moins coûteux. J'ai examiné le code assembleur résultant du 'C' pour voir la différence. Ça tient principalement au code d'initialisation généré par le compilateur et au fait que le délais est inséré comme une macro plutôt que défini comme une sous-routine comme c'est le cas dans ma version en assembleur. J'observe aussi une différence dans la routine de délais. La macro du programme 'C' est la suivante pour _delay_ms

; r24,r25 et r26 servent de registre 24 bits pour le compteur de délais.
.macro _delay_ms ; voir note 1

ldi r24, LOW(@0) ; octet faible du premier argument, aussi: BYTE1(@0)
ldi r25, HIGH(@0) ; 2ième octet du premier argument, aussi: BYTE2(@0)
ldi r26, BYTE3(@0) ; 3ième octet du premier argument

dly_loop:

subi r24, 0x01 ; soustrait 1 à (r24-r25-r26)
sbci r25, 0x00 ; sustraction en tenant compte du carry bit.
sbci r26, 0x00
brne dly_loop

.endmacro

Cette macro utilise une soustraction sur 24 bits au lieu de décrémenter successivement les compteurs. J'ai modifié mon code assembleur pour utiliser cette méthode et je sauve 6 octets:

; constantes ajoutées au début du fichier
; maintenant on divise par 5000 au lieu de 4000
; car il y a 5 cycles dans la boucle au lieu de 4.
; le 1000 c'est pour les millisecondes DLY=500/1000 sec.
.equ DLY1 = 0xFF & (DLY*F_OSC/5000)
.equ DLY2 = 0xFF & (DLY*F_OSC/5000)>>8
.equ DLY3 = 0xFF & (DLY*F_OSC/5000)>>16

delay_ms:
/*
sous-routine de délais
version améliorée
*/

ldi r16, DLY1 ; initialise le compteur délais
ldi r17, DLY2
ldi r18, DLY3

dly_loop:

subi r16, 1 ; 1tcy
sbci r17, 0 ; 1tcy
sbci r18, 0 ; 1tcy
brne dly_loop ; 2tcy
ret

Comparaison avec MCU PIC

Prenons la sous-routine delay_ms et comparons là avec ce qu'on ferais avec un PIC baseline ou mid-range:

ms_delay

movlw DLY1
movwf dly_cntr
movlw DLY2
movwf dly_cntr+1
movlw DLY3
movwf dly_cntr+2 ; 6 instructions pour initialiser le compteur au lieu de 3.

dly_loop

movlw 1
subwf dly_cntr,F
clrw
skpc
subwf dly_cntr+1, F
skpc
subwf dly_cntr+2, F
skpnc
goto dly_loop ; 9 instructions pour la boucle au lieu de 4
return

Ça prend 2 fois plus d'instructions sur un PIC!!. Essayons avec un enhanced midrange:

ms_delay

movlw DLY1
movwf dly_cntr
movlw DLY2
movwf dly_cntr+1
movlw DLY3
movwf dly_cntr+2 ; aucun gain par rapport aux baseline/midrange

dly_loop

movlw 1
subwf dly_cntr, F
clrw
subwfb dly_cntr+1, F ; instruction disponible seulement
subwfb dly_cntr+2, F ; sur les enhanced et extended.
skpnc
goto dly_loop ; gain de 2 instructions grâce à subwfb
return

Grâce à l'instruction subwfb disponible sur les cores enhanced, on sauve 2 instructions mais on est encore à 14/8 en comparaison avec le AVR. De plus grâce aux 32 registres interne au core AVR a n'a utilisé aucune mémoire RAM alors que les PIC en utilisent 3 pour le compteur.

Beaucoup de points positifs pour le core AVR mais tout n'est pas positif. En effet une instruction AVR occupe 2 octets et certaines en prennent 4. Donc pour le AtTiny13a qui a 1K de flash ça veut dire un maximum de 512 instructions. Il faut en tenir compte lorsqu'on choisi un mcu AVR pour un projet. L'autre point négatif est que l'accès à la RAM prend 2 cycles au lieu de 1 pour les PIC. Par contre un cycle AVR c'est un cycle d'horloge alors qu'un cycle PIC c'est 4 cycles d'horloges. Donc un PIC qui a une horloge interne de 16Mhz comme le PIC10F322 a un cycle d'instruction de 250nsec alors qu'un AVR AtTiny13A avec son horloge à 9.6Mhz a un cycle d'instruction de 104nsec. Donc ce qui semblait-être un point négatif au départ est en fait positif. A fréquence d'horloge égales l'AVR est 4 fois plus rapide pour les opérations arithmétiques et logiques qui se font sur ses registres internes et 2 fois plus rapide pour les accès à la RAM. Par contre s'il doit faire une opération sur une variable dans la RAM il doit d'abord la ramené dans un registre internet faire l'opération et la réécrire dans la RAM. Avec 1 PIC si on veut par exemple incrémenter une variable eu peut le faire en 1 seule instruction et 1 seul cycle. Mais avec ses 32 registres internes au core les AVR tiny peuvent faire pas mal de chemin sans utiliser la RAM.

Conclusion

L'expérience a été intéressante et ce n'est surement la dernière fois que je travaille avec des AVR. Au niveau de l'assembleur la richesse du jeux d'instructions à comparer à la pauvreté du jeux PIC baseline et mid-range rends l'expérience plus agréable. Le fait de pouvoir programmer en 'C' sans avoir à acheter un compilateur coûteux est aussi un point intéressant.

---

NOTES:
1) contrairement à mpasm avrasm n'utilise pas de noms pour les arguments de macros.
le nombre maximum d'arguments est de 10 et ils sont nommé @0-@9.
Une définition de macro peut se terminée par .endm ou .endmacro
Toutes les directives de l'asembleur commence par un '.'

tictactoe 3D, conclusion

Ce projet est maintenant complété. J'ai fait un montage sommaire du circuit sur un morceau de bois qui trainait dans le garage. Comme les modules LED ne tenaient pas bien à la vertical j'ai ajouté un morceau d'acrylique pour les tenirs droit.

J'ai ajouté un petit haut-parleur au circuit de la carte mère pour signaler certains événements aux joueurs. Voici le schéma corrigé.

Schéma des manettes de contrôle:

PIC12F1822

Comme c'est la première fois que j'utilise un PIC12F1822 sur ce blogue je vais en faire une brève présentation. Il s'agit d'un MCU à 8 broches avec un coeur enhanced mid-range avec 2KBi de mémoire flash, 128 octets de RAM et 256 octets EEPROM. Mais ce qui rends intéressant les enhanced mid-range c'est l'adressage indexé relatif via les 2 registres FSR. J'ai profité de cette fonctionnalité pour utiliser une façon différence de programmer. Tout en travaillant en assembleur, j'ai en quelque sorte imité le travail d'un compilateur 'C'. C'est à dire que j'ai créé une pile (stack) pour passer les arguments aux sous-routines et aussi pour les variables locales. J'ai défini un ensemble de macros pour faciliter ce travail avec la pile. Le programme ne fait donc pas usage de variables temporaires autres que celles qui sont empilées. L'ensemble des fichiers du projet sont ici.

fonctionnalités

Il ne s'agit pas seulement d'un jeux de tictactoe, le cube de LED peut-être contrôlé à partir d'un PC grâce à un cable sériel RS-232. les paramètres de transmission sont 19200BAUD/8N1 pas de contrôle de flux. Vous trouverez dans le dossier google docs du projet 3 scripts python à titre d'exemple.

Lorsque le jeux est allumé et avant de démarrer la partie, le PC peut transmettre des commandes au contrôleur maître qui les relais au cube. Cependant lorsque la partie est débutée les commandes ne sont plus relayées.

liste des fichiers source.

fichier	contenu
tictactoe3d.asm	firmware des modules LEDs.
pic10f322_m.inc	macros d'usage général pour PIC10F322
tictactoe-master.asm	firmware du contrôleur principal sur la carte-mère.
pic12f1822_m.inc	macros d'usage général pour PIC12F1822

difficultés rencontrées

Je dois dire que le développement du firmware a été plus difficile que je l'aurais cru surtout pour le contrôleur maître. En bonne partie du à ma nouvelle façon de travailler avec une pile. Il faut toujours un certain temps pour s'adapter à une nouvelle méthode de travail. Mais cette méthode vaut la peine d'être explorée et améliorée. Vous noterez dans le code source du fichier controleur-maitre.asm la présence de 2 sous-routines qui n'ont pas été compilées dans la version finales. send_to_pc et display_byte n'étaient que des outils de débogage. La première sous-routine envoie un octet vers le PC et l'autre utilise les modules 1 et 4 du cube pour afficher un octet en base 4. Sans ces outils le travail le n'aurais peut-être jamais aboutis. Ce sont deux exemples de la façon d'utiliser des ressources qui sont déjà disponible dans le projet pour faire du débogage.

conclusion

tictactoe-master.asm n'utilise que 51% de la mémoire programme et 12% de la RAM. Tictactoe3D.asm utilise 63% de la mémoire programme et 23% de la RAM il y a donc encore de la place pour apporter des améliorations et nouvelles fonctionnalités au projet.

mise à jours

2016-09-23 ajout d'une vidéo sur youtube suite à une demande.

tictactoe 3D, partie 3

Le cube est maintenant complété mais pour le moment il n'est contrôlé que par l'ordinateur via le port série. Il me reste à fabriquer 2 gamepads, et à écrire le firmware pour le contrôleur principal qui est un PIC12F1822.

tous les fichiers pour ce projet sont ici

Puisque c'est noël bientôt

puisque que c'est noël bientôt, le script python suivant donne au cube une allure de décoration avec ses 27 LEDS qui changent de couleur continuellement au hasard.

# NOM: random-led.py
# DESCRIPTION: contrôle aléatoire du cube 3x3x3 construit pour le jeux de tictactoe

import serial
import time
import argparse
import random
import msvcrt # windows seulement

done = False

parser=argparse.ArgumentParser(description='script de test pour module 3LED bi-couleurs',
usage='module-test.py [-h] device-name module_id [-n nouvel_id]')
parser.add_argument('serial', help='nom du port serie')
cmd_line=parser.parse_args()

device=cmd_line.serial
ser=serial.Serial(device, 19200,timeout=0)
ser.write(chr(3<<4)) while not done :

module=random.randrange(1,10)
led=random.randrange(0,3)
cmd=random.randrange(1,4)
ser.write(chr(module | led << 4 | cmd << 6)) time.sleep(.05) if msvcrt.kbhit() : # windows seulement, n'importe qu'elle touche arrête le programme.

done=True

ser.close()

J'ai filmé avec mon appareil photo mais la qualité est médiocre.

tictactoe 3D, partie 2

détail du montage des modules LEDs

matériel requis

• 27 LEDs bi-couleurs rouge/vert digikey P/N 67-1124-ND, 52C/10+
• 9 condensateurs céramic 10uF/10V SMD 1206, digikey P/N 445-4057-1-ND, 25,6C/10+
• 9 condensateurs cérmaic 100nF/10V SMD 0402, digikey P/N 445-1265-1-ND, 2,7C/10+
• 9 MCU 10F322T-I/OT, digikey P/N PIC10F322T-I/OTCT-ND, 62,8C/10+
  
• fil 30 AWG 100', digikey P/N K325-ND, 13,15$
• 1 protoboard robotshop P/N RB-Spa-233, 9,95$
  
• 45 broches 100mil,roboshop 2 x P/N RB-Spa-153, 1,50$

Plan de montage

étapes

partie LED

1. Découpez dans la platine 18 morceaux de 2x3 trous. Ces morceaux servent à relier les 3 DELs ensembles et sont repréentés par P1 et P2 sur le dessin.
2. Découpez dans la platine 9 morceaux de 2x7 trous. Ces morceaux servent pour le montage de la base avec le connecteur ICSP et le MCU.
3. Faites les liens sur les morceaux 2x3 tel qu'illustré en bleu sur le dessin. Le lien bleu pâle est fait sur l'autre face.
4. Les fils des LED ont une marque près de la capsule de plastique. Les 2 fils extérieurs, soit le fil pour l'anode rouge et celui de l'anode verte doivent-être écartés du fil central pour qu'il y est une distance de 100mil entre chaque fil. Servez-vous d'une pince à long bec (long nose) et pliez le fil vers l'extérieur juste en en haut de la marque à un angle de 45 degré. Déplacez la pince en bas de la marque et ramené l'extrémité du fil vers le centre pour qu'il soit en parrallèle avec celui de la cathode , comme illustré sur le dessin. Répétez l'opération avec le fil anode verte.
5. Glissez la LED dan les 3 trous d'un morceaux 2x3 jusqu'à ce que le morceau appui sur les coudes. Soudez en place.
   
6. Recommencez les 2 étapes précédentes avec une autre LED.ATTENTION! Le morceau n'est pas dans la même orientation. Sur le morceau P1 qui relie D1 et D2 se sont les fils Cathode et Vert qui sont croisés. Sur le morceau P2 qui relie D2 et D3 ce sont les fils Rouge et Cathode qui sont croisés.
7. Soudez ensemble D1 et D2 ensuite soudez D3 sur la base de D2.

partie base

1. Il n'y a que les 4 broches des extrémités qui sont reliés à des oeillets les broches du centre soit Vss et Vdd tombe entrent les oeillets. En vous servant d'un fil d'étain très fin ajoutez une goute d'étain sur les broches Vss et Vdd.
2. Observez sur le dessin la position du MCU et ajouter une goûte d'étain sur le rebord des oeillets à l'endroit où les broches 1, 3, 4 et 6 seront soudées.
3. En utilisant une pincette pour tenir le MCU par le corps faites refondre l'étain sur l'oeillet qui acceuille la broche 6 et positionnez le MCU en place pendant que l'étain est fondu et retiré le fer en tenant le MCU en place le temps que l'étain fige. Assurez-vous que le MCU est bien positionné. Les broches 2 et 5 ne doivent pas toucher au oeillets adjacents.
   
   
   
   
4. Faites refondre l'étain pour souder les broches 1,3 et 4.
5. Dans la languette de connecteur 100mil découpez une section de 5 borches et placez là à l'endroit indiqué sur le dessin ci-haut en ne soudant que la broche identifiée PGC sur le dessin.
6. Coupez un bout de fil no 30 juste assé long pour rejoindre la broche 2 du MCU à la broche du connecteur identifiée V- sur le dessin. Soudez d'abord le bout qui va sur le MCU en faisant refondre la goûte d'étain qu'on y a mis. Soudez ensuite sur la broche du connecteur.
7. Répétez cette opération pour la broche Vdd.
8. reliez l'oeillet sur lequel est soudé la broche 6 du MCU à la broche du connecteur identifiée Vpp.
9. Le condensateur 100nF au format 0402 est juste assé long pour relié les oeillets V- et V+ en leur partie la plus rapproché. Ce composant est vraiment minuscule et difficile à manipuler. Utilisez une pincette très pointu pour le tenir et faites refondre l'étain sur un des oeillet placez une extrémité du condensateur juste pour affleuré l'étain fondu. Enlevez le fer et laissé figé. Si le condensateur est bien positionné l'autre extrémité devrait effleuré l'autre oeillet. Faites refondre l'étain de cet oeillet pour souder cette extrémitée.
10. Le condensateur 10uF est au format 1206 et et plus facile à manipuler. Il est trop long pour être glissé entre les broches comme l'autre. Il mesure 130mil de long, juste de la bonne longueur pour appuyer ses extrémités sur chaque broche adjacente V- et V+ et le souder en place par refonte de l'étain. Ajoutez de l'étain au besoin.
11. Maintenant il faut positionné la partie LED sur la base. Le fil de l'anode rouge doit-être du côté extérieur tel qu'indiqué sur le dessin.
12. la broche 1 du MCU (RA0) va sur le fil du centre (cathode LED) et continu son chemin jusque sur la broche PGD du connecteur.
13. la broche 3 du MCU (RA1) va sur le fil à l'extérieur (anode rouge) et continu son chemin jusque sur la broche PGC du connecteur.
14. Finalement la broche 4 du MCU (RA2) va sur le fil anode verte du LED.
15. Il ne vous reste plus qu'à insérer le connecteur dans le Pickit 3 et à programmer le MCU et ensuite testez le module avec le script python fournis en partie 1.
16. J'oubliais un petit détail, il faut refaire ça 9 fois. Si vous êtres très motivés en utilisant des PIC12F609 vous pourriez fabriquer 100 modules de 10 LEDS bicouleurs pour un magnifique cube de 10x10x10.

modification d'un servo-moteur pour rotation continue

Lorsque j'explore l'internet au sujet de l'utilisation des micro-controlleurs je constate qu'il y a beaucoup d'intérêt pour les véhicules robots suiveurs de lignes ou autres. Lorsque je magazine sur les sites comme robotshop je constate aussi que si le coût des composants électroniques est très abordable de nos jours il n'en va pas de même pour les pièces mécaniques qui entre dans la fabrication des robots. Entre autre les moteurs avec engreganes utilisés pour motoriser les véhicules robots coûtent chers comparativement à un servo-moteur. Je ne suis pas le seul à l'avoir constaté car nombreux sont ceux qui utilisent des servo-moteurs pour motoriser leur véhicules car ceux-ci sont très abordables contrairement aux premiers. Chez robotshop on peut avoir un petit servo moteur pour aussi peut que 4$. Uh HS-422 coûte 10.49$.


Mais pour utiliser un servo-moteur pour motoriser un véhicule il faut le modifier. Dans cette chronique j'explique comment faire cette modification.

Un servo-moteur est un système asservi. C'est à dire un système qui compare une consigne à un état et modifie l'état jusq'à ce que l'erreur entre la consigne et l'état soit nulle. Dans le cas d'un servo-moteur, l'état contrôlé est la position de l'axe d'un potentiomètre. Il y a donc à l'intérieur du boitier un moteur avec un engrenage et un potientiomètre relié à l'axe de sortie du servo-moteur. En tournant le moteur fait aussi tourner l'axe du potentiomètre. Donc si on remplace le potentiomètre par 2 résistances d'égales valeurs comme indiqué dans le desssin ci-bas, l'erreur ne sera jamais corrigée et le moteur tournera continuellement. Évidemment s'il y a une butée autre que celle qui est dans le potentiomètre il faut l'enlever aussi.
Avec cette modification on a un moteur à rotation continue dont le sens de la rotation peut-être contrôlé.

En fonctionnement pour arrêter le moteur il suffit de lui envoyer des impulsions dont la largeur correspond à la position centrale. Pour le faire tourner vers la gauche (anti-horaire) on lui envoie des impulsions plus étroites et pour le faire tourner vers la droite (sens horaire) on lui envoie des impulsions plus larges que la valeur médiane.

projet TictacToe 3D

J'ai entrepris de construire un jeux de TicTacToe avec un cube de LED bi-couleurs. Au lieu d'utiliser un MCU qui a suffisamment d'E/S pour contrôler les 54 DELS (27 DELs bi-couleurs), j'ai choisi une approche modulaire dans le genre pixdel. Cependant au lieu de contrôler 1 seul DEL RGB avec un PIC10F202, j'utilise un PIC10F322 et je contrôle 3 DELS bi-couleurs rouge/verte. Chaque module représentera une colonne. Il en faudra donc 9. Pour le moment j'ai fait le dévelloppement du firmware pour le module et je l'ai testé en le branchant à un port COM de mon ordinateur. J'ai aussi construit le prototype #1. Au départ j'envisageais 9 modules pour former le cube 3x3x3 et un contrôleur maître servant à la logique du jeux et d'interface avec les 2 joueurs et pour contrôler le cube. Pour le moment seul la première phase est complétée, soit le dévelloppement et la construction d'un module 3 LEDs.
Sur la photo suivante on voie le montage de dévelloppement sur la platine sans soudure avec le premier prototype. Les 2 modules sont branchés sur le convertisseur de niveaux qui reçoit les commandes du script test-module.py. Tous les fichiers sont ici.

Sur cette photo on aperçoie a peine le MCU en format SOT23-6 qui est à l'extrémité droite du connecteur ICSP. Voici une vue en gros plan de la base du module.

expérimentation avec PIC10F322, partie 4, charlieplexing

La technique de multiplexage appellée charlieplexing tire avantage des interfaces 3 états comme ont les retrouvent sur les MCU. Par interface 3 états j'entends un port dont les connections externes peuvent-être configurées en entrée ou en sortie. Il y a effectivement 3 états puisqu'en configuration sortie, on peut avoir un niveau haut ou bas tandis que si la connection est configurée en entrée on a un 3ième état qui est la haute impédance (résistance).

Je disais donc que le charlieplexing tire avantage de ces 3 états en permettant de contrôler un nombre supérieur de dispositifs qu'il y a d'E/S. Le nombre possible est de
N*(N-1)
ou N est le nombre d'E/S utilisées.
Pour cette expérience puisqu'on utilise un PIC10F322 on dispose de 3 broches configurables en entrée ou en sortie. Ce qui nous donne la possibilité de contrôler 6 LEDs. Comme indiqué sur le schéma suivant:

fonctionnement du charlieplexing

Si on se réfère on schéma ci-haut on voit que les LEDs sont connectées entre 2 broches. Si par exemple on veut allumer D1 qui est branchée entre RA0 et RA1, on configure RA0 et RA1 en sortie et on laisse RA2 en mode entrée haute impédance. On met ensuite la Sortie RA1 à 1 et RA0 à 0 de sorte que le courant va passé de RA1 vers RA0 à travers D1. D2 reste éteinte puisque qu'une diode ne conduit pas dans le sens inverse. Pour allumer D2 on inverse les polaritées. C'est à dire qu'on mets RA1 à 0 et RA0 à 1. Les diodes électroluminescentes fonctionnent donc par paires branchées entre les 2 mêmes broches:

• D1 et D2 entre RA0 et RA1
• D3 et D4 entre RA0 et RA2
• D5 et D6 entre RA1 et RA2

Donc pour contrôler D3 et D4 on laisse RA1 en mode entrée et on configure RA0 et RA2 en mode sortie. De même pour contrôler D5 et D6 on laisse RA0 en entrée haute impédance et on configure RA1 et RA2 en mode sortie. De cette manière chacune des 6 LEDs peut-être allumée individuellement. Évidemment on ne peut toutes les allumées en même temps mais à cause de la persistance rétinienne si on allume séquentiellement chacune d'elle à tour de rôle rapidement on a l'impression qu'elles sont toutes allumées en même temps, c'est ce qu'on appelle un affichage multiplexé. Tous les affichages qui utilise un nombre élevé d'éléments sont multiplexés, c'est le cas pour l'éran de votre ordinateur et de votre téléviseur et on a pourtant l'impression que tous les pixels sont allumés en même temps.

expérimentation

Cette expérience utilise le montage illustré dans le schéma ci-haut et le programme charlieplexing.asm. Le fichier de macros pic10f322_m.inc est aussi nécessaire.

Le logiciel a 2 modes de fonctionnement. Le premier mode est un compteur binaire qui compte de 0 à 63 en boucle et le deuxième est un LED allumé qui se promème de gauche à droite et de droite à gauche alternativement. On passe d'un mode à l'autre en pressant le bouton qui est branché sur RA3.

Description du logiciel

Le timer0 est configuré pour générer une interruption à tous les 256usec. La routine d'interruption appelle la sous-routine charlie qui gère l'afficheur. la s.r. charlie affiche le contenu de la variable dsp_byte. A chaque appelle de la s.r. un nouveau bit est affiché. On passe d'un bit à l'autre en boucle. Comme il y a 6 bits à afficher le cycle complet prend 6*256usec, soit 1,5msec. La fréquence de muliplexage est donc de 667Herz. Beaucoup trop rapide pour que l'oeil percoive qu'il n'y a qu'un seul LED d'allumé à la fois. À 70herz l'oeil ne perçoit déjà plus de scintillement.

La routine principale du programme ne fait que gérer la lecture du bouton et le mode de fonctionnement. Dans le mode 0 la variable dsp_byte est simplement incrémentée 4 fois par seconde. Dans le mode 1 tous les bits de dsp_byte sont à zéro sauf 1 et ce bit est déplacé de gauche à droite et de droite-gauche avec les instructions rlf et rrf. A chaque fois que le bit arrive à une extrémitée la direction du déplacement est inversée.

expérimentation avec PIC10F322, partie 3

Dans cette 3ième partie de mes expérimentations avec le PIC10F322, je l'utilise pour produire des sons. Il y a 2 programmes, soundfx.asm et pwm_synth.asm.
Les 2 programmes utilisent le fichier de macros pic10f322_m.inc

Pour réaliser ces expériences j'ai ajouté un petit potentiomètre de 5K sur la platine d'expérimentation présentée en partie 1 de cette série. Ce potientiomètre sert dans le mode VCO du programme soundfx.asm et dans pwm_synth.asm.

effets sonores

Pour réaliser cette expérience vous avez besoin du matériel suivant:

• 1 PIC10F322 ou LF322
• 1 petit haut-parleur
• 1 résistance de 100 ohm
• 1 potientiomètre de 5K (la valeur n'est pas critique)
• 1 bouton à contact momentanée
• 1 platine d'expérimentation sans soudure
• 1 programmeur pickit 3 ou équivalent.

Le montage est le suivant:

Pour cette expérience tous les périphériques du PIC10F322 sont utilisés.

• Le NCO sert de générateur de fréquence audio principal.
• le PWM1 génère une fréquence audio fixe.
• la CLC est utilisée pour additionner (mixer) les sorties du NCO et de PWM1
• la sortie du CLC est connectée à RA2
• Le convertisseur A/N fait la lecture du potentiomètre sur RA0
• le timer 2 alimente le PWM
• le timer 0 est utilisé pour mesurer le temps pour les intervalles.

Le programme a 5 modes de fonctionnement:

1. Silence
2. balayage de fréquence
3. générateur de fréquence contrôlé par un voltage (VCO)
4. gamme musicale
5. mélodie

Le bouton branché sur RA3 permet de passer d'un mode à au suivant en boucle.
Le mode balayage de fréquence balaie de 100hz à 5Khz en montant et en descendant.
Ce signal est mélanger avec une fréquence fixe générée par PWM1 avec une fonction "ou exclusif" dans la cellule logique configurable. L'effet produit est très particulier.

Le mode VCO tant qu'à lui produit une fréquence qui est proportionnel au voltage lu sur le potentiomètre. En tournant le potentiomètre on fait varier la fréquence.

Le mode gamme utilise le NCO pour jouer la gamme musicale tempérée dont les valeurs de
fréquences sont inscrites dans la table scale_table.

Finalement le mode mélodie joue la mélodie We gonna fly now, musique thème du film Rocky 1.

synthès analogique par PWM

Le programme pwm_synth.asm est une illustration de l'utilisation de la modulation par largeur d'impulsion pour produire un signal analogique. Pour cette expérience le haut-parleur doit-être branché sur RA1 en série avec une résistance de 100R. Il faut aussi brancher un potentiomètre de 5K ou 10K aux bornes de l'alimentation avec le contact mobile (celui du centre) sur RA2. En tournant ce potentiomètre on sélectionne la note que le programme fait entendre.

Dans cette expérience le MCU est configuré pour fonctionner à sa vitesse maximale de 16Mhz et le canal PWM2 est utilisé pour générer une onde sinusoïdale. La fréquence du PWM est de 31Khz donc inaudible. J'ai utilisé OpenOffice calc pour calculer les valeurs de la table sine_table¹. ainsi que les délais de transfert des échantillons au PWM. Ces valeurs détermine la largeur d'impulsion que doit générer le PWM au différents angles du cycle de l'onde et le délais de transmission des échantillons pour chaque fréquence. Il y a 90 échantillons, donc un échantillon à tous les 4 degrés considérant qu'un cycle complet représente 360 degrés. La fréquence de l'onde est déterminée par la vitesse avec laquelle on envoie les échantillons au PWM.

délais = (1/fr)/Ns

délais est le délais entre l'envoie de chaque échantillon au pwm.
fr est la fréquence qui doit-être générée.
Ns est le nombre d'échantillons.

exemple pour générer un fréquence 440hz avec les 90 échantillons de la table sine_table

délais = (1/440)/90 = 0,0023/90 = 25 uSec

les valeurs pour le timer0 sont calculées de la façon suivante.

T0val=256 - délais/Tcy + 9
T0val est la valeur d'initialisation du compteur timer0.
délais est la valeur calculée dans la formule précédente.
Tcy est la période de l'horloge système soit 1/(Fosc/4), ce qui à 16Mhz
donne 250nsec.
9 est le nombre de Tcy qui s'écoule avant que le timer0 ne soit réinitialisé par la routine d'interruption.

pour 440Hz on a donc:

T0val = 256 - 25e-6/250e-9 + 9 = 165

J'ai fait un fine tuning des valeurs en mesurant les fréquence réelle à l'oscilloscope, pour être le plus près possible des valeurs de la gamme tempérée.

On entend clairement la fréquence audio dans le haut-parleur mais si on branche un oscilloscope sur la broche RA1 le signale ressemble à ceci:

Ceci est le signal en p3 sur le schéma ci-bas. Difficile de voir une forme sinusoïdale ici.

Si on remplace le haut-parleur avec ce filtre passe-bas pour éliminer le signal PWM, voici ce qu'on voit à l'oscillope.

Au point 2 le signal PWM n'est pas complètement éliminé il chevauche la fréquence audio.

Au point 1 le signal PWM est à peine visible, il ne reste que la fréquence audio synthétisée.

Dans les années 80 tous les ordinateurs personnels n'avaient pas de carte son, un petit haut-parleur était branché à une sortie numérique et tout ce que l'ordinateur pouvait produire c'était des BEEP en ondes rectangulaires. Jusqu'à ce que quelqu'un est l'idée de créer un pilote de périphérique qui pouvait lire un fichier .WAV et le faire entendre dans le haut-parleur. La technique utilisée était celle décrite dans ce démo synthèse analogique par modulation de largeur d'impulsion.

Il faut faut donc pas s'étonner que les périphériques PWM soit si répandus sur les micro-controlleurs, après les minuteries ce sont les périphériques les plus utilisés sur MCU. Au cours de mes chroniques j'en ai illustrer plusieurs usages:

• Contrôle de l'intensité lumineuse d'une DEL.
• Contrôle de la position d'un servo-moteur.
• Contrôle de la vitesse d'un moteur c.c.
• Synthèse de signaux analogiques.

Il y a d'autres usages comme par exemple les régulateurs de tension. En fait le PWM est la méthode la plus efficace pour contrôler et produire des signaux analogiques avec du numérique.

---

NOTES:
1) Notez que pour la table sine_table j'ai utilisé une table da plutôt qu'une table dt. Ce type de table permet d'enregistrer des valeurs plus grandes que 255 dans une location mémoire flash. La mémoire flash étant de 14 bits on peut enregistrer des valeurs de 0 à 16383. j'économise ainsi 90 locations mémoire par rapport à l'utilisation d'une table dt, une réduction de 50%. De plus l'accès dans la routine d'interruption est plus rapide.