Entwicklung SIGNALDuino Empfänger Firm- und Hardware V4 für Maple Mini und ESP32

Ralf9 · 05 Mai 2020, 21:33:30

ZitatKaum macht man es richtig, schon geht es !

Da bist Du jetzt ein großen Schritt vorwärts gekommen.

ZitatIst noch Feintuning angesagt, insbesondere ein close() une ein reconnect() handlen.

Im 00_Signalduino Modul gibts bereits eine Keep Alive Routine, wenn eine Minute nichts empfangen wird, dann wird eine Ping (P) Befehl gesendet.

Die sporatischen Abstürze bei der LAN-Version sind wahrscheinlich recht schwer zu finden.
Vorgestern lief es recht stabil, ich hatte während 11 Stunden keinen Absturz.
Gestern hatte ich schon nach weniger als eine halbe Stunde einen Absturz.
Heute Abend hatte ich erst nach ca 3 Stunden einen Absturz.

Ich versuche gerade herauszufinden, ob es davon abhängt, ob ich nur SlowRF oder nur FSK oder ob ich SlowRF und FSK empfange.

Können die Abstürze auch mit Interrupts zusammenhängen?

Ich will versuchen die Abstürze mit LEDs einzugrenzen. Z.B. indem ich eine LED vor dem Ethernet Print einschalte und nach der Ausgabe wieder ausschalte.
Kann ich an RX2 und TX2 auch LEDs anschließen, wenn ich sie als Ausgang konfiguriere?

Ich habe noch ein kleines Verständnis Problem mit "else if"
Momentan habe ich es so:

