Forum: Projekte & Code attiny USI Slave Implementierung

SCL Overflowfehler korrigiert.
Axel Gartner

Der slave zieht einmal beim Erkennen der Startbedingung und einmal beim
16-ten SCL Flankenwechsel die SCL Leitung runter. Nachdem der jeweilige
Interrupt abgearbeitet wurde, wird die SCL wieder freigegeben.
Axel

Hi zusammen,

ich bin im Moment auch daran, einen ATtiny als I2C-Slave zu
programmieren, allerdings einen ATtiny45. Ich habe die defines
geändert, sodass die PINS und PORTS stimmen.

Allerdings weiss ich nicht ganz, wie ich das jetzt genau mit meinem
Programm verbinden kann. Ich möchte, wenn die Verbindung hergestellt
ist, irgendwelche Daten, die in einer Variabel gespeichert sind,
zurücksenden.

Wo genau kann ich so etwas denn in den Code einfügen?

Herzlichen Dank schon im Voraus,

Benedikt K.

Hallo,

ich kann dir leider nicht viel Hoffnung machen. Ich hab das auch schon
verzweifelt versucht.

Evtl. hilft dir dieser
http://www.mikrocontroller.net/forum/read-4-271460.html
oder dieser
http://www.mikrocontroller.net/forum/read-1-239761.html
Thread.

Gruß
Michael

In der Tat. Alter Thread. Aber manche Threads wollen einfach nicht 
sterben ... :)

Also. Dank A.K.'s Code habe ich jetzt mal was gesehen auf meinem 
I2C-Bus.
Ich verwende einen ATtiny45 als Slave und den I2C-Tester aus dem 
"ATM18-Projekt" als Master. Wenn ich jetzt mit dem (famosen) I2C-Sniff 
von Peda auf dem Bus lausche, sehe ich, dass Bits verloren gehen, wenn 
der Slave sendet. Ein anderer Slave (mit Hardware-I2C) geht problemlos, 
das vom Master gesendete kommt auch an. Hat jemand einen Tip?
Mit dem DSO nachgemessen fällt mir auf, dass die Datenbits beim 
"Master-Write" etwas nach den Clock-Bits enden (was mir ansich richtig 
erscheint). Beim "Master-Read" (was ja wie erwähnt nicht ganz klappt) 
enden sie aber schon in der frühen fallenden Flanke vom Clock-Bit. 
Könnten meine Probleme damit etwas zu tun haben?

Ist jemand hier weiter?
Und gibt es eine funktionierende CodeVision-Portierung?

Grüße,
Christoph

Hallo...

hier findet ihr eine ausführlice Bibliothek für ein I2C / TWI Interface 
mit dem AVR USI.

http://www.jtronics.de/elektronik-avr/lib-i2ctwi-mit-usi-interface.html

Die Biblitothek ermöglicht eine I2C/TWI Kommunikation über das USI 
Interface von Atmel. Der verwendete Controller wird dabei als Slave in 
dem Bussystem verwendet. Neben Controllern der Reihe ATTiny, wie dem 
ATTiny2313, werden auch eine Reihe von anderen Controllern mit USI 
Interface unterstützt.
Die Bibliothek ist so programmiert, dass der Slave wie ein I2C-Speicher 
(I2C-Epprom) funktioniert.

unterstützt werden bisher folgende Controller:

ATtiny2313, ATtiny25, ATtiny45, ATtiny85, ATtiny26, ATtiny261, 
ATtiny461, ATtiny861, ATmega165, ATmega325, ATmega3250, ATmega645, 
ATmega6450, ATmega329, ATmega3290, ATmega169

Grüße Martin
http://www.jtronics.de

Info...
ich habe die datei nicht angehängt, da sie in Zunkunft noch weiter von 
mir ausgbeaut wird. Damit jeder immer die neuste Version bekommt sollte 
er die Lib von meiner Seite laden.

