host-apps.rst 6.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189
  1. Running ESP-IDF Applications on Host
  2. ====================================
  3. :link_to_translation:`zh_CN:[中文]`
  4. .. note::
  5. Running ESP-IDF applications on host is currently still an experimental feature, thus there is no guarantee for API stability. However, user feedback via the `ESP-IDF GitHub repository <https://github.com/espressif/esp-idf>`_ or the `ESP32 forum <https://esp32.com/>`_ is highly welcome, and may help influence the future of design of the ESP-IDF host-based applications.
  6. This document provides an overview of the methods to run ESP-IDF applications on Linux, and what type of ESP-IDF applications can typically be run on Linux.
  7. Introduction
  8. ------------
  9. Typically, an ESP-IDF application is built (cross-compiled) on a host machine, uploaded (i.e., flashed) to an ESP chip for execution, and monitored by the host machine via a UART/USB port. However, execution of an ESP-IDF application on an ESP chip can be limiting in various development/usage/testing scenarios.
  10. Therefore, it is possible for an ESP-IDF application to be built and executed entirely within the same Linux host machine (henceforth referred to as "running on host"). Running ESP-IDF applications on host has several advantages:
  11. - No need to upload to a target.
  12. - Faster execution on a host machine, compared to running on an ESP chip.
  13. - No requirements for any specific hardware, except the host machine itself.
  14. - Easier automation and setup for software testing.
  15. - Large number of tools for code and runtime analysis, e.g., Valgrind.
  16. A large number of ESP-IDF components depend on chip-specific hardware. These hardware dependencies must be mocked or simulated when running on host. ESP-IDF currently supports the following mocking and simulation approaches:
  17. 1. Using the `FreeRTOS POSIX/Linux simulator <https://www.freertos.org/FreeRTOS-simulator-for-Linux.html>`_ that simulates FreeRTOS scheduling. On top of this simulation, other APIs are also simulated or implemented when running on host.
  18. 2. Using `CMock <https://www.throwtheswitch.org/cmock>`_ to mock all dependencies and run the code in complete isolation.
  19. In principle, it is possible to mix both approaches (POSIX/Linux simulator and mocking using CMock), but this has not been done yet in ESP-IDF. Note that despite the name, the FreeRTOS POSIX/Linux simulator currently also works on macOS. Running ESP-IDF applications on host machines is often used for testing. However, simulating the environment and mocking dependencies does not fully represent the target device. Thus, testing on the target device is still necessary, though with a different focus that usually puts more weight on integration and system testing.
  20. .. note::
  21. Another possibility to run applications on the host is to use the QEMU simulator. However, QEMU development for ESP-IDF applications is still a work in progress and has not been documented yet.
  22. CMock-Based Approach
  23. ^^^^^^^^^^^^^^^^^^^^
  24. This approach uses the `CMock <https://www.throwtheswitch.org/cmock>`_ framework to solve the problem of missing hardware and software dependencies. CMock-based applications running on the host machine have the added advantage that they usually only compile the necessary code, i.e., the (mostly mocked) dependencies instead of the entire system. For a general introduction to Mocks and how to configure and use them in ESP-IDF, please refer to :ref:`mocks`.
  25. POSIX/Linux Simulator Approach
  26. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  27. The `FreeRTOS POSIX/Linux simulator <https://www.freertos.org/FreeRTOS-simulator-for-Linux.html>`_ is available on ESP-IDF as a preview target already. This simulator allows ESP-IDF components to be implemented on the host, making them accessible to ESP-IDF applications when running on host. Currently, only a limited number of components are ready to be built on Linux. Furthermore, the functionality of each component ported to Linux may also be limited or different compared to the functionality when building that component for a chip target. For more information about whether the desired components are supported on Linux, please refer to :ref:`component-linux-mock-support`.
  28. .. only:: not esp32p4
  29. .. note::
  30. The FreeRTOS POSIX/Linux simulator allows configuring the :ref:`amazon_smp_freertos` version. However, the simulation still runs in single-core mode. The main reason allowing Amazon SMP FreeRTOS is to provide API compatibility with ESP-IDF applications written for Amazon SMP FreeRTOS.
  31. Requirements for Using Mocks
  32. ----------------------------
  33. .. include:: inc/linux-host-requirements.rst
  34. If any mocks are used, then ``Ruby`` is required, too.
  35. Build and Run
  36. -------------
  37. To build the application on Linux, the target has to be set to ``linux`` and then it can be built and run:
  38. .. code-block:: bash
  39. idf.py --preview set-target linux
  40. idf.py build
  41. idf.py monitor
  42. .. _component-linux-mock-support:
  43. Component Linux/Mock Support Overview
  44. -------------------------------------
  45. Note that any "Yes" here does not necessarily mean a full implementation or mocking. It can also mean a partial implementation or mocking of functionality. Usually, the implementation or mocking is done to a point where enough functionality is provided to build and run a test application.
  46. .. list-table::
  47. :header-rows: 1
  48. :widths: 20 10 10
  49. * - Component
  50. - Mock
  51. - Simulation
  52. * - cmock
  53. - No
  54. - Yes
  55. * - driver
  56. - Yes
  57. - No
  58. * - esp_common
  59. - No
  60. - Yes
  61. * - esp_event
  62. - Yes
  63. - Yes
  64. * - esp_http_client
  65. - No
  66. - Yes
  67. * - esp_http_server
  68. - No
  69. - Yes
  70. * - esp_https_server
  71. - No
  72. - Yes
  73. * - esp_hw_support
  74. - Yes
  75. - Yes
  76. * - esp_netif
  77. - Yes
  78. - Yes
  79. * - esp_netif_stack
  80. - No
  81. - Yes
  82. * - esp_partition
  83. - Yes
  84. - Yes
  85. * - esp_rom
  86. - No
  87. - Yes
  88. * - esp_system
  89. - No
  90. - Yes
  91. * - esp_timer
  92. - Yes
  93. - No
  94. * - esp_tls
  95. - Yes
  96. - Yes
  97. * - fatfs
  98. - No
  99. - Yes
  100. * - freertos
  101. - Yes
  102. - Yes
  103. * - hal
  104. - No
  105. - Yes
  106. * - heap
  107. - No
  108. - Yes
  109. * - http_parser
  110. - Yes
  111. - Yes
  112. * - json
  113. - No
  114. - Yes
  115. * - linux
  116. - No
  117. - Yes
  118. * - log
  119. - No
  120. - Yes
  121. * - lwip
  122. - Yes
  123. - Yes
  124. * - mbedtls
  125. - No
  126. - Yes
  127. * - mqtt
  128. - No
  129. - Yes
  130. * - nvs_flash
  131. - No
  132. - Yes
  133. * - partition_table
  134. - No
  135. - Yes
  136. * - protobuf-c
  137. - No
  138. - Yes
  139. * - pthread
  140. - No
  141. - Yes
  142. * - soc
  143. - No
  144. - Yes
  145. * - spiffs
  146. - No
  147. - Yes
  148. * - spi_flash
  149. - Yes
  150. - No
  151. * - tcp_transport
  152. - Yes
  153. - No
  154. * - unity
  155. - No
  156. - Yes