ESP8266 KNX mit ETS

[mumpf]

Hi,

ich würde nicht auf die Idee kommen, die GA-Tabelle im Interrupt im Flash zu durchsuchen.
Ehrlich gesagt weiß ich nicht, wie schnell oder langsam der Zugriff aufs Flash ist, vermute aber dass es deutlich langsamer ist als im RAM.
Erst recht, wenn man ein externens SPI Flash nutzt, wie ich es vorhabe.

da reden wir aneinander vorbei! Ich meine nicht irgendeinen extern angebundenen Speicher. Ich meine mit Flash den internen 256k Programmspeicher, das ist doch auch ein Flash, oder (sorry, bin Hardware "nullinger")? Der kann ja (zumindest lesend) nicht langsam sein, da ja dort der Programmcode liegt, der dauernd abgearbeitet wird. Die tolle Arbeit von Bernator war ja, dass er das, was die ETS beim Programmieren hochlädt, eben da rein speichert (bis auf die KO, die müssen ja im RAM liegen). Ich lese alle Parameter während des Programmablaufs NUR aus dem Flash, ich kopiere die nicht ins RAM. Ich lasse mich gerne eines Besseren belehren, aber bisher hatte das Verfahren keinerlei Nachteile, nur Vorteile.

Bei meinem 24ch led dimmer (den ich wohl auf diesen Stack umbauen wollen würde) brauche ich > 200KOs. Das wäre erstmal nicht drin, ich könnte jedoch ohne weiteres auf den pinkompatiblem SAMD51 gehen.. und dann ist ram kein thema mehr (512k).

Ich will Dir nicht den SAMD51 ausreden, aber mit dem Fork, den ich nutze, habe ich schon eine wirklich große Applikation am laufen:

- Final parameter size is 10521

Das ist der Parameterspeicher in Bytes, liegt aber wie gesagt im Flash (Programmspeicher).

              <ComObject Id="M-00FA_A-0067-10-0000_O-421" Name="KOf99O" Number="421" Text="Ausgang" FunctionText="Logik 99, Ausgang" ObjectSize="1 Bit" ReadFlag="Enabled" WriteFlag="Disabled" CommunicationFlag="Enabled" TransmitFlag="Enabled" UpdateFlag="Disabled" ReadOnInitFlag="Disabled" />

Die Appliaktion nutzt derzeit 421 KO. Diese 421 KO nutzen irgendwas zwischen 6k und 7k RAM. Und meine Applikation dann nochmal das selbe. Wie viel der Stack selbst braucht, weiß ich wie gesagt nicht.

Auf jeden Fall läuft das auf dem SAMD21, geht also...

Und noch was: Wenn Du dann weißt, wie Deine Applikation aussehen soll, speziell so ein Dimmer-Kanal, dann sollten wir uns unterhalten. Ich hab ein Tool, mit dem man Kanäle vervielfachen kann. Dann braucht man das xml nur für einen Kanal zu bauen und das Tool macht dann 24 draus. Es macht nämlich gar keinen Spaß, das manuell an 24 Kanäle anzupassen, vor allem, wenn man dann mal was ändern bzw. ergänzen will. Wobei ich hier nur von der knxprod, nicht von der Firmware spreche. Das Tool ist aber erklärungsbedürftig, da es auf den Aufbau des xml ankommt .

Gruß,Waldemar

[mumpf]

Hi,

warum geht man bei dem SAMD21 nicht auf in i2c EEprom für die Paramter? Das würde flash freigeben....

Flash ist (zumindest bei mir) kein Problem, ich nutze derzeit ca. 170k für Programmcode + ca. 10k für Parameter. Da sind also noch gut 70k frei. Was weh tut ist das RAM. Und wenn man die Parameter extern hätte, müsste man sie am Anfang wieder ins RAM laden, das wäre als nicht besser, sondern eher schlechter.

Es würde auch das Problem
lösen wenn man neu programmiert dass die Parameter wieder weg sind.

Nur wenn man per USB programmiert. Ich programmiere über den JLINK-Debugger über SPI, der schreibt nur so viel in den Flash, wie nötig, also nur den Programmcode. Und er löscht vorher nicht.

Gruß, Waldemar

[Ing-Dom]

warum geht man bei dem SAMD21 nicht auf in i2c EEprom für die Paramter? Das würde flash freigeben....

wie ja auch schon Waldemar erwähnte, ist der interne Flash wohl meistens groß genug.
Natürlich hat es gewisse Vorteile einen externen Flash zu nutzen, aber der große Vorteile des internen Flashs ist: er ist immer vorhanden.

