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
CAN kann nur kurze Packete von 6 bytes. Das sind moeglicherweise nicht alle Wuensche. RS485 ist da etwas weniger limitiert.
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
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/doc2466.pdf 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
>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.
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.
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.
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...).
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)
>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.
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.
>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.
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.