AskSin++ Library

[Tom Major]

Wird doch alles gemacht.
https://github.com/pa-pa/AskSinPP/blob/master/Storage.h
https://github.com/pa-pa/AskSinPP/blob/30b03a0bdc2f84dd5a1ca4ced4090c51011810df/AskSinPP.h#L175

Man müsste halt rausfinden, warum die StorageConfig valid war, bzw. wenn der Rest gestimmt hat, warum nur die FreqConfig-Bytes FF waren.

Moin Jerome, bin gerade nicht in den Details der StorageConfig drin, aber ist das nicht die allgemeine HM Config die bei longpress gelöscht wird?
Dann wäre doch da die Frequenz mit Absicht nicht innerhalb der chksum (da sie erhalten bleiben muss) und deine verlinkte Prüfung auf sc.valid() würde für die Frequenz nichts bringen?

[Xent]

Ich werd nacher mal die alte Firmware flashen und schauen, ob dort auch schon die Frequenz ausgegeben wurde.
Falls nicht, dann wurden diese Bytes des EEPROMs ja noch nie beschrieben oder?

Wenn nun in beiden FF drin steht, dann wird ja beim berechnen der Checksumme zwei mal XOR mit FF gemacht und dadurch das erste XOR wieder rückgängig gemacht.
Dadurch passt dann die Checksumme wieder weil das Ergebnis raus kommt was auch ohne die beiden Bytes rausgekommen währe.

[jp112sdl]

Moin Jerome, bin gerade nicht in den Details der StorageConfig drin, aber ist das nicht die allgemeine HM Config die bei longpress gelöscht wird?
Dann wäre doch da die Frequenz mit Absicht nicht innerhalb der chksum (da sie erhalten bleiben muss) und deine verlinkte Prüfung auf sc.valid() würde für die Frequenz nichts bringen?

Ich werd nacher mal die alte Firmware flashen und schauen, ob dort auch schon die Frequenz ausgegeben wurde.
Falls nicht, dann wurden diese Bytes des EEPROMs ja noch nie beschrieben oder?

Wenn nun in beiden FF drin steht, dann wird ja beim berechnen der Checksumme zwei mal XOR mit FF gemacht und dadurch das erste XOR wieder rückgängig gemacht.
Dadurch passt dann die Checksumme wieder weil das Ergebnis raus kommt was auch ohne die beiden Bytes rausgekommen währe.

Dann mal anders herangegangen:
Wenn ich einen Sketch flashe und den 328P das erste Mal in Betrieb nehme -> welcher EEPROM Bereich wird dann mit Init Storage beschrieben?
Oder anders: Wann werden denn die Config-Bytes 0x04-0x20, in dem auch die Freq liegt, mit 0 beschrieben?