da reden wir aneinander vorbei! Ich meine nicht irgendeinen extern angebundenen Speicher. Ich meine mit Flash den internen 256k Programmspeicher, das ist doch auch ein Flash, oder (sorry, bin Hardware "nullinger")? Der kann ja (zumindest lesend) nicht langsam sein, da ja dort der Programmcode liegt, der dauernd abgearbeitet wird. Die tolle Arbeit von Bernator war ja, dass er das, was die ETS beim Programmieren hochlädt, eben da rein speichert (bis auf die KO, die müssen ja im RAM liegen). Ich lese alle Parameter während des Programmablaufs NUR aus dem Flash, ich kopiere die nicht ins RAM. Ich lasse mich gerne eines Besseren belehren, aber bisher hatte das Verfahren keinerlei Nachteile, nur Vorteile.

Ist mir schon klar, dass du aus dem internen Flash liest. Der ist wahrscheilich schneller als externer Flash.
Ich bin mir aber ziemlich sicher, dass ein Zugriff auf beliebige Speicherzellen im Flash spürbar langsamer ist, als in den RAM. Das mag bei Paramter ABSOLUT kein Problem darstellen, weil man die nicht regelmäßig braucht.
Ich brauche z.B. bei meinem Dimmer die Paramter nur beim Start - da werden dann meine DimmChannels instanziert, je nachdem wie die Parameter gesetzt werden. Und klar, das braucht etwas RAM, weil z.B. sowas wie ein "SwitchOnValue_Day" dann als member in der DimmChannel-Klasse vorhanden ist.
Ich wollte vielmehr auf die GA-Tabelle bzw. die Assoc Tabelle heraus. Liegen die bei dir im RAM oder im Flash? Die müssen ja bei jedem eintreffenden Telegramm durchsucht werden! Da zählt jede µs.

Auf jeden Fall läuft das auf dem SAMD21, geht also...

Ja es läuft. Weißt du, vor allem eine Sache schreckt mich jetzt an dem Stack etwas ab... ich hab mich mittlerweile durch alle 22 Seiten gearbeitet, aber was jetzt genau Sache ist, das weiß ich nicht.
Irgendwas bzgl. memory (RAM sparen) ist wohl im master branch enthalten (aber was?)
Ohne FlashAsEEPROM geht es aber nicht im master.
Was ist mit den small groupobjects?
Und was mit der globalen config.h ?

Wie gehts weiter? Wo kann man ggf. mitmachen? Vielleicht kurzes Statement von thesing ?

Was mir überhaupt nicht taugt, ist irgendwleche Branches zu verwenden, weil man irgendwann doch wieder auf den master aufspringen will, und dann wirds ungemütlich.

nd noch was: Wenn Du dann weißt, wie Deine Applikation aussehen soll, speziell so ein Dimmer-Kanal, dann sollten wir uns unterhalten. Ich hab ein Tool, mit dem man Kanäle vervielfachen kann. Dann braucht man das xml nur für einen Kanal zu bauen und das Tool macht dann 24 draus. Es macht nämlich gar keinen Spaß, das manuell an 24 Kanäle anzupassen, vor allem, wenn man dann mal was ändern bzw. ergänzen will. Wobei ich hier nur von der knxprod, nicht von der Firmware spreche. Das Tool ist aber erklärungsbedürftig, da es auf den Aufbau des xml ankommt

Hehe, jeder Programmierer, der sowas händisch macht, hat den falschen Job
Auch für das Konnekting-kdevice-xml habe ich mir natürlich (!) ein Tool gebaut, dass mir einen Kanal vervielfacht.
Ein perlscript ist das bei mir, und da stelle ich ein wieviel kanäle der dimmer hat und mir wird das xml gebaut.
Aber mit knxprod ist da sicher nochmal ne nummer komplexer. ?

[mumpf]

Hi,

Ich bin mir aber ziemlich sicher, dass ein Zugriff auf beliebige Speicherzellen im Flash spürbar langsamer ist, als in den RAM. Das mag bei Paramter ABSOLUT kein Problem darstellen, weil man die nicht regelmäßig braucht.

Sorry dass ich nochmal nachfrage, aber ich will ja was lernen. Ich hab in der ATMEL-Doku zum SAMD21 folgendes gelesen:

Reading from the NVM memory can be performed using direct addressing into the NVM memory space

Das bedeutet, dass man gerade NICHT das übliche lesen einer Page machen muss, bevor man die gewünschten Bytes bekommt. Und das ist meines Wissens nach der Hauptgrund, warum das Lesen bei Flash-Speichern normalerweise langsam ist. Bitte korrigier mich gerne, falls ich falsch liege.

Und was mir sonst auch nicht in den Kopf will: Wenn der Programmcode im Flash liegt, auf den der Prozessor ja auch random zugreift (bei sprüngen etc.), dann wird man da doch schnellen Flash einbauen und nicht irgendwas langsames, oder? Wir reden hier ja von "nur" 48 MHz Prozessortakt, da gibt es sicherlich Flash-Speicher, der schnell genug ist, oder?

