IIC nur in C

[carly (Gast)]

Hallo Zusammen,

ich bin auf der Suche nach einer reinen einfachen IIC Routine ohne 
Assembler für einen 8591(AD Wandler). Bisher habe ich die Routinen von 
Peter Fleury verwendet, die auch gut funktionieren.

Zum besseren Verständnis für meine Schüler hätte ich aber gerne eine 
reine C-Routine ohne Assembler. Ich hab mir da zwar was gebastelt (vgl. 
Dateianhang) - funktioniert aber nicht.

Vielen Dank carly

[Werner A. (homebrew)]

wird deine warteschleife vielleicht wegoptimiert? Ich glaube du must die 
variable als volatile deklarieren, damit der compiler meint, sie könnte 
sich auch innerhalb der schleife ändern...

[carly (Gast)]

vielen Dank für deinen Hinweis "volatile" hats aber leider auch nicht 
gebracht;
 carly

[peter (Gast)]

Hallo Carly

Vielleicht kannst Du mit meinen I2C Routinen etwas anfangen..? (Siehe 
Attachement)
Die Funktionen sollte gut überschaubar sein.

MfG  Peter

[TechInfo (Gast)]

Die Procyon avrlib enthält ebenfalls eine sehr umfangreiche I2C-lib.

[Jörg X. (Gast)]

wenn du schon <util/delay.h> include'st, warum benutzt du dann nicht 
auch die entsprechenden Funktionen ??

void i2c_warte(void)
{
 _delay_us(10); // 1µs ist ein Takt bei 1Mhz...
}
//oder auch
#define I2WAIT _delay_us(10);

// und das
sbi(PORTB,SDA);                      // SDA-Leitung ist jetzt Eingang
// .. stimmt irgendwie nicht ;)

(Außerdem mag ich weder sbi()/cbi(), noch mehrere Anweisungen pro 
zeile!!, aber das ist meine Meinung ;) )

hth. jörg

ps.: Hast du mal in der Codesammlung nach twi* oder i2c* gesucht, da 
gibts doch bestimmt C-Routinen

[Simon K. (simon)]

sbi/cbi ist deprecated (veraltet!).

http://www.nongnu.org/avr-libc/user-manual/deprecated.html

PS: Zumindest in der AVR-libc..

[Jörg W. (dl8dtl) (Moderator)]

> sbi/cbi ist deprecated

Er hat ja seine eigene Implementierung drübergeschrieben.

Ich finde die Wahl trotzdem nicht glücklich, gerade auch für Lernende.
Wenn's schon unbedingt in Makros verwurschtelt werden muss, dann
wären SETBIT und CLEARBIT allemal aussagekräftiger.  Eigentlich ist
es aber sinnvoller, gleich noch einen Schritt weiter zu gehen und eine
Art HAL daraus zu machen (hardware abstraction layer), sodass z. B.
die Startbedingung dann aussieht wie:

void i2c_start(void)
{
  SDA_HIGH; i2c_warte();
  SCL_HIGH; i2c_warte();
  SDA_LOW;  i2c_warte();
  SCL_LOW;  i2c_warte();
}

Ansonsten Zustimmung dazu, dass man delays nicht ,,nach Gutdünken''
zimmern sollte, entweder einen Timer oder die Funktionen aus
<util/delay.h> bzw. auch <util/delay_basic.h> nehmen.  Das ist zwar
wieder inline asm, aber in diesem Falle vom Hersteller des Systems,
damit transparent für den Nutzer.  Man kann sogar so weit gehen,
den Lernenden an Hand des aus der ,,privaten'' Zählschleife generierten
(oder besser: nicht generierten) Codes zu zeigen, warum man genau
sowas nicht machen darf und an welchen Stellen der C-Standard dem
Compiler Freiraum für seine Optimierungen gegeben hat.

[Florian (Gast)]

  if (Daten >= 128)
    sbi(PORTB,SDA);
              
    else
    cbi(PORTB,SDA);  
    
    i2c_warte();
         
    sbi(PORTB,SCL);
      Daten <<= 1; 

    i2c_warte();
    cbi(PORTB,SCL); i2c_warte();
  }

Ich finde das >= 128 gefährlich. Je nach Datentyp kann das zu Problemen 
führen nach dem Shift. Besser & 128 verwenden.

[Jörg X. (Gast)]

> Ich finde das >= 128 gefährlich.
> Je nach Datentyp kann das zu Problemen führen nach dem Shift.

Stimmt, der Typ von Daten (die ganz Zeile glaskugelanwerf 
"i2c_schreibe(unsigned char Daten)") fehlt
Es sieht außerdem unlogisch aus und Lernende müssen jedes Mal zwischen 
Bit- und Dezimaldarstellung hin- und herdenken
Ich würde da:

if (Daten & (1<<7))
    ...

nehmen (funktioniert eben auch mit signed-Typen)

hth. Jörg