search

ThrowTheSwitch / Ceedling

Ruby-based unit testing and build system for C projects
http://throwtheswitch.org
Other
597 stars 246 forks source link

:tools: :compiler: avr-gcc target #492

Open karbiuch opened 4 years ago

karbiuch commented 4 years ago

My settings:

I created a small project with files (cmd: ceedling new P1): src/p1.c and src/p1.h test/test_p1.c

p1.h: in SRC folder
-------
#ifndef __P1_H
#define __P1_H
#define F_CPU 8000000
#define MCU atmega328p
#include <avr/io.h>
#endif // P1_H

p1.c: in SRC folder

#include "p1.h"
int main(void) 
{
        DDRB = 0xFF; //<avr/io.h>
        PORTB ^= 0xFF; //<avr/io.h>
        while(1) 
    {   
        }
}
test_p1: in TEST folder
-------
#include "unity.h"
#include "p1.h"
#include "mock_io.h"

void setUp(void){}
void tearDown(void){}

void test_p1_NeedToImplement(void)
{
    TEST_IGNORE_MESSAGE("Need to Implement p1");
}

When I test avr-gcc with terminal everything is ok: cd /cygdrive/d/Ceedling/Pro1/src avr-gcc -mmcu=atmega328 -Os -g p1.c -o p1.elf AVR-GCC compiler is working.

But when I use ceedling I have strange problem. Ceedling is using wrong compiler. Example:

Test 'test_p1.c'

C:/Program Files (x86)/Atmel/Studio/7.0/toolchain/avr8/avr8-gnu-toolchain/avr/include/avr/io.h:623:6: warning: #warning "device type not defined" [-Wcpp] 623 | # warning "device type not defined" | ^~~ In file included from src/p1.h:6, from test/test_p1.c:3: C:/Program Files (x86)/Atmel/Studio/7.0/toolchain/avr8/avr8-gnu-toolchain/avr/include/avr/io.h:623:6: warning: #warning "device type not defined" [-Wcpp] 623 | # warning "device type not defined" | ^~~ Linking test_p1.out... /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld: build/test/out/c/p1.o: in function main': p1.c:(.text.startup+0x0): multiple definition ofmain'; build/test/out/c/test_p1_runner.o:/cygdrive/d/Ceedling/Pro1/build/test/runners/test_p1_runner.c:81: first defined here /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld: avr:5 architecture of input file build/test/out/c/p1.o' is incompatible with i386:x86-64 output /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld: build/test/out/c/unity.o:unity.c:(.rdata$.refptr.__iob[.refptr.__iob]+0x0): undefined reference to__iob' collect2: error: ld returned 1 exit status ERROR: Shell command failed.

Shell executed command: 'gcc "build/test/out/c/test_p1_runner.o" "build/test/out/c/test_p1.o" "build/test/out/c/mock_io.o" "build/test/out/c/unity.o" "build/test/out/c/p1.o" "build/test/out/c/cmock.o" -o "build/test/out/test_p1.out"' And exited with status: [1].

NOTICE: If the linker reports missing symbols, the following may be to blame:

  1. Test lacks #include statements corresponding to needed source files.
  2. Project search paths do not contain source files corresponding to #include statements in the test.
  3. Test does not #include needed mocks.

rake aborted!

Ceedling is trying use the gcc compiler instead of avr-gcc. I found the similar issue: https://github.com/ThrowTheSwitch/Ceedling/issues/209 I was trying to use that project.yml but still, ceedling doesn't work. So i wrote my one project.yml:

My project.yml:

Notes:

Sample project C code is not presently written to produce a release artifact.

As such, release build options are disabled.

This sample, therefore, only demonstrates running a collection of unit tests.

:project: :use_exceptions: FALSE :use_test_preprocessor: TRUE :use_auxiliary_dependencies: TRUE :build_root: build :release_build: TRUE :test_fileprefix: test :which_ceedling: gem :ceedling_version: 0.30.0 :default_tasks:

:test_build:

:use_assembly: TRUE

:release_build:

:output: MyApp.out

:use_assembly: FALSE

:environment:

:extension: :executable: .out

:paths: :test:

:defines:

in order to add common defines:

1) remove the trailing [] from the :common: section

2) add entries to the :common: section (e.g. :test: has TEST defined)

:common: &common_defines [] :test:

:cmock: :mockprefix: mock :when_no_prototypes: :warn :enforce_strict_ordering: TRUE :plugins:

Add -gcov to the plugins list to make sure of the gcov plugin

You will need to have gcov and gcovr both installed to make it work.

For more information on these options, see docs in plugins/gcov

:gcov: :reports:

:tools: :compiler: :executable: avr-gcc :arguments:

:tools:

Ceedling defaults to using gcc for compiling, linking, etc.

As [:tools] is blank, gcc will be used (so long as it's in your system path)

See documentation to configure a given toolchain for use

LIBRARIES

These libraries are automatically injected into the build process. Those specified as

common will be used in all types of builds. Otherwise, libraries can be injected in just

tests or releases. These options are MERGED with the options in supplemental yaml files.

:libraries: :placement: :end :flag: "${1}" # or "-L ${1}" for example :common: &common_libraries [] :test:

:plugins: :load_paths:

How to fix it ? What am I doing wrong ? I don't wanna use old WinAvr or Arduino. I would like to use a new version of avr-gcc. Please help.

mvandervoord commented 4 years ago

Your yaml file is pretty mangled in your post, so it's a bit hard to tell if you have all the formatting correct. It's strange that you have a both :compiler and :test_compiler under :tools. The former is doing nothing, I suspect.

I also note that you don't have a :test_linker specified, which is why it's defaulting to using the first gcc that it finds when it goes to link, and explains why the linker is complaining about the wrong object types.

It sounds like you're saying that it's also pulling in the wrong avr-gcc executable. That must mean you have both in your default path. If that's the case, you can manually change the path yourself, or you can have ceedling do it for you with :environment settings, or (probably easiest, but not very portable) you can just specify the tool with the full or relative path.

Finally, if you're going to cross compile like this, instead of building native tests (a more common approach), it means that you are going to need to specify a test_fixture as well... a simulator upon which to run these lovely tests you're building.