Forum: Mikrocontroller und Digitale Elektronik ATmega1284P I2C (TWI) STOP Interrupt fehlt


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Tycho B. (asellus)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

beim Schreiben einer interruptbasierten I2C-Bibliothek habe ich mit 
Entsetzen festgestellt, dass nach dem Setzen von STOP
1
TWCR = (1<<TWEN)|
2
(1<<TWIE)|(1<<TWINT)|(0<<TWEA)|(0<<TWSTA)|(1<<TWSTO)|(0<<TWWC);
 kein Interrupt mehr ausgelöst wird. Das ist ungünstig, wenn man die 
Kommunikation vom Hauptprogramm entkoppeln möchte und das Handling in 
der ISR erledigt.
Ist es vom Hersteller wirklich so implementiert oder stehe ich auf dem 
Schlauch?

Tycho

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Wind denn auch die STOP Condition auf dem Bus ausgelöst?
Nicht dass der Slave die Clock auf Low zieht und dadurch gar kein Stop 
auftreten kann...

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
Tycho B. schrieb:
> beim Schreiben einer interruptbasierten I2C-Bibliothek habe ich mit
> Entsetzen festgestellt, dass nach dem Setzen von STOP
> kein Interrupt mehr ausgelöst wird. Das ist ungünstig, wenn man die
> Kommunikation vom Hauptprogramm entkoppeln möchte und das Handling in
> der ISR erledigt.

 Was stört dich genau daran ?

 Wenn STOP gesendet wird, ist die Kommunikation meistens zu Ende, oder ?

 Was genau würde ein STOP-INT deiner Meinung nach bezwecken ?

 Wieso "mit Entsetzen" ?


 Ich glaube, du missverstehst da etwas:
 Der uC sendet START, Adresse+R/W, Data.
 Nachdem das letzte Databyte gesendet ist, feuert (wie vorher auch)
 dein TWI-INT.
 In der ISR wird nun festgestellt, dass nichts mehr zum senden da ist,
 Slave hat ACK gesendet, also erzeugt der Master eine STOP-Kondition
 und für ihn ist die Sache zu Ende. Slave braucht den STOP vom Master
 weder zu bestätigen noch irgendetwas anderes zu tun (ausser vielleicht
 sich schlafen legen und auf die nächste START-Kondition warten).

 Wozu dann noch ein zusätzlicher STOP-INT ?


> Ist es vom Hersteller wirklich so implementiert oder stehe ich auf dem
> Schlauch?

 Sowohl als auch.

: Bearbeitet durch User
von Tycho B. (asellus)


Bewertung
0 lesenswert
nicht lesenswert
Ohne Interrupt muss ich pollen bis Stopp erreicht, das Hauptprogramm für 
die anschließende Stoppzeit für 5µs blockieren und I2C_start() für den 
nächsten Sensor senden.

von Tycho B. (asellus)


Bewertung
0 lesenswert
nicht lesenswert
Es wäre sinnvoll wenn der Hersteller es implementiert hätte. Nach der 
Totzeit von 4,7µs bzw. 1µs für 400kHz einfach Interrupt auslösen.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-2 lesenswert
nicht lesenswert
Tycho B. schrieb:
> Ohne Interrupt muss ich pollen bis Stopp erreicht, das Hauptprogramm für
> die anschließende Stoppzeit für 5µs blockieren und I2C_start() für den
> nächsten Sensor senden.

 Nein, natürlich nicht.

 Ausserdem sind die 5us Worst time und das auch für 1,8V Operation.
 Und selbst wenn es so wäre - irgendwo muss man die Pointer etc.
 für den nächsten Sensor bereitstellen - das dauert bei dir 0us ?


Tycho B. schrieb:
> Es wäre sinnvoll wenn der Hersteller es implementiert hätte. Nach der
> Totzeit von 4,7µs bzw. 1µs für 400kHz einfach Interrupt auslösen.

 Nein, natürlich nicht.

 Wie schon gesagt:
