Arbeitsteilung zw. 2 µC's - Wie würdet ihr es machen?

Hi!
Mein Tricopter (https://www.roboternetz.de/phpBB2/vi...er=asc&start=0) fliegt demnächst (wenn es wärmer ist und der Gyrotemperaturdrift nicht mehr so nervt) autostabil. Das eröffnet die Möglichkeit den Copter autonom fliegen zu lassen. Allerdings erfordert das zusätzliche Sensorik die ich meinem ATmega32 nicht mehr zumuten kann. Er ist mittlerweile ziemlich ausgelastet. Also müssen sich wohl zwei µCs die Arbeit teilen. Hinzukommen würde ein GPS Modul und ein Höhenmesser (Ultraschall,Luftdruck oder beides weiss ich noch nicht).
Wie könnte man das nun machen? Ist die Kommunikation per TWI schnell genug (es sollten mit 400 Hz 4 bytes übertragen werden)? Benötigt die einen Timer? Wieviel Rechenaufwand fällt an um Daten zu empfangen? Macht es evtl. Sinn den Empfänger auf einem anderen µC auszuwerten als auf dem der die Motorsignale ausgibt?

Bevor ich mich mit TWI stärker auseinandersetze (ich finde irgendwie wenig verständliche Anleitungen im Netz...) würde ich gerne eure Empfehlungen hören und herausfinden ob das ganze so überhaupt Sinn macht....

So sieht das im Moment aus, neu hinzukommen würden die Komponenten auf der rechten Seite.
Bild hier  

Hut ab! Tolles Projekt.

Ich hatte ähnliche Überlegungen bei einem anderen Projekt. Also die TWI Schnittstelle läuft als Interrupt, aber im Interrupt selbst sind Wartezeiten drin (bis die entsprechenden Bits gesetzt sind usw...), dies kann Dir Ärger machen in den bisher aufgebauten Routinen, der TWI Interrupt steht zwar fast am Schluss, aber ich weiß jetzt nicht, ob der AVR einen Interrupt (in Deinem Fall den Timer 0 für die Antriebsregelung) unterbricht, wenn ein anderer reinkommt. Der TWI kann auch bis 400 kHz, was eigentlich reichen müßte.

Hast Du mal getestet, wie viel Luft Dein AVR noch hat z.B. Togglebit im Timer auf Oszi gemessen? Wenn hier kaum noch Luft ist, sehe ich die Sache als schwierig an. Dann wäre zu überlegen, einige Aufgaben dem zweiten Kontroller zu übergeben, sprich die Funktionen auf beide Kontroller zu verteilen, dies bricht zwar das Konzept mit der Sensortrennung, würde Dir aber wahrscheinlich etwas Luft verschaffen.

Eine andere Lösung wäre es einen 8 Bit Parallelbus aufzubauen zwischen den Kontrollern -- ohne TWI. Du würdest den einen Kontroller die Daten auf die Leitungen legen lassen und den andere würde sie dann nur am Port abholen, dies ließ sich auch dann über ein Bit einfachst steuern lassen, wenn Du mehrere Daten brauchst, verwendest Du einfach mehr Auswahlbits. (z.B. 3 Bit sind 8 verschiedene Datenbytes). Du mußt natürlich die Eingänge am Hauptkontroller noch freihaben.

Gruss
Volly

Hi Volly!

Zitat:

---

Hast Du mal getestet, wie viel Luft Dein AVR noch hat z.B. Togglebit im Timer auf Oszi gemessen?

---

Meine Regelung läuft mittlerweile nur noch mit ca. 200Hz. Ich glaube viel langsamer sollte das nicht mehr werden, sonst wird es instabil bzw. schwingt sich auf.

Zitat:

---

Eine andere Lösung wäre es einen 8 Bit Parallelbus aufzubauen zwischen den Kontrollern

---

Das klingt sehr interessant.... 10 Ports um 4 verschiedene bytes zu übertragen.... Das müsste eigentlich noch frei sein... Ich würde dann im zweit µC einfach die Daten aus GPS, Höhe und Heading fertig berechnen lassen und an den Haupt-µC die fertigen Sollwerte für die Motoren und das Heckservo übertragen... Das sollte doch funktionieren? Wenn ich das richtig verstehe kann ich die Werte dann genau so schnell abfragen wie mein µC läuft. Also bei 200 Hz und vier Daten immerhin mit 50 Hz... Vielleicht kriege ich den Haupt-µC aber auch noch schneller, allerdings bringt mir Code-optimieren nicht so viel Spaß wie neue Sachen zu implementieren X-D. Müssten die beiden µCs aber nicht auch synchronisiert werden? Dafür geht dann wahrscheinlich auch noch einiges an Zeit drauf.
Ist auf jeden Fall ein sehr interessanter Ansatz, werde mal darüber nachdenken. Hast du das schonmal ausprobiert bzw. jemand anderes aus dem Forum?

theoretisch kannst du deine 4 Byte Telemetriedaten über einen 400Khz TWI Bus mit ~4,76Khz übertragen (wenn ich das jetzt richtig gerechnet habe). Pro 4-Byte Block kommen noch Start- und Stoppbit, Read/Write Bit und 7 Bit Adresse dazu.
Das sollte doch reichen, oder? :)

