Atmel AVR Mikrocontroller mit OpenSuse: I2C, BeispielEEPROM-Ansteuerung

I2C (auch TWI=Two Wire Interface genannt) ist ein sehr hardware-naher De Facto-Standard, mit dem zwei oder mehrere Geräte oder auch Bausteine über einen gemeinsamen Bus miteinander kommunizieren können. Geräte können am Bus als Master oder als Slave teilnehmen. Über die Geräteadresse können mehrere Geräte unterschieden werden. Von verschiedenen Herstellern werden Chips angeboten, die das I2C Protokoll beherrschen. Die größeren AVRs bieten auch Unterstützung für dieses Protokoll.

Die Kommunikation erfolgt bei I2C über zwei Leitungen, SCL (serial clock) und SDA (serial data). Grob gesprochen wird pro Clock-Impuls ein Datenbit übertragen. Über diesem grundlegenden Protokoll sind bestimmte Abfolgen der übertragbaren Kommandos vorgeschrieben. Die Kommandos werden inhaltlich durch das jeweilige Gerät oder den jeweiligen Chip bestimmt. Die grundlegende Spezifikation von I2C ist unter http://www.nxp.com/acrobat/literature/9398/39340011.pdf zu finden.

Im folgenden sind die einfachen Kommandos des Busses kurz dargestellt: START, STOP, Bit-Übertragung, Acknowledgement. Komplexere Dinge bitte in der Spezifikation studieren.


START Condition: Beginn einer Übertragung
Während SCL high gehalten wird, wechselt SDA von high auf low

STOP Condition: Ende einer Übertragung. Während SCL high gehalten wird, wechselt SDA von low auf high

Übertragung eines einzelnen Bits.
Während einer positiven Taktflanke muss SDA stabil gehalten werden auf high oder auf low. Dies ist der übertragene Bit Wert

Acknowledge
Der Slave signalisiert dem Master dass er alle 8 Bits eines Bytes erhalten hat. Dazu gibt der Master die SDA Leitung frei (die unbelastet über den Pullup Widerstand auf high gehalten wird). Der Slave zieht seinerseits die Leitung auf low während der ganzen folgenden (neunten) positiven Taktflanke. Dies interpretiert der Master als Acnowledgement.

Praxis

Beispielhafte Chips sind die seriellen EEPROMs der Reihe 24Cxxx. Ich habe ein EEPROM 24C512 zum Experimentieren verwendet. Der Wert „xxx“ steht dabei für die Speichergröße in KBits (02…1024). Das 24C512 mit 512 KBit=64KByte kann mittels I2C gelesen und beschrieben werden. Das EEPROM kann benutzt werden, wenn die Größe des On-Chip EEPROMs des AVR nicht mehr ausreicht.

Das Protokoll kann in Software implementiert werden oder, wenn vorhanden,  kann die I2C Hardware eines Controllers verwendet werden.

Peter Fleury hat auch hierfür eine Bibliothek geschrieben, für den Hardware-Fall, bei der der AVR als I2C Master auftritt. Diese Bibliothek kann unter  http://homepage.hispeed.ch/peterfleury/i2cmaster.zip heruntergeladen werden. Als Beispiel ist der Zugriff auf ein 24C02 im ZIP File enthalten. Die kleineren EEPROMs kommen mit einer 8-Bit Adresse aus, für die größeren wie das 24C512 benötigt man eine 16-Bit-Adresse.


Pin-Belegung des 24C512.

Das 24C512 hat eine 2-Bit Adresse, so dass 4 solcher Bausteine am I2C-Bus unterschieden werden können. Die „Bausteinklasse“ 24Cxxx hat den festen Adressteil 1010xxxx (Binär) bzw. 0xAx. Die Chip-Adresse wird festgelegt, indem z.B. A0=A1=0 an GND gelegt wird. Dann kann man mit der I2C-Adresse 0xA0 diesen Chip ansprechen. Ein anderer, bei dem A0=1 und A1=0 gelegt wurde, ist mit 0xA1 anzusprechen. A0 und A1 sind 0, wenn sie nicht anders beschaltet werden. „WP“ heißt „Write Protect“, ein Hardware-Schreibschutz, der aktiv ist, wenn WP auf Vcc gelegt wird. Wird er offen gelassen oder auf GND gelegt, kann man das EEPROM auch beschreiben.


Simple Beschaltung des 24C512

Achtung: Auf dem Pollin Experimentierboard ist der WP-Anschluss leider fest auf Vcc gelegt, d.h. man kann ein normal eingestecktes EEPROM nicht beschreiben. Abhilfe schafft Einstecken mit abgebogenem WP-Pin.


24C512 auf dem Pollin Experimentierboard 2.0.  Da bei diesem Board der WP-Pin fest auf Vcc liegt,  muss man das EEPROM mit abgebogenem PIN einstecken, um es beschreiben zu können.

