www.mikrocontroller.net

Forum: Codesammlung attiny USI Slave Implementierung


Autor: Axel Gartner (axelg) Benutzerseite
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
Autor: Axel Gartner (axelg) Benutzerseite
Datum:
Angehängte Dateien:

SCL Overflowfehler korrigiert.
Axel Gartner
Autor: Benno (Gast)
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!
Autor: Axel Gartner (Gast)
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
Autor: peter dannegger (Gast)
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
Autor: Benno (Gast)
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?
Autor: Axel Gartner (axelg) Benutzerseite
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
Autor: Dennis Goetz (Gast)
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
Autor: B. Köppel (bekoeppel) Benutzerseite
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.
Autor: Kest (Gast)
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
Autor: Michael Fluhr (fury)
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
Autor: A.K. (Gast)
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.
Autor: malefs (Gast)
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!
Autor: Andre Göpfert (Gast)
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
Autor: Christoph Klein (hyla)
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
Autor: Martin J. (bluematrix) Benutzerseite
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.
Autor: pinkpanter (Gast)
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
Autor: auch_anfänger (Gast)
Datum:

Cool genau das hab ich gesucht.

danke
Autor: Thomas G. (mrmp3)
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
Autor: Martin J. (bluematrix) Benutzerseite
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
}
Autor: Martin J. (bluematrix) Benutzerseite
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)
  {  
  }
}
Autor: Thomas G. (mrmp3)
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
Autor: Martin J. (bluematrix) Benutzerseite
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
Autor: Martin J. (bluematrix) Benutzerseite
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
Autor: Tester (Gast)
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 ...
Autor: Martin J. (bluematrix) Benutzerseite
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.
Autor: Martin J. (bluematrix) Benutzerseite
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
Autor: Tester (Gast)
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 ?
Autor: Martin J. (bluematrix) Benutzerseite
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
Autor: Tester (Gast)
Datum:

Danke :-)  Compilieren geht schon mal ...
Autor: Martin J. (bluematrix) Benutzerseite
Datum:

fein fein
Autor: Volker (Gast)
Datum:

Jepp, das sollte in den Quellen dringend korrigiert werden! Ich bin beim
ATtiny45 eben auch auf den USICIF-Fehler gestoßen... :-/

Gruß, Volker
Autor: Martin J. (bluematrix) Benutzerseite
Datum:
Angehängte Dateien:

hier die korrigierte Version
Autor: Sebastian M. (compressed)
Datum:

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
Autor: Martin J. (bluematrix) Benutzerseite
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
Autor: Reiner Geiger (reinerg)
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ß
Autor: martin (Gast)
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
Autor: martin (Gast)
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...
Autor: Reiner Geiger (reinerg)
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
Autor: martin (Gast)
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.
Autor: Reiner Geiger (reinerg)
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ß
Autor: martin (Gast)
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
Autor: Matthias Sch. (Firma: Matzetronics) (mschoeldgen)
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.
Autor: Thomas Berends (thomy-pc) Benutzerseite
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
Autor: Thomas Berends (thomy-pc) Benutzerseite
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel




Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder GIF-Format hochladen.
Siehe Bildformate

Mit dem Abschicken erkennst du die Nutzungsbedingungen an.

webmaster@mikrocontroller.netImpressumNutzungsbedingungenWerbung auf Mikrocontroller.net