Bei einem nagelneuen 328P sollten ja alle EEPROM Bytes 0xFF sein?
Die Freq wird nur geladen, wenn
if( f1 != 0 ) {...

[Tom Major]

Bei einem nagelneuen 328P sollten ja alle EEPROM Bytes 0xFF sein?
Die Freq wird nur geladen, wenn
if( f1 != 0 ) {...

korrekt.
imho müsste mindestens noch f1,f2 != 0xff zur Prüfung dazu genommen werden - falls die Frequenz außerhalb der chksum liegt, das weiß ich nicht.

[Xent]

Ich denke, dass auch wenn es in der Checksumme drin ist, grprüft werden sollte ob das erste Byte  != FF ist.
Wenn man als Frequenz 0x21FF00 nehmen würde, dann währe das schon weit oberhalb der 868 Mhz.


EDIT: noch was anderes.
Wie überschreibe ich jetzt die Methode der ResetOnBoot Klasse?
Irgendwie bekomme ich es nicht hin, dass er von der Klasse erbt ...

So versuch ichs gerade ...

Code Auswählen Erweitern

template <class DEVTYPE>
class ResetOnBootCustom : public ResetOnBoot<DEVTYPE> {
  DEVTYPE& dev;

public:
 
  virtual void led(bool on) {
      on == true ? dev.led().ledOn() : dev.led().ledOff();
  }
}

[papa]

Da hilft ein C++Buch/Kurs

Code Auswählen Erweitern

template<class DEVTYPE>
class ResetOnBootCustom : public ResetOnBoot<DEVTYPE> {
public:
  ResetOnBootCustom (DEVTYPE& dev) : ResetOnBoot<DEVTYPE>(dev) {}
  virtual ~ResetOnBootCustom () {}
  virtual void led(bool on) {
       // do your own stuff here
   }
};


[papa]

Ich denke, dass auch wenn es in der Checksumme drin ist, grprüft werden sollte ob das erste Byte  != FF ist.
Wenn man als Frequenz 0x21FF00 nehmen würde, dann währe das schon weit oberhalb der 868 Mhz.

Ja - 0 ist da sicherlich falsch. Da muss 0xff hin.

[jp112sdl]

Ja - 0 ist da sicherlich falsch. Da muss 0xff hin.

Mich wundert nur, dass es da noch keinen "Aufschrei" gab.
Denn eigentlich müssten doch seit Einführung der FreqConfig Bytes alle erst-programmierten 328P derzeit FFFF als Freq setzen, sofern der FreqTest nicht ausgeführt wurde?

[Xent]

Danke, jetzt gehts.

Bin eigentlich mehr in C#, PHP und Javascript unterwegs.

Bisher habe ich die Klassen in C++ auch direkt vererbt ohne Template.
Daher haben mir meine bisherigen Erfahrungen und umgebaute Sketche nichts gebracht.

EDIT:
Bin ja froh, dass es scheinbar doch nen Bug ist und ich nicht einfach nur zu blöd war xD

[papa]

Mich wundert nur, dass es da noch keinen "Aufschrei" gab.
Denn eigentlich müssten doch seit Einführung der FreqConfig Bytes alle erst-programmierten 328P derzeit FFFF als Freq setzen, sofern der FreqTest nicht ausgeführt wurde?

Stimmt - aber vielleicht einfach Pech mit der 1 Byte Checksumme gehabt. Wenn der Chip schon mal in Benutzung war, kann da ja zufällig mal was Gültiges stehen. Auf jedem Fall sollte der Code bei einem neuen Chip funktionieren - da die Checksumme auf keinen Fall 0xFF ist.

[Xent]

Werd ich nachher testen.
Hab gestern noch nen neuen Arduino gelötet aber noch nicht programmiert.

Wird die Frequenz denn nun zurückgesetzt wenn man einen Reset macht?
Ich hatte dann irgendwann einen gemacht mit dem ResetOnBoot aber die Frequenz war immer noch falsch.

[gloob]

Werd ich nachher testen.
Hab gestern noch nen neuen Arduino gelötet aber noch nicht programmiert.

Wird die Frequenz denn nun zurückgesetzt wenn man einen Reset macht?
Ich hatte dann irgendwann einen gemacht mit dem ResetOnBoot aber die Frequenz war immer noch falsch.

Nein die Frequenz bleibt bestehen, auch noch einem Reset.

[jp112sdl]

Schrieb ich ja gestern auch bereits

[Tom Major]

da das Thema heute und hier Aufmerksamkeit hat, ich hätte mal folgende Frage an @papa um das für mein AskSinPP Wissen abzuspeichern:

- die 2 Frequenzbytes sind nicht nicht im allgemeinen AskSinPP Config space der bei longpress gelöscht wird, richtig?
- die 2 Frequenzbytes nehmen folglich nicht an der chksum des Config spaces teil?

oder adere Variante:

die 2 Frequenzbytes sind im AskSinPP Config space enthalten, nehmen an der chksum teil aber bei longpress werden diese ausnahmsweise nicht gelöscht?

Danke,

[jp112sdl]

Ich versuch mal wiederzugeben, wie ich es bisher verstanden habe.
Mit der Bitte um Korrektur von pa-pa.

Zutreffend ist am ehesten wohl

oder adere Variante:
die 2 Frequenzbytes sind im AskSinPP Config space enthalten, nehmen an der chksum teil aber bei longpress werden diese ausnahmsweise nicht gelöscht?

Die ersten 4 Byte (0...3) im EEPROM enthalten die 'magic'.
Die Freq liegt in Byte 4 und 5 (also die STORAGE_CFG_START + 0 und +1), und wird für die chksum mit herangezogen.
Beim Speichern der Frequenz wird die Neuberechnung der chksum durch sc.validate() vorgenommen: https://github.com/pa-pa/AskSinPP/blob/30b03a0bdc2f84dd5a1ca4ced4090c51011810df/examples/FreqTest/FreqTest.ino#L128

Ein longpress löscht nur die 'magic', also die ersten 4 Bytes, was dazu führt, dass beim nächsten Start ein "Init Storage" ausgeführt wird.
Der Space, der beim Booten seriell ausgegeben wird (32 - ...) wird gelöscht. Alles < 32 (0x20), die getConfigArea(), bleibt erhalten.