Hallo, hab schon sehr viel über twi gefunden.
Würde gerne mal wissen ob es nicht möglich ist zwei atmega über twi auf
einfachste weise mit einander kommunizieren lassen. Ich dachte da an
gemeinsam deklarierte variablen, die der eine beschreibt und der andere
liest. geht so was, wer hat erfahrung (vielleicht mit bascom)
ich wär für jede hilfe dankbar.
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 und diesen eben so einfach wie möglich mit dem ersten
verbinde. würde lediglich 8 byte vom ersten lesen wollen.
Bitte helft mir
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
sind es, ich habe vor viele sensoren (gyros, beschleunigungssensoren,
magnetfeld etc mit einander zu mischen).
Aber es muss doch leicht möglich sein ein paar bytes von einem zum
anderen prozessor zu schieben. Bitte helft mir.
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.
Kannst auch ein ganzen Port nehmen + einen Interruptpin.
Dein Slave Select Pin ziehst du auf High der andere Mega springt
den Interrupt an und liest das gesamte Byte vom Port.
Ich bezweifel das du so eine blöde Lösung brauchst -
Schafft garantiert ein µC alleine.
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
tausende flieskomma-berechnungen vielleicht nicht aber hundert
vermutlich schon. Und dass würde der Übersichthalber dann doch gerne in
bascom machen. Mein C oder Asm ist halt eingerostet. Deshalb lieber die
Verteilung. Genauer gesagt möchte ich mit dem Master ja zwei weitere
mega8 bedienen. Der erste slave soll die funke auswerten. (und somit
auch eine modulare Ersetzbarkeit ermöglichen, wenn ich z.B. mal auf 2,4
GHz wechsle) und der zweite Slave soll meine 8 Ausgänge in Quasi-PWM
bedienen.
Der soll kontinuierlich die 8 Byte als Servosignal zur Verfügung
stellen.
Und der andere soll 8 Byte abgefragt bekommen, wie die Knüppel gerade an
der Funke stehen. Also ich hab schon klare Vorstellungen. Notfalls mach
ich es halt im Timeshift-Verfahren und sende eben so 10 mal pro sekunde
die 8 Byte auf 19200 über Tx an Rx vom Hauptprozzi und der sendet wieder
mit Tx an Rx von Ausgangsprozzi. Wollte mir die "serile Schnittstelle"
halt für Diag/Parametrierung freilassen. Notfalls muss ich halt mit ner
zweiten SoftUart arbeiten. Wenns aber besser mit I2C ginge würde ich
diese Variante bevorzugen wollen. Deshalb der gedanke mit dem Shard
Memory. Wenn ich einen hardware-Speicherbaustein über I2C von allen
ansprechen könnte, könnte ich das doch nachbilden!?
Danke für die beteiligung schon im Voraus
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 :-)
Eine eigene Frage?
Dieser Thread ist über 17 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
