Entwicklungsblog Beta5/Final 1.0.0

[tuxedo]

Hallo,

beta4a ist ja raus und es geht "dem Ende" zu. Ende heißt so viel wie: Das Ding muss stabil werden.

Für beta5 gibt es einige große Änderungen. Wer sich dazu informieren will schaut bei ins im Github vorbei. Dort ist alles aufgelistet.

Damit ihr aber nicht müde werdet und der "heißhunger" auf "Mehr" nicht versiegt, werde ich hier immer wieder kleine fetzen News posten.

Heute mach ich den Anfang mit ein wenig Neuerungen in der Suite:

Die finale Version soll mit mehreren GAs pro KO umgehen können. In diesem Zug wird das UI ein wenig überarbeitet:

Klickt man nun doppelt in die Zelle wo die GA rein gehören kommt so ein Fenster:

Bildschirmfoto vom 2018-06-08 14-58-12.png
Man kann entweder die GA selbst eintippen und auf "Verbinden" klicken um die GA mit dem zuvor gewählten KO zu verbinden, oder man klickt auf "..." und kommt zu dieser Ansicht:
Bildschirmfoto vom 2018-06-08 14-58-31.png
Das ist nun gaaaaanz neu: Befindet sich im Projektverzeichnis ein ETS-exportiestes Projekt (.knxproj), dann wird das Projekt eingelesen und die GAs mit ihren Namen hier aufgelistet. Man kann sich einen Rauspicken und auf Select klicken.
Dann landet man wieder in dieser Ansicht:
Bildschirmfoto vom 2018-06-08 14-59-00.png
Leider war ich hier zu schnell beim Screenshot machen. Direkt nach dem "select" würde die GA nun im Textfeld stehen und man kann sich dann mit "Verbinden" nach unten in die Liste packen, wie auf dem Screenshot zu sehen.

Klickt man dann auf "fertig" sieht das ganze so aus:
Bildschirmfoto vom 2018-06-08 14-59-10.png

Das ist schon recht fein. Aber es kommt noch besser. Wer sowieso schon auswendig seine GA-Namen kennt (und diese wie ich im obigen Beispiel mit einer durchgehenden Namens-Konvention angelegt hat), kann (und das ist jetzt noch nicht fertig sondern ein Prototyp) einfach anfangen zu tippen (im Textfeld des ersten Screenshots) und bekommt direkt darunter eine "Autovervollständigung" angezeigt. Wenn das gesuchte schon in der Liste ist, kann man einfach mit den Pfeiltasten nach unten gehen und beim passenden Eintrag "Enter" drücken, oder eben mit der Maus klicken. Statt des Namens erscheint dann die GA im Textfeld und man kann mit einem weiteren klick bzw. "Enter" (der Fokus ist dann schon auf den "Verbinden" Knopf weitergerückt) zur GA-Liste für dieses KO übernehmen.
Bildschirmfoto vom 2018-06-08 14-52-55.png
(Prototyp!)

Damit lässt sich dann in Zukunft zum einen die GAs aus der ETS nutzen, und zum anderen ist man bei der Eingabe der GAs sehr schnell.

So, das war's für's erste.

Stay tuned for more ...



P.S. Wie gefällt euch das dunkle Farbschema "Darcula" (nein, das ist kein schreibfehler, das schreibt sich wirklich so)? Hab ich mal zum testen drin...

[Masifi]

Das finde ich schon einmal ziemlich cool :-)

Vorallem der ETS Import, das hat mich früher echt immer genervt, dass man immer in der ETS schauen musste wie die GA genau wieder war.

[henfri]

Klasse!

[tuxedo]

Der Prototyp ist nun soweit fertig und voll funktional.

Der ETS Import geht übrigens auch mit ETS5.

[tuxedo]