Ich brauche z.B. bei meinem Dimmer die Paramter nur beim Start - da werden dann meine DimmChannels instanziert, je nachdem wie die Parameter gesetzt werden.

Klar, damit kopierst Du die de facto ins RAM, potentiell in einer anderen Repräsentation. Bei mir würde das bei 80 Logikkanälen und 30 1-Wire-Kanälen zu viel Speicher kosten, ich habe sehr schlanke Klassen pro Kanal, die jeweils aktiv zur Laufzeit die Parameter abfragen, ich greife somit quasi ununterbrochen und random auf den Flash zu.

Ich wollte vielmehr auf die GA-Tabelle bzw. die Assoc Tabelle heraus. Liegen die bei dir im RAM oder im Flash?

So wie ich die Änderung von Bernator verstanden habe, liegen die im Flash (wie gesagt, ich hab das nicht selber gemacht, dazu reicht mein Wissen noch lange nicht aus).
Ich werde das man am WE vermessen. Ich werde mal die GA-Tabelle parallel ins RAM kopieren und dann jeden Zugriff sowohl im RAM wie auch im Flash suchen lassen, dann sehe ich mal den Unterschied. Interessiert mich jetzt mal. Und wie gesagt, ich will ja auch was lernen. Das ist eben mein erstes Projekt mit einem Microcontroller...

ich hab mich mittlerweile durch alle 22 Seiten gearbeitet, aber was jetzt genau Sache ist, das weiß ich nicht.

Welche 22 Seiten meinst Du? Git commits?

Was ist mit den small groupobjects?

Oh, sind die small groupobjects im master? Die kommen von mir. Das ist meine Reduzierung von 19 auf 8 Bytes pro KO. Ich erinnere mich gar nicht mehr, dass ich dafür einen Pull-Request gemacht habe. Falls Du das nutzen willst, dann kann ich entsprechend was dazu sagen.

Was mir überhaupt nicht taugt, ist irgendwleche Branches zu verwenden, weil man irgendwann doch wieder auf den master aufspringen will, und dann wirds ungemütlich.

Da hast Du vollkommen recht, die Situation hab ich jetzt. Aber damit muss ich leben, denn ich will auf die Features aus dem Branch nicht verzichten.

Hehe, jeder Programmierer, der sowas händisch macht, hat den falschen Job

Da sind wir uns einig .

Aber mit knxprod ist da sicher nochmal ne nummer komplexer

Ja. Ich hab mein Tool aber auch erweitert, dass man eben so was machen kann wie 80 Logikkanäle, 30 1-Wire-Kanäle. Technisch sind das dann Includes, die n-fach reingeneriert werden. Ist aber sicherlich kein "Glanzstück" an Software, eher nach und nach mit den Anforderungen gewachsen.

Danke erstmal fürs Feedback, das mit dem Flash messe ich mal und werde berichten.

Gruß, Waldemar

[Alloc]

Bzgl. FLASH Zugriffen ist im Datenblatt der Abschnitt 37.12 relevant. Bei über 24 MHz hat man einen Waitstate, also schonmal mindestens nen Zyklus mehr beim Lesen als aus dem RAM. Ob das für die Anwendung relevanter ist, als der potentiell eingesparte RAM muss man dann überlegen, hängt natürlich auch von den nötigen Zugriffen ab (z.B. in Bezug auf die GA-Suche).
Das hier RAM und FLASH im gleichen Adressraum liegen (teilweise von-Neumann-Architektur) hat erstmal auf Zugriffszeiten keinen Einfluss, nur braucht man eben keine spezifischen Instruktionen für den Zugriff (die in der Tat normalerweise auch nochmal für entsprechende Verzögerungen sorgen).

Und was mir sonst auch nicht in den Kopf will: Wenn der Programmcode im Flash liegt, auf den der Prozessor ja auch random zugreift (bei sprüngen etc.), dann wird man da doch schnellen Flash einbauen und nicht irgendwas langsames, oder? Wir reden hier ja von "nur" 48 MHz Prozessortakt, da gibt es sicherlich Flash-Speicher, der schnell genug ist, oder?

Der Zugriff durch die CPU ist was anderes, da dabei die Instruction-Caches üblicherweise nicht Byteweise lesen sondern eine ganze Cache-Line auf einmal gefüllt wird. Wie groß die beim M0+ jetzt sind hab ich nicht geschaut, vermutlich aber mal mindestens 8 Bytes.
Und ja, es gibt auch Flash der "schnell genug" wäre, aber das ist natürlich auch immer von vielen Faktoren abhängig (Kosten, technische Abwägungen wie Spannungsversorgung, Schreibzyklen etc).

[Ing-Dom]

mich hat das den ganzen Tag gewurmt, und ich wollte mal flash und ram zugriff vergleichen.
Mit dem sketch hab ich mir aber den itsybitsy so ins Nirwana geschickt, dass ich per SWD neu laden musste. (Danke jeff25 ).

