{"id":6588,"date":"2020-09-17T09:39:31","date_gmt":"2020-09-17T16:39:31","guid":{"rendered":"https:\/\/visualgdb.com\/w\/?p=6588"},"modified":"2020-10-23T08:29:28","modified_gmt":"2020-10-23T15:29:28","slug":"creating-simulation-platforms-to-test-embedded-code-without-hardware","status":"publish","type":"post","link":"https:\/\/visualgdb.com\/tutorials\/arm\/cmake\/simulation\/","title":{"rendered":"Creating Simulation Platforms to Test Embedded Code without Hardware"},"content":{"rendered":"

This tutorial shows how to run high-level code of embedded projects directly on Windows in order to speed up development and tests. We will create a unit test project based on the TinyEmbeddedTest framework<\/a>, will run the tests on the STM32F4 Discovery board, and will then create a separate simulation platform to run the tests directly on Windows.<\/p>\n

Before you begin, install VisualGDB 5.5 or later.<\/p>\n

    \n
  1. Start Visual Studio and open the VisualGDB Embedded Project Wizard:\"\"<\/a><\/li>\n
  2. Enter the name and location of your project: \"\"<\/a><\/li>\n
  3. On the first page of the VisualGDB Project Wizard select “Unit Test -> Advanced CMake”. Make sure you are using the TinyEmbeddedTest<\/strong> or GoogleTest<\/strong> framework, as other frameworks do not support portability between Windows and embedded targets: \"\"<\/a>If you are using Keil or IAR, start with creating a regular embedded CMake project and then reference the test framework (e.g. see this tutorial<\/a>).<\/li>\n
  4. Select the toolchain and device you would like to target and press “Next”:\"\"<\/a><\/li>\n
  5. Pick the basic test sample and proceed to the next page: \"\"<\/a><\/li>\n
  6. Finally, select the debug settings that work with your target and click “Finish”: \"\"<\/a><\/li>\n
  7. VisualGDB will create a CMake-based unit test project for the selected device. Try building it, and once the tests are discovered, run them via Test->Run All Tests: \"\"<\/a><\/li>\n
  8. VisualGDB will display the test outcome in the Test Explorer window: \"\"<\/a><\/li>\n
  9. The previous command ran the tests directly on the hardware, limiting the speed and the amount of available memory (you can still use Test Resources<\/a> to feed large data streams into the device). Now we will create a separate VS platform to run the tests directly on Windows. Right-click on the project node in Solution Explorer (CMake icon) and select “Add a Simulation Platform”:\"\"<\/a><\/li>\n
  10. VisualGDB will ask you for a MinGW-based toolchain (can be installed automatically), the name of the simulation platform, and will offer renaming the regular platform from “VisualGDB” to “hardware”. Press “OK” to confirm the platform names: \"\"<\/a><\/li>\n
  11. Once the platform is created, switch to it via the VS Platform selector. Note that if you try building the project now, it will fail due to missing STM32-specific headers:\"\"<\/a><\/li>\n
  12. This happens because the simulation platform does not emulate any target-specific hardware. Instead, it provides an easy way to build the high-level code with MinGW (GCC for Windows), relying on your own abstraction layer. In this example we will resolve the errors by wrapping STM32-specific code with #ifndef SIMULATION. <\/strong>You can also prevent STM32-specific files (e.g. system_stm32f4xx.c<\/strong>) from building via the “Exclude from Build” command (we will show how to make the exclusion conditional later):\"\"<\/a>WARNING: If you are using GoogleTest, update the main() function to pass the command-line arguments to InitGoogleTest() as shown here<\/a>.<\/strong><\/li>\n
  13. Now you will be able to build the project and run unit tests:\"\"<\/a>If the tests do not appear in Test Explorer, try closing and reopening the solution to reset any VS-level caches.<\/li>\n
  14. The tests will work the same way as they do for embedded targets, as long as they don’t include any hardware-specific code:\"\"<\/a><\/li>\n
  15. If you try building the hardware platform now, it will fail because we have excluded the system_stm32f4xx.c<\/strong> file from building. To make the exclusion conditional, locate the set_source_file_properties()<\/strong> statement in CMakeLists.txt<\/strong> and wrap it with if(SIMULATION)\/endif()<\/strong>:\"\"<\/a><\/li>\n
  16. If you would like to run some tests only on hardware (or only on simulation), you can always move them into a separate test executable. Right-click on the project node in Solution Explorer and select Add->New Item<\/strong>. Then select “Embedded Executable”<\/strong>: \"\"<\/a><\/li>\n
  17. Right-click on the executable and select Add->Add Reference<\/strong>. Then reference the test framework:\"\"<\/a><\/li>\n
  18. Replace the contents of the main source file with the following code:\n
    #include <TinyEmbeddedTest.h>\r\n\r\nTEST_GROUP(AnotherTestGroup)\r\n{\r\n};\r\n\r\nTEST(AnotherTestGroup, AnotherTest)\r\n{\r\n}\r\n\r\nint main()\r\n{\r\n    RunAllTests();\r\n    return 0;\r\n}<\/pre>\n<\/li>\n
  19. Then right-click on the executable and select “Disable for Current Platform”:\"\"<\/a><\/li>\n
  20. This will prevent AnotherTestExecutable <\/strong>from being built on the Hardware<\/strong> platform (see the EXCLUDED_PLATFORMS<\/strong> parameter CMakeLists.txt)<\/strong>, but will still let you build and run the tests declared in it using the Simulation platform:\"\"<\/a>If you would like to add code for simulating some STM32-specific peripherals, we advise placing it into a separate static library and disabling it for the Hardware<\/strong> platform. Disabled libraries will remain in Solution Explorer (so you can reference them unconditionally), but will not build any source files unless you switch to a supported platform.<\/li>\n
  21. Finally, we will show how to build and run Embedded CMake test projects outside Visual Studio so that you can integrate them into your Continuous Integration environment. Open the Windows command prompt in the project directory and run the following command lines:\n
    \"%VISUALGDB_DIR%\\VisualGDB.exe\" \/build EmbeddedSimulationDemo.vgdbcmake \/platform:Hardware \/config:Debug\r\n\"%VISUALGDB_DIR%\\VisualGDB.exe\" \/build EmbeddedSimulationDemo.vgdbcmake \/platform:Simulation \/config:Debug<\/pre>\n
    The first command line will build the unit tests for the hardware platform, while the second one will build Win32 executables using the MinGW toolchain:\"\"<\/a><\/li>\n
  22. Once the project is built, you can run all tests in a specific executable using the following command line:\n
    \"%VISUALGDB_DIR%\\VisualGDB.exe\" \/runtests EmbeddedSimulationDemo.vgdbcmake \/platform:Simulation \/config:Debug \/targetpath:build\\Simulation\\Debug\\EmbeddedSimulationDemo.exe \/vsoutput:results.trx<\/pre>\n
    \"\"<\/a>Note that when running tests from Visual Studio, VisualGDB will query CMake for the detailed project structure, and will then determine the paths to the built executables from it. This step is skipped when running tests from command line, so the exact path to the built executable needs to be specified via the \/targetpath<\/strong> parameter. If you would like to run tests from multiple executables (e.g. EmbeddedSimulationDemo.exe<\/strong> vs. AnotherTestExecutable.exe<\/strong>), simply invoke VisualGDB.exe multiple times, specifying a different target path each time.<\/li>\n
  23. You can also run the tests directly on the hardware using the command line shown below:\n
    \"%VISUALGDB_DIR%\\VisualGDB.exe\" \/runtests EmbeddedSimulationDemo.vgdbcmake \/platform:Hardware \/config:Debug \/targetpath:build\\Hardware\\Debug\\EmbeddedSimulationDemo \/vsoutput:results.trx<\/pre>\n
    The results will be saved into the results.trx<\/strong> file compatible with the test results files<\/a> produced by Visual Studio itself.<\/li>\n<\/ol>\n
    You can find the source code of the project shown in this tutorial in our Github repository<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
    This tutorial shows how to run high-level code of embedded projects directly on Windows in order to speed up development<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[222],"tags":[77,133,223,61,129],"_links":{"self":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/6588"}],"collection":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/comments?post=6588"}],"version-history":[{"count":7,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/6588\/revisions"}],"predecessor-version":[{"id":7051,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/6588\/revisions\/7051"}],"wp:attachment":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/media?parent=6588"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/categories?post=6588"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/tags?post=6588"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}