Archiv verlassen und diese Seite im Standarddesign anzeigen : Kommunikation zwischen mehreren µC
Hallo Zusammen,
ich habe mal (wieder :oops: ) ein Problem:
Ich muss für eine Antennensteuerung mehrere ATMEGA 32 verbinden.
Es gibt 2 St auf der Groundstation (nennen wir sie mal Mega1 und Mega2)
und zusätzlich noch ein XBEE. Über das XBEE kommen GPS Daten rein.
Der Mega1 berechnet aus den xbee GPS Daten und GPS Daten, die er über eine eigende Antenne (rs232) empfängt, eine Position in die Er die Schrittmotoren stellt. Die berechneten Winkel, Status und die 2 GPS Koordinaten (Lat1, Lon1, Lat2, Lon2) sollen nun zum Mega2 übergeben werden, welcher die darstellt auf einem LCD. Der Mega2 soll aber auch z.B. einen Offset per Encoder dem Mega1 mitteilen, wonach ebenfalls die Schrittmotoren gestellt werden. Nun zum letzten gerät in der Kette: Der PC. Der Soll alle Daten bekommen, die Relevant sind (Status, GPS Daten, Winkel der Schrittmotoren ...).
Nun meine Frage: Kann ich dass alles über einen RS232 bus laufen lassen? Da habe ich aber folgendes Problem: woher soll der Mega1 wissen welches GPS signal vom XBEE kommt und welches vom GPS Empfänger am Boden (beides die Gleichen) ??? ](*,)
Wenn ich jetzt statt 2 Mega 32, 2 Mega162 nehme kann ich dann das Realisieren was ich vorhabe? Quase Mega1 ist nen 162er bekommt über Uart1 das GPS vom Boden und über Uart2 das vom XBEE und gelichzeitig hängt an dem Uart2 der Mega2 als 162er ?? Nur der 162 hat nur 16kb ram und das dürfte für nen Grafik LCD wenig werden??? Wenn es geht möchte ich smd vermeiden :-k
So nun aber Genug geschrieben -- ich hoffe ihr könnt mir Folgen [-o<
Also bitte Helft mir :D
Wie weit sind denn die einzelnen Controller voneinander entfernt?
Wenn die Verbindungen kurz sind würde ich SPI verwenden einen Controller als Master nehmen und die einzelnen Controller per SPI anbinden.
Über verschiedene /SS Leitungen können dann die einzelnen Slaves angesteuert werden, da die SS Leitung im Master sowieso per Software verwaltet werden muß.
Der Master holt sich dann die Daten vom benötigen Slave.
Wenn die Verbindungen länger werden wäre eventuell ein RS485 Bus angebracht. In einer Multimaster Umgebung ( Jeder Controller kann willkürlich daten senden ) müsste man da auf ein etabliertes Bus Protokoll zurückgreifen - Stichwort Kollisionserkennung.
Ist ein Betrieb mit nur einem Master möglich könnte der dann über den Bus einzelne Controller adressieren. Und nur der adressierte Controller antwortet.
Spontannachrichten von einem Slave Controller sind so aber nicht möglich.
So ein RS 485 Bus kann aus bis zu 32 Busteilnehmern bestehen.
Den Handshake zwischen den Controllern kannst Du Dir selber ausdenken, was bei einem Single Master Betrieb relativ einfach ist, oder versuchen eine fertige .lib zu finden.
Die Bustreiber für den RS 485 ( z.B. SN75176 ) kannst Du mit dem USART und einer zusätzlichen Steuerleitung für Senden / Empfangen einfach anbinden.
geht alles, und das RAM hat mit dem GLCd auch nichts weiter zu tun, es sei denn Du willst den ganzen Frameinhalt im RAM halten, was käse ist.
Das knifflige an der ganze Geschichte ist das Protokoll, das Du zur Übertragung der Daten verwendest, aber auch da gibts geeignete Lösungen für.
Und was soll man nun helfen? Den Code proggen kann Dir wohl kaum jemand, das darfst Du schon selber machen :)
Jau, 485 bietet sich da an z.B.
mhmm thema Helfen dachte ich ihr hättet nen Besseren weg? Und wie ist es wenn ich das signal durchschleife? TX Mega1 zu RX Mega2? Ich mache mal ne zeichnung fertig (nachher)
So hier mal ne Zeichung wie ich das meine! Die µC sind drei 162er
das RAM hat mit dem GLCd auch nichts weiter zu tun, es sei denn Du willst den ganzen Frameinhalt im RAM halten, was käse ist.
wie meinst du dass? Wo soll ich denn dann die ganzen menüs speichern? Und vorllem darauf zugreifen?
Menüs erzeugt man dynamisch, per Funktion und schreibt die dann
einfach ins GLCD. Das hat dann das RAM wo der Anzeigeinhalt dann drinnen
steht.
Sprich Du hast Bitmuster für Buchstaben und Zahlen, die liegen im Flash,
dann schreibst Du nur noch das Bitmuster Deines Zeichens ins RAM des
GLCD.
Bei Kurvendarstellung gehts anders, da speicherst Du dann einfach die
Koordinaten ins RAM des ATMega, aber da reichen dann auch bei 320 * 240
320 Bytes aus.
Wenns ne graphische Darstellung von Buttons werden soll schreibst Du Dir
Funktionen, so Deine Programmiersprache die nicht schon dabei hat,
um Linien und Rechtecke zu zeichnen ... keine große Sache.
ah ok! Zurück zum Topic: Geht dass denn was ich vor habe?
TX-RX-Dirrektverbindung geht, warum auch nicht, kommt allerdings drauf an
welche Strecken mit welcher Baudrate in welcher Umgebung realisiert
werden soll.
Hohe Baudrate auf weite Strecke (>20m) ungeschirmte Kabel und Kräftige Störeinstreuungen (schwere Maschinen ... Föhn) geht schief.
Aber auch dafür gibts Lösungen, RS485, CAN ...
mhmm thema Helfen dachte ich ihr hättet nen Besseren weg? Und wie ist es wenn ich das signal durchschleife? TX Mega1 zu RX Mega2? Ich mache mal ne zeichnung fertig (nachher)
Ich würde das mit EINEM AVR "erschlagen", 2 Motore und ein paar RS232 Software Schnittstellen lassen den nicht schlapp machen.
Der Tipp mit den SN75176 RS485 Treiber ist gut, die habe ich für lange Leitungen auch immer verwendet.
Dadurch das jeder Teilnehmer seine eigene RS232 Schnittstelle hat, erledigt auch gleich das Problem die einzelnen Teilnehmer zu unterscheiden. Man weiß ja an welchem Port die hängen. :-) Wenn es Timing Probleme gibt nimmt man halt einen AVR mit möglichst hoher Quarz Frequenz.
Gruß Richard
mhmm verstehe ich dass richtig, dass bei rs485 mit Adressen Gearbeitet wird? Also kann ich nen ansi string an die Adresse 2 oder so senden, ohne dass ein anderer Kontroller "belästigt" wird? Und kann ich den Wandler auch nach einem XBEE einschleifen? Was muss ich denn da Beachten bei RS485?
mhmm verstehe ich dass richtig, dass bei rs485 mit Adressen Gearbeitet wird? Also kann ich nen ansi string an die Adresse 2 oder so senden, ohne dass ein anderer Kontroller "belästigt" wird? Und kann ich den Wandler auch nach einem XBEE einschleifen? Was muss ich denn da Beachten bei RS485?
Das verstehst Du leider falsch, RS485 bezieht sich erst einmal nur auf die Hartware vom BUS.
Das Signal wird auf 2 Leitungen Spiegelverkehrt gesendet und nur die Differenz der Signale Ausgewertet. Da Elektrische Störungen sich auf beiden Leitungen gleich auswirken (Gleichtakt) werden diese nicht verarbeitet.
Adressieren könnte man z.B. mit I²C damit lassen sich aber keine Entfernungen überbrücken. :-( Der CAN BUS wäre/ist für so etwas ideal, aber das Protokoll ist nicht ohne. Es gibt zwar CAN BUS Controller, aber selbst damit scheint es recht schwierig zu seil wie viele Hilferufe vermuten lassen. Nicht umsonst gibt es extra AVR's mit integriertem CAN Controller.
Deshalb hatte ich auch vorgeschlagen einfach in (EINEM) AVR mehrere RS232 Verbindungen parallel laufen zu lassen. Das geht dann auch mittels RS485 Treiber, allerdings braucht man dann 5 Adern B.z.w. 4 Datenleitungen und GND.
Die RS485 Treiber können für Lesen Schreiben umgeschaltet werden, dann reichen auch 2 Datenleitungen. Dann wird das Protokoll aber aufwändiger.
Ähnliches gild für Can BUS Treiber, das sind einfach Open Kollektor die mittels pull up "hochgehangen" werden. Da hier jeder jederzeit
"Dazwischequatchen" kann muß jeder Sender seine Sendung Byte für Byte selber überwachen und den Sendebetrieb bei Datenkollision einstellen und später noch einmal versuchen.
Der CAN BUS ist L aktiv wird ein H gesendet und ein anderer Sender überschreibt das H mit L stellt der H-Sender die Übertragung ein...
Gruß Richard
nunja, die AVR unterstützen RS485 schon ordentlich, klar ists n Weg von der
Theorie zur Praxis, aber das TXC undRXC-Interrupt sind schonmal sehr
praktisch, der 9-Bit-Mode ist ideal für Empfängeradressen auf dem
Bus, sprich für Protokollstarts.
Durch die 9-Bit-Geschichte kann man auch direkt adressieren, die
Auswertung in der Software ist easy ...
Bit 9 gesetzt = Adresse
prüfen ob = Slaveadresse
ja, geht Slave was an, nein, Slave ignoriert bis nächstes 9-Bit
Deshalb hatte ich auch vorgeschlagen einfach in (EINEM) AVR mehrere RS232 Verbindungen parallel laufen zu lassen.
Tag, wie kann ich denn z.B. auf nem Mega 32 mehrere Uarts Laufen lassen?
Deshalb hatte ich auch vorgeschlagen einfach in (EINEM) AVR mehrere RS232 Verbindungen parallel laufen zu lassen.
Tag, wie kann ich denn z.B. auf nem Mega 32 mehrere Uarts Laufen lassen?
Mybaud = 19200
Do
'first get some data
Serin S , 0 , D , 0 , Mybaud , 0 , 8 , 1
'now send it
Serout S , 0 , D , 1 , Mybaud , 0 , 8 , 1
' ^ 1 stop bit
' ^---- 8 data bits
' ^------ even parity (0=N, 1 = E, 2=O)
' ^-------------- baud rate
' ^-------------------- pin number
' ^----------------------- port so PORTA.0 and PORTA.1 are used
' ^--------------------------- for strings pass 0
' ^-------------------------------- variable
Oder....
'open channel for output
Open "comd.1:19200,8,n,1" For Output As #1
Print #1 , "serial output"
Open "comd.0:19200,8,n,1" For Input As #2
'since there is no relation between the input and output pin
'there is NO ECHO while keys are typed
Print #1 , "Number"
'get a number
Input #2 , B
'print the number
Print #1 , B
Gruß Richard
Das kannte ich ja noch garnet :D
Sagt mal wie kann ich denn damit ein Interrupt auslösen beim Empfangen?
UNd kann ich höhere Baud Raten fahren? z.B. 250.000baud?
Dann nehm ich also nen Mega32 häng da nen 16MhZ ran und benutze den mit z.B. 7 Uarts als Master und Verteiler nur wie bekomme ich es hin, dass ich empfangen und senden kann? Also der Verteiler muss ja mehrere gleichzeitig abarbeiten?
Software UART geht üblicherweise nicht mit hohen Bitraten.
Wenn, dann gleich nen richtig schweren Controller, wie dem ATMEGA 640 bzw. 1280. Der hat dann gleich 4 Hardware USART's an Bord.
Leider auch ein TQFP 100 Gehäuse.
Ich hab mir dazu Adapterplatinen gebastelt, damit man damit schön testen kann.
Diese Adapterplatinen gibts auch fertig, sind aber nicht ganz billig.
Das kannte ich ja noch garnet :D
Sagt mal wie kann ich denn damit ein Interrupt auslösen beim Empfangen?
UNd kann ich höhere Baud Raten fahren? z.B. 250.000baud?
Dann nehm ich also nen Mega32 häng da nen 16MhZ ran und benutze den mit z.B. 7 Uarts als Master und Verteiler nur wie bekomme ich es hin, dass ich empfangen und senden kann? Also der Verteiler muss ja mehrere gleichzeitig abarbeiten?
Ob Software Uart IRQ fähig sind? Da sollte die Bascom Hilfe etwas wissen. Oder man nimmt einen AVR bei dem alle Pins IRQ auslösen können.
Wie schnell gesendet werden kann? Aber 56 kBaud habe ich (glaube ich) schon einmal am laufen gehabt. "gleichzeitig" geht bei µC's sowieso NIX, die arbeiten immer alles sequentiell ab. Außerdem wenn Du mehrere Geräte über (irgendeinen) BUS betreibst müssen alle (außer beim CAN) auch darauf warten das sie bedient werden.
Gruß Richard
also ist die soft uart lösung quatsch! Gibt es noch ne bessere Lösung?
also ist die soft uart lösung quatsch! Gibt es noch ne bessere Lösung?
Natürlich, JA.
Du posteset was Du genau erreichen willst. Ob sich das dann realisieren lässt hängt von Deinem Geldbeutel und von Gott der bekanntlich nicht würfelt ab......
Gruß Richard
ok ich lege mal meine Karten auf den Tisch: Ich habe vor eine Antennen Tracking anlage zu Bauen. Ich bekomme per rs232 von einem GPS empfänger Daten wo mit ich den Kurs zu dem Flugmodell (ebenfalls ein rs232 gps empfänger) berechne. Dann stelle ich mit schrittmotoren die Antenne in Richtung modell (XY). Das übernimmt ein Controller. Die GPS Daten kommen Per xbee zur bodenstation. Dann gibt es eine Bedineinheit wo menüs gesteuert werden und wo alle Daten angezeigt werden. Außerdem kann ich dort etliche einstellungen an der Antenne (Main Controller) Vornehmen. Das Bedinpanel soll auch per pc oder handy (bluetoth) gesteuert werden.
Ich hoffe mein Problem ist nun Verständlicher: 2GPS Empfänger, 1Main Controller, 1 Bedineinheit und ausgabe module
Siehe unbenannt2:
Mega1 als I2C Master, Mega2 als slave.
Alle paar ms Mega1 den Mega2 pollen lassen, dabei Daten zur Bedieneinheit schicken und Zustand der Bedieneinheit abfragen.
Zum Abfragen der Bedieneinheit alternativ eine Leitung vom Mega2 zu einem der Ints am Mega1 legen und die bei Bedarf low/high ziehen um Zustandsänderung zu signalisieren und dann Zustand der Bedieneinheit abfragen.
Xbee(seriell?)/Gps je eine USART, im Zweifelsfall nen AtMega644p (2x USART) nehmen und die Idee mit den Soft UARTs besser gleich vergessen, lieber die Ints der USARTs nutzen. Die TWIs ebenfalls per Int nutzen. Das Ganze dann schön um eine zentrale Schleife mit globalen Variablen als Signale verpacken.
Dabei wirst du aber nicht daran vorbeikommen dich mit Timern, den USARTs, der TWI und einigen anderen Dingen, am Besten ohne fertige Libs, auseinanderzusetzen. Aber der Weg ist ein Teil des Ziels, oder? :)
Nur so eine Idee...
also ist die soft uart lösung quatsch! Gibt es noch ne bessere Lösung?
GPS Empfänger sind bekanntlich nicht besonders schnell und Aktualisieren ihre Werte 4....10 x/s
mit üblich 2400 Baud. Da langweilt sich jede Soft Schnittstelle gewaltig......Wozu wird dabei 240.000
Baud gebraucht???
Außerdem, ist es absolut sinnfrei ein DGPS selber bauen zu wollen. Dazu müssen zur gleichen Zeit die Daten von identischen Satelliten verglichen werden. Das bedeutet nicht nur die Empfänger müssen synchron laufen, sie müssen auch synchron den gleichen Satelliten empfangen.....wenn das SOOOO einfach wäre würden solche Systeme nicht im 5 Stelligen Preisbereich liegen.
Viel Spass beim Basteln. :-)
Gruß Richard
...Dazu müssen zur gleichen Zeit die Daten von identischen Satelliten verglichen werden. Das bedeutet nicht nur die Empfänger müssen synchron laufen, sie müssen auch synchron den gleichen Satelliten empfangen...
Hallo Zusammen,
@Richard: Ich muss ja nur einmalig eine GPS Position für die Ground station bekommen und dann nur noch von dem Modell!
Mega1 als I2C Master, Mega2 als slave.
Alle paar ms Mega1 den Mega2 pollen lassen, dabei Daten zur Bedieneinheit schicken und Zustand der Bedieneinheit abfragen.
Zum Abfragen der Bedieneinheit alternativ eine Leitung vom Mega2 zu einem der Ints am Mega1 legen und die bei Bedarf low/high ziehen um Zustandsänderung zu signalisieren und dann Zustand der Bedieneinheit abfragen.
Xbee(seriell?)/Gps je eine USART, im Zweifelsfall nen AtMega644p (2x USART) nehmen und die Idee mit den Soft UARTs besser gleich vergessen, lieber die Ints der USARTs nutzen. Die TWIs ebenfalls per Int nutzen. Das Ganze dann schön um eine zentrale Schleife mit globalen Variablen als Signale verpacken.
Also benutze ich den Rechen mega als main mega. Dann frage ich in der Main erst das GPS ab, rechne den winkel aus und stelle die Motoren. Dann frage ich noch die Bedineinheit ab und sende daten hin. Das Bedeutet Mega1 zu Mega2 per i2c und dann die GPS Daten per rs232 zum main Mega. Kannn ich denn über den i2c bus Strings senden? Die GPS Koordinaten usw? Und wie kann ich den Steuer Mega als i2c Slave laufen lassen?
Also benutze ich den Rechen mega als main mega. Dann frage ich in der Main erst das GPS ab, rechne den winkel aus und stelle die Motoren. Dann frage ich noch die Bedineinheit ab und sende daten hin. Das Bedeutet Mega1 zu Mega2 per i2c und dann die GPS Daten per rs232 zum main Mega. Kannn ich denn über den i2c bus Strings senden? Die GPS Koordinaten usw? Und wie kann ich den Steuer Mega als i2c Slave laufen lassen?
Jain.
die meisten GPS Empfänger geben 1x pro Sekunde Positionsdaten aus (oder können so konfiguriert werden). Die USART kann nun einen Int auslösen, sobald ein byte empfangen wurde. In der ISR wird dann der String byte für byte zusammengebaut, bei CR/LF dann die CRC überprüfen und eine globale Variable auf 'neue GPS Nachricht empfangen' setzen. in der Main Schleife dann halt überprüfen, ob eine neue GPS Nachricht da ist und ggfs. die Position extrahieren. Da der Mega644p 2 USARTS hat, kann man so im Hintergrund beide GPS Positionen zusammensammeln. Wenn neue Position eingegangen ist die Servos stellen.
Per Timerinterupt alle 250ms den Mega2 bearbeiten. Ein sei() am Anfang dieser ISR bewirkt, daß auch während dieser ISR Bytes von den GPS emfangen werden. Auch hier wieder eine globale Variable um Änderungen in der Bedieneinheit/Mega2 zu signalisieren.
Per I2C kannst du senden/lesen was du willst.
Da die Soft-Uart mit Warteschleifen arbeiten, kommst du damit bei 2x GPS nicht weit, da der komplette uC blokiert ist, solange du an einer Schnittstelle was empfängst.
Versuch meinen ersten Absatz zu verstehen und die Vorteile, die der asynchrone Empfang damit bringt. Kann sowas schwer erklären... in der Mainschleife halt wirklich nur Nachrichten der Subysteme bearbeiten, sonst kommt das mit dem Timing nicht hin und du verlierst Nachrichten vom GPS.
Wie gesagt, siehe unbenannt2, nur 2 Megas. Mega1 als Hauptrechner für 2x GPS, 2x Servo. Mega2 als Schnittstelle zur Bedieneinheit, PC. Vom Mega2 immer einen festen Block lesen und einen anderen festen Block in den Mega2 schreiben, jeweils mit allen relevanten Daten (GPS, Tasten...).
Alternativ könnte Mega1 auch nur dann was in den Mega2 schreiben, wenn wirklich was neues vorliegt. Dann könnte man den Mega2 auch ein Signal an den Mega1 schicken lassen (eine Leitung auf low/high), wenn sich bei ihm was neues ergeben hat...
Die ganze Geschichte bedingt aber wirklich eine intensive Auseinandersetzung mit den Möglichkeiten des AVR. 8-[
Was für GPS-Empfänger hast du eigentlich?
Also wenn ich dich richtig Verstehe, meinst du dass so:
(Mega 1 = main, Mega2 = bedinteil, Gps = Gps --> Xbee)
- Mega1 fängt an
- Mega1 fragt GPS koordinaten von GPS ab
- Mega1 rechnet Winkel aus
- Mega1 stellt Schrittmotoren
- Mega1 fragt Mega2 auf neuigkeiten ab (wenn port auf heigh)
- Mega1 sagt Mega2 neue Daten (Winkel kurs) (wenn neu)
Alles von Vorne
Und dass in der Normalen do loop end schleife?
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.