Im folgenden ist der beispielhafte Schreibzugriff dargestellt (der Code von Peter Fleury wurde im wesentlichen nur um die 2-Byte Adressierung erweitert):

#include "i2cmaster.h"

#define Dev24C512  0xA0      // device address of EEPROM 24C512, see datasheet

int main(void) {
     unsigned char val, ret;
     int addr;
 
     i2c_init(); // init I2C interface
 
     ret = i2c_start(Dev24C512+I2C_WRITE); // set device address and write mode
     if ( ret ) {
         /* failed to issue start condition, possibly no device found */
         printf("failed to issue start condition, possibly no device found.n");
         i2c_stop();
     } else {
         /* write 0x75 to eeprom address 0x05 (Byte Write) */
         /* issuing start condition ok, device accessible */
         addr=5;
         val=0x75;
         printf("writing %0x to address %0xn", val, addr ); 
         ret = i2c_write( (addr/256) ); // write hi address 
         if (ret!=0) 
             printf("error in writing value, ret=%0xn", ret );
         ret = i2c_write(  (addr%256) ); // write lo address 
         if (ret!=0) 
             printf("error in writing value, ret=%0xn", ret );
         ret = i2c_write(val); // ret=0 -> Ok, ret=1 -> no ACK 
         //printf("ret=%0xn", ret);
         if (ret!=0) 
             printf("error in writing value, ret=%0xn", ret );
         i2c_stop(); // set stop conditon = release bus
     }
}

Die ganzen dargestellten Prüfungen der Return-Werte sind nicht unbedingt nötig, aber bei der Fehlersuche hilfreich. Das Lesen geschieht wie folgt:

i2c_start_wait(Dev24C512+I2C_WRITE); // set device address and write mode
printf("reading value from address %0x: ", addr ); 
ret = i2c_write( (addr/256) ); // write hi address 
ret = i2c_write(  (addr%256) ); // write lo address 
i2c_rep_start(Dev24C512+I2C_READ); // set device address and read mode
ret = i2c_readNak(); // read one byte
printf("read value=%xn", ret );
i2c_stop();

Mit einem Logik Analysator wurde die Übertragung von Signalen betrachtet. Diese sind im folgenden dargestellt.

Ein AVR überträgt mit Hardware I2C Daten an das EEPROM.

Der Logikanalysator wurde auf asynchron, 200ns clock period gesetzt. Eine positive Taktflanke ist 8 Takte lang, also 1600ns=1,6µs. Die Übertragung eines ganzen Bytes dauert 21µs, so dass man auf eine Übertragungsrate von etwa 50KByte/s kommt. Der AVR kann noch deutlich schneller.


Das erste übertragene Byte, 1010.0000 = 0xa0

Das Byte hier dargestellt mit zusätzlichen Infos

ein weiteres übertragenes Byte, 0000.0101 = 0x05

Das Byte hier dargestellt mit zusätzlichen Infos

Atmel AVR Mikrocontroller mit OpenSuse: RS232-Ansteuerung

RS232-Ansteuerung mit dem AVR kann durch direktes Ansteuern zweier Pins und entsprechendem Code per Hand gemacht werden. Dies ist allerdings aufwendig und nicht notwendig, weil in den meisten AVRs ein UART enthalten ist (manchmal auch zwei), der das Low Level RS232 Handling (Bitschiebereien) schon erledigt. Man muss dann nur noch komfortabel mit Byte-Werten statt mit Bitverschiebungen operieren.

Keine serielle Schnittstelle am PC? Es gibt für unter 10 Euro Kabel, die als Adapter zwischen RS232 und USB dienen können. Unter Linux klinkt sich eine solches Kabel in den Gerätebaum z.B. als „/dev/ttyUSB0“ ein und kann dann genauso wie eine „echte“ serielle Schnittstelle genutzt werden. Bei meinem OpenSuse 11.2 sieht die Einbindung (mittels dmesg ausgegeben) wie folgt aus:

[ 3529.694778] usbserial: USB Serial Driver core
[ 3529.705376] USB Serial support registered for ch341-uart
[ 3529.705409] ch341 6-1:1.0: ch341-uart converter detected
[ 3529.718371] usb 6-1: ch341-uart converter now attached to ttyUSB0
[ 3529.718650] usbcore: registered new interface driver ch341

Die Ansteuerung des UARTs kann mittels Interrupt oder Polling erfolgen.

RS232 mit Polling

Das Polling kann unter C elegant gelöst werden, indem die Funktion fdevopen() genutzt wird. Dieser Funktion werden die beiden grundlegenden Funktionen für das Schreiben und Lesen einzelner Zeichen übergeben. Von da an werden diese Funktionen von den restlichen Funktionen aus „stdio.h“ benutzt, z.B. printf() oder scanf(). Wenn man nur Schreiben will, braucht man die Lesefunktion nicht implementieren und auch nicht übergeben.