Als nächstes wird die Anpassung des KONNEKTING-Kommunikationsprotokolls hin zum Arduino folgen. Die Programmierung läuft intern dann komplett anders ab und ist hoffentlich auch performanter (=schneller).
Auf Arduino Seite folgt dann die Speicherung der Daten in "Tabellen" im EEPROM/Flash, sowie das lesen der Daten aus der neuen Datenstruktur im EEPROM/Flash.
Im Anschluss muss dann das Feature "mehrere GA pro KO" umgesetzt werden. Wenn das soweit ist (gehört leider alles zusammen), können wir euch wieder ein bisschen testen lassen. Dann folgen die Features auf Seite der Lib sowie der Suite die ergänzend dazu kommen.

[Sonnengruesser]

Hallo und hört sich gut an - mehrere GA pro KO.
Wie sehr müssen wir denn unsere Sketches anpassen? Ich vermute mal die Idee ist: gar nicht. Hängt natürlich von einer sauberen Anbindung unserer sketches ab...
Wie sieht's mit dem Speicherbedarf aus? Gibt's dazu schon Info?

[tuxedo]

Ganz ohne anpassung wird es nicht gehen. Wir erweitern die Anzahl der möglichen Parameter auf >256. Damit muss zumindest einmal die Header-Datei aus der kdevice.xml neu generiert werden.

Ansonsten wird sich auf Seiten des Sketches nicht viel ändern. Wir versuchen hier die API Änderung wo es nur geht auf 0 zu halten.

Bzgl. Speicherbedarf: Ja, da wird etwas "mehr" gebraucht. Ein SAMD hat aber ausreichend Speicher. 328 und 32u4 haben nicht so viel, weswegen hier verschiedene Modes eingeführt werden. Der 328 und 32u4 wird dann mit einem "Light" Mode gefahren, was den Speicherbedarf reduziert, aber auch nicht die Menge an KOs und Parameter ermöglicht. Anders geht's leider nicht. Der 32u4 mit seinen 2,5kb RAM ist einfach nicht mehr Zeitgemäß. Vor allem wenn man bedenkt dass der SAMD hier 32kbyte liefert.

Genaue Zahlen folgen noch.

Gruß
Alex

[Sonnengruesser]

Danke für die Info.
Solche Sachen wie Header-file sind ja kein Problem. Wenn jetzt die EEPROM-Verwaltung oder die Zugriffe auf die ankommenden Daten verändert würden, dann wärs nicht mehr so nett.
"Light mode" klingt gut - ich denke grade für den Einstieg in das Thema sind die kleinen schon sinnvoll. Vor allem wenn man aus der Arduino-Bastelei kommt. Und wenn ich nur einen einfachen Sonderfall brauche (2 Relais schalten und einen I2C Sensor einlesen), dann nehm ich dafür keinen SAMD wenns nicht sein muss.
VG
Christoph

[tuxedo]

Der Zugriff auf KOs bleibt gleich. D.h. die ganzen read..() funktionen ändern sich an der Stelle nicht.

Was sich ändert ist die interne Speicherung der Parameter und GA<->KO Zuordnung im Speicher (EEPROM/Flash). Hier wird prinzipbedingt mehr Speicher notwendig werden. Deshalb der "Light Mode" der nicht ganz so viele GAs und Parameter erlaubt, damit eben im EEPROM/Flash noch Platz für Daten aus dem Sketch übrig bleibt.

Vor allem wenn man aus der Arduino-Bastelei kommt. Und wenn ich nur einen einfachen Sonderfall brauche (2 Relais schalten und einen I2C Sensor einlesen), dann nehm ich dafür keinen SAMD wenns nicht sein muss.

Der einzige Grund den ich persönlich hier gelten lasse ist der Preis: Ein 32u4 ist nach wie vor günstiger als ein SAMD. Aber die Preise fallen ständig und STM32-Support kommt ja nun mittlerweile auch Stück für Stück (quasi selbe Performance wie SAMD, aber günstiger).

Davon abgesehen wäre die Argumentation gleichzusetzen mit:

"Ich installiere ja auf meinem PC ja nur ein kleines Programm, dann reicht auch ein 32bit Betriebssystem".

Wenn das 64bit System aber keine Nachteile für das Programm mit sich bringt: Warum will man dann noch auf ein altes Pferd setzen (wenn es nicht gerade viel günstiger ist und an jeder Ecke zu bekommen ist).