Hallo, Ich hoffe das hier jemand ein offenes Ohr für mich hat. Ich hab 
mir auch die Lib von Martin gezogen, doch ich kann auf keine Weise den 
Attiny ansprechen. Der Test des Master-Codes mit einem externen EEPROM 
funktioniert wunderbar, doch wenn ich den Attiny verwende, dann bleibt 
der Master hängen. Vllt. könntet ihr mal über den Code schauen, ich hab 
wahrscheinlich Tomaten auf den Augen, sitz auch schon seit 9 an der 
ganzen sache :(

MfG

hier das allgemeine Beispiel von mir, steht auch auf der jtronics.de

1

//############# I2C/TWI Adressen

2

#define Adr_Attiny  0b00110100 

3

4

//############# I2C    ATTiny

5

void read_Attiny(void)

6

{

7

i2c_start_wait(Adr_Attiny + I2C_WRITE); // Adr_Attiny ansprechen

8

i2c_write(0);                          // startadresse zum lesen

9

10

i2c_rep_start (Adr_Attiny + I2C_READ ); // Lesen beginnen 

11

Byte0    = i2c_readAck();         // Byte empfangen 

12

Byte1    = i2c_readAck();         // Byte empfangen  

13

Byte2    = i2c_readAck();         // Byte empfangen  

14

Byte3    = i2c_readNak();         // letes Byte empfangen  

15

16

i2c_stop();                          // stopt I2C Verbindung

17

}

also
1.nimmst du überall die delays raus, so was macht man nicht, da der 
controller in der zeit nur warten und die anderen aufgaben nicht machen 
kann.

2. schreib die Adressen und Befehle bei TWI/I2C lieber binär, ist viel 
übersichtlicher. Du erkennst eher Muster und meist hat jede Bit nummer 
bei einem Befehl ihre Aufgabe.

3.so sollte das aussehen

1

int main(void)

2

{

3

uint8_t buffer;

4

uart_init(UART_BAUD_SELECT(2400, F_CPU));

5

sei();

6

i2c_init();

7

_delay_ms(10);

8

9

//##################################

10

uart_puts("Slave adresse senden\r");// debug

11

12

i2c_start_wait(ATTINY+I2C_WRITE);

13

i2c_write(0);                     // ab Speicherplatz 0 abfragen

14

15

16

uart_puts("Slave lesen\r");         // debug

17

18

i2c_rep_start(ATTINY+I2C_READ);

19

buffer=i2c_readNak();             // lesen

20

i2c_stop();

21

22

uart_puts("Buffer: ");// debug

23

uart_putc(buffer); 

24

uart_putc('\r');

25

26

while(1)

27

  {  

28

  }

29

}

Moin :D

@ Martin
Danke das du dir die Sachen mal angesehen hast, aber selbst mit deinem 
Codeschnipsel funktioniert nix, da bleibt er mir bei Slaveadresse senden 
hängen und ich bin mir eigentlich fast sicher das es am Slave liegt. 
Kannst du dir das mal anschauen ?! Aber so viel kann man da ja ne falsch 
machen, wahrscheinlich bin ich einfach nur zu doof dazu.

MfG

So habs grad nochmal aufgebaut atmega8 mit attiny2313
hab es erst mit dem internen quarz des attiny getestet, geht nicht.
hab einen quarz dran gemacht ... geht.

Der internen quarz der controller ist also zu ungenau.
Ist nix neues, steht ja schon ganz oft im forum.

Die Programme poste ich dir dann noch.
gruß martin

stop zurück, mit internem 8Mhz geht es auch... also jetzt gehts!
Warum es vorher nicht ging, keine ahnung.

hier die datei für den ATtiny2313 Slave bei 8Mhz

Unterstützt werden bisher folgende Controller:

ATtiny2313, ATtiny25, ATtiny45, ATtiny85, ATtiny26, ATtiny261, 
ATtiny461, ATtiny861, ATmega165, ATmega325, ATmega3250, ATmega645, 
ATmega6450, ATmega329, ATmega3290, ATmega169

deinen Controller musst du da mal noch selber implementieren ...
stell dann bitte das neue file hier hoch.

Hier noch eine Version mit überarbeiteten Kommentaren
komplett in Englisch...

Vielen Dank nochmal an Markus für das überarbeiten

Grüße Martin

mhm könnte ein kleiner Fehler sein...
in der usiTwiSlave.c musst du folgendes Ändern

1

#elif   defined( __AVR_ATtiny25__ ) | \

2

  defined( __AVR_ATtiny45__ ) | \

3

  defined( __AVR_ATtiny85__ )

4

  #define DDR_USI             DDRB

5

  #define PORT_USI            PORTB

6

  #define PIN_USI             PINB

7

  #define PORT_USI_SDA        PB0

8

  #define PORT_USI_SCL        PB2

9

  #define PIN_USI_SDA         PINB0

10

  #define PIN_USI_SCL         PINB2

11

  #define USI_START_COND_INT  USICIF     // HIER muss USISIF stehn!!!!

12

  #define USI_START_VECTOR    USI_START_vect

13

  #define USI_OVERFLOW_VECTOR USI_OVF_vect

so sollte dann funktionieren...
testen kann ich das aber net , hab grad kein controller dafür hier.
sag Bescheid, ob es geht.


Viel Erfolg

fein fein

hier die korrigierte Version

kann man hiermit auch einen LM75 Temp. Sensor auslesen?
Oder geht das nur als Master?

Meine Hardware soll in etwa so aussehen:
LM75-->usi Attiny slave-->twi atmega master

Deine Struktur geht so nicht.

Der LM75 wird auch über I2C/TWI angesprochen, von daher kannst du den 
auch gleich mit dem Mater auslesen.

Der Attiny hat außerdem nur einen Hardware TWI, bzw. nur ein USI 
Interface.
Deine Skizze ist somit nur mit einem Software TWI umsetzbar.

Grüße Martin

Martin J. schrieb:
> hier die korrigierte Version

Hallo Martin,

ich versuche momentan die Tiny45-Version zum laufen zu bekommen.

MASTER: ATMega1284P
SLAVES: PCF8563 RTC, DS2482-100 1-Wire Master, ATTiny45 (in EEPROM 
Version) als DCF77 Controller

ATTiny45 -> 1MHz interner Takt aus 8MHz RC-Oszillator
Der Tiny funktioniert als DCF77 Slave anstandslos, synchronisiert ohne 
Probleme und die Daten stimmen.

Die Uhr und auch der 1Wire Bus funktionieren mit den Treibern für den 
ATMega1284 bereits seit mehr als einem Jahr im Dauerbetrieb fehlerfrei.
Sobald der ATTiny mit dabei ist, gibt es sporadische Aussetzer, und die 
RTC und der 1Wire Master sind nicht mehr ansprechbar.

Der ATTiny45 meldet sich garnicht, bzw. erkennt seine Adresse nicht (mit 
Debugger geprüft). Die empfangenen Werte im USIDR / USIBR entsprechen 
nicht den übertragenen Adresswerten. Die empfangenen Adresswerte kommen 
im System nicht vor, gehören also definitiv auch nicht zu den anderen 
Slaves.

Nach Ausfall der Kommunikation wird per WDT-Reset die Kommunikation 
wieder hergestellt, aber der Zyklus beginnt irgendwannn wieder, und 
neben dem ATTiny funktionieren die anderen Slaves auch nicht mehr.

FRAGE: hast Du (oder ein anderer im Forum) einen ATTiny45 schon mit 
anderen (echten Hardware)Slaves gemeinsam betrieben?

Gruß

martin schrieb:
> Die neuste version hast du aber?
> siehe Beiträge weiter oben.
>
> eine noch neuere Version als die oben findest du hier:
> http://www.jtronics.de/avr-projekte/library-i2c/twi-slave-mit-usi-avr

Ja, ich nutze die neueste Library. Ich habe auch bereits die ATTiny 
Clock auf 8 MHz gesetzt, um die schnellste IRQ-Verarbeitung zu 
ermöglichen. Außerdem nutze ich das USIBR anstatt USIDR um keine 
Zeitprobleme bei 400kHz Masterclock zu bekommen. Bisher hat nichts 
geholfen. Seltsam, daß der ATTiny die Kommunikation der anderen Slaves 
stört .....


Wenn der Fall gelöst ist, melde ich mich wieder!

Grüße

martin schrieb:
>  .... viel erfolg

Problem gelöst!

Der ATTiny kann trotz 8 MHz Taktfrequenz (ohne Teiler!) offensichtlich 
keine 400kHz I2C Clock vertragen. Ich werde mir mal die vom C-Compiler 
generierten Interrupt-Routinen anschauen. Im USIDR stehende Daten werden 
wahrscheinlich bereits geshiftet, bevor die IRQ-Routine die Daten 
einlesen kann. Allerdings bringt die Nutzung des USIBR keine 
Verbesserung! Na mal sehen ...

Da es in meine Anwendung kein Problem ist, die I2C-Clock umzuschalten 
kann ich ersteinmal weiterarbeiten. Weitere Infos folgen.

Gruß

Der Link
http://www.jtronics.de/elektronik-avr/lib-i2ctwi-mit-usi-interface.html
liefert mir eine eigenartige Fehlermeldung mit SeaMonkey 2.6:

>Umleitungsschleife
>Limit für Umleitungen dieser URL überschritten. Die angeforderte Seite konnte 
nicht geladen werden. Dies könnte von blockierten Cookies verursacht werden.
>Der Verbindungsversuch zur aufgerufenen Adresse wurde abgebrochen. Die 
>aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden >kann.
>Haben Sie Cookies, die von dieser Website benötigt werden, deaktiviert oder 
>blockiert?
>HINWEIS: Falls das Akzeptieren von Cookies die Probleme mit der aufgerufenen 
Adresse nicht behebt, handelt es sich vermutlich um eine Fehlkonfiguration des 
Servers und nicht um einen Fehler Ihres Computers.

Habe allerdings keine Cookies blockiert. Mein Browser akzeptiert alle 
Cookies für diese Session.

Hallo

http://www.jtronics.de/avr-projekte.html?start=7

Der Link sollte funktionieren.

Ich habe ein anderes Problem:

Der Master ist mittels Hardware TWI auf einem Mega8 realisiert.
Ich schreibe ein Byte auf den controller, und möchte danach die 
Übertragung beenden.

Das was passiert ist leider, das der ATTiny 24 mit seiner 
USI-Schnittstelle den Bus blockiert, in dem er die SDA Leitung auf masse 
behält.

Meine eigene implementierung mit read_nack am slave funktioniert leider 
nicht.

der Master läuft mit 8MHz, ebenso der Slave (tiny)

Die gleiche Sache mit Hardware-TWI programmiert läuft einwandfrei.
Ich habe auch so das gefühl, das USI TWI ein deutlich größerer 
Software-Aufwand ist als Software TWI

Auch normale i2c eeproms funktionieren problemlos

Nachtrag:

Ich hab es hinbekommen.

Ganz dummer Fehler, ich habe eine Code-Zeile auskommentiert gehabt, und 
diese Codezeile hätte nicht auskommentiert werden dürfen.

Hat jemand den Code schon mal für einen ATMega8 umgebaut? geht das oder 
spricht technisch was dagegen?

genügt es folgende Ergänzung zu machen?

1

#elif   defined( __AVR_ATmega8__ )

2

    #define DDR_USI             DDRC

3

    #define PORT_USI            PORTC

4

    #define PIN_USI             PINC

5

    #define PORT_USI_SDA        PC4

6

    #define PORT_USI_SCL        PC5

7

    #define PIN_USI_SDA         PINC4

8

    #define PIN_USI_SCL         PINC5

9

    #define USI_START_COND_INT  USISIF

10

    #define USI_START_VECTOR    USI_START_vect

11

    #define USI_OVERFLOW_VECTOR USI_OVERFLOW_vect

hat doch sicher schon mal einer probiert oder?

Hallo zusammen,

habe auf einem ATTiny2313 die USI-TWI Slave 
http://www.jtronics.de/avr-projekte/library-i2c-twi-slave-usi.html zum 
Laufen gebracht.

Soweit - sogut! Hat schön funktioniert, kann den 2313 über Raspberry PI 
wunderbar ansteuern und auch abfragen.

Der 2313 ist bei mit 8 Mhz intern getaktet - kein CKDIV8 gesetzt.

Wenn ich nun zusätzlich den Timer0 im CTC Modus aktiviere, kann ich vom 
Raspberri Pi nicht mehr den Slave ansprechen. Irgendetwas im Timing 
scheint sich auf dem I2C Bus zu verändern.

Dabei arbeit in die Timer0 - Interrupt Routine (8bit) nur noch den 
Befehl "uint8_t Zaehler++" ab.

Nun meine Frage zur Theorie: Eigentlich dachte ich, dass die Timer (bis 
auf den Interrupt) keine Prozessor Zeit beanspruchen.
In der Interrupt Routine steht ja auch nur ein minimalistischer Befehl. 
Der Interrupt und dieser Befehl können doch nicht so zeitkritisch sein 
???

Kann mich da mal bitte ein Wissender aufklären, in welchen Konflikt ich 
reinlaufe, bzw. wie ich die Thematik in den Griff kriege?
Sind TWI-Slave Impelementierungen auf einem Atmel so sensibel ?

Muss ich die Interrupts gegeneinander verriegeln, oder macht der 
Prozessor dies eigenständig?

Danke im voraus!

Hallo,

Bitte hänge dein gesamtes Programm noch an.
So ist das nur Raten..

Uwe S. schrieb:
> Hallo,
>
> Bitte hänge dein gesamtes Programm noch an.
> So ist das nur Raten..

Also, dann mal das Programm:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>

//###################################################################### 
########

//USI TWI Slave driver - ATTiny2313

//Fuses: Ext FF; Hi DF; Lo 64

#include   <stdlib.h>
#include   <avr/io.h>
#include   <avr/interrupt.h>
#include   <avr/pgmspace.h>

//################################################################## 
USI-TWI-I2C

#include   "usiTwiSlave.h"
#define   SLAVE_ADDR_ATTINY       0x22

#ifndef   F_CPU
#define   F_CPU 8000000UL
#endif

  uint8_t    Farbe;

  uint8_t    PWM;
  uint8_t    PWM2_Wert;
  uint8_t    PWM3_Wert;
  uint8_t    PWM4_Wert;

int main(void)
{

//##################################################################

  DDRD  |= (1 << PD2);
  DDRD  |= (1 << PD3);
  DDRD  |= (1 << PD4);

  PORTD  &= ~(1 << PIN2);
  PORTD  &= ~(1 << PIN3);
  PORTD  &= ~(1 << PIN4);


// Timer 0 konfigurieren
  TCCR0A = (1<<WGM01); // CTC Modus

  TCCR0B |= (1<<CS00); // No Prescaler

  OCR0A = 55;

  TIMSK |= (1<<OCIE0A);

  sei();  // Global Interrupts aktivieren

//################################################################# Main 
routine

  cli();  // Disable interrupts

  usiTwiSlaveInit(SLAVE_ADDR_ATTINY);  // TWI slave init

  sei();  // Re-enable interrupts

  while(1)
  {

  Farbe  = rxbuffer[0];

  PWM2_Wert  = rxbuffer[1];
  PWM3_Wert  = rxbuffer[2];
  PWM4_Wert  = rxbuffer[3];

  txbuffer[0]= Farbe;

  txbuffer[1] = PWM2_Wert;
  txbuffer[2]  = PWM3_Wert;
  txbuffer[3]  = PWM4_Wert;


  if (PWM >= PWM2_Wert)
  {
    PORTD &= ~(1 << PIN2);
  }
  else
  {
    PORTD |= (1 << PIN2);
  }

  if (PWM >= PWM3_Wert)
  {
    PORTD &= ~(1 << PIN3);
  }
  else
  {
    PORTD |= (1 << PIN3);
  }

  if (PWM >= PWM4_Wert)
  {
    PORTD &= ~(1 << PIN4);
  }
  else
  {
    PORTD |= (1 << PIN4);
  }
}

ISR (TIMER0_COMPA_vect)
{
  PWM ++;
}

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 
<<<


Die entsprechenden ISR Slave Routinen sind bekannt
http://www.jtronics.de/avr-projekte/library-i2c-twi-slave-usi.html

Danke im voraus

Hallo Hendrik,

55 (DEZ) im Timer0 CompareRegister und Vorteiler 1:1 bedeutet:

alle 6,8 us einen Interrupt (1/8MHz * 55).

In der IRQ-Routine passiert ja noch (etwas) mehr als nur die Addition.

Der Interrupt hat eine höhere Priorität als die USI IRQ's, so dass für 
das sensible Timing in der ACK/NAK Phase eventuell Probleme enstehen 
können.
Soweit ich mich erinnere werden in der USI-Lib die IRQ Routinen nicht 
als kritische Bereiche (CLI;SEI) höher priorisiert.

Teste das doch mal mit 255 = 31 us oder einfach mit einem höheren 
Vorteiler.
Oder sperre die T0 IRQ's zum Test innerhalb der USI Interruptroutinen.

Gruß

Hallo Reiner,

habe mal den Gegentest gemacht:

1. Teiler auf 1024
2. OCR0A auf 250
3. Alle Abfragen in der Main Routine auskommentiert
4. Timer ISRs in den USI ISR Routinen gesperrt!!!

NO! geht definitiv nicht.

Gegentest ohne Timer ISR: Funzt!

Ich habe folgende Beobachtungen gemacht (mit Logicport)

Das ganze käuft unter 3,3 Volt (stabilisiert). Verändere ich den Trigger 
Level im LogicPort von 0,5 Volt auf 1,2 Volt, liegen die interpretierten 
Adressen (im LogicPort) schon mal daneben (anstelle x21 wird x42 
interpretiert).

Das stellt für mich die I2C Schnittstelle des Raspberry PI mal 
grundsätzlich hinsichtlich Robustheit (Flankensteilheit ?) in Frage - 
Linux ist ja auch kein Echtzeitsystem - haben mir ja schon viele gesagt!

Ausserdem scheint mir die USI-Slave Implementierung bei 8Mhz in einem 
2313 ebenfalls nicht so robust - oder positiv gesagt, filigran zu sein. 
Habe noch einmal den Gegentest ohne Timer ISR gemacht - funzt.

Das Oszilloskop zeigt mir als Zeitdifferenz zwischen ACK und NAK ca. 3 
-4 usec an. Das ist natürlich bedenklich wenig, wennn Interrupts 
irgendeine Reaktion verhindern sollten. Nun ist ja ein ATTiny2313 ja 
auch nicht ein "Präzsionsinstrument..."  Schade um die bisher 
investierte Zeit.

Einen letzten Versuch werde ich demnächts noch machen, indem ich einen 
externen Quarz mit 16 Mhz anschliesse. Mal schaun, was passiert. 
Gerüchteweise soll ja der interne weniger stabil sein - und doppelte 
Taktfrquenz hilft vielleicht.

Ansonsten werde ich (sollte kein systematischer Fehler vorliegen) wohl 
auf asynchrone Kommunikation umsteigen.

Danke im voraus (falls jemanden noch etwas einfallen sollte)

Hendrik L. schrieb:
> Die entsprechenden ISR Slave Routinen sind bekannt

Nein.
Es hat keiner Lust, Deinen Code zusammen suchen zu müssen.
Weißt Du nicht, was ein "Dateianhang" ist und wie man ein Zip aus allen 
nötigen *.c, *.h erzeugt?


Peter

Hallo Hendrik,

beim RasPI ist die Hardware I2C Schnittstelle schon o.k. ! Ich habe die 
mit verschiedenen Slaves ohne Probleme im Betrieb. Es liegt wohl eher am 
ATtiny. Die USI-Implementation macht bei mir bis 100 kHz keine Probleme, 
danach treten sporadisch auf dem I2C-Bus Probleme auf (andere Slaves 
'hängen' und blockieren den BUS), was auf Probleme mit dem USI Timing 
deuten. Ist halt nur eine Notlösung.

Bei anderen ATMEL Typen mit Hardware I2C habe ich noch nie irgendwelche 
Probleme bis 400 kHz gesehen!

Es gibt allerdings auch 14/20 Pin MCUs welche bis zu 1 MHz Clock als 
Slave vertragen ;-) (mit 8 MHz interner Clock) Dazu gibts dann noch frei 
einstellbare IRQ Prioritäten! Du solltest Dir eine MCU passend zur 
Aufgabe suchen!

Gruß

Reiner Geiger schrieb:
> das sensible Timing in der ACK/NAK Phase eventuell Probleme enstehen
> können.

Nein.
Beim I2C ist nichts sensibel, alle Takte können beliebig lang sein. Der 
I2C synchronisiert sich immer auf den langsamsten Teilnehmer.
Das ist ein riesen Vorteil gegenüber SPI, es können keine Daten verloren 
gehen.

Natürlich muß der Slave das Clock Stretching einschalten und der Master 
zum I2C-Standard konform sein, d.h. das SCL abfragen, bis es wieder high 
ist.
Genau deshalb ist nämlich auch SCL open-drain und nicht nur SDA.


Peter

Hallo Peter,

stimmt genau!

Leider wird bei der USI Implementation von I2C einiges mit Software 
erledigt; das funktioniert eben nur mit passenden Kombinationen von I2C 
Takt und MCU-Takt. Das gleiche Problem findet man ebenfalls wenn durch 
Leitungskapazitäten eine kleine Verzögerung eintritt und das 
Clock-Stretching knapp vom Master verpasst wird. Dann hilft nur eine 
kleinere I2C taktrate. Deswegen gibt es mit der USI-Implementierung ab 
100 kHz Probleme mit manchen Slaves ( z.B. ds2482-100 ).

Gruß

Peter Dannegger schrieb:
> Hendrik L. schrieb:
>> Die entsprechenden ISR Slave Routinen sind bekannt
>
> Nein.
> Es hat keiner Lust, Deinen Code zusammen suchen zu müssen.
> Weißt Du nicht, was ein "Dateianhang" ist und wie man ein Zip aus allen
> nötigen *.c, *.h erzeugt?
>
>
> Peter

Hallo Peter,

Der Rest ist gar nicht MEIN Code - sondern der von 
http://www.jtronics.de/avr-projekte/library-i2c-twi-slave.html. Habe ich 
oben schon gesagt.

Andere *.c und *.h Files (von mir) gibt es nicht, nur die jtronics!

In den jtronics Dateien habe ich auch nichts verändert - ich stelle 
diesen Code auch nicht in Frage, ist er doch in allen relevanten Foren 
empfohlen.

Gehe also davon aus, dass in den Basics die Lösung nicht zu suchen ist - 
wenn, liegt der "Fehler" darin, dass die Timer0 ISR  irgendwie das 
Timing zu Lasten der USI ISR verändert - was ich aber nicht verstehe!

Ich habe zwischenzeitlich sogar auch den Code aus der Timer0 ISR 
komplett entfernt!

ISR (TIMER0_COMPA_vect)
{

//  PWM ++;

}

Ändert gar nichts! Nur wenn ich alles


//  TCCR0A = (1<<WGM01); // CTC Modus

//  TCCR0B |=  (1<<CS02) | (1<<CS00); // Prescaler 1024
//  OCR0A = 250;

//  TIMSK |= (1<<OCIE0A);

auskommentiert habe, funzt die Kommunikation SICHER.

Zwischendurch bei eingeschaltetem Timer0 und ISR sporadisch ... - je 
nach Kombination von PreScaler und OCRA0 - aber nicht zuverlässig, mal 
ja mal
nein!

Mit Abschlußwiderständen 10kOhm habe ich auch schon gespielt - bringt 
nichts.
Ein anderer Tiny 2313 - bringt nichts - Gegencheck - verhält sich 
genauso.

Ein Check mit einem PCF 8574AP hat unter allen Betriebszuständen eine 
saubere Adressierbarkeit mit dem Raspberry Pi ergeben.

Ich denke, ein ATTiny2313 mit 8 Mhz ist grenzwertg für eine 400 khz TWI- 
Slave Software Implementierung - wobei ich mir das Phänomen "geht nicht 
in Kombination mit Timer0 ISR" nun bei "leerer ISR" (siehe oben) nicht 
mehr erklären - kann (mit meinem bescheidenen Halbwissen - in aller 
Demut - daher meine Fragestellung an die Experten!).

Weiß jemand evtl., ob ich (und wie) den SCL Takt an der Raspberry PI I2C 
Schnittstelle auf sagen wir mal 100 Khz runter bekomme ? 10khz würden 
mir auch schon reichen!

Danke!

Hendrik L. schrieb:
> Ein Check mit einem PCF 8574AP hat unter allen Betriebszuständen eine
> saubere Adressierbarkeit mit dem Raspberry Pi ergeben.

Der PCF8574 ist kein MC, d.h. SCL ist nur Eingang, da auf dem PCF8574 
kein Programm läuft und somit auf nichts gewartet werden muß.

Wenn der Raspberry Pi das Clock-Stretching nicht beachtet, ist das der 
Grund, warum ein dummmer I2C-Chip funktioniert, aber ein MC nicht.
In diesem Fall braucht man für den Raspberry Pi einfach nur eine korrekt 
implementierte I2C-Lib, damit man auch MCs als I2C-Slave ansprechen 
kann.


Peter

Hendrik L. schrieb:
>
> Weiß jemand evtl., ob ich (und wie) den SCL Takt an der Raspberry PI I2C
> Schnittstelle auf sagen wir mal 100 Khz runter bekomme ? 10khz würden
> mir auch schon reichen!
>
> Danke!

http://doc.byvac.com/index.php5?title=RPI_I2C

;-)

