Unittest for C++ running on an AtMega32a - c++

I've made a workflow to unit test C code for an AtMega32a. I've used a combination of the C test framework "unity"[1] and the AVR simulator "simavr"[2]. After I write the C code, I push it to a Gitlab server. The Gitlab server downloads and runs a docker container, installs gccavr, simavr to it, compiles the C code, and then runs the code in Simavr. Simavr pipes the messages from unity from the serial port to the console. When the tests are complete, the gitlab server sends me an e-mail with the results.
[1] http://www.throwtheswitch.org/unity
[2] https://github.com/buserror/simavr
Now I would like to do the same, but this time with C++ code. I'm therefore looking for a C++ test suite that:
a) Is written in C++, or can be called from C++ code
b) Runs on an AVR
c) Can send it's messages to the serial port. (So I can run the code also in a real AtMega32a connected to a serial port of my PC)
Do you know of such a suite?
Cheers,
Cedric

Google recently released pigweed, a framework for embedded development in C++, which includes unit test functionality.
It's platform-agnostic and doesn't require heap allocations, so you'd only need to implement an Event Handler interface to report your results through something like the serial port. It also includes a handler example, which you can reimplement the WriteLine function for your platform.
Now, if I recall correctly, the AVR-GCC doesn't include the C++ Standard Library, which would be a problem, because pigweed requires some Standard Library headers. For that, I recommend taking a look at something like ETL, which should implement most of what you need.

Related

Use Go within a Qt C++ project

Is it possible to use a Go API in a Qt C++ project?
I would like to use the following Google API written in Go: https://cloud.google.com/speech-to-text/docs/reference/libraries#client-libraries-install-go
Is it possible to use a Go API in a Qt C++ project?
It could be possible, but it might not be easy and would be very brittle to run Go and Qt code in the same process, since Go and Qt have very different thread (goroutine) and memory models.
However, Go has (in its standard library) many powerful packages to ease the development of server programs, in particular of HTTP or JSONRPC servers.
Perhaps you might consider running two different processes using inter-process communication facilities. Details are operating system specific. I assume you run Linux. Your Qt application could then start the Go program using QProcess and later communicate with it (behaving as a client to your Go specialized "server"-like program).
Then you could use HTTP or JSONRPC to remotely call your Go functions from your Qt application. You need some HTTP client library in Qt (it is there already under Qt Network, and you might also use libcurl) or some JSONRPC client library. Your Go program would be some specialized HTTP or JSONRPC server (and some Google Speech to Text client) and your Qt program would be its only client (and would start it). So your Go program would be some specialized proxy. You could even use pipe(7)-s, unix(7) sockets, or fifo(7)-s to increase the "privacy" of the communication channel.
If the Google Speech to Text API is huge (but it probably is not) you might use Go reflective or introspective abilities to generate some C++ glue code for Qt: go/ast, go/build, go/parser, go/importer, etc
BTW, it seems that Google Speech to Text protocol is using JSON with HTTP (it seems to be some Web API) and has a documented REST API, so you might directly code in C++ the relevant code doing that (of course you need to understand all the details of the protocol: relevant HTTP requests and JSON formats), without any Go code (or process). If you go that route, I recommend making your Qt (or C++) code for Google Speech to Text some separate free software library (to be able to get feedback and help from outside).

Faking SerialPort Communication

I am looking to mock a Serial Port so I can test communication and OS flushing.
Things I am hoping for out of the mock serial port. (in order of importance to the project)
Pass istty
Able to be used with an automated test suite (no gui)
Language Agnostic
Able to run on TravisCI
Cross Platform
I don't know if all those options are possible. But doing so would be nice. I know Unix treats everything as a file, so if I could just create a file that passes istty, that would be a good solution, but probably not windows compatible.
Anyway any ideas for testing SerialPort communication would be amazing.
Thanks Everyone.
I believe if you use CMock you can pass a .h file and get a mock generated.
Failing that, I'd write one by hand. Nothing fancy, just the stubs and some basic known return values. Once the mock (and your tests/unit under test) is sufficiently developed, that's when I'd switch to an integration test with the real socket API

RDP protocol for c++

Im looking for code that connects to another computer via remote desktop connection and checks if the connection was successful or not.
I packet logged and found out there was a galaxy worth of packets so i was wondering if there was some easy code out there.
There really isn't anything easy about RDP, that protocol stack is huge and builds on the ITU OSI protocols, which includes a fair amount of ASN.1/BER.
Your best bet is the code that's in FreeRDP.
A bit of terminology: you want a "RDP client library for C++".
As others have mentioned, look into the "FreeRDP" and "rdesktop" projects.
With FreeRDP, you're going to get a suite of libraries (each one doing it's thing). With rdesktop, you're going to get a client app (which you have to break the C code out of, and "build" your C++ api around).
If this is a new project, I'd pick FreeRDP over rdesktop, as they have libraries available with your C++ interface already in place.
Do you need to check if an RDP server is present, but not authenticate? In this case all you'd need are the first couple of packets used to negotiate protocol security. You can find the code in FreeRDP in libfreerdp-core/nego.c.
#Blanker1231 : You should have look on rdesktop code , its in c but can be very easily modified to be used in a C++ code , all you have to do is bridge their Struct Stream effectively .
moreover I have worked on a Rdp 7+ implementation ages ago in qt/c++ for a , so recently just for fun of it i used all of my experience and wrote a RDP parser and code generator and open sourced it on https://github.com/shashanksingh/Code-Generator-for-RDP
Right now it dead simple and i am still working on it more intelligent . Word of caution it doesn't generate everything . Examples includes demo.def which on compilation will generate all the class os ms-fscc used in ms-rdp
#Blanker1231 if you ever feel like , just fork the implementation and start pushing stuff in

