wolfgangr
commented
5 years ago Have an eye on the reference implementation:
https://github.com/jeelabs/el-client/blob/master/ELClient/ELClient.h#L100
//== Responses
// Process the input stream, call this in loop() to dispatch call-back based responses.
// Callbacks on FP are invoked with an ElClientResponse pointer as argument.
// Returns the ELClientPacket if a non-callback response was received, typically this is
// used to create an ELClientResponse. Returns NULL if no response needs to be processed.
ELClientPacket *Process(void);and here I i see that this is their state machine: https://github.com/jeelabs/el-client/blob/master/ELClient/ELClient.cpp#L115
So they delay the untwining of SLIP/non-SLIP to the loop(), prepending a ring buffer ( I suppose that's what a 'stream' attached to a serial line boils down to)
Do they have to provide for a situation where SLIP command processing stalls while ohter chars have to be processed?
https://github.com/jeelabs/el-client/blob/master/ELClient/ELClient.h#L105
// Busy wait for a response with a timeout in milliseconds, returns an ELClientPacket
// if a response was recv'd and NULL otherwise. The ELClientPacket is typically used to
// create an ELClientResponse.OK, forget it. If they cann afford busy wait for Client response, they don't care about something else happening anyway...
Well .... does ESP-Link end us commands at all ???? Le't pretend we don't know....
Inspired by this hack https://hackaday.com/2017/02/13/hacking-on-the-weirdest-esp-module/#comment-5820116 I tried something similiar: MQTT from an STM32 Bluepill running mecrisp FORTH, connected to ESP-Link.
However, when I try to issue test strings, the communication between ESP-LINK and the STM32 breaks down. I have to reset both the µC at http://192.168.1.88/console.html and ESP-Link at http://192.168.1.88/log.html using the HTML-Buttons at those pages.
I suspect that some wrong command string confuses ESP-LINK and renders it in a non-responsive state.
I assume that the communication ESP-LINK <-> µC is neither pure MQTT nor SLIP but a dedicated protocol, correct?
Unfortunately, there is no MQTT in https://embello.jeelabs.org/flib/ yet.
I have repeatedly searched the issues and all docs for some spec, but the only source I found is the https://github.com/jeelabs/el-client/blob/master/ELClient/examples/mqtt/mqtt.ino However, assembling test strings from reverse engineering this very error prone, too.
It would be great to find a couple of preassembled test strings to ensure that the whole setup is working. So I could work down to more complicated functions by small changes. Just some "hello" appearing on my mqtt would be great.
Details from my setup:
esp-link {"rssi":-60, "heap_free":19992}on my mosquitto_pub, so the ESP-link <-> mosquitto is workingI'd plan to rework the whole thing using string buffer (hope to find such in mecrisp) instead of blowing the stack. Would be glad to share, of course.