ESP32 Forum

Fyi, you can already do rotary encoder decoding using the pulse counter submodule.

Hi,

I would like to see an ARM core instead of a Cadence one.

The ARM toolchain and the ARM software ecosystem are 100 times better then GNU Xtensa.

Command line tools are like prehistoric animals.

It takes hours to configure the GNU Xtensa toolchain to debug a program.
It takes seconds with ARM.

Yet, the GNU compiler may not be the best solution.


Enrico Migliore

wwwenrico wrote:Hi,

I would like to see an ARM core instead of a Cadence one.

The ARM toolchain and the ARM software ecosystem are 100 times better then GNU Xtensa.

Command line tools are like prehistoric animals.

It takes hours to configure the GNU Xtensa toolchain to debug a program.
It takes seconds with ARM.

Yet, the GNU compiler may not be the best solution.


Enrico Migliore

ARM would be more expensive and different then Xtensa what would be the point?
They should just improve the software to be more Windows friendly and write some toolchain that seamlessly integrates with Visual Studio/VS Code IDEs

Deouss wrote:... They should just improve the software to be more Windows friendly ...

Please, don't "improve" the software to be more Windows friendly.

This is somewhat offtopic here, but regarding improvements for IDE support and experience on Windows, we're working on CMake support. Please have a look at the announcement:
https://esp32.com/viewtopic.php?f=13&t=5559

wwwenrico wrote:The ARM toolchain and the ARM software ecosystem are 100 times better then GNU Xtensa.

Command line tools are like prehistoric animals.

It takes hours to configure the GNU Xtensa toolchain to debug a program.
It takes seconds with ARM.

Deouss wrote:They should just improve the software to be more Windows friendly and write some toolchain that seamlessly integrates with Visual Studio/VS Code IDEs

I fully agree with Enrico and Deouss. I couldn't believe how primitive it is to set up the toolchain; like going back to the last ice age when MS-DOS roamed the planet. It should be easy to install the software directly from the Espressif website, without have to clone things off GitHub and to refer to instructions from 'readthedocs' or from dodgy instructions on YouTube. It should be as straightforward as installing from the Arduino website for an Arduino processor.

The silicon is fantastic except the ADCs and some shortage of GPIO pins. It's the software that needs sorting out.

For those engineers, scientists and hobbyists who are not computer graduates the ability to use the Arduino IDE is crucial. I get the impression that development of the Arduino IDE for the ESP32 has ground to a halt. There's still no function to write to the DAC, the I²C driver can hang indefinitely and I understand the loading of files into flash memory from PC has been broken for several months.

My view is that, unless the software is improved, the ESP32 will be squeezed out of the market by Arduinos with WiFi and fast processors. I've had to advise a colleague (a physicist) to stick with Arduinos.

will it contains longer physical range for bluetooth.?
now using ESP WROVER only providing range up to 2 meters. how can we increase this?

will any one have any clue?

Archibald wrote:
I fully agree with Enrico and Deouss. I couldn't believe how primitive it is to set up the toolchain; like going back to the last ice age when MS-DOS roamed the planet. It should be easy to install the software directly from the Espressif website, without have to clone things off GitHub and to refer to instructions from 'readthedocs' or from dodgy instructions on YouTube. It should be as straightforward as installing from the Arduino website for an Arduino processor.

The silicon is fantastic except the ADCs and some shortage of GPIO pins. It's the software that needs sorting out.

For those engineers, scientists and hobbyists who are not computer graduates the ability to use the Arduino IDE is crucial. I get the impression that development of the Arduino IDE for the ESP32 has ground to a halt. There's still no function to write to the DAC, the I²C driver can hang indefinitely and I understand the loading of files into flash memory from PC has been broken for several months.

My view is that, unless the software is improved, the ESP32 will be squeezed out of the market by Arduinos with WiFi and fast processors. I've had to advise a colleague (a physicist) to stick with Arduinos.

Well Arduino is not a must but if someone from Espressif wrote a simple VS extension - just like Visual Micro for Arduino - but extension for ESP boards only and fRTOS or other nice OSes - this would be a huge step for making this MCU a favorite enthusiast one.
It is already possible to setup full FRTOS under Visual Code but needs a lot of tweaks and python is not our friend here.
So far guys from Visual GDB make tons of money - ridiculous when this stuff should be free like ARM soft

Archibald wrote: I couldn't believe how primitive it is to set up the toolchain; like going back to the last ice age when MS-DOS roamed the planet. It should be easy to install the software directly from the Espressif website, without have to clone things off GitHub and to refer to instructions from 'readthedocs'

I usually stay out of debates like these, but I have to jump in because my experience is so different. I found the ESP32 tool chain easy to set up, and while I’m not a big fan of makefiles, I appreciate the work that went into making it easy to create and build a new component.

By contrast, I spent a frustrating hour yesterday wandering around ST’s website just trying to find the damn toolchain for one of their ARM M-4 boards, lost in a maze of spec sheets and brochures. They have IDE options, but 3 of the 4 only run on Windows (we’re a Mac shop), and frankly, I don’t want to learn another IDE. I code in Xcode, and I’d rather just hit Enter in a terminal window to build & flash the device. Moreover, a custom IDE won’t fit into our Jenkins based CI system.

Can we keep the software discussions, interesting as they may be, to a different topic perhaps? I'd like to specifically collect the _hardware_ withlist here.