Schon wieder: Problem mit I2C (c, mega8, mega 32)

[avrrobot]

Hallo,

Ich hatte schon einmal Probleme mit dem I2C, damals habe ich es dann aber zum laufen gekriegt.
Jetzt habe ich aber ein neues Board gebaut, hier sind die Bedingungen etwas verändert:
Als master habe ich einen Mega32 (getestet mit 2/10 Mhz), dieser hat diesen Code:

#include <avr/io.h>
#include <util/delay.h>
#include <inttypes.h>
#include "i2cmaster.h"  
#include "uart.h"
#include <avr/interrupt.h>
#include <util/twi.h>
#include <stdlib.h>

#define BAUD 2400
#define SLAVE_ADRESSE 0x50


void uart_puti(int val )
{
    char buffer[8];
    uart_puts( itoa(val, buffer, 10) );

}

uint8_t b1 = 0;
uint8_t b2 = 0;

int main()
{
    DDRC |= (1<<PC6);
    uart_init((UART_BAUD_SELECT((BAUD),F_CPU)));
    i2c_init();
    sei();
    uart_puts("Test des I2C am Board:\n");
    while(1)
    {
        i2c_start_wait(SLAVE_ADRESSE+I2C_WRITE);
         i2c_write(0x01);
          i2c_rep_start(SLAVE_ADRESSE+I2C_READ);
          b1 = i2c_readAck();
        uart_puti(b1);
        _delay_ms(200);
          b2 = i2c_readNak();
        uart_puts(b2);
          i2c_stop();
        _delay_ms(500);
        PORTC ^=(1<<PC6);

Die LED leuchtet dann, aber geht nicht aus, also bleibt der Controller irgendwo in der Schleife hängen.
Als Slave habe ich einen Mega8, natürlich auch Pullups, 4,7k. Taktfrequenz: getestet mit 4Mhz bzw. 16 Mhz.
Der Slave läuft mit folgendem Code: (Die Libs sind vom RN-Wissen, bzw von Peter Fleury)

#include "twislave.h"
#include <util/twi.h>
#include <avr/interrupt.h>
#include <stdint.h>
#include <stdlib.h>
#include <avr/io.h>
#include <util/delay.h>


#define SLAVE_ADRESSE 0x50

int main()
{
    init_twi_slave(SLAVE_ADRESSE);
    i2cdata[0] = 5;
    i2cdata[1] = 2;
    while(1)
    {
        i2cdata[0]++;
        i2cdata[1]++;
        _delay_ms(500);
    }
}

Wenn ein paar includes zu viel sind, ich lass die immer da, wenn ich die Controller für andere Sachen getestet habe.
Aber nun zum Hauptproblem:
Wenn ich die Leitungen mit dem Oszilloskop nachmesse, dann ist SDA stets auf High, keine Signale etc.
SCL ist (unerklärlicherweise) stets auf low, ebenfalls keine anderen Signale.
Hat hierzu jemand eine Idee?

MfG avrrobot

[oberallgeier]

Vielleicht probierst Du beim Master : VOR dem i2c_rep_start(~); eíne Kommandozeile i2c_stop(); ?

[avrrobot]

Du hast recht, jetzt geht es, zumindestens einer der beiden Werte, ich erhalte einen hochzählenden Wert über die serielle Schnittstelle und ein "ä",
weist du, woran das liegen könnte? (also das ä)

[oberallgeier]

... ich erhalte einen hochzählenden Wert ... und ein "ä", weist du, ...? (also das ä)

Leider nein. ASCII-ä ist dezimal 228 . . . ist das ne Hilfe ? Fällt Dir dazu etwas ein?

[avrrobot]

Ja, ich hab mich da auch etwas gewundert. Und wenn ich dem read_Nak ein read_Ack schreibe und das Nak später, dann kommt immer ein "-" bei raus, also ascii 45.

[oberallgeier]

... auch etwas ... ein read_Ack schreibe und das Nak später, dann... "-" ...

Hmmm - da müsste ich grübeln (geht jetzt nicht).
ASCII ä = dez 228 = bin 1110 0100
ASCII - = dez 045 = bin 0010 1101

Passiert irgendeine Bitsetzerei im Slave? Ist der Schreib-/Lese-Pointer ok?

Ich habe für meine I²C-Kommunikation (ich meine die zwischen meinen Controllern *gg*) die Lib von Fleury genommen (sieh hier, klick). Das geht bei mir (jetzt) einwandfrei, ob das bei Dir dann helfen würde, weiß ich aber nicht.

[avrrobot]

Nein, ich fürchte, da bin ich mit etwas schusseligen Vertippfehlern drann schuld *hust*.
Erstmal hab ich, wie oben im Quelltext bei b1 zwar uart_puti verwendet, dann allerdings bei b2 uart_puts.
Zuletzt habe ich zu testzwecken mal 0x01 statt 0x00 am Anfang gesendet und bin dann in den bytes verrutscht.
Jetzt geht alles und der einzige echte fehler war dann wohl das mit dem i2c_stop, auf welches du mich aufmerksam gemacht hast.
Danke nochmal!