New versions of LD cannot take ELF files as input to link - linux

I have been working on a 32-bit operating system project written in C using GNU LD version 2.34 as the linker.
As part of the build process, I use the following command:
ld -m elf_i386 -nostdlib -T ld/loader.ld build/bootloader/loader.o build/bootloader/loader.elf -o loader_full.elf
When using GNU LD version 2.34, this command succeeds. However, when I use a version higher than this, I get the following error:
ld: cannot use executable file 'build/bootloader/loader.elf' as input to a link
If necessary, here is the full Makefile script:
CC_FLAGS = -g -m32 -ffreestanding -nostartfiles -nostdlib -fno-stack-protector
LD_FLAGS = -m elf_i386 -nostdlib
CC := gcc ${CC_FLAGS}
LD := ld ${LD_FLAGS}
BOOTLOADER_DRIVERS = kernel/drivers/disk/ata.c kernel/drivers/io/screen.c kernel/drivers/utils/mem.c kernel/drivers/utils/ports.c
raw: prep os-image.bin
convert_vmdk: os-image.vmdk
all: prep os-image.bin
ESFS_raw_write: ESFS_raw_write.c
gcc $^ -o $#
# run OS in QEMU
run:
qemu-system-i386 -drive format=raw,file=os-image.bin
# assemble boot sector
build/bootloader/boot_sect.bin: boot/boot_sect.asm
nasm $^ -f bin -o $#
# compile second stage bootloader
build/bootloader/loader_2.o build/drivers/*.o: boot/*.c ${BOOTLOADER_DRIVERS}
${CC} -c $^
mv loader.o build/bootloader/loader_2.o
mv *.o build/drivers/
# link object files into kernel loader
build/bootloader/loader.elf: build/bootloader/loader_2.o build/drivers/*.o
${LD} -T ld/loader.ld $^ -o $#
rm build/bootloader/loader_2.o
# assemble first stage bootloader
build/bootloader/loader.o: boot/loader.asm
nasm $^ -f elf -o $#
# link first and second stage bootloaders
build/bootloader/loader_full.elf: build/bootloader/loader.o build/bootloader/loader.elf
${LD} -T ld/loader.ld $^ -o $#
# make bootloader binary file
build/bootloader/loader.bin: build/bootloader/loader_full.elf
objcopy $^ -O binary $#
./scripts/pad_loader.sh
# clean up unnecessary files
# rm build/bootloader/*.o build/bootloader/*.elf build/drivers/*.o
build/kernel/interrupt.o: kernel/cpu/interrupt.asm
nasm $^ -f elf -o $#
# compile kernel & write to 10MB raw drive image
build/kernel/hdd.bin: kernel/drivers/*/*.c kernel/cpu/*.c kernel/libc/*.c build/kernel/interrupt.o kernel/*.c
${CC} $^ -o build/kernel/kernel.o -T ld/kernel.ld
./scripts/write_kernel_to_drive.sh
# concat 3 boot stages into os-image file
os-image.bin: build/bootloader/boot_sect.bin build/bootloader/loader.bin build/kernel/hdd.bin
cat $^ > $#
os-image.vmdk:
VBoxManage convertfromraw os-image.bin os-image.vmdk --format VMDK
VBoxManage internalcommands sethduuid /home/tim/Dev/OSDev/os-image.vmdk 6372c00a-a62e-4241-9a21-90fa4c22f019
# prepare directory structure for build process
prep:
mkdir -p build/bootloader
mkdir -p build/drivers
mkdir -p build/kernel
# clean up build files and os-image binary
clean:
-rm -rf build/
-rm *.bin *.vmdk
-rm ESFS_raw_write
The project is also on GitHub, so you can build it for yourself:
http://github.com/TimCve/OSDev.git

I have just come up with a similar problem.
It seems ld version GNU ld (GNU Binutils) 2.36.1 links the file into an executable format.
To fix it, add -r in your ld command to output a relocatable format file.
From the ld manual:
-r
--relocateable
Generate relocatable output--i.e., generate an output file that can in turn serve as input to ld. This is often called partial linking. As a side effect, in environments that support standard Unix magic numbers, this option also sets the output file's magic number to OMAGIC. If this option is not specified, an absolute file is produced. When linking C++ programs, this option will not resolve references to constructors; to do that, use -Ur. This option does the same thing as -i.

It's not that ld can't take ELF files as input. It's that it won't take executable files as input. The error is:
ld: cannot use executable file '...' as input to a link
See https://sourceware.org/bugzilla/show_bug.cgi?id=26223
Does it work to simply use chmod -x $# after building the .elf file?

In my (eclipse-based) multicore MCUXpresso project, I had to add this line to my post-build steps to modify a byte inside of the generated "*.o" file so the linker step which used that file wouldn't complain anymore. This happened after I updated to version 11.6 which includes the LD version mentioned previously. I originally found this on the forums for NXP MCUXpresso, but I assume it will work similarly for just about anyone:
dd if=/dev/zero of="${BuildArtifactFileName}.o" bs=1 seek=16 conv=notrunc count=2
NXP MCUXpresso fix

Related

Yocto Multifile compilation

I have 4 files in different directories.
1. /home/Linux/NXP/XYZ/Embedded/Read/read.c
2. /home/Linux/NXP/XYZ/Embedded/main/mainfun.c
3. /home/Linux/NXP/XYZ/Embedded/write/write.c
4. /home/Linux/NXP/XYZ/Embedded/config/config.c
and the .bb file is located at
"/home/Linux/NXP/yocto/jethro/yocto/source/meta-mylayer/recipes-app/mainfun/mainfun.bb"
From mainfun.c I am calling different functions, the definitions of which are present inside write.c, config.c, read.c.
I have only come across a single file compilation using yocto so can you please help how do I write the .bb file? How can I compile and generate "XYZ_app" executable?
Here I attached my .bb file which I have written but it's not working:
DESCRIPTION = "multiple file compilation"
PR = "r0"
LICENSE = "CLOSED"
SRC_URI += "file://home/Linux/NXP/XYZ/Embedded/ \
"
S = "${WORKDIR}"
do_compile() {
${CC} ${CFLAGS} ${LDFLAGS} --static -c ${WORKDIR}}/home/Linux/NXP/XYZ/Embedded/read/read.c
${CC} ${CFLAGS} ${LDFLAGS} --static -c ${WORKDIR}}/home/Linux/NXP/XYZ/Embedded/write/write.c
${CC} ${CFLAGS} ${LDFLAGS} --static -c ${WORKDIR}}/home/Linux/NXP/XYZ/Embedded/conf/conf.c
${CC} ${CFLAGS} ${LDFLAGS} --static -c ${WORKDIR}}/home/Linux/NXP/XYZ/Embedded/mainfun/mainfun.c
${CC} ${CFLAGS} ${LDFLAGS} --static ${WORKDIR} /home/Linux/NXP/XYZ/Embedded/Read/read.o /home/Linux/NXP/XYZ/Embedded/write/write.o /home/Linux/NXP/XYZ/Embedded/conf/conf.o /home/Linux/NXP/XYZ/Embedded/mainfun/mainfun.o -c XYZ_App
}
do_install() {
install -m 0755 -d ${D}${bindir}
install -m 0755 ${S}/XYZ_App ${D}${bindir}
}
The direct compilation of source files in a recipe is a testing/emergency solution at best. Whenever it comes to something even only slightly advanced, the correct way is to use a build system of any kind.
Those directly supported in OpenEmbedded include (amongst others)
Makefiles
Autotools
CMake
Here are examples for a couple of recipes for those systems: http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#new-recipe-testing-examples
Properly packing the sources up also gives you a way to easily test the compilation and application without having to invoke the whole bitbake process. All of them have pros and cons, so you might want to dig a deep further. For a start into autotools, this seems to be a good thing:
https://developer.gnome.org/anjuta-build-tutorial/stable/create-autotools.html.en
An alternative is to look at GNU hello, and also the corresponding recipe.

On linux ubuntu 16 32bit, DrPaulcarter assembly language tutorial, undefined reference error

I'm new in assembly language, so i am following Dr.Paul Carter's pcasm tutorial(
http://pacman128.github.io/pcasm/
).
Exactly pdf file(http://pacman128.github.io/static/pcasm-book.pdf) page-33, and book's page-23
From that site, i downloaded Linux Example (http://pacman128.github.io/static/linux-ex.zip)
and at the terminal i input
nasm -f coff first.asm
gcc -c driver.c
nasm -f coff asm_io.o
gcc -o first driver.o first.o asm_io.o
But it returned it
Where is problem?
(Screenshot's command -lc is no matter, if there is no -lc, it returned the same thing)
For Linux asm_io doesn't work with 64-bit. You have to create 32-bit programs. Compile C files as 32-bit using the -m32 option. You also have to assemble asm_io.asm with a special define -d ELF_TYPE for this to work on Linux. Don't use coff. Commands like this should work:
nasm -f elf -d ELF_TYPE asm_io.asm
nasm -f elf first.asm
gcc -m32 -c driver.c
gcc -m32 -o first driver.o first.o asm_io.o
If you are truly on 32-bit Linux you will be able to omit -m32
I found that error is from asm_io.asm. You should have to modify asm_io.asm or check define lines.

How can I give permissions in a basic makefile

How do I add permissions to this simple make file?
all: shell ls cat groups
shell: shell.o cd.o
gcc shell.o cd.o -o shell
cat: cat.o
gcc -c cat.c -o cat
ls: ls.o header.h
gcc -c ls.c -o ls
groups: groups.o groups.h
gcc -c groups.c -o groups
shell.o: shell.c tlpi_hdr.h
gcc -c shell.c
cd.o: cd.c tlpi_hdr.h
gcc -c cd.c
cat.o: cat.c tlpi_hdr.h
gcc -c cat.c
ls.o: ls.c header.h
gcc -c ls.c
groups.o: groups.c groups.h
gcc -c groups.c
clean:
rm *.o shell cat ls groups
I need to run cat/ls/groups/cd within the shell that I created, but can't because it doesn't have permissions. How can I do this?
As an example, this rule:
groups: groups.o groups.h
gcc -c groups.c -o groups
tells GCC to produce an object file called groups (instead of the normal groups.o) because you included the -c option. Object files are not executables, so the compiler doesn't make them executable, hence your problem with the permissions. Note that the rule requires make to build groups.o, but then proceeds to ignore the object file because it recompiles the source code.
You wanted to write something more like:
groups: groups.o
gcc groups.o -o groups
groups.o: groups.h
You need to use a lot more macros — or you could leave the rules out of the makefile since make knows how to build groups from groups.c.
You should also be compiling with warning options. At minimum -Wall; preferably -Wall -Wextra -Werror (and I use still more options than these). You might want optimization (-O3); you might want debugging (-g). These are normally handled via setting macros and then using them in the commands.

what does ld -m --verbose actually do?

I am confused by this command. The man page http://linux.die.net/man/1/ld says it "emulates the emulation linker. You can list the available emulations with the --verbose or -V options." But what does the "available emulations" mean?
For example, I use the following command to link objects:
ld -r -nostdlib -L/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib \
-m elf_x86_64 --verbose ./arch/x86/x86_64.o ./mini-os_app.o ./blkfront.o ./events.o ./fbfront.o \
./gntmap.o ./gnttab.o ./hypervisor.o ./kernel.o ./lock.o ./main.o ./mm.o ./netfront.o ./sched.o \
./lib/ctype.o ./lib/math.o ./lib/printf.o ./lib/stack_chk_fail.o ./lib/string.o ./lib/sys.o \
./lib/xmalloc.o ./lib/xs.o ./xenbus/xenbus.o ./console/console.o ./console/xencons_ring.o \
./console/xenbus.o ./lwip.a -L./arch/x86 -lx86_64 -lc -lglib-2.0 -lvmi -o ./mini-os.o
GNU ld (GNU Binutils for Ubuntu) 2.22
Supported emulations:
elf_x86_64
elf32_x86_64
elf_i386
i386linux
elf_l1om
elf_k1om
using internal linker script:
==================================================
(>>> scripts displayed here, neglected <<<)
==================================================
...
attempt to open /media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a succeeded
(>>> lots of *.o listed here for libc.a <<<)
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a)mm.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a)sched.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a)setup.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a)time.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/mini-os-x86_64-vmi/arch/x86/libx86_64.a)traps.o
...
attempt to open /media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libglib-2.0.a succeeded
(>>> why no *.o files listed here? <<<)
attempt to open /media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a succeeded
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-accessors.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-convenience.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-core.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-events.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-memory.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-read.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-interface.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-kvm.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-memory_cache.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-xen.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)lt1-libvmi_la-core.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)lt2-libvmi_la-memory.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-symbols.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)lt3-libvmi_la-core.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-kpcr.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)lt4-libvmi_la-memory.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-peparse.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-process.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)grammar.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)lexicon.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-cache.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-strmatch.o
(/media/wind/lab/xen/xen/xen-4.4.0/stubdom/cross-root-x86_64/x86_64-xen-elf/lib/libvmi.a)libvmi_la-file.o
As showed in the above outputs, it seems that each *.a library should have their own *.o listed. But what is the meaning if no *.o listed for a certain *.a library,such as glib-2.0.a showed above ?
Thank you in advance!
The ld -m option is used while linking .o files to create an executable file for a hardware platform provided as an argument with -m option.
E.g. if you specify ld -m elf_x86_64 ..., an executable file is created (assuming no error occurred) that can run on a x86_64 system. This is generally used during cross compiling. i.e. in the situation when you are trying to create an executable for a platform different from the one it is being built.

Command line Arduino compiling and uploading?

How do I compile and upload Arduino sketches from the command line on Mac and Linux? I've installed the Arduino programming environment. Are there some sample makefiles anywhere?
There is a command-line Arduino toolkit named Ino. It just does that.
Compiling and uploading sketches (as apposed to C/C++ sources) on the command line (on Windows, Mac, and Linux) is supported directly via flags to the arduino executable since 1.5.0.
An ino can be compiled and uploaded with arduino --upload [sketch.ino]
Documentation
This is my boilerplate gnu make include for AVR projects, you may need to adapt some of it to fit your environment. It creates dependencies, has a host of standard gcc options I find useful or that optimize for size, as well as a library dir I use. I used this successfully to compile arduino software, I also previously hacked the PdePreprocessor in the arduino editor to be run from the command line to generate all the voodoo:
https://github.com/wesen/mididuino/blob/master/app/src/processing/app/preproc/PdePreprocessor.java
#
# generic AVR makefile
#
# (c) July 2011 - Manuel Odendahl - wesen#ruinwesen.com
#
# include this into your main Makefile, after having defined TARGET and TARGET_OBJS
all: $(TARGET).hex
CURDIR := $(dir $(lastword $(MAKEFILE_LIST)))
include $(CURDIR)MidiCtrl.mk
CC = avr-gcc
CXX = avr-g++
OBJCOPY = avr-objcopy
AVR_ARCH ?= atmega64
LDAVR_ARCH ?= avrmega64
FLASH_PROTOCOL = jtag2
CFLAGS += -Os -ffunction-sections -DAVR -I. -mmcu=$(AVR_ARCH) -mcall-prologues -fshort-enums -fpack-struct -Wall -Werror
CFLAGS += -Wall -DLITTLE_ENDIAN -g -flto
CFLAGS += no-tree-loop-optimize -ffreestanding -morder1 -funsigned-char -funsigned-bitfields -fshort-enums -fpack-struct
CFLAGS += -fdata-sections -fno-split-wide-types -fno-inline-small-functions -mcall-prologues
CLDFLAGS += -Wl,--relax,--gc-sections -ffunction-sections
CLDFLAGS += -mmcu=$(AVR_ARCH)
LDFLAGS = -m $(LDAVR_ARCH) -M
# generate list
# CFLAGS += -Wa,-adhlns=$#.lst
%.o: %.cpp
$(CXX) $(CXXFLAGS) -c $< -o $#
%.o: %.c
$(CC) $(CFLAGS) -c $< -o $#
%.o: %.s
$(CC) $(CFLAGS) -c $< -o $#
%.s: %.c
$(CC) -S $(CFLAGS) -fverbose-asm $< -o $#
%.o: %.S
$(CC) $(CFLAGS) -c $< -o $#
%.syx: %.hex
ihex2sysex $< $#
%.srec: %.elf
$(OBJCOPY) -j .text -j .data -O srec $< $#
%.hex: %.elf
$(OBJCOPY) -j .text -j .data -O ihex $< $#
%.ee_srec: %.elf
$(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O srec $< $#
AVR_BASE_DIR ?= $(abspath $(CURDIR)..)
AVR_LIB_DIR ?= $(AVR_BASE_DIR)/hardware/libraries
AVR_LIBS += CommonTools Midi
AVR_LIB_DIRS += $(foreach lib,$(AVR_LIBS),$(AVR_LIB_DIR)/$(lib))
AVR_INC_FLAGS += $(foreach dir,$(AVR_LIB_DIRS),-I$(dir))
AVR_OBJS += $(foreach dir,$(AVR_LIB_DIRS),$(foreach file,$(wildcard $(dir)/*.cpp),$(subst .cpp,.o,$(file))))
AVR_OBJS += $(foreach dir,$(AVR_LIB_DIRS),$(foreach file,$(filter-out $(AVR_HOST_EXCLUDE),$(wildcard $(dir)/*.c)),$(subst .c,.o,$(file))))
AVR_DEPS += $(subst .o,.d,$(AVR_OBJS))
# AVR_HOST_EXCLUDE can be used to exclude specific files later on
CXXFLAGS += $(AVR_INC_FLAGS)
CFLAGS += $(AVR_INC_FLAGS)
CXXFlags += -Werror -Wall
CFLAGS += -Werror -Wall
default: all
%.d:%.c
set -e; $(CC) -MM $(CFLAGS) $< \
| sed 's,\($*\)\.o[ :]*,\1.o $# : ,g' > $# ; \
[ -s $# ] || rm -f $#
%.d:%.cpp
set -e; $(CXX) -MM $(CXXFLAGS) $< \
| sed 's,\($*\)\.o[ :]*,\1.o $# : ,g' > $# ; \
[ -s $# ] || rm -f $#
%.host.d:%.c
set -e; $(CC) -MM $(CFLAGS) $< \
| sed 's,\($*\)\.o[ :]*,\1.o $# : ,g' > $# ; \
[ -s $# ] || rm -f $#
%.host.d:%.cpp
set -e; $(CXX) -MM $(CXXFLAGS) $< \
| sed 's,\($*\)\.o[ :]*,\1.o $# : ,g' > $# ; \
[ -s $# ] || rm -f $#
printlibs:
echo $(AVR_LIBS)
$(TARGET).elf: $(TARGET).o $(TARGET_OBJS) $(AVR_OBJS)
$(CXX) $(CLDFLAGS) -g -o $# $^
_clean:
- rm *.elf *.hex *.o .midictrl.flags
libclean:
rm -rf $(TARGET_OBJS) $(OBJS)
# concrete settings for development environment
UNAME=$(shell uname)
ISWIN=$(findstring CYGWIN,$(UNAME))
ISMAC=$(findstring Darwin,$(UNAME))
CC = avr-gcc
CXX = avr-g++
OBJCOPY = avr-objcopy
AVR_ARCH = atmega64
F_CPU = 16000000L
CORE = minicommand2
Official CLI tool
The arduino team is developing a cli client
https://github.com/arduino/arduino-cli
Announcement: https://blog.arduino.cc/2018/08/24/announcing-the-arduino-command-line-interface-cli/
You can do almost everything with this, from downloading boards and libraries, to compile and upload scripts. What's missing is the monitoring part.
To monitor in linux you can still use the commands stty to configure port and cat to read it.
stty -F /dev/ttyACM0 38400 # <-- Baud rate. The number in Serial.begin()
cat /dev/ttyACM0 # <-- Port
You can find the port with arduino-cli
arduino-cli board list
Full instructions in the Github repo and the man page:
$ arduino-cli Arduino Command Line Interface (arduino-cli).
Usage: arduino-cli [command]
Examples: arduino <command> [flags...]
Available Commands:
board Arduino board commands.
compile Compiles Arduino sketches.
config Arduino Configuration Commands.
core Arduino Core operations.
help Help about any command
lib Arduino commands about libraries.
sketch Arduino CLI Sketch Commands.
upload Upload Arduino sketches.
version Shows version number of Arduino CLI.
You need to actually create a viable cpp file out of your arduino sketch. The arduino environment does that for you automatically. One trick to get to those files is to open your arduino preferences.txt (it's in ~/Library/Arduino on the mac, I think in your Documents and Settings or Application Data on windows, don't remember exactly), and set build.verbose=true and upload.verbose=true. Start arduino, and compile your sketch (don't upload it). The console at the bottom will show you which files were compiled. You can now go to that directory, which will contain the cpp file, and compiled object files for all the core arduino objects. You can copy those into your project and use the cpp file to do further hacking. Let me know if you need more information about the Makefile, I can provide you with those I have.
You can actually use the arduino GUI to compile and upload, and set the editor to external in the preferences. That way, you can edit the C++ (PDE) files from xcode, and have arduino generate the actual CPP and build the whole shebang.
You can also use XCode to write plain C++/C for the arduino, using the avr-gcc compiler.
Have a look at: https://stackoverflow.com/a/8192762/153835
You can then use the plain avrdude upload tool to program the arduino. Have a look at: http://www.ladyada.net/library/arduino/bootloader.html
It used to be that the protocol spoken by Arduino was a modification of the STK500 protocol, and that only the avrdude bundled with arduino could speak it. I don't know if the mainstream avrdude was upgraded, or if you still have to resort to the avrdude inside the Arduino folder.
You can use biicode (it's a project I'm working in) which is based on CMake (but you don't actually need to write any cmake file) and is also a tool to manage Arduino libraries
It's main features are:
Dependencies resolution, transitively, as maven does, but without config files: reads dependencies directly from source code.
Central repository, anyone can upload their libraries. They can be explored, navigated and discovered in the web
Version control: it checks versions compatibility and allows safe updates of dependencies
You can use it with any text editor (it has optional eclipse integration)
It manages project setup and compilations, flashes generated firmware to the board
You can see a quick demo here and read more in the documentation.
If you can use cmake then there are some links in the same web (this and this for example). GNU makefile is a little bit different from cmake but nothing complicated. Just Google a little bit and you can find a lot of Makefile examples how to compile AVR code.
I use platformio, quite like it. It also has extensions into Visual Studio Code, so you can do everything from there. It has library manager and uploader built-in.
My setup is a NFS drive where I have the code, mounted on my linux laptop, and also mounted on my Raspberry Pi that sits next to my Arduino's.
When it's time to compile, I do so on my laptop, and as the RPi is next to the Arduino, I upload from there..
After installing and configuring, the basics are simple;
'platformio run' will compile your code.
'platformio run -t upload' will compile & upload.
I also have a bash function to upload without compiling;
function th(){
if [ "${1}" = "upload" ];then
if [ ! -f platformio.ini ]; then
echo platformio.ini not found
else
UPLOAD_PORT=`cat platformio.ini | grep upload_port | awk '{print $3}'`
if [ "${UPLOAD_PORT}" = "" ]; then
echo no upload port
else
if [ "${2}" != "" ]; then
FIRMWARE=${2}
else
#the firmware location seems to have moved
# FIRMWARE='.pioenvs/megaatmega2560/firmware.hex'
FIRMWARE='.pio/build/megaatmega2560/firmware.hex'
fi
if [ -f "${FIRMWARE}" ]; then
avrdude -v -p atmega2560 -C /home/stevenk/.platformio/packages/tool-avrdude/avrdude.conf -c wiring -b 115200 -D -P "${UPLOAD_PORT}" -U flash:w:$FIRMWARE:i
else
echo ${FIRMWARE} not found
fi
fi
fi
else
wget --timeout 8 -qO- http://192.168.178.212/$1
fi
}
If you do not insist on make there is also scons/sconstruct scons/sconstruct. Since this in basically written in Python it is much simpler to tweak than make. In addition it can be debugged with any Python debugger.
I have a makefile for Arduino which can be used to compile and upload Arduino (or plain AVR C) programs to Arduino.
Following are some of the important features of this makefile
Supports upload via Arduino as ISP or any programmer
Supports compiling plain AVR C programs
Supports user as well as system libraries.
Generate assembly and symbol files
Program using alternate Arduino core (like ATtiny or Arduino alternate cores)
There's an official Arduino CLI tool:
https://blog.arduino.cc/2021/02/15/arduino-cli-0-16-0-is-ready-for-you-all/?queryID=undefined
It works pretty well, in my opinion. The GitHub repo is here:
https://github.com/arduino/arduino-cli
It's version 0.16.0. so sort of beta, but not really....
You can find the libraries and sample codes included in the Arduino under "file->examples".

Resources