Gripes on ESP32/ESP-IDF

[Deouss]

Well, why don't you write to Cadence and Xtensa team to reveal full esp32/lx6 documents for technical reference and assembly manuals.
You can try RMT of ESP as it behaves similar to SPI and has full-duplex behavior. Like I said we have to wait for Cadence people to give us full docs and relevant asm stuff to work on fundamental apis

[Vader_Mester]

The thing that drive me nuts the most is the fact that you don't actually grasp what's exactly happening in the background while your program is running.
Specially FreeRTOS, because I always keep thinking about all the software times, and interrupts, and other stuff that goes in the background, and never able to tell the timing of my program.
It's bad that you have to keep writing your stuff with such a care to keep your program running unbothered, yet not completely mess up the FreeRTOS stuff in the background to not make the thing crahs.

This should be the other way around.
As soon as FreeRTOS comes into play, and the amount of RAM and CPU resource it uses, you suddenly find yourselft puzzling if this chip is better than the 8266 or not when it comes to performance. With FreeRTOS, your 240MHz speed can quickly feel like much less, which is not too good.
Since FreeRTOS is so deeply embeded into the system, I think it is woth doing an "abstract" of what the FreeRTOS is actually doing on the ESP, so people can see it. Also there should be a couple of benchmarking examples, just to see it in action.

Don't get me wrong, FreeRTOS is a very good thing, and it needs a uC at least as fast as the ESP32, but not for everyone.

Edit: I also understand that Espressif had to market the Dual-Core approach somehow, so with using the FreeRTOS extensively, they tried to use it as a marketing thing, and basically showing it down the throat of people. I completely get it. However, there should be a different approach provided by espressif, and the necessary API tools, so that people can make they own OS out of the box, without the FreeRTOS.

[Deouss]

They should come up with something super-light and lighter than rtos. Probably it is very easy to be done but chip must be strongly present on the market. I tested stuff with FreeRTOS and works amazingly great and stable. You just have to know what you are doing and keep track of resources and memory leaks. I would like to see an example of precise time measurement and how to easily convert ticks to microseconds.

[Vader_Mester]

I would like to see an example of precise time measurement and how to easily convert ticks to microseconds.

There is a possibility to read the cycle count registers, which then can be converted to uSeconds.
See my post about this here.

I also wrote a delay function, which should work in theory. This should be used in sub-milisec. delays.

Code: Select all

#include xtensa/hal.h

void IRAM_ATTR smalldelay(int dcycles)
{
	int dcycles;	//number of delay cycles
	int cycleStart, cycleStartWRP;
	cyclesStart = xthal_get_ccount() - dcycles;
//	cycleStartWRP = xthal_get_ccount() - 0xFFFFFFFF + dcycles;
//supplemented by the silly code below so you read CCOUNT once for setting start condition
	cycleStartWRP = cycleStart - 0xFFFFFFFF + dcycles + dcycles; 
//Calculate cycleStart value before wraparound detection makes the delay more accurate, so time is already passing during the running of the IF below.
	if (cycleStartWRP > 0) {	//if bigger than zero, CCOUNT register will wrap during the delay
		while ((xthal_get_ccount() > cyclestartWRP);	//Counts till the wraparound
		while ((xthal_get_ccount() < cycleStartWRP);
	}
	else {											//proceeds here if no wraparound is detected
	while ((xthal_get_ccount() - cyclesStart) < dcycles);
	}
}

[michprev]

Well, why don't you write to Cadence and Xtensa team to reveal full esp32/lx6 documents for technical reference and assembly manuals.
You can try RMT of ESP as it behaves similar to SPI and has full-duplex behavior. Like I said we have to wait for Cadence people to give us full docs and relevant asm stuff to work on fundamental apis

This is not about Cadence. Correct me if I am wrong but Espressif uses LX6 processor from Cadence. The rest is made by Espressif - WiFi + Bluetooth driver, all peripheral drivers (SPI, I2C, timers, RMT, ...).

AFAIK Cadence hardware works perfectly fine. Their docs are under NDA. But when you look at leaked ISA manual it is very good.

[Deouss]

So how do I calculate microsecond time interval

c0=xthal_get_ccount()

c1=(xthal_get_ccount()-c0) / ncyclesinmicrosec ???

[hassan789]

How often do you read gyro & accel data? Are you sure that you catch the new data every single time (you don't miss every second for example)? How powerful was the CPU you were using?

I worked on quadrotor uav 8 years ago. I used to read adc at 1kHz gyro+accel+mag, then apply a complimentary filters in software. My entire PWM frame update happened at 50Hz. I used a 320MHz TI C2000 processor (way more power than I needed), using TI's rtos.

Today you can take a Bosch BMX160 or Invensense icm-20948 (or similar chips) that do all the fusion and filtering and queue onto a hardware fifo inside the chip, and fires a GPIO when the fifo hits a percent mark. Here you can not miss any data.

If you are collecting each raw sample manually, this is not only wasting precious CPU bandwidth, but you are re-inventing the wheel.

[hassan789]

Also, just for the record, the FreeRTOS drivers for the ESP32 are amazing, this is the main reason I love this chip. The ESP-IDF is reliable and makes life easy for 99% of applications...

[michprev]

Today you can take a Bosch BMX160 or Invensense icm-20948 (or similar chips) that do all the fusion and filtering and queue onto a hardware fifo inside the chip, and fires a GPIO when the fifo hits a percent mark. Here you can not miss any data.

If you are collecting each raw sample manually, this is not only wasting precious CPU bandwidth, but you are re-inventing the wheel.

Ugh that it not true at all. I've been using DMP (digital motion processing - filtering data on the sensor itself) on MPU9250 and the results are not as good as doing it on manually. Also with DMP you can reach 200 Hz update rate max.

I am using this model


You can usually read accel data at 4 kHz max while gyro data can go up to 32 kHz. Using this model I can update speed regulators for motors everytime I get new gyro data. For me 1 kHz for both gyro & accel is pretty enough. Having raw data (rather than DMP calculated ones) gives even more advantages. Accel data can help you calculating altitude. Raw data are very often logged into flash memory to analyze it on computer and tune PID parameters. You can (and very often have to) apply custom filters to get rid of vibration noise.

This is not re-inventing the wheel.

Also, just for the record, the FreeRTOS drivers for the ESP32 are amazing, this is the main reason I love this chip. The ESP-IDF is reliable and makes life easy for 99% of applications...

Just few random examples..
https://github.com/espressif/esp-idf/issues/368
https://github.com/espressif/esp-idf/issues/2211
https://github.com/espressif/esp-idf/issues/1193

Also I have faced a strange issue. I have been using watchdog to kill my quadcopter whenever anything goes wrong. I have been also using flash core dump so I could analyze what was wrong. Sometimes there were random freezes (for few seconds) during watchdog reboot. Rarely my chip got stuck even forever!

[hassan789]

The MPU9250 is quite old, I am surprised you are using it for a new project. The problem with it is, the MPL software is on your host processor, which means any missing gyro data can mess the whole algo. Also, it is VERY sensitive to mag calibration, if it is not calibrated correctly, your reading will be off. Have you tried running the MPL without mag?

If raw is working for you, then great!