Probleme mit Protokollen UART/I2c

[Nils K. (nebukadnezar)]

Ahoi liebe Forengemeinde,
ich versuche gerade, mir die Grundlagen der I2C Programmierung 
anzueignen. Habe mir zur  Hilfestellung folgendes Tutorial angeschaut

http://www.rn-wissen.de/index.php/TWI_Slave_mit_avr-gcc

Habe den Code soweit verstanden, an der Umsetzung hapert es noch. Der 
Slave läuft soweit. Laut implementierung  gibt er über UART im 
1/2-Sekunden Takt zehn Zahlen aus.
Die Implementierung des Masters lief leider nicht so gut. Es wird zwar 
alles kompiliert, nur tut sich leider nichts. Um den Master zu testen 
habe ich auch hier eine Ausgabe per UART eingefügt. Nun gibt mir das 
Hyperterminal leider überhaupt nichts aus, noch nicht einmal das 
Initialisieren der UART Schnittstelle (was laut Code per uart_puts 
bestätigt wird). Habe den gleichen Controller genutzt wie beim SLAVE, am 
µC kann es folglich nicht liegen. Bin ein wenig verzweifelt, da der UART 
Code des Masters identisch mit dem des Slave ist. Bei den Controllern 
handelt es sich um Atmega328p, Software ist AtmelStudio6
Über Hilfe würde ich mich sehr freuen!

Hier der Code:

// I2C-Master-Routinen von Peter Fleury verwenden
// siehe http://homepage.hispeed.ch/peterfleury/avr-software.html#libs
// Hier sind auch die Dateien: i2cmaster.h und twimaster.c zu finden, die benötigt werden
// Letztes Update des Codes 5. April 2010 durch HannoHupmann

#include <util/twi.h>       //enthält z.B. die Bezeichnungen für die Statuscodes in TWSR
#include <avr/interrupt.h>  //dient zur Behandlung der Interrupts
#include <stdint.h>       //definiert den Datentyp uint8_t
#include <avr/io.h>
#include "i2cmaster.h"
#include "uart.h"           //UART-Lib von P- Fleury
#include <stdlib.h>         //nötig für Zahlumwandlung mit itoa
#include <util/delay.h>

/* define CPU frequency in Mhz here if not defined in Makefile */
#ifndef F_CPU
#define F_CPU 8000000UL
#endif
#define BAUD 9600 //Baudrate
#define SLAVE_ADRESSE 0x50 //Die Slave-Adresse

uint8_t byte1 = 42;
uint8_t byte2 = 43;
uint8_t byte3 = 44;

int main(void)
{
  //Serielle Schnittstelle aktivieren
  uart_init((UART_BAUD_SELECT((BAUD),F_CPU)));
  uart_puts("I2C-Test\r\n");
  uart_puts("\r\n");
  uart_puts("\r\n"); //Leerzeile

  i2c_init();         // init I2C interface

while(1) {
  if(!(i2c_start(SLAVE_ADRESSE+I2C_WRITE))) //Slave bereit zum schreiben?
  {
    uart_puts("Slave bereit zum schreiben \r\n");
    i2c_write(0x00);  // Buffer Startadresse setzen
    i2c_write(byte1); // Drei Bytes schreiben...
    i2c_write(byte2);
    i2c_write(byte3);
    i2c_stop();       // Zugriff beenden
  }
  else
  {
    /* Hier könnte eine Fehlermeldung ausgegeben werden... */
    uart_puts("Slave nicht bereit zum schreiben \r\n");
  }



  if(!(i2c_start(SLAVE_ADRESSE+I2C_WRITE))) //Slave bereit zum lesen?
  {
    i2c_write(0x00); //Buffer Startadresse zum Auslesen
    i2c_rep_start(SLAVE_ADRESSE+I2C_READ); //Lesen beginnen

    byte1= i2c_readAck(); // Bytes lesen...
    byte2= i2c_readAck();
    byte3= i2c_readNak(); // letztes Byte lesen, darum kein ACK
    i2c_stop();           // Zugriff beenden
  }
  else
  {
    /* Hier könnte eine Fehlermeldung ausgegeben werden... */
  }

  if ((byte1 != 42)||(byte2 != 43)||(byte3 != 44))
  {
    /* Die Bytes wurden nicht korrekt übertragen und wieder gelesen! */
    uart_puts("Slave nicht bereit zum lesen \r\n");
    _delay_ms(500);
  }
}  
//  for(;;);
}

[Karl H. (kbuchegg)]