Marc V. schrieb:
> Wenn STOP gesendet wird, ist die Kommunikation meistens zu Ende, oder ?

 Und nächsten Sensor muss man zuerst adressieren, dazu muss der Pointer
 auf SensorNr. erhöht werden, prüfen ob SensorNr. > Sensoranzahl, falls
 ja, geht der Pointer wieder auf Null, nochmals prüfen was mit den
 Sensordaten passieren soll (absenden / Flag setzen), danach auf jeden
 Fall aus der entsprechenden Tabelle die Sensoradresse auslesen usw.

 Bis dein uC das geschafft hat, sind die 0,5us (solange dauert es
 nämlich bei 5V) auch vorbei...
 Und dass deine Mega bei 1,8V und den dazu gehörigen 5us nur 4MHz
 schafft, ist dir bekannt ?


 Erst mal nachdenken bevor man über sinnvoll oder sinnlos redet...

von Tycho B. (asellus)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> Ausserdem sind die 5us Worst time und das auch für 1,8V Operation.

verstehe ich nicht

> Und dass deine Mega bei 1,8V und den dazu gehörigen 5us nur 4MHz
> schafft, ist dir bekannt ?

meine Mega? 4MHz? 1,8V?
worüber sprichst du?

von Marc V. (Firma: Vescomp) (logarithmus)


Angehängte Dateien:

Bewertung
-2 lesenswert
nicht lesenswert
Tycho B. schrieb:
> Marc V. schrieb:
>> Ausserdem sind die 5us Worst time und das auch für 1,8V Operation.
>
> verstehe ich nicht
>
 Die Angaben die du geschickt hast, gelten für Mega als Slave.
 Deine Mega ist Master, also interessieren nur die entspr. Zeiten für
 Sensoren.


>> Und dass deine Mega bei 1,8V und den dazu gehörigen 5us nur 4MHz
>> schafft, ist dir bekannt ?
>
> meine Mega? 4MHz? 1,8V?
> worüber sprichst du?

 Ich spreche von ATMEGA1284P.

 Es gibt nur 2 Möglichkeiten:
 a) Du arbeitest mit 100KHz, also dauert ein einziger Takt 10us aber
    dir sind 4,7us zu viel ?

 b) Du arbeitest mit 400KHz, dann stimmen die 4,7us aber nicht mehr,
    es ist max. 1us, das sind (selbst bei 20MHz) 20 Taktzyklen. Die sind
    verbraucht, noch bevor du die geprüften und neugestellten Pointer
    wieder reingeschrieben hast.

 Das du jetzt mit Gewalt versuchst, etwas sinnloses wie STOP-INT
 sinnvoll zu machen, wundert mich überhaupt nicht.

von Tycho B. (asellus)


Bewertung
0 lesenswert
nicht lesenswert
Lieber Herr Vesely,

es ist mir sehr mühselig, über Ihre Auffassung von sinnvoll und sinnlos 
in meinem Projekt zu diskutieren.
Die Frage war klar gestellt. Was ich als Antwort erwartet habe, wäre 
eine einfache Aussage, ob der Interrupt wirklich nicht ausgelöst wird, 
oder aber ich was falsch mache.

Mit freundlichen Grüßen

@ Jim Meba
Ich werde morgen am Oszi nachschauen, ob Stop auch ausgelöst wird.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-2 lesenswert
nicht lesenswert
Tycho B. schrieb:
> Lieber Herr Vesely,
>
> es ist mir sehr mühselig, über Ihre Auffassung von sinnvoll und sinnlos
> in meinem Projekt zu diskutieren.

 Lieber Herr Tycho,

 Es ist mir auch ziemlich schwer, über etwas zu diskutieren, was
 wahrscheinlich sowieso nie zu Ende gebracht wird.
 Aber rein hypothetisch gesprochen:
 Ein STOP-INT wäre absoluter Blödsinn, das haben die Leute bei Atmel
 erkannt und deswegen gibt es so etwas nicht.
 Eventuell wäre so etwas bei SLAVE nützlich aber bei Master niemals.
 Da deine Mega als Master arbeitet (rein hypothetisch, irgendwann
 einmal natürlich), ist so etwas uninteressant.

> Die Frage war klar gestellt. Was ich als Antwort erwartet habe, wäre
> eine einfache Aussage, ob der Interrupt wirklich nicht ausgelöst wird,

 Der Interrupt wird einfach nicht ausgelöst, weil sinnlos.

