Hallo Community, ich möchte mich erneut daran versuchen, einen relativ umfangreichen, fahrbaren Roboter zu bauen, der verschiedene Aufgaben erfüllen kann. Bereits in der Vergangenheit habe ich ein paar Roboter auf Grundlage verschiedener Microcontroller und Einplatinencomputer (Arduino, Raspberry,...) gebaut. Meinen nächsten Roboter möchte ich jedoch modularer gestalten. Meine Idee hierbei wäre es, an mehrere AtMegas/Attinys verschiedene Sensoren zu hängen (also z.B. ein uC für Wettersensoren, ein weiterer für Gyroskope/GPS/Radar/Lagesensoren). Softwaretechnisch würde dann die Hauptsteuerplatine - in diesem Fall ein Raspberry Pi 3 - immer die einzelnen uCs abfragen und die entsprechenden Werte erhalten. Dabei hatte ich im ersten Moment gedacht, sämtliche Kommunikationen über den I2C-Bus laufen zu lassen, da eine USB-Schnittstelle nicht in Frage kommt. Gibt es evtl schönere Lösungen? Ich bin momentan wieder vom I2C abgeneigt, da auch manche Sensoren über I2C mit den uCs kommunizieren würden und diese somit sowohl Master, als auch Slaves sein müssten... Viele Grüße und danke für Tipps F.S.
Falko S. schrieb: > Ich bin momentan wieder vom I2C > abgeneigt, da auch manche Sensoren über I2C mit den uCs kommunizieren > würden und diese somit sowohl Master, als auch Slaves sein müssten... Multimaster ist bei I²C vorgesehen.
Hallo, vielen Dank für die Info. Dann werde ich das wohl doch über I2C machen. Wenn jemand bereits Erfahrung oder Softwarelösungen für Arduino hat, sind diese hier natürlich gerne willkommen, ansonsten werde ich mich mal an das Projekt wagen. Viele Grüße F.S.
Ich würde dir ja vorschlagen einen richtigen Feldbus zu nutzen, mit Atmega/Atiny ohne integrierten Controller ist das eher nicht optimal. Versuche die einzelen Controller so dumm wie möglich zu machen, dann musst du bei änderungen und dem parametrieren nur an den RaspPi
Warum willst du die Mikrocontroller überhaupt Master spielen lassen? Wenn du die alle nur als Slave benutzt und alle I2C Sensoren selbst mit dem Raspberry abfragst machst du es dir deutlich einfacher. Das I2C am Ende trotzdem nicht funktioniert liegt dann nur in der fehlerhaften Implementierung des clock stretching im Raspberry weil Broadcom dafür zu doof war...
IPoAC? Jetzt mal im Ernst, es sollte doch irgendwie einleuchten das der OP nicht noch beliebig viel Aufwand treiben will. Er will OFFENSICHTLICH die AVRs (nein nicht nur Exoten mit CAN) an den Raspberry flanschen um Sensoren und Aktoren damit zu nutzen und nicht vorher jeden Controller mit einem entsprechenden Tranceiver ausstatten...
Hallo, Ich werde selbstverständlich NICHT den Can-bus verwenden. Die Controller sollen über eine Schnittstelle miteinander kommunizieren, die möglichst einfach zu händeln ist. Das Protokoll/Datenformat für die Messwerte werde ich selbst implementieren. Wahrscheinlich werde ich schlussendlich auch nicht einen Atmel, sondern einen 32bit MC von Nordic Semiconductor verwenden. Die einzige Frage ist, wie ich eine hardwareseitige Lösung zur simplen Kommunikation mehrerer Geräte im Master-Slave-prinzip realisieren kann. Grüße F.S.
I2C mit nem vernünftigen Master, also nicht den eingebauten I2C vom Raspberry nehmen.
Ich bleib dabei, RS485. Die serielle Schnittstelle ist zuverlaessig, robust, leicht anzusprechen. Kann sich nicht verhaeddern wie I2C. Clock-Stretch ist kein Thema. Ist auch ueber gewisse Strecken stabil (k.A. wie eng die Platinen beieinander sind). Busteilnehmer lassen sich leicht durch einen PC simulieren/ersetzen, sowohl Raspi als auch Mikrocontroller.
F. S. schrieb: > Was genau meinst du damit? Prinzipiell ist I2C genau das was du für deine Aufgabe brauchst nur eben im Raspberry fehlerhaft implementiert: http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html Also brauchst du entweder einen Controller der es richtig macht oder etwas zusätzliche Hardware am Raspberry oder du musst komplett sicherstellen das kein clock stretching verwendet wird.
Hmmm, ich mach die Verbindung zur Controllerebene über Bluetooth. So ziemlich jedes Gerät (Tablet, Smartphone, Notebook, RPI,...) verfügt mittlerweile über BT. Da kann man sich für nen Testlauf auch mal mit dem Notebook binden oder das alte Tablet als Brain missbrauchen.
Ein ähnliches Projekt hatte ich auch mal am Laufen. Da hatte ich die Atmegas mit dem Raspi durch SPI verbunden, geht ganz gut, wenn man nicht gerade mehr als acht Untermodule verwenden will. Es passt auch ganz gut, dass SPI schneller als I2C sein kann und weniger Overhead am Bus braucht
Ja, habs auch mit I2C, SPI und RS232 getestet. Letztlich hab ich mich gegen I2C entschieden weil der Raspberry das nicht vernünftig hin bekam und gegen SPI weil die AVRs lausige Slaves sind. Also einen dickeren AVR per UART an den Raspberry und alles Andere per I2C an den geflanscht. Letztlich waren die einzigen Gründe für den Raspberry die PiCam und das WLAN Modul...
I2C halte ich nur für sinnvoll um Sensormodule direkt abzufragen. Um diverse Mikrocontroller mit etwas Eigenintelligenz und Datenverarbeitung abzufragen ist RS485 sinnvoller. Es ist auch einfacher bei einem µC Sensoren mit der eingebauten I2C Schnittstelle abzufragen und für die Kommunikation zur übergeordneten Steuerung (Raspi) eine andere Schnittstelle zu verwenden.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.