FreeRTOS has a posix backend, letting you run freertos on linux or any other posix environment.
Zephyr has support for native posix target, https://docs.zephyrproject.org/latest/h ... index.html, which means you can build and run Zephyr and Zephyr apps on Linux.
Both of these things help with system testing logic and we make use of both for other projects, allowing us to test large amounts of our system all together. We do have to stub out various hardware components, eg, we have simulated motor controllers (and simulated at a level higher than say spi, or CANbus).
Is there such an effort for esp-idf? We'd like to take our whole esp-idf codebase, set the target to posix, and then be able to run valgrind and other analysis tools on the whole codebase.
If there isn't such an effort, is there any interest? I'd love to work on such an effort...
Regards,
Chris
esp-idf posix / linux support for pure software system testing?
-
- Posts: 9766
- Joined: Thu Nov 26, 2015 4:08 am
Re: esp-idf posix / linux support for pure software system testing?
It does. Try 'idf.py set-target linux'. Some more info is here.
Re: esp-idf posix / linux support for pure software system testing?
Hi Chris!
I'd like to elaborate what we currently have. We have a "Linux target" that you can switch on like any other ESP chip target. But this for now is only good for very isolated unit testing. E.g., you can test all the code of a potential sensor driver for an I2C sensor that uses the IDF I2C driver. But all the dependencies have to be mocked. Even FreeRTOS dependencies need to be mocked, currently.
But besides that, we are also working on integrating the upstream FreeRTOS POSIX port (I think that's what you meant with "posix backend"). We are still at the very beginning, the plan is to have a basic version running by the end of this quarter. If you're interested, we can hand over some patches to you once we have basic things running and you can try if it works for you. We'll be very interested in any kind of feedback, in particular to improve the ergonomics of this feature.
An alternative to the Linux target is QEMU https://github.com/espressif/qemu but I just see there's no public documentation available, seems like we haven't released it yet.
Best,
Jakob
I'd like to elaborate what we currently have. We have a "Linux target" that you can switch on like any other ESP chip target. But this for now is only good for very isolated unit testing. E.g., you can test all the code of a potential sensor driver for an I2C sensor that uses the IDF I2C driver. But all the dependencies have to be mocked. Even FreeRTOS dependencies need to be mocked, currently.
But besides that, we are also working on integrating the upstream FreeRTOS POSIX port (I think that's what you meant with "posix backend"). We are still at the very beginning, the plan is to have a basic version running by the end of this quarter. If you're interested, we can hand over some patches to you once we have basic things running and you can try if it works for you. We'll be very interested in any kind of feedback, in particular to improve the ergonomics of this feature.
An alternative to the Linux target is QEMU https://github.com/espressif/qemu but I just see there's no public documentation available, seems like we haven't released it yet.
Best,
Jakob
Re: esp-idf posix / linux support for pure software system testing?
I was wrong: there is documentation to build and use QEMU for ESP32.
https://github.com/espressif/qemu/wiki
Hope this helps!
Jakob
https://github.com/espressif/qemu/wiki
Hope this helps!
Jakob
Re: esp-idf posix / linux support for pure software system testing?
How much support is provided via QEMU? It looked like a pretty good approach actually.
For example would we get networking support? In our case we've got some hardware to mock, like we drive a motor with a pwm, so I'm guessing we'd have to make that a software virtual device.
Is the QEMU approach a better system level testing approach than the linux/posix target? It would seem to check all of the boxes for us:
- No or few modifications to esp-idf code
- Networking support (although we use a cell modem so we'll likely need some kind of software mock for that)
-- For tcp/udp does that work out of the box?
- Pure software testing
I did get the freertos linux/posix working but now I'm thinking this isn't a good approach since it won't work with any modules....
For example would we get networking support? In our case we've got some hardware to mock, like we drive a motor with a pwm, so I'm guessing we'd have to make that a software virtual device.
Is the QEMU approach a better system level testing approach than the linux/posix target? It would seem to check all of the boxes for us:
- No or few modifications to esp-idf code
- Networking support (although we use a cell modem so we'll likely need some kind of software mock for that)
-- For tcp/udp does that work out of the box?
- Pure software testing
I did get the freertos linux/posix working but now I'm thinking this isn't a good approach since it won't work with any modules....
Re: esp-idf posix / linux support for pure software system testing?
Hi Chris,
Regarding other features, the following are currently emulated in QEMU for ESP32:
PRO and APP CPUs, UART, eFuse, SPI1, DPORT (cache, APP CPU control, cross-core interrupt, APB clock config only), RNG, RTC (reset, clock control only), SHA (limited, known issues exist), Timer Group, FRC (legacy) timer, SPI Flash cache, Ethernet (opencores), I2C, RSA, Flash Encryption, SDMMC, PSRAM.
We are in the process of adding AES emulation and fixing bugs in SHA emulation.
There is also a community contribution for emulating Wi-Fi which we plan to review and merge in one of the next releases.
Regarding the future plans, we intend to develop ESP32-C3 emulation.
At the moment, Espressif doesn't promise to provide support to customers who decide to use QEMU at the same level as we provide support for ESP-IDF. We don't intend to abandon the project and will keep developing and maintaining it. If you run into a QEMU bug which is related specifically to ESP chip emulation, we will try to address it, with the timeline being dependent on the severity of the issue. If you run into some peripheral/feature which is not yet emulated in QEMU (like MCPWM), it is unlikely that we will add support for it quickly. If you have a general question about QEMU which is not ESP specific, then most likely you will need to refer to upstream documentation.cmorgan wrote: How much support is provided via QEMU? It looked like a pretty good approach actually.
Yes, you can use Ethernet for networking. Although QEMU doesn't emulate the real ethernet MAC available on the ESP32, we have a driver for "opencores" ethernet MAC in IDF, and this MAC is emulated in QEMU. This means that if you want to test networking, you will need to make a slightly different build for QEMU. Please refer to this section for details: https://github.com/espressif/qemu/wiki# ... et-support.cmorgan wrote: For example would we get networking support? In our case we've got some hardware to mock, like we drive a motor with a pwm, so I'm guessing we'd have to make that a software virtual device.
Regarding other features, the following are currently emulated in QEMU for ESP32:
PRO and APP CPUs, UART, eFuse, SPI1, DPORT (cache, APP CPU control, cross-core interrupt, APB clock config only), RNG, RTC (reset, clock control only), SHA (limited, known issues exist), Timer Group, FRC (legacy) timer, SPI Flash cache, Ethernet (opencores), I2C, RSA, Flash Encryption, SDMMC, PSRAM.
We are in the process of adding AES emulation and fixing bugs in SHA emulation.
There is also a community contribution for emulating Wi-Fi which we plan to review and merge in one of the next releases.
Regarding the future plans, we intend to develop ESP32-C3 emulation.
Who is online
Users browsing this forum: cdollar and 157 guests