> oder aber ich was falsch mache.

 Stur versuchen, etwas völlig unnötiges als nützlich darzustellen.
 Deine Mega ist Master, Master entscheidet wann Schluss ist und
 Master braucht dafür ganz einfach keinen Interrupt.
 Master kann auch mitten in der Kommunikation ein STOP oder repeated
 START senden, es ist alles legal und erlaubt.

 Wenn du mal ein bisschen weiter bist als Copy&Paste, wird dir das
 wahrscheinlich klar werden.

Tycho B. schrieb:
> @ Jim Meba
> Ich werde morgen am Oszi nachschauen, ob Stop auch ausgelöst wird.

 Da deine Mega Clock stretching hardwaremässig nicht unterstützt,
 wird das auch ein weiteres sinnloses Versuch.
 Und ich bezweifle sehr stark, dass die Sensoren das auch können.
 Dafür gibt es ACK/NACK.
 Aber das wirst du (vielleicht) verstehen wenn du dich weitere
 fünf Jahre intensiv damit beschäftigst.

von Tycho B. (asellus)


Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> Es ist mir auch ziemlich schwer, über etwas zu diskutieren, was
>  wahrscheinlich sowieso nie zu Ende gebracht wird.

Na dann lassen Sie es doch einfach, es zwingt Sie doch keiner.

von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
Tycho B. schrieb:
> Ohne Interrupt muss ich pollen bis Stopp erreicht, das Hauptprogramm für
> die anschließende Stoppzeit für 5µs blockieren und I2C_start() für den
> nächsten Sensor senden.

Du brauchst nicht abzuwarten, bis das STOP gesendet wurde, Du kannst STA 
und STO gleichzeitig setzen.
Siehe Table 21-2. Status codes for Master Transmitter mode.
Status 0x18 .. 0x30:
"STOP condition followed by a START condition will be transmitted and 
TWSTO Flag will be reset"

von Tycho B. (asellus)


Bewertung
0 lesenswert
nicht lesenswert
@ Peter Dannegger

Hab's gerade getestet und ja, genau das habe ich gesucht!
Danke!

von Marc V. (Firma: Vescomp) (logarithmus)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Tycho B. schrieb:
> Hab's gerade getestet und ja, genau das habe ich gesucht!
> Danke!

 Ein Blick ins DaBla hätte gereicht.

 Ich bin entsetzt.

von Tycho B. (asellus)


Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
> Ahem.
> Wußte ich doch, dass hier nur Datenblätter zitiert werden, um
> nichtbestehendes Wissen vorzutäschen, rumgemotzt und beleidigt
> wird. Kreativität, Ideen ?
> Gleich Null = Zero = Nada == Nothing.

Kommt das Ihnen bekannt vor?

von Steffen H. (avrsteffen)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Tycho B.

Ich hatte in etwa mal genau das selbe Problem. Aus irgendeinem Grund 
wurde der HW-TWI gestört, ein STOP sofort nach eintragen des Stop Flags 
ins Register, zu senden.

Mir bleib damals nur die Möglichkeit, über den PIN Change Interrupt den 
SDA Pin zu scannen. Nur dadurch wusste ich nun, wann der STOP von dem 
HW-TWI auf den Bus gebracht wurde.

Siehe hier:
Beitrag "Re: [ASM] Hardware TWI-MASTER Interrupt basierend für Mega AVR"

: Bearbeitet durch User
von Tycho B. (asellus)


Bewertung
0 lesenswert
nicht lesenswert
@Steffen H.

Mein Problem war, dass ich einen I2C-Puffer nicht kontinuierlich 
abarbeiten konnte, denn wenn ich STOP sendete, dann kam kein Interrupt, 
und ich musste aus dem Hauptprogramm das Weitersenden wieder initiieren.

Mit dem Vorschlag von Peter Dannegger ist es sogar noch besser als ich 
gedacht habe. Ich spare einen Interruptaufruf (den nach STOP, den ich 
eigentlich haben wollte) und der µC kümmert sich um das Senden des STOP, 
die Einhaltung der Pause und das erneute Senden von START. Und nach dem 
START kommt ja wieder ein Interrupt und die Schleife ist geschlossen. 
Damit ist die Kommunikation komplett vom Hauptprogramm entkoppelt.

