Frage zur Arbeitsweise von I2C und SPI

[Barney (Gast)]

Guten Tag

Ich habe die Aufgabe mit einem AVR einen Konoten zu machen mit dem 
Soll-Daten mit niedriger Priorität in einen Bus für Regeldaten mit hoher 
Priorität eingeschleust werden.

Dabei werden die Rergeldaten über I2C verarbeitet und die Solldaten 
kommen über SPI.
Da der Knotenprozessor einiges zu rechnen hat, würde es mich 
interessieren ob das Programm während dem Empfangen unterbrochen wird, 
oder ob das Byte einfach nur aus der Variable ausgelesen werden muß wenn 
gerade Zeit ist.

Weis da jemand etwas genaueres?
Ich konnte im Datenblatt leider nichts genaues darüber finden.

mfg Barney

[Falk B. (falk)]

@ Barney (Gast)

>Dabei werden die Rergeldaten über I2C verarbeitet und die Solldaten
>kommen über SPI.

Warum zwei Busse? Das halte ich für wenig sinnvoll.

>Da der Knotenprozessor einiges zu rechnen hat, würde es mich
>interessieren ob das Programm während dem Empfangen unterbrochen wird,

Naja, für EIN Byte muss das Programm nicht unterbrochen werden, das kann 
die SPI puffern. Bei mehreren Bytes geht das logischerweise nicht.

MFG
Falk

[Barney (Gast)]

Guten Tag

>Warum zwei Busse? Das halte ich für wenig sinnvoll.

Weil nicht alle verwendeten Komponenten I2C unterstützen.
Außerdem will ich nicht dass diverse Dinge mit niedriger Priorität wie 
das Abspeichern von Sensor-/Aktorstatistiken, das Ansteuern des LCD,... 
dem Regelkreis dazwischenfunkt.

Am Regelbus hängen diverse Aktoren und Sensoren die mit absoluter 
Priorität arbeiten müssen.
Wenn da das falsche Signal zur falschen Zeit daherkommt bricht die 
gesammte Regelung zusammen.
(Außerdem hat der Bus nicht genug Ressourcen übrig um alle Daten zu 
verteilen.)

Da die kleinen AVR's selten 2 I2C oder 2 SPI haben, verwende ich also 2 
verschiedene Bus-Systeme.


>Naja, für EIN Byte muss das Programm nicht unterbrochen werden, das kann
>die SPI puffern. Bei mehreren Bytes geht das logischerweise nicht.
Danke für die Information.
Mehr braucht ja auch nicht übergeben werden.

mfg Barney

[2920 (Gast)]

Wenn das Timing dermassen kritisch ist, wuerd ich's nicht mit einem 
Controller machen, sondern mit einem FPGA oder einem CPLD

[Barney (Gast)]

Das Timing ist nicht so kritisch.

Wenn diverse Teilnehmer die nicht der Regelung dienen die Daten über das 
gleiche Netz schicken können, kann ich nicht mehr sicher sein dass die 
Daten der Regelung rechzeitig durchkommen.

Und wenn die Daten der Regelung absolute Priorität haben, kann ich nicht 
sicher sein dass der Rest rechzeitig abgearbeitet wird.
Z.B. ist es nicht lustig wenn eine Haufen der Daten verloren gehen, 
Eingaben nicht beachtet werden oder das Display nicht aktualisiert wird.

Aus diesem Grund trenne ich das Ganze in 2 Prioritätsebenen auf.
Dadurch habe ich weniger Arbeit und habe es leichter bei der 
Fehlersuche.

mfg Barney

[Stefan W. (wswbln)]

...und dann nimmst Du den langsamen I2C für die hochpriorisierten Dinge 
und den schnellen SPI für die nebenläufigen???

[Barney (Gast)]

>...und dann nimmst Du den langsamen I2C für die hochpriorisierten Dinge
>und den schnellen SPI für die nebenläufigen???

Weil ich Komponenten im Regler-Bussystem habe die nur I2C können.
Priorität hat übrigens wie Echtzeitfähigkeit nicht immer etwas mit 
Geschwindigkeit zu tun.
(Außerdem habe ich absolut keine Lust das Handhaben verschiedener 
Prioritätsstufen auf einem Bus softwaremäßig zu lösen.)

Mfg Barney