mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Verständnisproblem Bus


Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
ich würde gerne mehrere verschiedene eigene Geräte miteinander
kommunizieren lassen. Das ganze soll sehr modular gehalten sein. Ich
dachte an einen 8 Bit Geräteadressbus und einen 8 Bit Datenbus.
Allerdings habe ich jetzt ein Problem. Jedes Gerät soll mit jedem
kommunizieren können. Das bedeutet dass es durchaus passieren kann dass
zwei (oder mehr) Geräte gleichzeitig auf den Bus zugreifen wollen. Nun,
damit die Signale auf dem Bus eindeutig sind, und jedes Gerät
überprüfen können muss ob noch ein anderes Gerät auf dem Bus versucht
zu kommunizieren, muss jedes Gerät idealerweise seine Geräteadresse
bekanntgeben. Das könnte ja dann folgendermaßen aussehen dass im
Adressbus die Adresse des zu rufenden Gerätes steht und im Datenbus die
Adresse des Gerätes das versucht eine Verbindung aufzubauen.
Folgendes Szenario:
3 Geräte:
Nummer 1 hat Geräteadresse 00000001
Nummer 2 hat Geräteadresse 00000010
Nummer 3 hat Geräteadresse 00000011

Angenommen Gerät nummer 2 und nummer 3 versuchen gleichzeitig eine
verbindung zu gerät 1 aufzubauen. Dann merkt nur Gerät 2 dass jemand
anderes auf den Bus ebenfalls kommuniziert, weil die Adresse auf dem
Bus nicht seiner Adresse entspricht. Dies ist der günstigste Fall.
Gerät 2 macht den Bus frei und Gerät 3 plappert weiter, da er davon
nichts mitbekommen hat.
Angenommen Gerät 1 und Gerät 2 rufen Gerät 3, habe ich ein Problem.
Beide könnten feststellen, dass der Bus duch einen anderen Teilnehmer
gestört wird. Aber wer gibt jetzt auf und macht den Bus frei?

Was wäre die optimale Lösung um solche logischen Fehler zu vermeiden?
Ich grübel jetzt schon ewig über dieses Problem aber ich komme einfach
nicht zu einer sinnvollen Lösung.

Hat irgendjemand eine Idee?

Autor: A. Arndt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mnal ganz simpel gedacht, es gibt ein Busy-Leitung, wenn diese z.B. low
ist, dann kann keine Kommunikation stattfinden, also der Sendende prüft
BUSY ??, wenn Leitung frei, Leitung auf Low, Senden und dann Leitung
auf High.

Ansonsten sollte CAN gut funktionieren, aber ist in meinen Augen
ziemlich aufwendig...

Vielleicht konnte ich helfen...

Gruss
A. Arndt

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Busy-Leitung würde nicht wirklich helfen. Wenn beide Geräte
gleichzeitig veruschen auf den Bus zuzugreifen. Beide Geräte prüfen
gleichzeitig den Signalzustand von Busy und sehen er ist logisch=0.
Darauf hin denken beide der Bus ist frei und fangen an ihn zu
reservieren. Das hilft mir also leider nicht :(

CAN sagt mir leider nichts. Könntest du mir etwas auf doe Sprünge
helfen? :)

Sven

Autor: A. Arndt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

tippe mal Google CAN ein, es gibt dort eine Site nennt sich CAN at
Home, da ist alles gut beschrieben.

Nochmal zum 1. Beitrag, der Sender prüft vorerst, ist Busy frei, wenn
ja schaltet er busy auf "Besetzt", sendet Daten und gibt die Leitung
wieder frei. Möchte ein Sender gleichzeitig senden trifft er auf
"Besetzt" und sendet nicht...


Gruss
A. Arndt

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok erst googeln dann nachfragen :)
Habe die Spezifikationen zum CAN-Bus überflogen. Das Prinziep dort ist,
dass eine serielle Übertragung stattfindet. Das dominate Gerät (Signal
=1) setzt sich durch und das andere gibt auf. Dies würde jedoch nur bei
einem seriellen Bus funktionieren, da bei einem paralellen unter
Umständen Überschneidungen stattfinden, die beide Geräte betreffen. Wer
steigt dann aus?
Was die Sache mit Busy angeht:
Vielleicht stelle ich mich auch etwas dämlich an aber. Wenn ein Gerät
Busy auf 1 setzt, und er würde dann Busy abfragen würde er 1 bekommen.
Es weiss also nicht ob ein anderes Gerät zeitgleich Busy ebenfalls auf
1 gesetzt hat. Angenommen er schickt jetzt sein Datenpaket ab und
wartet auf eine Antwort des Empfängers und angenommen Zwei Geräte haben
gleichzeitig den Bus blockiert und die Zieladresse verfälscht,
antwortet unter Umständen kein Gerät weil es eine ungültige Adresse
war. Dann wissen bedie Sendegeräte "upps. is was schiefgelaufen. Ich
probiers nochmal" und das gleiche Spiel beginnt wieder von vorne. Oder
wo liegt mein Denkfehler?