Ich habe nicht nachgeschaut ob der STOP auf der Leitung auch korrekt 
gesendet wird, das war nicht das Problem. Ich habe eine einzige 
komplette Übertragung gesendet und in der ISR die zugehörigen Aufrufe 
geloggt. Nach jedem Setzen von (1<<TWINT) wurde ein Interrupt 
ausgeführt, nur nach
TWCR = 
(1<<TWEN)|(1<<TWIE)|(1<<TWINT)|(0<<TWEA)|(0<<TWSTA)|(1<<TWSTO)|(0<<TWWC) 
;
nicht, also nach STOP.

Das hat mich verwundert, denn der Logik nach muss eine Abarbeitung in 
einer Interrupt-Schleife funktionieren, genauso wie es bei SPI oder UART 
möglich ist. Nun ja, tut es jetzt auch.

von Steffen H. (avrsteffen)


Bewertung
0 lesenswert
nicht lesenswert
Tycho B. schrieb:
> Mit dem Vorschlag von Peter Dannegger ist es sogar noch besser als ich
> gedacht habe. Ich spare einen Interruptaufruf (den nach STOP, den ich
> eigentlich haben wollte) und der µC kümmert sich um das Senden des STOP,
> die Einhaltung der Pause und das erneute Senden von START. Und nach dem
> START kommt ja wieder ein Interrupt und die Schleife ist geschlossen.
> Damit ist die Kommunikation komplett vom Hauptprogramm entkoppelt.

Aber blockierst du damit nicht eventuell den I2C Bus nach deinem Start, 
wenn du gerade keine Daten zum Senden hast? (Idle)

von Tycho B. (asellus)


Bewertung
0 lesenswert
nicht lesenswert
Wenn keine Daten mehr im Puffer sind, dann wird in der ISR ein echter 
STOP gesetzt und Interrupt deaktiviert. Wenn der Puffer wieder beladen 
ist, dann muss das Hauptprogramm den Interrupt wieder aktivieren.

von Tycho B. (asellus)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Steffen H. schrieb:
> Ich hatte in etwa mal genau das selbe Problem. Aus irgendeinem Grund
> wurde der HW-TWI gestört, ein STOP sofort nach eintragen des Stop Flags
> ins Register, zu senden.

So, ich habe jetzt auch ein Problem mit dem STOP. Allerdings nur bei 
eigentlich unzulässigen Bedingungen: ich habe einen 3,3V Slave an den µC 
mit 5V gehängt, und die µC-Pins hochohmig gemacht, ohne Pull-Ups. Der 
Slave hat intern Pull-Ups, aber wie gesagt nur 3,3V. Für die TTL-Logik 
ist es unter Idealbedingungen noch ok.

Die Verbindung war in Ordnung, aber ab und zu blieb die 
Interrupt-Schleife einfach stehen, und zwar immer an einer definierten 
Stelle, nach einem STOP, also nicht irgendwo zwischendrin. Die 
Übertragung funktionierte, nur das Weitersenden machte er nicht. Dann 
habe ich einen Kondensator vom SDA auf Masse gelegt, und der Fehler 
tritt jetzt reproduzierbar nach der ersten oder zweiten Datenübertragung 
auf.
Während SCL HIGH ist gibt der µC die Leitung frei um STOP anzuzeigen und 
legt sie wieder sofort auf LOW. Es ist nicht der Slave, der das macht. 
Ich weiß nicht warum das passiert. Der 3,3V zu 5V Pegelwandler ist schon 
bestellt, aber interessant finde ich es trotzdem.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
Tycho B. schrieb:
> So, ich habe jetzt auch ein Problem mit dem STOP.

 Du hast mehrere Probleme und zwar:

 a) Mit Rechnen.
 b) Mit TWI Registern und TWI Routinen bei MEGA.
 c) Mit I2C überhaupt.

 Zu a)
 Minimaler Abstand STOP - neuer Start ist 5us bei 100KHz.
 100KHz I2C Geschwindigkeit bedeutet 5us LOW, 5uS High für SCK.
 Was man auch immer am I2C Bus macht, SCK zählt, nicht die CPU
 Geschwindigkeit - es muss mindestens eine I2C-Clock Flanke
 dauern.


 Zu b)
 STOP wird nicht einfach so gesendet, es wird auch nachher geprüft,
 ob alles OK ist.
 Die Leute bei Atmel haben sehr wohl erkannt, dass ein INT nach STOP
 absoluter Blödsinn wäre, aber setzen und rücksetzen des TWSTO-bit in
 TWCR-Register sehr nützlich sein könnte.
 Deswegen heisst es bei ATMEL:
