mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bussystem für viele AVR


Autor: Movergan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Community,

ich habe mich schon viel im Netz belesen und auch hier und komme aber zu 
keiner Lösung für mein Problem.

Ich möchte einen Bus für eine beliebige Menge an µCs (vorerst AVRs) 
aufbauen. Allerdings finde ich bisher keine Lösung zu meinen Vorgaben. 
USART klingt interessant und ist in den Datenblättern gut beschrieben, 
aber es kommt wohl nicht in Frage.

Ich brauche:
- bis zu 100 µC und mehr
- alle µC gleichberechtigt, nicht unbedingt Master-Slave-System, wäre 
aber auch möglich
- ob synchron oder asynchron ist egal (ja, für synchron braucht man 
einen Master)
- jetzt kommts: adresslos, d.h. gesendete Daten gehen an jeden 
Busteilnehmer und jeder entscheidet per Software für sich selbst, die 
Daten zu verwerten oder zu verwerfen
- bis zu 1 oder 2kByte/s an Nutzdaten sollen insgesamt möglich sein
- serielle Übertragung, es sollten nicht zu viele Leitungen sein
- Fehlererkennung und Korrektur (z.B. per Parity-Bit) wäre wünschenswert

Hat jemand sowas schonmal gemacht oder kann mir Tipps oder Links geben?

Vielen Dank,
Movergan

Autor: Philipp Co (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit CAN sollten sich alle Deine Wünscher erfüllen lassen

Autor: Rene Zimmermann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Can Bus ?

Gruß Rene

Autor: sechsdreizwei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CAN kann nur kurze Packete von 6 bytes. Das sind moeglicherweise nicht 
alle Wuensche. RS485 ist da etwas weniger limitiert.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sechsdreizwei wrote:
> CAN kann nur kurze Packete von 6 bytes. Das sind moeglicherweise nicht
> alle Wuensche. RS485 ist da etwas weniger limitiert.

Im Vergleich dazu, um mit RS485 nen funktionierenden Multimaster 
aufzubauen, ist der Aufwand beim CAN, längere Daten in 8Byte-Pakete zu 
unterteilen geradezu lächerlich gering.

Aber man hat den entscheidenden Vorteil, daß längere Daten nicht den Bus 
blockieren. Man kann z.B. in einen Teilnehmer ein Softwareupdate laden, 
während sich alle anderen einfach weiter unterhalten.


Peter

Autor: Kai G. (runtimeterror)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche sonstigen Anforderungen gilt es denn einzuhalten? 
Echtzeitfähigkeit, Latenz, ...

Spontaner Einfall: Man kann AVRs mit zwei USARTs auch als Token-Ring 
aneinanderkabeln - stelle ich mir vom Aufwand her nicht allzu schwierig 
vor. Kannst sogar mehrere Tokens absetzen, wenn der Puffer reicht. Zum 
Ergänzen weiterer Einheiten muss das System ggf. abgeschaltet werden. 
Ein doppelter Ring wäre wahrscheinlich zu aufwändig.

Bis zu 256 AVRs lassen sich im "Multi-processor Communication Mode" auf 
einen USART-Bus aufschalten. Seite 161
http://www.atmel.com/dyn/resources/prod_documents/...
Je nach Verfahren muss hier eine Kollisionserkennung implementiert oder 
auf ein verlorenes Token reagiert werden.

So lange du wir was für die Kollisionserkennung ausdenkst fällt mir 
gerade nicht ein, was dagegen spricht alles auf ein USART zu packen (mal 
davon abgesehen, dass der dafür nicht vorgesehen ist ;) ). Vielleicht 
einen zentralen µC, der die Sendefreigaben erteilt...

Was die fertigen Lösungen CAN-Bus, etc. angeht, kennen sich Andere hier 
besser aus als ich.

Gruß

Kai

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>CAN kann nur kurze Packete von 6 bytes.

Es sind zwar 8 Byte Nutzdaten, macht aber keinen grossen Unterschied.
Dafür ist CAN relativ schnell mit bis zu 1 MBaud.

AVR's mit CAN gibt es aber nicht allzuviele und die Implementierung 
finde ich alles andere als gelungen, erste Gegeneration halt.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai Giebeler wrote:

> Spontaner Einfall: Man kann AVRs mit zwei USARTs auch als Token-Ring
> aneinanderkabeln

Ein klassischer Ansatz bei RS485 ist daran angelehnt: Token Passing. 
physikalisch irgendwas, logisch Ring.

Wobei der physikalische Ring technische Lösungen für den Ausfall einer 
Node benötigt (vgl. optischem Bypass bei FDDI), weshalb die meisten 
logischen Ringstrukturen physikalisch anderes realisiert werden (Token 
Ring wurde als Stern verkabelt).

