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

[Ralf9]

Läuft es mit

WS36

WS34

wieder an?

[killah78]

Ja, mit WS34 empfängt er wieder Nachrichten.

Edit: ... um nach 8 Nachrichten wieder zu stoppen...

Nochmal Edit: Jetzt beim zweiten Starten läuft es schon etwas länger. Ich musste aber erst WS36 und dann WS34 machen, damit es startet.

[Ralf9]

Hat da jemand eine Idee an was das liegen könnte? @Telekatz?  @papa?

Wenn der Empfang stoppt, dann ergibt mit "WS3D" ein chip status von 1 (receive mode)

Ein C35 (MARCSTATE Register) ergibt 0D (RX)

Nach einem strobe command WS34 (Enable RX) funktioniert der Empfang wieder

[killah78]

Was ist denn "Maple_cul_Boot20_USB_410dev200427.bin"? Ist das für das MapleCUL board?
Was muss ich im SerialMonitor eingeben, damit ich SlowRF in Bank 2 speichere?
Dann könnte ich mal probieren, ob es warum auch immer stabiler läuft.

[Ralf9]

Ja das "Maple_cul_Boot20_USB_410dev200427.bin" ist für den MapleCUL

Per Default wird Bank 0 mit SlowRF initialisiert und dem Radio B zugerordnet.
In Version steht (R: B0*)

Mit
bB2

wird Radio B der Bank 2 zugeordnet:

Code Auswählen Erweitern

The bank 2 was not complete initialized, therefore the bank and radio is reseted to sduino defaults (raw e). ccFactoryReset done

[killah78]

ok, also bA2,
ich empfange hier aber nichts, während der mapleCUL einige Nachrichten reinbekommt. auf 868 SlowRF.

bs:

Code Auswählen Erweitern

Bank__ 0 1 2 3 4 5 6 7 8 9  Radio_ - - A*- - - - - - -  N_____ 0 2 0 - - - - - - -  ccmode 0 3 0 - - - - - - -    0 - SlowRF  1 - M2_IT+  2 - SlowRF


Fehlt da noch was?

[Ralf9]

SlowRF geht momentan nur mit dem zweiten cc1101 (Radio B)
Hast Du den zweiten cc1101 nicht bestückt?

[killah78]

Ah ok.
Nein bisher ist nur Radio A mit einem 868 bestückt, das 433 Stamp ist noch auf dem Weg aus China.
ich überlege, ob ich ein 433 Modul, also mit Pin, mal übergangsweise dranlöte.

[Ralf9]

so gehts einfacher

[killah78]

Ja das stimmt. Habe aber schon alles auf der Ranseyer Platine verlötet. Nur eben Radio B fehlt noch.
Ich probiere das morgen mal mit dranzubasteln, so dass Radio A und B verwendet werden.
Ich sage erstmal vielen Dank für die Hilfestellung und die vielen Infos.
Ich hoffe, dass sich das mit dem Lacrosse-Stop noch auflöst.

By the way noch eine Frage: Wirst du zum späteren Zeitpunkt auch die weiteren Seriellen Schnittstellen mit implementieren?
Und: Wird wohl Ser2Net mit dem Maple funktionieren? Da es ja nicht wirklich eine echte Serielle Schnittstelle ist...

Schönen Abend noch.

[Ralf9]

Wirst du zum späteren Zeitpunkt auch die weiteren Seriellen Schnittstellen mit implementieren?

Ja das durchreichen der seriellen habe ich vor, da werde ich beim programmieren aber Hilfe gebrauchen.
Das durchreichen der seriellen wird nur bei der LAN Version funktionieren

Wird wohl Ser2Net mit dem Maple funktionieren?

Müsste eigentlich funktionieren, einfach mal testen.

[juergs]

Ja das durchreichen der seriellen habe ich vor, da werde ich beim programmieren aber Hilfe gebrauchen.
Das durchreichen der seriellen wird nur bei der LAN Version funktionieren

Müsste eigentlich funktionieren, einfach mal testen.

Wird leider noch ein weilchen daueren, irgendwie wurde meine USB-Infrastruktur lahmgelegt.
Der Maple wird nicht mehr erkannt ...


Mit der WLAN-Bridge sind noch einige Tests zu machen bevor man das Einsetzen kann.
In der momentanen Konfiguration bauche ich ein Änderung am Perl-Modul.
Die Socket.reccv-Methoe blockiert im Moment.
In Micropython kann man aber über "select" das Empfangen asynchron, sozusagen mit Callback, machen ....
Das muss ich noch kapieren wie das geht ... 


@Ralf9
Ich habe nun Deine 0427-Version in Visual-Studio-VisualMicro (Dank an Tim Leek, er hat mir meine Lizenz angepasst  ) am Laufen... wenn der Upload mit OpenOCD+STLINK  noch klappen würde. 
.. und ich mein Testsystem dann  mit einem CC1101 zu Laufen bringe ...
Die Änderungen mit der Übergabe über die serielle Schnittstelle im Sketch würde ich dann implementieren ...