1
Writing the TWSTO bit to one in Master mode will generate a STOP condition on the 2-wire Serial Bus.
2
When the STOP condition is executed on the bus, the TWSTO bit is cleared automatically.
 Und deswegen prüft man auch (in der ISR) ob die STOP condition auch
 tatsächlich aufgetreten ist. Ein einfacher Zähler verhindert, dass
 die ISR ewig prüft.
 Falls etwas nicht in Ordnung ist, meldet jede ISR-Routine einen Fehler,
 anstatt stumpf weiter zu senden.
 Und diesen Fehler behandelt man in main() mit State Machine anstatt
 ewig auf ein STOP bzw. INT zu warten.
 Woher soll die main() wissen, dass der INT nie aufgetretten ist, wenn
 alles in der ISR ablaufen soll ?
 Und rate mal, was passiert wenn deine MEGA einen Sensor trifft, der
 Clockstretching unterstützt oder sonstwie I2C-Bus blockiert.
 Du als möchtegern Experte kannst das natürlich auch anders machen...


 Zu c)
 Wenn du mehrere Sensors abfragen willst, ist ein STOP gar nicht
 notwendig. Hättest du aufmerksam gelesen, was ich dir schon vorher
 geschrieben habe, wusstest du, dass mit neuem START genauso gut
 der nächste Sensor adressiert werden kann.
 Mit dem klitzekleinen Unterschied, dass man dabei
 die volle Kontrolle über den Bus behält.

 Ich bin entsetzt über so viel Unwissenheit aber noch entsetzter bin
 ich darüber, dass jemand mit so wenig Kenntnissen überhaupt so
 etwas versucht.

 Bleib lieber bei Copy&Paste.

von Tycho B. (asellus)


Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> Wenn du mehrere Sensors abfragen willst, ist ein STOP gar nicht
>  notwendig. Hättest du aufmerksam gelesen, was ich dir schon vorher
>  geschrieben habe, wusstest du, dass mit neuem START genauso gut
>  der nächste Sensor adressiert werden kann.

"Each data transfer must be terminated by the generation of a STOP (SP) 
condition"

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Tycho B. schrieb:
> Während SCL HIGH ist gibt der µC die Leitung frei um STOP anzuzeigen und
> legt sie wieder sofort auf LOW.

Das scheint ein Bug im TWI des AVR zu sein.
Ich dachte, dieser Bug tritt nur bei Multimaster auf:
http://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html

Du könntest ja im Interrupt das STO setzen und nach 5µs das STA. 5µs 
Delay im Interrupt sollten nicht weh tun.

Man kann als Singlemaster aber auch auf das STOP ganz verzichten und nur 
Repeat-STARTs senden, wenn die Slaves ohne STOP auskommen.
Z.B. die 24Cxxx EEPROM brauchen das STOP, um mit dem Schreiben zu 
beginnen.
Ein PCF8574/A geht auch ohne STOP.

von Marc V. (Firma: Vescomp) (logarithmus)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Tycho B. schrieb:
> "Each data transfer must be terminated by the generation of a STOP (SP)
> condition"

 Nein.

von Tycho B. (asellus)


Bewertung
0 lesenswert
nicht lesenswert
Was heisst hier nein? Es steht so im Datenblatt.
http://www.farnell.com/datasheets/1691680.pdf

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Man kann als Singlemaster aber auch auf das STOP ganz verzichten und nur
> Repeat-STARTs senden, wenn die Slaves ohne STOP auskommen.
> Z.B. die 24Cxxx EEPROM brauchen das STOP, um mit dem Schreiben zu
> beginnen.

 Genau.
 Nur beim Schreiben braucht man STOP.
 Beim lesen der Sensoren aber natürlich nicht, da hast du als Master die
 entsprechenden Daten schon gekriegt.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
Tycho B. schrieb:
> Was heisst hier nein? Es steht so im Datenblatt.
> http://www.farnell.com/datasheets/1691680.pdf

 Ja, dann probiere es mal mit Repeated START (beim lesen natürlich).

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Das scheint ein Bug im TWI des AVR zu sein.

da läuft einiges nicht rund

