recommended esp reset about wifispi HOT 31 CLOSED

i did a port myself using 3 megabaud bidirectional uart and most of the core & libraries :)

from wifispi.

@JAndrassy , you're right, it's a major issue. I wonder how they sorted it out in original Wifi shield for Arduino.
I'll add a reset command to the interface. It would help when we've not lost the connection with the ESP yet.
@tonton81 : great! I was thinking of it myself, especially with the ESP-M3 module.

from wifispi.

esp-m3?
never heard of it :)
AsyncUDP, AsyncMQTT, AsyncWebsockets were ported to a non-wifi compliant mcu, the AT command set really sucks. I'm building a workhorse currently and have somewhere like 100 methods in a class that bring transparency (including handlers) over to it, with bauds running 2 000 000 - 3 000 000 with CRC checks as well. The beauty of the transparency is, if the core changes anything through updates, library is not affected. Almost all functions including their original returns are implemented. It's getting pretty crazy but I'm still working on it :)

Just an idea, I'm able to run Wifiscan.ino ESP demo on the other MCU just by changing the header and enabling the serial port, no constructor needed

from wifispi.

M3: I bought a couple of them, they are based on ESP8285 but they are basically made for serial communication so I could not run the library on them. Just google. The firmware is identical to ESP8266.

Regarding the serial communication: I like the master-slave idea, for full duplex we'd need 4 channels. We can't mix commands and data. So it seemed to me that converting the library to serial communication would require constant polling of the ESP and I wasn't quite happy about it.

from wifispi.

oh contrary, data goes in and out both ways
no polling, you send what you want, you get the response, if a callback occurs, it goes to the host!
i ported over all the handlers as well, including lambda anonymous one in async UDP
All packets are CRC verified and have yet to loose any at 2-3Megabaud, im even able to flood mqtt and receive async UDP packets at 0ms tight loop hammer mode :)

i just added yesturday callback queuing support
my handlers have 2 bonus features

1. non blocking (go ahead, sprinkle delays everywhere) :)
2. callbacks queued when functions are busy, and deque when free :) i call it “asychronous callback queuing” :)

whats better than a master-slave? multi-master!
the reason why the host is so updated is because ESP can talk to it too, as well as both ways can talk to each other. you can mix commands and data, ive done it, youd just have to see my videos for proof i guess, but id like to say, there is NO constant polling what im doing, how you poll is up to you with ESP commands on host, but there is NO polling in the library or UART communication

If you think thats crazy, I even ported over SPIFFS to the host. im able to read/write/create/append files on the ESP’s SPIFFS... from the host! :)

from wifispi.

here i am flooding MQTT server with publishes in 25ms loops while receiving asynchronous UDP packets.
Ignore the DEC packets, it's my library debugging enabled while I work on it :)

async websockets while mqtt publishing, with UDP packets async https://www.youtube.com/watch?v=5H4WNRGchdI&t=7s

heck heres another video of me flooding an MQTT server at 0ms tight loops
https://www.youtube.com/watch?v=lpUslp-ZI44
what you see in the video is asynchronous callbacks of it receiving it back from subscription! :)

from wifispi.

Thanks, I will look at it.

from wifispi.

The speed is impressive. I admit, I don't understand the callback stuff you are writing about.

from wifispi.

in serial monitor, you see the data which is from the callback, callbacks are for asynchronous events. lets take the stock ESP callbacks built in, ive ported them to the host. lets say wifi disconnects, or connects, or dhcp fails on connect, an event is fired on the ESP and it calls it’s core implemented callback. what i did basically is i create the identical callbacks, including their function arguments on the host end, and transfer the callback data over as a single payload which immediately is processed

from wifispi.

if your familiar with the websocket callback on the ESP:

void webSocketEventServer(uint8_t num, WStype_t type, uint8_t * payload, size_t length) {

The exact one is implemented on the host.

If you get a websocket text, or message, the ESP handler forwards it to the HOST one instead
I basically gave transparency a whole new level by forwarding events and methods without modifications to libraries or core

from wifispi.

I'd also like to mention no user code is stored on the ESP, ESP.* WiFi.* and libraries (WiFiClient/WiFiClientSecure(Yeah SSL support with bonus of loading certificate from SPIFFS, (from the host))),SPIFFS, EEPROM, UDP, websockets, etc etc etc), the host actually thinks it's an ESP at this point. Sorry no, I did not port over the SDK, that would be overkill :)

from wifispi.

So kind of RPC, then?

from wifispi.

RPC? now im lost :)

from wifispi.

Sorry, https://en.wikipedia.org/wiki/Remote_procedure_call

from wifispi.

