Open Hard- & Software [ DokuWiki WebSites MediaWiki NextCloud ]

Projekt-Kürzel: SCD
Projekt-Header: ScriptingCommandDispatcher

• MC : MicroController
• MP : MicroPython
• PC : PersonalComputer
• Command : Text (drei Zeichen) (Beispiel: MPA)
• Parameter : Text (1..Nc Zeichen) mit Argument eines Commands
• CommandLine : Textzeile mit Command und Np-Parametern, Trennung: ' ' , Abschluss: '\r\n'
• LFS : LocalFileSystem
• CFS : SDCard-FileSystem

• MicroController mit installiertem MicroPython-Image
• typisch Esp32UnoBoard, Esp32NanoBoard mit Interfaces Uart, Wlan, Lan, Bt
• Stm32F407Board mit Interfaces Uart, Lan

• MicroPython (für MC, hier Esp32UnoBoard)
• VisualStudioCode/PyMakr oder Thonny (auf PC) zur Programmierung der MP-Scripts
• Anaconda/Spyder (auf PC) zur Programmierung der PC-SCD-Software (GUIs, CLs)

Das Projekt SCD ermöglicht über einen Command-Dispatcher

• den Upload/Verwaltung von MP-Scripts (reine Texte!) vom PC zum MC über Wlan oder Uart
• die Abarbeitung einzelner MP-Commands (ohne Compiler)
• die Abarbeitung von MP-Scripts (ohne Compiler)

Die SCD-Software wird auf einer geeigneten SCD-Hardware installiert (Esp32/Stm32F407).
Wegen der Script-Verarbeitung ist SCD nicht für Echtzeitprozesse geeignet.
Das SCD-Board verfügt über mindestens ein Uart-Interface zur Kommunikation mit weiteren Echtzeit-Prozessoren.

Scripting : Upload / Download / Execute von MicroPython-Scripts für den Esp32.
Die Script-Execution erfolgt im MultiTasking parallel zu allen anderen Threads.

• Aufbau eines Modells des IT01 mit Bricks
• Hardware des IT01:
  • PressureSensor
  • DosingValve(DCMotor, Sensor(?))
  • Acht OnOffValves
  • Display(4×20)
  • Keyboard(4×4)
  • Drucker(Uart, Emulation über RPi-Hdmi-Display?)
• Software IT01Manager:
  • Tiny: VSCode,MicroPython für Esp32(Interfaces UartPC/BtAD/WlanUdp/UartUC)
  • Pro: VSCode,C++ für Esp32(Interfaces UartPC/BtAD/WlanUdp/LanUdp/UartUC)
  • VSCode,C++ für Stm32F103(UartUC)
  • Windows Python-GUI mit UCUart über USB-Uart-Converter(UartUC)

• VSCode mit C++
• CommandDispatcher (vormals: @LSO, @LSF) für \$LSO, \$LSF, also mit Header \$ !
• daher Dispatcher.ExecuteCommand: Detektion auf @ (Command-Esp32) / \$ (Command-ChildProcessor)
• VSCode mit Stm32F103C8T6-Module programmieren

• C++-Files compiled into MicroPython.bin
• MicroPython external C modules

• Esp32(C++, VSCode) mit UartPC, UartUC(Chain), BtUart und WlanUdp
• entweder: RPiPico(MicroPython, VSCode) mit UartUC(Chain)
• oder: Esp32(MiniModule, VSCode)(MicroPython, VSCode) mit UartUC(Chain), SDCard(?)
• Stm32xxx(C++, VSCode) mit UartUC(Chain)

• OOO Hardware: weiterer Stm32F103-Controller
• Verkettung Stm32F103-TxD-/RxD-Pins mit Esp32-TxD-/RxD-Pins

• OOO DokuWiki:pages:module:micropython:Esp32SDCard erzeugen!!!
• OOO Esp32ExecuteFile: die letzten beiden Esp32/Pc-Einträge müssen noch auf Esp32ExecuteFile transformiert werden!