Ich nutze ja deine Entprellroutine mit einem PCF8574 und 8 Tasten, kein 
Problem, verträgt sich auch mit der RTC prima, beim I2C eeprom konnte 
ich nicht busy abfragen also polle ich ob es wieder bereit ist mit 
Starts, klappt auch besser und schneller als die "üblichen" 5ms waits.

Als ich ein OLED rangehangen hatte ging nichts mehr, jedenfalls nicht in 
Verbindung mit dem PCF8574, OK das Problem ist entschärft seit ich 
Drehencoder nutze.

Soweit ich weis kommt der Atmel auch nicht mit clock stretching zurecht, 
andere behelfen sich mit einem weiteren Port der das Ende vom clock 
stretching beobachtet, irgendwie ist das Zusammenspiel weiterhin 
"merkwürdig" Dataenblatt hin oder her, jeder scheint sich nur etwas an 
die Regeln zu halten und irgendwie gehts ja auch manchmal :)

von Tycho B. (asellus)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Du könntest ja im Interrupt das STO setzen und nach 5µs das STA. 5µs
> Delay im Interrupt sollten nicht weh tun.

ich habe es anders gelöst, und zwar durch Senden von STOP und 
gleichzeitigem Deaktivieren des TWI
TWCR=(0<<TWEN)|(0<<TWIE)|(0<<TWINT)|(0<<TWEA)|(0<<TWSTA)|(1<<TWSTO)|(0<< 
TWWC);
Damit funktioniert es, die Leitung wird sofort frei. (Nur STOP getestet. 
Wie sich die Leitung verhält wenn ich START und STOP gleichzeitig sende, 
habe ich bei 3,3V noch nicht getestet. Bei 5V Pull-Ups funktionierte 
es.) Ich glaube aber, dass es mit den zu niedrigen Pegeln zusammenhängt. 
Wenn ich externe 5V Pull-Ups verbinde, dann läuft es auch durch. Kann 
mich aber auch täuschen.

Marc V. schrieb:
> Ja, dann probiere es mal mit Repeated START (beim lesen natürlich).

Warum sollte ich? Steht doch schwarz auf weis im Datenblatt wie es zu 
machen ist.

: Bearbeitet durch User
von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
Tycho B. schrieb:
> Warum sollte ich? Steht doch schwarz auf weis im Datenblatt wie es zu
> machen ist.

 Es stand auch bei ATMEL, dass ein INT nach STOP nicht notwendig und
 nicht vorhanden ist und trotzdem willst du es mit Gewalt machen.

Tycho B. schrieb:
> ich habe es anders gelöst, und zwar durch Senden von STOP und
> gleichzeitigem Deaktivieren des TWI
> TWCR=(0<<TWEN)|(0<<TWIE)|(0<<TWINT)|(0<<TWEA)|(0<<TWSTA)|(1<<TWSTO)|(0<<
> TWWC);

 Was hast du damit gelöst ?
 Damit hat dein Master nur den Bus freigegeben (was ja nach dem STOP
 sowieso der Fall ist).

 Sowohl SCK als auch SDA sind TriState und werden danach als Eingang
 geschaltet (deswegen braucht man Pullup).
 Ob aber der Sensor den Bus freigegeben hat oder ob dein STOP auch
 wirklich ausgeführt worden ist, weisst du immer noch nicht.

: Bearbeitet durch User
von Tycho B. (asellus)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das STOP-Problem ist jetzt weg. Wenn ich aber den µC über JTAG starte, 
dann bricht die TWI-Datenkommunikation sporadisch auch ab, diesmal jedes 
mal nach Repeated START. Die Sequenz sieht so aus:
1
i2c_start(I2C_DEVICE_ADDRESS + I2C_WRITE);
2
i2c_write( 0xA8);
3
i2c_rep_start(I2C_DEVICE_ADDRESS + I2C_READ);
4
i2c_readAck();
5
i2c_readNak();
6
i2c_stop();

Diese wird bis zu 100 Mal durchlaufen, und dann hängt es beim Senden der 
Adresse nach Repeated START. Es sieht so aus, dass der neunte Clock-Puls 
einfach nicht gesendet wird. Ohne JTAG-Verbindung sehe ich keine 
Abbrüche. Ich denke JTAG-Kommunikation verschlimmert das Signal und löst 
dieses Verhalten aus.