so mal au Neugier: was ha ich falsch gemacht?
Die Ausgabe "rampointer" kommt noch auf der seriellen an, dann ist Feierabend.


ARGH! ja ich weiß es... ptr + 2*1. die 2 war zuviel, das im im pointer-datenytp automatisch berücksichtigt.

Es ist kein nennenswerter UNterschied zwischen RAM und Flash.

einmal über ein 1024er array aus 16bit werten iterieren, ein vergleich und eine summenberechnung:

270 µs im Flash, 255 µs aus dem Ram.

[COLOR=#569cd6]void[/COLOR][COLOR=#dcdcaa]setup[/COLOR][COLOR=#d4d4d4]() {[/COLOR]


[COLOR=#9cdcfe]Serial[/COLOR][COLOR=#d4d4d4].[/COLOR][COLOR=#dcdcaa]begin[/COLOR][COLOR=#d4d4d4]([/COLOR][COLOR=#b5cea8]115200[/COLOR][COLOR=#d4d4d4]);[/COLOR]
[COLOR=#c586c0]while[/COLOR][COLOR=#d4d4d4]([/COLOR][COLOR=#d4d4d4]![/COLOR][COLOR=#d4d4d4]Serial);[/COLOR]

[COLOR=#569cd6]uint32_t[/COLOR][COLOR=#d4d4d4] sum [/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#b5cea8]0[/COLOR][COLOR=#d4d4d4];[/COLOR]

[COLOR=#569cd6]uint16_t[/COLOR][COLOR=#d4d4d4]*[/COLOR][COLOR=#d4d4d4] ptr [/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#d4d4d4] ([/COLOR][COLOR=#569cd6]uint16_t[/COLOR][COLOR=#d4d4d4]*[/COLOR][COLOR=#d4d4d4])[/COLOR][COLOR=#b5cea8]0x30000[/COLOR][COLOR=#d4d4d4];[/COLOR]

[COLOR=#9cdcfe]Serial[/COLOR][COLOR=#d4d4d4].[/COLOR][COLOR=#dcdcaa]println[/COLOR][COLOR=#d4d4d4]([/COLOR][COLOR=#ce9178]"flashpointer:"[/COLOR][COLOR=#d4d4d4]);[/COLOR]


[COLOR=#6a9955]//Serial.println(ptr);[/COLOR]

[COLOR=#569cd6]int[/COLOR][COLOR=#d4d4d4] i [/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#b5cea8]0[/COLOR][COLOR=#d4d4d4];[/COLOR]
[COLOR=#569cd6]bool[/COLOR][COLOR=#d4d4d4] found [/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#569cd6]false[/COLOR][COLOR=#d4d4d4];[/COLOR]

[COLOR=#569cd6]uint32_t[/COLOR][COLOR=#d4d4d4] start [/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#dcdcaa]micros[/COLOR][COLOR=#d4d4d4]();[/COLOR]

[COLOR=#c586c0]for[/COLOR][COLOR=#d4d4d4](i [/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#b5cea8]0[/COLOR][COLOR=#d4d4d4];i[/COLOR][COLOR=#d4d4d4]<[/COLOR][COLOR=#b5cea8]8000[/COLOR][COLOR=#d4d4d4];i[/COLOR][COLOR=#d4d4d4]++[/COLOR][COLOR=#d4d4d4])[/COLOR]
[COLOR=#d4d4d4]{[/COLOR]
[COLOR=#c586c0]if[/COLOR][COLOR=#d4d4d4]([/COLOR][COLOR=#d4d4d4]*[/COLOR][COLOR=#d4d4d4](ptr[/COLOR][COLOR=#d4d4d4]+[/COLOR][COLOR=#b5cea8]2[/COLOR][COLOR=#d4d4d4]*[/COLOR][COLOR=#d4d4d4]i) [/COLOR][COLOR=#d4d4d4]!=[/COLOR][COLOR=#b5cea8]0xab[/COLOR][COLOR=#d4d4d4])[/COLOR]
[COLOR=#d4d4d4]{[/COLOR]
[COLOR=#d4d4d4]sum [/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#d4d4d4] sum [/COLOR][COLOR=#d4d4d4]+[/COLOR][COLOR=#d4d4d4]*[/COLOR][COLOR=#d4d4d4](ptr[/COLOR][COLOR=#d4d4d4]+[/COLOR][COLOR=#b5cea8]2[/COLOR][COLOR=#d4d4d4]*[/COLOR][COLOR=#d4d4d4]i);[/COLOR]
[COLOR=#d4d4d4]}[/COLOR]
[COLOR=#d4d4d4]}[/COLOR]

[COLOR=#569cd6]uint32_t[/COLOR][COLOR=#d4d4d4] ende [/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#dcdcaa]micros[/COLOR][COLOR=#d4d4d4]();[/COLOR]
[COLOR=#9cdcfe]Serial[/COLOR][COLOR=#d4d4d4].[/COLOR][COLOR=#dcdcaa]println[/COLOR][COLOR=#d4d4d4]([/COLOR][COLOR=#ce9178]"flashaccess:"[/COLOR][COLOR=#d4d4d4]);[/COLOR]
[COLOR=#9cdcfe]Serial[/COLOR][COLOR=#d4d4d4].[/COLOR][COLOR=#dcdcaa]println[/COLOR][COLOR=#d4d4d4](ende [/COLOR][COLOR=#d4d4d4]-[/COLOR][COLOR=#d4d4d4] start);[/COLOR]
[COLOR=#9cdcfe]Serial[/COLOR][COLOR=#d4d4d4].[/COLOR][COLOR=#dcdcaa]println[/COLOR][COLOR=#d4d4d4](sum);[/COLOR]




[COLOR=#d4d4d4]sum [/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#b5cea8]0[/COLOR][COLOR=#d4d4d4];[/COLOR]
[COLOR=#569cd6]uint16_t[/COLOR][COLOR=#9cdcfe]mytable[/COLOR][COLOR=#d4d4d4][[/COLOR][COLOR=#b5cea8]8000[/COLOR][COLOR=#d4d4d4]];[/COLOR]
[COLOR=#d4d4d4]ptr [/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#d4d4d4] mytable;[/COLOR]
[COLOR=#9cdcfe]Serial[/COLOR][COLOR=#d4d4d4].[/COLOR][COLOR=#dcdcaa]println[/COLOR][COLOR=#d4d4d4]([/COLOR][COLOR=#ce9178]"rampointer:"[/COLOR][COLOR=#d4d4d4]);[/COLOR]
[COLOR=#6a9955]//Serial.println(ptr);[/COLOR]

[COLOR=#d4d4d4]start [/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#dcdcaa]micros[/COLOR][COLOR=#d4d4d4]();[/COLOR]

[COLOR=#c586c0]for[/COLOR][COLOR=#d4d4d4](i [/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#b5cea8]0[/COLOR][COLOR=#d4d4d4];i[/COLOR][COLOR=#d4d4d4]<[/COLOR][COLOR=#b5cea8]8000[/COLOR][COLOR=#d4d4d4];i[/COLOR][COLOR=#d4d4d4]++[/COLOR][COLOR=#d4d4d4])[/COLOR]
[COLOR=#d4d4d4]{[/COLOR]
[COLOR=#c586c0]if[/COLOR][COLOR=#d4d4d4]([/COLOR][COLOR=#d4d4d4]*[/COLOR][COLOR=#d4d4d4](ptr[/COLOR][COLOR=#d4d4d4]+[/COLOR][COLOR=#b5cea8]2[/COLOR][COLOR=#d4d4d4]*[/COLOR][COLOR=#d4d4d4]i) [/COLOR][COLOR=#d4d4d4]==[/COLOR][COLOR=#b5cea8]0xab[/COLOR][COLOR=#d4d4d4])[/COLOR]
[COLOR=#d4d4d4]{[/COLOR]
[COLOR=#d4d4d4]sum [/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#d4d4d4] sum [/COLOR][COLOR=#d4d4d4]+[/COLOR][COLOR=#d4d4d4]*[/COLOR][COLOR=#d4d4d4](ptr[/COLOR][COLOR=#d4d4d4]+[/COLOR][COLOR=#b5cea8]2[/COLOR][COLOR=#d4d4d4]*[/COLOR][COLOR=#d4d4d4]i);[/COLOR]
[COLOR=#d4d4d4]}[/COLOR]
[COLOR=#d4d4d4]}[/COLOR]

[COLOR=#d4d4d4]ende [/COLOR][COLOR=#d4d4d4]=[/COLOR][COLOR=#dcdcaa]micros[/COLOR][COLOR=#d4d4d4]();[/COLOR]
[COLOR=#9cdcfe]Serial[/COLOR][COLOR=#d4d4d4].[/COLOR][COLOR=#dcdcaa]println[/COLOR][COLOR=#d4d4d4]([/COLOR][COLOR=#ce9178]"ramaccess:"[/COLOR][COLOR=#d4d4d4]);[/COLOR]
[COLOR=#9cdcfe]Serial[/COLOR][COLOR=#d4d4d4].[/COLOR][COLOR=#dcdcaa]println[/COLOR][COLOR=#d4d4d4](ende [/COLOR][COLOR=#d4d4d4]-[/COLOR][COLOR=#d4d4d4] start);[/COLOR]
[COLOR=#9cdcfe]Serial[/COLOR][COLOR=#d4d4d4].[/COLOR][COLOR=#dcdcaa]println[/COLOR][COLOR=#d4d4d4](sum);[/COLOR]





[COLOR=#d4d4d4]}[/COLOR]

[COLOR=#569cd6]void[/COLOR][COLOR=#dcdcaa]loop[/COLOR][COLOR=#d4d4d4]() {[/COLOR]
[COLOR=#6a9955]// put your main code here, to run repeatedly:[/COLOR]

[COLOR=#d4d4d4]}[/COLOR]

[mumpf]

Hi,

Bzgl. FLASH Zugriffen ist im Datenblatt der Abschnitt 37.12 relevant.

Danke für den Hinweis und die Erklärung. Bin da, wie schon gesagt, nicht ganz so fit...

270 µs im Flash, 255 µs aus dem Ram.

danke, das beruhigt mich. Ich hatte es damals nicht so vermessen, sondern in der main loop nur min/max/avg von einem Loopdurchang pro Sekunde gemessen (jeweils für RAM und Flash) und da hat sich nichts nennenswertes getan. Aber so ist es aussagekräftiger. Und bei 1024 Werten knapp 300ms würde ja sogar für einen ACK reichen.

Ich sehe aber im Stack noch ein grundsätzliches Problem mit dem ACK. Selbst wenn ich an der Stelle, an der das ACK gemacht werden soll, gar nicht nach GA suche sondern gleich bestätige, wird kein ACK auf den Bus gemacht. Da muss ich noch weiter forschen. Es liegt zumindest nicht an der linearen Suche bzw. daran, dass die Tabelle im Flash ist.

Bis bald,
Waldemar

[Ing-Dom]

Gestern hab ich gelesen, dass es auch einen original Arduino mit RP2040 geben wird und es ein Arduino-Core dafür geben wird.
Das original Raspberry Pico Board kostet ja nur 4$, das kostet der SAMD21 schon alleine.
Auch Adafruit arbeitet an einem ItsyBitsy RP2040. Bin gespannt was das kosten wird, aber wenn das Raspberry Pico für 4$ übern Tisch geht, kann Adafruit schlecht 15$ verlangen.

Der Controller hat meiner Meinung nach echt das Potential den SAMD21 den Rang abzulaufen.
2x 133mhz Cortex M0+
264k ram
10-30mA

[mumpf]

Hi,

Der Controller hat meiner Meinung nach echt das Potential den SAMD21 den Rang abzulaufen.

Hört sich irgendwie gut an, aber wenn es keinen gibt, der den Stack auf diesen Prozessor portiert, würde ich das nicht verwenden können. Ich persönlich möchte keine Eigenentwicklungen mehr ohne ETS-Integration haben.

Gruß, Waldemar

[thesing]

Um mal was zum Stand zu sagen:

- Jeder ist beim mitmachen willkommen. Bei mir liegt akuell der Fokus auf einem anderen Hobby, ich kümmere mich aber immer noch um Pull-Requests, Bugs usw.

- Dokumentation gibt es nur z.T. im Code. Aber für einen Anwendungsprogrammier sollte das Beispiel ausreichen. Man muss nur die KO im Code definieren, auf die Parameter mit den Offsets aus der knxprod zugreifen. Mehr Berührungspunkte als Parameter und KOs hat man mit den Stack eigentlich nicht. Ich habe aufgrund einen Wunsches hier im Forum auch das Wiki in github aktiviert, aber bisher hat noch keiner etwas geschrieben.

- Im letzten Jahr hat Nanosonde den Stack gewaltig erweitert: Es wurden KNX-Datasecure, KNX-RF, und Routing implementiert. Außerdem gibt es nun als Platformen SAMD21, ESP8266, ESP32, STM32 und Linux. Man kann den Stack auch als USB-Interface nutzen und einen Python-Wrapper für Linux gibt es auch.

- Als dringenstens Feature sehe ich noch direktes Flash schreiben für SAMD21. Dafür habe ich im flash-Branch schon den platformunabhängigen Teil geändert. Es müsst nur noch der platformspezifische Teil geschrieben werden. Dann fällt bei SAMD21 die EEPROM-Emulation weg. Das dürfte auch der Hauptgrund für den fork von mumpf gewesen sein.

- Bei Fragen: fragen. Ich hab jetzt auch die E-Mail-Benachrichtigung des Forums aktiviert.

[mumpf]

Um mich mal selber zu zitieren und zu kritisieren:

Ich sehe aber im Stack noch ein grundsätzliches Problem mit dem ACK. Selbst wenn ich an der Stelle, an der das ACK gemacht werden soll, gar nicht nach GA suche sondern gleich bestätige, wird kein ACK auf den Bus gemacht. Da muss ich noch weiter forschen. Es liegt zumindest nicht an der linearen Suche bzw. daran, dass die Tabelle im Flash ist.

Ich habe nach einer langen debug-Session das Problem gefunden und korrigieren können. Nur um dann festzustellen, dass es im Original-Stack bereits korrigiert ist. Was wieder mal den Nachteil zeigt, auf einem Fork zu arbeiten. Ich werde mal ein merge versuchen und schauen, wo es überall klemmt, aber da bin ich schon letztes mal gescheitert...

Wollte hier nur mitteilen, dass es kein prinzipielles ACK-Problem im Stack gibt, das ist längst gefixt.

Gruß, Waldemar

[Ing-Dom]

Hört sich irgendwie gut an, aber wenn es keinen gibt, der den Stack auf diesen Prozessor portiert, würde ich das nicht verwenden können. Ich persönlich möchte keine Eigenentwicklungen mehr ohne ETS-Integration haben.

Nunja, sobald es da einen Arduino-Core gibt werden ich mir mal 1-2 Boards besorgen und experimentieren.
Ich gehe davon aus, dass eine Portierung nicht so extremaufwändig ist, am Ende ist es ja auch nur ein Cortex M0+ mit Ardunio wie der SAMD21.
Ich würde mich diesem Thema auch annehmen wenn es soweit ist.

- Als dringenstens Feature sehe ich noch direktes Flash schreiben für SAMD21. Dafür habe ich im flash-Branch schon den platformunabhängigen Teil geändert. Es müsst nur noch der platformspezifische Teil geschrieben werden. Dann fällt bei SAMD21 die EEPROM-Emulation weg. Das dürfte auch der Hauptgrund für den fork von mumpf gewesen sein.

Schön dass du noch dabei ist! Auch wenn du nicht mehr so aktiv dabei bist, aber ohne dich denke ich würde es nicht recht weitergehen.
Macht es Sinn hier zu unterstützen? Und wenn, dann mit PR auf den flash branch oder?
Ggf. kannst du die Architektur nochmal kurz umreißen.
Es müssen aber alle Plattformen gemacht werden oder?

Weiteres wichtiges Feature wäre aus meiner Sicht auch die "Small Group Objects" von Waldemar.
Und als enabler dafür ggf. die globale config.h ?

[thesing]

Schön dass du noch dabei ist! Auch wenn du nicht mehr so aktiv dabei bist, aber ohne dich denke ich würde es nicht recht weitergehen.
Macht es Sinn hier zu unterstützen? Und wenn, dann mit PR auf den flash branch oder?
Ggf. kannst du die Architektur nochmal kurz umreißen.
Es müssen aber alle Plattformen gemacht werden oder?

Es müssen nicht alle Platformen auch Flash direkt nutzen können. Die Idee ist, dass man an der Platform einstellen kann, ob EEPROM oder Flash genutzt werden soll.
Für den Stack (memory.h/cpp) an sich ist das egal. Der nutzt nur die Methoden

virtual uint8_t* getNonVolatileMemoryStart();
virtual size_t getNonVolatileMemorySize();
virtual void commitNonVolatileMemory();
// address is relative to start of nonvolatile memory
virtual uint32_t writeNonVolatileMemory(uint32_t relativeAddress, uint8_t* buffer, size_t size);

der Platform. Die nutzt dann die Methoden

virtual size_t flashEraseBlockSize(); // in pages
virtual size_t flashPageSize(); // in bytes
virtual uint8_t* userFlashStart(); // start of user flash aligned to start of an erase block
virtual size_t userFlashSizeEraseBlocks(); // in eraseBlocks
virtual void flashErase(uint16_t eraseBlockNum); //relativ to userFlashStart
virtual void flashWritePage(uint16_t pageNumber, uint8_t* data); //write a single page to flash (pageNumber relative to userFashStart

die in der konkreten Platform implementiert sind.
Eine konkrete Platform kann nun entweder direkt die *NonVolatileMemory*-Methoden überschreiben und so wie bisher damit auf EEPROM-Emulation gehen, oder die flash*-Methoden überschreiben und die Implementation der *NonVolatileMemory*-Methoden aus der platform.cpp nutzen.

Also:
- memory.cpp/h: Verwaltung des Speichers für den Stack.
- platform.cpp/h: Multiplexen auf die verschiedenen Speicherarten (derzeit EEPROM (+Emluation)/Flash (memory mapped))
- konkrete Platform: Implementation für die konkrete Hardware.

Später kann man dann auch SPI-Flash der nicht gemappt ist in die platform.cpp/h hinzufügen.


Geplant war in der nächsten Ausbaustufe auch noch Methoden für EEPROM zur Platform hinzufügen, und dort je nach Einstellung EEPROM oder Flash zu nutzen.

Wenn das Feature funktioniert kann der Pull-Request direkt gegen master. Wenn nur im Teilschritte geht, dass gegen den flash-Branch.

Weiteres wichtiges Feature wäre aus meiner Sicht auch die "Small Group Objects" von Waldemar.
Und als enabler dafür ggf. die globale config.h ?

Genau.

- Zum OTA-Update:
Das könnte man auch über ETS machen. Da müsste man die neue Firmware in der knxprod als Baggage hinzufügen und dann über einen speziell LoadProcedure schreiben. Müsste man mal schauen, wie das die Hersteller so machen. Ich würde das wahrscheinlich spontan über ein spezielles InterfaceObject machen.

[mumpf]

Hi,

Und als enabler dafür ggf. die globale config.h ?

die config.h bräuchte man nur, wenn man weiterhin die arduino IDE nutzen will, zumindest soweit ich die noch kenne. Bei platformIO kann man defines pro Projekt von außen mitgeben (-Dxxx in der platformio.ini wirkt so wie ein #define xxx in jedem compilierten File), darüber könnte man sich die benötigten Teile zusammenstellen.

Oder man includiert eben die config.h in jedem File...

Weiteres wichtiges Feature wäre aus meiner Sicht auch die "Small Group Objects" von Waldemar.

Ich kann gerne nochmal zusammensuchen, was das bedeutet. Bei genügend RAM will man das vielleicht gar nicht haben. Ich habe Speicherplatz auf Kosten vom Komfort gespart.

  private:
    size_t asapValueSize(uint8_t code);
    [MARKIEREN]GroupObjectUpdatedHandler _updateHandler;[/MARKIEREN]  // (b)
    size_t goSize();
    uint16_t _asap = 0;
    ComFlag _commFlag = Ok;
    uint8_t* _data = 0;
    uint8_t _dataLength = 0;
    [MARKIEREN]GroupObjectTableObject* _table = 0;[/MARKIEREN]  // (c)
    [MARKIEREN]Dpt _datapointType;[/MARKIEREN]               // (a)

Zum einen (a) hab ich 3 Byte gespart, indem ich mir nicht an jedem KO den DPT merke, sondern den bei jedem Zugriff mitgebe, das heißt:

        knx.getGroupObject(LOG_KoHeartbeat).value(true, getDPT(VAL_DPT_1));

statt

        knx.getGroupObject(LOG_KoHeartbeat).value(true);

Hier wandern die 3 Bytes also vom RAM ins compilierte Programm.

Zum anderen (b) habe ich den Callback, den jedes KO haben kann, um bei Änderungen passend die Applikation zurückzurufen durch einen statischen Callback ersetzt (Klassen- statt Instanzvariable). Damit ruft jede KO-Instanz bei Änderung die selbe Methode auf (mit einer Referenz auf das KO selbst) und man muss selber dispatchen (z.B. anhand der KO-Nummer), wie das behandelt wird. Praktisch heißt das, statt vieler Methoden, die einzelne KO-Inputs behandeln, selber eine Methode stricken, die ein CASE macht und dann die behandelnden Methoden aufruft. Das hat 4 Bytes pro KO gebracht.

Und drittens (c) habe ich die Referenz, die jedes KO auf die GroupObjectTable gehalten hat (und die es ja nur einmal im Stack gibt) in eine Klassenvariable umgewandelt. Das hat nochmal 4 Byte gebracht und keinerlei Komforteinbußen.

Die 3 + 4 + 4 = 11 Bytes sind die, die dann aus 19 eben 8 Bytes Verwaltungsinformationen ausmachen.

Wenn ich das richtig sehe, müsste ich doch jetzt meinen master auf den aktuellen Stand bringen, dann einen neuen branch machen, dort meine Änderungen aus SmallGroupObject reintun, das dann testen und dann einen Pull-Request stellen, oder? An sich ist das ja unabhängig davon, ob ich den aktuellen Stack nutze oder nicht. Ich könnte ja ne weitere knx-demo machen, die das nutzt. Wäre das in Eurem Sinne?

thesing: Thomas, schön von Dir zu lesen und dass Du prinzipiell dabei bist. Ich kann komplett verstehen, dass man auch andere Hobbies hat, ging mir die letzten 8 Monate nicht anders.

Gruß, Waldemar

[Ing-Dom]

Bei genügend RAM will man das vielleicht gar nicht haben. Ich habe Speicherplatz auf Kosten vom Komfort gespart.

Klar, daher auf jeden Fall mit Compiler-Switch. Aber Bedarf denke ich gibt es dafür.

Wenn ich das richtig sehe, müsste ich doch jetzt meinen master auf den aktuellen Stand bringen, dann einen neuen branch machen, dort meine Änderungen aus SmallGroupObject reintun, das dann testen und dann einen Pull-Request stellen, oder? An sich ist das ja unabhängig davon, ob ich den aktuellen Stack nutze oder nicht. Ich könnte ja ne weitere knx-demo machen, die das nutzt. Wäre das in Eurem Sinne?

Du kannst auch einfach den master neu forken und da dann ganz dezidiert die Änderungen einbauen. Ist wahrscheinlich weniger Arbeit als wenn du erst deinen master versucht wieder gerade zu biegen.