bartoszek/zephyr
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
3b26d50012
zephyr/samples/drivers/ipm/ipm_esp32
History
Gerard Marull-Paretas 79e6b0e0f6 includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h> 
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.

The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.

NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-09-05 16:31:47 +02:00
..
boards
ipm_esp32_net includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h> 2022-09-05 16:31:47 +02:00
src includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h> 2022-09-05 16:31:47 +02:00
CMakeLists.txt
prj.conf
README.rst
sample.yaml

README.rst 

.. _ipm_esp32:

ESP32 Soft-IPM example
######################

Overview
********
This simple example can be used with multicore ESP32 Soc, and demonstrates
the software intercore messaging mechanism to be used in AMP applications.

ESP32 has two CPU named APP and PRO, in this simple example PRO send a
message to the APP using the IPM driver, and waits for the APP response
message and prints its contents on console.

ESP32 intercore messaging has up two four channels, the 0 and 1 are
reserved for BT and WIFI messages, and channels 2 and 3 is free to
any application, each channel supports up to 64 bytes of data per
message, so high level protocol is responsible to fragment larger
messages in chunks of 64bytes.

Building and Running the Zephyr Code
************************************

The sample requires two build commands to run, for that reason a pre built
version of esp32_net, the APP cpu side firmware is already provided for quick
tests just type on the console:

.. zephyr-app-commands::
   :zephyr-app: samples/drivers/ipm/ipm_esp32
   :board: esp32
   :goals: build flash
   :compact:

The other option is building from scratch just involve a single extra build command
and file moving, first of all you need to build the esp32_net firmware as follows:

.. zephyr-app-commands::
   :zephyr-app: samples/drivers/ipm/ipm_esp32/ipm_esp32_net
   :board: esp32_net
   :goals: build
   :compact:

Copy output file build/zephyr/esp32_net_firmware.c to samples/drivers/ipm/ipm_esp32/src,
then build the main project and flash as stated earlier, and you would see the following output:

.. code-block:: console

   *** Booting Zephyr OS build zephyr-v3.0.0-1911-g610f489c861e  ***
   PRO_CPU is sending a fake request, waiting remote response...
   PRO_CPU received a message from APP_CPU : APP_CPU: This is a response
   PRO_CPU is sending a fake request, waiting remote response...
   PRO_CPU received a message from APP_CPU : APP_CPU: This is a response
   PRO_CPU is sending a fake request, waiting remote response...
   PRO_CPU received a message from APP_CPU : APP_CPU: This is a response
   PRO_CPU is sending a fake request, waiting remote response...
   PRO_CPU received a message from APP_CPU : APP_CPU: This is a response
   PRO_CPU is sending a fake request, waiting remote response...
   PRO_CPU received a message from APP_CPU : APP_CPU: This is a response
   PRO_CPU is sending a fake request, waiting remote response...
   PRO_CPU received a message from APP_CPU : APP_CPU: This is a response
   PRO_CPU is sending a fake request, waiting remote response...
   PRO_CPU received a message from APP_CPU : APP_CPU: This is a response