Bussystem für viele AVR

Mit CAN sollten sich alle Deine Wünscher erfüllen lassen

Hi,

Can Bus ?

Gruß Rene

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

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

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.

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.

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

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

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

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.

>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

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