yeah i guess it's similar to that
when I started designing it, it was suppose to be for MQTT client for mult-controller network, but thats been pushed aside temporarily once I kept upgrading the potential of this
The idea was to run the same functions locally as remotely, without any tampering of the code, which made it upgradable through core 2.3 -> 2.4 of the ESP, and still ongoing! the remote's stock function return goes back to the host and returns to user what the other end returned. This allowed me to port over tons of methods to make them run, including original naming scheme, as if the user was running an ESP (but really isn't). Everyday I look for more ways to advance it, it's getting bigger all the time :)

from wifispi.

@tonton81 you hijacked this issue. will you publish your firmware and library?

from wifispi.

eventually yeah, i already have a thread on a forum regarding the WIP, regarding your reset issue, GOIO15 must be low for a normal boot, which your using for SPI, and since your master doesn’t know if/when the ESP resets, thats where it gets stuck when the master is holding the line HIGH. you have no choice but to have access to reset gpio to reboot it to a known state as explined above. i used to use an additional gpio on the ESP (GPIO16) which would be driven high or low after sketch boot, to let the master know it was booted and ready, or completely lost (bad boot?), which then knew that it must be reset. i no longer do this as i use async uart for synchronization

from wifispi.

@JAndrassy Sorry, I am aware of the OT communication.
It is possible with external circuitry to avoid the situation when the ESP Reset does not work but I wanted to keep things as simple as possible.
See esp8266/Arduino#2466 (comment)
I filed an issue to the WiFiESP library. JiriBilek/WiFiSpiESP#6

from wifispi.

@tonton81 I hade a plan to develop just for fun a proxy/stub/rpc system like you describe, so I am curious

from wifispi.

im not sure on implementation of your idea as im not familiar with that method, but its good to have more ideas to expand it further. regarding my implementation, the functions do nothing but send the payload command, and retrieve the original return, before returning value to user, so the master code is basically, mostly, just uart data, with autosync and crc validations. bringing SPIFFS over was a major bonus. Theoretically the only way to ‘break’ the way the functions work is if the core/library authors decide to change the function overloads to a point where it affects their own users, which, you know, will never happen as no one wants to break an entire user base of people using their code. regardless, adding more methods or modifications is not that hard, but i keep it as transparent as possible to look and act as a real ESP as the objects and functions and callbacks are identical in every way

from wifispi.

for example, my code doesnt just do WiFi.begin(“user”,”pass”);, surely no, im talking real transparency implementation, meaning you can input the additional channel, bssid, etc in the overloads and yeah, thats what i decided to work on

like ESP.restart(), funny thing is i added a lambda function of my own :) I called it ESP.onDetect{}; and you run it in setup with any of your ESP startup code, its binded to the ESP object so persists on master even after setup() exits, so example we drop WiFi.begin call in the onDetect lambda, if we call an ESP.reset as an example, the lambda will detect the ESP reconnect from callback and automatically resend the WiFi.begin call to it. I did a huge command call as a test and it works perfectly every time no matter how huge it is, even my callback implementations are non-blocking and support any commands you throw at it that wont work if you did that to an actual ESP

from wifispi.

@tonton81, you should learn some IT terminology to be able to communicate with other developers :-).
Please publish on GitHub what you have or create a private repo with access for chosen (me, Jiri, @per1234).
I have test setups of esp8266's with Arduinos and experience with different esp8266 firmwares for arduino networking. I promise I will respect your code and coding style.

from wifispi.

honestly i never used github so i wouldnt know where to start LOL, your a dev? yeah my lingo is not so good with words because im self taught over the last several years, sorry

from wifispi.

Yes I am a professional developer in Java and hobby developer for Arduino. Start with creating a repo :-). You use Arduino IDE?

from wifispi.

yeah always, and i use teensy mcus

from wifispi.

my sense of direction to a project i started on that thread changed upwards of post #10 and continues to end which is progressing, so i put it aside to work on this as it was more demanding

https://forum.pjrc.com/threads/48839-New-project-code-named-teensquitto

from wifispi.

the stale project will be remade in future to allow multi-network mcu controller support over mqtt using the library im working on which gives teensy as much benefits it can from the ESP, it should work on other mcus as well, but, provided the other micros have STL support as the async callback queue system uses std::deque with std::vectors in a push_back push_front scenario in order to keep the workflow solid. functional is also required to be included

from wifispi.

pop_front i mean*

from wifispi.

In development branch there is an implementation of soft reset. I mean reset over SPI. If you'd want to play with it don't forget to check out development branch on the WiFiSPiESP project, too.

from wifispi.

Hard reset implemented in dev-0.2.0 branch by f537249

from wifispi.

Implemented in 48ea9f3

from wifispi.