In der main() Funktion wird fdevopen() aufgerufen. Die Funktion ioinit() initialisiert den UART.

int main(void) {
     unsigned int c;
 
     ioinit();     fdevopen(uart_putchar, uart_getchar ); 
 
     printf("nnMotor testnn");
 
     for(;;) {
         // input processing via rs232
         c = getchar();
         printf("you entered: %c, %un", c, c);
     }
}

Die Funktion ioinit():

void ioinit(void) {
     UCSRB = _BV(TXEN) | _BV(RXEN); /* tx/rx enable */
     UBRR = (F_CPU / (16 * 19200UL)) - 1; /* 19200 Bd */
     /* initialize TWI clock: 100 kHz clock, TWPS = 0 => prescaler = 1 */
#if defined(TWPS0)
     /* has prescaler (mega128 & newer) */
     TWSR = 0;
#endif
     TWBR = (F_CPU / 100000UL - 16) / 2;
}

Hier die Implementierung der beiden Funktionen für Schreiben und Lesen, welche die UART nutzen (getestet auf ATmega8, bei anderen Chips können sich die  Registernamen unterscheiden):

int uart_putchar(char c, FILE *notused ) {
     if (c == 'n')
         uart_putchar('r',notused);
     loop_until_bit_is_set(UCSRA, UDRE); 
     UDR = c;
     return 0;
}
 
int uart_getchar(FILE *notused) {
     unsigned char c;
 
     loop_until_bit_is_set (UCSRA,RXC); // Wait until a char is received
     c = UDR;
     //uart_putchar (c,NULL);
     return c;
}

uart_putchar() und uart_getchar() können beispielsweise auch so geschrieben werden, dass sie nicht den UART nutzen, sondern z.B. auf ein LCD-Display ausgeben. Das „tolle“ an der ganzen Sache ist, dass dann die Standard-C-IO-Funktionen genutzt werden können.

Wenn Zeichen nur fehlerhaft kommen (Pollin-Board): Sicherstellen, dass die Versorgungsspannung hoch genug ist. Wenn ein AVR via 7805 seine Spannung erhält, die Spannung die in den 7805 hineingeht aber zu niedrig ist (also z.B. auch nur 5V), funktioniert der AVR zwar selbst noch ganz gut, die serielle Schnittstelle ist dann aber nicht mehr fehlerfrei.

RS232 mit Interrupts

Peter Fleury hat eine Bibliothek geschrieben, die Interrupts benutzt und damit nebenläufig zur eigentlichen Anwendung genutzt werden kann.

Ich benutze diese Bibliothek eigentlich immer, weil damit ähnlich wie beim log4j von Java Logging-Ausgaben produziert werden können, so dass man über den Programmverlauf informiert ist. Dazu kann man auf einem PC ein Terminalprogramm (z.B. das schreckliche Standardprogramm bei Windows XP, „Hyperterminal“) laufen lassen und die Ausgaben mitverfolgen. Ist kein Terminal angeschlossen, stört dies den Programmablauf nicht. Allerdings wird der Code etwas langsamer laufen.

Im folgenden Codeauszug ist die Nutzung der Bibliothek dargestellt. „interrupt.h“ und signal.h müssen eingebunden werden, da die Bibliothek Interrupts und Signale benutzt.

Die UART_BAUD_RATE gibt die zu nutzende Baudrate an (das Terminalprogramm muss passen eingestellt werden). In zwei Trivialmakros habe ich mir die häufigsten Aufrufe gekapselt: DI() initialisiert die Bibliothek, DO() gibt einen String mittels uart_puts() aus.

#include "../uart/uart.h"
#include <avr/interrupt.h>
#include <avr/signal.h>
#define UART_BAUD_RATE      19200     /* 9600 baud */
 
#define DI() uart_init( UART_BAUD_SELECT(UART_BAUD_RATE,XTAL_CPU) )
#define DO( m ) uart_puts(m)

...

DI();
/*
 * now enable interrupt, since UART library is interrupt controlled
*/
sei();
DO("after init usartnr");
/* initialize display, cursor off */
lcd_init(LCD_DISP_ON);
 
DO("after init lcdnr");

Im Codebeispiel wird die Bibliothek initialisiert mittels DI() und Interrupts freigegeben (sei()). Danach kann man mittels DO() Ausgaben an das Terminal senden. Dies wird im Beispiel vor und nach dem Funktionsaufruf lcd_init() gemacht.

Die Bibliothek muss im Makefile als zusätzliche Bibliothek eingetragen werden. Die Funktionsprototypen stehen alle im Header „uart.h“, den man im eigenen Programm eintragen muss.


Ausgaben des AVR Controllers mittels der UART-Bibliothek auf einem Terminalprogramm  (Fotografie vom Bildschirm, daher die schlechte Qualität)