The Rust on ESP Book
docs.espressif.com
The Rust on ESP Book
1–10 of 25 posts
Re: The Rust on ESP Book
#2The [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.
What is the recommended way to test on the host?
[1]: https://docs.espressif.com/projects/rust/book/application-development/testing.htmlRe: The Rust on ESP Book
#3The [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 `…
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.
Re: The Rust on ESP Book
#4The [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 `…
Especially for embedded work (but for regular software too!) I've bought into the "sans-io pattern" for a lot of the software i write anymore
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
Re: The Rust on ESP Book
#5awesome 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.
Re: The Rust on ESP Book
#6The [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 `…
Especially for embedded work (but for regular software too!) I've bought into the "sans-io pattern" for a lot of the software i write anymore 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 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.
Re: The Rust on ESP Book
#7The [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 `…
Especially for embedded work (but for regular software too!) I've bought into the "sans-io pattern" for a lot of the software i write anymore 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
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.
Re: The Rust on ESP Book
#8The [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 `…
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.
Re: The Rust on ESP Book
#9BUN in oven
Re: The Rust on ESP Book
#10Earlier quoted context omitted.
Especially for embedded work (but for regular software too!) I've bought into the "sans-io pattern" for a lot of the software i write anymore 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 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.
[flagged]