ESP8266 KNX mit ETS

[thesing]

mumpf : Das sollte für dich irrelevant sein. std::function ist quasi ein Functionpointer als C++ Klasse. Es wird an der Stelle nur der Typ
GroupObjectUpdatedHandler definiert.

Ing-Dom Der flash-branch ist der richtige. Memory-rework ist der Branch in dem Bernator SAMD21-Flashzugriff implementiert hat. (In etwa der Stand auf dem mumpf aufgesetzt hat.) https://github.com/thelsing/knx/blob...samd_flash.cpp sollte da am interessantesten sein. (Dort ist eine Row ein Eraseblock, also der Teil der beim Flash immer zusammen gelöscht wird.)
Jetzt sollte der flash branch auch wieder compilieren.

[Ing-Dom]

der "flash" branch ist schon der richtige oder thesing ?
Weil es gibts ja doch noch ein memory_rework ? Was hats damit auf sich?

[mumpf]

Danke, mal schauen, ob ich das brauche. Ich hab im Augenblick einen Branch knx-for-pull gemacht, der jetzt auf dem Original steht, mal schauen, ob ich da weiter komme.

Aber ich hab gleich eine Frage an thesing: In group_object.h gibt es jetzt was neues:

#if HAS_FUNCTIONAL
#include <functional>
typedef std::function<void(GroupObject&)> GroupObjectUpdatedHandler;
#else
typedef void (*GroupObjectUpdatedHandler)(GroupObject& go);
#endif

Was ist das denn? Ich hatte ja den GroupObjectUpdatedHandler-Callback statisch gemacht. Wie man das aber auf die andere Methode umsetzt, weiß ich nicht wirklich. Ich könnte höchstens bei meinem Ansatz dann das HAS_FUNCTIONAL wieder auf 0 setzen. Oder ich mach auch die Funktion statisch, ich bin mir nur nicht sicher, ob ich das vernünftig getestet bekomme. Ist aber eher meinen mangelnden C++-Kenntnissen zuzuschreiben.

Gruß, Waldemar

[Ing-Dom]

neues projekt (leeres repo!) mumpf/knx2 anlegen
thelsing/knx lokal clonen nach C:\Data\knx2
dann origin von C:\Data\knx2 entfnern
origin C:\Data\knx2 auf mumpf/knx2 setzen
pushen

[mumpf]

Hi,

Du kannst auch einfach den master neu forken

jetzt kommt mein beschränktes Wissen zu github raus... Ich hab schon einen Fork gemacht, wie kann ich das nochmal forken?

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.

[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

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

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

[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

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

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

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

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]

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]