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 ...
Allerdings profitiert man bei Hardware-I²C von den integrierten Filtern gegen Störungen.
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.
SMB I2C ähnliche Bausteine haben unter anderem eine minimale Taktfrequenz Spezifikation. Siehe hier: https://www.maximintegrated.com/en/app-notes/index.mvp/id/476
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.