Ausführungsgeschw. I2C vs SPI Kommunikation

[malthy]

Hallo!

Ich habe folgendes Problem: zwei M8 auf einem Board sollen miteinander kommunizieren. Ein Controller ist nur damit beschäftigt, einige Ports zu pollen. Das ist SEHR zeitkritisch, d.h. ich möchte auf jeden Fall die Wahrscheinlichkeit klein halten, etwas an einem Port zu verpassen (Randbemerkungen: 1. ich weiss, dass Bascom für so eine Aufgabe nicht unbedingt die optimale Sprache ist, ich möchte vorerst trotzdem dabei bleiben, 2. die Hardware-Interupts sind schon verbraucht, es ist die einzige Möglichkeit zu pollen). Der zweite Controller soll sich um ein kleines User-Interface (UI) kümmern, d.h. er stellt Werte auf einem LCD dar, fragt einige Tasten ab und macht UART Kommunikation mit einem PC. Es geht nun natürlich darum, vom erstgenannten M8 Daten in den UI-M8 zu bekommen. Der Punkt ist, dass die Kommunikation auf dem ersten M8 natürlich so wenig Zeit wie möglich verbrauchen soll.

Ich habe mehrere AVRs bisher immer per I2C miteinander Reden lassen, in diesem Falle frage ich mich, ob SPI nicht schneller wäre. Und mit "schneller" meine ich nicht einfach den reinen Bustakt (der ist bei SPI ja in der Tat potentiell schneller) sondern welche Zeit die entsprechenden Bascom Routinen benötigen würden. Kann mir da jemand ein paar Hinweise geben?

Vielen Dank für alle Tipps! Viele Grüße!
Malte

[Jaecko]

Auch mit nur 1 freien Interrupt kannst du trotzdem mehrere Pins "abfragen".
Die Pins einfach alle mit einer Diode (1N4148 etc.) an den INT-Pin legen. Sobald einer der Pins auslöst, reagiert auch gleichzeitig der INT-Pin.
In der ISR dann als erstes nachschauen, welcher Pin das war.

Ansonsten wenns wirklich schnell gehen muss, würd ich SPI verwenden. I2C geht zwar nach Spezifikation auch in den Bereich MBit, bei nem 16MHz-AVR ist aber bei 400 kBit so ziemlich Schluss, wenn man die Formel


TWBR = ((F_CPU/scl_clock)-16)/2; // must be > 10 for stable operation

beachtet.

Aber wie du auch schon gesagt hast: Zeitkritisch und Bascom widersprechen sich etwas.

[malthy]

Hallo Jaecko (und alle anderen)!

Danke, das entspricht auch meiner Intuition. Ist die Ausführungsgeschwindigkeit des I2C- bzw. SPI-Codes Deiner Ansicht nach einigermaßen proportional zum verwendeten Bustakt?

An die Variante mit Dioden ein einfaches Oder-Glied aufzubauen, hatte ich auch schon kurz gedacht aber es nicht weiter verfolgt. Du hast Recht, das sollte ich so machen. Danke für den Hinweis!

Ich hätte dann aber noch eine Nachfrage: wenn während der SPI-Übertragung ein Interrupt erfolgt (und die ISR hinreichend klein ist), bleibt dann die SPI-Kommunikation ungestört? Ich denke das sollte so sein, weil SPI ja die Clock mitüberträgt, aber ich bin mir da garnicht sicher... :-)

Vielen Dank, viele Grüße!
Malte

[Jaecko]

Indirekt proportional schon.
Also die SPI-Geschwindigkeit ist durch einen Hardware-Teiler an die F_CPU gekoppelt, d.h. da sind nur ganzzahlige Teiler (2^x) möglich.
Bei SPI gibts eigentlich keine "ideale" Frequenz; hier fährt man einfach vollgas, je nach dem was halt die Kommunikationspartner können.

Bei TWI/I2C hast du mit dem TWBR noch nen gewissen Spielraum, um so grobe Standardwerte einzustellen. Übliches Minimum sind 100kHz für I2C, Maximum eben so, dass TWBR > 10 ist bzw. dass die I2C-Geräte noch mitkommen.

Wenn während der SPI-Übertragung ein Interrupt kommt, wird das aktuell angefangene Byte noch fertig gesendet (das macht die Hardware ja von alleine), das nächste Byte kommt aber erst dann, wenn der Interrupt beendet ist und SPDR wieder gefüttert wird.

[malthy]

Vielen Dank!

Malte