pls give us the nonos SDK

[sanpei]

Give us the non-OS SDK, please.

Person or organization like us DO NOT need the things a RTOS have done. We can write scheduler and everything by ourselves. The flexibility has been compromised by binding to an RTOS. Actually, a RTOS make higher costs in many projects, we need learn more things about the OS and we need think about how to make our project coordinated with it.

Don't say that we can ignore it because blah blah blah... we CAN NOT pretend the OS does not exists. it IS here. And, due to the works we do, the non-OS SDK is a basic thing. it is more IMPORTANT than Arduino and is even more important than RTOS SDK.

More choices is the way means to be. please release the non-OS SDK, you don't need make it out-perform before "it can be released". just give us what you use in your company. Thank you.

[ESP_igrr]

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.

[ESP_Angus]

More choices is the way means to be. please release the non-OS SDK, you don't need make it out-perform before "it can be released". just give us what you use in your company. Thank you.

Just to add one thing to Ivan's reply: the SDK that we use inside Espressif is ESP-IDF, based on the exact same codebase that's on github.

[ESP_Angus]

sanpei, do you have ESP8266 non-OS SDK code that you need to port to ESP32?

[sanpei]

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.

[sanpei]

sanpei, do you have ESP8266 non-OS SDK code that you need to port to ESP32?

No.

We don't port low level drivers (codes which operate hardware). it's not necessary, and with understanding of uses, correct behaviors, protocols (,etc.), rewriting a driver is not difficult. After all, it's rarely needed to implement a heavy driver with complex functions on a MCU. Controlling pins is not difficult, right? The wifi stack and bluetooth stack are complex, and you did them

What I concern about is that What your MCU can do with its nature/power, and How we can push it to its limit. if a job can be done by using one chip, nobody wants two. So we hope that all resources can be open to users, well-documented, and users can decide how to use functions and features provided by your products.

for example, if we want to implement something like a communication protocol on ESP8266, but we don't want to use a loop with delays, then we need to use GPIO interrupts. but even with nonOS SDK it's not easy. The whole interrupt system is encapsulated by your framework. In interrupt handler, we can minimize our operations to use about 50 cycles or less, but your framework uses 100 cycles. And your wifi triggers NMI interrupts, but no official document mentions these behaviors, one may encounter timing problems without any hints even if he is just implementing a simple uart-like protocol (which needs not-too-low bandwidth). With a 8051-like MCU and it's documents, these mysteries won't happen.

As I know, the source codes you have been released provide many details about ESP32. I appreciate that. But documents that have industry average quality are still needed. And it's better if you could provide some examples showing how to use ESP32 as a "naked" chip, like those traditional MCUs.

[ESP_Sprite]

I see a lot of issues you have with the ESP8266 SDK that you think you will also have with the ESP32. While I do acknowledge the fact that you have these issues with the ESP8266, I'd like you to know that we weren't entirely happy with the way that ended up either. That is why we decided to go a different, more modular and more open-source way with the ESP32. Although I feel your frustration with the ESP8266, for the ESP32, can I ask you to first take a good look on how we solved the issues there before assuming a bunch of things? If you still see issues with the ESP32 SDK, I'm more than happy to either explain why we did things that way, or consider changing what we did.

[ESP_igrr]

sanpei,

Thanks for explaining. What you say makes sense.
I have to disagree on you 20/80 division though, based on customer requirements and feedback I see it the other way around. 80% of the application requirements are being covered with the ESP-IDF, for the other 20% developers need to dive deeper.

As a software guy, I totally get your point about providing a way to do "bare metal" programming. But the reality is, we don't have resources to spin low-level and high level frameworks at the same time. And 80% of our customers (probably more) need the high-level thing at this point. As time goes, we will likely be refactoring ESP-IDF to be make less assumptions (which will naturally happen as support for other RTOSes and chips is added) and moving some of the basic chip support code into (relatively) standalone libraries which you can use outside of the IDF.

For now the only thing we can realistically offer you is to look at the code present in the IDF and reuse it for your bare metal efforts at will.

[ZequiPZO]

Hi,
im using esp8266 since 2017, and after the NON_OS_SDK_3.0.0 all my projects works fine.
But I only use the precompiled files ".a" and they respective ".h" files, the rest of things I did myself as always.

I need to agree with "sanpei" on the esp32 SDK, just to turn on a PIN there is so many code... OMG
I tryed to do things on my way but is impossible, I look on all the important parts of the code and
made some stuff work baremetal, but when I look inside the "components\esp_wifi\esp32\esp_adapter.c"
That peace of code made me stop imidiatly, and I will continue to use the esp8266, esp32 esp-idf is bad, realy bad.
I like to understand the microcontroller I use, but this kind of thing made stop trying to use ESP32.
I realy like esp8266 doing almost everything baremetal.

Sorry espressif I am one of those less then 10% that like a NON_OS SDK
So I think I will never use esp32 on my projects

[ESP_igrr]

Hi ZequiPZO,

Since the initial post was written, we have started supporting bare metal development on ESP32 series of chips via esp-hal project. You can get access to all the low-level details and also use wireless functionality.
Please refer to https://esp-rs.github.io/book/overview/bare-metal.html for the initial pointers.