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
replyhttps://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.
reply[flagged]
replyThis 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.
replyI 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.
replyThis 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.
replyI would also love to hear that the authors of this book suggest.