Sven

Autor: A. Arndt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also:

Der Sender prüft die Busy-Leitung, die Leitung ist frei (angenommen
low), er zieht die die Leitung auf High und sendet seine Daten und
setzt die Leitung dann wieder auf low.

Und so macht es jeder Baustein und ist Busy nicht frei sendet auch
keiner und sonst heisst es, wer zuerst kommt, malt zuerst und dass zwei
uC gleichzeitig die Leitung auf High ziehen ist denke ich minimaler
Zufall...

Gruss
A. Arndt

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, aber was ich meine ist, das die Möglichkeit besteht dass die Geräte
wirklich gleichzeitig senden. Und wenn dass passiert dann verhängt sich
der Bus in einer Endlosschleife, weil dann beide Geräte synchron
miteinander laufen und den Bus permanent durch ungültige Datenpakete
blockieren. Auch wenn die Wahrscheinlichkeit gering ist, möchte ich das
nicht riskieren.

Sven

Autor: Carsten Sprung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>dass zwei uC gleichzeitig die Leitung auf High ziehen ist denke ich
minimaler Zufall...

Das will ich so nicht stehen lassen. Denn die Wahrscheinlichkeit ist
direkt Abhängig von der Anzahl der Busteilnehmer als auch von der
Häufigkeit der Buszugriffe.

Ausserdem ist zu beachten das sich ein elektrisches Signal auch erst in
einem Leiter ausbreiten muss. Soll heissen das Busysignal wird am
"anfang" des Busses erzeugt und ist zum Zeitpunkt des Prüfens eines
andren Knotens noch gar nicht am Ende des Busses angekommen.

Was man in diesem Falle braucht ist die Möglichkeit Kollisionen zu
erkennen und diese zu beheben.

Gruss Carsten

Autor: Peter Kasi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur mal als Denkanstoß,
leg doch als erstes die Adresse des Geräts das senden will auf den Bus
und überprüf, ob sie auch richtig auf dem Bus liegt, wenn ja hast du
den Bus für dich alleine und kannst dann deine Zieladresse auflegen.
Die einzelnen Adressen haben dann halt unterschiedliche Prioritäten,
aber kann ja durchaus erwünscht sein ;)
Gruß
Peter

Autor: Darko Sabljo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm... mal ne Idee in den Raum geschmissen ;-)
wie wärs mit passivem Treiben... d.H. man treibt niemals High Pegel,
sondern verwendet die Pull-Ups, schaltet also den Pin auf Input für
einen High Pegel, und für Low eben Output Low.
So kann wenigstens nix passieren wenns mit dem Bussy nicht klappt.

Ich hoffe nur ich mach grad keinen Denkfehler.

Autor: Andreas Jäger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es denn mit einem Token?

MfG
Andreas Jäger

Autor: Gralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Prinzip ist das ganze ja eine Art Ethernet 10Base2. Alle Geräte
sollen mit allen zu jeder beliebigen Zeit kommunizieren können. Dabei
denke ich, ist es egal, ob es ein serieller oder ein paralleler Bus
ist.
Beim Ethernet funktioniert das so, daß eines der Geräte eine
Serverfuktion übernimmt und somit das Netzwerk managed. Steigt das
Gerät aus dem System aus, übernimmt ein anderes die Serverfunktion.

Um die ganzen Abfragen zu vereinfachen, würde ich eine Art
Buscontroller erstellen. Dieser liegt mit am Bus. Wenn ein Gerät senden
will, meldet es das am Buscontroller an. Am Buscontroller entsteht
somit eine Warteschlange, die dann durchgetickert wird. Somit erhält
jeder Baustein die Option auf den Bus.

Autor: Markus Kaufmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist es wirklich nötig, daß die Busteilnehmer die Arbitrierung unter sich
ausmachen? Wie wäre es mit einer zentralen Verwaltung? Jeder
Busteilnehmer der senden will schickt eine eine Nachricht an die
Busverwaltung und bekommt irgendwann eine Bestätigung, daß er den Bus
jetzt benutzen darf.

Diese Anforderung kann man z.B. mit zwei Leitungen pro Gerät machen
(Request und Acknoledge) oder über ein spezielles Datenpaket, das zu
bestimmten Zeiten gesendet, z.B. das von Andreas erwähnte Token.

Markus

Autor: Markus Kaufmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gralf:
Was Du wohl meinst ist die Netbios Namensauflösung ohne Domain
Controller. Beim 10Base2 gibts keinen Master.

