Q: application CPU and handling of events from protocol CPU

[capablegh]

Hello.

Newbie questions in context of using the processors on ESP32.
* As I understand CPU0 is assigned for processing protocols (e.g. Wifi, BT, I2C, etc), and CPU1 is for application. Is this my understanding correct? If yes, how about when using the Arduino framework?
* How is the protocol CPU processing modeled? To elaborate the question using an example: when a Bluetooth data packet is received, it somehow is processed on CPU0 only. But then how is it made available for application - is the packet given to the application for processing on CPU0, or is it posted such that the processing occurs only on CPU1?

I am attempting to determine whether or not in the application code I need to use mutexes/locks/semaphores/synchronization to prevent multi threading issues.

[ESP_igrr]

The names "protocol" and "application" are somewhat of a legacy. In practice the only difference is that the CPU0 is responsible for application startup (up to the point when app_main runs). From that point on, FreeRTOS tasks can be created and run on CPU0, on CPU1, or scheduled automatically (on CPU0 or CPU1, the scheduler will decide). WiFi and BT create tasks pinned to CPU0 by default, but some of the tasks can be moved to CPU1, if needed, using settings found in menuconfig. ESP-IDF app_main function is called from a "main" task running on CPU0. Arduino setup and loop functions are called from a task running on CPU1. You can create more tasks and pin them to whichever CPU you need.
If your code runs in one task pinned to one CPU, then the concurrency issues you might run into are related to receiving callbacks from other tasks (mainly Wi-Fi events and Bluetooth stack callbacks). Your callback will be called in the context of another task, which might be on a different CPU.
It is recommended to use FreeRTOS primitives (queues, semaphores, etc.) to implement communication between tasks, or between interrupts and tasks.