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?
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 meld dich mal wenn das ganze läuft! mfg Gast
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
_Gast schrieb: > http://www.google.de/url?q=https://www.nxp.com/docs/en/reference-manual/BCANPSV2.pdf&sa=U&ved=2ahUKEwi6ubT6vLPnAhUM0qYKHcy9BpgQFjADegQICRAB&usg=AOvVaw27Tdd6C-1D8DQqLdL93Lac Google muss doch nicht alles wissen ;-( https://www.nxp.com/docs/en/reference-manual/BCANPSV2.pdf
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.
_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. :)
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.
Vergess aber nicht den Link auf das Github-Repository mit der funktionsfähigen Software zu posten.
:
Bearbeitet durch User
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
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.
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.
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?
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.
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.
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.
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)
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.
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.
Denk an die Verschlüsselung.. Immerhin ist genau das der Punkt den DU ja so großspurig bemängelst insb. An KNX.
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.
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.
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.
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 :-)
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.
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.
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)
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
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.
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.
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.
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.
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
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.
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
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.
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.
@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.
Yep. Und wenn man dann doch eine hohe Verlustrate hat, sollte man zunächst nach der Ursache davon suchen, nicht gleich per Software flicken.
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.