-
        

Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 25

Thema: Kommunikation zwischen mehreren µC

  1. #1
    Erfahrener Benutzer Roboter-Spezialist Avatar von MiniMax
    Registriert seit
    26.07.2007
    Ort
    Bremen
    Beiträge
    241

    Kommunikation zwischen mehreren µC

    Anzeige

    Hallo Zusammen,
    ich habe mal (wieder ) 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

    So nun aber Genug geschrieben -- ich hoffe ihr könnt mir Folgen [-o<

    Also bitte Helft mir
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken unbenannt_142.jpg   unbenannt2_150.jpg  
    Gruß
    MiniMax

  2. #2
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    1.892
    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.

  3. #3
    Erfahrener Benutzer Robotik Einstein Avatar von Vitis
    Registriert seit
    06.01.2005
    Ort
    Südpfalz
    Alter
    43
    Beiträge
    2.240
    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.
    Vor den Erfolg haben die Götter den Schweiß gesetzt

  4. #4
    Erfahrener Benutzer Roboter-Spezialist Avatar von MiniMax
    Registriert seit
    26.07.2007
    Ort
    Bremen
    Beiträge
    241
    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)
    Gruß
    MiniMax

  5. #5
    Erfahrener Benutzer Roboter-Spezialist Avatar von MiniMax
    Registriert seit
    26.07.2007
    Ort
    Bremen
    Beiträge
    241
    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?
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken unbenannt3_170.jpg  
    Gruß
    MiniMax

  6. #6
    Erfahrener Benutzer Robotik Einstein Avatar von Vitis
    Registriert seit
    06.01.2005
    Ort
    Südpfalz
    Alter
    43
    Beiträge
    2.240
    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.
    Vor den Erfolg haben die Götter den Schweiß gesetzt

  7. #7
    Erfahrener Benutzer Roboter-Spezialist Avatar von MiniMax
    Registriert seit
    26.07.2007
    Ort
    Bremen
    Beiträge
    241
    ah ok! Zurück zum Topic: Geht dass denn was ich vor habe?
    Gruß
    MiniMax

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von Vitis
    Registriert seit
    06.01.2005
    Ort
    Südpfalz
    Alter
    43
    Beiträge
    2.240
    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 ...
    Vor den Erfolg haben die Götter den Schweiß gesetzt

  9. #9
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.01.2006
    Beiträge
    4.556
    Zitat Zitat von MiniMax
    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

  10. #10
    Erfahrener Benutzer Roboter-Spezialist Avatar von MiniMax
    Registriert seit
    26.07.2007
    Ort
    Bremen
    Beiträge
    241
    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?
    Gruß
    MiniMax

Seite 1 von 3 123 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •