ESP-IDF 2.0
Moderator: ESP_flying_raijin
Re: ESP-IDF 2.0
Here's the log from msys32. New download, make clean; make defconfig all V=1 and it compiled fine
After that - last part of log - I just did make clean; make menuconfig and make and the errors show up.
Lesson learned, sort of ... I followed the steps in http://esp-idf.readthedocs.io/en/latest ... setup.html and they're apparently not quite right. Your version seems to work fine.
Again, thanks for the patience.
After that - last part of log - I just did make clean; make menuconfig and make and the errors show up.
Lesson learned, sort of ... I followed the steps in http://esp-idf.readthedocs.io/en/latest ... setup.html and they're apparently not quite right. Your version seems to work fine.
Again, thanks for the patience.
Re: ESP-IDF 2.0
oops ... no upload for .zip. Do you want the log?
Re: ESP-IDF 2.0
So is this delayed until Feb?ESP_igrr wrote:We plan to make the final v2.0 release on January 26.
Re: ESP-IDF 2.0
We have decided to take more time to fix some of the open issues. The release timeframe has moved to the second week of February.
-
- Posts: 95
- Joined: Tue Feb 21, 2017 10:17 pm
Re: ESP-IDF 2.0
Well, it's the third week now. What's the word so we can have an official clean release on this stuff and have you get on to the other functionalities NOT in the idf?ESP_igrr wrote:We have decided to take more time to fix some of the open issues. The release timeframe has moved to the second week of February.
Re: ESP-IDF 2.0
We're working on cleaning up various issues found by the QA. Sorry for the delay folks, we have a good share of features ready to be merged post-2.0, and would really like to ship them. However we need to fix issues first. WiFi part passes QA now, so just a few things to fix in the BT part.
-
- Posts: 95
- Joined: Tue Feb 21, 2017 10:17 pm
Re: ESP-IDF 2.0
Except for some small, mild annoyance at the BT Classic functionality not being exposed right now, it's all good. So far, the RC is letting me start work on the varying things they're intending to at least experiment with on the boards they bought. So they're "happy" and I am.ESP_igrr wrote:We're working on cleaning up various issues found by the QA. Sorry for the delay folks, we have a good share of features ready to be merged post-2.0, and would really like to ship them. However we need to fix issues first. WiFi part passes QA now, so just a few things to fix in the BT part.
While I'm wanting sooner rather than later, because of my client's desires, if they're possible- I'd rather this be fairly solid because I'm already liking what I'm seeing and it's going to be used quite a bit in my pet projects...and I want it to WORK...
Good to hear that you're almost there.
Re: ESP-IDF 2.0
Some weeks ago, we decided to wait for esp-idf V2 in our project.
Since then, only a few things arrived in github, at least what I can see.
My question now is, should we wait for V2 or not ?
If it takes some days, waiting would be ok.
Taking more than a month, the answer could be not to wait.
Is there any information, you guys can give to make our decision easy ?
Since then, only a few things arrived in github, at least what I can see.
My question now is, should we wait for V2 or not ?
If it takes some days, waiting would be ok.
Taking more than a month, the answer could be not to wait.
Is there any information, you guys can give to make our decision easy ?
Re: ESP-IDF 2.0
My belief is that Espressif releases versions that are "frozen" in time periodically ... v1.00, v2.00 and then the future. However, immediately after a version is released, continuous development still continues and this is what is found in the Github for ESP-IDF in the master branch. For example, the functions that made their way into v1.00 were present for weeks and weeks in Github master and the v1.00 just "became" the frozen release at that point (as best as I can tell). As such, v2.00 is likely to follow the same pattern. Meaning that the v2.00 functions are likely to be already present in the Github master and when ready, Espressif will just freeze the code base at that point and call it v2.00.
Assuming your project is Espurino, and you won't actually be committing anything to mass production, I would recommend that Espruino base itself on the "latest and greatest" master in Github and just "call it good".
Is there some function in ESP-IDF v2.0 that you are waiting upon that isn't present yet in the Github master?
Assuming your project is Espurino, and you won't actually be committing anything to mass production, I would recommend that Espruino base itself on the "latest and greatest" master in Github and just "call it good".
Is there some function in ESP-IDF v2.0 that you are waiting upon that isn't present yet in the Github master?
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32
-
- Posts: 64
- Joined: Tue Jan 10, 2017 1:09 pm
Re: ESP-IDF 2.0
Hi Kolban,
let me explain the point of view of my company, that is also waiting for v2.0 of the framework.
When developing a new product, what's very important for us is to use a stable development environment (framework, libraries...): OTAs are not always applicable if bugs in the framework are found after you ship the boards and affect your code. Moreover, the esp-idf at the moment includes some "closed" core components (wifi, bluetooth...) so we must "trust" Espressif about the maturity of those components. I know that "version 2.0" it's just a label (tag) on Github, but it should assure that everything included is well-tested...
For example, when we develop our own code, we usually have different branches (it's quite uncommon for me having only the "master" branch, as now it's in the esp-idf repository): at least one dedicated to new functionalities... and one to develop bugfixes for the actual "stable" release.
let me explain the point of view of my company, that is also waiting for v2.0 of the framework.
When developing a new product, what's very important for us is to use a stable development environment (framework, libraries...): OTAs are not always applicable if bugs in the framework are found after you ship the boards and affect your code. Moreover, the esp-idf at the moment includes some "closed" core components (wifi, bluetooth...) so we must "trust" Espressif about the maturity of those components. I know that "version 2.0" it's just a label (tag) on Github, but it should assure that everything included is well-tested...
For example, when we develop our own code, we usually have different branches (it's quite uncommon for me having only the "master" branch, as now it's in the esp-idf repository): at least one dedicated to new functionalities... and one to develop bugfixes for the actual "stable" release.
Who is online
Users browsing this forum: No registered users and 9 guests