Ich würde gerne langfristig mehr auf Modularität setzen. Eugen hat mit dem MI schon einen gewissen Grundstein gelegt. Für die Hutschiene haben wir ja auch schon ein gut modulares Schema.

Wenn wir das noch auf den LowCost "ich bastel mal eben schnell was zusammen" Bereich ausweiten können wäre das perfekt, denke ich. Sowas wie ein Arduino mit integriertem KNX wäre fein. @Matsifi hat da ja schon mit dem KNX Shield einen Anfang gemacht. Richtig cool fäden ich es aber, wenn wir einen Arduino mit KNX fertigen könnten, der von der Größe her nicht größer als ein ProMicro und eine SiemensBCU ist und bei dem man nicht immer eine komplizierte "Sammelbestellung die dann von uns noch (in teilen) handgefertigt werden muss" ausrufen muss (eine einfache und unkomplizierte Bestellung bis Lieferung wäre fein), und wo der Preis stimmt... Mal schauen was die Zukunft bringt...

Ach, ich schweife wieder ab. Wir sind hier ja im Beta5 blog ...

[Lapheus]

Wieviele Parameter sind den aktuell und zukünftig in der Light Version beim 32u4 möglich?
Konkretes Beispiel: ein Leonardo/Pro Micro mit 1Wire-Shield und ca 30 bis 40 Temperatursensoren > somit 60 bis 80 Gruppenadressen.

[Eugenius]

Ich stimme Alex vollkommen zu, warum soll man auf den alten (10-15 Jahre) Chip sich festlegen, wenn die Alternativen nicht viel mehr kosten, dafür aber viel leistungsfähiger sind:
STM32: bei Aliexpress/eBay für ca 1,60Euro zu bekommen, bei Amazon für ca 4 Euro:
https://www.amazon.de/Gazechimp-Mini...dp/B01N4E8RTE/
SAMD21:
https://www.ebay.de/itm/WeMos-D1-SAM...8AAOSwcgNZCwCK

Und ja, für eine blinkende LED braucht man keinen 32-bit Prozessor, da frage ich mich aber ob es dann auch eine KNX Anbindung sein soll? Man braucht ja kein Porsche, mit dem Trabi kommt man auch am Ziel an
Und im Endeffekt sprechen wir von wie vielen Euros? 3 vs 10 ?! Also 1-2 Bier weniger im Biergraten trinken, dafür sich weniger Gedanken um RAM und CPU-Zyklen machen. Programmieren tut man die genauso einfach wie die 328p und 32u4 Prozessoren (außer man steigt in die Register-Welt ein, wobei an der Stelle wieder die Anforderungen so hoch sind, dass lieber gleich ein stärkerer Prozessor viel Ärger sparen kann).
Bei den schon vorhanden Dingen ist es eine Sache, aber wenn man eh neu kaufen muss, dann lieber gleich 32-bit.

Aber jetzt zurück zum Thema: es werden immer wieder neue Features gefordert (z.B. mehr KOs) das braucht halt RAM, ROM und auch Rechenleistung...

[Eugenius]

Wieviele Parameter sind den aktuell und zukünftig in der Light Version beim 32u4 möglich?
Konkretes Beispiel: ein Leonardo/Pro Micro mit 1Wire-Shield und ca 30 bis 40 Temperatursensoren > somit 60 bis 80 Gruppenadressen.

60-80 Adressen soll in diesem Fall nicht das Problem sein, sondern RAM und ROM für den Sketch...
Läuft es schon? viel RAM/ROM hast du übrig?
Warum nicht gleich sowas kaufen und einsetzen?: https://www.ebay.de/itm/SAMD21-M0-32...0/152663167405

[Lapheus]

Läuft noch nicht, 1-Wire Shield Hardware ist auf dem Weg zu mir.
Wollte es mit dem ProMicro machen, da noch vorhanden.

Werde testen und sonst auf den SAMD21 umstellen.

[Sonnengruesser]

