Schnellste serielle Schnittstelle

Hallo Leute,
Für mein Projekt brauche ich einen sehr schnellen Bus. Ein paralleler Bus schließt sich fast aus, da ich kaum mehr freie Pins am ATmega16 frei habe.
Der Takt ist 16MHz.
I²C (TWI) ist superlangsam, hat einen maximalen Takt von 100kHz (dazu kommen noch Adressbits)
Der USART ist da etwas schneller, hat sowei ich weiß bei 16MHz einen max Takt von 1Mhz (oder 0,5MHz??).
Das SPI scheint am schnellsten zu sein, mit einem maximalen Takt von 4MHz (1/4 des Systemtakts)

Stimmt das alles, oder habe ich irgeneinen Fehler reingebastelt?
Was ich so komisch finde ist, das I²C so furchtbar langsam ist. Wie kommt das?

Gruß, Yaro

Edit: meine Infos habe ich aus dem Buch "mikrocomputertechnick mit Controllern der Atmel AVR-RISC-Familie 4. Auflage"
Ich habe gerade bei WIKI gelesen, dass I²C bis zu 3,4MHz Takt hat. Stimmt das?

Der I2c geht soweit ich weiß bis 400kHz

Jetzt habe ich noch was neues herausgefunden:
"Der Bus hat in der aktuellen I2C-Spezikation 2.1 von 2001 eine maximale
Datenübertragungsrate von 3,4 Mbit/s (High-Speed Modus), jedoch ist der
ATmega 16 ein Fast-Mode Gerät, daher können nur Übertragungsraten von
maximal 400 kbit/s verwendet werden."

Sher interresant, das habe ich nicht gewusst

Noch was neues:
TWI stands for Two Wire Interface and for most marts this bus is identical to I²C. The name TWI was introduced by Atmel and other companies to avoid conflicts with trademark issues related to I²C. A description of the capabilities of TWI interfaces can be found in the data sheets of corresponding devices. Expect TWI devices to be compatible to I²C devices except for some particularities like general broadcast or 10 bit addressing.

For the time being there is also no TWI high speed mode.

If you have an I²C analyser it will work with a TWI set-up as well without modifications.

SPI geht bis hahlbe Takfrequeunz: 8MHz
Gruß

uart kann man im synchron modus glaube auch bis 8Mhz fahren bei 16Mhz clock! oder ich hab die formel im datenblatt falsch interpretiert (iss ja quasi nix anderes als SPI nur verschwendet der noch 2-3 bits für start und stop, was allerdings der fehlererkennung dienlich ist!)

Wir haben I2C bei unsrem Bot im Einsatz, und haben mit einigen Experimenten die maximal stabile Frequenz auf 340-360 kHz eingestellt. Darüber funktionierte die Übertragung nicht mehr.

Das Senden (bzw. als Master) geht der 8 MHz takt bei SPI, als Slave geht es soweit ich weiss nicht so schnell. Da sollten wenigstens 4 Takte je Bit vorgesehn sein. Damit man noch etwa Reserve hat, weil die Quarze ja nicht 100% gleich sind, wird man eventuell sogar 6 Takte nehmen müssen. Und weil das vermutlich nicht einzustellen ist, könnte es sein das 8 Takte je Bit wohl das minimum sein wird.

Als Slave braucht man für SPI tatsächlich 4 Takte, als Master gehen auch 2 (wieso eigentlich nicht auch 1???)
Ich hatte SPI mal mit 8MHz laufen, mit 1/4 Takt (master und salve), und es lief ohne Fehler. Habe sogar interne Oszilatoren verwendet, die ja nicht so genau sind....

> "wieso eigentlich nicht auch 1"
Weil auf einer Flanke des SCK die Daten angelegt werden und auf der anderen Flanke die Daten eingelesen werden - Da ist es nicht so einfach, noch was dazwischenzusetzen...

> "8MHz laufen, mit 1/4 Takt"
=> Fclk = 24MHz => AVR übertaktet? ;P

ich glaub er hat nur paar daten verwürfelt, mit internem osc gehen auch nru 8Mhz da iss 8Mhz SPI auch unmöglich XD

trotzdem hätte Tux das problem, dass datenkollisionen entstehen könnten! (multimaster ?! )
er bräuchte schon etwas schnelleres mit zwischenspeicher wenn cih das richtig vertanden habe

Ich meine, ich hatte den AVR mit 8MHz laufen, und SPI dann mit 1/4 Takt, also 2MHz =)

Übrigens....habt ihr die neuen XMEGAS gesehen? die haben ja übertrieben viele Schnittschtellen. wenn ich mich recht erinnere, dann sowas wie 2xTWI, 4xSPI und 8xUSART. Wozu braucht man so viele schnittschtellen???
Diese XMEGAS sind schon wirklich extrem!

So viele "schnittschtellen" ("scht" oder "st"?) braucht man schon manchmal.
Hier im Forum wird sich öfter darüber beklagt, dass man die Schnittstellen der Atmegas bereits voll benutzt und nun nicht mehr weiß, wie es weiter geht.

Es geht ja auch darum, dass diese Schnittstellen nicht einfach nur die Pinbelegung reserviert bekommen, sondern dass sie ein entsprechendes Hardwaremodul haben, damit die Software nichts machen muss.