• später (ProVersion): Esp32-SDCard in C++
• später (ProVersion): Esp32-Lan in C++
• weitermachen mit TinyVersion: Esp32-MicroPyton: kein Lan, keine SDCard
• daher: löschen der SDCard.py-Datei

• Sequentieller Zugriff auf beide FileSystems:
  • MFS : MemeoryFileSystem(default)
  • CFS : CardFileSystem
• Basis: 2201161640_Esp32SDCard_02V02_wr8000lines.zip
• — gilt nur für ESP32(MicroPython, SriptingCommandDispatcher) —
• Ergebnis: SDCard unter MicroPython nur sehr eingeschränkt nutzbar!
• Nur einmal Wechsel von MFS → CFS möglich!
• Kein Wechsel von CFS → MFS möglich!
• notwendiger SoftSystemReset am Program-Ende!
• default: MFS mounted
• kein umount von MFS möglich
• alle Missergebnisse unter Esp32SDCard
• damit: ESP32(MicroPython, SriptingCommandDispatcher)
  • KEIN LAN möglich
  • KEIN Wechsel MFS↔CFS
• → Esp32 nur als Tiny(Ohne SDCard, Lan) in MicroPython einsetzbar…

• Fehler im FileSystem???
  • exec(open('blinky.py').read()) wird ausgeführt
  • 'demoy.py' aber nicht, da nicht auf FS, obwohl mehrfach Upload versucht???!!!
  • weiter mit blinky, wird jetzt ausgeführt:
  • secure Esp32: 2201221613_Esp32ScriptingCommandDispatcher.zip
  • secure PC: 2201221613_PcScriptingCommandDispatcher.zip
  • ganz sicher: exec(exec(open(<fileonsdcard>[.py]).read()) wird nur mit Files auf SDCard ausgeführt,
  • wenn SDCard noch geöffnet ist !!!!
  • so, ENDLICH Fehler gefunden:
    • Wird eine SDCard aktiv an Esp32 angeschlossen UND bleibt(!) eine Protocol-Datei geöffnet, greift
    • > exec(open('blinky.py').read(), globals(), locals())
    • NICHT auf das LFS-LocalFileSystem zu, sondern auf die Files der SDCard!
    • → IMMER nach SD-Access File.open() auch wieder schliessen : File.close() !!!
• 2201221809_Esp32ScriptingCommandDispatcher_01V09.zip
• 2201221809_PcScriptingCommandDispatcher_01V09.zip
• OOO die letzten beiden Esp32/Pc-Einträge müssen noch auf Esp32ExecuteFile transformiert werden!

• (deutliche) Übergabe von globalen und lokalen Übergabeparametern: Integer-Variable
• (deutliche) Übergabe von globalen und lokalen Übergabeparametern: Class-Instanzen
• 2201221134_Esp32ExecuteFile_01V03.zip

>>>
*** Esp32ExecuteFile: begin
########################################
--- Locals -------------------------------
{'Handler': <CHandler object at 3ffe5880>, 'HAN': <module 'Handler' from 'Handler.py'>, 'gc': <module 'gc'>, 'GInteger': 13004, 'GCalculator': <CCalculator object at 3ffe5140>, 'CAL': <module 'Calculator' from 'Calculator.py'>, 'bdev': <Partition type=1, subtype=129, address=2097152, size=2097152, label=vfs, encrypted=0>, 'TIM': <module 'utime'>, 'I': 2, '__name__': '__main__', 'Execute': <function Execute at 0x3ffea3d0>, 'time': <module 'utime'>, 'uos': <module 'uos'>}
--- Globals ------------------------------
{'Handler': <CHandler object at 3ffe5880>, 'HAN': <module 'Handler' from 'Handler.py'>, 'gc': <module 'gc'>, 'GInteger': 13004, 'GCalculator': <CCalculator object at 3ffe5140>, 'CAL': <module 'Calculator' from 'Calculator.py'>, 'bdev': <Partition type=1, subtype=129, address=2097152, size=2097152, label=vfs, encrypted=0>, 'TIM': <module 'utime'>, 'I': 2, '__name__': '__main__', 'Execute': <function Execute at 0x3ffea3d0>, 'time': <module 'utime'>, 'uos': <module 'uos'>}
------------------------------------------
--- Begin --------------------------------
GInteger[13000]
GCalculator[321]
--- Main --------------------------------
GInteger[13000]
GCalculator[321]
Execute:begin
--- blinky:begin
--- blinky: LLL[13000]
--- blinky: Calculator[321]
--- blinky: [13001]
--- blinky: Calculator[10321]
--- blinky:end
Execute:end
GInteger[13001]
GCalculator[10321]
--- End --------------------------------
GInteger[13001]
GCalculator[10321]
########################################
--- Locals -------------------------------
{'Handler': <CHandler object at 3ffeb7e0>, 'HAN': <module 'Handler' from 'Handler.py'>, 'gc': <module 'gc'>, 'GInteger': 13001, 'GCalculator': <CCalculator object at 3ffea3e0>, 'CAL': <module 'Calculator' from 'Calculator.py'>, 'bdev': <Partition type=1, subtype=129, address=2097152, size=2097152, label=vfs, encrypted=0>, 'TIM': <module 'utime'>, 'I': 0, '__name__': '__main__', 'Execute': <function Execute at 0x3ffea3d0>, 'time': <module 'utime'>, 'uos': <module 'uos'>}
--- Globals ------------------------------
{'Handler': <CHandler object at 3ffeb7e0>, 'HAN': <module 'Handler' from 'Handler.py'>, 'gc': <module 'gc'>, 'GInteger': 13001, 'GCalculator': <CCalculator object at 3ffea3e0>, 'CAL': <module 'Calculator' from 'Calculator.py'>, 'bdev': <Partition type=1, subtype=129, address=2097152, size=2097152, label=vfs, encrypted=0>, 'TIM': <module 'utime'>, 'I': 0, '__name__': '__main__', 'Execute': <function Execute at 0x3ffea3d0>, 'time': <module 'utime'>, 'uos': <module 'uos'>}
------------------------------------------
Handler[4321]
--- Handler --------------------------------
Handler[4321]
Handler-Execute:begin
--- blinky:begin
--- blinky: LLL[13001]
--- blinky: Calculator[10321]
--- blinky: [13002]
--- blinky: Calculator[20321]
--- blinky:end
Handler-Execute:end
Handler[8642]
--- Handler --------------------------------
Handler[8642]
Handler-Execute:begin
--- blinky:begin
--- blinky: LLL[13002]
--- blinky: Calculator[20321]
--- blinky: [13003]
--- blinky: Calculator[30321]
--- blinky:end
Handler-Execute:end
Handler[17284]
--- Handler --------------------------------
Handler[17284]
Handler-Execute:begin
--- blinky:begin
--- blinky: LLL[13003]
--- blinky: Calculator[30321]
--- blinky: [13004]
--- blinky: Calculator[40321]
--- blinky:end
Handler-Execute:end
Handler[34568]
--- End --------------------------------
GInteger[13004]
GCalculator[40321]
Handler[34568]
########################################
*** Esp32ExecuteFile: end
♦♦>

• Basis MicroPython: 2201211901_Esp32ExecuteFile_01V02.zip
• (deutliche) Übergabe von globalen Übergabeparametern: Integer-Variable
• (deutliche) Übergabe von globalen Übergabeparametern: Class-Instanzen
• 2201221038_Esp32ExecuteFileGlobalsIC.zip
• 

• (von unten:) Ausbau des Dispatchers mit neuen Commands:
  • ???!!! Problem: Übergabe von globalen SystemVariablen an Scripts !!!???
  • Übergabe globals() und locals() gelöst Python auf dem PC
  • DokuWiki: !!! OOO !!! noch pages:module:python:ExecFile:ExecFile.txt erzeugen !!!
  • Parameter-Übergabe in Python: 2201192121_ExecFile_01V01.zip
  • Parameter-Übergabe in MicroPython (als Basis für XPS…-Commands):
  • 2201211858_Esp32ExecuteFile_01V01.zip
  • ÜbergabeParameter Local: 2201211901_Esp32ExecuteFile_01V02.zip

#
class CCalculator():
    def __init__(self):
        self.Result = 123
        return
    def Add(self, a, b):
        self.Result = a + b
        return self.Result
#
def Execute():
    print('Execute:begin')
    L = 4321
    exec(open('blinky.py').read(), globals(), locals())
    print('Execute:end')
    return    
#
print('*** Esp32ExecuteFile: begin')
print('---------------------------------------------------------------------')
print(locals())
print('---------------------------------------------------------------------')
print(globals())
print('---------------------------------------------------------------------')
C = CCalculator()
print(C.Result)
C.Add(3, 4)
print(C.Result)
L = 4321
Execute()
print(C.Result)
#
print('*** Esp32ExecuteFile: end')

import time as TIM
#
print('blinky:begin')
# NC !!! global C
print('Local L[{}]'.format(L))
#
for I in range(10, 13):
    #
    C.Add(1, I)
    print('.' + str(C.Result) + '.')
    TIM.sleep(0.5)
print('blinky:end')

• UPS - Upload Python-Script <filename.py>
• DPS - Download Python-Script <filename.py>
• mit Scripting - daher auch SCD-ScriptingCommandDispatcher
• MultiTasking Verarbeitung von uP-Scripts (execute filename.py):
• XPS - Execute Python-Script <filename.py>
• APS - Abort (all) Python-Script(s) <none>

• OOO RPiZW mit Netzteil von WBoogaerts ausprobieren!!!
• Wunsch: RPiZW mit Python und Uart(-UartUC!)
• ————————————
• ZielA: RPiZW für PSR-PythonScriptRemoting über UartUC
• ZielB: RPi3/4 GuiTerminal mit PSR über UartUC
• ZielC: RPiP(ico) mit PSR über UartUC
• ————————————
• hat überhaupt nicht funktioniert, da Netzteile für RPiZW nicht genügend Spannung gebracht haben!
• Austausch von RPiZW mit RPi3B
• Anschluss von 20pin-RPi-Steckerleiste: Uart(RxPin:GPIO15|TxPin:GPIO14)
• Python-Library: wiringPi
• Installation: NC! sudo apt-get install wiringpi
• Top-Erklärung Uart-RPi
• GESCHAFFT: Uart0 auf RaspberryPi-Stecker(rechts RPi-Remote-Desktop)
• kommuniziert mit 115200baud → FTDI-Uart-USB → mit PC-USB und Terminal(links)

• um AdressCharacter (0..9, A..Z) erweiterte Syntax: <@><address>< ><command>[< ><parameteri>]<CR><LF>
• bisher Commands:
  • X LSO - LedSystemOn
  • X LSF - LedSystemOff
• X Ausbau des Dispatchers mit neuen Keyboard-Commands:
  • X EKB - EnableKeyboard
  • X DKB - DisableKeyboard
  • X APR - AbortProgramReset (Dispatcher.AbortProgramReset())
  • 2201191620_Esp32ScriptingCommandDispatcher_01V07_commanddisplay.zip
• X Ausbau des Dispatchers mit neuen LCDisplay-Commands:
  • X CLD - Clear Display
  • X WDT <r> <c> <t> - WriteDisplayText Row Column Text
  • X SDO - SetDisplayOn
  • X SDF - SetDisplayOff
  • X SBO - SetBacklightOn
  • X SBF - SetBacklightOff
  • 2201191707_Esp32ScriptingCommandDispatcher_01V08_commanddisplay.zip

• Ausbau des Dispatchers mit neuen Commands:
  • ???!!! Problem: Übergabe von globalen SystemVariablen an Scripts !!!???
  • UPS - Upload Python-Script <filename.py>
  • DPS - Download Python-Script <filename.py>
  • mit Scripting - daher auch SCD-ScriptingCommandDispatcher
  • MultiTasking Verarbeitung von uP-Scripts (execute filename.py):
  • XPS - Execute Python-Script <filename.py>
  • APS - Abort (all) Python-Script(s) <none>

• / (nicht) alle Hardware Threads umwandeln in Execute-Methoden
• X Nur noch 3 Threads:
  • X ThreadMain : existiert per Definition, Main-Loop
  • / ThreadInterface :
    • ALLE sleep()s eleminieren!
    • / KEIN UartPC.Execute, Uart-Thread bleibt erhalten!
    • / KEIN UartUC.Execute, Uart-Thread bleibt erhalten!
    • X BtUartAD.Execute
    • X WlanUdpPC.Execute
  • X ThreadController :
    • ALLE sleep()s eleminieren!
    • X Keyboard4x4.Execute
    • X LCDisplayI2C.Execute
    • X SDCard.Execute
• Ausgangsversion:
• 2201161933_Esp32ScriptingCommandDispatcher_NearlyOKwithSDCard.zip
• Reduktion auf drei Threads:
• 2201191027_Esp32ScriptingCommandDispatcher_01V05_minimalthread.zip
• mit DEBUG- und ACTIVITY-Constants:
• 2201191147_Esp32ScriptingCommandDispatcher_01V06_ifdef.zip

• MinimalProgram zum Test der Maxizahl von parallelen Threads
• MinimalProgram : die Anzahl der parallelen Threads in MicroPython auf 16 begrenzt!
• “cannot create thread” : vermutlich RAM-Mangel, da jeder Thread 4kB für Stack benötigt 👎👎👎
• falsch: gc.collect / gc.free_ram Ausgabe zeigt, dass genügend RAM während der parallelen 16-fach Thread-Verarbeitung (100kB !!!) vorhanden ist!
• ABER: am RAM kann es nicht liegen: in den aufeinander folgenden Thread-States(start/busy/abort/end) sind immerhin noch 100kB(!!!) RAM FREI????
• Ungelöstes Problem: ??? Welcher Mechanismus verhindert den Start von mehr als 16 Threads bei Minimal-Programm ???

• precompiled Python-Files
• MPY-Files
• am 220118 versucht:
  • Modul: /Downloads/python/_Esp32MpyFile
  • !!! noch Module-DokuWiki erzeugen !!!
  • precompile: python -m mpy-cross Esp32MpyFile.py
  • erzeugt: Esp32MpyFile.mpy
  • aber: ~dieser *.mpy-File nur auf PC lauffähig, nicht auf MicroController!

• Events werden immer in Row3 (unterste Zeile) des Displays ausgegeben
• LedSystem mit OnEvent ausstatten
• Erzeugung eines Sekunden-Events mit !EST <hh>:<mm>:<ss>
• Vollversion: 2201131550_Esp32ScriptingCommandDispatcher_01V02.zip
• Vollversion: 2201131550_PcScriptingCommandDispatcher_01V02.zip

• Keine Änderung boot.py
• Erzeugung/Speicherung von main.py mit execfile('Esp32ScriptingCommandDispatcher.py')

• Dispatcher.Commands (entsprechend Dispatcher.Events)
• volle kreuz/quer-Kommunikation über UsbUart(PC-UC), BluetoothUart(Tablet-UC), WlanUdp(PC-UC)
• Generierung KeyCode-Events mit Tastatur4x4
• Ansteuerung LCDisplayI2C
• 2201131106_Esp32ScriptingCommandDispatcher_01V01.zip
• 2201131106_PcScriptingCommandDispatcher_01V01.zip

• Versuch: CB Keyboard4x4_OnKeyEvent pushed nur noch Event → EventLines(Dispatcher)
• Main: Dispatcher.Execute → BtUartAD- / WlanUdpPC- / UartUC- / UartPC.TxLine(event)
• 2201130933_Esp32ScriptingCommandDispatcher_00V08.zip

• Zusatz-Hardware: LCDisplayI2C
• Version mit LCDisplay: 2201121411_Esp32ScriptingCommandDispatcher_00V04_lcdisplay.zip
• jetzt auch mit UartUC (bisher CreateThread-Exceeption) :
• 2201121525_Esp32ScriptingCommandDispatcher_00V05_uartuc.zip
• ab und zu: Problem bei Bt-Connection mit AndroidDevice (Connection failed gatt status 133)
• Lösung: noch einmal verbinden!!!!
• 2201121606_Esp32ScriptingCommandDispatcher_00V06.zip

• Zusatz-Hardware: Keyboard4x4
• Keyboard-Tastendruck sendet Event zu allen (Uart/Bt/Wlan-)Interfaces
• 2201122328_Esp32ScriptingCommandDispatcher_00V07.zip

• mit Scripting - daher auch SCD-ScriptingCommandDispatcher
• MultiTasking Verarbeitung von uP-Scripts (execute file.py)
• Ausbau des Dispatchers mit neuen Commands:
  • UPS - Upload Python-Script <filename.py>
  • DPS - Download Python-Script <filename.py>
  • XPS - Execute Python-Script <filename.py>
  • APS - Abort (all) Python-Script(s) <none>
• Ausbau des Dispatchers mit neuen LCDisplay-Commands:
  • WTD <r> <c> <t> - WriteTextDisplay Row Column Text
  • CLD - Clear Display
• Ausbau des Dispatchers mit neuen Keyboard-Commands:
  • EKB - EnableKeyboard
  • DKB - DisableKeyboard

• !!! OOO !!! Schaltplan SCD
• SDCard(Spi-Interface) an Esp32/MicroPython
• MicroController UC als ChildProcessor an Uart (↔Esp32)

• PC(!): CommandDispatcher
  • Gui Tkinter mit Listbox, Terminal, CommandButtons
  • Command-Fifo
  • Definition Command-Software-Handshake
  • Test mit Esp32 : Esp32UdpClientServer02V01

• CommandLineDispatcher für Uart, Bt, Wlan

• X Neues Modul: CommandLineDispatcher
• X CCommand, CDispatcher
• O Analyse Command from received line
• O Execute Command
• O MultiLine-Fifo-Support (mit List [])

• X Esp32-Plattform mit MicroPython
• X Parallelisierung von MicroPython-Process-Scripten
• – Esp32 mit MicroPython-CommandLine-Interfaces: Uart, Wlan, Bt | später auch Lan mit W5500
• O MiroPython-Scripts: Upload / Download / Execute (in eigenem Thread mit System-Synchronistion)
• O Erweiterung mit RealTime-Prozessoren (Stm32F407) unter Arduino-C++
• O Stm32: eine Uart zur bidirektionalen Kommunikation mit Esp32 (Uart2/3)
• O eventuell zweiter Stm32 ebenfalls mit bidirektionaler Kommunikation mit Esp32 (Uart3/2)
• O Esp32 → Stm32: Durchreichen der Esp32-detektierten Commands (Uart, Wlan, Bt) zum Stm32
• O Rückmeldung / SystemEvents Stm32 → Esp32 → Uart, Wlan, Bt

• Kapselung aller System-Variablen (CpuTemperature,…)
• Collector für Commands/Responses für lokale Hardware-Ressourcen(BreadBoard!):
  • LedSystem
  • LedQuad(Uart1, Wlan, Bt, (Lan))
  • DHT22: Temperature/Humidity(CLK, DATA, 5V0, GND) * Pressure/Humidity

• Basis: 2201112144_Esp32ScriptingCommandDispatcher_00V02
• Dispatcher soll CBfunction erhalten
• If-Verteiler zur Ausführung von Commands
• 2201121256_Esp32ScriptingCommandDispatcher_00V03.zip

• Neues Projekt: ScriptingCommandDispytcher
• Kopie aller letzten Uart/Bt/WlanUdp-Scripts in das neue SCD-Verzeichnis
• Zusätze: Thread.py/Lines.py/Define
• Version: 2201112112_Esp32ScriptingCommandDispatcher_00V01
• Version mit Bt-Klassenaufspaltung: 2201112144_Esp32ScriptingCommandDispatcher_00V02
• Uart-/Bt-/Wlan-Functions IsBusy(self) einführen und in MainLoop nur Abarbeitung, wenn alle Threads aktiv!

• Optimierung des SourceCodes: 2201102238_Esp32BtTxRxLine_00V03.zip
• Optimierung des SourceCodes: 2201111247_Esp32BtTxRxLine_00V04.zip
• mit Open/Close/Thread/RxTxLine: 2201111645_Esp32BtTxRxLine_01V01.zip
• Version OOP aufgeräumt: 2201111717_Esp32BtTxRxLine_01V02.zip
• funktioniert wiederholbar auf Android-Devices unter BT-Terminal

• C++ BtSerial funktioniert mit Android- & Windows-Terminal
• uP dagegen nur mit Android-Terminal
• Suche nach Bt bzw. BtBle-Uart-Terminal-Example erfolglos:
• aktuell nur BtUart über Android- (und nicht Win-/Lin-)Terminal benutzbar
• keine Change, wenn mit BtDeviceNames oder UUIDs gespielt wird -
• Reste lassen sich nur teilweise mit DeviceManager ShowHidden beseitigen!

• neuer Projektname: Esp32UartTxRxLine
• CUart: Thread: Open start / Close abort, lokale Thread-CB, external: OnTxLine, OnRxLine
• CUart: Callback: OnTxLine, OnRxLine
• CUart: Constructor: uartid, txpin, rxpin, ontxline, onrxline
• CUart: Handler: Open, Close
• CUart: Thread-Busy:
  • 0: RxData - convert/collect rxline
  • 1: first: RxData - callback
  • 2: second: TxData - send / callback
• CUart: RxLine:
  • erste Möglichkeit: Rx-Callback definieren und damit automatisch (in CB) RxLine verarbeiten
  • zweite Möglickeit: (Rx-Callback == None) Pollen mit (0 < len(Uart.RxLine()))
• CUart: TxLine: Senden von TxLines mit Uart.TxLine(txline)
• 2201091626_Esp32UartTxRxLine_01V01.zip
• 2201092059_Esp32WlanUdpTxRxLine_01V01.zip
• 2201092059_PcWlanUdpTxRxLine_01V01.zip

• XXX Neue BT-Dongle LogiLink und TP-Link ausprobieren!!!
• keine Änderung, ebenso kann Esp32BtUart nicht mit PC über UsbUart kommunizieren

• Versuch, alle lokalen Ressourcen einzubinden
  • 2112161443_Esp32LCDisplayI2C_01V01
  • 2112251413_Esp32DisplayKey_01V03
  • LedSystem
• noch nicht verwendet: 2112312248_PcWlanUdpThread_01V01
• Versuch, alle Interfaces einzubinden
  • 2112261253_Esp32UartThread_01V01
  • 2112271828_Esp32BtThread_01V04_onlyPhoneTablet
  • 2112312248_Esp32WlanUdpThread_01V01
  • erkannte Notwendigkeit: Uart/Bt/Wlan(/Lan) müssen gleiche CB-Struktur besitzen
  • daher Uart/Bt/Wlan in neuen Einzelversionen optimieren

• Esp32ScriptingCommandDispatcher
  • Übernahme Module 2112312248_Esp32WlanUdpThread_01V01
  • Umbenennen SCD
• Zwei neue Modul-Verzeichnisse (in Downloads/pathon):
  • PcScriptingCommandDispatcher
  • Esp32ScriptingCommandDispatcher

• der bisherigen Ergebnisse (PC:Python - ESP32:MicroPython):
  • Pc/Esp32-Uart-Thread
    • PC-Terminal: HTerm (Win & Lin)
    • 2112261253_Esp32UartThread_01V01.zip
  • Pc/Esp32-Wlan(-Udp)-Thread
    • 2112312248_PcWlanUdpThread_01V01.zip
    • 2112312248_Esp32WlanUdpThread_01V01.zip
  • AndroidTablet/Esp32-Bt-Thread
    • GooglePlay: suchen nach "Serial Bluetooth Terminal"
    • 2112271828_Esp32BtThread_01V04_onlyPhoneTablet.zip

• PcWlanUdpThread korrespondierend mit
• Esp32WlanUdpThread

• Wiederherstellung der Projekte
  • Esp32, MicroPython: 2112131937_Esp32UdpClientServer_02V03
  • PC, Python:2112131938_UdpClientServer_02V03
• Zusammenführung in Esp32WlanThread

• zwischen PC und PC - Problem
• zwischen PC und Phone/Tablet - ?
• zwischen ESP32 und Phone/Tablet - ok
• zwischen ESP32 und PC aufbauen - nicht reproduzierbare Probleme, abhängig vom Dongle-Typ

• Auf allen möglichen Linux/Windows-Laptops habe ich mit eingebauten BT bzw. drangesteckten USB-BT-Dongles nur Probleme -
• mal werden die ESP32-BT-Devices erkannt , mal nicht, der allergrösste SCHEISS 👎👎
• Letzter Versuch: Kauf eines ORIGINAL Win10/BT4-USBDongles von LogiLink und von TP-Link, auf jeden Fall morgen erst einmal Wlan-Communication…

• bisher ein völlig hoffnungsloser Kampf:
• mit Handy / Tablet sieht die Et-Connection mittlerweise erfolgreich aus
• mit PC überhaupt nicht👎👎👎
• C++-Version Esp32BluetoothSerial funktioniert dagegen mit PC-Terminal - warum auch immer??!!
• vermutlich Pairing in der MicroPython-Version anders als in C++-Library?!
• Jetzt noch letzter Versuch, Esp32WlanThread entsprechend Esp32BtThread und Esp32UartThread zu programmieren…

• 211225: jetzt wieder Minimal-Multithreading mit Esp32-Uart-Wlan-Bt
• parallele Command/Response Verarbeitung über alle In/Out-Interfaces
• Basis-Minimal-Projekt: Esp32UartBtWlan (Multithreading)

• Dual-Threading Display / Keyboard Application zur parallelen Verarbeitung von Esp32-IO
• Esp32DisplayKey BasisModul Esp32 mit LCDisplayI2C und Keyboard4x4(IOPins) mit Threading aber ohne CommandDispatcher

• gleichzeitig: Thread1: execfile('ProcessA.py')
• und parallel: Thread2: execfile('ProcessB.py')
• und Hauptprogramm ausführen lassen.
• Ziel: CommandDispatcher (mit Threads Uart, Bt, Wlan, Lan) und
• parallel execfile(commandscript.py) ausführen
• MultiProcessExecution

• Reduktion unnötiger Callback-Funktionen
• PC: UdpClientServer02V03
• Esp32: Esp32UdpClientServer02V03

• Esp32UdpClientServer02V01 - Esp32 : UdpClientServer: Senden/Empfangen Udp-Data von PC (Thread, NonBlocking)
• Esp32UdpClientServer01V01 - Client- und Server-MicroPython-Script zum Empfangen / Senden von UDP-Daten
• Esp32UnoBoard/MicroPython : Wlan / Scan
• Transmit/Receive TextLines

• UdpClientServer - Senden und Empfangen von UDP-Datenpaketen
• Transmit/Receive TextLines
• Unidirektionales Senden und Empfangen von UDP-Datenpaketen (NoBlocking)
• Bidirektionales Senden und Empfangen von UDP-Datenpaketen (OOP, Threading, NoBlocking)

• Esp32 : Basis-Module
  • Esp32UnoBoard/MicroPython : Threading [Esp32CheckThreading]
  • Esp32UnoBoard/MicroPython : Libraries [Esp32CheckLedSystem]
  • Esp32UnoBoard/MicroPython : Libraries [Esp32CheckMath]
  • Esp32UnoBoard mit MicroPython

Open Hard- & Software [ DokuWiki WebSites MediaWiki NextCloud ]