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

[RichardCZ]

Danke für den Hinweis, werde ich in meinem angepassten 00_Signalduino Modul korrigieren.

Sidey ist gerade dabei das 00_Signalduino Modul zu überarbeiten, da ist es schon korrigiert
https://github.com/RFD-FHEM/RFFHEM/blob/feaa3f38f3bf58db049218aa9f79eed406627bce/FHEM/lib/SD_Protocols.pm#L873

Hm. Mein Vorschlag ist besser.

my $x = 0;
$x = 5;

... da muss ich doch an Helmut Kohl denken: "Wichtig ist, was hinten rauskommt."

[Ralf9]

kurzer Zwischenstand, so wies aussieht läufts mit dem core 1.9.0 stabiler.

Ich habe mit der LAN Version inzwischen eine uptime von fast 12 Stunden

[Reinhard.M]

Habe die neue Version ebenfalls auf 1.9.0 compiliert und auf meinem MapleCUL installiert. Mal sehen wie sie bei mir läuft. Eine Frage zur Anzeige des "wr". Wird es bei einem WD-Reset immer mit der Version ausgegeben oder nur beim ersten Mal auslesen?

[Ralf9]

Eine Frage zur Anzeige des "wr". Wird es bei einem WD-Reset immer mit der Version ausgegeben oder nur beim ersten Mal auslesen?

Es wird nach einem WD-Reset solange das "wr" in der Version ausgegeben bis ein normaler Reset erfolgt.

[Reinhard.M]

Hallo Ralf,
der Watchdog funktioniert:

Code Auswählen Erweitern

V 4.1.1-dev200603 SIGNALduino cc1101 (R: A1 B0*) wr - compiled at Jun 4 2020 17:01:52
Kam nach ca. 3 Stunden, lief davor aber schon mal 15 Stunden. Sporadisch halt.

[Ralf9]

Ich hab für die Version V 4.1.1-dev200603 nun auch bin-Files erstellt, sie sind mit dem core 1.9.0 compiliert
https://github.com/Ralf9/SIGNALDuino/releases

Ich habe auch mein angepasstes 00_SIGNALduino Modul erweitert und optimiert
https://github.com/Ralf9/RFFHEM/commit/356f85ce5ec8f801e8940ddb743c7ef4580c6103
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900

Ich teste grad die LAN Version
Zuerst hatte ich ein uptime von 1 Tag und 14 Stunden,
dann habe ich mit einem andern MapleSduino weiter getestet, da habe ich bis jetzt eine uptime von 1 Tag und 2 Stunden

Kam nach ca. 3 Stunden, lief davor aber schon mal 15 Stunden. Sporadisch halt.

@Reinhard.M
kannst Du die Stromversorgung als Ursache ausschließen?
Sind auf der MapleCul Platine Kondensatoren, z.B. 10uF?

Gruß Ralf

[nagelreo]

Hallo,

nach etwas längerem Warten habe ich die Teile für den maple-mini erhalten (STM 32F 103 CBT6 ) und zusammen gelötet.
Nach dem Versuch den bootloader auf die Version "maple_mini_boot20.bin" zu flashen funktioniert USB nicht mehr. Ich habe sehr viel gelesen und und über den Seriellen Port probiert, bisher leider ohne Erfolg.

Wer kann mir helfen?
Gruß
Rolf

[Ralf9]

War das flashen des "maple_mini_boot20.bin" erfolgreich?
Welche Anleitung hast Du dazu verwendet?

Nachtrag:
Hier z.B. ist eine Anleitung
https://wiki.fhem.de/wiki/MapleCUN
und hier noch eine
https://taillieu.info/index.php/hardware/microprocessors/302-maple-mini-serial-programming-and-upgrading-to-bootloader-2-0

[nagelreo]

Hallo Ralf,

vielen Dank für die schnelle Antwort/Frage.
Wir haben das flashen mit verschiedenen Verfahren bzw. Anleitungen probiert.
Mit dm FTDI Adapter und Python konnte der boot-loader erfolgreich geflasht und verifiziert werden. Leider funktionierte USB am Raspberry und Windows-PC nicht.

Da ich mit dem Python noch nicht so vertraut bin, habe ich danach mit
-  FTDI Adapter am Windows PC mit Arduino IDE 1.8 und
-  Raspberry (serieller Port) How To: STM32F103C8T6 As An USB Device ( Virtual Serial Port / CDC ) (https://www.youtube.com/watch?v=YZjnCOun1wU)
probiert zu flashen.

Mit Arduino gab es am Schluss die Fehlermeldung

Code Auswählen Erweitern

maple_loader v0.1
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]...
dfu-util - (C) 2007-2008 by OpenMoko Inc.
Couldn't find the DFU device: [1EAF:0003]
This program is Free Software and has ABSOLUTELY NO WARRANTY

