67 lines
2.1 KiB
C
Raw Permalink Normal View History

/*
* This file is part of the MicroPython project, http://micropython.org/
*
* The MIT License (MIT)
*
qemu-arm: Rework to provide a REPL and run tests via a pty serial port. Currently, the qemu-arm (and qemu-riscv) port has two build modes: - a simple test that executes a Python string; and - a full test that uses tinytest to embed all tests within the firmware, then executes that and captures the output. This is very different to all the other ports. A difficulty with using tinytest is that with the large number of tests the firmware overflows its virtual flash size. It's also hard to run tests via .mpy files and with the native emitter. Being different to the other ports also means an extra burden on maintenance. This commit reworks the qemu-arm port so that it has a single build target that creates a standard firmware which has a REPL. When run under qemu-system-arm, the REPL acts like any other bare-metal port, complete with soft reset (use machine.reset() to turn it off and exit qemu-system-arm). This approach gives many benefits: - allows playing with a REPL without hardware; - allows running the test suite as it would on a bare-metal board, by making qemu-system-arm redirect the UART serial of the virtual device to a /dev/pts/xx file, and then running run-tests.py against that serial device; - skipping tests is now done via the logic in `run-tests.py` and no longer needs multiple places to define which tests to skip (`tools/tinytest-codegen.py`, `ports/qemu-arm/tests_profile.txt` and also `tests/run-tests.py`); - allows testing/using mpremote with the qemu-arm port. Eventually the qemu-riscv port would have a similar change. Prior to this commit the test results were: 743 tests ok. (121 skipped) With this commit the test results are: 753 tests performed (22673 individual testcases) 753 tests passed 138 tests skipped More tests are skipped because more are included in the run. But overall more tests pass. Signed-off-by: Damien George <damien@micropython.org>
2024-08-12 11:32:28 +10:00
* Copyright (c) 2024 Damien P. George
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
qemu-arm: Rework to provide a REPL and run tests via a pty serial port. Currently, the qemu-arm (and qemu-riscv) port has two build modes: - a simple test that executes a Python string; and - a full test that uses tinytest to embed all tests within the firmware, then executes that and captures the output. This is very different to all the other ports. A difficulty with using tinytest is that with the large number of tests the firmware overflows its virtual flash size. It's also hard to run tests via .mpy files and with the native emitter. Being different to the other ports also means an extra burden on maintenance. This commit reworks the qemu-arm port so that it has a single build target that creates a standard firmware which has a REPL. When run under qemu-system-arm, the REPL acts like any other bare-metal port, complete with soft reset (use machine.reset() to turn it off and exit qemu-system-arm). This approach gives many benefits: - allows playing with a REPL without hardware; - allows running the test suite as it would on a bare-metal board, by making qemu-system-arm redirect the UART serial of the virtual device to a /dev/pts/xx file, and then running run-tests.py against that serial device; - skipping tests is now done via the logic in `run-tests.py` and no longer needs multiple places to define which tests to skip (`tools/tinytest-codegen.py`, `ports/qemu-arm/tests_profile.txt` and also `tests/run-tests.py`); - allows testing/using mpremote with the qemu-arm port. Eventually the qemu-riscv port would have a similar change. Prior to this commit the test results were: 743 tests ok. (121 skipped) With this commit the test results are: 753 tests performed (22673 individual testcases) 753 tests passed 138 tests skipped More tests are skipped because more are included in the run. But overall more tests pass. Signed-off-by: Damien George <damien@micropython.org>
2024-08-12 11:32:28 +10:00
#include "py/mphal.h"
#include "shared/runtime/semihosting_arm.h"
#include "uart.h"
qemu-arm: fully integrated test suite. This is primarily intended to provide testing of Thumb-specific code within Travis CI as well as if anyone else want to run it locally. As discussed in purposes. This is currently agains an emulated Cortex-M3 core, however in the near future it can extended to support M0, M0+ as well M4 (work in progress exists in sushihangover/qemu). It's probably true that most of the code base can be covered running uPy natively on a POSIX system, however we do have the tiny bit of assembly code. There may exist bugs related to endianness and type aliases, let alone potential standard library or compiler bugs or even architecture-specific optimisations. This could also incorporate lwIP (or other TCP/IP stack) integration as well as SDIO+FATFS drivers. The solution to inline the test cases was chose due to simplicity. It could alternatively be implemented in a number of different way (see #515), but this looked the simplest. Inclusion of tinytest was just to avoid writing boilerplate code for counting failed tests and other utility functions. Currently only a few functions are used, however this could be extended. Checking in the code instead of using submodule was a personal preference, but if people do want the pain of submodules, this can provided. This particular framework is also pretty good if one desires to run unit test on target. The approach with scripts being inlined is probably not quite suited for the size of memory an MCU has, but the tinytest itself should be good, if lower-level C code is to be unit tested.
2014-05-05 17:06:45 +01:00
qemu-arm: Rework to provide a REPL and run tests via a pty serial port. Currently, the qemu-arm (and qemu-riscv) port has two build modes: - a simple test that executes a Python string; and - a full test that uses tinytest to embed all tests within the firmware, then executes that and captures the output. This is very different to all the other ports. A difficulty with using tinytest is that with the large number of tests the firmware overflows its virtual flash size. It's also hard to run tests via .mpy files and with the native emitter. Being different to the other ports also means an extra burden on maintenance. This commit reworks the qemu-arm port so that it has a single build target that creates a standard firmware which has a REPL. When run under qemu-system-arm, the REPL acts like any other bare-metal port, complete with soft reset (use machine.reset() to turn it off and exit qemu-system-arm). This approach gives many benefits: - allows playing with a REPL without hardware; - allows running the test suite as it would on a bare-metal board, by making qemu-system-arm redirect the UART serial of the virtual device to a /dev/pts/xx file, and then running run-tests.py against that serial device; - skipping tests is now done via the logic in `run-tests.py` and no longer needs multiple places to define which tests to skip (`tools/tinytest-codegen.py`, `ports/qemu-arm/tests_profile.txt` and also `tests/run-tests.py`); - allows testing/using mpremote with the qemu-arm port. Eventually the qemu-riscv port would have a similar change. Prior to this commit the test results were: 743 tests ok. (121 skipped) With this commit the test results are: 753 tests performed (22673 individual testcases) 753 tests passed 138 tests skipped More tests are skipped because more are included in the run. But overall more tests pass. Signed-off-by: Damien George <damien@micropython.org>
2024-08-12 11:32:28 +10:00
// UART is better behaved with redirection under qemu-system-arm, so prefer that for stdio.
#define USE_UART (1)
#define USE_SEMIHOSTING (0)
qemu-arm: fully integrated test suite. This is primarily intended to provide testing of Thumb-specific code within Travis CI as well as if anyone else want to run it locally. As discussed in purposes. This is currently agains an emulated Cortex-M3 core, however in the near future it can extended to support M0, M0+ as well M4 (work in progress exists in sushihangover/qemu). It's probably true that most of the code base can be covered running uPy natively on a POSIX system, however we do have the tiny bit of assembly code. There may exist bugs related to endianness and type aliases, let alone potential standard library or compiler bugs or even architecture-specific optimisations. This could also incorporate lwIP (or other TCP/IP stack) integration as well as SDIO+FATFS drivers. The solution to inline the test cases was chose due to simplicity. It could alternatively be implemented in a number of different way (see #515), but this looked the simplest. Inclusion of tinytest was just to avoid writing boilerplate code for counting failed tests and other utility functions. Currently only a few functions are used, however this could be extended. Checking in the code instead of using submodule was a personal preference, but if people do want the pain of submodules, this can provided. This particular framework is also pretty good if one desires to run unit test on target. The approach with scripts being inlined is probably not quite suited for the size of memory an MCU has, but the tinytest itself should be good, if lower-level C code is to be unit tested.
2014-05-05 17:06:45 +01:00
qemu-arm: Rework to provide a REPL and run tests via a pty serial port. Currently, the qemu-arm (and qemu-riscv) port has two build modes: - a simple test that executes a Python string; and - a full test that uses tinytest to embed all tests within the firmware, then executes that and captures the output. This is very different to all the other ports. A difficulty with using tinytest is that with the large number of tests the firmware overflows its virtual flash size. It's also hard to run tests via .mpy files and with the native emitter. Being different to the other ports also means an extra burden on maintenance. This commit reworks the qemu-arm port so that it has a single build target that creates a standard firmware which has a REPL. When run under qemu-system-arm, the REPL acts like any other bare-metal port, complete with soft reset (use machine.reset() to turn it off and exit qemu-system-arm). This approach gives many benefits: - allows playing with a REPL without hardware; - allows running the test suite as it would on a bare-metal board, by making qemu-system-arm redirect the UART serial of the virtual device to a /dev/pts/xx file, and then running run-tests.py against that serial device; - skipping tests is now done via the logic in `run-tests.py` and no longer needs multiple places to define which tests to skip (`tools/tinytest-codegen.py`, `ports/qemu-arm/tests_profile.txt` and also `tests/run-tests.py`); - allows testing/using mpremote with the qemu-arm port. Eventually the qemu-riscv port would have a similar change. Prior to this commit the test results were: 743 tests ok. (121 skipped) With this commit the test results are: 753 tests performed (22673 individual testcases) 753 tests passed 138 tests skipped More tests are skipped because more are included in the run. But overall more tests pass. Signed-off-by: Damien George <damien@micropython.org>
2024-08-12 11:32:28 +10:00
uintptr_t mp_hal_stdio_poll(uintptr_t poll_flags) {
// Not implemented.
return 0;
qemu-arm: fully integrated test suite. This is primarily intended to provide testing of Thumb-specific code within Travis CI as well as if anyone else want to run it locally. As discussed in purposes. This is currently agains an emulated Cortex-M3 core, however in the near future it can extended to support M0, M0+ as well M4 (work in progress exists in sushihangover/qemu). It's probably true that most of the code base can be covered running uPy natively on a POSIX system, however we do have the tiny bit of assembly code. There may exist bugs related to endianness and type aliases, let alone potential standard library or compiler bugs or even architecture-specific optimisations. This could also incorporate lwIP (or other TCP/IP stack) integration as well as SDIO+FATFS drivers. The solution to inline the test cases was chose due to simplicity. It could alternatively be implemented in a number of different way (see #515), but this looked the simplest. Inclusion of tinytest was just to avoid writing boilerplate code for counting failed tests and other utility functions. Currently only a few functions are used, however this could be extended. Checking in the code instead of using submodule was a personal preference, but if people do want the pain of submodules, this can provided. This particular framework is also pretty good if one desires to run unit test on target. The approach with scripts being inlined is probably not quite suited for the size of memory an MCU has, but the tinytest itself should be good, if lower-level C code is to be unit tested.
2014-05-05 17:06:45 +01:00
}
qemu-arm: Rework to provide a REPL and run tests via a pty serial port. Currently, the qemu-arm (and qemu-riscv) port has two build modes: - a simple test that executes a Python string; and - a full test that uses tinytest to embed all tests within the firmware, then executes that and captures the output. This is very different to all the other ports. A difficulty with using tinytest is that with the large number of tests the firmware overflows its virtual flash size. It's also hard to run tests via .mpy files and with the native emitter. Being different to the other ports also means an extra burden on maintenance. This commit reworks the qemu-arm port so that it has a single build target that creates a standard firmware which has a REPL. When run under qemu-system-arm, the REPL acts like any other bare-metal port, complete with soft reset (use machine.reset() to turn it off and exit qemu-system-arm). This approach gives many benefits: - allows playing with a REPL without hardware; - allows running the test suite as it would on a bare-metal board, by making qemu-system-arm redirect the UART serial of the virtual device to a /dev/pts/xx file, and then running run-tests.py against that serial device; - skipping tests is now done via the logic in `run-tests.py` and no longer needs multiple places to define which tests to skip (`tools/tinytest-codegen.py`, `ports/qemu-arm/tests_profile.txt` and also `tests/run-tests.py`); - allows testing/using mpremote with the qemu-arm port. Eventually the qemu-riscv port would have a similar change. Prior to this commit the test results were: 743 tests ok. (121 skipped) With this commit the test results are: 753 tests performed (22673 individual testcases) 753 tests passed 138 tests skipped More tests are skipped because more are included in the run. But overall more tests pass. Signed-off-by: Damien George <damien@micropython.org>
2024-08-12 11:32:28 +10:00
int mp_hal_stdin_rx_chr(void) {
for (;;) {
#if USE_UART
int c = uart_rx_chr();
if (c >= 0) {
return c;
}
#endif
#if USE_SEMIHOSTING
char str[1];
int ret = mp_semihosting_rx_chars(str, 1);
if (ret == 0) {
return str[0];
}
#endif
}
qemu-arm: fully integrated test suite. This is primarily intended to provide testing of Thumb-specific code within Travis CI as well as if anyone else want to run it locally. As discussed in purposes. This is currently agains an emulated Cortex-M3 core, however in the near future it can extended to support M0, M0+ as well M4 (work in progress exists in sushihangover/qemu). It's probably true that most of the code base can be covered running uPy natively on a POSIX system, however we do have the tiny bit of assembly code. There may exist bugs related to endianness and type aliases, let alone potential standard library or compiler bugs or even architecture-specific optimisations. This could also incorporate lwIP (or other TCP/IP stack) integration as well as SDIO+FATFS drivers. The solution to inline the test cases was chose due to simplicity. It could alternatively be implemented in a number of different way (see #515), but this looked the simplest. Inclusion of tinytest was just to avoid writing boilerplate code for counting failed tests and other utility functions. Currently only a few functions are used, however this could be extended. Checking in the code instead of using submodule was a personal preference, but if people do want the pain of submodules, this can provided. This particular framework is also pretty good if one desires to run unit test on target. The approach with scripts being inlined is probably not quite suited for the size of memory an MCU has, but the tinytest itself should be good, if lower-level C code is to be unit tested.
2014-05-05 17:06:45 +01:00
}
qemu-arm: Rework to provide a REPL and run tests via a pty serial port. Currently, the qemu-arm (and qemu-riscv) port has two build modes: - a simple test that executes a Python string; and - a full test that uses tinytest to embed all tests within the firmware, then executes that and captures the output. This is very different to all the other ports. A difficulty with using tinytest is that with the large number of tests the firmware overflows its virtual flash size. It's also hard to run tests via .mpy files and with the native emitter. Being different to the other ports also means an extra burden on maintenance. This commit reworks the qemu-arm port so that it has a single build target that creates a standard firmware which has a REPL. When run under qemu-system-arm, the REPL acts like any other bare-metal port, complete with soft reset (use machine.reset() to turn it off and exit qemu-system-arm). This approach gives many benefits: - allows playing with a REPL without hardware; - allows running the test suite as it would on a bare-metal board, by making qemu-system-arm redirect the UART serial of the virtual device to a /dev/pts/xx file, and then running run-tests.py against that serial device; - skipping tests is now done via the logic in `run-tests.py` and no longer needs multiple places to define which tests to skip (`tools/tinytest-codegen.py`, `ports/qemu-arm/tests_profile.txt` and also `tests/run-tests.py`); - allows testing/using mpremote with the qemu-arm port. Eventually the qemu-riscv port would have a similar change. Prior to this commit the test results were: 743 tests ok. (121 skipped) With this commit the test results are: 753 tests performed (22673 individual testcases) 753 tests passed 138 tests skipped More tests are skipped because more are included in the run. But overall more tests pass. Signed-off-by: Damien George <damien@micropython.org>
2024-08-12 11:32:28 +10:00
mp_uint_t mp_hal_stdout_tx_strn(const char *str, size_t len) {
#if USE_UART
uart_tx_strn(str, len);
#endif
#if USE_SEMIHOSTING
mp_semihosting_tx_strn(str, len);
#endif
return len;
qemu-arm: fully integrated test suite. This is primarily intended to provide testing of Thumb-specific code within Travis CI as well as if anyone else want to run it locally. As discussed in purposes. This is currently agains an emulated Cortex-M3 core, however in the near future it can extended to support M0, M0+ as well M4 (work in progress exists in sushihangover/qemu). It's probably true that most of the code base can be covered running uPy natively on a POSIX system, however we do have the tiny bit of assembly code. There may exist bugs related to endianness and type aliases, let alone potential standard library or compiler bugs or even architecture-specific optimisations. This could also incorporate lwIP (or other TCP/IP stack) integration as well as SDIO+FATFS drivers. The solution to inline the test cases was chose due to simplicity. It could alternatively be implemented in a number of different way (see #515), but this looked the simplest. Inclusion of tinytest was just to avoid writing boilerplate code for counting failed tests and other utility functions. Currently only a few functions are used, however this could be extended. Checking in the code instead of using submodule was a personal preference, but if people do want the pain of submodules, this can provided. This particular framework is also pretty good if one desires to run unit test on target. The approach with scripts being inlined is probably not quite suited for the size of memory an MCU has, but the tinytest itself should be good, if lower-level C code is to be unit tested.
2014-05-05 17:06:45 +01:00
}