Reiner Geiger schrieb:
> Hendrik L. schrieb:
>>
>> Weiß jemand evtl., ob ich (und wie) den SCL Takt an der Raspberry PI I2C
>> Schnittstelle auf sagen wir mal 100 Khz runter bekomme ? 10khz würden
>> mir auch schon reichen!
>>
>> Danke!
>
> http://doc.byvac.com/index.php5?title=RPI_I2C
>
> ;-)

Hallo Reiner,

vielsten Dank - da steht es ja - RPI hat kein Clock Stretching!

Werde berichten!

Vielen Dank!

Soooo ...!

Nachdem ich wie angeregt die TWI Taktrate des RPI von 400 kHz auf ca. 66 
kHz (gemessen) verringert habe, läuft die Koppelung nun stabil.

Es hatte zwar noch einige Hänger gegeben, aber aus irgendwelchen Gründen 
läuft das System JETZT stabil (ohne Hänger). Irgendwie schon etwas 
mysteriös.

Die PWM Addition und den restlichen Code habe ich wieder aktiviert, der 
Prescaler ist nun ausgeschaltet - immer noch alles stabil!

Etliche Stunden investiert - ganz schön nervend.

Vielen Dank für Eure Hilfe!

Gruß

Nach 4 Stunden Weiterentwickung meines Programms und damit verbundenem 
Testing unter allen "Betriebszuständen":

