Irgendein Bug bekannt beim Adressempfang?

[tuxedo]

Die Sortierung ist richtig. Sie liefert aber den Index zurück, nicht den Wert!

*BrettVormkopf* Richtig... Ich schau weiter nach "Problemen".

[tuxedo]

Hab den Sortier-Algo weiter ausprobiert, und er funktioniert nicht komplett korrekt. hat man von Vornherein Duplikate (z.B. durch mehr als ein unbenutztes KO 8das dann keine korrekte GA hat, hier in diesem Beispiel mit 0x0000), gerät es etwas durcheinander. Hier die Ausgabe meines Testprogramms:

Before sorting:
        ComObj Index [0] = GA 0x0001
        ComObj Index [1] = GA 0x0004
        ComObj Index [2] = GA 0x0003
        ComObj Index [3] = GA 0x0000
        ComObj Index [4] = GA 0x0005
        ComObj Index [5] = GA 0x0002
        ComObj Index [6] = GA 0x0000
Resulting Order Index Table:
        On OrderIndex [0] we have ComObj Index 6
        On OrderIndex [1] we have ComObj Index 0
        On OrderIndex [2] we have ComObj Index 5
        On OrderIndex [3] we have ComObj Index 2
        On OrderIndex [4] we have ComObj Index 1
        On OrderIndex [5] we have ComObj Index 4
        On OrderIndex [6] we have ComObj Index 0
Resulting GA order:
        OrderIndex[0] = GA 0x0000
        OrderIndex[1] = GA 0x0001
        OrderIndex[2] = GA 0x0002
        OrderIndex[3] = GA 0x0003
        OrderIndex[4] = GA 0x0004
        OrderIndex[5] = GA 0x0005
        OrderIndex[6] = GA 0x0001

[andi11]

also ich habe mal etwas gesucht:
Der Sortieralgorithmus löscht mir nicht die entsprechende GA raus (wenn gleich auch das mit dem zugriff auf das Sortierungsarray etwas aufwendig ist )
Mir bricht in der Funktion IsAddressAssigned die Zeile for (i = 4; _assignedComObjectsNb >> i; i++) divisionCounter++; das Genick.
Wenn ich die auskommentiere und nur divisionCounter=1; mache geht es.
Ist vielleicht daher der Fehler noch nicht weiter aufgetreten, da die "KOs Monster" erst langsam kommen?

[tuxedo]

wenn die betroffene GA aber an der "falschen" Stelle bzw. falschen reihenfolge sitzt, wird sie von IsAddressAssigned nicht gefunden...

WEIL IsAddressAssigned bedient sich eines Tricks um nicht jede GA in der Liste anschauen und vergleichen zu müssen. Das setzt aber eine korrekte Sortierung voraus...

[Eugenius]

Wie viele KOs hast du denn?

[tuxedo]

Bei mir sind es >70

[andi11]

66 KOs vorhanden, 44 haben eine zugewiesene GA.

[tuxedo]

Denke man sieht das am besten, wenn man sich das mal vernünftig auf der Konsole ausgeben lässt.

Was natürlich auch noch sein kann, und das geht in Richtung "IsAddressAssigned"-Implementierungsproblem: Das schnelle suchen in der Liste geht schief WEIL es Duplikate gibt (nämlich die in-aktiven KOs die alle 0x0000 oder 0xffff haben, weiß das auswendig nicht mehr so genau).

[andi11]

die Sortierung war richtig bei mir. Ich kann allerdings nur mit USART "debuggen". Aber nicht benutzte KOs werden mit einer 0 am Anfang zusammengefasst.

[tuxedo]

Fassen wir nochmal zusammen:

1) Duplikate entfernen ist "pöhse", weil wir per Definition vor dem Sortieren schon Duplikate haben können und die auch brauchen
2) Der aktuelle Sortier-Algo ist mangelhaft, kann aber durchaus auch korrekte Ergebnisse liefern (kommt auf die Konstellation der GAs an)
3) Das "schnelle Suchen" kann, wenn es Duplikate gibt, durchaus dazu führen, dass eine GA nicht gefunden wird

Wenn es mit "Wenn ich die auskommentiere und nur divisionCounter=1; mache geht es." zuverlässig klappt, dann ist das die beste Workaround-Lösung.

Wie gesagt: In beta5 muss ich die Sortierung überarbeiten, und das "schnelle Suchen" muss ich eh komplett über den Haufen werfen und re-implementieren, da wir nicht nur ein, sondern mehrere Suchergebnisse haben können (eine GA die von mehreren KOs genutzt wird, Beispiel "Zentral-Stockwerk-AUS"-GA bei einem Schaltaktor auf allen Kanälen für das betroffene Stockwerk).