-
-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ESP32 SDK 2.0.2. #420
Comments
@fredlcore Hi, can you remember for me why you used Here was glitches? I got error with name definition when i run test on PlatformIO but haven't problems with Arduino Studio:
|
Yes, we had a discussion earlier this year about it: |
I just figured out that the size parameter is no longer supported/used. So
should be sufficient. The problem will be that older IDEs may still not support the new library (which is just 3 weeks old), so changing the code may produce problems there. Since we officially recommend the Arduino IDE, I would only make the change once the newest Arduino IDE also supports this new library version. When that will be, God nows... |
Thank you!
Compiler for some reason mix unsigned int (32 bit length) and address pointer (32 bit length) I guess.
Arduino IDE has no problem with ESP32 SDK 2.0.1. By the way current DHT library can work unstable/incorrect for same reason as old OneWire library (multicore MCU + interrupts). So we should to change it to https://github.com/beegee-tokyo/DHTesp |
Sorry for posting this here, but related issues seems to be closed:
My basic mods (followed by manual) are
Compiler results somehow close to #issue 322 are:
Has anyone v2 with Wifi for ESP32 running and could give me a hint? |
In SDK 2.0.x some definitions, functions and header files was changed. I added one more header file in bsb.cpp: About OneWire: you can take library from my branch https://github.com/dukess/BSB-LAN/tree/ESP32-SDK-2.0.1 because official library not contatin yet needed changes OR just delete OneWire directory. |
Is it confirmed that the official Arduino IDE now uses SDK 2.0? I'm just wondering because otherwise many more users should be complaining about that problem. Or maybe they are all using older versions still? In any case, if Arduino IDE is using SDK 2.0, we'll have to make these adjustments so that it compiles without errors. |
Yep. Arduino Studio for Windows can use ESP 2.0.1. But Platformio support 1.0.6 only. For this reason i can't propose do PR with my changes. |
Sorry for misunderstanding, i meant ESP32 esspressif version in board administrator. Just can't get it compiled but errors are related to this. Also don't need one wire, DHT or BME support for now. |
I just installed the Arduino IDE from scratch on my Mac, version 1.8.19. The board manager for ESP32 only offers me SDK version 1.0.6 as the newest version. I used ESP32 Dev Module as target board. |
Big thx, let me check on latest Ardu. Interesting, i get newer versions offered here with windows setup, but can choose older version if needed. |
I'm using this URL for the ESP32 board manager: |
yeah, this URL, i choosed 2.0.1 |
It shouldn't be OS related, I guess, because the JSON file that I'm referring to only lists version up to 1.0.6. Which URL are you using? |
@Ludn you can choose version 1.0.6 in board manager |
Ok, that's different from what I know, but I see that it's listed in the official docs. Strange that there is a difference between the two, as both seem to be from Espressif... |
just checked 1.0.6. (with Ardu 1.8.15) and 1st error occurs:
|
@dukess: I installed 2.0.2 now, but adding |
double-checked and compiled fine with 1.0.6.: i had quoted 2nd line not deactivated, i am happy for now^^ thx so much |
look like you use my branch with 1.0.6
@fredlcore can you show me log? |
Sure:
|
Include is added in line 501:
|
@fredlcore These changes allow to compile project with SDK 2.0.2: dukess@0941e33 |
That's good news. Can't actually find where in project (ESP32) is defined. And is there any other advantage of SDK 2.0.2. appart from being updated to latest? |
ESP32 will be defined automatically. And no, this SDK has no advantages excepting more stable work with SD card and Ethernet adapter on OLIMEX ESP32 EVB board. |
So if you use WiFi you have no reason for instant moving to SDK 2.0.x. |
@dukess: Cool, thanks! Will try it out and if it works, we could make a note in the manual that we've moved to 2.0 for ESP32 and refer to the official board manager URL and make 2.0.x a requirement. That will prevent us from adding new functions that may only run on 1.0.6 which we would then have to adjust again later. |
Yes, please let me know when and what to add ;) Merry Xmas btw! |
@MrAntonka: So the WROVER works if you disable the usage of SPI PSRAM? Then it might be the case that you accidentally used a pin which the WROVER uses internally to control the PSRAM => these pins aren't available/useable at the WROVER as they are at the WROOM (means in other words that the WROOM has two more 'useable' pins than the WROVER). Screenshot taken from page 10 in here: https://www.espressif.com/sites/default/files/documentation/esp32-wrover-e_esp32-wrover-ie_datasheet_en.pdf Isn't the exact type of printed onto the module, so that we/you know, which type of WROVER exactly you are using? Maybe then we can find something more specific/definitive about the mentioned pins within the belonging datasheet.. |
Wow, @1coderookie, great find! That could be a good explanation! |
@1coderookie you are right. pin 16 (default value in bsblan) is used for BUS and PSRAM at once |
Pin 16 and 17 are default RX/TX pins for those ESP32 NodeMCU boards that we recommend using. You can of course use any other pin as well. |
@fredlcore well most boards that have PSRAM will use this pins(16/17) for PSRAM and if the user remaps pins for BSB then the adapter will not work. I think there is no way how to solve this issue ..maybe in manual few words about the issue with boards with PSRAM and shared pin 16/17. |
You mean if the user remaps pins for BSB then the adapter will work, isn't it? But why is disabling PSRAM support as you mentioned above is not an option? Because it would have to be done directly in the library? Or what is the reason that ther is no solution? |
@fredlcore well you are right ,, there is no official BSB adapter for ESP so there is no issue :) |
Ok, so adding the above lines and/or un-/redefining them in the BSB-LAN code won't work? |
Ok, thanks, could you check that? Because if it doesn't hurt non-PSRAM boards, we could still add this to make it easier for PSRAM-based board users. Or does this affect other functions of these boards? (I assume the extra memory won't be available then, so it would eventually be better just to use different RX/TX pins) |
I will check that how to do it from the code. well from the code it is easy but arduinoIDE/platformIO based on selected board add some arguments/flags into build command like "-D BOARD_HAS_PSRAM" so .. :/ but I will try. |
Thanks! |
What you think about this?
or
|
I already mentioned the WROOM32-type board within the chapter of the recommended NodeMCU and the Olimex also is a WROOM, too. But I just added an explicit note about WROOM/WROVER at the chapter about ESP32 (https://1coderookie.github.io/BSB-LPB-LAN_EN/chap01.html#13-esp32): @MrAntonka : Could you please check though, if the WROVER with PSRAM would work if you'd use other pins for TX/RX instead of 16/17 how I wrote it there? Thanks |
@dukess: pin 17 is also used at the WROVER, so that one must also been changed in your example about |
@1coderookie sure, you right! |
@1coderookie yep, for example, this works on board with PSRAM |
I would not add additional pin configurations based on "unsupported" boards - also because it wouldn't fit with our "official" boards. In the end, users who prepare their own boards will also be aware (now) that they have to choose the BSB bus pins according to their setup. Maybe a note that pin autodetection only works with Arduino Due, ESP32 NodeMCU and Olimex ESP32 EVB in conjunction with our "official" (better term needed here) boards would clear up any misunderstandings. But as I said above, if we can add some defines that will disable PSRAM, I'd be happy to do so. But if that's not easily doable, I'd just leave things as they are. |
I'd also suggest to not include additional support for 'unsupported/not recommended' boards - just because there are too many different types of ESP32 and we probably would've check all the data sheets if there are any additional differences. If someone really wants to use WROVER type, then he'll probably wants to do that especially because the additional PSRAM. Even if not: in that case one should be capable of reading data sheets and manuals to look for differences, if the note within our manual isn't enough yet. @fredlcore: Good point, I added this additional note now, I think that should be (clear) enough: |
Thanks for the note, @1coderookie, but I would phrase it differently, because pins 16 and 17 are only used for the NodeMCU-type ESP32. The Olimex uses other pins (from the back of my head 4 and 17), so I wouldn't mention the pin numbers there. I would phrase it more generally that when using non-recommended boards (such as WROVER types) one needs to make sure that the BSB bus pins do not interfere with other connected devices (including PSRAM) - or something like that. |
Aight, I'll change it (probably not before tomorrow though) to the suggested phrase. |
Thanks - and no hurry! |
No, I just realized that I need to think about it again anyway. Because: yes, sure, one should always look which pins are useable if he uses a non-recommended board anyway - but what we talked about above was the specific thing with the PSRAM and the WROVER module, which might be worth to be mentioned that clearly how I already wrote it. But I'll think about it again and let you know then.. |
Yes, I agree - it's just the specific pin numbers which could be misleading because we're not just using 16 and 17 on the ESP32. In fact, my auto-detection relies on the test whether the board configuration used defines RX1 and TX1. In that case, BSB-LAN assumes an Olimex and uses pins 4 and 17. If pin 4 is high, it assumes a board revision of 4.1 or lower without the suggested modifications and uses pins 4 and 36. But pin 4 could be high in a different setup for many other reasons as well. And if neither is the case, it assumes a NodeMCU board and uses pins 16 and 17. |
Successfully compiled on version 2.0.2 that I got by that URL: https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json . Had a problem with compilation with the version 1.0.6. |
BSB-LAN not work with SDK 1.0.6 since 25.12.2021. |
I'm starting software adaptations for using with new ESP32 SDK.
At the moment, the program is being built without errors.
To do this, i had to use a new version of the OneWire library.
Now i'm not assured in possibility of working with Dallas sensors, it should be tested.
Probably we should to update DHT library with this (https://github.com/beegee-tokyo/DHTesp ) fork because it works with multicore ESP32.(Already in master branch)Current progress: https://github.com/dukess/BSB-LAN/tree/ESP32-SDK-2.0.2
The text was updated successfully, but these errors were encountered: