search

RFD-FHEM / SIGNALESP

SIGNALduino direclty on ESP8266
GNU General Public License v3.0
15 stars 8 forks source link

support for both hardware revisions implemented (incl. bugfixes for latetest changes) #8

Closed habeIchVergessen closed 6 years ago

sidey79 commented 7 years ago

Wenn du hier weitere Features einbaust, wird das meiner Meinung nach nie was mit dem Mergen.. besser ist es, für jedes Thema einen eigenen PR zu machen, sonst lässt sich am Ende wegen eines Themas der ganze PR nicht mergen

habeIchVergessen commented 7 years ago

meinst du das Prüfen auf beide Hardware Revisionen? Da werden doch nur Register getauscht. Ansonsten sind es lediglich Anpassungen, die aus meiner Sicht Sinn ergeben. Separate PRs bedürfen mehrerer Branches auf der Entwicklungsseite. Auch nicht toll.

sidey79 commented 7 years ago

Es sind hier 18 commits in dem PR.

Ich schätze, das sind mehrere unabhängig Änderungen .

habeIchVergessen commented 7 years ago
sidey79 commented 7 years ago

ja, ich eine Callback für alle Ausgaben wäre gut. Die Lösung mit dem Makro ist etwas suboptimal

habeIchVergessen commented 7 years ago

Soll der Callback die Macros ablösen? die standardmäßige Ausgabe nach Serial wird gleich in signalDecoder implementiert? Möchtest du den Vorschlag machen?

sidey79 commented 7 years ago

ja alle Ausgaben sollten über eine Callback laufen. Bin noch nicht sicher, ob man eine Callback mit Parameter oder eine 2. Callback für debug macht. vielleicht sollte der Signale Decoder alles auf eine Ausgabe werfen. Nur im Hauptskech braucht man da wohl was

sidey79 commented 7 years ago

ich habe gestern ein bisschen mit einem Pointer auf ein Stream Objekt experimentiert. Compilieren geht, aber der ESP schmiert ab, sobald ich dem pointer die Adresse vom serverClient zuordne. Bleibt dann wohl doch nur die Callback Funktion

habeIchVergessen commented 7 years ago

wenn direkt in serverClient geschrieben wird, könnten wir yield() wieder nicht sehen.

sidey79 commented 7 years ago

was meinst Du mit yield sehen? yield läuft bei jedem write. Um yield brauchen wir uns nicht kümmern, eher darum dass write nicht so oft aufgerufen wird, da es einen enormen Overhead erzeugt.

habeIchVergessen commented 7 years ago

yield sehen: den Aufruf von serverClient.write (impliziert yield nach den letzten Erkenntnissen) im Haupt-Thread mitbekommen

dann muss der Callback solange puffern, bis eine gewisse Größe erreicht ist oder MSG_END in den Daten vorkommt.

sidey79 commented 7 years ago

MSG_END ist eine gute Idee. also entweder Puffer voll oder halt MSG_END. Muss nur Mal sehen wie das mit Print, ptintln oder write läuft.

sidey79 commented 7 years ago

ich habe das mit der Callback gestern mal angefangen.

So richtig gefällt mir das noch nicht, da wir die ganzen Funktionen aus Stream/Print/WifiClient verlieren. Die Callback brauchen wir ja auch nur, da in WifiClient der Puffer noch fehlt.

Ich habe das Mal grob zuende gedacht. Wenn man die diversen Print und Write Ausgaben beibehalten möchte, braucht es eine eigene Klasse oder man übergibt mehrere Callback Funktionen.

sidey79 commented 7 years ago

ich habe jetzt einen Ansatz,

ich habe mehrere Write Funktionen in den Signaldecoder eingebaut. Die sind notwendig, damit man die gewohnten Print, Write Optionen grob abdeckt. (Ausgabe eines Zeichens, Ausgabe einer Zeichenkette,..)

Diese Write Funktionen ruft eine Callback aus dem Hauptprogramm auf, welche dann tatsächlich ein Write auf eine Stream Klasse anwendet.

habeIchVergessen commented 7 years ago

möchtest du die in einem neuen branch teilen?