Problem mit I2CSlave.lib

[Otti66]

Hallo alle Zusammen,

Nachdem ich nun schon seit ein paar Tagen dieses Forum nach einer Lösung durchforste, diese aber nicht finde muß ich hier meine Frage
loswerden:

Mein Master ist ein Mega128, mit dem habe ich eigentlich kein Problem,
dieser sendet brav seine I2C Kommandos wie ich mit dem Oszi sehen
kann.
Der Slave ist das Problem, ich hab die Slave Library von MCS gekauft,
und auf einen Tiny13 ein Programm geschrieben, wenn ich das Programm
auf dem Master starte funktioniert der erste Slave einmal, danach sind alle Slaves tot, der I2C-Bus aber nicht, der sendet brav weiter, wie oben schon erwähnt. Der Slave muß auch nur Daten empfangen, also keine zurück senden.
Nun ein paar Code Schnipsel:

Master:


$regfile = "M128def.dat"
$crystal = 2000000
$lib "i2c_twi.lbx"
Config Scl = Portd.0
Config Sda = Portd.1
Config Twi = 4000

I2cinit


Ddra = &B0000000
Porta = &B11111111
Ddrf = &B11111111

Dim Poweron As Bit
Dim S As Byte

Declare Sub An
Declare Sub Prg1


Do

Debounce Pina.0 , 0 , An , Sub
Debounce Pina.1 , 0 , Prg1 , Sub

Loop

An:

Toggle Poweron
If Poweron = 1 Then
Portf.0 = 1
Else
Portf.0 = 0
End If
Return

Prg1:
If Poweron = 1 Then
Portf.1 = 1
S = 5
Waitms 2
I2cstart
Waitms 20
I2cwbyte &H0A 'Motor1
Waitms 20
I2cwbyte S
Waitms 20
I2cstop
Waitms 12000
I2cstart
Waitms 20
I2cwbyte &H0E 'Motor3
Waitms 20
I2cwbyte S
Waitms 20
I2cstop
Waitms 12000
Goto Prg1
Else
Portf.1 = 0
Return
End If

End

Slave1:


$regfile = "attiny13.dat"
$crystal = 9600000

Config Pinb.3 = Output
Config Pinb.4 = Input
Config I2cslave = &B00001010 , Int = Int0 , Timer = Timer0


Dim Bfake As Byte
Declare Sub Stop1


Do

If Bfake = 5 Then
Portb.3 = 1
Waitms 3000
Goto Stop1
Else
Loop
End If


Stop1:

If Pinb.4 = 1 Then
Goto Stop1
Else
Waitms 50
Portb.3 = 0
Bfake = 0
End If
Return


I2c_master_has_data:
Waitms 10
Bfake = _a1
Return


bitte Code-Tags verwenden (PicNick)

[PicNick]

Prg1:
If Poweron = 1 Then
....
Goto Prg1
Else
Portf.1 = 0
Return
End If


Wie kommt das (master)Programm jemals aus "prg1" wieder raus ?

[Otti66]

Hallo PicNick,

Danke für den Hinweis mit den Codetags, hab ich übersehen.
Nun zu meinem Problem.
Der Master kommt aus PRG1 raus indem ich ihn ausschalt.
Spaß beiseite, das Masterprogramm dient nur zum Test des I2C-Bus,
und der funktioniert nicht auf der Slave Seite.

[PicNick]

Ahja. "auto-iterativ" nennen das die Fachleute.

Aber nochwas beim Slave is sub-optimal
Goto Stop1
Stop1:
Return
Das soll sicher "GOSUB Stop1" heissen, sonst rappelt's in der Kiste

[Otti66]

Hallo Robert,

Hab alle goto's durch gosub's ersetzt,
leider ist alles beim alten.
Ich muß noch dazu sagen das ich die waitms ganz weggelassen hab,
auf 2 reduziert hab usw. hat aber leider auch nichts verändert.

Mfg
Ottmar

[PicNick]

Würd mal sagen, die Slaves hängen sich irgendwie auf.
Du solltest beim master nach dem adresse-schicken
I2cwbyte &H0A 'Motor1
abfragen, ob ERR = 1 , d.h ob der Slave geACKed hat oder nicht.
(wenn nicht, brauchst du nicht weiterzusenden)

Ich muß mich über die I2CSlave -Lib erstmal ein wenig schlau machen

[Otti66]

Hab nun einfach folgende Codezeile nach jeder
Adressierung eingesetzt:

Portf.2 = Err 'Kontroll LED an PortF.2
Der erste Slave verrichtet brav seine Arbeit,
sobald an den Zweiten adressiert wird leuchtet die "ERR-LED".
Also hat Robert recht, nur was jetzt?
Die Adressen des zweiten Slaves hab ich schon mehrfach verändert,
und ihn natürlich auch schon als ersten gesetzt, dann funktioniert er,
liegt also nicht an der Hardware.
Danke schonmal fürs weiterhelfen.

MfG
Ottmar

[Otti66]

Ich muß noch eine Entdeckung dazu schreiben:

Wenn ich das Masterprogramm umschreibe, so daß nur noch ein
Slave angesprochen wird und nur noch der angeschloßen ist, funktioniert alles.
Kann es sein, das der zweite die Fehladressierung irgendwie
falsch auslegt?

