Roboterbau - Kombination von Raspberry und Mikrocontrollern

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...

RS485?

CAN Bus ?

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.

Was genau meinst du damit?

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.

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...