microsoft ⁽⁵⁾

Generally, the advice on unit testing in embedded environments is to run your tests on the PC host rather than on the target device. Whilst I agree that this is the most productive arrangement, there are a variety of reasons for needing to test on the target which can be convincing in certain situation. The technique described here allows for both. Mike Long in his GOTO 2015 presentation Continuous Delivery for Embedded Systems says "Test on your host because that's fast - it's a really fast way to develop. But also test on the target because behaviour can change in different ways, different compilers, different hardware..." Niall Cooling in his talk at the EmbeddedOnlineConference 2020 "How agile is changing the face of embedded software development" says (at 46m) on the gap between testing on the host and the target Things like TDD really are based on testing in the host, and really that's fine but of course we are typically using host compilers like host GCC and of course we know that at the moment this is typically going to be an Intel based processor. So we are compiling for the underlying OS. And it is good for finding a…

Excel is a great all purpose tool, used by maybe 7% of the world's population. From shopping lists to budgets, Gantt charts and calendars to circuit simulators and digital music workstations, it can do it all. It is so good at so many things and so universally available to businesses that in many cases the biggest competition for software startups is not other specialized software solving the same problems but Excel. When it comes to using Excel for engineering tasks, there are lots of known pitfalls. Treating values as dates, or strings which are supposed to be hex like "51E67" as scientific format is one big category of pitfalls. Another is that although the probability of an error in any one cell is small, when you have a high number of cells all dependent on each other, the probability of error somewhere in the sheet means that the final result is likely to be wrong. The canonical case study is Reinhart and Rogoff, covered by a talk I highly recommend, Emery Berger's "Saving the World from Spreadsheets". So cross checking or auditing become necessary. Use CTRL-` to switch between formula view and value view. In common with many computer languages,…

SES Include File ManagerA simple helper application for use with Segger Embedded Studio when working with the Nordic Semiconductor SDK. The application checks which paths exist and allows you to remove those that don’t, allows a search by filename to show which folder they are in, and allows conversion between relative and absolute paths for the include folders. (It does not search your SDK folder for include files to automatically add them to the include paths.) The Nordic SDK folder is structured so that many include files which are needed for a project are in different folders. All of the folder paths need to be added to the c_user_include_directories definition for the project to compile. It is time consuming to search for each include file that a compile will complain about being missing so that it’s path can be added to the project c_user_include_directories. It is easy to end up with duplicate paths and unnecessary paths. The relative path can be tricky to manage due to its change of depth (number of ../) when a project is moved within the folder structure. Opens the file, parses it and shows the results in two lists - Include Paths and Include Files.

Segger Embedded Studio project files appear to be XML formatted with a custom DOCTYPE. <!DOCTYPE CrossStudio_Project_File> <solution Name="ble_app_MA_lightbulb_pca10040_s132" target="8" version="2"> <project Name="ble_app_MA_lightbulb_pca10040_s132"> <configuration Name="Common" arm_architecture="v7EM" arm_core_type="Cortex-M4" arm_endian="Little" arm_fp_abi="Hard" arm_fpu_type="FPv4-SP-D16" arm_linker_heap_size="8192" arm_linker_process_stack_size="0" arm_linker_stack_size="8192" arm_linker_treat_warnings_as_errors="No" ... /> <configuration Name="Debug" c_preprocessor_definitions="DEBUG; DEBUG_NRF" gcc_optimization_level="None" /> </solution>ReadingIn VB.NET, Private xmlDoc As XmlDocument = New XmlDocument()xmlDoc.PreserveWhitespace = TruexmlDoc.XmlResolver = NothingxmlDoc.Load(filename)Once the XML is loaded, an attribute such as c_user_include_directories can be read using this syntax sIncludes = xmlDoc.SelectSingleNode("solution/project/configuration[@c_user_include_directories]").Attributes("c_user_include_directories").ValueWritingHowever, writing out an this XML document object back to a file has a few problems. The DOCTYPE tag changes in that additional square brackets [] appear at the end due to a bug in the .NET framework, so you get <!DOCTYPE CrossStudio_Project_File []> which although is valid XML, causes SES to say that the file is not a valid project. The workaround is to create a new XML Document object and replace the Document Type with a new one, with Nothing (in VB.NET, equivalent to null in C#) for the subset object, as distinct from an empty string. Dim n As XmlDocument = New XmlDocument()n = xmlDoc.Clone()Dim parent As XmlNode = n.DocumentType.ParentNode'4th param in CreateDocumentType has to be Nothing to avoid getting [] in DOCTYPE, which is what…

The type 'MainWindow' was not found. Verify that you are not missing an assembly reference and that all referenced assemblies have been built. Microsoft say this will be fixed in 16.3 Visual Studio 16.3 fixed this.