I'm trying to compile micropython for the ESP32.
( git#github.com:micropython/micropython.git and git#github.com:espressif/esp-idf.git)
in micropython/ports/esp32/GNUMakefile I have variables defined like so:
#PYTHON2 = $(shell pwd)/../../../venv3.7/bin/python
ESPIDF = $(shell pwd)/../../../esp-idf/
BOARD = GENERIC_SPIRAM
PORT = /dev/cu.SLAB_USBtoUART
FLASH_MODE = dio
FLASH_SIZE = 4MB
BAUD = 115200
In the makefile lazy setters are used ( ?=) for variables like the BOARD but still gmake ends up building GENERIC instead of GENERIC_SPIRAM.
Other settings like PORT are ignored as well and I cannot even erase any connected device as /dev/cu.SLAB_USBtoUART is always overwritten with '/dev/ttyUSB0'
I'm on OSX mojave.
Can anyone point me in the right direction?
After countless hours of debugging I found out that even though OSX is case insenstive... It mattered that the GNUMakefile had a uppercase M while it should have been GNUmakefile
That was an expensive typo...
Related
I have a problem getting a valid absolute address in my Makefile. I need to migrate from GNU Make 3.81 to 4.3.
When using this:
PROJECT_DIR = $(subst \,/,${CURDIR})/..
Instead of something like:
D:/Project/What_ever/
I'm getting this:
/d/Project/What_ever
I need the absolute address for some external tools.
And of course the /d/... is not the Windows format really.
KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file does not work as I expected.
First lesson I learned: defconfig != .config
Bare-Kernel-Build (without yocto): A new defconfig file below arch/arm/config/xy_defconfig created by make savedefconfig is not equal to the .config file. I assume the linux kernel expand some symbols and create the final .config.
Yocto-Build: Here comes the issue: Yocto can not correctly handle the defconfig file below arch/arm/config/xy_defconfig. When building the linux-kernel with yocto.. the kernel is half size and not bootable. This results, because yocto does not expand the missing symbols in .config, which a make defconfig would do.
How do you handle the issue?
Update:
Figured out an additional make xy_defconfig do the trick and creates the correct .config file. It is a ugly hack, any better ideas are very welcome.
Added this to my custom linux-xy.bb file.
KBUILD_DEFCONFIG ?= xy_defconfig
do_makedefconfig() {
oe_runmake -C ${B} ARCH=${ARCH} $KBUILD_DEFCONFIG
}
addtask do_makedefconfig after do_configme before do_compile
First copy your defconfig to sources/meta-mylayer/recipes-kernel/linux
and write a .bbappend file for linux recipe
linux-ti_%.bbappend
FILESEXTRAPATHS_prepend : "${THISDIR}:"
SRC_URI += "file://your-defconfig"
2. open sources/meta-mylayer/conf/machine/your-machine.conf add below line,
search the macro if already present or nor using grep -inr "INTREE_DEFCONFIG"
INTREE_DEFCONFIG_pn-linux-ti = "am335x_phytec_defconfig"
if the macro already present in the same file replace defconfig name.
kernel-yocto approach
The KBUILD_DEFCONFIG variable is handled by kernel-yocto class, so you need to inherit it. It is usually done indirectly through include file linux-yocto.inc, so you should have this line you linux recipe:
require recipes-kernel/linux/linux-yocto.inc
Please note that KBUILD_DEFCONFIG_KMACHINE consists of two parts. The first one is variable name (KBUILD_DEFCONFIG) and the second one is kernel machine override (KMACHINE). So you need to change the override to fit your machine. That's why the KMACHINE part is written in italics in the documentation [1]. There is an example for RPi from the documentation:
KBUILD_DEFCONFIG_raspberrypi2 = "bcm2709_defconfig"
The KMACHINE is set in linux-yocto.inc to the MACHINE variable by default.
handle in-tree defconfig by hand
We are using in-tree defconfig without the kernel-yocto class. linux.inc from meta-oe layer is used. I don't know if this is a best practice. Here is our linux recipe (it is reduced to a bare minimum):
require recipes-kernel/linux/linux.inc
PV = "your_version"
SRC_URI = "your_sources"
do_configure_prepend() {
bbnote "Copying defconfig"
cp ${S}/arch/${ARCH}/configs/YOUR_defconfig ${WORKDIR}/defconfig
}
[1] https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#var-KBUILD_DEFCONFIG
Let me start out with a disclaimer:
I am new to writing my own makefiles and have just had a few days of research and tinkering around with my own makefile to try to figure things out. I have also Googled this question and spent a fair amount of time looking for an answer but haven't found one. There are many things I am inexperienced with, so if I ask a stupid question, please bear with me (and try to help me understand it).
I have made a makefile that I have been testing out to see if my understanding is correct, and so far everything here makes sense and works until it gets to $(CC). I'm on windows 7 using cygwin64 terminal and it gives this output after I type make:
make: tricore-gcc: Command not found
make: *** [Makefile:20: test_eeprom.o] Error 127
So why can't it recognize my compiler? Why does it say "Command not found?" I know the compiler is installed because I have used it for existing projects on my computer and just now am starting to write my own makefile and try to use it. I have even seen in other makefiles that were made by someone previous to me that they define the compiler the same way as me in the makefile.
For reference, here is my makefile:
#Test module Makefile
#compiler
CC = tricore-gcc
#path to MBD header files
MBDPATH = ../../../../../../Application/MBD/build/test_ert_rtw
#where the source code is
SRC = Src
#object files to be made
DS_OBJ = test_eeprom.o test_gd.o test_task.o \
sct_conf.o unimportant_name.o
#rule to make test eeprom object
test_eeprom.o: $(SRC)/test_eeprom.c $(SRC)/test_eeprom.h $(SRC)/test_task.h \
$(MBDPATH)/test.h
$(CC) -c test_eeprom.
I am new to the world of STM32F103. I have a demo code for STM32F103 and I am using arm-none-eabi to compile it.
I tried what I could find on Google, but nothing worked so far. I have already spent three days on the problem.
Anyone can give me a demo code for printf which works well?
Part of my makefile:
CFLAG = -mcpu=$(CPU) -mthumb -Wall -fdump-rtl-expand -specs=nano.specs --specs=rdimon.specs -Wl,--start-group -lgcc -lc -lm -lrdimon -Wl,--end-group
LDFLAG = -mcpu=$(CPU) -T ./stm32_flash.ld -specs=nano.specs --specs=rdimon.specs -Wl,--start-group -lgcc -lc -lm -lrdimon -Wl,--end-group
By including the following linker flags:
LDFLAGS += --specs=rdimon.specs -lc -lrdimon
it looks like you are trying to use what is called semihosting. You are telling the linker to include system call libraries.
Semihosting is a mechanism that enables code running on an ARM target to communicate and use the Input/Output facilities on a host computer that is running a debugger.
Examples of these facilities include keyboard input, screen output, and disk I/O. For example, you can use this mechanism to enable functions in the C library, such as printf() and scanf(), to use the screen and keyboard of the host instead of having a screen and keyboard on the target system.
Since you are using openSource tools for your STM32 development (Makefile and arm-none-eabi), I am assuming you are also using openOCD to program your microcontroller. openOCD requires you to enable semihosting as well using the following command:
arm semihosting enable
You can at the command to your openOCD script making sure you terminate the configuration stage and enter the run stage with the 'init' command. Below is an example of an openOCD script (adapted for STM32F103):
source [find target/stm32f1x.cfg]
init
arm semihosting enable
Other solutions mentioned here where your retarget the fputc() function to a UART interface will also work and might. Semihosting will work on all recent ARM Cortex-M but will require some compiler & debugger configuration (see above). Retargeting the fputc() function to a UART interface will work with any compiler but you will have to check your pin configurations for every board.
Writing an own printf implementation is an option, and probably the most recommended option according to me. Get some inspiration from the standard library implementation and write your own version, only to cater your requirements. In general, what you have to do is, first retarget a putc function to send char s through your serial interface. Then override the printf method by using the putc custom implementation. Perhaps, a very simple approach is sending the string character-wise by recursive calls for putc function.
Last but not least, you can find some lightweight printf implementations. The code size and the set of features offered by these lightweight implementations lie in between the custom written printf function and the stock standard printf function (aka the beast). I have recently tried this Tiny Printf and very pleased with its performance on an ARM core in terms of memory footprint and the number of execution cycles required.
-PS
Copied from my own writings sometime back.
Link: How to retarget printf() on an STM32F10x?
Try hijacking the _write function like so:
#define STDOUT_FILENO 1
#define STDERR_FILENO 2
int _write(int file, char *ptr, int len)
{
switch (file)
{
case STDOUT_FILENO: /*stdout*/
// Send the string somewhere
break;
case STDERR_FILENO: /* stderr */
// Send the string somewhere
break;
default:
return -1;
}
return len;
}
The original printf will go through this function (depending on what libs you use of course).
Look there. This is printf from glib. But you have microcontroller. So you sould write own printf, where vfprintf will return result into buffer and next you will send data from buffer to UART. Kind of
void printf( const char * format, ... )
{
char buffer[256];
va_list args;
va_start (args, format);
vsprintf (buffer,format, args);
send_via_USART1 (buffer);
va_end (args);
}
Also you can write own vsprintf. Standart vsprintf is very heavy. Usually little part of vsprintf features is used.
I am using GNU Make to build a multiple-directory project.
My question is how can I use single makefile to build multiple devices?
e.g. My application has to run on various X,Y,Z mobile devices each having different properties like screensize, keyboard type, platform version etc. I have to pass make -f <makefilename> <targetname>. Here targetname can be device name and model like Samsung CorbyPlus, but my makefile has to go to particular dirname of samsung and open the .txt file or so where all above properties are defined. I have to read all of them during build time and access in my code through some macros/defines/flags.
Can anyone suggest how to do this? Even better solution for my requirement will be appreciated.
I'd suggest using configuration makefiles. For example, suppose you have several device with its configurations:
config_device1.mk
OPTION1=yes
OPTION2=0
config_device2.mk
OPTION1=no
OPTION2=1
Then you can conditionally include them into base makefile using special parameter passed from command line (make -f makefile DEVICE=dev_type1) and use options from configuration files and process them:
makefile
ifeq ($(DEVICE),dev_type1)
include $(CONFIG_PATH)/config_device1.mk
endif
ifeq ($(DEVICE),dev_type2)
include $(CONFIG_PATH)/config_device1.mk
endif
ifeq ($(OPTION1),yes)
CFLAGS += -DBUILD_OPTION1
endif
CFLAGS += -DBUILD_OPTION2=$(OPTION2)
BTW, for a long perspective (if you don't have time constraints now) it's better to use some of existing build system, read its manual and stick to its methodology.