With enabled add_definitions("-pedantic-errors") avr-gcc causes an error in code that contains binary extensions, for example:

value = 0b10101; 

Hey,

first of all I want to thank you for the grate project.

But i think there is a bug: The variables (e.g. AVR_MCU) defined at the top of the CmakeLists file inside the root directory are never used.

I think this is because the tool chain file, which is passed with "-DCMAKE_TOOLCHAIN_FILE=../../generic-gcc-avr.cmake is parsed right after the project() call, but at this moment there are´t any variables set. Because of this the generic-gcc-avr.cmake script uses always the default values.

Steps to reproduce

1. Clean build directory
2. Run cmake
3. make (look at the file names)
4. Clean build directory
5. Change AVR_MCU to atmega16
6. Run cmake
7. make (file name suffix is still atmega8)

Possible solution 1 Move the project() call to a position downwards. (Don´t know which variables will be used by the generic-gcc file... so it could be that we need to move the project() call anywhere else ?!) e.g.

set(AVR_UPLOADTOOL avrdude)
set(AVR_PROGRAMMER avrispmkII)
set(AVR_UPLOADTOOL_PORT usb)

set(AVR_MCU atmega16)
set(AVR_H_FUSE 0xd9)
set(AVR_L_FUSE 0xc3)

project(AVR-EXAMPLE)

2 Introduce a new parameter and manually include the generic-gcc-cmake file.

This is a suggestion of getting clearer messages at the moment that the files can't be found. This helps in particular to show where the lack of finding is happening, so people can check their path.

How can I pass options to the linker? I am building a bootloader and I need to pass: -section-start=.text=0x7c00 Also, is there a way with cmake to display/log the actual compiler/linker commands being executed?

Added OSX support with AVR toolchaing installed from macports.org

• fix: avr-size args (unsupported "-C" key)
• fix: CMAKE_FIND_ROOT_PATH: /opt/local/avr

Tested in osx 10.10 with tools versions specified in README.md

Some generators throw in a try_compile() sanity check that will fail trying to link and run an exe on the host platform since this is a cross-compiler. This behavior was seen on Windows.

Since linking and running won't work with this toolchain on the host, change the CMAKE_TRY_COMPILE_TARGET_TYPE to "STATIC_LIBRARY".

This PR fixes avr_target_link_libraries. Due to a typo, using it resulted in a CMake error:

CMake Error at generic-gcc-avr.cmake:348 (target_link_libraries):
  The INTERFACE, PUBLIC or PRIVATE option must appear as the second argument,
  just after the target name.
Call Stack (most recent call first):
  CMakeLists.txt:32 (avr_target_link_libraries)

This PR fixes problems when using add_avr_executable more than once by disambiguating targets with the same name.

Currently, when adding several images, you get:

Make Error at generic-gcc-avr.cmake:224 (add_custom_target):
  add_custom_target cannot create target "upload_eeprom" because another
  target with the same name already exists.  The existing target is a custom
  target created in source directory "...".
  See documentation for policy CMP0002 for more details.

The problem was solved in several steps:

1. The target upload_eeprom was renamed upload_${EXECUTABLE_NAME}_eeprom
2. The targets get_status, get_fuses, set_fuses, get_calibration, and set_calibration were moved inside a new function, since they are stand-alone and don't depend on the executable target. The user has to explicitly call avr_generate_fixed_targets().

Please note that this PR changes the usage.

• Add additional macros for target_include_directories and target_compile_definitions
• Add identification variable AVR, which is very useful for cross-platform cmake configurations (e.g. AVR and Raspi, depending on tool chain)

• added support for setting the upload baudrate
• added baudrate parameter in get_status
• added baudrate massage
• changed the order of messages
• aligned comment-lines
• added baudrate comments
• added support for uploadtool additional parameters

The CMAKE_BUILD_TYPE MinSizeRel is currently not recognized so that the build system falls back to Release. In contrast to Release, MinSizeRel advises the compiler to optimize for size instead of speed which is particularly interesting on micro controllers. For GCC CMake will typically specify the option -Os instead of -O3.

