Hallo AVR-Gemeinde, hat schon mal jemand I2C nachprogrammiert ohne das TWI zu benutzen? Damit meine eine I2C als reine Software lösung. Ich kann leider das TWI aus pinnig-grunden nicht benutzen (vorgegeben), brauche aber trotzdem eine I2C Schnittstelle. Hat jemand eine Idee. Bedanke mich im voraus. Viele Grüße. Adalbert
Suche im Forum mit "+i2c +software" gibt 1200 Treffer, so z.B. den Beitrag "Software I2C MSP430" Suche mit Google "i2c software" gibt 1 Million Treffer, da könnte auch was dabei sein.
Viele Dank Lothar, allerdings vergass ich zu erwähnen, dass mich tips für einen SLAVE als softwarelösung interessieren (mein Fehler). Da wird die Sache etwas übersichtlicher. AVR bevorzugt. Trotzdem vielen Dank! Adalbert
> hat schon mal jemand I2C nachprogrammiert ohne das TWI zu benutzen? Das haben viele Leute getan. Einfach durch lesen des Datenblatts. .-) > allerdings vergass ich zu erwähnen, dass mich tips für einen SLAVE als Das ist leider problematischer weil du enge Timingvorgaben einhalten musst. In der Praxis geht es natuerlich trotzdem weil du ja schliesslich auch den Master-Controller programmierst und so dafuer sorgen kannst das alles im von dir gesetzen Rahmen bleibt. Waehrend man aber einen Master einfach so runterprogrammieren kann, wird man einen Slave enger an die Hardware, also den Faehigkeiten des aktuellen Controller und der Anwendung, was ist schon im Controller belegt, anpassen muessen. Mit anderen Worten man muss sich auf jedenfall auf den Hosenboden setzen und es selber machen damit es in die eigene Anwendung passt. Olaf
Olaf wrote: >> hat schon mal jemand I2C nachprogrammiert ohne das TWI zu benutzen? > Das haben viele Leute getan. Einfach durch lesen des Datenblatts. .-) Super: PBR Programming By Reading, der Durchbruch am Softwarehimmel :-) Trotzdem wichtig zu wissen: Ein I2C-Slave darf den Takt vom Master ausbremsen. Zum Beispiel auch der I2C-Sniffer von Peter Dannegger im Beitrag "Re: USI-Slave als TWI-Logger auf Tiny2313"
1 | Mein I2C-Sniffer verzögert dann einfach den I2C-Bus (SCL = low). |
Allerdings dürften einige I2C-Master, die da so in reiner Software programmiert wurden, ein Problem haben, wenn der Slave den Clockzyklus verlängern will.
Moin, in der Januarausgabe der Zeitschrift Elektor gab es eine Bauanleitung für einen I²C Slave mit AVR ATtiny: http://www.elektor.de/jahrgang/2009/januar/i2c-slave-kernel-fur-attiny13-2313.769117.lynkx. Carsten
> Ein I2C-Slave darf den Takt vom Master ausbremsen. Mag ja sein, aber wenn jemand selber einen I2C-Slave programmiert dann muss man das ja nicht nutzen. Zumal ich da sowieso nicht viel von halte. > Mein I2C-Sniffer verzögert dann einfach den I2C-Bus (SCL = low). > Allerdings dürften einige I2C-Master, die da so in reiner Software > programmiert wurden, ein Problem haben Das ist sicherlich richtig, zum beispiel die Software-I2C die ich programmiert habe. <g> Aber selbst wenn es der Master, egal ob jetzt als Software oder Hardware, richtig implementiert hat, ist sowas nicht besonders klug. Und ganz besonders nicht von einem Sniffer weil er so ein Gerät in seiner Funktion beeinflussen kann das man doch eigentlich untersuchen will. Olaf
Olaf wrote: > Aber selbst wenn es der Master, egal ob jetzt > als Software oder Hardware, richtig implementiert hat, ist sowas > nicht besonders klug. Warum nicht? Es ist die einzige Möglichkeit, wenn der Slave selbst ein MC ist, um keine Daten zu verlieren. In der Regel soll der Slave-MC ja auch etwas tun und nicht nur ständig auf den I2C-Bus warten. Und dann kann er eben gerade andere Interrupts bearbeiten, wenn was auf dem I2C-Bus ankommt. Es ist daher mit voller Absicht von den I2C-Entwicklern so vorgesehen worden und auch klug, es zu benutzen. Es ist allerdings dumm, einen SW-I2C-Master nicht das SCL einlesen zu lassen, wenn der Slave ein MC sein kann. Ein HW-I2C-Master unterstützt das daher immer. > Und ganz besonders nicht von einem Sniffer > weil er so ein Gerät in seiner Funktion beeinflussen kann das man > doch eigentlich untersuchen will. Was soll ein Sniffer denn sonst tun, wenn sein UART-Puffer voll ist? Pakete wegzuschmeißen wären das äußerst blödeste, da verzögere ich lieber. In der Regel macht auch der Master ja noch was anderes, d.h der I2C-Bus ist nicht ständig unter Vollast. Und in den Pausen kann der Sniffer dann seinen Puffer leer senden. Peter
> Warum nicht? Weil man damit das Zeitverhalten im Master beeinflusst. Das wird sicher oft gut gehen, kann aber auch mal z.b Problemen fuehren. Wenn das ganze nun in der Form eines Messgeraete genutzt wird, das man verwendet um ein Geraet auf Fehler zu untersuchen, dann wuerde ich es nicht so gut finden wenn man damit eine potentielle neue Fehlerquelle einbaut. > Was soll ein Sniffer denn sonst tun, wenn sein UART-Puffer voll ist? Ich muss sagen das ich noch nie das Beduerfniss hatte den I2C-Bus gross zu belauschen. Wenn ich irgendwo I2C Implementiere dann tue ich das ja erstmal mit einer kleinen Basisfunktion die nicht mehr kann als von einem beliebigen Baustein zu lesen/schreiben. Das kann man noch sehr gut mit dem Logicanalyzer oder Oszi sehen. Alle hoeheren Funktionen nutzen dann diese Funktion. Ich weiss dann also schon das I2C funktioniert. Es koennte also hoechstens noch ein uebergeordnetes Problem geben das man einfacher direkt im Code findet. Wenn ich aber so einen Sniffer brauchen sollte, z.B um ein mir fremdes Geraet auf die Finger zu schauen, dann wuerde ich wohl ein CPLD nehmen welches kein Problem haette den I2C-Bus komplett mitzuschreiben und die Daten dann als RS232 mit schnellem Takt ausgeben. Und diesen Aufwand wuerde ich auch nur machen weil es wohl keinen Micrcontroller gibt dessen eingebautes Slave-I2C auf jeder beliebigen Adresse anspricht. > In der Regel macht auch der Master ja noch was anderes, d.h der I2C-Bus > ist nicht ständig unter Vollast. Ich denke auch das es oft kein Problem ist. Aber eben nicht immer. Olaf
Olaf wrote: > Alle hoeheren Funktionen nutzen dann diese Funktion. Ich weiss > dann also schon das I2C funktioniert. Hatte ich auch mal gedacht. Probleme gabts aber erst mit vielen Teilnehmern, wenn öfter die Arbitration verloren ging und Retries erfolgten. Und da alle Teilnehmer HW-I2C hatten, haben die garnichts vom Sniffer gemerkt. Ob der Sniffer überhaupt mal SCL-Stretching machen mußte, weiß ich nicht. > Es koennte also hoechstens noch > ein uebergeordnetes Problem geben das man einfacher direkt im Code > findet. So ein Problem findet man nur sehr schwer im Code. > Wenn ich aber so einen Sniffer brauchen sollte, z.B um ein mir fremdes > Geraet auf die Finger zu schauen, dann wuerde ich wohl ein CPLD nehmen > welches kein Problem haette den I2C-Bus komplett mitzuschreiben und die > Daten dann als RS232 mit schnellem Takt ausgeben. Da würde ich eher noch nen FRAM an den ATTiny anschließen, z.B. der FM25CL64 könnte dann 8kB puffern. Bzw. zuerst würde ich von Textausgabe auf Binärausgabe mit PC-Program zur Darstellung umsteigen. Das bringt schonmal doppelten Durchsatz. Oder einfach die Zeile SCL-Abfrage in den Software-Master reinpappen, die stört ja niemanden. Peter P.S.: Mein Problem hatte auch damit zu tun: http://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html
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.