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 :-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.