unity.c looking for _main

[Steve Zielinski]

I'm attempting to get Ceedling/CMock/Unity running on a PIC16LF1705 using xc8 from Microchip. 

I'm following the instructions found in Unit-testing (embedded) C applications with Ceedling [Dmitry Frank]

I'm encountering an error: 

Non line specific message: (1091) main function "_main" not defined

The line being executed is:

xc8 -O0 --CHIP=16LF1705 -c build/vendor/unity/src/unity.c 

-o"build/test/out/test_adc_handler/unity.p1" -I"C:/code/Unity/Unity-master/Unity-master/src/" -I"C:/Program Files/Microchip/xc8/v2.46/pic/include/proc/" -I"C:/Program Files/Microchip/xc8/v2.46/pic/include/c90" -I"C:/code/dimonomid/test_ceedling_example/src/appl/" -I"C:/code/dimonomid/test_ceedling_example/src/bsp/" -I"C:/code/dimonomid/test_ceedling_example/src/util/" -Wall -mlarge-code -mlarge-arrays

So it seems the while compiling "build/vendor/unity/src/unity.c" a "main" is missing.

Note: There is a "main" in Dmitry's example code.

I don't understand the error message nor how to fix it. 

In case it is helpful the complete output following "ceedling test:all" is:

C:\code\dimonomid\test_ceedling_example\test_ceedling>ceedling test:all

Ceedling set up completed in 226 milliseconds

Preparing Build Paths...

Extracting Build Directive Macros
---------------------------------
Parsing test_adc_handler.c...

Ingesting Test Configurations
-----------------------------
Collecting search paths, flags, and defines for test_adc_handler.c...

Collecting Testing Context
--------------------------
Parsing & processing #include statements within test_adc_handler.c...

Determining Files to be Generated...

Mocking
-------

Test Runners
------------
Generating runner for test_adc_handler.c...

Determining Artifacts to Be Built...

Building Objects
----------------
Compiling test_adc_handler.c...
Compiling test_adc_handler::adc_handler.c...
Compiling test_adc_handler::appl.c...
Compiling test_adc_handler::unity.c...
Compiling test_adc_handler::cmock.c...
Compiling test_adc_handler::test_adc_handler_runner.c...
ERROR: Shell command failed.
> Shell executed command:
'xc8 -O0 --CHIP=16LF1705 -c build/vendor/unity/src/unity.c -o"build/test/out/test_adc_handler/unity.p1" -I"C:/code/Unity/Unity-master/Unity-master/src/" -I"C:/Program Files/Microchip/xc8/v2.46/pic/include/proc/" -I"C:/Program Files/Microchip/xc8/v2.46/pic/include/c90" -I"C:/code/dimonomid/test_ceedling_example/src/appl/" -I"C:/code/dimonomid/test_ceedling_example/src/bsp/" -I"C:/code/dimonomid/test_ceedling_example/src/util/" -Wall -mlarge-code -mlarge-arrays'
> Produced output:
C:\Program Files\Microchip\xc8\v2.46\pic\bin\picc @C:\Users\ussz\AppData\Local\Temp\xcAs13ps.\xc8_tmp_0.cmd [ -O0 --CHIP=16LF1705 -c build/vendor/unity/src/unity.c -obuild/test/out/test_adc_handler/unity.p1 -IC:/code/Unity/Unity-master/Unity-master/src/ -IC:/Program Files/Microchip/xc8/v2.46/pic/include/proc/ -IC:/Program Files/Microchip/xc8/v2.46/pic/include/c90 -IC:/code/dimonomid/test_ceedling_example/src/appl/ -IC:/code/dimonomid/test_ceedling_example/src/bsp/ -IC:/code/dimonomid/test_ceedling_example/src/util/ -Wall -mlarge-code -mlarge-arrays ]
Microchip MPLAB XC8 C Compiler V2.46
Build date: Jan  4 2024
Part Support Version: 2.46
Copyright (C) 2024 Microchip Technology Inc.
License type: Node Configuration

legacy HI-TECH support is deprecated and will be discontinued in a future release; consult the release notes for more details
legacy C90 library is deprecated and will be discontinued in a future release; consult the release notes for more details
Non line specific message: (1091) main function "_main" not defined
(908) exit status = 1
(908) exit status = 1
> And exited with status: [1].

ShellExecutionException ==> 'Test Compiler' (xc8) exited with an error

Ceedling could not complete operations because of errors.

[Mark Vander Voord]

It sounds like you have the wrong flags for the version of the compiler you're using. It's giving you a linker error (that it can't find main) when Ceedling is attempting to ask it to just compile to an object file so that it can link with other things later? I'm not sure why else it would require all the functions to exist? Unless main is special for this compiler?

--
You received this message because you are subscribed to the Google Groups "ThrowTheSwitch Forums" group.
To unsubscribe from this group and stop receiving emails from it, send an email to throwtheswitc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/272702e1-e9a1-4c83-9e2f-4a60e999a5b2n%40googlegroups.com.

[Steve Zielinski]

OK. Got past that problem and new one emerged:

First the new issue. (Solution to the first issue is below.)

build/vendor/cmock/src/cmock.c:28:: error: (1250) could not find space (32776 bytes) for variable _CMock_Guts_Space

That seems really large and I'm not sure what to do.

Solution to the can't find _main problem:

  From the xc8 compiler manual: 

"The above example uses the command-line driver, xc8-cc, to perform the final link step. You can explicitly call the linker application, hlink, but this is not recommended as the commands are complex and when driving the linker application directly, you must specify linker options, not driver options, as shown above ."

So the trick was to present :test_linker: with the list of *.p1 files:  

:test_linker:
    :name: "Microchip XC8 Calling Compiler as The Linker"
    :executable: xc8-cc
    :arguments:
      - -mcpu=16LF1705
      - -o ${2}
      - <%= Dir.glob('build/test/out/test_bit_manipulation/*.p1').join(' ') %>

[Mark Vander Voord]

Hi Steve:

(1) are you aware that you can specify CMOCK_MEM_STATIC and CMOCK_MEM_SIZE (the first keeping disabling dynamic memory for CMock and the latter you can assign to whatever stack size you find usable. It defaults to 32k, but you can set it to whatever you like. The tradeoff being that a small stack size means a low limit on the number of calls CMock can remember for you.

(2) You can also help yourself by choosing to target the LARGEST device in the family of parts you're using. It's all the same instruction set, and your memory locations are mostly being abstracted anyway... so there's no harm in targeting a larger device than the one you're targeting for real.

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/114e7e1a-5294-45e1-be9f-16fab3d76b88n%40googlegroups.com.