ESP32 Serial aus JavaScript

Hallo zusammen,

ich habe einen ESP32, den ich per COM-Port anspreche.
Es gibt eine simple Anfrage-->Antwort Kommunikation, dann wird die Verbindung wieder gekappt.
Per Arduino IDE oder Hyperterminal funktioniert das auch wunderbar.

Verbinde ich mich per Browser (Chomium Engine vorausgesetzt), kann ich den Port auswählen und speichern.
Die Anfrage geht raus, die Antwort kommt zurück. Nun schließe ich den Port und der ESP32 rebootet.
Nach gründlicher Recherche scheint der Return to Sender Parameter ein Problem darzustellen.

Den Parameter kann man leider erst nach dem Öffnen setzen, was offenbar wiederum zu einem Reboot führt. Jetzt also vorher, dafür nicht mehr beim Schließen :unamused:

Hat sich damit schon mal jemand befasst einen ESP32 per Browser mit webSerial zu nutzen?

Reboot nach dem Close:
await port.open({ baudRate: settings.BaudRate });

Reboot nach dem Open, nicht mehr nach dem Close:

await port.open({ baudRate: settings.BaudRate });
port.setSignals({dataTerminalReady: false, requestToSend: false, break: false});

Natürlich habe ich mit den Parametern rumgespielt, allerdings ohne Verbesserung.

Vielleicht ist es auch einfach eine nicht steuerbare Limitierung der Implementierung Web Serial API in Chromium :man_shrugging:t2:

Wer sich das nachbauen möchte, geht das in etwa so:

let port;
async function ConnectComPort(settingsText){
    try {
        const ports = await navigator.serial.getPorts();
        console.log(ports);
        if(ports.length > 0)
            port = ports[0];
        else
            port = await RaiseComPortSelection();
        const settings = JSON.parse(settingsText);
        
        await port.open(settings);        
}
async function RaiseComPortSelection(){
    try {
        port = await navigator.serial.requestPort();
        return port;
    } catch (error) { 
        return null;
    }
}

Auf deinem ESP32 Board ist eine Schaltung die RTS und DTR auswertet und damit einen Reset auslöst. Vielleicht kannst du die vor dem Öffnen setzen.

Hallo,
schau mal das hier zu der Schaltung

Teilauszug aus
https://esp32-server.de/schaltplan/

Tausche ich die Reihenfolge der Aufrufe, dann erhalte ich leider die Meldung:

Uncaught (in promise) InvalidStateError: Failed to execute 'setSignals' on 'SerialPort': The port is closed.
at ConnectComPort

Entsprechend kann ich die Einstellungen erst nach dem Connect setzen, was zu einem Reboot führt.
Oder ich lasse es wie es ist und nach dem Beenden gibt es einen Reboot, da DTR & RTS schließlich schon gesetzt waren :sweat_smile:

Dann denke ich, dass es eine Limitierung seitens der API ist. Im Open() kann das leider nicht als parameter/setting mitgegeben werden.
Auf dem ESP wollte ich jetzt keine Leiterbahnen trennen und beim flashen brücken.
Also muss ich wohl, zumindest in diesem speziellen Fall, damit leben.

Hallo,
ich konnte mir vorstellen das es irgendwo eine Parametereinstellung gibt um die Hardware Flusskontrolle für DTR & RTS abzuschalten. Die wird ja teilweise bei RS232 genutzt.
Eventuell bei Einstellug der Seriell Parameter ( boudrate usw ) als option.

Nein, genau das schreibe ich ja eingangs.
Im Port.Open() kann man lediglich

  • baudRate
  • dataBits
  • stopBits
  • parity
  • flowControl

mitgeben.

  • dataTerminalReady
  • requestToSend
  • break

sind die Optionen für Port.setSignals(). Und das kann ich erst ausführen, nachdem der Port geöffnet wurde.
Das ist ja das Problem :man_shrugging:t2:

Prinzipiell wäre mir der Reboot auch egal, wenn nicht ein Display die letzte getätigte Eingabe anzeigen würde. Die verschwindet dann natürlich. Oder ich starte mit einem Reboot, bekomme die ganzen ESP Start-Meldungen und kann dann nach einem kurzen delay fortfahren.

das sollte es doch sein

1 Like

Schön wär´s :sweat_smile:


Source

Auch wenn das grundsätzlich vielversprechend klingt:


Source

Wenn ich quasi in´s Gegenteil gehe und auf flowControl: hardware gehe, rebootet der ESP nicht mehr. Weder beim Öffnen, noch beim Schließen. Yay :partying_face:
Nur leider empfängt er dann auch nichts mehr.

Schiebe ich dann per setSignals RTS und DTR false hinterher, gibt es einen Error. Klar, ist ja nun auch der Hardware überlassen.

Jede Kombination ist geprüft, ich denke ich belasse es dabei.

PS: Der Arduino Uno startet immer nach jeder Verbindung neu. Nimmt sich ca. 1,4 Sekunden Zeit bis er auf den Input reagiert und bleibt dann aber aktiv, bis zur nächsten Verbindung.

Der Original UNO hat eine durchtrennbare und wieder zulötbare Brücke dafür ( s. Bild) , aber ein 10µF Kondensator zwischen GND und RESET verhindert auch, dass vom PC aus ein RESET ausgelöst wird (leider auch beim Upload)
Die 1,4 Sekunden wartet der Bootloader, ob ein neuer Sketch kommt ...