Uploading 'MapleSduino_V27_VS' to 'Generic STM32F1 series' using 'COM12'
Uploader started for board Generic STM32F1 series
Upload method will be: bootloader
Uploading via Bootloader
C:\ProgramData\vmicro\tools\openocd-0.10.0.20200213\bin\openocd.exe -d2 -s "C:\ProgramData\vmicro\tools\openocd-0.10.0.20200213/scripts/" -f "interface/stlink.cfg" -f "target/stm32f1x.cfg" -c "echo -n {****[vMicro]**** Uploading ELF :}" -c "reset_config; telnet_port disabled; program {C:\Users\js\AppData\Local\Temp\VMBuilds\MAPLES~1\STM32_~1\Release/MapleSduino_V27_VS.ino.elf} reset;reset_config;shutdown"
Open On-Chip Debugger 0.10.0+dev-01058-g853a05287 (2020-02-13-16:41)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
****[vMicro]**** Uploading ELF :Info : clock speed 1000 kHz
Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748
The uploader process failed
Info : Target voltage: 3.563444
Error: init mode failed (unable to connect to the target)
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked

Melde mich wieder, wenn alles lauffähig ist .. 

Grüße,
Jürgen

[Ralf9]

In der momentanen Konfiguration bauche ich ein Änderung am Perl-Modul.
Die Socket.reccv-Methoe blockiert im Moment.
In Micropython kann man aber über "select" das Empfangen asynchron, sozusagen mit Callback, machen ....
Das muss ich noch kapieren wie das geht ... 

Ist mir nicht klar, welche Richtung blockiert da?

Die Änderungen mit der Übergabe über die serielle Schnittstelle im Sketch würde ich dann implementieren ...

Das geht doch viel einfacher, Du musst doch nur in der Arduino IDE den USB Support deaktivieren.
Wenn Du die serielle Schnittstelle für die WLAN-Bridge verwendest, wird das USBserial nicht benötigt.

Gruß Ralf

[juergs]

Ist mir nicht klar, welche Richtung blockiert da?
Das geht doch viel einfacher, Du musst doch nur in der Arduino IDE den USB Support deaktivieren.
Wenn Du die serielle Schnittstelle für die WLAN-Bridge verwendest, wird das USBserial nicht benötigt.

Gruß Ralf

1.) socket.recv() bleibt solange stehen, bis eine Übertragung über WLAN stattfindet.
Dann wird die Serielle Schnittstelle des Targets mittels readline()  abgefragt und Daten sind dann sozusagen im Puffer.
Dann kommt wieder recv() zur Ausführung und bleibt solange dort stehen, bis eine weitere WLAN-Übertragung kommt.
Dann erst kann der Pufferinhalt des vorhergehenden seriellen Einlesens an Fhem geschickt werden.
Das ist ein ungünstiges Verhalten, das auch eine gewisse Timing-Komplexität beinhaltet ...
Die Implementierung mit "set_blocking_mode(False)" scheint nicht zu funktionieren...
Die Lösung wird sein das blockierende Element asynchron zu setzen. Das kann man wohl mittels "select"  machen ..

2.) Momentan komme ich per USB nicht an den Maple ran...
Das muss ich wieder in Ordnung bringen ...
Immerhin funktioniert mein STLINK wieder, bzw. wird erkannt ...

Beim Start des Geräts USB\VID_0000&PID_0002\5&38e97a59&0&9 ist ein Problem aufgetreten.

Treibername: usb.inf
Klassen-GUID: {36fc9e60-c465-11cf-8056-444553540000}
Dienst:
Untere Filter:
Obere Filter:
Problem: 0x2B
Problemstatus: 0x0

/edit: Wechseln des USB-Port ... 

Uploading 'MapleSduino_V27_VS' to 'Generic STM32F1 series' using 'COM41'
Uploader started for board Generic STM32F1 series
Upload method will be: bootloader
Uploading via Bootloader
C:\Users\js\AppData\Local\arduino15\packages\STM32\tools\STM32Tools\1.3.2\tools\win\maple_upload.bat COM41 2 1EAF:0003 "C:\Users\js\AppData\Local\Temp\VMBuilds\MAPLES~1\STM32_~1\Release/MapleSduino_V27_VS.ino.bin"
maple_loader v0.1
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]...
Found it!
Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=1149
Starting download: [##################################################] finished!
state( = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!

[Ralf9]

1.) socket.recv() bleibt solange stehen, bis eine Übertragung über WLAN stattfindet.
Dann wird die Serielle Schnittstelle des Targets mittels readline()  abgefragt und Daten sind dann sozusagen im Puffer.

Heisst das, daß Fhem per polling die empfangenen Daten abfragen muss?
Dies wäre timingmässig ein sehr ungünstiges Verhalten

Lässt sich nicht wie beim ESP die serielle in einer Loop abfragen?

Code Auswählen Erweitern

  if(Serial.available()){
    uint8_t len = Serial.available();
    uint8_t sbuf[len];
    Serial.readBytes(sbuf, len);

Momentan komme ich per USB nicht an den Maple ran...

Hast Du schon den Bootloader neu geflasht? Das Bootloader flashen sollte normal immer funktionieren, auch bei defektem Bootloader