• Added support for avr-gcc from homebrew. The current supported version is 9.3.1
• Additionally, now generates compile_commands.json for use with YouCompleteMe (a vim/vundle plugin)

I created hex-files with the help of this great repository, thanks already for this very helpful project! Now I want to upload my code to a MCU (using avrdude!?) But I haven't really exactly figured out how this would work. There seems to be some connection between cmake and avrdude, is that correct? For example there are some things set in the CMakeLists.txt like

set(AVR_UPLOADTOOL avrdude) set(AVR_PROGRAMMER avrispmkII) set(AVR_UPLOADTOOL_PORT usb)

later in the "generic-gcc-avr.cmake", these definitions are used for add_custom_target()-functions:

`

##########################################################################

avr_target_compile_definitions

Calls target_compile_definitions with AVR target names

##########################################################################

function(avr_target_compile_definitions EXECUTABLE_TARGET) if(NOT ARGN) message(FATAL_ERROR "No compile definitions to add to ${EXECUTABLE_TARGET}.") endif()

get_target_property(TARGET_LIST ${EXECUTABLE_TARGET} OUTPUT_NAME)
set(extra_args ${ARGN})

target_compile_definitions(${TARGET_LIST} ${extra_args}) endfunction()

function(avr_generate_fixed_targets)

get status

add_custom_target( get_status ${AVR_UPLOADTOOL} ${AVR_UPLOADTOOL_BASE_OPTIONS} -P ${AVR_UPLOADTOOL_PORT} -n -v COMMENT "Get status from ${AVR_MCU}" )

get fuses

add_custom_target( get_fuses ${AVR_UPLOADTOOL} ${AVR_UPLOADTOOL_BASE_OPTIONS} -P ${AVR_UPLOADTOOL_PORT} -n -U lfuse:r:-:b -U hfuse:r:-:b COMMENT "Get fuses from ${AVR_MCU}" )

set fuses

add_custom_target( set_fuses ${AVR_UPLOADTOOL} ${AVR_UPLOADTOOL_BASE_OPTIONS} -P ${AVR_UPLOADTOOL_PORT} -U lfuse:w:${AVR_L_FUSE}:m -U hfuse:w:${AVR_H_FUSE}:m COMMENT "Setup: High Fuse: ${AVR_H_FUSE} Low Fuse: ${AVR_L_FUSE}" )

get oscillator calibration

add_custom_target( get_calibration ${AVR_UPLOADTOOL} ${AVR_UPLOADTOOL_BASE_OPTIONS} -P ${AVR_UPLOADTOOL_PORT} -U calibration:r:${AVR_MCU}_calib.tmp:r COMMENT "Write calibration status of internal oscillator to ${AVR_MCU}_calib.tmp." )

set oscillator calibration

add_custom_target( set_calibration ${AVR_UPLOADTOOL} ${AVR_UPLOADTOOL_BASE_OPTIONS} -P ${AVR_UPLOADTOOL_PORT} -U calibration:w:${AVR_MCU}_calib.hex COMMENT "Program calibration status of internal oscillator from ${AVR_MCU}_calib.hex." ) endfunction()

`

but what is happening here exactly? Could anyone elaborate or point me to to the documentation for these details? Also, as stated in the topic, how does this cmake-avr interact with avrdude or some other mechanisms to upload the code to my mcu?

This should fix problem with file location when building in customdirectory. Add frequency speed into compiler flags. Unless variable is cache, they should be lower_case. But if required, I can change it to UPPER_CASE.

First of all, thank you for this project, it's really nice.

Would like to ask if it's any development towards, a custom target that runs ie. simavr, and connect to it, without to running it on every compile. I find tedious to make && simavr -t ... & and in other window / tab avr-gdb file foo and inside gdb target remote localhost:port.

If there are none, I did a little modification in the code to do this automatically, and it could be modified to work with other ie. simulavr, avarice... I could pull request it for your review, if it's fine.

When I use find_package(C_LIB c) for my (atmega128) project, I get the wrong /usr/lib/avr/lib/libc.a when I require /usr/lib/avr/lib/avr51/libc.a. Is there a way to indicate this architecture specific setting to cmake?