ESP_igrr wrote:Currently we don't have plans for the non-OS SDK for the ESP32. That being said, if you are comfortable writing a scheduler, you can take the ESP-IDF and adapt it to your needs. You will need to provide some stubs implementing RTOS locking functions, and functional equivalents of queue/semaphore/task functions if you plan to link against the wifi stack.
Please correct me if I am wrong.
I understand that your wifi stack have dependencies on some mechanisms, and currently, you are using the mechanisms implemented by the RTOS. And there might be other considerations, so you decide release your product with the whole RTOS.
I had thought about the way you said: providing my own version of these stubs. But I haven't check into details of your RTOS SDK, so I don't know if it can be done easily. I've been a bit leery of your documents and the potential 'secrets' in your proprietary binary. Without all information in detail, I'm afraid to screw things up.
To be honest, my experience with esp8266 is not so good. there are so many things that are not documented, and some of them totally are under-hood. A main channel to get information is surfing on the web, looking posts which are posted by some hackers who have interests to dig with their spare time. And luckily if one of you post some info in someone's thread, then I can learn a lot.
In my opinion, a product like yours do not need to do much things, but it should be well-documented. The way you select may not suit everyone. If we want to do more to help our users, I prefer using libraries, but not frameworks. Frameworks do things without explicit calls from users, it does hide some complicated details which user shouldn't care about. But as an user, I find that with every frameworks, when I want to do something what are not considered by the authors, frameworks always make trouble.
When I say "something what are not considered by the authors", I don't mean there are few things (20%), I mean there are a lot things (80%) are not considered by most authors. Someone may ask why they don't find this, why they don't hear complaints from 80% ? the answer is that many users are familiar to get around troubles, these users waste their life to learn these "skills", they feel proud of these "skills" and they are accustomed to fight with troubles. and other users may just choose other products, they never sound. but troubles are still troubles, they don't become other things just because users can solve them or they just give up.
omg.. I write so long with my poor English. I write these because I like your products, so I think that I should give my suggestions. An IoT framework may be a good idea, but before that, you should make a good embed system first. most users don't do very complex stuff on a MCU, but we often need to operate things precisely, directly, and fast. we need to exactly know what happen in details. Everything on the chip should be controlled by user, control should go back to user, but not go back to framework/system.
You may think that, at least, you should guarantee that the wifi runs fine. for that, your framework/system must take the control. I don't think so. What you must guarantee is that wifi will run fine when user does the right things and satisfies the preconditions. As I can see, you are not only a wifi/IoT solution provider now, you are a MCU (with Wifi) provider, so you may change your mind for this transformation. it's not users like me too old to work in a new way, but the resources on a chip like this is too limited (to some extent this is the reason we choose a MCU with wifi or other functions, otherwise we can use a snapdragon), only users know how to use it in best way to get what they what.
Anyway, it's just my 2 cents. I don't want to be rude. but I can't ensure that all my words (including their means and their forms) are proper. so please excuse me if I said something wrong or unpolite.
