circuitpython/ports/qemu-arm/test_main.c

55 lines
1.2 KiB
C
Raw Normal View History

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 12:06:45 -04:00
#include <stdint.h>
#include <stdlib.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 12:06:45 -04:00
#include <stdio.h>
#include <string.h>
#include <malloc.h>
#include <setjmp.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 12:06:45 -04:00
#include "py/obj.h"
#include "py/compile.h"
#include "py/runtime.h"
#include "py/stackctrl.h"
#include "py/gc.h"
#include "py/mperrno.h"
#include "shared/runtime/gchelper.h"
#include "lib/tinytest/tinytest.h"
#include "lib/tinytest/tinytest_macros.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 12:06:45 -04:00
#define HEAP_SIZE (100 * 1024)
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 12:06:45 -04:00
#include "genhdr/tests.h"
int main() {
mp_stack_ctrl_init();
mp_stack_set_limit(10240);
static uint32_t heap[HEAP_SIZE / sizeof(uint32_t)];
upytest_set_heap(heap, (char *)heap + HEAP_SIZE);
int r = tinytest_main(0, NULL, groups);
printf("status: %d\n", r);
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 12:06:45 -04:00
return r;
}
void gc_collect(void) {
gc_collect_start();
gc_helper_collect_regs_and_stack();
gc_collect_end();
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 12:06:45 -04:00
}
mp_lexer_t *mp_lexer_new_from_file(const char *filename) {
mp_raise_OSError(MP_ENOENT);
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 12:06:45 -04:00
}
mp_import_stat_t mp_import_stat(const char *path) {
return MP_IMPORT_STAT_NO_EXIST;
}
mp_obj_t mp_builtin_open(size_t n_args, const mp_obj_t *args, mp_map_t *kwargs) {
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 12:06:45 -04:00
return mp_const_none;
}
MP_DEFINE_CONST_FUN_OBJ_KW(mp_builtin_open_obj, 1, mp_builtin_open);
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 12:06:45 -04:00
void nlr_jump_fail(void *val) {
printf("uncaught NLR\n");
exit(1);
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 12:06:45 -04:00
}