Kein einziger Ausfall mehr, selbst bei Erweiterung des Programm Codes in 
der ISR-Timer0!

Damit ist für mich diese Master-Slave-Codierung robust. Dank an den 
Ersteller des Programms.

Guten Rutsch an Alle!

Hallo zusammen,

leider funzt die obige Lösung 1 der I2C Bus Verlangsammung nur bei der 
256 MB Raspberry Pi Variante (Version 1.0).

Bei der 512 MB Version (2.0) wurde die GPIO Belegung neu festgelegt, 
I2C-0 wurde von der Stiftleiste genommen, stattdessen wurde I2C-1 dort 
herausgeführt.

Die "schnelle Lösung" (Register Patch) funzt aber nur beim I2C-0, der 
nun nicht mehr einfach über die Stiftleiste zugänglich ist.

Habe darum die in der Lösung 2 empfohlenen "Ersatz- I2C Routinen" neu 
installiert - nach dieser Anleitung 
http://doc.byvac.com/index.php5?title=RPI_I2C#Devices_requiring_Option1_or_2. 
Sie hat zudem den Vorteil, dass man auf jede beliebige Pin Paarung einen 
I2C Bus beim Raspberry Pi legen kann (also auch mehrere).

War nicht ganz einfach - aber wenn man der Anweisung exakt folgt, klappt 
alles wunderbar.

