Grundsätzlich sehe ich persönlich Bedarf für mehr als 256 CommObj. Ja, dafür braucht man entsprechende µC. Die gibts aber. SAMD51, aber ich denke auch der SAMD21 packt das.
Ja, die Verwaltung mit der Suite wird anspruchsvoll.
=> oft braucht man aber eh nur einen Bruchteil der vorhandenen KO. Kanal 1 wird nur geschalten, Kanal 2 wird gedimmt, Kanal 3 ist RGB ...
Trotzdem muss ich für jeden Kanal alle KOs "anbieten", auch wenn dann nur ein Bruchteil verwendet wird.
Nein, die Codekomplexität eines solchen Gerätes wird nicht zwangsweise komplexer. Ob ich 10 oder 20 Instanzen einer Kanalklasse habe, spielt für die Codekomplexität keine Rolle.
Ich habe mir daher ein wenig Gedanken gemacht, wie man das realisieren könnte und dabei kann ich denke ich zeigen, dass auch das Argument: "braucht viel mehr Speicher, weil die IDs doppelt so groß werden" entkräften.
Nun folgen ein paar Berechnung. Der IST-Stand bezieht sich auf: https://wiki.konnekting.de/index.php..._Memory_Layout
Speicherbedarf SYSTEM_TYPE_DEFAULT (256/256/256):
Address Table: 256x2byte = 512byte
CommObjTable: 256x1byte = 256byte
AssocTable: 256x2byte = 512byte
=> 1,25 kbyte
wenn man jetzt an Geräte mit mehr als 256 commobjekten und damit auch GA denkt, muss die ID größer werden. Für eine ideale Lesbarkeit von Code und Speicher respektiere ich hier mal die Bytegrenzen.
Berechnung auf 256 co/ga/assoc zur Vergleichbarkeit
Address Table: 256x2byte = 512byte (bleibt gleich, adressen bleiben gleich groß)
CommObjTable: 256x1byte = 256byte (bleibt gleich, flags bleiben gleich groß)
AssocTable: 256x4byte = 1024byte
=> 1,75 kbyte (512byte mehr)
hierbei fällt aber auf, dass die AddressTable redundant wird. Denn sobald die ID 2byte groß ist, kann ich auch die Adresse direkt in die assoc-table schreiben und die address table entfällt:
Address Table: 0byte
CommObjTable: 256x1byte = 256byte (bleibt gleich, flags bleiben gleich groß)
AssocTable: 256x4byte = 1024byte
=> 1,25 kbyte => kein byte größer
Jetzt mal den Simpletype betrachtet IST Stand:
Address Table: 128x2byte = 256byte
CommObjTable: 128x1byte = 128byte
AssocTable: 128x2byte = 256byte
=> 768byte
oder mit entfall der addresstable (mein Vorschlag):
Address Table: 0byte
CommObjTable: 128x1byte = 128byte
AssocTable: 128x4byte = 512byte
=> 768byte
Fazit: wenn man zugunsten einer größeren AssocTable auf die AddressTable verzichtet, vergrößert sich der Speicherbedarf für Type 0x00 und 0x01 nicht.
Jedoch ermöglicht es ohne größere strukturelle Eingriffe eine Vergrößerung auf bis zu 65k GAs/CO/Assocs (auch wenn vielleicht nur 512-1024 tatsächlich sinnvoll sin).
Sorry dass mit das jetzt erst auffällt. Ich kann verstehen wenn ein Umbau nicht mehr erwünscht ist. Aber ich denke es würde uns fitter für die Zukunft machen.
Ich helfe auch gerne Tatkräftig bei der Umsetzung mit.
Ja, die Verwaltung mit der Suite wird anspruchsvoll.
=> oft braucht man aber eh nur einen Bruchteil der vorhandenen KO. Kanal 1 wird nur geschalten, Kanal 2 wird gedimmt, Kanal 3 ist RGB ...
Trotzdem muss ich für jeden Kanal alle KOs "anbieten", auch wenn dann nur ein Bruchteil verwendet wird.
Nein, die Codekomplexität eines solchen Gerätes wird nicht zwangsweise komplexer. Ob ich 10 oder 20 Instanzen einer Kanalklasse habe, spielt für die Codekomplexität keine Rolle.
Ich habe mir daher ein wenig Gedanken gemacht, wie man das realisieren könnte und dabei kann ich denke ich zeigen, dass auch das Argument: "braucht viel mehr Speicher, weil die IDs doppelt so groß werden" entkräften.
Nun folgen ein paar Berechnung. Der IST-Stand bezieht sich auf: https://wiki.konnekting.de/index.php..._Memory_Layout
Speicherbedarf SYSTEM_TYPE_DEFAULT (256/256/256):
Address Table: 256x2byte = 512byte
CommObjTable: 256x1byte = 256byte
AssocTable: 256x2byte = 512byte
=> 1,25 kbyte
wenn man jetzt an Geräte mit mehr als 256 commobjekten und damit auch GA denkt, muss die ID größer werden. Für eine ideale Lesbarkeit von Code und Speicher respektiere ich hier mal die Bytegrenzen.
Berechnung auf 256 co/ga/assoc zur Vergleichbarkeit
Address Table: 256x2byte = 512byte (bleibt gleich, adressen bleiben gleich groß)
CommObjTable: 256x1byte = 256byte (bleibt gleich, flags bleiben gleich groß)
AssocTable: 256x4byte = 1024byte
=> 1,75 kbyte (512byte mehr)
hierbei fällt aber auf, dass die AddressTable redundant wird. Denn sobald die ID 2byte groß ist, kann ich auch die Adresse direkt in die assoc-table schreiben und die address table entfällt:
Address Table: 0byte
CommObjTable: 256x1byte = 256byte (bleibt gleich, flags bleiben gleich groß)
AssocTable: 256x4byte = 1024byte
=> 1,25 kbyte => kein byte größer
Jetzt mal den Simpletype betrachtet IST Stand:
Address Table: 128x2byte = 256byte
CommObjTable: 128x1byte = 128byte
AssocTable: 128x2byte = 256byte
=> 768byte
oder mit entfall der addresstable (mein Vorschlag):
Address Table: 0byte
CommObjTable: 128x1byte = 128byte
AssocTable: 128x4byte = 512byte
=> 768byte
Fazit: wenn man zugunsten einer größeren AssocTable auf die AddressTable verzichtet, vergrößert sich der Speicherbedarf für Type 0x00 und 0x01 nicht.
Jedoch ermöglicht es ohne größere strukturelle Eingriffe eine Vergrößerung auf bis zu 65k GAs/CO/Assocs (auch wenn vielleicht nur 512-1024 tatsächlich sinnvoll sin).
Sorry dass mit das jetzt erst auffällt. Ich kann verstehen wenn ein Umbau nicht mehr erwünscht ist. Aber ich denke es würde uns fitter für die Zukunft machen.
Ich helfe auch gerne Tatkräftig bei der Umsetzung mit.
