Bei so vielen Aufgaben wird die Aufteilung auf 2-4 µCs sinnvoll sein. Bei einem großen µC hat man leicht das Problem, dass irgendwelche Hardwarefunktionen doch den gleichen Pin benötigen.
Außerdem wird es bei einem µC schon schwierig das ganze so zu programmieren, dass die Reaktionszeit auf alle Interrupts kurz genug bleibt. Die Servokontrolle ist ja schon etwas Zeitkritisch.
Wenn man die Komumnikation einmal fertig hat, ist I2C als Bus nicht so schwer und auch gut erweiterbar.
Bei der Ansteutung von LEDs und tastern könnt man noch einigers an Pins sparen wenn es sein muß.
Nachdem sich jetzt so viele für eine Lösung mit mehreren µC ausgesprochen würde ich gerne weiter auf diese Lösung eingehen:
Damit spricht Besserwessi auch gleich an wo das Problem von meiner Seite aus liegt. Wie bekomm ich eine vernünftige, bidirektionale Kommunikation mehrer Controller hin?Wenn man die Komumnikation einmal fertig hat, ist I2C als Bus nicht so schwer und auch gut erweiterbar.
Jemand Anleitungen oder Ideen?
in welcher sprache möchtest du das ganze denn realisieren?
Hallo,
da gibt es viele Möglichkeiten, je nach dem wie kreativ du sein willst
I2C ist multimasterfähig, d.h. dass jeder Teilnehmer selbst aktiv eine Übertragung starten kann. Der Nachteil eines solchen Ansatzes ist, dass evtl. timingkritische Aufgaben darauf warten müssen, bis der Bus frei ist.
Eine andere Möglichkeit wäre z. Bsp. ein Ringbus via UART oder SPI, was gewisse Timinggarantien zulassen würde.
Oder du wählst eine zentralisierte Architektur, verdrahtest alles via SPI sternförmig und hast einen Master der die einzelnen Teilenehmer anpollt/befehligt.
Es gibt auch die Möglichkeit, all das zu kombinieren und für mehrere Bussysteme parallel zu verwenden, etwa einmal I2C für weniger zeitkritische Aufgaben oder für allgemeine Steuerbefehle, und dann SPI oder evtl. ein 4/8-Bit-Bus für Übertragungen hoher Priorität/größerer Datenmengen.
Je nach Realisierung wäre es etwa auch möglich zu sagen, dass dieser "breite" Bus kontinuierlich Steuerbefehle für die ganze Mechanik in einem definierten Paketformat transferiert, die ein Master-Controller generiert und dann von den einzelnen Slaves umgesetzt werden. Der Master könnte dann selbst kompliziertere Berechnungen anstellen ohne noch auf das IO-Timing zu achten.
Man könnte dieses Konzept dann sogar noch weiter treiben, indem man dem Master selbst die zu berechnenden Zielkoordinaten etc. via I2C zusendet, die ein zentraler Controller etwa über Funk bekommen hat. Dieser zentrale Controller könnte etwa verschiedene Sensoren auswerten (oder die Auswertungsergebnisse via I2C abholen ...), auf die Batteriespannung achten, mit einer Echtzeituhr reden, den Displaycontroller instruieren etc.
mfG
Markus
Eine bidirektionals Kommunikation ist schon etwas aufwendiger. Man kann die Aufgabe aber oft so aufteilen, dass man im wesentlichen mit unidirektionaler Kommunaikation auskommt, und auch mit eher niedriger Datenrate.
Ein Controller der die Servos und DC motoren steuert braicht kaum was zurückmelden. Die paar weniger Daten die mal in andere Richtung gehen, kann man dann auch per Pollng abhohlen, also ohne Multimaster.
@dremler, am liebsten in C oder Assembler wobei ich glaub ich gerade fitter in C bin.
@Besserwessi, die Motoren müssen auf jedenfall ihre Geschwindigkeit zurück liefern und die möglichst kontinuierlich. Zudem den Ladezustand der Batterie, falls diese kritisch wird.
Der Servocontroller muss in der Tat gar nichts zurück geben sondern einfach machen. Anders sieht es da schon wieder bei den Sensoren aus. Die müssten Quasi in direkter Verbindung mit dem Master bleiben.
Soweit so gut in der Theorie, die ist in der Tat nicht so kompliziert, aber wie würde man sowas in Code umsetzen? Da hakt es dann meistens bei mir.
Für arr-gcc findest du nen Code von mir für die I2C-Slaves im Wiki. Damit werden die Slaves ähnlich wie ein I2C-EEPROM angesteuert. Also hat man quasi ein dualport-RAM, auf das beide Controller zugreifen können. Für den Master findet man haufenweise libs, ich bevorzuge die von P. Fleury.
EDIT: ich seh gerade, dass im Wiki noch eine etwas ältere Version steht. Hier der neuste Stand:
http://home.edvsz.fh-osnabrueck.de/u...r/twislave.zip
Hallo!
@ HannoHupmann
Ich habe damit zwar keine Erfahrung, aber denke, dass es für Erstellung eines gesamtes Programms kein Unterschied gibt, mit wieviel µC's es realisiert wird.
Ich stelle mir das einfach so vor, das der Haupt µC ein Hauptprogramm ausführen wird und fast alle Unterprogramme werden in den untergeordneten µC's untergebracht und vom Haupt µC in festgelegter Reihenfolge per ein Bus (z.B. I2C) aufgerufen.
So wie ich das sehe, irgendwann wird es dazu kommen, dass mit einem µC, nicht nur wegen zu wenig I/O Ports, nicht mehr gehen wird immer kompliziertere Roboter zu steuern.
Ich habe in der Elektronik mit Röhren angefangen und heute programmiere ich µC's. Ich kann mir nicht vorstellen, dass ich heute eine Steurung eines Botes mit Röhren realisieren könnte. Das Leben ist leider brutal und man muss viel Sachen zum ersten mal machen...
MfG
@PICTure ich weis ich weis und ich hab mich auch schon in viele neue Gebiete eingearbeitet. Aber aus diesen Erfahrungen hab ich gelernt, dass es sinnvoller ist sich erst mal umzusehen ob es nicht schon jemand gemacht hat. Ich hab nicht den Anspruch das Rad für mich neu zu erfinden.
Daher Zielt meine Frage jetzt auch auf Codebeispiele ab, den die Theorie ist soweit klar, jetzt gehts an die praktische Umsetzung. Wenn ich weis wie das zu Lösen ist mach ich mich an den Entwurf der Schaltungen
Hallo!
@ HannoHupmann
Das mit praktisch ausprobierten Mustern stimmt, aber leider als Entwickler muss man oft etwas "erfinden" um sein Projekt nach eigener Vorstellung zu realisieren.
Ich wünsche dir wirklich viel Erfolg in Realisierung deinen Plänen und hoffe, dass du etwas brauchbares und für dich adaptierbares findest.
MfG
Berechtigungen
Zitieren
Lesezeichen