Chat here about code rewrites, mods, etc... with respect to the github project https://github.com/esp8266/Arduino

Moderator: igrr

User avatar
By kolban
#25933 To my way of understanding, the notion of the ESP is to be event driven. For example, if we request that an ESP station connect to an access point, we are called back when we connect and called back when assigned an IP. We are also called back if we lose connectivity.

For a TCP server, we are called back when a client connects. This is ESP level programming.

In the Arduino model of the world, we are "busy loop" processing. We poll for interesting state changes. For example we poll to see if we are connected and we poll to see if we have a new client connected to us that has data to be read.

These two visions are distinct.

The ESP8266 Arduino libraries provide us with the "illusion" that we are working on an Arduino device and provide skills familiarity with folks already familiar with the Arduino libraries ... however, I'm starting to question that philosophy when writing new ESP apps.

And this is where I'd like to throw some ideas out there ... what if we extended the Arduino libraries available in ESP (eg. WiFi and WifiServer as examples) to provide callback functions when events are detected from the underlying ESP SDK? This would allow existing programs that are "Arduino" flavored to work but would allow new applications to leverage what I believe to be the design intent of the ESP. The implications of this would beneficial to the Arduino ESP community ... I don't think anyone doubts the value of adding new functions and capabilities ... but it would "break" anyone trying to port an Arduino ESP app BACK to the Arduino.

... which brings up the philosophical question. What is the intent of this project?

o Provide the Arduino IDE tooling for ESP programming?
o Provide the Arduino libraries AS-IS for the ESP environment?
o Extend the Arduino libraries for the ESP environment?
o ... others?

I for one would like to see the libraries that are being built that add "value" such as WiFi and WiFiServer be augmented with ESP "flavored" functions. Ideally, I would eliminate the need for "loop()" in my programs and all activity would be handled by events.

Neil
User avatar
By igrr
#25936 The intent of this project was to experiment with ways to bridge the gap between underlying event-driven APIs and blocking Arduino library APIs. You might as well say that it was born out of this conflict in philosophies. From this point of view, it was a mixed success. Single coroutine approach works well for simple cases but breaks down when multiple network services are operating. As you may have noticed, libraries which use UDP (mDNS, SSDP) have already been rewritten to use event-driven APIs. UdpContext class, which is a private class behind WiFiUDP, has an option of working asynchronously exactly for this reason.

I'm totally okay with doing more things in an event-driven manner. In fact, this might very well be done in a separate library, not bound to be compatible with Arduino WiFi library. Any contributions in this area are welcome. My suggestion is to stick to the overall design of asio library, which is by far the best thing for network programming in C++.
User avatar
By schufti
#25952 sorry if this is totally BS, but wouldn't it be possible to have both?
Would it be possible to just have a "handler" (like e.g. ticker or OneButton) for such cases?
The user then could either poll the status in loop() or have a handler registered that would allow him to immediately react on the triggering event determined e.g. by reading the status (to minimize the count of necessary handlers).

rgds,
schufti
User avatar
By kolban
#25958 Schufti,
Your thinking is solid. From a technical perspective, there is no obvious reason that we couldn't have multiple techniques. The questions before us though are not "what can be done" but rather "what should be done". Iggr is the project owner and primary maintainer, this community is the primary set of consumers.

Any project (such as the ESP/Arudino IDE/Libraries) would descend into anarchy if things that could be done were "just done". So the question before us is strategy and direction and not one of technical implementation.

What we need to do is set a "roadmap" of where the project is going to go in the next month, 6 months and year. Think about the possible "big ticket" items and list them out. And then, when "notions" such as an event driven model come to mind ... discussion them as a community with prime consideration given by the project owner and architect. If the owner and the consumer community decide that an enhancement or functional change becomes a desire, then it gets added into the roadmap and those who have skills and time can become technical contributors.

... at least this is my way of thinking :-)

If this thinking holds water, we start not by thinking about how to implement it ... but rather drawing up a roadmap for the project against its goals and directions and then take it from there.

Neil