ernitron wrote:Hello everyone and happy to start being part of the community! This is my first message and I am excited!
Just want to express my congratulations and gratitude to all the contributors, Damien, Sokolovsky and all the developers of this great community. Thanks!
Hello and welcome! Sorry for the delay with response - we were busy with 1.8.2 release and related organizational matters.
I am following the micropython project since march-april this year. I am actually developing in LUA and really cant wait to migrate to micropython. Besides I am a python enthusiast and don't really want to use LUA or C (anymore!).
Great, that was one of my motivation to contribute to MicroPython - to provide a (better) alternative to Lua for use in small embedded projects.
I have to say that I already started in developing something with latest releases of micropython 1.8.1 porting my web server from LUA to uPython but without success.
That's somewhat vague, so it's hard to say something besides: "Feel free to open separate threads to discuss specific issues you face".
There's however something to comment about in the phrase above. Lua is a very bare language, which doesn't even have builtin socket module for network communication. There's however "standard" external socket module:
http://w3.impa.br/~diego/software/luasocket/ . NodeMCU, which you use, does NOT implement it. So, you don't really have your web server written "in Lua", it's written in NodeMCU's proprietary, adhoc, non-standard API. This is widely different from Python and MicroPython. Python does have fully standard socket module for network communication, and MicroPython implements just it (a subset, but everything required to write a network client/server is there). Morever, Python's socket server is based on BSD Socket API, which is a universal, cross-language (also implemented by Lua socket module above NOT implemented by NodeMCU).
So, the problem you face is how to rewrite your application from a proprietary API to a standard API. This is common problem in software engineering, commonly known as
Vendor lock-in. It's possible to solve it. You don't even need MicroPython to start with it. Try to rewrite your server to work with "big" Python (just use the core of socket API, not extra fancy features), and then you will just need to optimize it for MicroPython.
I have tenths of WeMos, Lolin and plan to add more to my project for controlling sensors and actuators via
I cannot afford instability and quit the development waiting for more stable and complete releases. Surely my faults but now the questions:
1. Is there a roadmap and a schedule of micropython for ESP8266 so I can check the deadlines for more advance developing and testing?
Sure, the roadmap is laid out in the description of the original Kickstarter campaign (which includes unlocked stretch goals):
https://kickstarter.com/projects/214379 ... -easy-iot/
2. When do you think there will be a version ready for deployment in production? Comparable with the stability of NodeMCU for example...
It depends on what kind of "production" use you look for. Stability of MicroPython ESP8266 consists of: 1) stability of MicroPython implementation; 2) stability of ESP8266 platform. Stability of MicroPython is guarded by 90+% test coverage, including on-device testing. Stability of ESP8266 platform itself isn't too great. For example, it's common pattern for over a year that the vendor Espressif releases a new version of SDK, and a week or two follows with some "important patch" to it. Again, this happens with almost every time. And instead of making a new release, they exactly make a "patch", to make matters more confusing. So, both QA and release process for ESP8266 pltaform is not up to par. It's also known by ESP8266 RE community that its firmware contains dozens of places where firmware just locks up (doesn't recover from error, or at least resets, but exactly locks up). So, stability of ESP8266 itself isn't too great. With this in mind, what exactly do you mean by "Comparable with the stability of NodeMCU"?
3. Is there a reference design for a basic httpd web server to add modules that control sensors and actuators, via GPIOs/I2C etc?
There're examples of HTTP(S) clients and servers:
https://github.com/micropython/micropyt ... es/network . They can be extended per user needs. As one of the stretch goals, there's a task to port uasyncio library to esp8266, and that should provide even more features and flexibility. So, we, developers, pool resources to work on that (while working on other stretch goals, and we have a lot of them, covering wide functionality, as the KS page above shows). But everything one needs to write simple servers are already there, and that would be an excellent community project to provide examples like you write above, so feel free to start it!
Consider that I have followed the news updates on kickstarter and read quite a few topics on this forum, and I think this project it is going at a real fast pace but indeed I would like to have a clear view of the plan and objectives in a timeline. Or just address me where I can find this information.
Thank you all
Most of the information is indeed available in the KS description/updates, in the documentation (docs.micropython.org), here on the forum, and on github.
