ESP8266 KNX mit ETS

[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).

[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

[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,

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

[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

[jeff25]

Hi,

warum geht man bei dem SAMD21 nicht auf in i2c EEprom für die Paramter? Das würde flash freigeben....
Weil es die existierende HArdware nicht hergibt? Ich fände das sehr interessant. Es würde auch das Problem
lösen wenn man neu programmiert dass die Parameter wieder weg sind....

[Ing-Dom]

Ich hatte damals mit ca. 100 KO und ca. 3.3kB Parametern so ziemlich die Grenze erreicht. Nur so als Anmerkung, hängt davon ab, was man machen will.

Ich hadere da auch grade mit mir - ob es das wert ist. Entwicklungskoten (zeit) vs. Stückkosten.

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).
Der kostet auch nur 2-3€ mehr, bei einem Dimmer mit Materialpreis um die 100€ (je nach FETs) ist das auch kein Thema mehr.
Und für kleine Geräte mit wenigen Kanälen tut es dann auch der SAMD21.

[Ing-Dom]

Kostet zwar den doppelten Speicher, da es aber "nur" Flash ist, wäre das unkritisch. Und da während des Programmierens nur der KNX-Stack läuft und nicht die drauf aufsetzende Firmware, sollte man auch genug RAM haben, um erstmal zu sortieren.

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.


wenn du mal Zeit hast, könntest du ja mal die Zeit ermitteln die für solche GA-Suchen drauf gehen, bei vielen GAs.
Ist ja kein Hexenwerk, micros() merken und dann abziehen und ausgeben...

[mumpf]

Hi,

noch eine Anmerkung: Wahrscheinlich werden bei der Version mit FlashAsEEPROM-Lib immer noch alle Parameter zur Laufzeit im RAM vorgehalten. Und alle KO, GA und KO-GA-Zuordnungen. Damit sind aufwändige Applikationen schwieriger zu realisieren, je nachdem, was man machen will. Ich hatte damals mit ca. 100 KO und ca. 3.3kB Parametern so ziemlich die Grenze erreicht. Nur so als Anmerkung, hängt davon ab, was man machen will.

Gruß, Waldemar

[Ing-Dom]

ich hatte das Problem, dass ich ohne while(!Serial) gar nichts mehr bekommen habe, wenn ich später erst dem COM Port geöffnet habe am PC.
Ich kann das aber aktuell nicht reproduzieren, nun gehts ? Komisch.

Natürlich sollte es ohne USB gehen! Aber es spricht ja nichts gegen eine Debug-Konfiguartion bei der das while drin ist. Aber du hast recht, dass kan jeder selbst in sein Programm aufnehmen.

[mumpf]

Hi,

Das Sortieren wäre doch kein Problem, einmal zur Instanziierung müsste doch reichen.

ein paar Probleme gibt es schon... Die Tabelle selbst kommt von der ETS (über den Aufbau weiß ich auch nichts genaueres), derzeit wird sei (bei mir) einfach beim Programmieren in den Flash geschrieben. Um die restliche Funktion nicht zu stören, könnte man redundant auch eine sortierte Liste wegschreiben und dann binär suchen. Kostet zwar den doppelten Speicher, da es aber "nur" Flash ist, wäre das unkritisch. Und da während des Programmierens nur der KNX-Stack läuft und nicht die drauf aufsetzende Firmware, sollte man auch genug RAM haben, um erstmal zu sortieren.

wenn bisher eine Zuordnung der GA zum KO implizit über seine Position in einem Array geschah,

Es gibt auf jeden Fall noch eine weitere Tabelle, in der die Relation von KO und GA beschrieben wird, ich würde auch darauf Tippen, dass diese Zuordnungen indexbasiert sind (weiß es aber nicht). Das alles sauber zu verwalten, oder Daten redundant abzulegen, dürfte schon aufwändig sein. Vor allem, weil die ETS beim partiellen programmieren auch mal nur Einzelne Tabellen schickt und nicht immer alle. Aber auch da weiß ich nicht, wie das genau abgeht...

Gruß, Waldemar

[mumpf]

Hi,

ich weiß nicht, ob das von der Entwicklungsumgebung abhängt, ich nutze PlatformIO. Da kommt was auf Serial an, sobald man ein Serial-Terminal öffnet. Das Problem mit dem while war bei mir, dass das Device auch dann wartet, wenn keine USB-Verbindung zum PC da ist. Da es aber ein KNX-Gerät ist, soll das auch ohne USB funktionieren . Zumindest teste ich auch das immer wieder...

Ich hab das bei mir mit einem delay(5000) beim Start gelöst, in der Zeit schaffe ich es, das Terminal zu starten, um alle Serial-Ausgaben zu bekommen (von Anfang an). Und wenn ich es mal ohne USB teste (oder das Gerät sich einfach nach dem Programmieren neu startet), gibt es keinen "hänger", weil man vergessen hat, das while auszukommentieren.

Ob das mit der Arduino-IDE genau so geht, weiß ich allerdings nicht.

Evtl sollte man das mit in das Beispiel aufnehmen...

Wegen des "Hängers" würde ich das nicht in das Beispiel aufnehmen. Oder nur in Kombination mit einer Maximalwartezeit...

Gruß, Waldemar

[Ing-Dom]

gut zu wissen. Bei meinem Board (ItsyBitsy) heißt die USB Serial "Serial". Kann am SAMD21 Mini anders sein.
Aber ich denke dass mit dem warten haben alle SAMD21 Arduino-Boards gemein. Evtl sollte man das mit in das Beispiel aufnehmen...

[jeff25]

Mal was anders - hat bei euch mit SAMD die Debugserial ohne weiteres funktioniert? Ich musste ein while(!Serial); einfügen, damit er im Setup auf die Serial wartet, sonst kam da gar nichts.

Ich habe nicht direkt mit Serial getestet aber mit SERIALUSB und da hatte ich auch ein while(!Serial); einbauen müssen sonst kam nichts auf der Schnittstelle an...

[Ing-Dom]

Das Sortieren wäre doch kein Problem, einmal zur Instanziierung müsste doch reichen. Je nach Algorithmus bräuchte man halt noch genug freien Speicher zum Rumschieben.

Grundsätzlich natürlich nicht.
Ich weiß ehrlich gesagt überhaupt nicht, wie die Tabellen aufgebaut sind, aber:
wenn bisher eine Zuordnung der GA zum KO implizit über seine Position in einem Array geschah, dann verliert man diese Information bei einer Sortierung. D.h., mann muss dann jeder GA noch einen Zeiger auf "ihr" KO mitgeben, was wieder Speicher frisst.
Wie meistens ist es also ein Tradeoff.. Speicher vs. Laufzeit.

Mal was anders - hat bei euch mit SAMD die Debugserial ohne weiteres funktioniert? Ich musste ein while(!Serial); einfügen, damit er im Setup auf die Serial wartet, sonst kam da gar nichts.