DMX-Gateway

[Eugenius]

für die Performance könnte sortieren nach GA im Vorfeld helfen, wenn GA>SollGA dann break;

Die Sortierung gibt es schon von Frank...

[tuxedo]

Sortiert wird bereits jetzt.

[tuxedo]

Ach ja, der nächste Knackpunkt:

Die ganzen KOs müssen im RAM liegen damit der Vergleich schnell von statten geht. Bei 85 KOs sind das mind. 255 bytes. Being 32u4 mit seinen 2,5k RAM macht das bereits 10% aus.
Mit zunehmender Anzahl KOs wird das natürlich schlimmer. Und es ist ja nicht so, dass wir allein die KOs im RAM liegen haben. Wer 160KOs braucht, der hat noch ne Menge anderen Kram im RAM.

Man kann jetzt argumentieren dass der 32u4 für sowas dann eben nicht mehr geeignet ist. Aber die Frage ist dann eben (bevor man implementierungstechnisch mehrgleisig fährt), ob man nicht den Support für 32u4 einstellt?! Aber dann verliert man die ganz einfachen Projekte und Lösungen...

Ihr seht: das ist alles nicht ganz so einfach...

[Eugenius]

Man kann es auch anders sehen: die, die 160KOs brauchen, wissen was die tun, weil wahrscheinlich auch der Sketch so gros ist, dass nicht mehr in den 328p/32u4 reinpasst. D.h. die sollen auf die "größere" Chips, z.B. SAMD21G18A ausweichen...
Ob man die Sperre direkt einbauen soll?! ich glaube nicht. Arduino rechnet ja vor dem komplieren, wie viel man Speicher braucht. Ich hoffe es wird richtig gerechnet

[andi11]

auch wenn ich den halben Offtopic damit unterstütze:
Ich bin hier für Mehrgleißigkeit.
Die Arduino IDE wird da schon meckern wenn der Ram nicht reicht. Oder entsprechend #if zum limitieren. Sonst wird man einfache Bastelprojekte und KNX Geräte mit vielen Möglichkeiten nie unter einen Hut bringen. Ist der vergleich von max 2byte pro GA so performance relevant?

[tuxedo]

die, die 160KOs brauchen, wissen was die tun,

Erfahrungsgemäß: Sie sollten.... tun es aber nicht immer. Also kann man darauf nicht vertrauen.

Arduino rechnet ja vor dem komplieren, wie viel man Speicher braucht.

Die Arduino IDE wird da schon meckern wenn der Ram nicht reicht.

Das funktioniert zuverlässig für die Sketch-Größe, aber für den RAM Bedarf ist das "eine Schätzung".

Vielerlei Dinge werden dynamisch zur Laufzeit angelegt. Das kann der Compiler eben nicht wissen, und auch nicht mit einberechnen. Und wenn der RAM dann doch mal knapp wird (was gerade bei den kleinen µC schnell der Fall sein kann), dann gibt's keine sprechende Fehlermeldung, sondern ein unvorhersehbares Verhalten. Hab schon ganze Nachmittage damit verbraucht den Fehler im Code zu suchen, bis ich rausgefunden hab, dass der RAM zu voll war...

Ist der vergleich von max 2byte pro GA so performance relevant?

Das kann man so pauschal nicht sagen.

Aber lass uns das mal schnell überschlagen:

Man muss im Idealfall alle 400µs Task() aufrufen, damit man kein Byte eines Telegramms verpasst.

Hab jetzt grad nicht auswendig im Kopf wieviele Bytes "protokolloverhead" im KNX Protokoll vorgesehen sind, aber gehen wir doch mal 10 bytes für ein einfaches Telegramm aus. Das macht dann rund 4ms pro Telegramm.

Also müsste man alle 4 Millisekunden, neben dem ganzen Code in task(), die GA des gerade empfangenen Telegramms gegen sagen wir 160 GAs (die in 160 KOs stecken) abgleichen.
Auch wenn man mit sortierung und geschickten Algorithmen Zeit sparen kann, man muss hier vom Worst-Case ausgehen. Denn wir wollen ja kein einziges Telegramm verlieren.