Den 8-Bit Bus mit den Select Bits kannst du theoretisch mit der halben Taktfrequenz (Ohne Sync) auslesen, das ergäbe max. 8MB/sek, das ist für einen AVR doch etwas viel an Daten.
So ein Bus ist zwar recht einfach zu implementieren, aber doch etwas oversized. Und zum 4-Bit Bus ists auch nicht weit.

Um ein bisschen mehr Luft bei der Verarbeitung zu bekommen, könntest du zb. einen Mega88 einsetzen, der geht bis 20Mhz.

mfg

von wegen 20Mhz - da würd ich dir nen Atmega644 empfehlen, der ist pinkompatibel zum Atmega32 - dann brauchst nicht zu viel an deiner Schaltung ändern :)

Hi,

bzgl. 8-Bit Parallel Bus: ich würde da noch sowas wie eine Fehlerkorrektur einbauen - ich hab bei meinem Bot die Kommunikation auch so gestaltet, und ohne Korrektur war beinahe jedes dritte Byte fehlerhaft - nicht so wahnsinnig gut ;-) Mit Korrektur ist die Fehlerquote nun bei 0%.


Viele Grüße

Hi!

Zitat:

---

theoretisch kannst du deine 4 Byte Telemetriedaten über einen 400Khz TWI Bus mit ~4,76Khz übertragen (wenn ich das jetzt richtig gerechnet habe). Pro 4-Byte Block kommen noch Start- und Stoppbit, Read/Write Bit und 7 Bit Adresse dazu.
Das sollte doch reichen, oder?

---

Wenn mein µC nichts anderes zu tun hätte würde das reichen... Aber wie es scheint haut einem TWI wohl mit interrupts dazwischen.

Zitat:

---

Den 8-Bit Bus mit den Select Bits kannst du theoretisch mit der halben Taktfrequenz (Ohne Sync) auslesen, das ergäbe max. 8MB/sek, das ist für einen AVR doch etwas viel an Daten.

---

Wie soll ich mit 8MHz auslesen...? Dazu brauche ich einen Loop der mit 8Mhz läuft oder? Meiner läuft aber wie gesagt mit 200 Hz...

Zitat:

---

von wegen 20Mhz - da würd ich dir nen Atmega644 empfehlen

---

Den hatte ich ursprünglich auch eingeplant, allerdings passen 16Mhz sehr viel schöner für die Timerinterrupts für die Servoansteuerung...

Zitat:

---

bzgl. 8-Bit Parallel Bus: ich würde da noch sowas wie eine Fehlerkorrektur einbauen