Damit kann man im Master jede Busgeschwindigkeit einstellen. Und der 
ATTINY2313 als Slave antwortet bei niedriger Geschwindigkeit wunderbar!

Gruß

Hallo,
vielleicht dir hier jemand helfen, da hatte letztes auch jemand 
Problemen mit den ATtinys. Frag doch mal wie er es gelöst hat.
http://www.jtronics.de/forum/viewtopic.php?f=7&t=303

Lösen konnte ich das leider nicht (Attiny I2C mit USI war einfach nicht 
stabil als Slave [Master: Atmega]). Habe aufgegeben und statt eines Tiny 
einen Atmega mit TWI als Slave genommen.

Der Vollständigkeit halber:

bezüglich der jtronics library 
(http://www.jtronics.de/avr-projekte/library-i2c-twi-slave-usi.html 
Webseite verweist auf diesen Thread hier). Bei mir (und noch mindestens 
einem anderen, zum Beispiel hier: 
http://forum.arduino.cc/index.php?topic=160147.0 welcher eine Library 
benutzt die ihrerseits auf der oben erwähnten usiTwiSlave library 
aufbaut und das selbe Symptom zeigt) ist das Problem aufgetreten daß der 
Slave nur mit Adressen < 64 zuverlässig funktionierte, insbesondere wenn 
andere Interrupts auf dem Slave mit im Spiel waren und das clock 
stretching direkt nach der Startbedingung erforderlich wurde.

