mikrocontroller.net

Forum: Haus & Smart Home CAN Bus oder Bus per Software?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Nano (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Beim durchstöbern alter Threads zum Thema Smart Home und eigene Bus 
Lösung ist mir aufgefallen, dass die meisten auf CAN Bus setzen weil es 
für CAN Bus wiederum jede Menge Mikrocontroller gibt, die den CAN Bus 
verstehen bzw, eine Lösung in Hardware mit an Bord haben.

Meine Frage ist nun aber. Wäre es bei der geringen Geschwindigkeit von 
so einem Smart Home BUS nicht auch möglich, so einen BUS, wobei das 
nicht CAN sein muss, in Software zu realisieren?

Den Vorteil den ich mir dadurch verspreche wären:
1. leichtere Portierbarkeit auf andere µC.
2. Baumtopologie, mit der bestehende CAN BUS fähige Chips, die den BUS 
in Hardware realisiert haben, vielleicht nicht klar kommen könnten.
3. Mehr Auswahl an µC.
4. Eigener BUS Standard unabhängig von CAN und somit mehr Freiheiten.


Auch soll der KNX BUS mit dem CAN Bus eng verwandt sein, aber wenn er 
nur verwandt ist, also nicht CAN ist, wie wird dort dann die Bus 
Anbindung gelöst? Wurden hierfür spezielle KNX BUS Chips entwicklet oder 
sind das Softwarelösungen in den µC?

von _Gast (Gast)


Bewertung
1 lesenswert
nicht lesenswert

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Nano schrieb:
> Meine Frage ist nun aber. Wäre es bei der geringen Geschwindigkeit von
> so einem Smart Home BUS nicht auch möglich, so einen BUS, wobei das
> nicht CAN sein muss, in Software zu realisieren?

So gefragt, also ohne Zeitlimit: ja.

Bis du eine komplett eigene Lösung hast, die genauso zuverlässig läuft 
wie CAN, wird es halt ein wenig länger dauern.

: Bearbeitet durch User
von o.m.g (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Bis du eine komplett eigene Lösung hast, die genauso zuverlässig läuft
> wie CAN, wird es halt ein wenig länger dauern.

PS: Das bezog sich auf einen Multimaster-Bus.

von Nano (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
_Gast schrieb:
> Na dann viel Spass!
>
>
> 
http://www.google.de/url?q=https://www.nxp.com/docs/en/reference-manual/BCANPSV2.pdf&sa=U&ved=2ahUKEwi6ubT6vLPnAhUM0qYKHcy9BpgQFjADegQICRAB&usg=AOvVaw27Tdd6C-1D8DQqLdL93Lac


Danke für den Link. Das Dokument ist sehr aufschlußreich.

>
> meld dich mal wenn das ganze läuft!

Ich habe nichts konkretes zugesagt, sondern nur mal gefragt. :)

von Nano (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
A. K. schrieb:
> Nano schrieb:
>> Meine Frage ist nun aber. Wäre es bei der geringen Geschwindigkeit von
>> so einem Smart Home BUS nicht auch möglich, so einen BUS, wobei das
>> nicht CAN sein muss, in Software zu realisieren?
>
> So gefragt, also ohne Zeitlimit: ja.

Wobei man aber auch sagen muss, dass CANBus Anfang der 80er eingeführt 
wurden und wir somit fast ca. 40 Jahre Chipentwicklung haben, mit Chips, 
die wesentlich leistungsfähiger sind, als das, was man früher gehabt 
hat.


> Bis du eine komplett eigene Lösung hast, die genauso zuverlässig läuft
> wie CAN, wird es halt ein wenig länger dauern.

Ja, vielleicht stelle ich mir das alles zu einfach vor. :)

So als Grundgedanken hatte ich hier folgende Überlegungen:

Im Prinzip hat man Pakete, vergleichbar wie beim IP Protokoll bzw. 
Ethernet, nur kleiner. Die Frames die da versendet werden, haben einen 
recht trivialen Aufbau.

Man braucht ein paar Bits für das Ziel, sowie für die Quelle, dann noch 
deutlich mehr Bits für Daten und am Ende wieder ein paar Bits für die 
Error Correction und vielleicht noch vor der Error Correction und vor 
den Daten ein paar Bits für das ein oder andere Flag.

Damit nicht jeder gleichzeitig sendet, braucht man noch bekannte 
Verfahren wie CSMA/CD, CSMA/CA oder CSMA/CR.
Und dann noch eine feste Bitrate als Geschwindigkeit.


Wie dann die Daten genau übertragen werden, ob digital oder analog 
irgendwie aufmoduliert, das ist ne Elektronikergeschichte, da kenne ich 
mich zu wenig aus.

Was man noch haben will ist, dass der BUS mit 2 Leitungen auskommt und 
auf dem eine DC Stromversorgung von ungefähr 30 V, wegen den 
Leitungslängen und Spannungsabfall, übertragen wird und das digitale 
oder analoge Signal da oben Huckepack drauf läuft.
Vor dem µC muss man das Signal aus den 30 V extrahieren bzw, auskoppeln.
Auch das ist ne Elektronikergeschichte, ich habe mir dazu aber noch 
keine ausreichende Gedanken gemacht, wie man das am besten löst. 
Vielleicht mit Z-Dioden? Ah nein, das geht wegen dem Spannungsabfall 
vermutlich nicht bzw. wären die Geräte dann nicht flexibel genug.


Und dann dürfte man da zumindest die Grundbasis für den Austausch von 
Paketen haben.

Als nächstes kommt als Zwiebelschicht ne weitere Schicht, in der dann 
die eigenltichen Protokolle genauer definiert werden, drauf. Diese 
werden im Datensegment des Pakets verschickt.

Als zweite Schichte wäre hier bspw. das Aushandeln eines 
Verschlüsselungsverfahren und Verschlüsselung sinnvoll.
CRC haben wir ja schon in der ersten Schicht.


Auch TCP/IP fing mal klein an und wurde AFAIK an irgendeiner Uni in 
Hawei entwickelt.

von Carl D. (jcw2)


Bewertung
1 lesenswert
nicht lesenswert
Vergess aber nicht den Link auf das Github-Repository mit der 
funktionsfähigen Software zu posten.

: Bearbeitet durch User
von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Damit nicht jeder gleichzeitig sendet, braucht man noch bekannte
> Verfahren wie CSMA/CD, CSMA/CA oder CSMA/CR.
> Und dann noch eine feste Bitrate als Geschwindigkeit.
> (...)
> Was man noch haben will ist, dass der BUS mit 2 Leitungen auskommt und
> auf dem eine DC Stromversorgung von ungefähr 30 V, wegen den
> Leitungslängen und Spannungsabfall, übertragen wird und das digitale
> oder analoge Signal da oben Huckepack drauf läuft.

Das ist KNX/TP.

> Vor dem µC muss man das Signal aus den 30 V extrahieren bzw, auskoppeln.
> Auch das ist ne Elektronikergeschichte, ich habe mir dazu aber noch
> keine ausreichende Gedanken gemacht, wie man das am besten löst.

Man kauft einen Siemens Busankoppler ;)

Es gibt auch kollisionsfreie Multimaster-Systeme wie Token-Ring oder 
einen Baum mit aktiven Knoten. Letzterer scheint mir gut zur 
Smart-Home-Verkabelung zu passen. Damit wird die Software geradezu 
trivial.

: Bearbeitet durch User
von Xerxes (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi.
Natürlich kannst du dir ein beliebiges Busprotokoll in SW auf beliebiger 
physikalischer Ebene realisieren.
Habe ich mal mit einem RS422-Bus quer durch meine Wohnung gemacht.
War nur eine Spielerei um mal zu sehen was geht.

Einfach wird's natürlich wenn man sich auf bestehende Busprotokolle und 
z.B. CAN beschränkt.

von Nano (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Das ist KNX/TP.

Es ist nur ähnlich, aber nicht das gleiche.
Eine Spannung von 30 V ist nur naheliegend, da viele gängige 
Spannungsregler damit noch arbeiten können und eine hohe Spannung zu 
große Leitungsverluste verhindert.


>> Vor dem µC muss man das Signal aus den 30 V extrahieren bzw, auskoppeln.
>> Auch das ist ne Elektronikergeschichte, ich habe mir dazu aber noch
>> keine ausreichende Gedanken gemacht, wie man das am besten löst.
>
> Man kauft einen Siemens Busankoppler ;)

Und hat dann einen KNX Bus mit allen Nachteilen, wie einer ziemlich 
proprietären ETS Software.


> Es gibt auch kollisionsfreie Multimaster-Systeme wie Token-Ring oder
> einen Baum mit aktiven Knoten. Letzterer scheint mir gut zur
> Smart-Home-Verkabelung zu passen. Damit wird die Software geradezu
> trivial.

Du meinst bezüglich Baum an jeder Verzweigung einen Knoten, der das dann 
aktiv managed, oder?
Könnte man machen, dafür würde dann sogar auch CanBUS gehen, kostet dann 
allerdings für jede Abzweigung ein Bauteil und ist somit eine Kosten 
Nutzenfrage.

Token Ring ist schlecht, weil es einen geschlossenen Kreislauf 
darstellt. Damit kann man bei Blitzeinschlägen leicht Ströme in die 
Leitung induzieren.
Außerdem ist es unflexibel beim Aufbau des Netzes.
Eine Baumstruktur halte ich für ein Haus schon am sinnvollsten. Die 
Frage ist halt nur, ob man die Verzweigungen aktiv managed oder nicht. 
Dagegen sprechen die Kosten.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Xerxes schrieb:
> Natürlich kannst du dir ein beliebiges Busprotokoll in SW auf beliebiger
> physikalischer Ebene realisieren.
> Habe ich mal mit einem RS422-Bus quer durch meine Wohnung gemacht.
> War nur eine Spielerei um mal zu sehen was geht.

Und wie lief das so?
Welche Bitrate hast du verwendet?

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Eine Baumstruktur halte ich für ein Haus schon am sinnvollsten. Die
> Frage ist halt nur, ob man die Verzweigungen aktiv managed oder nicht.
> Dagegen sprechen die Kosten.

Dafür übrigens die höhere Geschwindigkeit, die man dann fahren könnte.

von Fitzebutze (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Ein Mischmasch aus Ethernet und dem klassischen RS485/modbus 
funktioniert auch nicht schlecht. Simpel, einfach zu debuggen.
Aber man muss immer an die Dokumentation denken. Nützt alles nichts, 
wenn das Zeug kaputtgeht und keiner mehr weiss, wie's geht.

von Harald (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Fitzebutze schrieb:
> Nützt alles nichts,
> wenn das Zeug kaputtgeht und keiner mehr weiss, wie's geht.

Bei SmartHome sollte man immer an die eigene Nichtverfügbarkeit denken, 
das geht manchmal schneller als man denkt und dann sitzen die 
Hinterbliebenen mit dem Spezialscheiss, den kein Mensch warten kann. Da 
bleibt nur komplett rausreißen und neu.
Klar, kann einem persönlich egal sein, soweit richtig.

von Xerxes (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Xerxes schrieb:
>> Natürlich kannst du dir ein beliebiges Busprotokoll in SW auf beliebiger
>> physikalischer Ebene realisieren.
>> Habe ich mal mit einem RS422-Bus quer durch meine Wohnung gemacht.
>> War nur eine Spielerei um mal zu sehen was geht.
>
> Und wie lief das so?
> Welche Bitrate hast du verwendet?

Ach, das ist lange her. Wenn ich mich recht erinnere waren es damals 
testweise bis 200kBit. Kommt natürlich aufs Kabel an.
Nach Standart kann der Bus 1MBit bis zu 100m. Das sollte doch reichen.
Ich hatte einen Master im Bus und einige Slaves die Daten nur auf 
Anforderung zurück gesendet haben.

Das Protokoll wird natürlich total easy wenn du die Daten einfach mit 
einem Schieberegister auf einem GPIO raushaust. (z.B. ein Startbit ,8 
Datenbits, und 1 stopbit)

von Andreas S. (marais)


Bewertung
1 lesenswert
nicht lesenswert
Harald schrieb:
> Bei SmartHome sollte man immer an die eigene Nichtverfügbarkeit denken,
> das geht manchmal schneller als man denkt und dann sitzen die
> Hinterbliebenen mit dem Spezialscheiss, den kein Mensch warten kann. Da
> bleibt nur komplett rausreißen und neu.

Daran dachte ich bei meiner Installation auch. Wenn meine Frau hier als 
Witwe im SmartHome sitzt, sollte sie in der Lage sein, einen kundigen 
Handwerker zu rufen, der reparieren kann, anstatt die Installation 
komplett neu zu machen. Das würde hier 30k kosten.

von Harald (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Bedenke auch, wenn die Komponenten in 10 Jahren anfangen auszufallen:

- Du wirst andere Prioritäten haben, Du willst dann einfach nur 
tauschen/erweitern, nicht neu entwicklen. Versprochen!

- In 10 Jahren wechseln die Entwicklungswerkzeuge und verfügbaren 
Komponenten dramatisch, einfach kopieren ist meist nicht mehr möglich. 
Du würdest zu einer Neuentwicklung gezwungen werden.

- CAN wird es noch geben, mit Sicherheit. Ein eigenes Protokoll wirst Du 
dann neu erdenken und implementieren müssen und dich über die netten 
„Schmankerl“ von damals ärgern.

- Fertige Komponenten verfügen (meist) über eine Produktreife, die bei 
einer Eigenentwicklung hart erkämpft werden müssen.

von Manuel X. (vophatec)


Bewertung
1 lesenswert
nicht lesenswert
Denk an die Verschlüsselung..

Immerhin ist genau das der Punkt den DU ja so großspurig bemängelst 
insb. An KNX.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Manuel X. schrieb:
> Denk an die Verschlüsselung..
>
> Immerhin ist genau das der Punkt den DU ja so großspurig bemängelst
> insb. An KNX.

Viel mehr als die Verschlüsselung bemängele ich den Punkt, dass die ETS 
Software proprietär und unfrei ist. Wäre die Open Source wie Eclipse 
oder Apache, ich würde gar nicht lange zögern und hätte mich schon 
längst für KNX entschieden.

Bezüglich der Verschlüsselung bei KNX ist mit KNX Secure ja durchaus 
eine Option in Sicht, insofern ist das nicht der Hauptkritikpunkt.

von Nano (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Daran dachte ich bei meiner Installation auch. Wenn meine Frau hier als
> Witwe im SmartHome sitzt, sollte sie in der Lage sein, einen kundigen
> Handwerker zu rufen, der reparieren kann, anstatt die Installation
> komplett neu zu machen. Das würde hier 30k kosten.

und

Harald schrieb:
> Bedenke auch, wenn die Komponenten in 10 Jahren anfangen
> auszufallen:
>
> ...

Ja, das sind die Nachteile von einer eigenen Lösung. Danke euch beiden 
für den Hinweis.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Xerxes schrieb:
> Das Protokoll wird natürlich total easy wenn du die Daten einfach mit
> einem Schieberegister auf einem GPIO raushaust. (z.B. ein Startbit ,8
> Datenbits, und 1 stopbit)

Ja, wenn die Spannung in der Leitung 0 V beträgt würde das direkt gehen,
aber ich müsste die Daten ja noch auf eine 30 V DC Leitung 
aufmodulieren.

von Tilo R. (joey5337) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ein paar Gedanken:


Nano schrieb:
> Meine Frage ist nun aber. Wäre es bei der geringen Geschwindigkeit von
> so einem Smart Home BUS nicht auch möglich, so einen BUS, wobei das
> nicht CAN sein muss, in Software zu realisieren?

Ja, das ist möglich. Aber...


Nano schrieb:
> 1. leichtere Portierbarkeit auf andere µC.
Ein serielles Protokoll ist timing-kritisch, in Software realisiert also 
nicht so leicht zu portieren.

> 2. Baumtopologie, mit der bestehende CAN BUS fähige Chips, die den BUS
> in Hardware realisiert haben, vielleicht nicht klar kommen könnten.

Mit einer Sternförmigen Verkabelung braucht man einen aktiven 
Sternpunkt. Mit einer Baumtopologie braucht man mehrere Busanschlüsse am 
Knoten. Es wird also in jedem Fall aufwändiger, als z.B. bei CAN oder 
RS485, die nur einen Anschluss an ein gemeinsames Kabel brauchen.

> 3. Mehr Auswahl an µC.
vorausgesetzt, er kriegt das Bustiming hin. Aber eigentlich geht jeder 
µC, schließlich gibt es externe CAN-Controller.

> 4. Eigener BUS Standard unabhängig von CAN und somit mehr Freiheiten.
Ich habe mir verschiedene Hausbus-Projekte angeschaut, die CAN verwenden 
und dabei unterschiedliche Ideen haben, wie sie den Bus nutzen.
Ich hatte nicht den Eindruck, dass CAN dabei limitierend ist.
Das Protokoll, das man über dem CAN-Bus macht ist ja immer noch frei.
Die einzigen Beschränkungen sind CAN-IDs von max 29 Bit und eine Payload 
von max. 8 Byte pro Paket.

Nano schrieb:
> Man braucht ein paar Bits für das Ziel, sowie für die Quelle, dann noch
> deutlich mehr Bits für Daten und am Ende wieder ein paar Bits für die
> Error Correction und vielleicht noch vor der Error Correction und vor
> den Daten ein paar Bits für das ein oder andere Flag.

z.B. http://doku.canathome.de/ nutzt die CAN-ID, um darin die Absender- 
und Empfängeradresse mit jeweils 8 Bit einzukodieren.

Error-Correction, bzw. zumindest Fehler-Erkennung, ist im CAN-Bus schon 
eingebaut. Eine großartige Möglichkeit für Softwarefehler schonmal 
ausgeschlossen :-)

> Damit nicht jeder gleichzeitig sendet, braucht man noch bekannte
> Verfahren wie CSMA/CD, CSMA/CA oder CSMA/CR.

Buszugriffsverfahren sind nicht trivial und sie betreffen immer auch die 
elektrische Signalübertragung.

CAN ist CSMA/CR. Umgesetzt wird das indem statt High und Low auf dem Bus 
die Signale "Dominant" und "Rezessiv" verwendet werden. Zusätzlich ist 
der Bus so langsam, dass ein Knoten es noch mitbekommt, wenn ein anderer 
Knoten eines seiner rezessiven Bits dominant überschreibt. Dafür ist der 
Buszugriff deterministisch, Kollissionen gibt es nicht. Theoretisch kann 
man die Buskapazität zu 100% ausnutzen.

Das alte Ethernet (10Base2) macht CSMA/CD und ist deutlich schneller, 
weil zur Kollisionserkennung nicht auf ein einzelnes Bit gewartet wird, 
sondern auf ein ganzes Paket. Jeder Knoten kann senden, wenn er einen 
freien Bus sieht. Signale mehrere Knoten breiten sich auf dem Bus aus 
und überlagern sich. Damit sendende Knoten eine Kollision erkennen 
können muss ein Paket mindestens so lang sein, dass es innerhalb der 
Paketlaufzeit überall im Bus ankommt. Bei einer Kollision muss ein 
Knoten warten und es später nochmal probieren (wo es vielleicht wieder 
nicht klappt). Weil das vom Zufall abhängt heißt das Verfahren 
nichtdeterministisch oder stochastisch. Blöd ist, wenn viel Verkehr ist. 
Dann gibt es immer mehr Kollisionen und die nutzbare Bandbreite sinkt 
sogar.

RS485 hat weder dominant/rezessive Signale, noch können sich gesendete 
Daten überlagern. Es darf also nur einer gleichzeitig senden und deine 
Software muss sich drum kümmern. Wenn man das als Multimaster, also 
nicht Master-Slave, abhandeln will, wird das richtig kompliziert (und 
damit fehleranfällig).


> Was man noch haben will ist, dass der BUS mit 2 Leitungen auskommt und
> auf dem eine DC Stromversorgung von ungefähr 30 V, wegen den
> Leitungslängen und Spannungsabfall, übertragen wird und das digitale
> oder analoge Signal da oben Huckepack drauf läuft.
Ich würde mich nicht so auf die 2 Leitungen festlegen. Eine separate 
Stromversorgung, also 4 Adern, sind nicht so viel mehr Kabel. Dafür wird 
der Rest einfacher. Auch das grüne KNX-Kabel hat 4 Adern :-)

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tilo R. schrieb:
> Nano schrieb:
>> 1. leichtere Portierbarkeit auf andere µC.
> Ein serielles Protokoll ist timing-kritisch, in Software realisiert also
> nicht so leicht zu portieren.

Oben wurden Schieberegister vorgeschlagen, könnte man mit solchen 
Hardwarebausteinen das Problem zumindest für das Senden beim Timing 
nicht in den Griff kriegen?`


>> 2. Baumtopologie, mit der bestehende CAN BUS fähige Chips, die den BUS
>> in Hardware realisiert haben, vielleicht nicht klar kommen könnten.
>
> Mit einer Sternförmigen Verkabelung braucht man einen aktiven
> Sternpunkt. Mit einer Baumtopologie braucht man mehrere Busanschlüsse am
> Knoten. Es wird also in jedem Fall aufwändiger, als z.B. bei CAN oder
> RS485, die nur einen Anschluss an ein gemeinsames Kabel brauchen.

KNX kommt ohne aus, die Reflektionen am Bus durch eine Baumtopologie 
scheinen bei niedrigen Geschwindigkeiten in den Griff zu kriegen sein.
Ansonsten könnte KNX nicht so funktionieren wie es funktioniert.

Gibt es für CAN IC Bausteine, die mehrere CAN Schnittstellen haben, also 
sich für so etwas genau eignen und die Signale vom einen Strang in den 
nächsten senden können?


>> 3. Mehr Auswahl an µC.
> vorausgesetzt, er kriegt das Bustiming hin. Aber eigentlich geht jeder
> µC, schließlich gibt es externe CAN-Controller.

Das ist gut zu wissen, dann könnte man so eine aktive Weiche für die 
Baumstruktur zumindest mit einem µC und mehreren CAN-Controllern lösen.
Stellt sich nur die Frage, was die kosten.


>
>> 4. Eigener BUS Standard unabhängig von CAN und somit mehr Freiheiten.
> Ich habe mir verschiedene Hausbus-Projekte angeschaut, die CAN verwenden
> und dabei unterschiedliche Ideen haben, wie sie den Bus nutzen.
> Ich hatte nicht den Eindruck, dass CAN dabei limitierend ist.
> Das Protokoll, das man über dem CAN-Bus macht ist ja immer noch frei.
> Die einzigen Beschränkungen sind CAN-IDs von max 29 Bit und eine Payload
> von max. 8 Byte pro Paket.

Ja, gehen tut das schon.
Bei nur 8 Byte Payload müsste man größere Datenmengen in mehrere Pakete 
aufteilen und da sind 8 Byte leider sehr limitierend, da man ja auch 
noch Platz für dieser Nummerierung dieser Teilstücke benötigt.
Für Kapselung mit Headern und Co wird da sehr ungünstig.
Ich wünschte, man könnte wenigstens 64 Byte als Payload übertragen, da 
könnte man schon einiges mit Anfangen, ohne die Pakete zu zerstückeln 
oder die Payload fest zu verdrahten, wie es einige gelöst haben.



> z.B. http://doku.canathome.de/ nutzt die CAN-ID, um darin die Absender-
> und Empfängeradresse mit jeweils 8 Bit einzukodieren.

Ja, die Seite kenne ich, habe schon einiges darin gelesen.
Trotzdem Danke für den Link.


>
>> Damit nicht jeder gleichzeitig sendet, braucht man noch bekannte
>> Verfahren wie CSMA/CD, CSMA/CA oder CSMA/CR.
>
> Buszugriffsverfahren sind nicht trivial und sie betreffen immer auch die
> elektrische Signalübertragung.
>
> CAN ist CSMA/CR. Umgesetzt wird das indem statt High und Low auf dem Bus
> die Signale "Dominant" und "Rezessiv" verwendet werden. Zusätzlich ist
> der Bus so langsam, dass ein Knoten es noch mitbekommt, wenn ein anderer
> Knoten eines seiner rezessiven Bits dominant überschreibt. Dafür ist der
> Buszugriff deterministisch, Kollissionen gibt es nicht. Theoretisch kann
> man die Buskapazität zu 100% ausnutzen.
>
> Das alte Ethernet (10Base2) macht CSMA/CD und ist deutlich schneller,
> weil zur Kollisionserkennung nicht auf ein einzelnes Bit gewartet wird,
> sondern auf ein ganzes Paket. Jeder Knoten kann senden, wenn er einen
> freien Bus sieht. Signale mehrere Knoten breiten sich auf dem Bus aus
> und überlagern sich. Damit sendende Knoten eine Kollision erkennen
> können muss ein Paket mindestens so lang sein, dass es innerhalb der
> Paketlaufzeit überall im Bus ankommt. Bei einer Kollision muss ein
> Knoten warten und es später nochmal probieren (wo es vielleicht wieder
> nicht klappt). Weil das vom Zufall abhängt heißt das Verfahren
> nichtdeterministisch oder stochastisch. Blöd ist, wenn viel Verkehr ist.
> Dann gibt es immer mehr Kollisionen und die nutzbare Bandbreite sinkt
> sogar.
>
> RS485 hat weder dominant/rezessive Signale, noch können sich gesendete
> Daten überlagern. Es darf also nur einer gleichzeitig senden und deine
> Software muss sich drum kümmern. Wenn man das als Multimaster, also
> nicht Master-Slave, abhandeln will, wird das richtig kompliziert (und
> damit fehleranfällig).

Danke, das ist sehr aufschlussreich.

Noch so als Bemerkung am Rande, die nichtdeterministischen Ereignisse 
bei CSMA/CD könnten sich als (Teil-)Quelle für einen Zufallsgenerator 
anbieten, den man für die Verschlüsselung benötigt.
Das zu extrahieren würde natürlich alles komplizierter machen, weswegen 
ich das nicht wählen würde, aber erwähnen kann man es ja. :)

Wie gut der nichtdeterminismus dann wirklich ist, das müsste man 
natürlich noch näher untersuchen.
Aber wenn man schon Elektronik von Grund auf designen muss, dann gibt es 
da auch bessere Lösungen für einen Zufallsgenerator.


> Ich würde mich nicht so auf die 2 Leitungen festlegen. Eine separate
> Stromversorgung, also 4 Adern, sind nicht so viel mehr Kabel. Dafür wird
> der Rest einfacher. Auch das grüne KNX-Kabel hat 4 Adern :-)

Ja, wobei bei KNX nur 2 genutzt werden und die 2 anderen der 
Signalqualität dienen oder als Reserve für eine 24 V Stromversorgung 
genutzt werden können.

Nur zwei Adern zu verwenden hätte den Vorteil, so einen eigenen BUS und 
KNX gleichzeitig über ein KNX Kabel zu nutzen. Deswegen halte ich das 
für ein wichtiges Feature.


Auf jeden Fall Danke für dein Kommmentar, das war sehr aufschlussreich.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Nur zwei Adern zu verwenden hätte den Vorteil, so einen eigenen BUS und
> KNX gleichzeitig über ein KNX Kabel zu nutzen. Deswegen halte ich das
> für ein wichtiges Feature.

Gerade im Hinblick, wenn man nicht mehr da ist und die Ehefrau etwas 
reparieren lassen muss, könnte das günstig sein.
Da der Elektriker dann einfach die beiden KNX Adern verwenden könnte 
ohne dass der Rest der Installation groß umgebaut werden muss.

von Tilo R. (joey5337) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Tilo R. schrieb:
>> Nano schrieb:
>>> 1. leichtere Portierbarkeit auf andere µC.
>> Ein serielles Protokoll ist timing-kritisch, in Software realisiert also
>> nicht so leicht zu portieren.
>
> Oben wurden Schieberegister vorgeschlagen, könnte man mit solchen
> Hardwarebausteinen das Problem zumindest für das Senden beim Timing
> nicht in den Griff kriegen?
Ja. Man kann aber auch den UART oder das Pendant, das in jedem uC 
eingebaut ist, benutzen.


>>> 2. Baumtopologie, mit der bestehende CAN BUS fähige Chips, die den BUS
>>> in Hardware realisiert haben, vielleicht nicht klar kommen könnten.
>>
>> Mit einer Sternförmigen Verkabelung braucht man einen aktiven
>> Sternpunkt. Mit einer Baumtopologie braucht man mehrere Busanschlüsse am
>> Knoten. Es wird also in jedem Fall aufwändiger, als z.B. bei CAN oder
>> RS485, die nur einen Anschluss an ein gemeinsames Kabel brauchen.
>
> KNX kommt ohne aus, die Reflektionen am Bus durch eine Baumtopologie
> scheinen bei niedrigen Geschwindigkeiten in den Griff zu kriegen sein.
> Ansonsten könnte KNX nicht so funktionieren wie es funktioniert.
CAN kann auch jede Topologie, wenn man ihn nur langsam genug macht. Man 
muss nur garantieren, dass innerhalb einer Bitzeit, jeder jeden anderen 
sieht. KNX arbeitet mit 2400 Baud. Wenn man CAN nimmt, nimmt man oft 
100k oder mehr.

> Gibt es für CAN IC Bausteine, die mehrere CAN Schnittstellen haben, also
> sich für so etwas genau eignen und die Signale vom einen Strang in den
> nächsten senden können?
Imho nein. Es gibt Buskoppler, z.B. zur elektrischen Isolation. Ich habe 
auch schon selbst gebastelte Sternkoppler gesehen. Aber das alles hat 
zusätzliche Latenz, die die Bitzeit verlängert, weil sonst die 
Arbitrierung nicht mehr funktioniert.


>>> 3. Mehr Auswahl an µC.
>> vorausgesetzt, er kriegt das Bustiming hin. Aber eigentlich geht jeder
>> µC, schließlich gibt es externe CAN-Controller.
>
> Das ist gut zu wissen, dann könnte man so eine aktive Weiche für die
> Baumstruktur zumindest mit einem µC und mehreren CAN-Controllern lösen.
> Stellt sich nur die Frage, was die kosten.
Und dein Protokoll oberhalb CAN darf sich dann noch um so Probleme wie 
Routing kümmern...

>>> 4. Eigener BUS Standard unabhängig von CAN und somit mehr Freiheiten.
>> Ich habe mir verschiedene Hausbus-Projekte angeschaut, die CAN verwenden
>> und dabei unterschiedliche Ideen haben, wie sie den Bus nutzen.
>> Ich hatte nicht den Eindruck, dass CAN dabei limitierend ist.
>> Das Protokoll, das man über dem CAN-Bus macht ist ja immer noch frei.
>> Die einzigen Beschränkungen sind CAN-IDs von max 29 Bit und eine Payload
>> von max. 8 Byte pro Paket.
>
> Ja, gehen tut das schon.
> Bei nur 8 Byte Payload müsste man größere Datenmengen in mehrere Pakete
> aufteilen und da sind 8 Byte leider sehr limitierend, da man ja auch
> noch Platz für dieser Nummerierung dieser Teilstücke benötigt.
> Für Kapselung mit Headern und Co wird da sehr ungünstig.
> Ich wünschte, man könnte wenigstens 64 Byte als Payload übertragen, da
> könnte man schon einiges mit Anfangen, ohne die Pakete zu zerstückeln
> oder die Payload fest zu verdrahten, wie es einige gelöst haben.
Die Auslieferung auf dem CAN-Bus ist zuverlässig. Da gehen keine Pakete 
unbemerkt verloren oder werden verfälscht. CANOPEN schafft es auch, mehr 
als 8 Byte zu verschicken. (verteilt auf mehrere Pakete)

von Volle (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Ich wünschte, man könnte wenigstens 64 Byte als Payload übertragen, da
> könnte man schon einiges mit Anfangen, ohne die Pakete zu zerstückeln
> oder die Payload fest zu verdrahten, wie es einige gelöst haben.

-> CAN-FD
können aber nur wenige neue µC

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Bei nur 8 Byte Payload müsste man größere Datenmengen in mehrere Pakete
> aufteilen und da sind 8 Byte leider sehr limitierend, da man ja auch
> noch Platz für dieser Nummerierung dieser Teilstücke benötigt.

Ich habe in einer Anwendung den kompletten Inhalt eines Dataflash per 
CAN übertragen. Log-Daten einer Steuerung. Es hilft dabei, wenn man den 
CAN Treiber so betreibt, dass die Reihenfolge der Pakete erhalten 
bleibt.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tilo R. schrieb:
> Ja. Man kann aber auch den UART oder das Pendant, das in jedem uC
> eingebaut ist, benutzen.

Danke für den Tipp. Werde mir mal den WP Artikeln zum Thema UART 
durchlesen.

>> Das ist gut zu wissen, dann könnte man so eine aktive Weiche für die
>> Baumstruktur zumindest mit einem µC und mehreren CAN-Controllern lösen.
>> Stellt sich nur die Frage, was die kosten.
> Und dein Protokoll oberhalb CAN darf sich dann noch um so Probleme wie
> Routing kümmern...

Ja, wäre das Problem dabei. Auch deswegen wollte ich keine aktiven 
Komponenten um die Baumtopologie an den Verzweigungen miteinander zu 
verknüpfen.

Mit einem fest gelegten Protokoll wie CAN, dürfte das sogar noch 
schwieriger sein. Da ich mal vermute, dass der Buskoppler eine eigene 
Adresse hat und sich bei der Zieladresse im anderen Strang gar nicht 
angesprochen fühlt, dass er das jetzt weiterleiten muss.
Vor allem die 8 Byte für die Daten werden hier zum Problem, wenn man die 
Zieladresse darin einpacken wollte.
Da braucht man also ganz andere Lösungen.

Danke für deine Antwort.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Volle schrieb:
> Nano schrieb:
>> Ich wünschte, man könnte wenigstens 64 Byte als Payload übertragen, da
>> könnte man schon einiges mit Anfangen, ohne die Pakete zu zerstückeln
>> oder die Payload fest zu verdrahten, wie es einige gelöst haben.
>
> -> CAN-FD
> können aber nur wenige neue µC

Interessant, ich dachte CAN-FD bezieht sich nur auf eine flexiblere 
Busgeschwindigkeit.
Wenn man aber auch die Größe der Pakete verändern kann, dann wäre das 
super.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Ich habe in einer Anwendung den kompletten Inhalt eines Dataflash per
> CAN übertragen. Log-Daten einer Steuerung. Es hilft dabei, wenn man den
> CAN Treiber so betreibt, dass die Reihenfolge der Pakete erhalten
> bleibt.

Gut, wenn die Pakete nicht verloren gehen und immer in der richtigen 
Reihenfolge zugestellt werden, dann ist das natürlich kein Problem.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Gut, wenn die Pakete nicht verloren gehen und immer in der richtigen
> Reihenfolge zugestellt werden, dann ist das natürlich kein Problem.

Zig Pakete werden zu einem Bündel mit CRC geschnallt, und wenn da was 
nicht stimmt, fragt man eben das ganze Bündel nochmal an. Wenn fehlende 
oder in verkehrter Reihenfolge zugestellte Pakete selten genug sind, ist 
das kein Problem.

: Bearbeitet durch User
von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Nano schrieb:
>> Gut, wenn die Pakete nicht verloren gehen und immer in der richtigen
>> Reihenfolge zugestellt werden, dann ist das natürlich kein Problem.
>
> Zig Pakete werden zu einem Bündel mit CRC geschnallt, und wenn da was
> nicht stimmt, fragt man eben das ganze Bündel nochmal an. Wenn fehlende
> oder in verkehrter Reihenfolge zugestellte Pakete selten genug sind, ist
> das kein Problem.

Das muss auch in Ausnahmefällen funktionieren.
Wie stelle ich die aber fest, wenn ich mich allein auf CAN verlasse und 
daher keine Sequenznummer mitschicke?
Das wäre ja nur möglich, wenn die Länge aller Payloads der vielen Pakete 
nicht stimmt und damit da nichts anderes kommt, das diese Länge 
verfälscht, müsste man noch sicherstellen, dass da nicht noch weiteres 
nachgeschickt wird.
Ja, gehen tut das sicherlich irgendwie, macht das Protokoll aber auch 
aufwendiger.

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Nano schrieb:
> Wie stelle ich die aber fest, wenn ich mich allein auf CAN verlasse und
> daher keine Sequenznummer mitschicke?

Indem du dich nicht allein auf CAN verlässt.

Stelle es dir ungefähr so vor:
  LOG-ANFANG: Position im Log
  LOG-DATEN
  LOG-DATEN
  ...
  LOG-DATEN
  LOG-ENDE: 40 Pakete + CRC über die gesamten Daten

Wenn mit dem Ende alle Pakete mit richtiger Anzahl und insgesamt 
korrekter CRC in endlicher Zeit reinkommen, dann stimmts, sonst nicht. 
Das geht nur in die Hose, wenn du es schaffst, mit Fehlern oder 
Verdrehern die gleiche Anzahl und CRC zu erzeugen. Wenn dabei aufgrund 
von Fehlern trotz Retries nichts mehr durchkommt, hast du ein anderes 
Problem.

Ich habs ähnlich gemacht wie oben irgendwo verlinkt, und in die 29-Bit 
ID bei sämtlichen Paketen im Netz Quelle, Ziel und Typ (z.B. obiges 
LOG-ENDE) reincodiert. Etwas inspiriert vom mir vertrauteren Ethernet- 
oder IP-Networking, da ich vom automotiven CAN-Umfeld völlig unbeleckt 
bin.

> Ja, gehen tut das sicherlich irgendwie, macht das Protokoll aber auch
> aufwendiger.

Der Aufwand dafür war sehr überschaubar. Das mit der CRC habe ich hier 
hinzu gefügt, um es allgemeiner zu halten, ist aber kaum Zusatzaufwand. 
War damals aufgrund des einfachen CAN-Umfelds und der unkritischen Daten 
nicht nötig.

: Bearbeitet durch User
von Tilo R. (joey5337) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Das ganze Gerede über Fehlerkorrektur etc. ist natürlich alles richtig.

Man darf aber nicht vergessen, dass CAN selbst schon auf jedes einzelne 
Paket eine 15-bit Checksumme macht die von allen Busknoten kontrolliert 
wird. Fehler werden in fast allen Fällen, auch bei richtig vielen 
Störungen, sicher erkannt. CAN ist diesbezüglich Rock Solid.

Wer es nicht glaubt, hier ist ein Paper dazu:
http://www.jcho.de/jc/Pubs/cia-94.pdf

Die wichtigen Kurven sind auf Seite 8.
Man beachte die X-Achse mit den Bitfehlerraten, die gehen dort von 
0,0001 bis 0,1.
0,001 heißt, jedes Tausendste Bit geht auf der Leitung kaputt. Ich weiß 
nicht welche Kabel verbaut werden sollen oder ob im Wohnzimmer ein 
Elektroschweißroboter steht. Aber in allen vernünftigen Fällen wird 
schon die Roh-Bitfehlerrate um Größenordnungen besser sein.

Aber selbst wenn jedes tausendste Bit kippt, ist die Rate unerkannter 
Bitfehler in deiner Payload in der Größenordnung 1e-10.
Du musst ein Gigabyte Daten verschicken bis du im Schnitt ein falsches 
Bit siehst. Mit 100kBit, unter Volllast dauert das Wochen.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Tilo R. schrieb:
> Man darf aber nicht vergessen, dass CAN selbst schon auf jedes einzelne
> Paket eine 15-bit Checksumme macht die von allen Busknoten kontrolliert
> wird.

Falls du mich meinst: Die erwähnte CRC dient nur zur Erkennung, ob 
Pakete in fehlender oder in falscher Reihenfolge eintrudeln. Braucht 
weniger Platz als eine Sequenznummer in jedem Paket eines Bündels und 
steht i.A. als generische Lib-Funktion fertig zur Verfügung.

von Tilo R. (joey5337) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
@A. K.
jaja, das habe ich alles verstanden und finde ich auch gut.
Ich wollte nur sagen: der Bus drunter ist nicht soo schlecht, dass man 
da groß Angst haben muss.

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Yep. Und wenn man dann doch eine hohe Verlustrate hat, sollte man 
zunächst nach der Ursache davon suchen, nicht gleich per Software 
flicken.

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.

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