32F303 support
32F303 support
Hi, all the best in 2025!
Not being here for a longer time..
Perhaps you may indicate to me whether the vintage F303 is supported with a core?
Thanks, P.
Not being here for a longer time..
Perhaps you may indicate to me whether the vintage F303 is supported with a core?
Thanks, P.
Pukao Hats Cleaning Services Ltd.
Re: 32F303 support
welcome back
here you go
https://github.com/stm32duino/Arduino_C ... 303C(B-C)T
but that I'd think the g4xx series is an 'upgrade'
https://github.com/WeActStudio/WeActStu ... 1CoreBoard
faster speeds
https://www.st.com/en/microcontrollers- ... 431cb.html
https://www.st.com/en/microcontrollers- ... 474ce.html
and that they have adc, dac, opAmp, comparators etc
plus Math accelerator, ART accelerator, practically every useful F4xx features that you can dream of


here you go
https://github.com/stm32duino/Arduino_C ... 303C(B-C)T
but that I'd think the g4xx series is an 'upgrade'
https://github.com/WeActStudio/WeActStu ... 1CoreBoard
faster speeds
https://www.st.com/en/microcontrollers- ... 431cb.html
https://www.st.com/en/microcontrollers- ... 474ce.html
and that they have adc, dac, opAmp, comparators etc
plus Math accelerator, ART accelerator, practically every useful F4xx features that you can dream of