> #include "uart.h"           //UART-Lib von P- Fleury

Die UART Lib vom Fleury Peter ist interrupt getrieben.
Wenn du also keinen sei() machst, dann laufen auch keine Interrupts und 
dein Programm gibt solange in den internen Puffer aus, bis dieser voll 
ist. Danach hängt dann alles.
Ein sei() VOR dem ersten uart_puts() behebt dieses.

[Nils K. (nebukadnezar)]

Vielen Dank für die schnelle Antwort! Leider ist das problem noch nicht 
ganz behoben. Wenn ich den µC resette, empfange ich drei Zeichen, das 
wars leider auch schon. Diese sind auch nicht das erwartete, sondern 
eher kryptisch. Das Problem hatte ich beim Slave jedoch auch, war aber 
nach 1-2 Sekunden weg.
Bin ein wenig mit meinem Latein am Ende :(

[Karl H. (kbuchegg)]

Nils K. schrieb:
> Vielen Dank für die schnelle Antwort! Leider ist das problem noch nicht
> ganz behoben.

Dann speck erst mal ab.

int main(void)
{
  uart_init((UART_BAUD_SELECT((BAUD),F_CPU)));

  sei();
  while( 1 ) {
    uart_puts("Hello world\r\n");
  }
}

Solange das nicht einwandfrei funktioniert, brauchst du I2C noch nicht 
mit dazu nehmen.

> Wenn ich den µC resette, empfange ich drei Zeichen, das
> wars leider auch schon. Diese sind auch nicht das erwartete, sondern
> eher kryptisch.

"kryptische" zeichen sind meistens ein sicheres Indiz, dass das hier

#ifndef F_CPU
#define F_CPU 8000000UL
#endif

nicht der Realität entspricht. Dein µC läuft nicht mit 8Mhz.

[Nils K. (nebukadnezar)]

Den Tipp mit dem reduzieren des Codes habe ich umgesetzt, kam jetzt 
durchgehend was bei mir anb, leider immernoch Schrott.
Was die Frequenz angeht, war ich mir sehr sicher, dass Frequenz und 
Baudrate stimmen, da es ja beim Slave auch funktionier hat. Um sicher zu 
gehen, habe ich den Code vom Slave nochmal raufgespielt. Dieser geht 
plötzlich auch nicht mehr.
Da ich noch gerne Anfängerfehler mache, hier der Ablauf, wie ich 
Übersetzte, vielleciht ist da ja der Wurm drin:

Programm erstelle ich mit  AVRStudio6 und kompiliere es. Zum übertragen 
nutze ich das myAVR Progtool. Hexfile ausfählen, EEprom in Ruhe lassen, 
brennen. Funktioniert auch immer ohne Fehlermeldung. Bei den Fusebist 
deaktiviere ich "divide clock by 8" um auf 8MHz zu kommen.
Zur Taktfrequent: Auf einen externen Oszillator muss ich verzichten, da 
der Controller in ein Bluetoothmodul (BCA8-BTM) eingebettet ist.

[Eumel (Gast)]

Nils K. schrieb:
> Den Tipp mit dem reduzieren des Codes habe ich umgesetzt, kam jetzt
> durchgehend was bei mir anb, leider immernoch Schrott.
> Was die Frequenz angeht, war ich mir sehr sicher, dass Frequenz und
> Baudrate stimmen, da es ja beim Slave auch funktionier hat. Um sicher zu
> gehen, habe ich den Code vom Slave nochmal raufgespielt. Dieser geht
> plötzlich auch nicht mehr.
> Da ich noch gerne Anfängerfehler mache, hier der Ablauf, wie ich
> Übersetzte, vielleciht ist da ja der Wurm drin:
>
> Programm erstelle ich mit  AVRStudio6 und kompiliere es. Zum übertragen
> nutze ich das myAVR Progtool. Hexfile ausfählen, EEprom in Ruhe lassen,
> brennen. Funktioniert auch immer ohne Fehlermeldung. Bei den Fusebist
> deaktiviere ich "divide clock by 8" um auf 8MHz zu kommen.
> Zur Taktfrequent: Auf einen externen Oszillator muss ich verzichten, da
> der Controller in ein Bluetoothmodul (BCA8-BTM) eingebettet ist.

Also läuft dein Controller mit dem internen RC Taktgeber? Das geht nicht 
gut, du brauchst einen Quarz!

[Malte S. (maltest)]

UART und interner Oszillator ist so eine Sache. Acuh wenn du ihn 
kalibrierst, bleibt die Temperaturabhängigkeit. Zuverlässig ist was 
anderes.

[Nils K. (nebukadnezar)]

Okay, werde mich drum kümmern. Danke!

[Nils K. (nebukadnezar)]

Der Port für die externe Clock (XTAl1/ PB6) ist leider durch eine LED 
belegt. Jetzt funktionieren sowohl das SLAVE als auch das "Hello World" 
Programm. Scheint tatsächlich an der Temperatur gelegen zu haben. Beim 
Master Programm wird die UART-Initmeldung "I2C-Test" wiedergegeben. Das 
wars dann aber auch.  Im Moment habe ich noch keinen I2C Verbindung 
hergestellt, müsste also eine Fehlermeldung erscheinen.
Zum I2C bzw TWI habe ich noch eine Frage:
wenn ich einen Master und einen Slave habe (mehr brauch ich nicht), sind 
dann die Pullupwiderstände nötig?

[Jörg E. (jackfritt)]

9600 baud sollten auch ohne quarz machbar sein.Höhere baudraten werden 
kritischer.

[Karl H. (kbuchegg)]

3% sind 3%. Egal bei welcher Baudrate.

[Jörg E. (jackfritt)]

Du hast Recht sorry nehme alles zurück.

[Nils K. (nebukadnezar)]

Tatsächlich funktioniert es gerade mit 1MHz Takt und einer Baudrate von 
4800, bei 8MHz und höheren baud jedoch nicht. Ist ja auch nur für 
Testzwecke, TWI ist weitaus störender gerade :)

