gemeinsame variablen über twi verwenden.

migo schrieb:
> P.s. der eine prozessor ist mit dem auswerten der 8 Kanäle meines
> empfängers so beschäftigt,

Glaub ich nicht.


> dass ich einen zweiten nutzen möchte den rest
> zu erledigen und diesen eben so einfach wie möglich mit dem ersten
> verbinde. würde lediglich 8 byte vom ersten lesen wollen.

Das müssen ja mordsmäßig komplizierte Rechnungen sein, damit sich der 
Aufwand lohnt, die Daten über den Flaschenhals I2C zu schleusen.


Peter

migo schrieb:

> Aber es muss doch leicht möglich sein ein paar bytes von einem zum
> anderen prozessor zu schieben. Bitte helft mir.

Mehrprozessorlösungen sind nur in Ausnahmefällen leicht. In den meisten 
Fällen möchte man diese vermeiden, wo auch immer es geht. Relativ leicht 
sind Mehrprozessorlösungen nur dann, wenn es eine klare Sender/Empfänger 
Struktur gibt, sprich: ein µC sitzt in der Mitte, wie die Spinne im Netz 
und verteilt Kommandos bzw holt Ergebnisse reihum von den Satelliten 
ein. Und das auch nur dann, wenn der Falschenhals 'Datenübertragung' 
nicht das zeitbestimmende Glied ist.

Du könntest tatsächlich so eine Struktur haben, also lies dich ins Thema 
TWI ein. Und vergiss die Idee mit 'gemeinsamen Variablen'. Dein 
zentraler Prozessor schickt ein Kommando an den Satellitenprozessor und 
der antwortet mit seinem Wert.

> P.s. der eine prozessor ist mit dem auswerten der 8 Kanäle
> meines empfängers so beschäftigt, dass ich einen zweiten nutzen
> möchte den rest zu erledigen.

Das klingt erst mal einleuchtend. Und zwar genau solange, bis man 
draufkommt, dass der erste, vermeintlich dichte, Prozessor ja auch noch 
nebenher die Kommunikation machen soll. Und zwar fehlerfrei, was 
normalerweise ein recht enges zeitliches Korsett für diesen Prozessor 
bedeutet.

migo schrieb:
> sind es, ich habe vor viele sensoren (gyros, beschleunigungssensoren,
> magnetfeld etc mit einander zu mischen).

Es gibt keinen mathematischen "Misch-Operator".

Ich vermute, Dein Hauptproblem ist, Deine Aufgabe erstmal verständlich 
zu beschreiben.


> Aber es muss doch leicht möglich sein ein paar bytes von einem zum
> anderen prozessor zu schieben. Bitte helft mir.

Was hast Du davon, wenn Du nichtmal weißt, was Du mit den Daten machen 
willst.

Du mußt mindestens schon tausende float-Rechnungen benötigen, damit sich 
das I2C-Geraffel überhaupt lohnt.


Peter

migo schrieb:
> tausende flieskomma-berechnungen vielleicht nicht aber hundert
> vermutlich schon.

Oder gar keine :-)

> auch eine modulare Ersetzbarkeit ermöglichen, wenn ich z.B. mal auf 2,4
> GHz wechsle)

erstens hat das Frequenzband nichts mit der Auswertung zu tun und wenn 
du wirklich mal auf 2,4Ghz wechselst, hast du ganz andere Probleme.

> und der zweite Slave soll meine 8 Ausgänge in Quasi-PWM
> bedienen.

Gäähn.
Und wie verhinderst du, dass der µC wegen chronischer 
ArbeitsUNTERlastung Selbstmord begeht?

> Der soll kontinuierlich die 8 Byte als Servosignal zur Verfügung
> stellen.

Ach ne.
Servosignale, und dann noch 8 Stück.
Das macht der Timer mit ein bischen Hilfe in der IRQ schon fast alleine.

> Und der andere soll 8 Byte abgefragt bekommen, wie die Knüppel gerade an
> der Funke stehen.

8 mal ADC auslesen. Auch nicht gerade Raktentechnik. Das macht die ADC 
Unit mit ein bischen Hilfe in einer IRQ ganz von alleine.

> Also ich hab schon klare Vorstellungen.

Ja klar.
Man kann natürlich von Salzburg nach München über Helsinki fahren und 
sich Gedanken darüber machen, wie man 3000 Kilometer mit nur einer 
Tankfüllung hinkriegt. Man kann aber auch einfach direkt fahren :-)