Am Rasp kam ich mit den Angaben zum boot-loader nicht klar, http://github..... und Name , siehe Anhang.

Gruß
Rolf

[Ralf9]

Mit Windows kann ich nicht weiterhelfen, ich habe Linux verwendet.
Bei mir funktioniert das flashen nur mit Rootrechten

Code Auswählen Erweitern


./stm32flash -w maple_mini_boot20.bin -v /dev/ttyUSB0

evtl ist vorher noch ein "-k  Disable the flash read-protection" notwendig:

Code Auswählen Erweitern

./stm32flash -k  /dev/ttyUSB0

Es kann sein, daß das firmware flashen auch nur mit Rootrechten funktioniert
entweder mit

Code Auswählen Erweitern

./maple_upload ttyACM0 2 1EAF:0003 Maple_sduino_USB_411dev200603.bin
oder

Code Auswählen Erweitern

./dfu-util -v -d 1eaf:0003 -a 2 -D Maple_sduino_USB_411dev200603.bin -R

Beim dfu-util muß man kurz vorher Reset drücken

[Reinhard.M]

@Reinhard.M
kannst Du die Stromversorgung als Ursache ausschließen?
Sind auf der MapleCul Platine Kondensatoren, z.B. 10uF?

Hallo Ralf,
ich habe mal zwischen die Basis und Maple Platinen geschaut und konnte kein C entdecken. Gänzlich ausschließen kann ich die Stromversorgung natürlich nicht. Da müsste ich mit dem Oszi mal drauf schauen. Bei einem Spannungseinbruch hätte es aber einen Power-On Reset und keinen WD-Reset gegeben. Seit 1,5 Tagen läuft der Maple auch gerade ohne Probleme.

[Telekatz]

vielen Dank für die schnelle Antwort/Frage.
Wir haben das flashen mit verschiedenen Verfahren bzw. Anleitungen probiert.
Mit dm FTDI Adapter und Python konnte der boot-loader erfolgreich geflasht und verifiziert werden. Leider funktionierte USB am Raspberry und Windows-PC nicht.

Aktivier den DFU Bootloader manuell. Board an USB anstecken, Reset drücken und unmittelbar nach dem loslassen der Resettaste die Taste but=32 für etwa 1 Sekunde drücken. Der Maple blinkt dann vor sich hin. Danach ganz normal in der Arduino IDE den Sketch hochladen. Welchen COM Port man dabei in der IDE auswählt ist dabei egal.

[Ralf9]

Irgendwas passt bei dem UsbSerial noch nicht so richtig.
Bei ca jedem 5 - 10 ten Reset kommt beim UsbSerial was durcheinander. Da ist im log auch das USBD_reenumerate zu sehen.
Zwischen dem ersten CONNECTED und DISCONNECTED wird das gesendete XQ vom Maple noch nicht erkannt

Code Auswählen Erweitern

cmd(9) = AT^SQPOXQ
cmd(3) = RT?
sieht ohne das XQ so aus (Query Port Type), kommt dies vom Linux Betriebsystem?

Code Auswählen Erweitern

cmd(10) = AT^SQPORT?

Nach dem zweiten CONNECTED ist was durcheinander,
Als Antwort zu "XQ" kommt "Unsupported command"
Als Antwort zu "V" kommt die Antwort vom "XQ": "rxA=0 rxB=0 rxC=0"

Bei allen nachfolgenden gesendeten Befehlen ist es dann genauso, daß anstatt des gesendeten Befehl von Maple der zuvor gesendete Befehl empfangen wird!
Dies lässt sich nur durch einen Reset beheben.

Code Auswählen Erweitern

2020.06.08 17:54:08.088 3 : Setting sduino serial parameters to 115200,8,N,1
2020.06.08 17:54:08.089 1 : sduino/define: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.06.08 17:54:08.089 1 : sduino/init: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.06.08 17:54:08.089 1 : /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00 reappeared (sduinoRXB)
2020-06-08 17:54:08.090 SIGNALduino sduino CONNECTED
2020.06.08 17:54:08.100 3 : sduino/noMsg Parse: Watchdog enabled
...
2020.06.08 17:54:08.103 3 : sduino/noMsg Parse: detect B: Partn=0 Ver=20
2020.06.08 17:54:08.162 3 : sduino/noMsg Parse: rxA=1 rxB=1 rxC=1
2020.06.08 17:54:09.589 3 : sduino/init: disable receiver (XQ)
2020.06.08 17:54:09.590 3 : sduino SW: XQ
2020.06.08 17:54:09.600 3 : sduino/noMsg Parse: Unsupported command
2020.06.08 17:54:09.996 1 : /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00 disconnected, waiting to reappear (sduinoRXB)
2020-06-08 17:54:09.998 SIGNALduino sduinoRXB DISCONNECTED

