Core1 wants to be free!

[mfp20]

First thing first: congratulations for the project both for the tech and the emotional side of the story. I've been reading your logs waiting for the next old gaming system you'd name in text, and I didn't hear about since I was a kid... it took good memories out of my heart.

I got to your project searching for a way to set core1 free of FreeRTOS, and it looks like you are the only guy that is doing something useful with Mr. Free Core One. About 4 more guys produced some previous art, but those were just proofs of concept and nothing really usable.

Getting to the point: I was wondering if you are available to make an independent project out of your unique know-how. Something like an esp-idf template with an hellocore1 'void main(argc, argv)' ready to be filled with custom code to run 'uninterrupted' on core1. It would probably help many people. I have spare time to help but ... I don't have your knowledge. I've been banging my head on esp32 twice in the past 4 years; a few months each time; and I've never been able to make an hardware timer handler ticking faster than 4us. On old AVRs I was able to get less than 1us! I'm pretty disappointed with esp32 sold as "microcontroller". It's good for IoT, not for "controlling" :P

Let me know if we can arrange something.

Thanks and keep going!

[DerfJagged]

You're definitely right that almost nobody forces the second core to run realtime. I think mostly this is because they only added the disabling of watchdogs per-core mid last year, so previously you HAD to run just straight assembly on cpu1.

If you're looking to just run regular ESP-IDF code (not Arduino and not straight assembly), you can just spawn a task on cpu1, use portENTER_CRITICAL(&my_mutex); on the first line, and turn off the Task Watchdog for cpu1 in menuconfig.

More info and my code on this thread of mine: https://esp32.com/viewtopic.php?t=17628

Edit: FYI this prevents you from running any other tasks on that core, so make it an infinite loop. It also probably breaks built in timer functions since it can't switch tasks to sync up with the RTC.

[darthcloud]

Disabling permanently interrupt on core1 will lead to core0 to crash in loop if you do anything useful like running BT or WIFI.

Read this:

https://hackaday.io/project/170365-blueretro/log/189836-esp32-rtos-bare-metal-best-of-both-worlds

[DerfJagged]

How long did it take to crash for you? In my own project, I was able to bitbang Genesis 6 button mode with a Bluetooth controller connected. I wasn't doing any WiFi things, but I wasn't getting crashes from staying in an infinite loop in CRITICAL mode on core1.

All that stuff made me want to go back to Teensy. If only they were cheap and had BT/WiFi built in without a shield!

[darthcloud]

That's surprising maybe my crash are related to something else I got enabled.

In any case I'm not putting more time investigating this :) It work the way I did it.

[darthcloud]

@mfp20 If you read the blog post I link to in previous reply you will see that my conclusion on removing FreeRTOS from Core 1 are mixed. I'm not sure it's worth the trouble. What really help is stalling Core0 & disable Core1 interrupt (less than 300ms if running BT) while you do your critical stuff and then release both once done.

[mfp20]

I red that post before posting here. It seemed to me you had found a way to do it without stalling, but then went back to stalling because some of the emulators were a bit picky. I probably got it wrong; while reading I was missing some bits (DPORT!? Stalling!?).

In general, yes, forcing the board out of Espressif's sdk is a pain. I was hoping you survived that pain!

If I start an hw timer to call a simple isr handler every 3us

static bool IRAM_ATTR timerIsrHandler(void *arg) {
	uint64_t now = esp_timer_get_time();
	return false;
}

it triggers a wdt timeout; 4us are ok (but that handler isn't doing anything except asking "what time is it?"). According to an issue on esp-idf repo, esp_timer_get_time() takes less than 1us, so the whole alarm trigger and isr call uses more than 2us of cpu time. It is crazy. On atmega@16MHz it was less than 20 cpu cycles, and it was deterministic. No fancy latencies.

The same applies to RPi Zero: a powerful cpu, huge ram, but no way to use it as a microcontroller. I mean, in both cases it is possible to write highly specialized code to serve 1 purpose, but no general purpose high speed bitbanging on multiple pins. Example: pigpio (RPi) can get a few MHz on a couple of pins, so you can even bitbang radio signals, but if you are willing to drive more than 2 pins... no way... jitter kills you. And must rely on specialized peripherals (ex: SMI, DPI), dma, and so on. Is it OK on a 1GHz cpu? I don't think so. On that broadcom silicon there are 14 cores, and can't even fully benefit of 1.

I'm pissed now. Apologize for the rant. I'll go relaxing by placing my parallax propeller on a breadboard for the very first time; just to change air a bit.

Thanks for the tips! Have a good one!

[DerfJagged]

You could use the "get clocks" function to get the current clock cycle number (maybe it had CCOUNT in the name?) and do time math if it's very short timers. That's essentially instant.

[mfp20]

@DerfJagged thanks but the problem isn't esp_timer_get_time() speed; it's 2us to call an isr! The design is flawed. I have my own timeutils.h with fast inline asm specialized code, but time code must be inserted in its application context. That context is slow. esp-idf has been made with IoT in mind; its core business is tcp/ip (milliseconds), not gpio (nanoseconds).
And indeed it is possible to go bare metal, without wifi/ble. One or the other. Not both.

They launched the esp32 talking of "pro core" and "app core" because they had in mind to use core0 for hw management, and core1 for application management, but now this distinction is described as obsolete in the docs. Probably because it can't be done. When I first approached esp32 there were some hw bugs preventing that; they had to put some workarounds in place, in order to circumvent those bugs, entangling the 2 cores. No idea what happened after...

[darthcloud]

ISR are slow on ESP32 you can hook up via _xt_intexc_hooks to bypass some of the overhead but at best you save maybe 0.3 or 0.4 us on your 1.5-2 us delay. (See

BlueRetro/main/system/intr.c

Line 56 in 9e6259b

_xt_intexc_hooks[intr_level] = 0;

)

On a busy loop looking at a GPIO pin I get around a delay of 300-500ns to flip another GPIO.

In any case I understand your frustration but in most case I would simply pair the Wireless MCU with a PIC or AVR to do the low level stuff.

I haven't done so for BlueRetro only to avoid adding additional latency and keeping it easy to build for DIY crowd.

I wish I could help more but I got very little free time and much of it goes to BlueRetro.

[mfp20]

In any case I understand your frustration but in most case I would simply pair the Wireless MCU with a PIC or AVR to do the low level stuff.

I agree, but upside down: esp32 is good as co-processor to offload. Prefer to build the houses ground up...

Anyway, thanks again for the discussion and tips. And good luck for your project!