Ich muss dazu sagen, dass das Signal wirklich miserabel ist. Das ist 
aber gewollt, damit ich alle möglichen Fehler jetzt schon sehen kann und 
deren Behandlung implementiere. Wenn aber ein Puls hardwareseitig 
einfach nicht gesendet wird - da weiß ich echt nicht mehr weiter. Die 
SDA bleibt auf LOW, diesmal durch den Sensor.

von Tycho B. (asellus)


Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> und trotzdem willst du es mit Gewalt machen

du checkst es nicht, oder?

Marc V. schrieb:
> Ob aber der Sensor den Bus freigegeben hat oder ob dein STOP auch
>  wirklich ausgeführt worden ist, weisst du immer noch nicht.

Guter Einwand. Und genau hier wäre ein STOP-Interrupt sinnvoll, gelle? 
So von wegen TWSTO checken und so.

von Marc V. (Firma: Vescomp) (logarithmus)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Tycho B. schrieb:
> du checkst es nicht, oder?

 Mir scheint es als ob du es nicht checkst.

Tycho B. schrieb:
> Guter Einwand. Und genau hier wäre ein STOP-Interrupt sinnvoll, gelle?
> So von wegen TWSTO checken und so.

 Manoman.
 du checkst es wirklich nicht, oder?

 Was ist wenn der INT nicht kommt ?
 Bis in alle Ewigkeit warten ?
 Trotzdem dumb weiter senden ?

 P.S.

 Hier:
 Dauert 5.083us zwischen STOP und START, macht die MEGA ganz von
 alleine.
1
     ldi    r16, 0b10010100
2
      sts    TWCR, r16
3
WtStop:
4
  lds  r16,TWCR
5
  sbrc  r16, TWSTO
6
  rjmp  WtStop
7
8
  ldi  r16, 0b10100100
9
  sts  TWCR, r16
 Natürlich sind für deine HiTechDeepSpace Anwendung 5us einfach zu viel,
 verstehe ich vollkommen - ist ja auch die Hälfte von einem I2C Takt...

: Bearbeitet durch User
von Tycho B. (asellus)


Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> Manoman.

Alter, hast du eine Berufsunfähigkeitsversicherung? Du bist ab dem 
ersten Post auf 180 und kommst nicht runter. Ist schlecht fürs Herz. 
Nimm dir warme Milch mit Honig und schau irgendetwas lustiges in der 
Glotze an, sonst machste nicht mehr lange mit dem Temperament :)  Fühlst 
du dich irgendwie beleidigt? Habe ich etwas gesagt, was dich persönlich 
gekränkt hat? Willst du darüber reden?
streichelt
Weisst du, die rein verbale Kommunikation hat so ihre Tücken. So sieht 
man sein Gegenüber nicht und neigt dazu, in seine Wortwahl etwas zu 
interpretieren, was einen selbst tagsüber beschäftigt. Nennt sich 
freudsche Fehlleistung.
Wirst du vielleicht ständig angemacht in deinem Freundeskreis, in deinem 
Arbeitskreis, in dem du nicht wertgeschätzt wirst? Glaubst du generell, 
dass deine Leistung mehr Wertschätzung verdient? Sind die Kollegen immer 
zu unfreundlich zu dir? War das schon immer so, auch in der Kindheit? Es 
gibt Menschen, die können sich nicht in ihr gegenüber gefühlsmäßig 
hineinversetzen. Man sagt, deren Empathie ist gering. Das 
fortgeschrittene Krankheitsbild dazu nennt man Authismus. Die Symptome 
treten in der Regel vor dem dritten Lebensjahr auf und zeigen sich in 
Problemen im sozialen Umgang und der sprachlichen sowie nonverbalen 
Kommunikation sowie in eingeschränkten, stereotypen und wiederholenden 
Verhaltensweisen und Interessen.
Falls du mich wieder missverstehen solltest: es ist keine Beleidigung! 
Mich interessiert einfach was die Menschen antreibt, ihr gegenüber ohne 
jeden Grund so anzupissen.

Ich will dich aufheitern.
Ein SemiOT-Witz:
Ein Mann fährt auf der Autobahn und hört im Radio die Durchsage: 
"Achtung! Ein Geisterfahrer auf der A1."
Und der Mann schüttelt den Kopf und murmelt:
"Einer? Hunderte!"

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
Tycho B. schrieb:
> Mich interessiert einfach was die Menschen antreibt, ihr gegenüber ohne
> jeden Grund so anzupissen.

 Ohne jeden Grund ?
 Anzupissen ?