Markus

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

du solltest bischen mehr Stoff zu dem Can Bus lesen. Es kann
Kollisionen erkennen und Auswerten. Desweitern kann man die einzelnen
Geraete (in deinem Fall die anderen µC) Pioritaetsnummern verteilen.
Im Auto ist es Standard (VW&Audi), sogar fuer Sicherheitsrelevate
Bereiche. Aufwendig ist es nicht gerade, sondern eine Kostenfrage. Kauf
dir ein MCP2590 (Can Controller mit SPI) und ein tda1054(Can
Transmitter IC) zum steuern des MCP2590 z.B. ein AVR.


Mfg

Dirk

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter
Die Adresse des sendenden Gerätes wollte ich ja auch auf den Bus legen.
Aber wenn ich 2 sendewillige Geräte habe, eins mit der Adresse 00000010
und eins mit der Adresse 00000001 und wenn diese beiden Geräte synchron
ihre Adresse auf dem Bus schieben entsteht die logische Adresse
00000011. Beide Geräte überprüfen anschlißend ob ihre korrekte Adresse
auf dem Bus liegt. Beide Geräte stellen fest, dass sie falsch ist. Also
wissen jetzt beide Geräte, dass ihr Verbindungsaufbau von einem anderen
Teilnehmer gestört wurde. Und dann? Wer entscheidet wer jetzt den Bus
bekommt? Wenn sie es auf gut glück nochmal versuchen habe ich erst reht
ein tierisches Problem. Wenn beide Geräte vom selben Typ sind, läuft
die weitere Programmausführung absolut synchron, und beide stören sich
unendlich lang auf dem Bus. Die Folge ist dass nicht nur die 2 Geräte
ausfallen, sondern auch der BUS permanent belegt wird.

@Darko Sorry, den Sinn davon verstehe ich nicht ganz

@Andreas. An die Möglicheit ein Token-netz aufzubauen habe ich auch
schon gedacht. Allerdings bin ich davon nicht besonders begeistert. Zum
einen was die Geschwindigkeit und Reaktionszeit betrifft. Zum anderen
vom mechanischen Aufbau. Die Geräte hocken alle in einem 19 Zoll
Baugruppenträger. Für leere Schächte in der Mitte müsste ich Dummies
reinsetzten die den BUS brücken. Das erste und Letzte Gerät müsste ich
über ein externes Kabel zusätzlich brücken. Wie gesagt damit kann ich
mich einfach nicht anfreunden. Ich bin der festen Meinung dass es eine
einfache Lösung für mein Problem geben muss.

@Gralf
Der Unterschied zwischen einer seriellen und paralellen
Datenüberträgung ist, dass es bei einer paralellen mehr Bits verfälscht
werden können. Bei einer seriellen Übertragung gibt es nur eine
Datenleitung, wenn andere Geräte gleichzeitig ebenfalls auf dem Bus
senden setzt sich das Gerät mit der höhren Adresse durch, da es einfach
seine Adresse auf den Bus schiebt, und sobald das erste Gerät merkt,
hoppla da wurde mein Signal verfäscht steigt es aus. Es ist unmöglich
das beide sendenden Geräte dies Gleichzeitig merken, denn einer von
beiden setzt auf jeden Fall das richtige Signal. Bei einer paralellen
Datenübertragung können bis zu 8 Bits manipuliert werden. Das bedeutet
dass beide Geräte unter Umständen sofort merken dass ein anderer
Teilnehmer auf den Bus hockt, da es Überschneidungen gibt und nun, im
Gegensatz zum seriellen Bus können beide Ausgaben von beiden Geräten
gleichzeitig verfälscht werden. Und dann ist wieder die Frage die mich
beschäftigt: Wer gibt den Bus dann frei?

@Gralf und Markus
Bei einem solchen System würde ich nichts sparen, denn der
Verbindungsaufbau zum Server müsste ja ebenfalls über einen Bus
geschehen. Und da hab ich die gleichen Probleme. Einzige Möglichkeit:
Ich reserviere für jedes Gerät eine extra Leitung, damit wüsste der
"Server" und jedes andere Gerät sofort welche Geräte grad auf dem Bus
rumpfuschen, aber bei einem Adressbus mit 8 Bit Breite ergibt es die
maximale Anzahl von 256 verschiedenen Geräten. Damit würde ich den Bus
mal eben mit 274 Signalleitungen betreiben müssen etwas zu hoch wie ich
finde.
Eine andere Möglichkeit wäre zu sagen dass die Geräte unter sich nicht
kommunizieren sollen, und dies alles über eine Art Server abgewickelt
wird. Das würde bedeuten dass nur der Server zu anderen Geräte eine
Verbindung aufbauen kann, somit könnte es auch keine Kollision geben.
Das würde aber auch einen ehrheblichen Mehraufwand bedeuten. Der Server
müsste ständig jedes Gerät abfragen ob es was neues gibt. Wenn es was
neues gibt so lässt er sich das Datenpacket über den bereits
reservierten Bus schicken. Dieses leitet er dann unter Umständen an die
betroffenen Geräte weiter. Die Laufzeit der Datenpakete ist dadurch
zwar höher, aber wie es mir scheint ist dies die einzig vernünftige
Möglichkeit die mir bleibt.

