I2C oder UART?

[Che Guevara]

1.000.000 ist bei 16Mhz eine fehlerfreie Baudrate (http://halvar.at/elektronik/kleiner_..._zum_computer/). Die 115.200 sind auskommentiert, das war der alte Wert und die beiden Softuart-Pins sind nur für das BTM222, um welches es hier nicht geht.
Hm, ich übertrage 5 Words (10Byte) und noch ein Byte. Das sind dann also 11Byte / 235µs (nicht ganz) = 46.808Byte / sek. Von 1Mbit war nie die Rede.
Ich weiß, ein paar Kommentare würden nicht schaden, aber ich denke, man kann es schon größtenteils nachvollziehen, oder nicht?!

Gruß
Chris

[Richard]

Trotzdem sind mir $baud = 1000000 irgendwie zu viel, ein Byte setzt sich ja aus 1 Start, 8 Daten,und 1 Stopp Bit zusammen. macht also 10 Bit pro Byte
Bei einer Baudrate von 1.000000 sind das dann 10.000000 Bit/s. Selbst wenn der µC sonst nix macht ist das hart und über eine Leitung schicken wird auch Probleme bereiten. Außerdem kenne (ich) keine RS232 welche das schafft? Wo Du jetzt die 235µs her hast? Aber es ist auch schon spät ich bin nur wieder auf weil ich nicht Einschlafen kann.

Gruß Richard

[Besserwessi]

Die Baudrate gibt die rate der übertragenen Bits, incl. Start und Stop Bits an. Bei 1 MBaud kommt man so auf 100 kBytes /s.

Das sollte kein prinzipielles Problem sein, wenn man die Hardware UART nutzt. Die Empfängerseite muss aber relativ schnell sein um die Daten auch zu verarbeiten - ob das in Bascom reicht ist mir nicht klar, denn man hat bei 16 MHz Takt nur 160 Zyklen um 1 Byte zu verarbeiten.



Die UART ist einfacher in der Handhabung als I2C, es ist halt eine einfache unidirektionale Übertragung und keine Bus, wo der Master erstmal klären muss für wen die Daten sind.

[Che Guevara]

Hallo,

mit der Einstellung (baud = 1.000.000) fliege ich seit ca. 2 Wochen, alles funktioniert bestens! Die 235µs habe ich gemessen, indem ich den Timer1 vor dem Senden auf 0 gesetzt habe und nach dem Senden dann ausgelesen habe; ich denke, das sollte stimmen
Die Verbindung der beiden µC ist ca. 2-3cm lang, das stellt kein Problem dar. Wie gesagt, es funktioniert so, wie es jetzt ist, mit den obigen Codes. Ich wollte nur wissen, ob ihr denkt, es würde sich lohnen, auf I2C umzusteigen? Meine Argumente hatte ich ja schon im 1. Post erwähnt...
Aber ich denke, ich werde bei UART bleiben, außer jemand bringt ein gutes Argument für I2C oder gegen UART

Gruß
Chris

[Besserwessi]

Es spricht fast nichts für I2C. Einen kleinen Vorteil hat I2C, wenn es darum geht den Slave in den Pausen in einen Stromsparmodus zu versetzen - das geht bei I2C gut, bei der UART geht nur Idel. Das wird hier eher nicht der Fall sein.

[Che Guevara]

Naja, für I2C würde sprechen, dass ich jederzeit völlig problemlos abfragen kann, ob ein ACK und Syn ACK vorhanden war / ist! Das würde die Übertragungssicherheit (bzw. das erkennen von Fehlern) wesentlich vereinfachen.... Außerdem könnte ich dann das BTM222 an die Hardware-Uart anschließen, was auch wieder den erheblichen Vorteil des Interrupts mitsich bringen würde. Ich denke, ich werds einfach mal auf dem Steckbrett ausprobieren, dann kann ich alle Vor- und Nachteile gut abwägen.

Stromsparmodus o.ä. brauche ich nicht, da der ATTINY2313 ständig die PWM für die BL-Regler generieren soll.

Gruß
Chris

[Besserwessi]

Gegenüber einer Software UART ist I2C wohl schon ein Fortschritt. Hinsichtlich der Fehlerabfrage könnte man bei der UART mit eher weniger Aufwand als für I2C auch die Daten oder ggf. eine Prüfsumme zurückschicken - wie sich der Aufwand in Bascom verhält kann ich aber nicht sagen, denn da sind einige Teile recht langsam und andere spezielle Hardwarenahe Funktionen relativ schnell.

Als weitere Alternative gibt es auch noch das SPI Interface: das braucht zusätzliche Pins, ist aber sonst eines der schnellsten, zumindest von der Hardware. Es fehlt vermutlich die gute Unterstützung die Bascom für die UART bietet.