Re: 32F303 support
Hi, yup I know 411 is better, but I found a couple of 303 I collected in past in my junkbox and I want to reuse them.
Thanks!
PS: and afaik 303CB (128k flash) usually gets 256k - I hope the generic 303CB variant supports that larger flash (the bootloader)..
Thanks!
PS: and afaik 303CB (128k flash) usually gets 256k - I hope the generic 303CB variant supports that larger flash (the bootloader)..
Pukao Hats Cleaning Services Ltd.
Re: 32F303 support
I think it is fairly feasible to edit the ld script as well as in boards.txt to redefine those values.
but in IDE 2.x, you may need to clear the cache:
https://forum.arduino.cc/t/manual-edits ... /1045377/2
but in IDE 2.x, you may need to clear the cache:
https://forum.arduino.cc/t/manual-edits ... /1045377/2
Re: 32F303 support
off-topic:
in the meantime I'm messing with CMake
viewtopic.php?t=1648
https://github.com/stm32duino/Arduino_C ... E_CMAKE.md
https://github.com/stm32duino/Arduino_C ... esentation
https://github.com/stm32duino/CMake_workspace
there are some prerequisites to install, most important CMake, python (and some python modules), ninja
https://github.com/stm32duino/Arduino_C ... wiki/Setup
after prerequisites are installed, is to run the quick start script from the *parent* (above sketch) folder of the sketch to generate a CMakeList.txt file in the sketch folder
https://github.com/stm32duino/Arduino_C ... art-script
e.g. where ${ARDUINO_CORE_STM32_FOLDER} is where you git clone the Arduino_Core_STM32 repo
edit the generated CMakeList.txt file in the sketch folder to see that all your sketch sources are listed under the build_sketch() section.
then the build steps are, make a directory e.g. build (this is for CMake to generate it's work scripts / files and build, the bin file is found there after the build)
https://github.com/stm32duino/Arduino_C ... sing-cmake
then to actually compile it is
there is quite a bit of convenience to use cmake with eclipse, eclipse CDT has features that support cmake. And without any custom add-on in eclipse, i.e. CDT is adequate. And that cmake is (far) more fluid vs Arduino IDE which pre-defines files in certain locations (it is a good and bad thing).
I'm still learning cmake , but that i managed to fork set_board.cmake,
https://github.com/stm32duino/Arduino_C ... oard.cmake
and edit the CMakeList.txt in sketch folder call that myset_board.cmake in a different my own cmake scripts folder, and I managed to build my variant files outside the default source tree in my own source folder.
This may be useful e.g. to edit variant sources and/or make a new variant.
in the meantime I'm messing with CMake
viewtopic.php?t=1648
https://github.com/stm32duino/Arduino_C ... E_CMAKE.md
https://github.com/stm32duino/Arduino_C ... esentation
https://github.com/stm32duino/CMake_workspace
there are some prerequisites to install, most important CMake, python (and some python modules), ninja
https://github.com/stm32duino/Arduino_C ... wiki/Setup
after prerequisites are installed, is to run the quick start script from the *parent* (above sketch) folder of the sketch to generate a CMakeList.txt file in the sketch folder
https://github.com/stm32duino/Arduino_C ... art-script
e.g. where ${ARDUINO_CORE_STM32_FOLDER} is where you git clone the Arduino_Core_STM32 repo
Code: Select all
python3 $(ARDUINO_CORE_STM32_FOLDER}/cmake/scripts/cmake_easy_setup.py --board BLACKPILL_F303CC --sketch sketch_folder
then the build steps are, make a directory e.g. build (this is for CMake to generate it's work scripts / files and build, the bin file is found there after the build)
https://github.com/stm32duino/Arduino_C ... sing-cmake
Code: Select all
cmake -S [source folder] -B [build folder] -G Ninja
Code: Select all
cmake --build [build folder]
I'm still learning cmake , but that i managed to fork set_board.cmake,
https://github.com/stm32duino/Arduino_C ... oard.cmake
and edit the CMakeList.txt in sketch folder call that myset_board.cmake in a different my own cmake scripts folder, and I managed to build my variant files outside the default source tree in my own source folder.
This may be useful e.g. to edit variant sources and/or make a new variant.
Re: 32F303 support
Thanks!
After spending years with exclusively LibMaple library (and I've been using BluePills F103 with it inside almost everyday) I've added the STM32 support to the Arduino env (from the github you pointed me kindly to).
I've tried the empty stuff and it is 8.3kB flash (F303CB), the readanalogvoltage example is 18kB flash, both with NewLib Nano(default) and Optimize Smallest -0 default. The pritf/scanf adds 30kB up..
Is that volume of flash ok? Just asking, perhaps I have missed something to set up (it looks pretty large flash consumption..)
My current understanding is I will burn in the sw via DFU, not sure it supports the trick with the 2xbigger flash memory, however.
Otherwise the SWD may work, but here also not sure about the 2xbigger memory.
With F103 I still use the bootloader (from RogerC era) I flashed into it some 6-8y ago, so no problem with 2x bigger flash
After spending years with exclusively LibMaple library (and I've been using BluePills F103 with it inside almost everyday) I've added the STM32 support to the Arduino env (from the github you pointed me kindly to).
I've tried the empty stuff and it is 8.3kB flash (F303CB), the readanalogvoltage example is 18kB flash, both with NewLib Nano(default) and Optimize Smallest -0 default. The pritf/scanf adds 30kB up..
Is that volume of flash ok? Just asking, perhaps I have missed something to set up (it looks pretty large flash consumption..)
My current understanding is I will burn in the sw via DFU, not sure it supports the trick with the 2xbigger flash memory, however.
Otherwise the SWD may work, but here also not sure about the 2xbigger memory.
With F103 I still use the bootloader (from RogerC era) I flashed into it some 6-8y ago, so no problem with 2x bigger flash

Pukao Hats Cleaning Services Ltd.
Re: 32F303 support
I think the core is somewhat 'fatter', an unfortunate fact to attempt to integrate practically the HAL practically all stm32 series lol
oh and don't forget to check out steve's core, that one has F303, lean and fast !
https://github.com/stevstrong/Arduino_STM32
in case for some reason the IDE 'doesn't support' there are some makefiles but that they may need some adaptation
viewtopic.php?t=37
what is interesting is the spread of stm32 boards on offer these days
https://weactstudio.aliexpress.com/stor ... match_sort
what used to be f405 'mini', Adafruit has a good competitor these days stm32f405 feather
https://www.adafruit.com/product/4382
micropython has a f405
https://store.micropython.org/product/PYBv1.1
and they added a h722
https://store.micropython.org/product/PYBD-SF2-W4F2
then I'd guess there are more if one searches in various online outlets. then if one wander a little further, going beyond 'development boards', 3d printer boards adds to the mix, it fits the needs of those who specifically wanted them, some fitted with 'high end' stm32s
https://www.aliexpress.com/store/475702 ... =518714589
then that targetting HAL starts to 'make sense', but I'd guess it'd at least add to all that if-defs whch i'd guess can't be helped.
a thing is many of those boards has more flash, sram than do that good'o f103 pill, and some run (a lot) faster
--
OT and stm32 is 'going places' these days 600 gops, it practically makes 'whetstone' benchmark irrelevant, and 'small' is 4.2MB sram, a thing is they didn't forget the arduino headers
viewtopic.php?t=2560
https://www.st.com/en/evaluation-tools/ ... l#overview
oh and don't forget to check out steve's core, that one has F303, lean and fast !

https://github.com/stevstrong/Arduino_STM32
in case for some reason the IDE 'doesn't support' there are some makefiles but that they may need some adaptation
viewtopic.php?t=37
what is interesting is the spread of stm32 boards on offer these days
https://weactstudio.aliexpress.com/stor ... match_sort
what used to be f405 'mini', Adafruit has a good competitor these days stm32f405 feather
https://www.adafruit.com/product/4382
micropython has a f405
https://store.micropython.org/product/PYBv1.1
and they added a h722
https://store.micropython.org/product/PYBD-SF2-W4F2
then I'd guess there are more if one searches in various online outlets. then if one wander a little further, going beyond 'development boards', 3d printer boards adds to the mix, it fits the needs of those who specifically wanted them, some fitted with 'high end' stm32s
https://www.aliexpress.com/store/475702 ... =518714589
then that targetting HAL starts to 'make sense', but I'd guess it'd at least add to all that if-defs whch i'd guess can't be helped.
a thing is many of those boards has more flash, sram than do that good'o f103 pill, and some run (a lot) faster

--
OT and stm32 is 'going places' these days 600 gops, it practically makes 'whetstone' benchmark irrelevant, and 'small' is 4.2MB sram, a thing is they didn't forget the arduino headers

viewtopic.php?t=2560
https://www.st.com/en/evaluation-tools/ ... l#overview
Last edited by ag123 on Fri Jan 17, 2025 8:07 pm, edited 1 time in total.
Re: 32F303 support
In terms of 'reducing the fat', there is some notes here I left about CMake, mainly so that when i forgot, i'd do a search
viewtopic.php?p=15222#p15222
cmake can generate a dependency graph of the *targets*, by adding this in CMakeList.txt
and runnning
but that 'targets' are synthetic, e.g. in the 'sensor' example in the above thread
in this way the 'sensor' is a target created by the add_library() statement.
so if the sketch has in CMakeList.txt a
the include directories to sensor.h would be provided when building the sketch.
my thoughts are that if 'sensor' is not referenced, it'd probably not be 'included' after all. even if it is defined as a 'target'.
but that if it is referenced then omitting the would result in a 'include not found' error or link errors due to missing objects.
i'm not too sure if the 'fat' is due to 'hidden dependencies' , e.g. a -> b -> c when you prefer a -> c. or due to 'fatter' implementation say of c itself.
and other things i'm not too sure could be contributed by the compiler etc.
I remember in my makefile, i tried doing 'nostdlibs', if one trims enough, one'd land with link errors to missing objects.
but that sometimes when it succeeds, then the bin file is much smaller.
and a notion about the 'targets' which may include 'libraries' could be that if there is a peripheral that you won't use, perhaps excluding that from initializing in the core and thus excluding that dependency could save some space.
--
oh and there are map file viewers,
https://www.sikorskiy.net/info/prj/amap/
https://github.com/govind-mukundan/MapViewer
useful for this purpose too

viewtopic.php?p=15222#p15222
cmake can generate a dependency graph of the *targets*, by adding this in CMakeList.txt
Code: Select all
set_property(GLOBAL PROPERTY GLOBAL_DEPENDS_DEBUG_MODE 1)
Code: Select all
cmake -S [source folder] -B [build folder] -G Ninja
Code: Select all
add_library(sensor)
target_include_directories(sensor PUBLIC "${CMAKE_CURRENT_SOURCE_DIR}")
target_sources(sensor
PUBLIC
sensor.cpp
sensor.h
)
target_link_libraries(sensor PUBLIC
base_config
core_usage
)
so if the sketch has in CMakeList.txt a
Code: Select all
target_link_libraries(sketch PUBLIC sensor)
my thoughts are that if 'sensor' is not referenced, it'd probably not be 'included' after all. even if it is defined as a 'target'.
but that if it is referenced then omitting the
Code: Select all
target_link_libraries(sketch PUBLIC sensor)
i'm not too sure if the 'fat' is due to 'hidden dependencies' , e.g. a -> b -> c when you prefer a -> c. or due to 'fatter' implementation say of c itself.
and other things i'm not too sure could be contributed by the compiler etc.
I remember in my makefile, i tried doing 'nostdlibs', if one trims enough, one'd land with link errors to missing objects.
but that sometimes when it succeeds, then the bin file is much smaller.
and a notion about the 'targets' which may include 'libraries' could be that if there is a peripheral that you won't use, perhaps excluding that from initializing in the core and thus excluding that dependency could save some space.
--
oh and there are map file viewers,
https://www.sikorskiy.net/info/prj/amap/
https://github.com/govind-mukundan/MapViewer
useful for this purpose too
Re: 32F303 support
I' started step by step - hardware first - I removed the F103 from a BluePill board and soldered the F303 in.
Then I spent a day with trying to flash something in. Finally I managed to get it working, first flashing via SWD something in, then the DFU started working as well.. Grrrh..
Next step is the bootloader - the DFU and SWD work, but I think it does not allow to flash 256kB into the F303CB (128kB).
I've seen a CDC bootloader (from stevestrong) thread here - perhaps it could be modded (or it works straight).
Thanks for the above info, I am going to study it. I've been using a Maple/Bluepill as hw interface for a measurement system, but that is in Sloeber, under Libmaple core (and the old bootloader). So perhaps 8y old setup. And perhaps a dozen of 100/103/407 boards gathering dust..
Then I spent a day with trying to flash something in. Finally I managed to get it working, first flashing via SWD something in, then the DFU started working as well.. Grrrh..

Next step is the bootloader - the DFU and SWD work, but I think it does not allow to flash 256kB into the F303CB (128kB).
I've seen a CDC bootloader (from stevestrong) thread here - perhaps it could be modded (or it works straight).
Thanks for the above info, I am going to study it. I've been using a Maple/Bluepill as hw interface for a measurement system, but that is in Sloeber, under Libmaple core (and the old bootloader). So perhaps 8y old setup. And perhaps a dozen of 100/103/407 boards gathering dust..
Pukao Hats Cleaning Services Ltd.
Re: 32F303 support
For one thing try Steve's F3 libmaple core, I remember some time back I implemented the RTC by adapting from F4xx implementation.
f303 is very similar to F4xx less that 'ART Accelerator' (sram cache)
that should be a pretty complete and lean implementation.
But that if you are using 'custom' F303 boards, for f103 bluepill, the onboard crystal is 8 mhz, vs those 'blackpill' which may be a different frequency.
you may need to look at how the crystal frequency is passed to the RCC codes to setup the clocks.
e.g. to pass the correct HSE frequency to RCC so that it'd at least operate at the correct frequency, that could in itself make USB work.
Oh and in case you need a makefile for F303 with steve's libmaple, here is it This makefile works in eclipse with CDT, I'm not sure about Sloeber
f303 is very similar to F4xx less that 'ART Accelerator' (sram cache)
that should be a pretty complete and lean implementation.
But that if you are using 'custom' F303 boards, for f103 bluepill, the onboard crystal is 8 mhz, vs those 'blackpill' which may be a different frequency.
you may need to look at how the crystal frequency is passed to the RCC codes to setup the clocks.
e.g. to pass the correct HSE frequency to RCC so that it'd at least operate at the correct frequency, that could in itself make USB work.
Oh and in case you need a makefile for F303 with steve's libmaple, here is it This makefile works in eclipse with CDT, I'm not sure about Sloeber
Code: Select all
# version 0 (alpha)
#
# This make file for libmaple core is possibly *dangerous*
# i.e. it compiles the sources (in src and STM32F1) directory
# and overwrite all the stuff in $(out_dir)
# $(out_dir) is the binary directory where the object files are dumped there
#
# make clean *deletes* the *$(out_dir)* (coded here as bin )
#
# this is a relative path makefile
# the directory structure needs to be
# Root
# +-- src (your sources e.g. the sketch
# | the files has to be cpp, c or h, no ino)
# |
# +-- STM32F3 (copy from the libmaple core)
# |
# +-- Makefile (this makefile)
#
# the make needs to be run from the root of this file structure
# the make is relative path from this Root
# generated object files and binaries (elf, bin) are placed into the
# $(out_dir) - bin
#
# make clean - *deletes* $(out_dir)
#
# make all - starts the build
#
# This is free and unencumbered software released into the public domain.
#
# Anyone is free to copy, modify, publish, use, compile, sell, or
# distribute this software, either in source code form or as a compiled
# binary, for any purpose, commercial or non-commercial, and by any
# means.
#
# In jurisdictions that recognize copyright laws, the author or authors
# of this software dedicate any and all copyright interest in the
# software to the public domain. We make this dedication for the benefit
# of the public at large and to the detriment of our heirs and
# successors. We intend this dedication to be an overt act of
# relinquishment in perpetuity of all present and future rights to this
# software under copyright law.
#
# 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 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.
#
# For more information, please refer to [http://unlicense.org]
# this folder is deleted with make clean
out_dir := build
# this is the name of the subdirectory under STM32F1/variants
# it needs to match, this caters to a single variant
variant := generic_f303cc
# these are the defines passed to gcc, g++ and the assembler
# use += to add more definitions
defines := MCU_STM32F303CC
defines += __STM32F3__
defines += STM32F3
defines += STM32_MEDIUM_DENSITY
defines += ARDUINO=100
defines += VECT_TAB_ADDR=0x8000000
defines += USER_ADDR_ROM=0x8000000
defines += CONFIG_MAPLE_MINI_NO_DISABLE_DEBUG
defines += DEBUG_LEVEL=DEBUG_NONE
defines += F_CPU=72000000L
defines += CRYSTAL_FREQ=8
defines += SERIAL_USB
defines += BOARD_HAVE_SERIALUSB
defines += USB_VID=0x1EAF
defines += USB_PID=0x0004
defines += USB_MANUFACTURER=\"Unknown\"
defines += USB_PRODUCT=
defines += LED_BUILTIN=PC13
defines += HAVE_ERROR_LED
defines += ERROR_LED_PORT=GPIOC
defines += ERROR_LED_PIN=13
# source directories
# these are the initial directories to search for sources
# relative to this build (root) directory
# if you use libraries either put them in a sub-directory in src
srcdir := src
# or add it here
#srcdir += library1
#srcdir += library2
# points to the root folder of stm32duino libmaple core
# this should be 1 level above STM32F1 folder
# use of this is not encouraged, it is safer to copy the STM32F1
# folder into the current directory
# omit the final slash after the directory
core_root := .
# these are the source directories for the libmaple core
# and variant, normally they stay unchanged
# if you want to place the libmaple core directory somewhere else,
# define core_root above
coredir := $(core_root)/STM32F3/cores/maple
variantdir += $(core_root)/STM32F3/variants/$(variant)
coredir += $(variantdir)
#this is the ld script in STM32F1/variants/$(variant)/ld to use
#ldscript := bootloader_20.ld
ldscript := jtag.ld
#the includes i.e. the -Ipath needs to be exlicitly stated
#no automatic recursive searching
#if you use libraries you may want to add it here
#includedir += /opt/arduino/gcc-arm-none-eabi-8-2018-q4-major/arm-none-eabi/include/
includedir += STM32F3/cores/maple/
includedir += STM32F3/cores/maple/libmaple/
includedir += STM32F3/cores/maple/libmaple/usb
includedir += STM32F3/cores/maple/libmaple/usb/usb_lib/
includedir += STM32F3/system/libmaple/
includedir += STM32F3/variants/generic_f303cc
#if you use core_root, you would need to add that as a prefix
#includedir := $(addprefix $(core_root)/,$(includedir))
# update this to match
# this should be the install base location of ARM_NONE_EABI_GCC toolchain
ARM_NONE_EABI_PATH := /opt/arduino/gcc-arm-none-eabi-8-2018-q4-major
# this should be the location of the arm standard libraries c & c++
# the arm-none-eabi/lib select the folder matching the arch
# compile options e.g. thumb and v7-m
LD_TOOLCHAIN_PATH := $(ARM_NONE_EABI_PATH)/arm-none-eabi/lib/thumb/v7e-m+fp
# recursive wildcard function, call with params:
# - start directory (finished with /) or empty string for current dir
# - glob pattern
# (taken from http://blog.jgc.org/2011/07/gnu-make-recursive-wildcard-function.html)
rwildcard=$(foreach d,$(wildcard $1*),$(call rwildcard,$d/,$2) $(filter $(subst *,%,$2),$d))
cfiles := $(strip $(foreach s, $(srcdir), $(call rwildcard,$(s),*.c)))
cxxfiles := $(strip $(foreach s, $(srcdir), $(call rwildcard,$(s),*.cpp)))
asfiles := $(strip $(foreach s, $(srcdir), $(call rwildcard,$(s),*.S)))
core_cfiles += $(subst $(core_root)/,,$(strip $(foreach s, $(coredir), $(call rwildcard,$(s),*.c))))
core_cxxfiles += $(subst $(core_root)/,,$(strip $(foreach s, $(coredir), $(call rwildcard,$(s),*.cpp))))
core_asfiles += $(subst $(core_root)/,,$(strip $(foreach s, $(coredir), $(call rwildcard,$(s),*.S))))
src_files := $(cfiles) $(cxxfiles) $(asfiles)
core_files := $(core_cfiles) $(core_cxxfiles) $(core_asfiles)
files := $(src_files) $(core_files)
sdirs := $(sort $(dir $(files)))
#hfiles := $(foreach s, $(includedir), $(call rwildcard,$(s),*.h))
#hfiles += $(foreach s, $(srcdir), $(call rwildcard,$(s),*.h))
#incdirs = $(sort $(dir $(hfiles)))
TOOLPREFIX := arm-none-eabi-
CC = $(ARM_NONE_EABI_PATH)/bin/$(TOOLPREFIX)gcc
CXX = $(ARM_NONE_EABI_PATH)/bin/$(TOOLPREFIX)g++
AS = $(ARM_NONE_EABI_PATH)/bin/$(TOOLPREFIX)as
OBJCOPY = $(ARM_NONE_EABI_PATH)/bin/$(TOOLPREFIX)objcopy
OBJDUMP = $(ARM_NONE_EABI_PATH)/bin/$(TOOLPREFIX)objdump
AR = $(ARM_NONE_EABI_PATH)/bin/$(TOOLPREFIX)ar
SIZE = $(ARM_NONE_EABI_PATH)/bin/$(TOOLPREFIX)size
NM = $(ARM_NONE_EABI_PATH)/bin/$(TOOLPREFIX)nm
LD = $(ARM_NONE_EABI_PATH)/bin/$(TOOLPREFIX)ld
DFUUTIL = dfu-util
RM = /usr/bin/rm
MKDIR = /usr/bin/mkdir -p
TEST = /usr/bin/test
DEFINES := $(addprefix -D,$(defines))
INCLUDES := $(addprefix -I,$(includedir))
#optimise
# -O0 - none
# -Os - optimise size
# -O1 - optimise
# -O2 - optimise more
# -O3 - optimise most
# -Og - optimise debug
OFLAG := -Os
#debug
# default none
# -g - debug
# -g1 - minimal
# -g3 - maximal
DFLAG = -g
COMMON_OFLAGS := -Wl,--gc-sections $(OFLAG) $(DFLAG) \
-ffunction-sections -fdata-sections \
-fmessage-length=0 -fsigned-char \
-ffreestanding -fno-move-loop-invariants \
--specs=nano.specs -Wall -Wextra
FPU_FLAGS := -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant
#FPU_FLAGS := -mfloat-abi=softfp -mfpu=fpv4-sp-d16 -fsingle-precision-constant
TARGET_FLAGS += -mcpu=cortex-m4 -march=armv7e-m+fp -mthumb \
$(FPU_FLAGS) \
$(INCLUDES) $(DEFINES)
GLOBAL_CFLAGS := $(COMMON_OFLAGS) $(TARGET_FLAGS)
TARGET_CFLAGS :=
GLOBAL_CXXFLAGS := -fno-rtti -fno-exceptions \
-fno-use-cxa-atexit -fno-threadsafe-statics \
$(COMMON_OFLAGS) \
$(TARGET_FLAGS)
TARGET_CXXFLAGS :=
GLOBAL_ASFLAGS := $(TARGET_FLAGS)
#TARGET_ASFLAGS := -Wl,--gc-sections $(OFLAG) $(DFLAG) -Xassembler -Wall
TARGET_ASFLAGS := -Wl,--gc-sections $(OFLAG) $(DFLAG)
LD_SCRIPT_PATH := $(variantdir)/ld/$(ldscript)
# -nostdlib
# -nodefaultlibs
# -nostartfiles
# -Wl,--gc-sections
GLOBAL_LDFLAGS := --specs=nano.specs \
-Xlinker --gc-sections
TARGET_LDFLAGS := $(TARGET_FLAGS) \
-Xlinker -T$(LD_SCRIPT_PATH) \
-L $(variantdir)/ld
CFLAGS = $(GLOBAL_CFLAGS) $(TARGET_CFLAGS)
CXXFLAGS = $(GLOBAL_CXXFLAGS) $(TARGET_CXXFLAGS)
CPPFLAGS =
ASFLAGS = $(GLOBAL_ASFLAGS) $(TARGET_ASFLAGS)
# Add toolchain directory to LD search path
TOOLCHAIN_LDFLAGS := -L $(LD_TOOLCHAIN_PATH)
LDFLAGS = $(GLOBAL_LDFLAGS) $(TARGET_LDFLAGS) $(TOOLCHAIN_LDFLAGS)
#build lists of object files relative to $(out_dir)
COBJS = $(addprefix $(out_dir)/,$(patsubst %.c,%.o,$(cfiles)))
CXXOBJS = $(addprefix $(out_dir)/,$(patsubst %.cpp,%.o,$(cxxfiles)))
ASOBJS = $(addprefix $(out_dir)/,$(patsubst %.S,%.o,$(asfiles)))
CORE_COBJS = $(addprefix $(out_dir)/,$(patsubst %.c,%.o,$(core_cfiles)))
CORE_CXXOBJS = $(addprefix $(out_dir)/,$(patsubst %.cpp,%.o,$(core_cxxfiles)))
CORE_ASOBJS = $(addprefix $(out_dir)/,$(patsubst %.S,%.o,$(core_asfiles)))
variant.ELF = $(out_dir)/$(variant).elf
variant.BIN = $(out_dir)/$(variant).bin
.PHONY: all clean mkdir
all: mkdir $(variant.BIN)
@echo
@$(SIZE) $(variant.ELF)
@echo
@ls -l $(variant.BIN)
@echo
@$(OBJDUMP) --section-headers $(variant.ELF)
@echo
@echo Source dirs
@echo $(srcdir) $(coredir) | sed 's/ /\n/g'
@echo
@echo $(sort $(dir $(src_files))) | sed 's/ /\n/g'
@echo $(addprefix $(core_root)/,$(sort $(dir $(core_files)))) | sed 's/ /\n/g'
@echo
@echo Includes
@echo $(INCLUDES) | sed 's/ /\n/g'
@echo
@echo Defines
@echo $(DEFINES) | sed 's/ /\n/g'
install: all
$(DFUUTIL) -d 0483:df11 -a 0 -s 0x8000000 -D $(variant.BIN)
$(variant.BIN): $(variant.ELF)
$(OBJCOPY) -v -Obinary $(variant.ELF) $@
$(variant.ELF): $(ASOBJS) $(COBJS) $(CXXOBJS) \
$(CORE_COBJS) $(CORE_CXXOBJS) $(CORE_ASOBJS)
$(CXX) $(LDFLAGS) -o $@ -Wl,-Map,$(out_dir)/$(variant).map $+
# General directory independent build rules, generate dependency information
$(COBJS): $(out_dir)/%.o: %.c
$(CC) $(CFLAGS) -MMD -MP -MF $(@:%.o=%.d) -MT $@ -o $@ -c $<
$(CXXOBJS): $(out_dir)/%.o: %.cpp
$(CXX) $(CXXFLAGS) -MMD -MP -MF $(@:%.o=%.d) -MT $@ -o $@ -c $<
$(ASOBJS): $(out_dir)/%.o: %.S
$(CC) $(ASFLAGS) -MMD -MP -MF $(@:%.o=%.d) -MT $@ -o $@ -c $<
$(CORE_COBJS): $(out_dir)/%.o: $(core_root)/%.c
$(CC) $(CFLAGS) -MMD -MP -MF $(@:%.o=%.d) -MT $@ -o $@ -c $<
$(CORE_CXXOBJS): $(out_dir)/%.o: $(core_root)/%.cpp
$(CXX) $(CXXFLAGS) -MMD -MP -MF $(@:%.o=%.d) -MT $@ -o $@ -c $<
$(CORE_ASOBJS): $(out_dir)/%.o: $(core_root)/%.S
$(CC) $(ASFLAGS) -MMD -MP -MF $(@:%.o=%.d) -MT $@ -o $@ -c $<
# create the build directories
tgtdirs := $(addsuffix .dir,$(addprefix $(out_dir)/,$(sdirs)))
mkdir: $(tgtdirs)
# the .dir file is a marker file that the directory is created
$(tgtdirs) : $(out_dir)/.dir
$(MKDIR) $(dir $@)
@touch $@
$(out_dir)/.dir:
$(MKDIR) $(dir $@)
@touch $@
clean:
@echo clean
$(RM) -r $(out_dir)
DEPENDS := $(COBJS:%.o=%.d) $(CXXOBJS:%.o=%.d) $(ASOBJS:%.o=%.d)
DEPENDS += $(CORE_COBJS:%.o=%.d) $(CORE_CXXOBJS:%.o=%.d) $(CORE_ASOBJS:%.o=%.d)
-include $(DEPENDS)