[Nils K. (nebukadnezar)]

Bin ziemlich sicher, dass das Problem an folgender Stelle hängen bleibt.

if(!(i2c_start(SLAVE_ADRESSE+I2C_WRITE))) //Slave bereit zum schreiben?

Laut twimaster.c sehen die Funktionen folgendermaßen aus:

unsigned char i2c_start(unsigned char address)
{
    uint8_t   twst;

  // send START condition
  TWCR = (1<<TWINT) | (1<<TWSTA) | (1<<TWEN);

  // wait until transmission completed
  while(!(TWCR & (1<<TWINT)));

  // check value of TWI Status Register. Mask prescaler bits.
  twst = TW_STATUS & 0xF8;
  if ( (twst != TW_START) && (twst != TW_REP_START)) return 1;

  // send device address
  TWDR = address;
  TWCR = (1<<TWINT) | (1<<TWEN);

  // wail until transmission completed and ACK/NACK has been received
  while(!(TWCR & (1<<TWINT)));

  // check value of TWI Status Register. Mask prescaler bits.
  twst = TW_STATUS & 0xF8;
  if ( (twst != TW_MT_SLA_ACK) && (twst != TW_MR_SLA_ACK) ) return 1;

  return 0;

}/* i2c_start */

unsigned char i2c_write( unsigned char data )
{  
    uint8_t   twst;
    
  // send data to the previously addressed device
  TWDR = data;
  TWCR = (1<<TWINT) | (1<<TWEN);

  // wait until transmission completed
  while(!(TWCR & (1<<TWINT)));

  // check value of TWI Status Register. Mask prescaler bits
  twst = TW_STATUS & 0xF8;
  if( twst != TW_MT_DATA_ACK) return 1;
  return 0;

}/* i2c_write */

Mir ist nicht ganz klar, was dieser Ausdruck bewirkt: 
"i2c_start(SLAVE_ADRESSE+I2C_WRITE)"
SlAVE_ADRESSE erklärt sich selbst, aber warum eine Funktion addieren?

[Georg G. (df2au)]

Nils K. schrieb:
> SlAVE_ADRESSE erklärt sich selbst, aber warum eine Funktion addieren?

Weil in "C" auch GROSS-klein-Schreibung beachtet wird.
Es gibt die Funktion i2c_write und die Konstante I2C_WRITE. Das ist ein 
wenig ungeschickt vom Programmierer, aber legal.

[Jörg E. (jackfritt)]

Das Problem liegt meist darin das der Bus hängt. Ich habe in meine 
Routinen deswegen einen Abbruch nach zeit eingebaut und probiere es 
später nochmal.
Einfach bei den while noch eine zeit mit aufnehmen.

Addieren zur Slave Adresse, weil damit lesen oder schreiben ausgewählt 
wird.
Lies dich nochmal in das Thema ein bzw. den Code.

Gruß,
Jörg

[Nils K. (nebukadnezar)]

Das erklärt einiges, danke! Werd wohl doch nochmal das Datenblatt lesen 
müssen.