The release branches are not immutable. We tag our releases with git tags, but then keep backporting changes to the release branch which will then become, for example, v3.3.1, v3.3.2, etc. The latest v3.3 stable release is v3.3: https://docs.espressif.com/projects/esp-idf/en/v3.3/mzimmers wrote: ↑Wed Nov 13, 2019 3:22 pm1. As I mentioned above, this all came about when I tried to migrate to IDF release/v4.0. When I returned to release/v3.3, however, the problem persisted. I had assumed that the release/v3.3 branch was immutable at this point, but perhaps I was mistaken. If it isn't immutable, which IDF should I use in production?
The IDF docs has a section about versions which explains the difference between these concepts. If you find any information there is missing or unclear, please let me know - we want the system to be clearly understood by everyone: https://docs.espressif.com/projects/esp ... sions.html
The bug was introduced to master (which was then version v4.0-dev) in commit 434dd2d7 and backported to release/v3.3 branch in commit f380d728. This commit isn't in the v3.3 release ("git tag --contains f380d728" confirms this), so if you "git checkout v3.3" then the UART will work correctly again.
During app startup IDF makes some additional tweaks to the flash config, and one of them clobbers GPIO 9 & 10 UART function.
May be a week or two because we're having issues (again) with our internal CI system infrastructure, so a lot of changes are getting queued up. If this is a blocker for you then I can give you a short patch that fixes the problem, you can apply it to IDF and then remove it later when you update.
Which branch do you want the patch for?
I'm not a good candidate for dev tool recommendations, due to almost two decades of being an emacs user. I'm not fast with emacs because it's somehow superior, I'm fast because I have all the relevant emacs addons I use (helm, projectile, gnu global tags integration, etc) baked into my subconscious & the keyboard shortcuts in my muscle memory.
The reason I found this bug pretty quickly is less exotic: I've been working on ESP-IDF since before it was called ESP-IDF, and it's my job to know what goes on in the IDF codebase.
That's fair, and major reason is that most of the early ESP-IDF core developers were comfortable with "old school" tools like emacs/vim/etc.mzimmers wrote: ↑Wed Nov 13, 2019 3:22 pmMy primary complaint about the ESP32 platform is the paucity of modern development tools, notably an interactive debugger. The lack of this has been a major factor in my productivity with this device. (That's why I was trying to move to Eclipse in the first place.)
The new Eclipse plugin looks really good, I'm excited about and I think it will change this situation for the better (I'm almost ready to give up my comfort blanket of emacs and switch. Almost). There is also official VSCode support coming soon, including debugger support also.
GPIOs 34 and higher are input-only. Probably the config system should limit setting them as TX pins, sorry about that. If you set RX to 35 and TX to 32 then it should work.mzimmers wrote: ↑Wed Nov 13, 2019 3:22 pmAlso, regarding the use of SD2/SD3: if I'm reading the datasheet correctly, these are my only choices for UART1. I tried using menuconfig to assign some other lines (IO32 and IO35), but I'm not getting any output. Can someone confirm that this is expected behavior?
Pin functions in ESP32 are a bit confusing. We have the "IOMUX" for high speed assignments, and it has fixed pin-to-peripheral mappings (that's the pin where IO9 is UART1 or SD2, etc). Then there is "GPIO Mux" which allows arbitrary peripheral to pin mappings. Some peripherals (SD card for example) need to use IOMUX.
Other peripherals can use either IOMUX or GPIO Mux, meaning any pin. The only reason to require IOMUX is if you need really high speeds (40MHz+). If you don't need to run UART1 at 40Mbaud, you can use any pins.