Alle Token-Lösungen haben einen Haken: Das Token kann verloren gehen und 
dann wird's spannend wie man zuverlässig wieder aufsetzt.

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn nichts gegen Can spricht, würde ich das damit machen. Da gibt es 
satt Unterstützung in jeder Hinsicht: Jede Menge Chips, Dokumentation, 
Projekte etc. Ein eigenes Protokoll zu entwerfen, was wirklich 
funktioniert, kann schnell mal 1-2 Jahre Vollzeit verschlingen.

RS485 ansich ist ja auch noch kein Protokoll, sondern eher der 
Physical-Layer.

Autor: Philipp Co (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde Dir auch weiterhin zu CAN raten und dann vielleicht einen CAN 
Controller extra nehmen. zB den MCP2515 der ist zusammen mit einem Mega8 
immernoch günstiger als ein AVR mit CAN und das funzt wenigstens gut. 
Außerdem hat CAN (genau wie RS485) noch alle Vorteile die eine 
differentielle Übertragung so mit sich bringt. Du wirst die 100 AVR ja 
nicht gerade alle auf einem Board haben.

Autor: Movergan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Welche sonstigen Anforderungen gilt es denn einzuhalten?
Sonst habe ich keine Anforderungen. Latenz, Echtzeit, Leitungslängen, 
alles nicht so wichtig, da keine speziellen Wünsche.

>CAN kann nur kurze Packete von 6 bytes.
Ob 6 oder 8, wie andere sagen, ist egal. Ich habe nur kleine Datenpakete 
von evtl. 16 Byte. Kann man möglicherweise splitten, hab ich mir noch 
nicht überlegt.
Aber die CAN-Unterstütung ist bei AVR zumindest nicht gegeben, bzw. 
nicht gut wie ihr sagt.
Hab gerade mal kurz was zum CAN-Bus gelesen (später lese ich mehr) und 
auf den ersten Blick gefällt mir, dass er adresslos ist. Die Nachrichten 
enthalten einen Identifier, also eine Typenbezeichnung, und jeder 
Teilnehmer prüft, ob er damit was anfangen muss.

>Man kann AVRs mit zwei USARTs auch als Token-Ring aneinanderkabeln
Ja, aber wenn ich es physikalisch als Bus aufbauen will, dann brauche 
ich ja wieder Adressen und die will ich nicht.
Verlorene Tokens sind auch kein Problem. Bei mir würde ein Timeout 
reichen und wenn das alte Token doch noch verspätet auftaucht, wird es 
geschluckt. Daraus resultiert eine kleine Verzögerung auf dem Bus, aber 
ich habe nichts zeitkritischen.

Im Grunde will ich eine Steuerung aufbauen, bei der mehrere AVRs (nicht 
auf dem gleichen Board aber in kurzen Entfernungen) selbstständig 
arbeiten und Messwerte oder Verarbeitungsaufträge weitergeben, die 
mehrere andere AVRs betreffen können. Daher soll es adresslos sein, weil 
kein AVR weiß, wer noch so zuhört und man soll leicht im Betrieb weitere 
AVRs anschließen oder bestehende abklemmen können. Einen Master kann es 
meinetwegen geben, bei dem sich ein frisch angeschlossener AVR bei der 
Initialisierung anmeldet (mit seinem Typ und nicht mit einer Adresse).
Das Bussystem soll ausbaubar sein, deswegen will ich erstmal bis 100 
AVRs möglich machen. Die Datenraten sind sehr gering, es werden nur 
kleine Codes versendet. Es ist nichtmal wichtig, dass Datenpakete 
bestätigt werden. Wenn ein Busteilnehmer ausfällt, ist er weg und keiner 
merkt es. Das ist ok.
Außerdem soll der Bus leicht nachbaubar sein, d.h. 
Multicontroller-Lösungen würde ich nicht gerade bevorzugen, z.B. AVR + 
jeweils CAN-Controller.

Welche anderen µCs können denn besser mit CAN umgehen?
Was ist von I2C zu halten?
Oder doch noch andere Ideen? Gibts eine Webseite, auf der jemand einen 
geeigneten Bus vorstellt?

Danke euch schonmal!

Autor: Movergan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Korrektur: Meine Datenpakete umfassen 16 Bit, nicht 16 Byte. Mehr wäre 
aber auch nicht schlecht, z.B. 4 Byte.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Movergan wrote:

> Welche anderen µCs können denn besser mit CAN umgehen?

Unterhalb der 40/64-Pin-Klasse ist beispielsweise Microchip etwas 
rühriger. Gibt 28pinner mit CAN, z.B. PIC18F258[0] und dsPIC30F4012. 
Nachteilig sind freilich die Bugs, der MCP2515 ist ziemlich sauber, die 
integrierten Versionen oft nicht.

Interessanterweise ist ein Mega8/168 mit MCP2515 erheblich billiger als 
beispielsweise der PIC18F258 mit integriertem CAN. Zumindest bei R&Co, 
in 100er Stückzahlen mag das anders sein.

8051er mit CAN dürfte es recht viele geben. Auch von Atmel 
(AT89C51CC...).

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mei den AVRs kann man die Adressierung umgehen, man kann eine Feste 
Adresse verwenden und jeder µC antwortet auf diese Adresse. Jetzt kannst 
du per software auswerten, ob der jeweilige µC etwas damit anfangen 
kann.

Der Vorteil wäre jetzt noch, du könntest den Bus doch noch segmentieren, 
d.h. wenn du datenpakete hast die nur eine spezielle gruppe etwas 
angehen kannst du diese Paket an diese spezielle Adresse schicken. (Eine 
Art Broadcast, Multicast lässt sich also so realisieren)

Autor: Movergan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Der Vorteil wäre jetzt noch, du könntest den Bus doch noch segmentieren,
>d.h. wenn du datenpakete hast die nur eine spezielle gruppe etwas
>angehen kannst du diese Paket an diese spezielle Adresse schicken. (Eine
>Art Broadcast, Multicast lässt sich also so realisieren)
Die Idee mit dem Identifier wäre ja das gleiche, beides kann erst nach 
Empfang per Software ausgewertet werden.

Wie machen Busse (ohne Master und adresslos) das eigentlich generell, 
dass nicht zwei Teilnehmer gleichzeitig quatschen? Ich könnte eine 
Besetztleitung definieren, die von einem sendewilligen Teilnehmer auf 
einen definierten "Besetzt"-Pegel gesetzt werden muss, bevor er senden 
darf. Andere Teilnehmer müssen warten, bis die Leitung wieder auf den 
"Frei"-Pegel gewechselt hat, bevor sie selbst wieder auf "Besetzt" 
umschalten und dann senden. Aber damit habe ich nicht den 
unwahrscheinlichen Fall abgedeckt, dass zwei Teilnehmer genau 
gleichzeitig die Leitung auf "Besetzt" schalten. Ansonsten gibts da noch 
die Möglichkeit mit dem Selbsthilfegruppengesprächsball, auch Token 
genannt. Wer den Ball hat, darf erzählen. Das erfordert aber Adressen 
oder eine physikalisch definierte Reihenfolge. Was anderes fällt mir 
dazu nicht ein. (für den Fall, dass ich mir doch selber einen Bus 
bastel)

Autor: mehrfacher STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Falle von CAN gibt es ein dominantes Bit.
Der Sender empfängt gleichzeitig seine gesendeten Daten. Wenn der 
Empfang nicht mit dem Gesendeten übereinstimmt, stellte der Sender mit 
dem nicht dominanten Bit seine Sendung erst mal ein.

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnte man so realisieren: nach dem belegen der Besetzt leitung wartet 
jeder der schreiben will eine (Zufällige!!!) Zeit ab und liest während 
dessen den bus, wenn nichts ankommt, kann er schreiben. Natürlich muss 
die Zeit entsprechend klein sein, um den Bus nicht extrem auszubremsen.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Selbsthilfegruppengesprächsball

Oder auch Medienzugriffssteuerung genannt. Ich arbeite selbst derzeit an 
so etwas, so dass n RFM12 Funkmodule sich zivilisiert unterhalten. 
Google nach CSMA/CA (Carrier Sense Media Accesscontrol / Collision 
Avoidance) bringt viel Infos zutage. So etwas könnte man auch auf RS485 
als physikalische Übertragungsschicht implementieren (was ich wohl 
demnächst auch mal in Angriff nehmen muss).

Grüße
Stefan

Autor: Uwe Bonnes (Firma: TU Darmstadt) (uwebonnes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ethernut unterstuetzt den AT90CAN128 recht gut.

Autor: Movergan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>jeder der schreiben will eine (Zufällige!!!) Zeit ab und liest während
>dessen den bus, wenn nichts ankommt, kann er schreiben.
Das war ja auch mein Gedanke, aber da die Busteilnehmer nicht 
synchronisiert senden, kann prinzipiell jederzeit ein Teilnehmer eine 
Kommunikation starten.
Wenn also ein sendewilliger Teilnehmer den Bus prüft, ob der gerade frei 
ist, kann in der Zwischenzeit ein anderer Teilnehmer anfangen zu senden, 
bevor der oben genannte Teilnehmer nun beginnt. Das Zeitintervall 
zwischen "Bus prüfen" und "mit Senden beginnen" ist sehr klein, aber ich 
frage mich, wie statistisch wahrscheinlich es ist, dass genau zwischen 
den beiden Vorgängen jemand anderes zu senden beginnt und dann senden 
zwei Teilnehmer gleichzeitig. Nicht, dass dann nur Datenmüll ankommt, es 
ist ja auch elektronisch ein Problem, wenn ein AVR den Pegel der Leitung 
anhebt und der andere ihn gleichzeitig senkt.

Aber ihr habt mich auf eine Idee gebracht. Ich werde mir nochmal USART 
ansehen und jedem Teilnehmer einfach die gleiche Adresse geben. Das 
könnte vielleicht gehen. Über eine Art Subnet kann ich mir ja auch noch 
Gedanken machen, bzw. eine logische Aufteilung wie beim VLAN.

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.