I'm planning to use cpputest as a testing framework in my project which I need to cross compile as it will be used on ARM platform. The compiler I'm using for ARM development is arm-gcc which is built with pthreads disabled. Due to this, I need to build cpputest without pthreads. Currently l am following the autotool approach for building cpputest. Any help would be really appreciated.
Are you trying to compile, download, and run CppUTest on a target device?
Typically, CppUTest isn't compiled and downloaded to your target device but instead it's built as a Windows (or Linux) console application. This means that CppUTest gets compiled using a native compiler (Visual Studio or GCC) but your firmware will also need to compile using that same native compiler (Visual Studio or GCC).
Unit testing is meant to verify that your code's logic is correct, which means it doesn't matter if the code is executing on an ARM processor or in an Intel processor. For the record, when I first started getting into unit testing this blew my mind.
But what about hardware registers and stuff like that? Well, there's ways around testing embedded devices hardware in a Windows environment. At the end of the day, you'll still need to download your firmware onto the embedded device and verify that your port mappings are correct (i.e. That you're properly settings up a GPIO port to turn on an LED for instance).
There's several advantages to running your unit testing on your development PC instead of on target. Your development PC is much faster, has more resources (i.e. storage and RAM) and it also easily allows for running in a continuous integration environment (like Jenkins or TeamCity) whenever you check-in code to your version control system.
I highly recommend the book Test-Driven Development for Embedded C by James W. Grenning for more information. It will answer all your questions on unit testing on an embedded device. CppUTest can be used for C as well as C++ projects.
Related
This might be a very specific question. But it might be interesting for some other people, too.
The setting might be quite common: we develop an embedded device using C++ and Linux and have a build system for this. With our device we ship a C# desktop app using a DLL based plugin mechanism. The plugin contains the shared logic used both on the embedded device and the app. To keep processes easy it would be best to create the DLL on our Linux build system (hence I would like to use .Net Core and not "normal" .Net).
As far as my trial and error showed it's not possible - even with .Net Core 3.1. Can you confirm this? The software is for windows only (although it's compiled on Linux) - so theoretically it could possible since .Net Core supports CLI/C++ in Version 3.1 (https://devblogs.microsoft.com/dotnet/announcing-net-core-3-1/).
What I tried:
I compiled pure C# code on Linux to an exe running successfully on windows using the console app dotnet
I successfully created a simple C++/CLI test app on Windows using sample code following this guide: https://devblogs.microsoft.com/cppblog/an-update-on-cpp-cli-and-dotnet-core/
Finally I took the (probably for too naive) approach to replace the test app's .vcxproj with the .csproj of step 1 (.csproj seems to detect files automatically). I got the following error message:
quote CSC : error CS5001: Program does not contain a static 'Main' method suitable for an entry point [/home/vagrant/Projects/cpp_dotnet_on_linux/cs_on_linux.csproj]
Is there something I can improve or is the task just impossible (adding the cpp-files manually to .csproj, ...)? I'm afraid it's just technically impossible because I guess .Net Core is missing a C++ compiler on Linux but I'm not sure.
C++/CLI is not support on Linux.
Some sources:
https://devblogs.microsoft.com/cppblog/the-future-of-cpp-cli-and-dotnet-core-3/ :
We don’t currently have plans for C++/CLI for targeting macOS or Linux. Additionally, compiling with “/clr:pure” and “/clr:safe” won’t be supported for .NET Core.
https://github.com/dotnet/coreclr/issues/659#issuecomment-539742740
C++/CLI on Linux will not be supported and would be very challenging. It would require Microsoft VC++ to support Linux or require Clang or GCC to support C++/CLI. Those are both huge projects with uncertain payoff. It is also unclear if Clang or GCC would ever allow us to upstream our changes. Maintaining an up-to-date fork of a fast moving compiler project forever is very expensive. We have no plans to take on either of those projects.
We want to try to launch our software on Chrome OS using ARC. Many parts of our software application are written in C++ and compiled using the Android NDK.
Is it possible to launch this kind of application under ARC?
Is it possible to launch Native applications(or Java + JNI) under ARC?
Yes, ARM compiled NDK libraries will run on all Chromebooks currently. For ARM machines they run more or less natively.
For non-ARM machines there is a binary translation layer that dynamically converts the code to run on the target machine. This layer may not be 100% machine compatible and if you see errors or crashes indicating instructions cannot be translated, or fundamental differences between your app on ARM and x86, you should file a bug: http://goo.gl/megdlG
I am currently using a library in my project called PDFtron. It contains ".so" files that I have to assume are either c or c++, and they work fine with Java + JNI. There doesn't seems to be a lot of information out there about how this all works(and what works or doesn't), so please post your findings.
From google spokesperson(taken from arstechnica):
"""The app code is all running on top of the Chrome platform, specifically inside of Native Client. In this way the ARC (App Runtime for Chrome) apps run in the same environment as other apps you can download from the Chrome Web Store, even though they are written on top of standard Android APIs. The developers do not need to port or modify their code, though they often choose to improve it to work well with the Chromebook form factor (keyboard, touchpad, optional touchscreen, etc)."""
In this quote I think the important part is the integration with native client, which is a technology for executing Native code like C and C++ in the browser.
I have an executable I made using a CLI console application with Visual Basic 2010. I can run the program completely fine from my developer machine.
However, when I copy the executable over to another machine, re-boot to a pre-installation environment and run the executable again, nothing happens at all. There are no errors shown or anything.
My guess is the executable can't run without certain dependencies that aren't loaded at this environment, but I need it to work in a PE.
Any ideas on whats going on?
First of all, since the question is tagged "c++" and you mention C++/CLI several times, I assume that "Visual Basic 2010" is a typo for "Visual Studio 2010". But either way, whether you've written the application in Visual Basic (VB.NET) or C++/CLI, the problem is exactly the same.
My guess is the executable can't run without certain dependencies that aren't loaded at this environment, but I need it to work in a PE.
That's exactly correct. You've written an application that targets the .NET Framework. Somewhat like Java applications requiring a JVM, .NET applications require that the .NET Framework be installed in order to run (or a compatible alternative implementation, like Mono). Unfortunately, Windows PE does not support the .NET Framework.
Note that it is irrelevant whether you've written a WinForms, WPF, or Console application. Although they present their UI in very different ways, they all depend on the .NET Framework being installed.
You will need to (re-)write the application in a different programming language, one that generates native code without any dependencies on the .NET Framework. C and C++ are popular choices. If you choose to use C++, make sure that you create what Visual Studio calls a "Win32" project. This is one that targets the underlying operating system APIs directly (i.e. a native application) and does not have a dependency on the .NET Framework. Stay away from anything that has ".NET" or "CLR" in its description.
I don't really have a full comprehension of when an application is using .NET or not... I am just used to Linux C/C++ development. I hate Microsoft shit
It uses .NET whenever you use the .NET Framework libraries/classes in your code. I'm not really sure why this is so difficult to understand. The same problem could easily exist on Linux if you were using a third-party library that was not available in certain environments for whatever reason. This is not Microsoft's problem, it's an issue of using the wrong tools for the job. The .NET Framework is an object-oriented wrapper around the native APIs that makes it much easier for people to get up and running writing programs for Windows. But if you're "used to Linux C/C++ development", you should have little trouble writing a simple console application that targets the native APIs directly without using .NET.
If your hatred for "Microsoft shit" has turned into an allergy, you can avoid Visual Studio entirely and download MinGW, which is a Windows port of the GCC compiler you're probably used to. Combined with your favorite Windows port of Vi, you're working in an environment very similar to the one you're used to. And since GCC doesn't support C++/CLI or the .NET Framework, you won't have to worry about getting stuck picking the wrong option.
The .Net framework has been supported as an optional package install during your PE build process for the past couple versions of WinPE. I write code in C# that I run in WinPE everyday. I have yet to find a good way to debug in a manner where I can walk through break points, etc... though. My best option has just been a lot of logging and a global Exception catch around my main entry point that will write out a full stack dump. You can attach to your app as a remote process in a VM running WinPE, but if you need to catch something early in the execution you'll have a difficult time.
I come from the world of Java and JUnit. I made a demonstration of Hudson and all what I achieve there with JUnit among other things. I would like to do the same with C++ code on an embedded device but can't find where to start.
THe project is compiled with iccarm.exe (IAR compiler) Right now the output is converted into an image file using romutil.exe to be flashed to the ARM9 board.
I tried to follow this tutorial: http://netbeans.org/kb/docs/cnd/c-unit-test.html but I'm having issues trying to figure out how to port it to my case.
Can I run unit tests on the C++ code outside of the device? (i.e. for doing it with Hudson to gather reports and so on)
Can I turn the output into an exe? (looks like Netbeans expects it to be)
What's the most appropriate unit framework for my case? (CppUnit, CUnit, etc)
Any help/direction is more than welcome.
1) You could build a cross-compiler, and then instead of using iccarm.exe, use the cross compiler. There are lots of tutorials on the net how to build a cross compiler using gcc. Then instead of building for the target (using cross compiler) build for your host using normal compiler.
3) Whatever you like. cppunit, google unit tests, etc
What code coverage tools have you used with Symbian C++ and Maemo? What are the pros and cons of the tool you are using?
On Symbian I've used BullseyeCoverage and Testwell CTC++. Cannot really describe the pros/cons of them in detail. Both got the job done, eventually. Both needed some effort with setup and integration with an automated test suite. Both contained bugs that e.g. crashed the downstream compiler with slightly broken instrumented source code.
On Maemo, since the toolchain is GCC based, I'd guess gcov would be a good starting point. Though I haven't been working on Maemo much yet and haven't done any coverage measurement there.
See SD C++ Test Coverage for a tool that has extremely low overhead and works very well in embedded environments.
I have used Bullseye Coverage on Symbian and it is very good. The only problem is that it only runs on emulator and not hardware. Therefore you would not be able to get coverage metrics from a device or devboard. If your app runs on both hardware and emulator, this won't be a big deal (apart from the standard differences between running on emulator vs hardware). Also, as there are plans to replace the emulator with a proper hardware simulator, perhaps bullseye wouldn't be the best choice.
gcov can be used (and is used) in maemo platform and tool called lcov can then be used to generate "pretty" reports.
However, in order use gcov in maemo sdk, you need to disable compiler cache during the build time when you are creating binaries for coverage execution..