Archiv verlassen und diese Seite im Standarddesign anzeigen : Kommunikation zwischen Mikrocontrollern
Dunkle Macht
14.07.2011, 18:48
Hallo,
aufgrund diverser Probleme mit unseren Motoren haben wir uns dafür entschieden in Zukunft die Geschwindigkeit von diesen mit Encodern zu steuern. Dazu würde ich gerne einen 2. controller nehmen, der Anweisungen vom Hauptprozessor ausführt. Dieser müsste dann die 4 Antriebsmotoren (Omnidirectionaler Antrieb) , die bis zu 900rpm erreichen, regeln. Da wir die Encoder selbst bauen ist noch offen wie viele Impulse es pro Umdrehung werden. Wir möchten die für den Encoder notwendigen Magneten direkt am Rad befestigen. Ich habe mir so 8 Impulse pro Umdrehung vorgenommen. Ist das machbar? Das Rad dreht sich immerhin mit 900 rpm.
Die nächste Frage wäre der Controller. Ich denke ein Atmega128 wäre etwas overpowered. Ich denke ein Atmega8 würde auch reichen oder?
Doch nun zum Hauptproblem:
Wie lässt man die beiden Controller (Hauptprozessor ist ein Atmega128) miteinander kommunizieren?
I²C steht leider nicht zur Verfügung. Ist es einfacher den Slave mit einem PWM Signal für jeden Motor zu steuern oder würde serielle Schnittstelle mehr Sinn machen?
Gruß
Lukas
Wenn I2C ausfällt (warum?) ist seriell sicherlich die einfachste Möglichkeit der Kommunikation, da alles schon in den Atmels integriert ist. Man braucht 3-5 Zeilen Code um die Schnittstellen zu konfigurieren und das senden und Empfangen läuft dann mit einem Befehl vollautomatisch ab.
Dunkle Macht
14.07.2011, 19:23
Hallo,
ok. I²C fällt weg, da das auf unserem Board verwendet Prozessormodul kein I²C kann. Das hört sich schonmal gut an. Ich nehme an, dass die intergrierte Konfiguration auch zwischen unterschiedlichen ControllerTypeen funktioniert, richtig?
Ich muss evtl. noch erwähnen, dass die PWM Ports am Master bereits vorhanden wären.
Den größten Vorteil der Seriellen Schnittstelle sehe ich darin dass der Slave auch ganz einfach antworten kann, oder?
Hast du vielleicht noch eine kleine Lektüre wo man sich bisschen in die serielle schnittstelle einlesen kann?
Gruß
Genau. Und ich denke du willst Geschwindigkeit übertragen, das geht seriell bestimmt besser wie mit PWM. Das müsstest du im Motor-Controller ja erst wieder zurück wandeln.
Als Lektüre empfehle ich die Datenblätter von Atmel zu den Controllern. Da sind auch schöne Beispiele drin.
Hallo,
- Wenn beide Controller (wenn ich das richtig verstanden habe) mit der Steuerung (Auslesen der Drehzahl, Regler, Einstellen der Motorspannung bzw. des PWM) beschäftigt sein sollen,
bringt eine Lösung mit 2 Controllern immer ein Problem: Zeit. Ich würde in so einem Fall eher einen leistungsstärkeren Controller nehmen.
- Die Zahl der nötigen Impulse pro Umdrehung hängt von der Erfordernissen ab: Wie schnell soll die Steuerung funktionieren, nach wie vielen Umdrehungen soll eine Abweichung korrigiert
werden, je mehr Impulse / Umdrehung desto schneller die Reaktion.
- Wenn schon 2 Controller, dann Schnittstelle, nicht PWM, der Aufwand, dass PWM-Signal im Timer/Counter auszuwerten, ist in jedem Falle aufwendiger und prozessorzeitraubender. Auf jeden
Fall sollte der Slave-UART im RXC_INT-Modus und nicht im Polling betrieben werden.
- Ich verwende zur Drehzahlsteuerung / Wegmessung die Rotary-Encoder von austriamicrosystems AS5040, vielleicht lohnt mal ein Blick ins Datenblatt.
mfg
achim
Ich glaube bei der Trennung geht es weniger um die Performance, als um die Aufteilung des Problems in zwei Teile. Oder?
Dunkle Macht
16.07.2011, 10:08
Hallo,
die Zeit der Übertragung spielt eigentlich keine Rolle, da der Hauptprozessor nur eine Zahl von 0-255 schickt, die der Coprozessor dann mit dem bestimmten motor fahren soll. Die Auswertung der Impulse und die Reaktion darauf soll dieser dann steuern. Würdet ihr hierfür die Zählereingänge nehmen oder lieber Interrupteingänge?
Gruß
Eigentlich ist es egal, das kommt ein bischen darauf an, ob dein Sollwert (0-255) die Geschwindigkeit oder die Anzahl der Impulse sein soll, die gefahren werden soll. Bei der Geschwindigkeit wird der Zählereingang wohl etwas einfacher sein.
Chypsylon
16.07.2011, 19:52
ok. I²C fällt weg, da das auf unserem Board verwendet Prozessormodul kein I²C kann.
Ich dachte ihr verwendet das gleiche Board wie die Antitischhocheber und da ist ja ein 128er oben der eigentlich schon i2c kann?
Gruß
Alex von den Androids
Dunkle Macht
17.07.2011, 09:03
Hallo,
ist das gleiche board, jo. Das is aber n Prozessormodul, da sind schon paar bauteile mit drauf und das Modul kann aus Gründen, die sich mir auch nicht ganz erschließen, kein I²C.
Ist aber auch nicht weiter schlimm weil bis jetzt seriell immer gereicht hat.
Gruß
Lukas
Chypsylon
20.07.2011, 17:09
Und wie lest ihr dann den Kompass aus? über PWM?
hallo,
Ich glaube bei der Trennung geht es weniger um die Performance, als um die Aufteilung des Problems in zwei Teile. Oder?
Wer schon mal versucht hat, etwas digital zu regeln, weiss: Das ist ist IMMER eine Frage der Zeit, quasi der Performance.
Und wie lest ihr dann den Kompass aus? über PWM?
Etwas mit PWM auslesen stelle ich mir zumindest sehr tricky vor. Was hat denn dieser Kompass für eine Schnittstelle.
mfg
achim
i_make_it
21.07.2011, 08:13
1234567890
hallo,
Nicht umsonst wird bei Computern das Ganze in eine eigenständige Netzwerkkarte ausgelagert.
Nicht umsonst wird bei (den meisten) Mikrocontrollern das ganze in eine eigenständige Hardwareeinhait USART ausgelagert.
Wenn man diesen, mit samt seinen Interrupts und mittels gut organisierter Lese-/Schreibpuffer (RXCINT/DREINT) nutzt,
sehe ich selbst bei hohen bps kaum ein Problem, also m.M.n. kaum mit Ethernet-Zeit- und Kollisionsproblemen zu
vegleichen.
mfg
achim
Dunkle Macht
21.07.2011, 13:09
Hallo,
kann man irgendwie Prioritäten setzen, dass also der Slave nur Senden kann wenn der Master nicht sendet, oder anders gesagt, dass der Master ein Signal schickt, wenn er nichts senden will, dieses Signal aber dann von der Antwort des Slaves überlagert wird?
@Chypsylon: Den kompass lesen wir, wie du bereits vermutet hast, über Pwm aus.
Gruß
Lukas
Oder erher nicht.
Wenn der Slave einfach antwortet wann es ihm beliebt, kann er auch genau in dem Moment antworten in dem der Master was sendet.
Das gibt dann eine Kollision wie wir sie von Ethernet kennen (Stichwort CSMA/CD = Carrier Sense Multiple Access / Colission Detected).
Also Entweder eine Art Interrupt Leitung pro Slave die dem Master signalisiert ob der jeweilige Slave grade ein wichtiges Event hat oder ein Master/Slave Bus, bei dem der Master zyklisch pollt und die Slaves fragt ob sie was zu melden haben.
Es gibt noch die Möglichkeit nach CAN Bus Art. Da kann jeder jederzeit senden. Jedes gesendete Bit wird zeitgleich vom Sender selber gelesen, wird es als überschrieben erkann, geht der Sender vom BUS und sendet neu wenn der Bus frei ist. Das klappt deshalb weil der BUS mittels Pull-Up hochgezogen wird und der Sender diesen auf L zieht, die Daten also L Aktiv sind ein H wird nicht gesendet das ersetzen die Pull-Up.
Der CAN Bus kann aber auch per Polling arbeiten und trotzdem während dessen von Sendern höherer Priorität (mehr L Pegel) unterbrochen werden, so wird gewährleistet das wichtige Meldungen Vorrang behalten. Ähnliches klappt auch mir RS232 und CAN bus Treibern wenn man sich das in ASM selber "Bastelt". Es muss halt JEDES Bit(vom Sender) auf überschrieben geprüft werden.
http://de.wikipedia.org/wiki/Controller_Area_Network
Gruß Richard
Chypsylon
21.07.2011, 20:23
Hallo,
kann man irgendwie Prioritäten setzen, dass also der Slave nur Senden kann wenn der Master nicht sendet, oder anders gesagt, dass der Master ein Signal schickt, wenn er nichts senden will, dieses Signal aber dann von der Antwort des Slaves überlagert wird?
@Chypsylon: Den kompass lesen wir, wie du bereits vermutet hast, über Pwm aus.
Gruß
Lukas
So programmieren das der Slave nur antwortet wenn ihm der Master vorher den Befehl dazu gibt und der Master muss dann eben mit dem senden solange warten bis er eine Antwort erhalten hat (oder ein Timeout erreicht ist) ;)
Eine andere Möglichkeit wäre auch noch SPI, wenn euer Controller das kann (was normalerweise der Fall ist). siehe z.b. http://www.ermicro.com/blog/?p=1050
Dunkle Macht
22.07.2011, 13:27
Hallo,
SPI Schnittstelle wäre ebenfalls vorhanden, stimmt.
Ist das die bessere Lösung gegenüber seriell?
Gruß
SPI und I2C kann zur Not auch per Bitbanging in Software gemacht werden.
SPI kann in Harware ne ganze Ecke schneller sein als UART
SPI und I2C kann zur Not auch per Bitbanging in Software gemacht werden.
SPI kann in Harware ne ganze Ecke schneller sein als UART
Wobei hier durch die Adressierung, R/W Bit und NAK/ACK schon erhebliche Sicherheit vorgesehen ist. Nur das dabei natürlich Polling verwendet werden muss oder das Polling nur auf IRQ Anforderung gestartet wird.
Gruß Richard
Chypsylon
22.07.2011, 17:10
Hallo,
SPI Schnittstelle wäre ebenfalls vorhanden, stimmt.
Ist das die bessere Lösung gegenüber seriell?
Gruß
IMHO nach schon aber über UART (seriell) ist es wahrscheinlich einfacher und sollte genauso funktionieren wenn du es so machst wie ich es oben geschrieben habe.
Ich würde vorschlagen ihr probiert es einfach zuerst über seriell und dann könnt ihr ja immer noch auf SPI umsteigen...
Hallo allerseits,
ich hab hierzu auch ne Frage
Wenn ich (nur) zwei atmega8 miteinander "reden" lassen will reicht es doch wenn ich rx mit tx und andersrum verbinde und dann noch die massen verbinde oder?
mfg Sebastian
Hallo allerseits,
ich hab hierzu auch ne Frage
Wenn ich (nur) zwei atmega8 miteinander "reden" lassen will reicht es doch wenn ich rx mit tx und andersrum verbinde und dann noch die massen verbinde oder?
mfg Sebastian
Jain......die Anschlüsse müssen gekreuzt werden....
TX>>>>>RX,Senden>>>>>>Empfangen
RX<<<<<TX,Empfangen<<<<<<Senden
GND-------GND
Baud,8,n,1 muss bei beiden gleich sein und wenn der µC mit internem Takt arbeitet kann es Probleme bei hohen Baudraten geben.
Gruß Richard
Da war ja sogar noch jemand wach :-) danke für die schnelle antwort
Ähmm ja so meint ich das, hab mich wohl schlecht ausgedrückt. Sorry
Okay jetzt bin ich beruhigt und kann in ruhe weiterlayouten. Vielen Dank.
mfg Sebastian
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.