Continuous Integration/ Unit testing in embedded C++ systems

What tools are generally used for unit testing and especially continuous integration for embedded systems?
I am especially thinking that you usually have to cross-compile and deploy, and also that you can't easily visualize the target platform. Also it can be difficult to run test-code and frameworks.
What could I use too alleviate these difficulties?
(I think it should be some kind of dual targeting, where the build server runs its tests on a easier target)
For unit testing, take a look at Unity.
http://sourceforge.net/apps/trac/unity/wiki
It is a really lightweight test harness (2 x .h and 1 x .c file) supported by Ruby scripts. We have been using in an embedded ARM7 target system for unit testing (redirecting test reporting over a serial port).
It is also supported by CMock for (surprise, surprise) Mocking. Even though not extensive, the great thing about these is they are so easy to use.
Regarding CI, then Hudson (now Jenkins) is very good if you're Linux based.
Also look at CppUTest and check out James Grenning's book "TDD for Embedded C" at http://renaissancesoftware.net/
At work I use the embUnit framework:
http://embunit.sourceforge.net/embunit/index.html
The nice thing about this framework is, that it's lean. It does not require any external libraries (not even libc). You can hook your own output function with ease so if you work on a system where the only connection to the outside world is jtag or an UART, then embUnit will still work.
I have used RCUNIT and CANTATA++ for unit testing embedded code on the PC. Any Nunit should easily integrate into any continuous test platform. We found it an lot easier to just simulate the hardware on the PC and only test on the target during final integration.
Hardware interface abstraction is crucial for unit testing embedded code on the PC. This works well with continuous integration since it is run on a pc with just the hardware access simulated. With a little effort we could test 95% of the code on a PC for continues integration.
You could also look at these questions:
Unit Testing C Code
Testing Frameworks for C
Unit Testing Embedded Software
I've seen C(pp)unit used on a system that let you launch to the target via JTAG.
Helps to have console comms etc sorted.
But it can work.
I'm working on an open-source tool for that, that is either a minimal test or can provide detailed information when run through the debugger.

port native C++ non static binary on Android

Im quite new on Android and I have some question for all of you who are experts!
Ok, my problem...
I implemented a client-server application based on socket programming. The server encode some packets, send them to the client through a socket and the clinet decode them.
I tested the code with two linux machines and it works fine but in my experiment it is required to include another node (this will be the Android). So the server (linux machine) will encode the packets and send through socket to client1(linux machine) and client2(Android).
For this reason I want to port the native binary of my code (which is in C++) to Android.
In which way could I do this?
Please give me some help!
Really im totally stucked!
Thanks,
Zenia
when you want to port native code C/C++ to android you want to look up android ndk and jni
http://developer.android.com/sdk/ndk/index.html
http://download.oracle.com/javase/1.5.0/docs/guide/jni/spec/functions.html
There are some examples in the ndk on how to do this.
be warned that C is fully supported but C++ support apis is very limited on android (the list is in the docs of the ndk) so you might have problems porting your code.
I would recommend using directly java if you can, since working with JNI is tedious lol
how else can you port this? start learning android i did a quick check noticed it's sdk uses java you can start by looking at
http://developer.android.com/reference/java/net/Socket.html
Thanks for the reply,
I first tried to write my own code totally in java using sockets, however i had to port some optimized libraries to Android and I could figure out how to do that (i could port a simple small library but not the one that I wanted). I gave up and I right now im trying to play with jni and ndk. however i dont know if indeed i could port my binary as it is non static (like hello world). Thats why im asking. if anyone else have some experince on that please let me know. thanks a lot,
Zenia
What you should probably do is install the SDK and NDK and build the hello-jni ndk example.
Then look up how to access the android logcat output from C, and write yourself a nice little printf-like wrapper for that (probably using the vargs version of the underlying function) so you can easily generate debug output from your native code.
Then graft your native executable onto the hello-jni example code, so you'll have a java wrapper that does very little other than start things with a call to the native code. Just remember not to do much processing in the UI thread or native code called under that thread, or you will risk an application not responding timeout.
It is also possible to (ab)use the ndk's gcc to produce stand alone native executables with no java wrapper, but this is discouraged. It's hard to find a reliable place to install them on a non-rooted phone, and android's process management isn't happy about unknown native processes. In other words, that's a path that's fine for personal experiments on your own device, but a difficult and non-future-proof one for an application deployed to others.