2020.06.08 17:54:32.007 3 : Setting sduino serial parameters to 115200,8,N,1
2020.06.08 17:54:32.007 1 : sduino/define: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.06.08 17:54:32.007 1 : sduino/init: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.06.08 17:54:32.007 1 : /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00 reappeared (sduinoRXB)
2020-06-08 17:54:32.009 SIGNALduino sduino CONNECTED
2020.06.08 17:54:33.508 3 : sduino/init: disable receiver (XQ)
2020.06.08 17:54:33.508 3 : sduino SW: XQ
2020.06.08 17:54:33.519 3 : sduino/noMsg Parse: Unsupported command
2020.06.08 17:54:34.008 3 : sduino/init: get version, retry = 0
2020.06.08 17:54:34.008 3 : sduino SW: V
2020.06.08 17:54:34.018 3 : sduino/noMsg Parse: rxA=0 rxB=0 rxC=0


Ich habe bei der serialEvent Routine eine serielle debug Ausgabe eingebaut:

Code Auswählen Erweitern

void serialEvent()
{
  while (MSG_PRINTER.available())
  {
    char inChar = (char)MSG_PRINTER.read();
    Serial2.println((uint8_t)inChar);
    switch(inChar)
    {
    case '\n':
    case '\r':
    case '\0':
    case '#':
command_available=true;
Serial2.print("cmd(");
Serial2.print(cmdstring.length());
Serial2.print(") = ");
Serial2.println(cmdstring);
break;
    default:
      cmdstring += inChar;
    }
    if (cmdstring.length() > maxCmdString)
    {
cmdstring = ""; // todo die restlichen Zeichen ignorieren
MSG_PRINT(F("cmd to long! (max "));
MSG_PRINT(maxCmdString);
MSG_PRINTLN(F(")"));
    }
  }
}

Code Auswählen Erweitern

79
88
81
10
cmd(9) = AT^SQPOXQ
82
84
63
13
cmd(3) = RT?
94
66
77
67
59
...
67
65
84
13
cmd(64) = ^BMC;LL=-2583;LH=3;C=1L=32;R=40;s23;b2^^BMC;LL=-2584;LH=3;C=^CAT
94
66
77
83
59
80
48
61
45
52
49
52
57
59
80
49
45
59
67
94
67
94
66
77
83
59
80
48
61
45
52
49
52
57
59
80
49
61
59
67
80
94
67
13
cmd(0) =
10
cmd(0) =
85
110
115
117
112
112
111
114
116
101
100
32
99
111
109
109
85
110
115
117
112
112
111
114
116
101
100
32
99
111
109
109
13
cmd(17) = mUnsupported comm
10
cmd(17) = mUnsupported comm
13
cmd(17) = mUnsupported comm
10
cmd(17) = mUnsupported comm
65
85
110
115
117
112
112
111
114
116
101
100
32
99
111
109
109
84
13
cmd(18) = AUnsupported commT
65
85
110
115
117
112
112
111
114
116
101
100
32
99
111
109
109
84
13
cmd(18) = AUnsupported commT
126
0
cmd(1) = ~
120
240
126
126
0
cmd(1) = ~
120
240
126
88
81
10
cmd(2) = XQ
86
10
cmd(1) = V
86
10
cmd(1) = V
...

normal sieht es so aus

Code Auswählen Erweitern

65
84
94
83
81
80
79
82
84
63
13
cmd(10) = AT^SQPORT?
65
84
13
cmd(2) = AT
65
84
13
cmd(2) = AT
65
84
13
cmd(2) = AT
126
0
cmd(1) = ~
120
240
126
126
0
cmd(1) = ~
120
240
126
88
81
10
cmd(2) = XQ
86
10
cmd(1) = V
98
114
10
cmd(2) = br
88
69
10
cmd(2) = XE


Es macht wahrscheinlich Sinn, daß ich was einbaue, daß nach einem Reset nur XQ und V ausgewetet wird und alles andere ignoriert wird

[nagelreo]

Hallo Ralf, Hallo Telekatz,

vielen Dank für die Anregungen.
Mit Unterstützung läuft der maple-mini nun. Bootloader "maple_mini_boot20.bin" und "MSCboot_maplemini.bin" über Python am PC-USB und dem FTDI Adapter geflasht. Danach die Firmware  "MapleCUNx4_W5500_BL.bin" über den PC-USB auf den maple-mini kopiert und am Raspberry angeschlossen.

Ich hoffe, das Einrichten funktioniert etwas einfacher.

Gruß
Rolf

[RaspiLED]

Hi,
meinst Du so etwas:
https://github.com/AlphaLima/ESP32-Serial-Bridge
Gruß Arnd