Support for building RepRap v3-dev using Eclipse

NR12

Hi, I was trying to build the newly released Reprap v3-dev on Github using Eclipse and i ran into the following error:

Invoking: Cross G++ Compiler
arm-none-eabi-g++ -std=gnu++17 -D__SAM4E8E__ -DRTOS -DDUET_NG -D_XOPEN_SOURCE -I"C:\eclipse\Firmware V3\CoreNG\cores\arduino" -I"C:\eclipse\Firmware V3\CoreNG\libraries\Flash" -I"C:\eclipse\Firmware V3\CoreNG\libraries\SharedSpi" -I"C:\eclipse\Firmware V3\CoreNG\libraries\Storage" -I"C:\eclipse\Firmware V3\CoreNG\libraries\Wire" -I"C:\eclipse\Firmware V3\CoreNG\asf" -I"C:\eclipse\Firmware V3\CoreNG\asf\common\utils" -I"C:\eclipse\Firmware V3\CoreNG\asf\common\services\clock" -I"C:\eclipse\Firmware V3\CoreNG\asf\common\services\ioport" -I"C:\eclipse\Firmware V3\CoreNG\asf\sam\drivers" -I"C:\eclipse\Firmware V3\CoreNG\asf\sam\services\flash_efc" -I"C:\eclipse\Firmware V3\CoreNG\asf\sam\utils" -I"C:\eclipse\Firmware V3\CoreNG\asf\sam\utils\cmsis\sam4e\include" -I"C:\eclipse\Firmware V3\CoreNG\asf\sam\utils\header_files" -I"C:\eclipse\Firmware V3\CoreNG\asf\sam\utils\preprocessor" -I"C:\eclipse\Firmware V3\CoreNG\asf\thirdparty\CMSIS\Include" -I"C:\eclipse\Firmware V3\CoreNG\variants\duetNG" -I"C:\eclipse\Firmware V3\RepRapFirmware\src" -I"C:\eclipse\Firmware V3\RepRapFirmware\src\DuetNG" -I"C:\eclipse\Firmware V3\RepRapFirmware\src\Networking" -I"C:\eclipse\Firmware V3\DuetWiFiSocketServer\src\include" -I"C:\eclipse\Firmware V3\FreeRTOS\src\include" -I"C:\eclipse\Firmware V3\FreeRTOS\src\portable\GCC\ARM_CM4F" -I"C:\eclipse\Firmware V3\RRFLibraries\src" -O2 -Wall -c -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -ffunction-sections -fdata-sections -fno-threadsafe-statics -fno-rtti -fno-exceptions -nostdlib -Wdouble-promotion -fsingle-precision-constant "-Wa,-ahl=NetworkBuffer.s" -MMD -MP -MF"src/Networking/NetworkBuffer.d" -MT"src/Networking/NetworkBuffer.o" -o "src/Networking/NetworkBuffer.o" "../src/Networking/NetworkBuffer.cpp"
../src/Networking/W5500Ethernet/Wiznet/Ethernet/WizSpi.cpp: In function 'void WizSpi::Init()':
../src/Networking/W5500Ethernet/Wiznet/Ethernet/WizSpi.cpp:195:16: error: invalid initialization of reference of type 'const PinDescription&' from expression of type 'const Pin' {aka 'const unsigned char'}
ConfigurePin(APIN_SPI_SCK);
^~~~~~~~~~~~
In file included from C:\eclipse\Firmware V3\CoreNG\cores\arduino/Core.h:203,
from C:\eclipse\Firmware V3\RepRapFirmware\src/RepRapFirmware.h:33,
from ../src/Networking/W5500Ethernet/Wiznet/Ethernet/WizSpi.h:11,
from ../src/Networking/W5500Ethernet/Wiznet/Ethernet/WizSpi.cpp:8:
C:\eclipse\Firmware V3\CoreNG\variants\duetNG/variant.h:167:13: note: in passing argument 1 of 'void ConfigurePin(const PinDescription&)'
extern void ConfigurePin(const PinDescription& pinDesc);

Got the same error for all the 4 pin descriptions for SPI, followed by

src/Networking/W5500Ethernet/Wiznet/Ethernet/subdir.mk:24: recipe for target 'src/Networking/W5500Ethernet/Wiznet/Ethernet/WizSpi.o' failed
make: *** [src/Networking/W5500Ethernet/Wiznet/Ethernet/WizSpi.o] Error 1
make: *** Waiting for unfinished jobs....

Is there a simple fix by just changing the variable type or is it something more that i might be overloooking?

Thanks

gtj0

I can't check at the moment but are you using the v3-dev branch of CoreNG?

NR12

ah, that was it. i followed the build instructions for 2.03, didn't realize they weren't updated for V3.
thanks.

dc42

The v3 branch of the RepRapFirmware project now uses the dev branch of CoreNG again. But I ported the v3 changes in CoreNG to the dev branch only a few days ago, so I expect you didn't have the latest commits.

gtj0

@dc42 Ha! Thought of using git submodules to lock branches across projects?

dc42

As I understand it, git submodules only allow hierarchical dependencies between projects. The CoreNG project is used by both RepRapFirmware and DuetIAP. Likewise, the FreeRTOS and RRFLibraries projects are used by RepRapFirmware and Duet3Expansion. So a hierarchical structure in Git won't work. However, I've never used submodules, so I could be wrong. What I try to do instead is to keep all development branches of my projects using the dev branches of CoreNG and RRFLibraries - which is why I recently merged the v3-dev branch of CoreNG into the dev branch.

gtj0

We use submodules extensively at the "day job" explicitly to lock branches together. In fact, you can actually tie commits/branches/tags together so if the RRF 3.0.0-beta1 tag needs the CoreNG v3-dev branch at a certain point in time, you can do that. When you checkout RRF 3.0.0-beta1 you can do a git submodule update and it will automatically check out CoreNG (and any other submodules) at the appropriate commit.

It's probably overkill here though, as long as you don't keep messing with the branches.

NR12

@dc42 Yeah, I guess that makes sense. I did get a build done after I downloaded CoreNG-dev3 yesterday.