Tycho B. schrieb:
> Alter, hast du eine Berufsunfähigkeitsversicherung? Du bist ab dem
> ersten Post auf 180 und kommst nicht runter. Ist schlecht fürs Herz.

 Ich versuche auch ab der ersten Post dir irgendetwas ganz langsam
 zu erklären.
 Du machst aber einen auf entsetzten Allwissenden Experten.
 Und so etwas bringt mich echt auf 180. Mit keinem einzigen Wort hast
 du versucht zu erklären, was dein Program macht wenn dein so
 erwünschter STOP INT eventuell nicht kommen sollte.

Tycho B. schrieb:
> Wirst du vielleicht ständig angemacht in deinem Freundeskreis, in deinem
> Arbeitskreis, in dem du nicht wertgeschätzt wirst? Glaubst du generell,

 Nein, meine Freunde suche ich mir aus. Und meine Freunde tun das auch.
 Und in meinem Arbeitskreis gibt es so etwas nicht, da gilt es nicht als
 Schande zuzugeben, dass man etwas nicht gewusst oder falsch verstanden
 hat. Dass es meine Firma ist, hat damit nichts zu tun - wenn mir jemand
 mit besserem Vorschlag kommt oder erklärt warum ich mit meiner Idee
 nicht weiterkommen kann, dann gibt es bestimmt keinen Streit darüber.

 Zum Tausendsten Mal:
 Es ist keine Schande etwas nicht zu wissen.

Tycho B. schrieb:
> Falls du mich wieder missverstehen solltest: es ist keine Beleidigung!

 Es ist aber bedenklich wenn man persönlich wird.
 Und mit deinem gescheitertem Versuch einen auf Allwissenden Experten
 in Psychoanalyse zu markieren wirst du persönlich.

von Tycho B. (asellus)


Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> Ich versuche auch ab der ersten Post dir irgendetwas ganz langsam
>  zu erklären.
>  Du machst aber einen auf entsetzten Allwissenden Experten.
>  Und so etwas bringt mich echt auf 180.

Siehst du? Schon wieder. Schon wieder glaubst du etwas gelesen und 
verstanden zu haben, was ich nicht so meinte. Es interessiert mich nicht 
was dich auf 180 bringt. Mein Interesse bestand lediglich darin zu 
begreifen, warum du immer und immer wieder hier auftauchst.

Ich habe mit Wohlwollen die von dir hier gelassenen kleinen 
Wissenskrümmel zur Kenntnis genommen, aber der Rest... Ein mal, zwei 
mal, fünf mal. Ja nach fünf mal habe ich ganz sicher kapiert, dass ich 
nichts kann und nur zusammenkopieren soll, kein allwissender Experte bin 
und das schlimme Wort "entsetzt" ganz doof war.

Aber du schreibst es noch das sechste mal. Und siebente. Man könnte 
meinen, der Sieger entferne sich erhobenen Hauptes stolz lächelnd mit 
eingepferchtem Siegesschrei in der Lunge des Schlachtfeldes. Aber nein, 
du kommst nochmal, wie ein Zwangsneurotiker.

Verhalten sich deine Vorgesetzten auch so? Hast du so wenig, wofür du 
stolz sein könntest? Verschafft es dir deswegen eine gewisse Genugtuung, 
jedes mal deine Meinung anonym irgend jemandem geigen zu können? Ist das 
anonyme Internet dabei behilflich, da es eine nonverbale 
Meinungsäußerung in den Allerwertesten unterbindet?

Hast du wenigstens über den Witz gelächelt? :)

Aber genug des Spaßes, bleiben wir doch beim Thema.

von Tycho B. (asellus)


Bewertung
0 lesenswert
nicht lesenswert
Tycho B. schrieb:
> Wenn ich externe 5V Pull-Ups verbinde, dann läuft es auch durch. Kann
> mich aber auch täuschen.

Nein, tut es nicht. Nur ohne JTAG-Verbindung habe ich einen 
unterbrechungsfreien Datenstrom.
Hängt genau an der selben Stelle, beim Senden der Adresse nach repStart 
gibt es nur acht Clock-Pulse.

: Bearbeitet durch User

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]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.