Entwicklungsblog Beta5/Final 1.0.0

[tuxedo]

Mal ein "Draft-Status" der Beta5 EEPROM/Flash Aufteilungs-Übrlegung:

Bildschirmfoto vom 2018-06-14 20-58-50.png

Ist noch nicht ganz Spruchreif

[Eugenius]

Kleiner Nachtrag von mir (ich glaube ich bin derjenige, der bei uns im Team 2KByte EEPROM beim 32u4 fälschlicherweise ins Hirn eingebrannt habe...)
32u4 hat nur 1KB EEPROM. und 2,5KB RAM. Von dem RAM gehen 0,5KB für Bootloader (wenn ich mich recht erinnere)
Aber wie man im Bild oben drüber sieht, bei 1KB EEPROM fehlen 291 Bytes EEPROM Platz, wird also nicht mehr gehen :/

[tuxedo]

Verdammt, ja du hast recht. 1k EEPROM, 2,5k RAM.
d.h. da muss bereits abgespeckt (LightMode) werden damit man mit 1k EEPROM auskommt.

Der Bootloader sitzt aber nicht in RAM, sondern im Programmspeicher. Das ist nochmal was anderes. Wäre ja sinnfrei den dauerhaft im RAM zu belassen.

[Ing-Dom]

Der Bootloader sitzt aber nicht in RAM, sondern im Programmspeicher. Das ist nochmal was anderes. Wäre ja sinnfrei den im RAM zu belassen.

die AVRs haben eine Harvard-Architektur, sprich führen den Programmcode nicht aus dem RAM aus wie bei einer von-Neumann-Architektur sondern direkt aus dem Flash.

[tuxedo]

Wenn ich alles auf 128 limitiere (128 GAs, 128KOs und 128 Verknüpfungen zwischen GA und KO), verbleiben noch 349 Bytes im Speicher für Parameter und User-Daten.

349 Bytes klingt nach nicht viel. Aber wenn man bedenkt dass die meisten Parameter doch nur uint8 oder int8 sind, wären das beispielsweise auch nochmal 128 Parameter und für User-Daten 221 bytes übrig.

Ich denke mit der Größenordnung käme man im Light-Modus aus.

[Sonnengruesser]

Ich hab bei meinem 8-fach Fancontroller um die 50Bytes User-Daten und ca. 60 Parameter. Weiß jetzt nicht ob das repräsentativ ist, aber das sollte dann ausreichen.

[Ing-Dom]

auch wenn der Mega2560 nicht unterstützt wird - mit 8k RAM und 4k E² sollte der im normalen Modus laufen, oder?

[tuxedo]

8K RAM und 4K EEPROM werden für den "Normal-Modus" super ausreichend sein.

[tuxedo]

Sonnengruesser
Parameter welcher Art? vieles 1byte/8bit Parameter?

[Eugenius]

Ing-Dom
Beim MEGA2560 sollte man auf den Stromverbrauch achten. Und mit beta4a testen

und jetzt zum Thema: RAM und EEPROM ist eine Sache, CPU Geschwindigkeit ist ne andere... da könnte ein Flaschenhals sein -> einfach testen

[tuxedo]

Die 16Mhz des Mega sollten eigentlich auch ausreichen, wenn man es nicht übertreibt.
Wichtig für eine schnelle Ausführung ist eine gute Datenstruktur der GAs im inneren der Lib. Hier muss man allerdings die Balance zwischen RAM und Geschwindigkeit finden.

Hier müssen wir halt noch teste und evaluieren wie wir das am besten bewerkstelligen. Ist ja keinem geholfen wenn die Abfrage super schnell ist, der RAM Bedarf aber gleich z.B. 2x so hoch ist.

[Sonnengruesser]

Parameter welcher Art? vieles 1byte/8bit Parameter?

ja, hauptsächlich. Hab irgendwann mal hardwarenahe 8bit Programmierung gelernt, das wirkt noch nach...
Notfalls könnte ich noch auf Bitfelder reduzieren, aber in C wird das schnell unleserlich.

[tuxedo]

Die kleinste Einheit als KONNEKTING Parameter ist ein byte (int8/uint8). Passt also.

btw: der Protokollumbau hat begonnen:

https://github.com/KONNEKTING/Konnek...e59686f02e6caf

Und ich hab so ganz nebenbei auch wieder meine Notiz über die "System Types" gefunden:

https://wiki.konnekting.de/index.php...01#System_Type

[tuxedo]

Die Suite ist ja nur eine "UI". Das eigentliche Kernstück das die ganze Arbeit macht ist das "KonnektingDeviceConfig" Projekt.

Hab hier nun das neue Programmier-Protokoll (https://wiki.konnekting.de/index.php...ification_0x01) weitestgehend implementiert.

Bin jetzt so weit, dass ich das im Prinzip schon testen müsste. Also brauche ich das Gegenstück auf Arduino-Seite. Das wird nun als nächstes folgen. Für heute sind es wieder genug tausende Zeilen angepasster/geschriebener Code ...

https://github.com/KONNEKTING/Konnek...otocol-changes

Stay tuned for more ...

[tuxedo]

Während alle Welt Fußball schaut, bastel ich weiter an der Software (habs nicht so mit Fußball...).

Und wie es so ist wenn man tiefer und tiefer einsteigt: Es passt nicht, es muss angepasst werden. Und so geht's mir jetzt gerade bei der Umsetzung des neuen Protokolls. Ein paar Protokollnachrichten Fallen weg, was anderes kommt hinzu, und am ende ist das halbe Prozedere quasi komplett anders.
Das ist nun weder schlimm noch problematisch. Kostet einfach ein wenig Zeit. Aber das alles ist tatsächlich notwendig wenn das Protokoll nun recht flexibel und zukunftssicher sein soll. Wir wollen ja nicht in einem Jahr das Protokoll nochmal anfassen.
Also muss ich auf der Suite-Seite nochmal ran, bevor ich an die Arduino Seite gehe ...

Stay tuned ...