Der Grund war die falsche Erkennung der Startbedingung: Direkt nach der 
Startbedingung legt der Master das höchste Adressbit (im Falle von 
Adressen zwischen 64 und 127 wäre das eine 1) auf SDA, gibt SCL frei und 
wartet darauf dass der Slave ebenfalls SCL freigibt.

Der Slave muss nun im ISR(USI_START_VECTOR) ermitteln ob eine Start- 
oder eine Stopbedingung vorliegt.

usiTwiSlave.c verwendet dazu irrtümlicherweise diese Zeile code

1

if ( !( PIN_USI & ( 1 << PIN_USI_SDA ) ) )

Und das kann nicht zuverlässig funktionieren, SDA ist zu diesem 
Zeitpunkt undefiniert und wenn die Slave-Adresse > 63 ist dann ist die 
Wahrscheinlichkeit hoch dass zu diesem Zeitpunkt SDA bereits high ist, 
insbesondere wenn der Interrupt verzögert ausgelöst wird und der Slave 
daher schon eine Weile auf der Taktleitung steht.

Der folgende Patch sollte das Problem beheben (bei mir tut er es, 
seither rennt der Slave auf dem Tiny zuverlässig mit 400kHz ohne 
jegliche Aussetzer):

1

--- usiTwiSlave_old.c  2011-10-21 12:17:44.000000000 +0200