---

Hast du denn eine synchronisation? Dem Zweit-µC muss doch mitgeteilt werden dass der Erst-µC seine Daten abgeholt hat. Also bräuchte man wohl noch einen zusätzlichen Port den der Erst-µC nur auf high setzt wenn er bereit ist daten zu empfangen... Während der high-zeit sendet µC2 einen konstanten wert, während der low zeit erstellt er den nächsten wert... Oder so ähnlich...
Ich programmiere in Bascom, gibt es hier wohl eine Funktion oder ein Beispiel wie man aus den einzelnen Port-Bits ein Byte zusammenschraubt mit dem sich weiter rechnen lässt?
Danke auf jeden Fall für eure Anregungen @all

Hi Willa,

ich hab sowohl einen 8 Bit - Bus vom "Master" zum "Slave", als auch wieder zurück. So kann der Slave die Daten zurücksenden, um sie überprüfen zu lassen.

Ich würde mich nicht auf eine Kommunikation ohne Rückmeldung verlassen, denn durch die Motoren ist schnell eine Störung "eingesät", und so ein Tricopter ist schneller am Boden als ein Hexapod ;-)

Viele Grüße

Hi,

Zitat:

---

Zitat von Willa

... Wenn mein µC nichts anderes zu tun hätte würde das reichen... Aber wie es scheint haut einem TWI wohl mit interrupts dazwischen ...

---

GENAU mit diesem Problem schlage ich mich seit einiger Zeit herum. Nun habe ich keinen xxCopter - nur einen "popeligen" Zweiräder. Aber der ist auch mit einigen empfindlichen Interrupts gespickt - Zeitgeber 20kHz, Regelung für zwei Motoren - also 2 x 405 Hz, irDME - 1,22 kHz. Dazu noch zwei extINT für die Drehzahlerfassung der Motoren mit ISR bis jeweils max. 1500 Hz. - normal etwa je 1 kHz.

TWI hatte ich noch nie installiert - die hier vorgelegten Argumente hatte ich schon mal rausgehört - und daher TWI weggelegt/abgehakt. Tatsächlich funktioniert hatte bei mir die Kommunikation zwischen zwei Controllern mit dem seriellen Protokoll "TTL"232. Lief bisher in der Testphase zufriedenstellend und fehlerfrei mit 57600 Bd. Ich hatte es noch nie in der eigentlichen Funktionsumgebung realisiert, da ich mir den zweiten Controller bisher gespart hatte. Das scheint mir als Kommunikation zwischen zwei Kontrollern sinnvoll und ausreichend schnell zu sein - und die Hardware ist ja bei megas praktisch immer vorhanden. Ich hatte auch angedacht einen dritten Controller dranzuhängen, der mir die Kommunikation zum PC ermöglich - der die Steuerbits für die µC-µC-Verbindung ausblendet und nur Daten "nach aussen" durchlässt.

@Willa: Übrigens hast Du mich auf einen weißen Fleck in meiner Auslegung gebracht. Ich hatte zwar alle ISR zeitlich recht genau ausgemessen - aber NIE die Kommunikation :(. Na ja, wie gesagt - das war bisher nur Testphase.

Jedenfalls wünsche ich Dir viel Erfolg

Zitat:

---

Zitat von ikarus_177

Hi,

bzgl. 8-Bit Parallel Bus: ich würde da noch sowas wie eine Fehlerkorrektur einbauen - ich hab bei meinem Bot die Kommunikation auch so gestaltet, und ohne Korrektur war beinahe jedes dritte Byte fehlerhaft - nicht so wahnsinnig gut ;-) Mit Korrektur ist die Fehlerquote nun bei 0%.

Viele Grüße

---

Naja 8bit gehen auch ohne clockleitung ... must nur zwei ports verbinden die interupt on change unterstützen den haste die daten sobald sich was Ändert must nur immer hinungdherschalten wegen senden / entfangen altanativ spi