Code Auswählen

 if (ccmode == 0) {

else if (ccmode < 15) {

Die Bedingung 1 soll bei ccmode == 0 ausgeführt werden.
Die Bedingung 2 soll bei ccmode 1 bis 14 ausgeführt werden.
Oder ist es so besser?

Code Auswählen

 if (ccmode == 0) {

else if (ccmode > 0 && ccmode < 15) {

Gruß Ralf

juergs · 05 Mai 2020, 22:04:11

Hallo Ralf,

ZitatIch habe noch ein kleines Verständnis Problem mit "else if"
Momentan habe ich es so:
Code: [Auswählen]
if (ccmode == 0) {

else if (ccmode < 15) {

Die Bedingung 1 soll bei ccmode == 0 ausgeführt werden.
Die Bedingung 2 soll bei ccmode 1 bis 14 ausgeführt werden.
Oder ist es so besser?
Code: [Auswählen]
if (ccmode == 0) {

else if (ccmode > 0 && ccmode < 15) {

Das lässt sich doch einfach in 2 hintereinandergelegten If's abfragen ...

Code Auswählen


if (ccmode == 0) 
{
  tu_dies;
}

if ccmode > 0  && ccmode <15 
{
    tu_das ; 
}

Ist glaube ich verständlicher, als solche Schachtelungen (KISS-Prinzip) ...

Ein switch war glaube ich langsamer in der AAusführung als die If's:

Code Auswählen

switch (ccmode)
{
case 0:
     tu_dies;
     break;
case 0:
case 1:
..
case 14:
    tu_das;    

}

Habe den WIZNet-code nur kurz überflogen und leider noch nicht ausprobieren können.
Aber als nächstes kann ich Dich ggf. beim Fehlersuchen unterstützen, wenn die Sensor-Protokoll Bedingungen
bei mir auch irgendwie reproduzierbar sind.

Kannst Du die Testbedingungen mal formulieren?
Also, welches Protokoll, wie Einstellen, was wird erwartet ...

Man könnte auch ein OLED SS1306, ein TFT-2,4 '' oder ein TFT-7750-Display an den I2C-Bus hängen und den Debug-Output dort als Terminal ausgeben ....
Glaube, das werde ich sowieso tun müssen, wenn ich über die Serial1 andocke ...

Jürgen

Reinhard.M · 05 Mai 2020, 22:06:01

Version 1 reicht bei if/else Konstrukten bereits. Bei case kann sowas zu Fehlern führen.

Ralf9 · 05 Mai 2020, 22:58:51

Mich interessiert bei der LAN Version folgende Test:

a.) nur Radio A für FSK Empfang (z.B. LaCrosse) aktiv

b.) nur Radio B für SlowRF (ASK) aktiv

c.) Radio A und B aktiv für SlowRF und FSK Empfang

Gibt es bei allen 3 Varianten Abstürze?

Reinhard.M · 05 Mai 2020, 23:38:23

Ich habe auf alle Fälle Abstürze im Fall c). Die anderen beiden kann ich momentan nicht testen.

Nachtrag:
Die Abstürze kommen bei mir relativ regelmäßig ungefähr alle 24 Stunden. Ich würde einen überlaufenden Counter in Erwägung ziehen.

Ralf9 · 06 Mai 2020, 12:48:26

können überlaufende Counter einen Absturz verursachen?
Bei einem überlaufenden Puffer oder Array kann ich es mir vorstellen.

Ich habe den Eindruck, wenn mehr Nachrichten ausgegeben werden, daß dann der Absturz früher kommt.

Reinhard.M · 06 Mai 2020, 13:10:38

Du hast Recht, Counter macht lediglich einen Wrap Around. Wird allerdings ein Counter für einen Pointer auf einen Buffer verwendet und wird dieser Pointer nicht ab 0 sondern ab 1 verwendet kann das schon merkwürdige Effekte erzeugen wenn dann doch plötzlich eine 0 auftaucht. War auch nur so eine Idee.
Was ich aber bei mir beobachte ist eine Wiederholung der Abstürze etwa alle 22 bis 25 Stunden (Ungefähr!). Seit mehreren Tagen. Irgendwo scheint zumindest ein Zähler im Spiel zu sein. Messages sind jedenfalls nicht auffällig mehr oder weniger gewesen. Ich werde weiter genau hinschauen.

juergs · 06 Mai 2020, 14:38:26

Hallo Ralf9,

hast Du mal mit den Compiler-Optimierungen variiert?

https://gcc.gnu.org/onlinedocs/gnat_ugn/Optimization-Levels.html

Ralf9 · 06 Mai 2020, 22:52:23

Zitathast Du mal mit den Compiler-Optimierungen variiert?

Nein habe ich noch nicht gemacht. Meinst Du die in der Anlage?

Was schlägst Du vor?

juergs · 06 Mai 2020, 22:53:55

Ja, genau die .... "Smallest" ist evtl. zu drastisch ...

Reinhard.M · 07 Mai 2020, 08:30:47

Ich habe gerade die Fast (O1) Variante compiliert und geladen. Mal sehen was passiert. Diesmal hatte sich der Maple nach 9 Stunden verabschiedet.

juergs · 07 Mai 2020, 09:52:05

Hallo, habe gestern meine Basis-Version als Startpunkt in mein Github-Repository gestellt.
Sie enthält eine Vereinheitlichung und Anpassung des gesamten Codes auf eine für mich passende Form,
von der ich meine Änderungen für das WLAN-Interface in entsprechende Branches eintragen werde.

Die Master-Version ist von Ralfs Version SIGNALDuino-4.1.0-dev200427 abgeleitet und beinhaltet noch keine Änderungen bezüglich WLAN-Interface!

Der Compile lief in der Arduino IDE unter Windows 10 durch und läuft bei mir in Ranseyers Platinen-Version: MapleSDuino V0.2 mit zwei 868Mhz-CC1101 erfolgreich.

Grüße,
Jürgen

/edit: zum Anschliessen eines TFT-Displays (ST7735, 1,8'' 128x160 Pixel) werde ich diese Anschlüsse nutzen:

GND	GND
3V3	VCC
SCL	TX3/SCL = Pin 1
SDA	RX3/SDA = Pin 0
RES	NRESET = Pin RESET
DC	CC_IN_3 = Pin 14
CS	CC_CS3 = Pin 3
BL	(Backlight) Brücke mit 3V3

juergs · 07 Mai 2020, 14:26:59

Zitat von: Reinhard.M am 07 Mai 2020, 08:30:47
Ich habe gerade die Fast (O1) Variante compiliert und geladen. Mal sehen was passiert. Diesmal hatte sich der Maple nach 9 Stunden verabschiedet.

Mit LAN oder ohne über USB?

Ralf9 · 07 Mai 2020, 16:20:29

ZitatMit LAN oder ohne über USB?

USB läuft stabil, da konnte ich bis jetzt noch keine Abstürze beobachten.

Zitat von: killah78 am 03 Mai 2020, 21:35:36
Hi. Ja habe es jetzt 36 lStunden aufen gehabt. Ich habe noch ab und an ca 20 minütige Aussetzer, aber ich würde es als deutlich stabiler bezeichnen. Vorher hatte ich ja Stunden lange Aussetzer, jetzt habe ich in 36 Stunden 5 Aussetzer von ca je 20 min. gefunden. Also deutlich besser, wenn auch nicht ganz perfekt.

Ich teste gerade mit USB den Empfang von Mode1 LaCrosse.
Dazu schreibe ich mit "event-min-interval .*:60" jede Minute den state ins Filelog.
Damit das state auch ins reading geschrieben wird, wenn sich der state nicht ändert, musste ich in der 36_LaCrosse.pm was auskommentieren:

Code Auswählen

readingsBulkUpdate($rhash, "state", $state); # if( Value($rname) ne $state );

juergs · 07 Mai 2020, 17:15:27

Die Idee mit dem TFT war ja nicht schlecht,
bis auf das meine funktionierenden Libs in der "Maple"-Konfiguration laufen und nicht in der Core-Variante.
Weil die sich nicht an die STMDuino <SPI.h> Funktionen gehalten bzw. auf die Kompatibilität verzichtet haben ....

Mal schauen, ob sich das für das doch noch einfach für ST7735 lösen lässt, oder .... das erst mal von der Todo-Liste streiche ...