2

+++ usiTwiSlave.c  2014-10-25 17:00:17.794250296 +0200

3

@@ -255,7 +255,7 @@

4

5

   while (  ( PIN_USI & ( 1 << PIN_USI_SCL ) ) &&  !( ( PIN_USI & ( 1 << PIN_USI_SDA ) ) ));// SCL his high and SDA is low

6

7

-  if ( !( PIN_USI & ( 1 << PIN_USI_SDA ) ) )

8

+  if ( !( PIN_USI & ( 1 << PIN_USI_SCL ) ) )

9

     {  // A Stop Condition did not occur

10

     USICR =

11

     ( 1 << USISIE ) |                // Keep Start Condition Interrupt enabled to detect RESTART

Hallo,

ich möchte etliche ATTiny85 mit diesem Code nutzen.

Ich habe den letzten Beitrag mit dem Patch gelesen und habe daraufhin 
von der jtronics Seite die V1.3 der Lib runtergeladen.

In dieser Version ist der Patch ja noch nicht implementiert.

Gibt es Bestätigungen oder Einwände bezüglich des Patches?
Hat es außer dem Entwickler des Patches jemand so am laufen?

Vielen Dank für Feedback...

MfG Dennis

Dennis K. schrieb:
> ...
> Gibt es Bestätigungen oder Einwände bezüglich des Patches?
> Hat es außer dem Entwickler des Patches jemand so am laufen?

Ja, und läuft mit allen Adressen ...

Andere Baustelle. In diesem Thread geht es um AVR Controller ohne 
halbwegs echtem I2C-Modul, bei dem das ziemlich bitweise über USI 
implementiert wird. Der Tiny88 hat aber ein echtes I2C-Modul (aka TWI), 
das nicht mit dem USI der anderen Tinys verwandt ist, sondern mit den 
Megas wie Mega8 und Nachfolgern.