Hallo zusammen,
ich möchte gerne einige Bausteine via I²C auslesen/beschreiben.
Gleichzeitig trudeln in unregelmäßigen Abständen externe IRs ein.
Die ISR ist so kurz wie möglich, also nur "zahl++" und wir mit 0 - 100
Hz aufgerufen.
Wie verhält sich das jetzt bei einer I²C Kommunikation?
Kann eine I²C Kommunikation unterbrochen werden? Wartet der IR kurz ?
Ist dem I²C in der Regel auch eine Priorität zugeschrieben?
Ich plane einen Microchip Cortex M4 µC mit 120 MHz zu nutzen.
Grüße
Matthias
Frank Herbert schrieb:> Hallo zusammen,> ich möchte gerne einige Bausteine via I²C auslesen/beschreiben.> Gleichzeitig trudeln in unregelmäßigen Abständen externe IRs ein.
IRs? Infrarots?
Oder eher Interrupts?
> Die ISR ist so kurz wie möglich, also nur "zahl++" und wir mit 0 - 100> Hz aufgerufen.>> Wie verhält sich das jetzt bei einer I²C Kommunikation?
Unkritisch.
> Kann eine I²C Kommunikation unterbrochen werden?
Ja, denn sie ist wie SPI synchron.
> Wartet der IR kurz ?
Wer bitte? Warum sollte der Interrupt warten? Eher die I2C
Übertragung.
> Ist dem I²C in der Regel auch eine Priorität zugeschrieben?
Eben die, welche du dem I2C in deiner Software gibst.
> Ich plane einen Microchip Cortex M4 µC mit 120 MHz zu nutzen.
Der wird sich langweilen ;-)
Hast du dir schon vor Augen geführt welch professionelle
Abkürzung du da gewählt hast.
Demnach würde ich zum Beispiel die Abkürzung WU als
"Wackelpudding" interpretieren.
Kleiner Hinweis: "Interrupt" wird im Techie-Slang mit "Int" gekürzt. Ein
regelrechte Abkürzung im eigentlichen Sinne gibt es dafür nicht.
Insbesondere ist "IR" nicht einfach die durch weglassen des 'S' in "ISR"
eine gültige Abkürzung für "Interrupt".
"IR" hingegen ist eine regelrechte Abkürzung für "Infrarot" - was denn
Falk auch in den Raum gestellt hat.
Frank Herbert schrieb:> Wie verhält sich das jetzt bei einer I²C Kommunikation?> Kann eine I²C Kommunikation unterbrochen werden?
Wenn die Komponenten das Clockstretching beherrschen, sollte das
gelingen.
Für die anderen Fragen: (und auch sowieso)
Vielleicht mal die I2C Spezifikation zu Rate ziehen.
Oder/Und auch die Datenblätter der Komponenten.
Die Hardware des i2c-Controllers kümmert sich um den i2c-Transfer. Die
CPU kann währenddessen etwas anderes machen, z.B. die ISR ausführen. Im
schlimmsten Fall kommt es dadurch zu einer kleinen Verzögerung, bevor
deine Software das nächste Byte senden kann.
So oder so ist das alles nicht relevant, i2c hat einen Takt, und du
kannst an jeder Stelle während der Kommunikation die fünfzigfachte Zeit,
die du brauchst um "x++" in einer ISR zu machen, warten ohne dass
irgendetwas passiert.
Pedant schrieb:> Kleiner Hinweis: "Interrupt" wird im Techie-Slang mit "Int" gekürzt.
Naja, eher mit IRQ. Nicht maskierbare Interrupts werden mit NMI
abgekürzt.
Die Frage ist in jeder Hinsicht schlampig gestellt. Über die unsinnige
Abkürzung "IR" wurde ja nun alles gesagt. Aber auch der I²C Teil hätte
besser ausgeführt werden können. Hardware I²C oder Bitbanging?
Wenn Hardware, dann kann die CPU zwischenzeitlich beliebiges tun, gerne
auch Zyklen in einer ISR verbraten. Und wenn Bitbanging, dann würde man
an kritischen Stellen eben keine Interrupts zulassen.
Axel S. schrieb:> Und wenn Bitbanging, dann würde man> an kritischen Stellen eben keine Interrupts zulassen.
Nein.
Denn I2C ist quasi-statisch zu betreiben, zumindest in sehr
vielen Fällen. Damit ist das Protokoll auch ziemlich beliebig
unterbrechbar. Nein, I2C braucht keinen festen Clock. Hier
und da mal eine Flanke, ganz unregelmässig, das geht.
Hier ist Bit-Banging unschlagbar denn ich kann meinen Bus
sehr leicht Debuggen.
Ich mache das schon sehr lange im Interrupt-Kontext und habe
nie Probleme damit gehabt.
Es mag die eine oder andere Ausnahme geben .... ich kenne keine.
Das ist nicht msl auf nem ATTiny mit 8 MHz ein Problem. Hier läuft IRMP
mit 15000 Aufrufen/s und I²C als Bitbanger (Fleury Lib) ohne jegliches
Problem nebeneinander.
Hallo und vielen Dank für eure Antworten!
Das hört sich schonmal gut an. Den Unterschied zwischen Hardware I²C und
Bitbanging kannte ich ja noch gar nicht, deshalb hätte ich das auch gar
nicht fragen können.
Grüße
Frank Herbert schrieb:> Den Unterschied zwischen Hardware I²C und> Bitbanging kannte ich ja noch gar nicht
Spielt für deine Frage auch keine Rolle. Beinahe alle I²C Bausteine
lassen sich beliebig langsam ansprechen.
Frank Herbert schrieb:> Den Unterschied zwischen Hardware I²C und> Bitbanging kannte ich ja noch gar nicht,
Ein Unterschied der dem Einsteiger/Anfänger gar nicht
geläufig sein wird:
Bei Soft-I2C kann man praktisch jedes beliebige Pin-Paar
des eigenen Controllers verwenden wogegen man bei Hardware-
I2C meist deutlich eingeschränkt(er) ist.
Auch hat man bei Hardware-I2C keinen deutlichen Geschwindig-
keitsvorteil da der Bus so langsam ist dass die Hardware-
unterstützung kaum Vorteile bringt.
... hi hi, manchne schwören ja bei I2C auf DMA ...
Beo Bachta schrieb:> Auch hat man bei Hardware-I2C keinen deutlichen Geschwindig-> keitsvorteil da der Bus so langsam ist dass die Hardware-> unterstützung kaum Vorteile bringt.
Man hat den Vorteil beim Senden nicht jedes Bit einzeln am Händchen
halten zu müssen mit 20 Interrupts pro Byte oder wie manche es machen
einfach blockierend drauf zu warten daß die Taktleitung wieder hoch geht
und Delay-Schleifen zu bauen um sich die Statemachine zu sparen.
Man kann stattdessen ungestört andere Sachen erledigen während die
Hardware von selbst die Bits rauswackelt.
Bernd K. schrieb:> mit 20 Interrupts pro Byte
Ja, wer ein I2C Byte mit 20 Interrupts sendet der hat wirklich
Ahnung davon wie man per Bitbanging Daten überträgt.
Bernd K. schrieb:> mit 20 Interrupts pro Byte
Zum Glück ist mancher Mist der hier geschrieben wird so
offensichtlich dass man nicht im Detail drauf eingehen muss.
Spät Zialist schrieb:> Bernd K. schrieb:>> mit 20 Interrupts pro Byte>> Zum Glück ist mancher Mist der hier geschrieben wird so> offensichtlich dass man nicht im Detail drauf eingehen muss.
Ja, sind nur 18 notwendig, hab mich verzählt. Trotzdem, selbe
Größenordnung. Des weiteren könntest Du vielleicht mal lesen auf welche
Aussage ich geantwortet habe, also welche Randbedingungen einzuhalten
sind: "keine Nachteile gegenüber Hardware-I2C"! Oder wie stellst Du Dir
vor soll man den SCL-Takt erzeugen ohne mit Warteschleifen zigtausende
von CPU-Takten pro Byte in Wärme zu verwandeln?
Arduino Fanboy D. schrieb:> Frank Herbert schrieb:>> Wie verhält sich das jetzt bei einer I²C Kommunikation?>> Kann eine I²C Kommunikation unterbrochen werden?>> Wenn die Komponenten das Clockstretching beherrschen, sollte das> gelingen.>> Für die anderen Fragen: (und auch sowieso)> Vielleicht mal die I2C Spezifikation zu Rate ziehen.> Oder/Und auch die Datenblätter der Komponenten.
ich sage mal kein Problem,
ich mache ja mit einem ATmega328p
64µs Interrupts (15000) Timer für IR IRMP, zähle dort bis 150 und hüpfe
bei 10ms in den longIRQ gebe den Timer IRQ wieder frei für IRMP mit
Umleitung vorbei am longIRQ, dort lese ich Tasten auch per I2C Port aus
1,5-2µs und verlasse die IRQ wieder, weder IRMP noch I2C fühlen sich
gestört.
Bernd K. schrieb:> Oder wie stellst Du Dir> vor soll man den SCL-Takt erzeugen ohne mit Warteschleifen zigtausende> von CPU-Takten pro Byte in Wärme zu verwandeln?
Was tut die CPU denn eigentlich sonst in der Zeit? Schickst du die dann
zwischen den Bytes in den Energiesparmodus? ;)
Sven B. schrieb:> Was tut die CPU denn eigentlich sonst in der Zeit? Schickst du die dann> zwischen den Bytes in den Energiesparmodus? ;)
Natürlich! Wenn nichts zu tun ist außer auf die Hardware zu warten kann
der Core sich schlafen legen. Jedes Grad Celsius um das es sich nicht
erwärmt ist ein gutes Grad Celsius. Jede Milliamperesekunde die es nicht
verbraucht ist eine gute Milliamperesekunde.
Bernd K. schrieb:> Sven B. schrieb:>> Was tut die CPU denn eigentlich sonst in der Zeit? Schickst du die dann>> zwischen den Bytes in den Energiesparmodus? ;)>> Natürlich! Wenn nichts zu tun ist außer auf die Hardware zu warten kann> der Core sich schlafen legen.
Macht der aber nicht, außer du sagst es ihm. Tust du das zwischen dem
Verschicken zweier i2c-Bytes (wobei ein Byte im Fast Mode ca. 20 µs
dauert)?
Sven B. schrieb:> Bernd K. schrieb:>> Sven B. schrieb:>>> Was tut die CPU denn eigentlich sonst in der Zeit? Schickst du die dann>>> zwischen den Bytes in den Energiesparmodus? ;)>>>> Natürlich! Wenn nichts zu tun ist außer auf die Hardware zu warten kann>> der Core sich schlafen legen.>> Macht der aber nicht, außer du sagst es ihm.
Ja, das sag ich ihm.
> Tust du das zwischen dem> Verschicken zweier i2c-Bytes (wobei ein Byte im Fast Mode ca. 20 µs> dauert)?
Ich tu das immer wenn die Arbeit getan ist. Ich schreib das Byte in das
Datenregister und leg mich schlafen. Wenn es durch ist kommt der
Interrupt und schreibt das nächste Byte und dann wird wieder geschlafen.
Es wird fast immer geschlafen, es sei denn es ist was zu tun.
