2014-04-16 12:27:23 -04:00
|
|
|
include ../py/mkenv.mk
|
|
|
|
|
-include mpconfigport.mk
|
|
|
|
|
|
|
|
|
|
# qstr definitions (must come before including py.mk)
|
|
|
|
|
QSTR_DEFS = qstrdefsport.h
|
|
|
|
|
|
|
|
|
|
# include py core make definitions
|
|
|
|
|
include ../py/py.mk
|
|
|
|
|
|
|
|
|
|
CROSS_COMPILE = arm-none-eabi-
|
|
|
|
|
|
2014-04-21 16:08:15 -04:00
|
|
|
INC = -I.
|
|
|
|
|
INC += -I$(PY_SRC)
|
|
|
|
|
INC += -I$(BUILD)
|
|
|
|
|
|
2014-04-16 12:27:23 -04:00
|
|
|
CFLAGS_CORTEX_M3 = -mthumb -mcpu=cortex-m3
|
2014-04-21 16:08:15 -04:00
|
|
|
CFLAGS = $(INC) -Wall -Werror -ansi -std=gnu99 $(CFLAGS_CORTEX_M3) $(COPT) \
|
2014-04-21 16:00:23 -04:00
|
|
|
-flto -ffunction-sections -fdata-sections
|
2014-04-16 12:27:23 -04:00
|
|
|
|
|
|
|
|
#Debugging/Optimization
|
|
|
|
|
ifeq ($(DEBUG), 1)
|
|
|
|
|
CFLAGS += -g -DPENDSV_DEBUG
|
|
|
|
|
COPT = -O0
|
|
|
|
|
else
|
|
|
|
|
COPT += -Os -DNDEBUG
|
|
|
|
|
endif
|
|
|
|
|
|
2014-04-21 16:00:23 -04:00
|
|
|
## With CoudeSourcery it's actually a little different, you just need `-T generic-m-hosted.ld`.
|
|
|
|
|
## Although for some reason `$(LD)` will not find that linker script, it works with `$(CC)`.
|
|
|
|
|
## It turns out that this is specific to CoudeSourcery, and ARM version of GCC ships something
|
|
|
|
|
## else instead and according to the following files, this is what we need to pass to `$(CC).
|
|
|
|
|
## - gcc-arm-none-eabi-4_8-2014q1/share/gcc-arm-none-eabi/samples/src/makefile.conf
|
|
|
|
|
## - gcc-arm-none-eabi-4_8-2014q1/share/gcc-arm-none-eabi/samples/src/qemu/Makefile
|
|
|
|
|
LDFLAGS= --specs=nano.specs --specs=rdimon.specs -Wl,--gc-sections -Wl,-Map=$(@:.elf=.map)
|
2014-04-16 12:27:23 -04:00
|
|
|
|
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
|
|
|
ifeq ($(RUN_TESTS), 1)
|
|
|
|
|
SRC_C = \
|
|
|
|
|
test_main.c \
|
|
|
|
|
|
|
|
|
|
else
|
2014-04-16 12:27:23 -04:00
|
|
|
SRC_C = \
|
2014-04-21 16:00:23 -04:00
|
|
|
main.c \
|
2014-04-16 12:27:23 -04:00
|
|
|
|
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
|
|
|
endif
|
|
|
|
|
|
2014-04-16 12:27:23 -04:00
|
|
|
SRC_S = \
|
|
|
|
|
|
|
|
|
|
OBJ =
|
|
|
|
|
OBJ += $(PY_O)
|
|
|
|
|
OBJ += $(addprefix $(BUILD)/, $(SRC_C:.c=.o))
|
|
|
|
|
OBJ += $(addprefix $(BUILD)/, $(SRC_S:.s=.o))
|
|
|
|
|
|
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
|
|
|
ifeq ($(RUN_TESTS), 1)
|
|
|
|
|
INC += -I../tools/tinytest/
|
|
|
|
|
OBJ += $(BUILD)/tinytest.o
|
|
|
|
|
endif
|
|
|
|
|
|
2014-04-21 16:00:23 -04:00
|
|
|
all: run
|
|
|
|
|
|
|
|
|
|
run: $(BUILD)/flash.elf
|
2014-04-16 12:27:23 -04:00
|
|
|
qemu-system-arm -cpu cortex-m3 -nographic -monitor null -serial null -semihosting -kernel $(BUILD)/flash.elf
|
|
|
|
|
|
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
|
|
|
.PHONY: $(BUILD)/genhdr/tests.h
|
|
|
|
|
|
|
|
|
|
$(BUILD)/test_main.o: $(BUILD)/genhdr/tests.h
|
|
|
|
|
$(BUILD)/genhdr/tests.h:
|
|
|
|
|
$(Q)echo "Generating $@";(cd ../tests; ../tools/tinytest-codegen.py) > $@
|
|
|
|
|
|
|
|
|
|
$(BUILD)/tinytest.o:
|
|
|
|
|
$(Q)$(CC) $(CFLAGS) -DNO_FORKING -o $@ -c ../tools/tinytest/tinytest.c
|
|
|
|
|
|
2014-04-21 16:00:23 -04:00
|
|
|
## `$(LD)` doesn't seem to like `--specs` for some reason, but we can just use `$(CC)` here.
|
2014-04-16 12:27:23 -04:00
|
|
|
$(BUILD)/flash.elf: $(OBJ)
|
2014-04-21 16:00:23 -04:00
|
|
|
$(Q)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJ) $(LIBS)
|
2014-04-16 12:27:23 -04:00
|
|
|
$(Q)$(SIZE) $@
|
|
|
|
|
|
|
|
|
|
include ../py/mkrules.mk
|