Sorry dass ich diesen Thread hier ein wenig OT gebracht hab. Mir geht's halt um die "Nachrüstung" von Masifis HW1.2 usw. Da sind ja auch noch einige unterwegs und viele Bastler haben irgend welche Dinge damit vor aber noch nicht umgesetzt. Oder aber ich will noch was ändern und ziehe existierende HW mit. Am schlimmsten wärs, wenn ich dafür die Suite V4 und für die SAMDs die V5 brauche.
Aber so wie's aussieht sollte das ja möglich werden. Dann hoffe ich mal, dass die 9% freier Speicher noch ausreichen...

[tuxedo]

beta4 hat noch keine KO limitierung. Wir hatten mal 85 angedacht, aber nie kontrolliert/limitiert.

Das Problem bei den Adressen ist: Man braucht _alle_ GAs im RAM, weil das laden von einem Speicher "zu lange" dauert.
80GAs machen da schon 160 bytes aus. Aber um die GAs drum rum hat man ja auch noch das KO-Objekt, das auch nochmal speicher braucht.
Bei den Parametern hatten wir das Limit bei 256 Params. Das wird nun auf >=512 angehoben. Zumindest für den SAMD.

Eine Beispiel-EEPROM/Flash-Belegung für beta5:

Bei bis zu 256KOs
BIs zu 256GAs
und bis zu 256 KO<->GA Verknüpfungen

--> gehen aktuell rund 1,3k drauf. Die Parameter und alles was der Sketch für sich noch braucht hängt dann dahinter.

Bei einem 32u4 der 2k EEPROM hat bleiben also rund 700bytes für die Parameter und die User-Daten "übrig".

EEPROM Speicher ist also nicht so das "riesen" Problem. Mit 700 bytes kommt man für Parameter und User-Daten ja noch recht weit.
Aber 256GAs erfordern mehr als 512K RAM. Und wenn man nur 2,5k hat ist das schon eine Menge.
Hinzu kommt, dass es auch ein wenig CPU-Power erfordert in rasender Geschwindigkeit ein eingehendes Telegramm von der GA her gegen die parametrisierten GAs zu vergleichen. Viel Zeit darf das nicht kosten, denn der Sketch muss ja noch laufen und wir dürfen kein einziges Bytes eines Telegramms verlieren, sonst ist das System unzuverlässig.

Der SAMD hat 32k RAM... das ist für unsere Anwendung mehr als genug. Und mit seien 32bit und 48Mhz ist er auch gewaltig schnell. So schnell, dass auch ein "Anfänger" mit den Ressourcen verschwenderisch sein darf ohne dass er gleich in Probleme läuft. Beim 32u4 bin ich schon mehrfach an die RAM Grenze gestoßen. Einen Aktor wie den DFF4.1 hätte ich damit NIE realisieren können.... Und der hat nur um die 70KOs (wenn ich mich recht erinnere).

Alles in allem:

Ihr dürfte gerne "reale" Wünsche äußern wie groß der Light-Modus sein soll (ich suche noch nach meinem Dokument wo ich mir meine bisherigen Gedanken dazu notiert hatte...).

Der Light-Modus wird auch glaub ich erstmal nicht fest an die HW gebunden, sondern man muss es im Code einstellen. D.h. ihr könntet euch auch über eine Light-Mode Limitierung hinwegsetzen, müsste dann aber mit den Konsequenzen leben.

---

Zur Entwicklung an sich gibt's auch wieder etwas zu berichten. ChriD hatte Probleme mit der Suite in dem Tunneling-Mode seiner KNX Schnittstelle. Hintergrund: Mehrere Netzwerschnittstellen und eine "kaputte" Namensauflösung die dazu geführt haben dass man alle anderen Netzwerkschnittstellen deaktivieren musste.

Hab das gestern Abend noch debugged und heute in einer Hau-Ruck-Aktion gefixt. Ist aber schon ein deutlicher Umbau, weswegen das nicht mehr in eine beta4 Version einfließt. Wer auch auf das Problem stößt: Vorrübergehend unnötige Netzwerkschnittstellen deaktivieren...

Gruß
Alex