Hi, ich habe vor in einem Roboterprojekt mehrere Mikroprozessoren mit einem 8-bit Bus zu verbinden. Für Adress- und Datenbus gehen jeweils 8 Leitungen drauf. Nun meine Frage: Kennt jemand ein IC, das Adressdecodierung mit Enable Leitung (und evt. noch Bustreiber) in einem Gehäuse vereinigt? Mein Problem ist, dass ich zu diesem Zweck momentan einen 8-Bit Vergleicher, ein AND-Gate und einen Bustreiber brauche. Das ist schon sehr aufwändig und ich hätte es gerne etwas einfacher. Der I²C-Bus kommt für mich nicht in Frage, weil er etwas langsam ist. Danke im Voraus Tristan
Hallo, ich würde in dem Fall der Flexibilität wegen auf Programmierbare Logik (z.B. Xilinx XC9536XL oder XC9572XL) setzen. Da kannst Du nachher noch beinahe beliebig verändern (nur durch die Chipgröße beschränkt). Die Software gibt's von Xilinx, die Chips vom Reichelt (kostet sehr wenig) und einen Adressdekoder kann man in VHDL nach einigen Stunden (wenn Du bei Null anfängst) hinbekommen. Das Layout wird auch einfacher und vor allem: Mit dem IC-Grab hast Du ein riesiges Problem, wenn Du eine Adresse verändern willst. MfG - C. Lechner
Nur so aus Interesse (und weil I2C immerhin bis 3.4Mbit/s geht): Welche Daten werden denn übertragen?
Die Datenrate von I²C würde vermutlich noch reichen, allerdings haben die Controller die da dran hängen ohnehin schon genug zu tun und ich weiß nicht, ob die Latenzzeiten dann auffallen. Ich habe I²C bis jetzt nur an dem Bedienteil im Einsatz, wo ein paar LEDs oder ein Summer anzusteuern sind. Bluetooth und GPS ist fest vorgesehen, eine einfache Motorsteuerung und dann noch diverse Extras (daher auch das Bussystem, damit das Ganze gut erweiterbar ist). Das Projekt steht gerade noch am Anfang, aber ich weiß wirklich nicht, ob I²C in diesem Fall die beste Wahl ist (v.a. sind die 3.4MBit/s doch das absolute Optimum und ich behaupte bei relativ vielen Devices am Bus dürfte das etwas einbrechen). Oder ist ein 8-bit Bus hier reichlich überdimensioniert? Ich habe sowas noch nie vorher gebaut, also lasse ich mich gerne belehren :)
Du wirst Dir bei Deinem 8-Bit-Bus Gedanken machen müssen um die Verwaltung - welcher Controller darf den Bus wann belegen? Solche Verfahren sind gar nicht so trivial, und da hat die Verwendung eines etablierten Protokolles schon so ihre Vorzüge. Wie stellst Du Dir denn so Deinen Busbetrieb vor? Soll es einen Busmaster geben, der die anderen Busteilnehmer pollt oder soll es einen Multimaster-Betrieb geben (jeder darf wann er will)?
Ehe man irgendeinen Bus zusammenschustert, sollte man sich schon überlegen, mit welchen Datenraten man es zu tun hat. Auch sollte man die Aufgaben so aufteilen, daß sich möglichst wenig Datenaustausch ergibt. Bzw. man sollte sich erstmal sicher sein, daß überhaupt mehrere CPUs notwendig sind. CPUs sind auch nur Menschen. D.h. wenn 3 Personen ein Projekt bearbeiten sind sie nur etwa doppelt so schnell, wie einer, eine Person geht voll für die Kommunikation drauf. Ein 8Bit-Bus ist sehr ungünstig. Es gab früher mal 8051-er, die quasi wie ein SRAM als Slave angesprochen werden konnten. Ansonsten sind mir keine µCs bekannt, die sowas können. Und zu Fuß kostet das ne Menge Softwareaufwand. Ich würde den CAN-Bus empfehlen. Irgendeiner stellt einfach 8 Bytes in seinen Sendepuffer und irgendwann findet der andere die 8 Bytes in seinem Empfangspuffer. Dazwischen sind exakt 0 Byte Software nötig (macht ja alles die Hardware). Peter
Ich werde mir das mit dem 8-bit Bus nochmal überlegen. Geplant war eine Master-CPU, die andere pollt. Damit das nicht ständig Traffic erzeugt, können die gesprächswilligen per Interrupt die Master-CPU benachrichtigen. Auf jeden Fall mal vielen Dank für eure Antworten.
CAN ist natürlich die Königslösung. Vom parallelen Bus kann ich auch nur abraten. Du musst in einer gestörten Umgebung wie einem Roboter mit Motoren für Datensicherheit sorgen. Damit Du die Daten nicht zu oft senden musst, ist da einiges in Hardware nötig (Parity, Error Correction, etc.). Ein serieller Bus ist da genau richtig. Du könntest auch den UART nehmen oder SPI. Ich kann allerdings Peter nur zustimmen, CAN macht den geringsten Ärger und kostet auch kaum mehr.
Für solche Aufgaben ist der IEC-Bus (auch IEEE oder HP-IB) dereinst geschaffen worden. Der Aufwand ist nicht unerheblich, wenn das komplette Protokoll gefahren werden soll (wechselnde Master). Was hierbei aber gut ist, und wo Du sonst sicherlich Probleme bekommen wirst, ist die Ansteuerung des Busses über spezielle Treiber ICs: 75160-75162. Falls jemand glaubt, es würde klappen, einfach mehrere Teile parallel zu schalten, darf sich nicht wundern, wenn ab und zu die ganze Sache stehenbleibt.
Hm, ich denke ich werde mir den CAN Bus mal zu Gemüte führen. Der 8-bit Bus hätte eben den Vorteil, dass die MPUs relativ wenig Rechenleistung für die Transfers benötigen und dass man recht schnell übertragen kann. Durch die Interrupt-Geschichte würde zudem ein gleichzeitiges Auftreten von Schreib-/Leseoperationen vermieden. Zwecks Fehlerkorrektur habe ich mir zugegebenermaßen noch keine Gedanken gemacht - da würde ich mich einfach auf die Wahrscheinlichkeit für das Auftreten von Fehlern verlassen (ansonsten wäre - wie schon Joachim richtig bemängelt - der Aufwand immens hoch) IEC-Bus werde ich mir auch mal ansehen. Hab davon noch nicht mal gehört (CAN kenne ich wenigstns vom Hörensagen). Vielen Dank für eure Tipps!
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.