Rendered at 18:41:17 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
iconara 4 days ago [-]
The [page on testing][1] suggests this:
> Where possible, and where it makes sense, you should try to test as much as possible on your host machine, not on the target device.
When I have tried this I have encountered multiple problems, first that the Rust test framework requires std, making it convoluted writing test code – but when working around that using conditional compilation, I run into other things like the `esp-hal` depending on crates that won't compile on the host.
I don't use the the builtin testing framework, or std, and I often explicitly use a no-heap crate. Check out Embassy and you'll be free to ignore pretty almost everything suggested here, especially when developing and testing. I create a separate [bin] for each test (I usually run out of flash to fit all the tests into a single binary), and a few lines of bash/python to make a test runner/reporter for all the flashing and running of tests. Sometimes I flash up to 50 times a day and haven't lost an MCU (AVR-Rust, ESP-Rust, STM-Rust) yet due to too many writes.
Keeping all of the actual hardware/network/io interface code separate really makes writing unit tests and porting to different computers much simpler
tredre3 21 minutes ago [-]
This is good advice however it should be noted that many of espressif's other purely software components depend on esp-hal, so you still want it to compile if you use any of espressif's provided components.
tylerc230 23 minutes ago [-]
I do something similar. I have all my esp/idf code in one crate and all my business logic in a separate crate. The business crate has no dependencies that won’t compile/run on the host. This is where all my tests live.
devmor 1 hours ago [-]
This is a constant issue for me in every facet of embedded development - with the sole exception of devices that can easily be tested in a qemu environment.
I would also love to hear that the authors of this book suggest.
jauntywundrkind 41 minutes ago [-]
awesome to see this under espressif.com! that's so fantastic.
not to the point here, but i wonder what Zephyr would have been like if Rust had been more of a thing at the time. that's not really possible, as from my understanding it derived from Wind River Systems' donated Rocket OS, which i think predates Rust (which is not a new language!). still an interesting what if to me: zephyr seems to be the embedded os with the best wireless support by a country mile, have a lot of companies targeting it (often alas forking it rather than going upstream): it holds my interest the most.
> Where possible, and where it makes sense, you should try to test as much as possible on your host machine, not on the target device.
When I have tried this I have encountered multiple problems, first that the Rust test framework requires std, making it convoluted writing test code – but when working around that using conditional compilation, I run into other things like the `esp-hal` depending on crates that won't compile on the host.
What is the recommended way to test on the host?
[0] https://github.com/embassy-rs/embassy
https://sans-io.readthedocs.io/how-to-sans-io.html
Keeping all of the actual hardware/network/io interface code separate really makes writing unit tests and porting to different computers much simpler
I would also love to hear that the authors of this book suggest.
not to the point here, but i wonder what Zephyr would have been like if Rust had been more of a thing at the time. that's not really possible, as from my understanding it derived from Wind River Systems' donated Rocket OS, which i think predates Rust (which is not a new language!). still an interesting what if to me: zephyr seems to be the embedded os with the best wireless support by a country mile, have a lot of companies targeting it (often alas forking it rather than going upstream): it holds my interest the most.