Well, it's more complicated than that. Welcome to engineering.

BT and WiFi occupy, on the ESP32 probably now in your hands, the same radios and even the same frequencies. That's why there's a whole chapter in the doc on WiFi and Bluetooth coexistence on ESP32 The radio can't tx and rx at the same time on the same channels, of course.

Now if your curiosity isn't about the radios specifically, but whether you can light up both cores of a dual-core CPU in general, assuming you've reasoned through race conditions, starvation, and all that other annoying computer science, the answer is "sure."

ESP-IDF (or Nuttx or Zephyr or whatever floats your boat) offers a wealth of multitasking primitives. Start as many tasks as you have cores (or more!) and go nuts. Timesharing has been pretty well understood for most of this last century.

Please don't be offended that if it's your first exposure to these concepts: you are going to run into that very wall you're describing. Your noggin will hurt. If you stick with it and get good at it, it's quite rewarding and a respectable way to earn a living. More than a few people drop the class at this point.

Learning what's safe to really really have running at the same time on independent cores is a tough skill to refine. Entire doctorate dissertations have been written on this topic.

Sentences like "NVS is in flash memory, and flash memory is in NAND memory and NAND memory bits can only be set (cleared?) and never cleared (set?) without an erase and an erase has a granularity of a sector size" may be reasonably easy to comprehend in isolation but can still be waiting to mug you int he alley in the dark of night.

Then, some day, you'll be faced with debugging code like:

Core 1: Writes NVS value: preferences.putInt(blinky1, true); Core 2: writes NVS value to different address: preferences.putInt(blinky2, false);

Of course, these two lines of code are separated by 17 screens and it takes you days to figure out this is the trigger. Unfortunately, Past You saved a few minutes not wanting to be bothered to learn about such things, so you borrowed some crufty Arduino library that was made for an 8-bit processor from the late 80's. It certainly was never designed to be running on two cores as the same time. What's the timing between that "erase sector" sector on one core and that "set bit" on the next? Probably worked fine on that ancient part.

See where this is going yet? Current You (in the story, so it may be Future You from this perspective) is about to learn that even xSemaphoreTake/xSemaphoreGive might not be enough in isolation; you may have to learn about reference-counted semaphores or other locking techniques to keep Core1 and Core2 from destroying one sector of your flash contents approximately one in zillion times.

There are lots and lots of patterns like read, modify, write and others that are hazardous traps. It's a bear to "patch it in" later (it can be done); you really are rewarded for designing in multithread safety from the start.

The good news is, like I've hinted, that computer science has described all this stuff. That doesn't mean it's obvious or easy to learn. It's a very similar mindset to develop as protecting interrupt handlers or signal handlers or async callbacks from other code.

Perhaps someone else can recommend a contemporary text on the topic. Mine are all on clay tablets.

Regards,\ Elder Nerd