@Dirk
ich werd mich noch n bissl über den CAN-Bus informieren. Allerdings ist
das ganze eine Kostenfrage. Wenn die Controller zu teuer sind werde ich
sie nicht einsetzten können.

Sven

Autor: Markus Kaufmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sven,

- bei Kollisionen auf dem CAN-Bus zieht sich der Teilnehmer mit der
niedrigeren Priorität zurück. Kollisionen sind deswegen kein Problem.
- wenn Du ein Protokoll verwendest, bei dem Kollisionen auftreten
können, dann warten einfach beide nach der Kollision eine zufällige
Zeit ab, bevor sie es wieder probieren. Diese Lösung wird beim Ethernet
benutzt.
- Wenn Du extra Leitungen für die Arbitrierung hast, dann brauchst Du
keine 274 Leitungen, da Du a) nicht für jede potentielle Adresse eine
Leitung brauchst, sondern nur für die real vorhandenen und b) das
sowieso nur für Karten mit Busmasterfähigkeit brauchst.
- Zur Serverlösung: Die Daten müssen nicht über den Server. Der Server
muß nur sagen, wann wer übertragen darf. Sonst müssen die Daten ja
zweimal über den Bus.

Prinzipiell solltest Du Dir auch mal bestehende Systeme anschauen. Es
ist ja nicht das erstemal, daß jemand für ein 19"-Rack einen Bus
braucht.

Markus

Autor: Peter Kasi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sven, dann erzeug in jedem Gerät ne Zufallszahl und warte diese Zeit
ab, bevor die Geräte wieder versuchen dürfen den Bus zu belegen. Kannst
ja auch mal nach CSMA/CD googeln...
Peter

Autor: Peter Kasi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus war wohl etwas schneller...

Autor: Gralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wenn Du für die Anmeldung der Geräte am Server eine Serielle Leitung
nimmst? Im Prinzip reicht es ja, wenn das Gerät, was senden will, seine
Adresse an den Server sendet. Dieser stellt die Adresse dann in eine
Warteschlange. Kommt die Adresse an die Reihe, sendet der Server
einfach die Adresse zurück. Alle angeschlossenen Geräte scannen diese
Leitung. Kommt die eigene Adresse, wird gesendet. Da auf diesem
seriellen Bus sicherlich weniger Traffic sein wird, als auf dem
parallelen, schadet es nicht, wenn ein Gerät mal etwas warten muß, bis
es seine Anfrage an den Server schicken kann, weil gerade zur selben
Zeit der Server eine Zuteilung macht oder ein anderes Gerät sich
anmeldet.
Sollte es doch etwas eng werden, kannst Du immer noch zwei serielle
Leitungen nehmen, eine zum Server hin, eine vom Server weg.

Wenn das einzige Problem beim Token-Ring die Verkabelung ist, dann sehe
ich da keine Probleme. Dadurch daß es ein begrenzter Ort ist
(19"Rack), kann man alle Eventualitäten einplanen. Die erste und
letzte Karte, besser den erstn und letzten Slot kannst Du intern schon
miteinander verbinden. Ist ein Slot frei, stellt dieser selbst die
Überdrückung her. Z.B. durch ein abfallendes Relais, das beim
Einstecken einer Karte über eine kleine Pinbrücke direkt am
Steckverbinder gespeist wird und dann anzieht.

Gralf

Autor: Schmittchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sven:
> Beide Geräte überprüfen anschlißend ob ihre korrekte Adresse
auf dem Bus liegt. Beide Geräte stellen fest, dass sie falsch ist

Nein, nur ein Gerät stellt das fest, da die Überprüfung nach jedem
Bit geschieht (und nicht erst nach der kompletten Adresse).

Ansonsten beschreibst du mit deinen Anforderungen genau das was der
CAN-Bus leistet.

Schmittchen

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Schmittchen
Diese Aussage bezog sich auf einen paralellen Bus mit 8 Bit. Seriell
stimme ich dir voll und ganz zu.
Ich werde jetzt einfach mit einer zufälligen Zeitverzögerung arbeiten,
falls 2 Geräte sich blockieren. Dürfte am einfachsten und billigsten
sein.

Sven

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.