Ich werde jetzt nie wieder behaupten, dass das Ganze l=E4uft. Nach einigen funktionierenden Versuchen, straft mich das Ding dann eh wieder l=FCgen.
Was zum Teufel ist das:
Zwei gegeneinander arbeitende Push-Pull-Ausgänge?
Gruß Henning
Aktiv getriebener High-Pegel, der vom ACK-Bit etwas gedrückt wird?
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
snipped-for-privacy@googlemail.com:
Sind wohl die Flanken nicht steil genug für 400kHz. Hast du 2k gegen Vcc? Und was man da sieht: der Master hört mit dem Takten auf, mitten im Byte! Schon seltsam. Kein Wunder, das der Slave dann auf L bleibt (er bleibt bei bit 6 stehen und da I2C statisch ist, wartet er noch auf bit 7 und bit 8, ehe er den Bus freigeben würde). Warum hört der Master mitten im Byte auf? Brichst Du denn mittendrin ab?
M.
-- Bitte auf mwnews2@pentax.boerde.de antworten.
schrieb:
ja, schlecht.
Vielleicht bist du zu früh, musst erst warten bis die letzte Übertragung abgeschlossen ist? Setzt/löscht die I2C hardware ein flag, wertest du das aus?
Du könntest testweise mal die I2C-Beispielroutine aus dem datasheet deines Controllers 1:1 abtippsern ohne viel dran wild "rumzutesten"/abzuändern.
Wird entweder polling mit loop sein oder vermutlich doch ein eigener Interrupt, du setzt dann den passenden Vektor auf deine ISR.
Jedenfalls schlecht, die eigene Übertragungkette selbst mittendrin abzuwürgen, nur weil dein Controller sich grad langweilt!
Wenn es so wäre, seltsam, daß das überhaupt geht, da hat wohl einer latches gespart?
Wohl eher nicht, vielleicht liegt es doch an den fehlenden pull-ups!
Wär nett wenn du da mal laut sagen könntest: "Ich hab grad zwischen SDA/SCL und GND jeweils 2k2 gesehen und daran liegt es also nicht" oder ähnliches Sätzchen.
"Ruediger Klenner" schrieb:
VCC natürlich *an die Stirn klatsch*
snipped-for-privacy@googlemail.com:
Wieder bloss 6 Takte auf SCL. Wirklich seltsam, das er beim letzten Byte nur 6 bits will. ... dann Stromspitze? (zwei gegeneinander arbeitende Ausgänge), dann bricht Vcc ein? und du hast nen Reset?. (Mal gesponnen; zeichne mal Vcc mit auf).
M.
-- Bitte auf mwnews2@pentax.boerde.de antworten.
Wei=DF ich nicht :/
Vielleicht versteh ich ja was falsch, aber au=DFer beim ACK (oder nach ner Sendeanforderung) "zieht" der Slave doch gar nicht an der Datenleitung, die m=FCsste also doch wieder auf high gehen, wenn der Mster aufgrund eines Fehlers mit Takten aufh=F6rt
Arbitration Loss? Keine Ahnung...
Nicht dass ich w=FC=DFte
Ja aber er befindet sich doch gerade mitten in der Übertragung eines Bytes, da bleibt er dann genau da stehen, wo er gerade war.
Gruß Henning
Am 26.07.2007, 16:26 Uhr, schrieb Christian Eyrich :
Dann MISS HALT NACH (im ausgeschalteten Zustand)... oder such's Widerstand'l...
Ansgar
-- Mails an die Adresse im Header erreichen mich - oder auch nicht. Nützliche Adresse gibt's bei Bedarf! Mails to the address given in the header may or may not reach me - useful address will be given when reqired!
Der Witz ist ja, dass sich diese Beispielapplikation genauso verh=E4lt wie meine. Sprich, manchmal geht sie, manchmal nicht. Die l=E4uft standardm=E4=DFig mit 400kbit/s. Einzige =C4nderung, die ich gemacht habe ist, in jede Warteschleife ein Watchdog Clear einzuf=FCgen (leider nicht per Software abschaltbar).
Ergebnis eines Abbruchs:
L=E4uft alles =FCber polling
Wie kann ich das messen ohne was kaputt zu machen? :)
Nochmals danke an alle, die mir helfen
Dann Initialisierungsfehler der Ports bzw. SIO/I2C Moduls. Nochmals das datasheet konsultieren!
bei bitbanging:
Bei totem-pole der Portpin:
Portpin steht *immer* auf LOW und bleibt es auch!
SDA_High = *pin als Eingang schalten* (via data direction register) SDA_Low = *pin als Ausgang schalten"
clock ebenso.
Als Eingang schalten = hohe Impedanz des portpin. (Tristate wäre auch ok, gleiches Prinzip).
Niemals nicht wird der pin auf Output und "High" gesetzt bei I2C!
Du hast ab und zu heftige Spikes auf SDA und zwar immer genau synchron zu fallend SCL. Denkbar, dass dein Controller grad 'pusht' statt 'nur loszulassen' und der slave zieht sich die fetten Ströme durch seinen OC-Transi.
Vermutlich immer dann, wenn du an deinen Registern rumfummelst, z.B. in der Zeit zwischen:
wär verdächtig.
4k7 gegen 3,3V Versorgung
4k7
Christian Eyrich :
Eigentlich sollte man meinen, das Beispielapplikationen getestet sind und laufen. Wenn es wirklich das Beispiel zu 100% ist und du die Hardware getauscht hast, und alles Messbare ok ist (Vcc) dann bleibt nur noch, 'ne Nacht drüber zu schlafen und wenn es dann morgen auch nicht geht, den Hersteller anzurufen und zu fragen, was die da für einen Mist gebaut haben.
M.
-- Bitte auf mwnews2@pentax.boerde.de antworten.
"Christian Eyrich" schrieb:
Da könnte es jetzt sein, dasses an den 4k7 liegt, zu hoch. Sieht man ja auch im Schirmbild gut.
Da wär jetzt ne andere Ursache denkbar: Wenn du kurzzeitig den I2C Mode verlässt, dann irgendwas umfummelst und wieder das I2C modul on chip einschaltest, könnte für diese Zeit der pin von OC auf push-pull output umschalten und für diese Umschaltzeit den Graphikchip versuchen zu grillen, falls dessen OC grad durchgeschaltet ist.
Der üble spike auf SDA könnte sich so erklären.
Kannst ja mal im datasheet nachschauen was mit den portpin passiert wenn du ICCR0_EN = 0 setzt. Ob es auf push-pull umschaltet, könnte gut sein.
Wenn, könntest du den pin erst auf Input (oder tristate) schalten, dann dein Gefummel machen und am Ende wieder auf Output *nachdem* ICCR0_EN = 1 gesetzt ist.
Bevor du nun weiter deinen teuren Graphikchip gefährdest:
1) Schau doch mal, ob die Routine die der Hersteller angiebt fehlerfrei läuft, vielleicht bei 100kbit/s. ** Sieh auch nach errata sheets bei Mitsubishi! **Das sollte laufen, wenn nicht vermute zu hohe pullup-R's.
4k7 ist etwas viel, 2k2 wär üblich. Schau mal, ob dieser spike auf SDA von der Originalroutine auch produziert wird. Sollte mich wundern (aber denkbar ist ja alles :) !2)
*Erst wenn das zuverlässig läuft*, die Signale auf dem Oszi besser aussehen, dann fummel an deiner Software weiter.Nach dem Motto: Einen Fehler nach dem anderen beheben, nicht alle gleichzeitig :)
Wieso sollte durch diesen Befehl da was passieren, statt: while(IBSR0_LRB =3D=3D 1) { HWWD_CL =3D 0; timeout++; if (timeout =3D=3D 0x0FFF) {} }
siehts dann halt so aus: while(IBSR0_LRB =3D=3D 1) { timeout++; if (timeout =3D=3D 0x0FFF) {} }
Das steht im Manual:
[bit 13] EN (ENable) This bit enables the I2C interface operation. It can only be set by the user but may be cleared by the user and the hardware. When this bit is set to '0' all bits in the IBSR0 register and IBCR0 register (except the BER and BEIE bits) are cleared, the module is disabled and the I2C lines are left open. It is cleared by the hardware if a bus error occurs (BER=3D'1' in IBCR0). Warning: The interface immediately stops transmitting or receiving if is it is being disabled. This might leave the I2C bus in an undesired state!
Werd ich dann morgen machen, gehe jetzt nach hause
Ist mir noch nicht untergekommen
Okay :)
"Christian Eyrich" schrieb:
Missverständnis. Das geschieht auf Hardwareebene (wenn es so geschieht, guck' ins datasheet Abschnitt I/O-Hardware) und nicht auf Softwareebene.
Da keine I/O "verschenkt" werden sollen bei einem Controller, ist an den ports die von on-chip-hardware (SIO z.B.) mitverwendet wird oft zweierlei Hardware vorhanden: kräftige totem-pole Treiber um z.B. LED leuchten zu lassen und u.U. was Spezielles, Open-Drain z.B. kommt bei I2C in Frage. Auch andere Sachen kommen vor, Komparatoren Eingänge, Ausgänge u.A...alles konfigurierbar.
Dann zwingend nötig natürlich das dazugehörige Umschaltgeraffel in Hardware, irgendein/welche FF oder kombinatorisch oder so... im datasheet sollte das ausführlich erläutert sein!
Welcher Ausgangs'typ' dann jeweils 'aktiv/deaktiv' ist wird i.d.R. zusammen, d.h. gleichzeitig mit den enable-flags der module gesteuert.
Ein 'enable Dingsmodul' kann also den Ausgangstreibertyp umschalten z.b. auf OC (OD natürlich bei CMOS) und ein 'disable Dingsmodul' dann dann wieder zurück auf die kräftigen 'general purpose' Ausgangstreiber vom Typ 'push-pull'.
Wäre nicht unüblich bei Controllern, natürlich muss man das im datasheet verifizieren. "Jeder Jeck ist anders" wie man weiss!
Also zusammengefasst:
module aus bla blubb module an
kann darum gefährlich sein, weil in der Zeit für bla und blubb der Ausgangstreibertyp gewechselt hat und in dieser Spanne irgendwelche Transis sich u.U. gegenseitig zu grillen versuchen...
egal, was bla und blubb macht, watchdog oder sonstwas, egal.
Und falls es noch nicht klar ist: Wenn Ausgangstreiber gegeneinander arbeiten wie dein
zeigt, ist das nicht so gut für deine Hardware (kokel... ;) Klartext: Ganz schlecht! Sozusagen eine der seltenen Chancen, intraboard-hardware durch Software kaputtzumachen, u.U.
Guten Morgen,
habe eben das Beispielprogramm nochmal mit 100kbit/s laufen lassen, gleiches Ergebnis, 2mal gings nicht, 1mal gings...
Im Hardware-Manual (
Zum einen ist da folgende Tabelle, in der die verschiedenen Ports n=E4her klassifiziert werden:
Und eben, was ich woanders schonmal geschrieben habe:
PFR22.5 0 - Port is in general purpose port mode. 1 - Port is in resource function mode: Resource function is SCL0 open drain PFR22.4 0 - Port is in general purpose port mode. 1 - Port is in resource function mode: Resource function is SDA0 open drain, and INT14 input
Christian Eyrich :
Mal Vcc mit aufzeichnen, oder auch Icc (kleinen Widerstand in die Masseleitung und da dran den Oszi). Und dann noch SCL. Dann sehen wir, ob es da irgendwo Probleme mit gegeneinander kämpfenden Ausgängen gibt (sollte ja nicht, wenn alles Open-Drain ist).
Übrigens, die kleine Spitze auf SDA am Ende jedes Bytes ist normal und hab ich schon öfters gesehen. (Glaube war das Ack, der Master gibt SDA mit H frei und der Slave reagiert an derselben Clockflanke mit dem ziehen auf L - nur durch ein paar Gatterlaufzeiten verzögert.)Dann mal das Busserrorflag irgendwo auf ein Pin mit rausgeben (wird vielleicht ein bischen schwierig) und auf dem Osci darstellen. Das geht ja vermutlich irgendwann an? Nachwievor ist noch ungeklärt, warum der SCL nach 6 Takten (habe in deinen Bildern auch mal nur 5 gezählt) einfach aufhört. Kannst Du mal die Fehlerbehandlung ausschalten (also rücksetzen der I2C Hardware, bzw. wiederholen bei Fehler).
Haben beide Systeme die gleiche Betriebsspannung? Das eine Bild (ca.
2/3 H-Pegel bei SDA) kann auch davon kommen, dass der Slave nur 3V hat, während der Master mit 5V arbeitet.M.
-- Bitte auf mwnews2@pentax.boerde.de antworten.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.