Datum:
Angehängte Dateien:Hallo! Hier ein funktionierendes Beispiel für einen I2C-Slave mit Hilfe des USIs. Läuft auf attiny26 und attiny2313. Vielleicht interessiert es ja jemanden... Gruß Axel Gartner PS: Siehe auch: http://www.mikrocontroller.net/articles/USI
Datum:
Angehängte Dateien:SCL Overflowfehler korrigiert. Axel Gartner
Datum:
Hallo Alex! Schön das du die so viel mühe gemacht hast. Das gleiche was du hier gepostet hast, bschäftigt mich schon ein paar Wochen. Also vielen Dank! Jetzt wollte ich das Programm mal testen und compilieren . Benutze das AVR Studio.....mit GCC! Nun meine Frage: Du linkst in den Programm zu keiner header datei oder ähnliches....! Bei kompilieren bekomme ich fehler, ../main2.c:63: error: `PORT_USI_SCL' undeclared (first use in this function) und noch viele andere....! ´Falls du doch auf andere datein links......wäre es super wenn du diese zur verfügung stellen könntest. DANK IM VORRAUS Dear Benno!
Datum:
Hallo Benno! Du must in deinem Makefile den MC-Typ definieren z.B.: _at90tiny26_ MCU = attiny26 F_CPU = 8000000UL CDEFS = -DF_CPU=$(F_CPU) -D__$(MCU)__ Die Defines sind typabhängig. forlgendes steht ganz am Beginn: // Device dependant defines #if defined(_at90tiny26_) | defined(_attiny26_) #define PORT_USI_SCL PORTB2 #endif #if defined(_at90Tiny2313_) | defined(_attiny2313_) #define PORT_USI_SCL PORTB7 #endif Gruß Axel
Datum:
@Axel, wenn man bestimmte Defines verlang, gehört es zum guten Ton, bei fehlen dieser Defines mit #error einen entsprechenden Hinweis auszugeben. Nach Monaten oder Jahren weißt Du sonst selbst nicht mehr, welche Defines für welches Projekt mal benötigt wurden. #if !defined(MODEL) #error Modell nicht definiert! #endif Peter
Datum:
Wunderbar das hat geklappt....! Wenn ich jetzt mit einem Master folgendes sende START ADRESSE (0x20) R/W dann sollte doch der Slave den BUS auf LOW ziehen richtig?
Datum:
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
Datum:
Hallo zusammen, cih habe versucht, den Code auf meinem ATTiny26 zum Laufen zu bekommen. Die Start-Condition erkennt der Controller auch noch und springt auch in die ISR, arbeitet diese ab und springt wieder zurück. Allerdings bleiben dann SCL und SDA low, was ja eigentlich nicht sein dürfte, oder? PullUps sind überall drin. Als I2C-Master verwende ich gerade einen RS232/I2C-Adapter der Firma IB-Hoch. Kann es ein, dass ich hier einfach keinen Takt zur Verfügung habe und den selbst vom Slave aus generieren sollte? Denn in diesem Falle kann es ja durch die Einstellung USI_CONTROL |= (1<<USIWM1) | (1<<USIWM0) | (1<<USICS1); (externer Clock) gar nicht gehen. Oder verstehe ich da was total falsch? Wer hilft mir mit dieser Geschichte auf die Sprünge, denn ich sehe gerade bei mir einfach den Fehler nicht....! Vielen Dank mal soweit! Dennis
Datum:
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.
Datum:
Hallo, habe versuch den Slave auf Tiny45 zu portieren (nur Pins verändert). Wenn ISR ausgelöst wird, sollte eine LED angehen, aber nicht mal START Condition wird erkannt :-o Nebenbei benutze ich auch die PWMs, ist aber wohl egal. Die ersten Zeilen habe ich so geändert: /* Device dependant defines */ #define DDR_USI DDRB #define PORT_USI PORTB #define PIN_USI PINB #define PORT_USI_SDA PORTB0 #define PORT_USI_SCL PORTB2 soll ja richtig sein, oder? Jetzt schlage ich mich den ganzen Tag damit rum und sehe den Wald vor lauter Bäumen nicht und bin kurz dran den ganzen Kram in Software zu implementieren. Weis jemand Rat? Hat jemand vielleicht auch Probleme damit gehabt und es auch nicht ging? Als Master habe ich AVR Mega 8, auf dem Oszi ist Start Condition wunderbar zusehen und die Implementierund des Masters funktioniert mit anderen Sachen... Mh... Help Gruß Kest
Datum:
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
Datum:
Angehängte Dateien:Vielleicht nützt das ja jemandem. Ich hatte das mal geschrieben und getestet (auf Tiny2313), es ist aber nicht produktiv im Einsatz, mag also Macken haben. Orientiert sich auch an Atmels AN, arbeitet aber Message-orientiert.
Datum:
Hallo ! Beschäftige mich gerade mit dem Code von Axel Gartner ... versuche das für codvision umzusetzen meine frage ist nach dem die Startbedingung erkannt wurde und erfolgreich das Adressbyte inklusive R oder W Bit eingelesen wurde, muß doch der slave generell das acknow.Bit setzen oder??? d.h. SDA als Ausgang und auf low ziehen. oder langt es den Pin nur als Ausgang zu schalten? DDR_USI |= (1<<PORT_USI_SDA); USI_STATUS = 0x0e;// reload counter for ACK, (SCL) high and back low bzw. suche die stelle an der das Acknowlege (SDA->Low) gesetzt wird. Vielleicht kann mir jemand einen Tip geben oder sagen ob ich falsch liege! Vielen dank!
Datum:
Hallo, ist zwar schon ein älterer Beitrag, aber für mich doch sehr aktuell :) Ich beabsichtige gerade die Umsetzung bei einem Tiny261, dass das USI zum I2C-Slave wird. Sendet halt keine ACK. Die Interruptroutine vom Codevision-Wizard will auch net :) Wurde das Problem schon mal gelöst für einen Tiny. Wäre dankbar für Tipps und natürlich auch nen Bsp.-Code :) Grüße
Datum:
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
Datum:
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-m... 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.
Datum:
Genau so was hab ich gesucht! Und im gegensatz zu allen anderen Codeschnipseln funktionierte die Bibliothek gleich beim ersten Versuch. Vielen Dank der Richard
Datum:
Angehängte Dateien: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
Datum:
hier das allgemeine Beispiel von mir, steht auch auf der jtronics.de
//############# I2C/TWI Adressen #define Adr_Attiny 0b00110100 //############# I2C ATTiny void read_Attiny(void) { i2c_start_wait(Adr_Attiny + I2C_WRITE); // Adr_Attiny ansprechen i2c_write(0); // startadresse zum lesen i2c_rep_start (Adr_Attiny + I2C_READ ); // Lesen beginnen Byte0 = i2c_readAck(); // Byte empfangen Byte1 = i2c_readAck(); // Byte empfangen Byte2 = i2c_readAck(); // Byte empfangen Byte3 = i2c_readNak(); // letes Byte empfangen i2c_stop(); // stopt I2C Verbindung } |
Datum:
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
int main(void) { uint8_t buffer; uart_init(UART_BAUD_SELECT(2400, F_CPU)); sei(); i2c_init(); _delay_ms(10); //################################## uart_puts("Slave adresse senden\r");// debug i2c_start_wait(ATTINY+I2C_WRITE); i2c_write(0); // ab Speicherplatz 0 abfragen uart_puts("Slave lesen\r"); // debug i2c_rep_start(ATTINY+I2C_READ); buffer=i2c_readNak(); // lesen i2c_stop(); uart_puts("Buffer: ");// debug uart_putc(buffer); uart_putc('\r'); while(1) { } } |
Datum:
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
Datum:
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
Datum:
Angehängte Dateien: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
Datum:
Hallo, ich bekomme folgenden Fehler bei Verwendung von avr-gcc und attiny[248]5:
Library_TWI_USI_Slave_Epprom_8MHZ % make -------- begin -------- avr-gcc (GCC) 4.3.4 Copyright (C) 2008 Free Software Foundation, Inc. Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE. Compiling: main.c avr-gcc -c -mmcu=attiny45 -I. -gdwarf-2 -DF_CPU=8000000ULUL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 -MD -MP -MF .dep/main.o.d main.c -o main.o Compiling: usiTwiSlave.c avr-gcc -c -mmcu=attiny45 -I. -gdwarf-2 -DF_CPU=8000000ULUL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=usiTwiSlave.lst -std=gnu99 -MD -MP -MF .dep/usiTwiSlave.o.d usiTwiSlave.c -o usiTwiSlave.o usiTwiSlave.c: In Funktion »usiTwiSlaveInit«: usiTwiSlave.c:201: Fehler: »USICIF« nicht deklariert (erste Benutzung in dieser Funktion) usiTwiSlave.c:201: Fehler: (Jeder nicht deklarierte Bezeichner wird nur einmal aufgeführt usiTwiSlave.c:201: Fehler: für jede Funktion in der er auftritt.) usiTwiSlave.c: In Funktion »__vector_13«: usiTwiSlave.c:239: Fehler: »USICIF« nicht deklariert (erste Benutzung in dieser Funktion) usiTwiSlave.c: In Funktion »__vector_14«: usiTwiSlave.c:263: Fehler: »USICIF« nicht deklariert (erste Benutzung in dieser Funktion) make: *** [usiTwiSlave.o] Fehler 1 |
USICIF sollte doch definiert sein. BTW: bei attiny26 funktioniert das Compilieren ...
Datum:
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.
Datum:
Angehängte Dateien:Hier noch eine Version mit überarbeiteten Kommentaren komplett in Englisch... Vielen Dank nochmal an Markus für das überarbeiten Grüße Martin
Datum:
Hallo, vielen Dank für die super schnelle Antwort. Martin J. schrieb: > Unterstützt werden bisher folgende Controller: > > ... ATtiny25, ATtiny45, ATtiny85 Ich möchte das für attiny45 ja nutzen. Verstehe ich hier etwas falsch ?
Datum:
mhm könnte ein kleiner Fehler sein... in der usiTwiSlave.c musst du folgendes Ändern
#elif defined( __AVR_ATtiny25__ ) | \ defined( __AVR_ATtiny45__ ) | \ defined( __AVR_ATtiny85__ ) #define DDR_USI DDRB #define PORT_USI PORTB #define PIN_USI PINB #define PORT_USI_SDA PB0 #define PORT_USI_SCL PB2 #define PIN_USI_SDA PINB0 #define PIN_USI_SCL PINB2 #define USI_START_COND_INT USICIF // HIER muss USISIF stehn!!!! #define USI_START_VECTOR USI_START_vect #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
Datum:
Jepp, das sollte in den Quellen dringend korrigiert werden! Ich bin beim ATtiny45 eben auch auf den USICIF-Fehler gestoßen... :-/ Gruß, Volker
Datum:
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
Datum:
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ß
Datum:
Hallo. klingt interessant was du da machst. Leider kann ich dir grad nicht helfen. Ich habe für ein Messsystem 2 Attiny 2313, 2 Atmega644 und 2 Maxim ADCs an einem I2C Bus Betrieben. Die Attinys arbeiteten mit der hier vorliegenden Library. Bisher konnte ich keine Fehler bzw. Probleme finden. Der Aufbau läuft jetzt schon seit Jahren ind verschiedenen Systemen zuverlässig. Momentan habe ich keinen ATTiny45 zu verfügung, sonst hätte ich es auch mal getestet. VIelleicht kann dir daher jemand anderes helfen. Grüße Martin
Datum:
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/tw...
Datum:
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/tw... 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
Datum:
Das wäre super, dann könnte im Fall eines Fehlers die Lib angepasst werden oder anderen mit gleichem Problem hätten dann schnell eine Lösung. noch viel erfolg.
Datum:
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ß
Datum:
interessant. meine erfahrungen waren, dass du bei 16MHz CLock den I2C bis knapp über 900Khz takten kannst, was aber nicht zu empfehlen ist. Der Bus läuft aber sicher bis zu 800 Khz. grüße martin
Datum:
Der Link http://www.jtronics.de/elektronik-avr/lib-i2ctwi-m... 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.
Datum:
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
Datum:
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.