Thank you for response. I think so but it is interesting to know different points of view. Strategy used in Pebble looks pretty good.
Nice article. Unfortunately my development machine is Windows and I used to work with it.
I tried to compile cpputest with mingw/cmake/“gnu make for windows” and it worked, now I have the two .a libraries.
I tried to use MakefileWorker.mk, but it seems it isn’t compatible with Windows standard tools. It uses uname, mktemp and so on. Any chance to port that Makefile so it works with a standard Windows command line?
Any suggestions how to use cpputest under Windows, without using Cygwin?
We have a library that is sort of Hardware Abstraction Layer for different families of MCU (at least all of them are Cortex-M devices). Basically the code is bunch of SDK function calls from MCU manufacturer with very occasional logic (check if parameter is NULL etc.)
I’m thinking how we can test it to add new platform support easier. The unit tests are not the best fit. Now suppose we want to support a new platform. Manual testing if peripheral is working is a bit daunting task but I think this is the only way to do it. I suppose this part of the code won’t change much over time.
Great intro, @tyler . I’m really hoping to lean into automated unit tests in our new project.
One problem I’m seeing in my initial dabbling (Ceedling/Unity) are build errors around datatype mismatches between the 32-bit MCU (Cortex-M4) embedded code and the x64 test code. Clearly a uint32_t is the same size on all architectures… but (e.g.) time_t is not.
I also have a [probably unfounded] concern that gcc-7.x used for the target hardware is going to do something subtly different than gcc-12.x. Should I attempt to use an older gcc for the test code?
Is there a generic way to build the test code as a 32-bit application, or would you deal with specific issues – i.e. sizeof(time_t) – as they arise?
Kind regards,
+Joel.