Von den 4ms die wir in task() verbraten können (dann hat unser eigentlicher Sketch aber noch nichts gemacht...), bleiben uns sicherlich nicht mehr als 2-3ms für den GA Abgleich. Rechnen wir also mit 3ms weiter.

Bei der Worst-Case-Rechnung wären somit bei 160 vergleichen 18,75µs Zeit pro Vergleich.

Klingt viel, ist auch viel. Aber denk dran dass wir im eigentlichen Sketch noch 0 Zeit verbraten haben. Und schon wird's etwas enger...


Was ich damit sagen will: Man kann das Thema nicht einfach klein reden. Es spielen viele Faktoren mit rein. Buslast, Telegrammgröße, die tatsächliche GA (kleiner wert vs. großer wert), ...

Ein weiterer Punkt der (mal wieder) vergessen wurde: Die Anzahl GAs die ein KO haben kann. Bis dato ist das fest auf 1...

Wenn man nun 160 KOs hat, dann wären das max. 160 GAs (nach bisherigem Stand). Beta5 wird aber mehr als eine GA pro KO können.

D.h. im wirklichen Worst-Case, hast du nicht nur 160GAs zu vergleichen, sondern ein vielfaches davon...

Und wo legt man hier das Limit fest? Wieviele GAs darf es geben?

Ich kann ja nicht einfach sagen:

max. 255 KOs und max. 255 GAs, und gleichzeitig darf ein KO mehrere GAs haben. Das beißt sich.

Wo ziehst du da dann die Grenze?

Alles in allem: Das Problem lässt sich nicht mit 5 Sätzen und 3 Posts lösen. Ich brüte da schon deutlich länger darüber...

Ich denke wir hören an dieser Stelle mit dem Offtopic auf. Das Thema wurde schon in einem anderen Thread diskutiert (suche ...) und kann dort gerne fortgeführt werden.

[jentz1986]

Ich kram den hier mal wieder raus. Wie schaut es denn bei euch anderen aus: Habt ihr etwas erreicht?

Mein Ansatz für ein ähnliches Ding ist aktuell:

Haupt und Mittelgruppe ist definiert, die eigentliche Gruppenadresse bleibt dann ein Byte und das ist einfach die DMX-Adresse, auf die dann das eine Byte Wert geschrieben wird, fertig. Allerdings will ich nur ein Simpel-Gateway bauen: 255x Byte rein -> DMX raus. Eher sogar weniger Kanäle, da mir grundsätzlich wahrscheinlich 32 sogar reichen.
Ich habe allerdings eine globale "Rampe" eingestellt = Soft-Dimm. Bei jedem Schritt nach x millisekunden die nächste Stufe angesprungen wird, bis der KNX-definierte Wert erreicht ist.
Einen "smarten" Effekt will ich noch einbauen: Je drei Kanäle ein Bit Rückmeldeobjekt für das Netzteil.
Szenen ließen sich natürlich auch einbauen, wären aber hart programmiert, und ich brauche sie nicht.

Damit habe ich noch keine Animations-Szenen a la Feuer gebaut aber das brauche ich eigentlich auch nicht.

Das einzige ist: Das geht mit Konnekting so nicht, sondern man muss die KNX-Libs nehmen, und sie ändern, dass sie nur nach Haupt- und Mittelgruppe filtern und alles danach einfach akzeptieren. Geht, aber KNX-schön ist anders.

Stand bei mir ist:
DMX Seite ist komplett umgesetzt, inkl. Galvanischer Trennung. Ich nutze einen Pro Micro als DMX Generator, der PJON-Telegramme anderweitig empfängt. Mein KNX<->PJON fehlt aber noch, weil der genau das Problem mit der großen Menge an GAs hätte und ich noch nicht dahinter gekommen bin, wie der Vergleich schneller sein kann. Prototypenhaft habe ich mal eine Matrix gebaut, die einfach 65535 (256 x 256) Binärwerte im Speicher ablegt und diese nur über die Adresse prüft. Damit ist der Speicher eines Mega aber schon voll. Der Due kann da schon mehr... Aber den habe ich gerade mal als Busmonitor aktivieren können. Dauert noch.