Enable SM1000 ctests inside GitHub using QEMU.

[tmiw]

This PR enables ctests for the SM1000 using QEMU by adding -DUSE_QEMU_FOR_UNITTEST=1 to the SM1000's cmake command. By doing so, this allows the ctests to run as GitHub actions (also enabled).

[tmiw]

The following STM32 tests currently fail in QEMU:

	  5 - tst_ofdm_mod_plain (Failed)
	  6 - tst_ofdm_mod_ldpc (Failed)
	  9 - tst_ofdm_demod_AWGN (Failed)
	 10 - tst_ofdm_demod_fade (Failed)
	 22 - tst_api_demod_700D_plain_test (Failed)
	 25 - tst_api_demod_700E_plain_test (Failed)

Will investigate further when I get time.

[drowe67]

Hi @tmiw, this is interesting - it would be very useful if we can run stm32 unit tests without the dev board hardware. Couple of thoughts:

1. Do these changes changes break the current hardware dev board support? We should probably check that.
2. Can the QEMU version tests be run outside of github actions, for example on one of our machines while developing? Perhaps you are doing that already. Would require some edits to the SM1000 README.md documentation to discuss setup (apt packages) and running under QEMU.

[tmiw]

1. Do these changes changes break the current hardware dev board support? We should probably check that.

Amazon's supposed to deliver a STM32F4 dev board tomorrow so I can find out for sure. Ideally the results would be the same in both.

(For context, someone reached out to me on LinkedIn recently trying to get support for Codec2 on STM32 and I noticed some test failures when he tried running the tests on his board. Figured it'd be a good idea to get the tests running consistently because as-is, they're not run often.)

2. Can the QEMU version tests be run outside of github actions, for example on one of our machines while developing? Perhaps you are doing that already. Would require some edits to the SM1000 README.md documentation to discuss setup (apt packages) and running under QEMU.

Yep, I'm able to do that on a Linux VM (but not natively on macOS due to hardcoded build_linux paths).

BTW I looked at the last message I got from the person I talked about and it looks like the first four of the failures I posted above are what he's experiencing, too, so it's likly these failures aren't a result of QEMU.

[tmiw]

I'm getting a smaller set of failures in this PR branch, both on actual hardware and QEMU:

The following tests FAILED:
	  5 - tst_ofdm_mod_plain (Failed)
	  6 - tst_ofdm_mod_ldpc (Failed)
	  9 - tst_ofdm_demod_AWGN (Failed)
	 10 - tst_ofdm_demod_fade (Failed)

(More detailed logging at qemu-ctest-failures.txt.)

I suspect these four are legitimate failures. The others mentioned in #13 may have gotten fixed inadvertently by the minimal changes needed for the tests themselves.

[drowe67]

Thanks. As agreed offline - closing with no further action to be performed now reported bugs have been reproduced. QEMU stuff should be useful should we port new waveforms under development to stm32.