MfG
Ottmar

[hrei]

Hallo Ottmar,


Ich muß noch eine Entdeckung dazu schreiben:
Wenn ich das Masterprogramm umschreibe, so daß nur noch ein
Slave angesprochen wird und nur noch der angeschloßen ist, funktioniert alles.
Kann es sein, das der zweite die Fehladressierung irgendwie
falsch auslegt?


ich versuche mal zusammenzufassen was ich bisher verstanden habe:

Du sprichst mit dem Mega 128 zwei Tiny13 als Slave an.

Tiny13 - 1 hat Adresse &h0A
Tiny13 - 2 hat Adresse &h0E

Sobald Du beide Slaves ansprichst, hängt sich das Programm auf.

In Deinem Slaveprogrammen kann ich keinen Fehler entdecken. Master tut es ja prinzipiell offensichtlich nun auch.

Mir fällt unter den gegebenen Umständen nur noch ein, daß bei zwei angeschlossenen Slaves die Spannungen bzw. deren Flanken nicht mehr sauber sind. Also ein Hardwareproblem. Das hatte ich bisweilen auch schon. Wenn ich die bei mir standardmäßig auf 10kOhm ausgelegten Pullups auf 4,7kOhm verringere oder am Busende einfach noch mal 10k pulle (kommt auf das selbe heraus), ist der Spuk dann vorbei.

Leider stochere ich im Nebel, gerade bei solchen Sachen müsste man die Hardware vor sich haben, um zielstrebig weiter zu helfen. Tiny13 habe ich im Augenblick nicht da :-(.

Grüße
Henrik

[Otti66]

Hallo Hendrik,

Danke für deine Tips. Du hast das ganze in soweit richtig verstanden,
außer das der erste Slave richtig funktioniert und der nächste dann nicht mehr.
Als Pullups hab ich mittlerweile interne, zweimal 10k, einmal10k probiert,
werde aber morgen auf 5k und 2,5k runter gehn.
OK, ich gebs zu, die Hardware "was made quick and dirty" aber die Pegel sehen auf dem Speicher Oszi direkt am Pin super aus.
Den Tiny13 hat mir Mark Albers erst vor kurzem in BascomAVR I2CSlave implementiert, da ja Int0 und Tmr0 die gleichen Pins sind wie bei den anderen Tiny's.
Im Moment glaube (ich weiß, daß tut man in der Kirche) das, daß ganze
nur mit einem Software Slave funktioniert, sobald einer fehladressiert ist hängt er sich auf.
Muß da mal bei Marc Albers nachfragen.
Trotzdem Danke für deine Hilfe.

MfG
Ottmar

[Otti66]

Hallo,

Das mit den Pullups hat leider nichts gebracht.
Ich bin mir aber mittlerweile sicher das es an der Fehladressierung
liegt, nur leider kann ich die I2Cslave.lib nicht anpassen, da ich kein Assembler kann.
Auf die Antwort von Mark wart ich noch.

MfG
Ottmar

[Otti66]

Hallo,

Ich hab eine Lösung gefunden und will euch diese nicht vorenthalten.
Die Lösung ist zwar nicht sehr befriedigent für mich aber sie funktioniert.
Ich hab den Tiny13 gegen einen 90S2343 getauscht, und siehe da es funktioniert, liegt also wohl am kleinen Speicher des Tiny13 (64 Byte),
der 2343 hat immerhin doppelt soviel.
Für die normale Adressierung reichen wohl die 64 byte nur
bei einer Fehladressierung nicht mehr, dann hängt sich der Tiny13 auf.
Vielleicht kann das ja jemand als Anhaltspunkt für eine Lösung mit dem
Tiny13 nehmen.

MfG

Ottmar

[PicNick]

Freut mich, Otti, hauptsache mal, es funzt.
Ich wollt mich über die I2CSlave.lib schlau machen, konnt aber nix detaillierteres finden.
Gibt's irgendwelche Links zu Doku ? (kaufen will' ich nix)

[Otti66]

Hallo Robert,

Zu der I2Cslave Library gibts eigentlich keine Doku nur das
Beispielprogramm bei MCS, und natürlich die Library, diese basiert übrigens auf AN302 von Atmel.
Wobei ich mich eh Frag wie die Library mit Tiny12, 22, 15
funktionieren soll, da die ja gar keinen RAM haben, bei denen
funktioniert kein wait bzw. waitms und so weiter, also nur mit Assembler
programmierbar, dann brauch ich aber auch kein Bascom dazu.
Was jetzt nicht heißt das ich Bascom schlecht finde, jedoch müßten die
Tinys aus dem Beispielprogramm raus.

MfG
Ottmar

[PicNick]

Ich stimme nicht ganz zu, ich denke, die Variante, gerade kleine MC - Büttel als reine Slaves einzusetzen, liegt schon nahe.
Hilft uns jetzt aber auch nicht weiter.
Ich hoff', ich komm bald dazu, mir diese offenbar verflixte I2C-Slaverei mal ernsthaft zu Brust zu nehmen, ist ja lästig, sowas.