Posts made by trayracing

@dc42 Thanks. The ctl_access.h problem was from outdated arm tools on my end.

Thanks @dc42. That commit, locally defining SAME5x=0, and the local change to ctl_access.h got me building again.

@trayracing said in Build troubles - 3.02 for DuetWifi:

STRINGLIST_tan

Right, that one is came in with ce3b93cd737f34c9206d6c42e3d277676c7f1f58, dc42
28 Aug, which looks like an update to NamedEnum.h over in RRFLibraries might not be committed.

Looks like it's probably from

#include <Core.h>

being inside the

extern "C" {

in Src/Libraries/sd_mmc/ctl_access.h. Can anyone confirm that?
Moving the include up gets rid of most, but not all the errors. If so, it's been broken since at least 10 July, which seems unlikely.
Also seems strange that I'm running into so many different errors. Was there a tools change that I'm missing? Is no one building Duet2 any more?

Last error seems to be:

In file included from C:\Users\JARK\Repos\RepRapFirmware\src/GCodes/GCodeMachineState.h:14,
                 from ../src/GCodes/GCodeBuffer/StringParser.h:13,
                 from ../src/GCodes/GCodeBuffer/GCodeBuffer.h:12,
                 from ../src/GCodes/GCodeBuffer/ExpressionParser.cpp:10:
C:\Users\JARK\Repos\RRFLibraries\src/General/NamedEnum.h:19:38: error: 'STRINGLIST_tan' was not declared in this scope
 #define STRINGLIST( ... ) VA_SELECT( STRINGLIST, __VA_ARGS__ )
                                      ^~~~~~~~~~
C:\Users\JARK\Repos\RRFLibraries\src/General/NamedEnum.h:12:21: note: in definition of macro 'CAT'
 #define CAT( A, B ) A ## B
                     ^
C:\Users\JARK\Repos\RRFLibraries\src/General/NamedEnum.h:16:32: note: in expansion of macro 'SELECT'
 #define VA_SELECT( NAME, ... ) SELECT( NAME, VA_SIZE(__VA_ARGS__) )(__VA_ARGS__)
                                ^~~~~~
C:\Users\JARK\Repos\RRFLibraries\src/General/NamedEnum.h:19:27: note: in expansion of macro 'VA_SELECT'
 #define STRINGLIST( ... ) VA_SELECT( STRINGLIST, __VA_ARGS__ )
                           ^~~~~~~~~
C:\Users\JARK\Repos\RRFLibraries\src/General/NamedEnum.h:86:53: note: in expansion of macro 'STRINGLIST'
  static constexpr const char* _names[NumValues] = { STRINGLIST(_v1, __VA_ARGS__) }; \
                                                     ^~~~~~~~~~
../src/GCodes/GCodeBuffer/ExpressionParser.cpp:19:1: note: in expansion of macro 'NamedEnum'
 NamedEnum(Function, unsigned int, abs, acos, asin, atan, atan2, cos, degrees, floor, isnan, max, min, mod, radians, random, sin, sqrt, tan);
 ^~~~~~~~~
C:\Users\JARK\Repos\RRFLibraries\src/General/NamedEnum.h:19:38: note: suggested alternative: 'STRINGLIST_14'
 #define STRINGLIST( ... ) VA_SELECT( STRINGLIST, __VA_ARGS__ )
                                      ^~~~~~~~~~
C:\Users\JARK\Repos\RRFLibraries\src/General/NamedEnum.h:12:21: note: in definition of macro 'CAT'
 #define CAT( A, B ) A ## B
                     ^
C:\Users\JARK\Repos\RRFLibraries\src/General/NamedEnum.h:16:32: note: in expansion of macro 'SELECT'
 #define VA_SELECT( NAME, ... ) SELECT( NAME, VA_SIZE(__VA_ARGS__) )(__VA_ARGS__)
                                ^~~~~~
C:\Users\JARK\Repos\RRFLibraries\src/General/NamedEnum.h:19:27: note: in expansion of macro 'VA_SELECT'
 #define STRINGLIST( ... ) VA_SELECT( STRINGLIST, __VA_ARGS__ )
                           ^~~~~~~~~
C:\Users\JARK\Repos\RRFLibraries\src/General/NamedEnum.h:86:53: note: in expansion of macro 'STRINGLIST'
  static constexpr const char* _names[NumValues] = { STRINGLIST(_v1, __VA_ARGS__) }; \
                                                     ^~~~~~~~~~
../src/GCodes/GCodeBuffer/ExpressionParser.cpp:19:1: note: in expansion of macro 'NamedEnum'
 NamedEnum(Function, unsigned int, abs, acos, asin, atan, atan2, cos, degrees, floor, isnan, max, min, mod, radians, random, sin, sqrt, tan);
 ^~~~~~~~~

@Veti said in Build troubles - 3.02 for DuetWifi:

why are you using 3.0.2? and not 3.1.2?

edit: my bad you said 3.02

That's actually a worthwhile question. I went there because that's where the recent commits are. Ideally, there'd be a spot to go to that identifies the active branch, with up-to-date build instructions for that branch, including what branches of other repos are needed. (Sub modules are a way to manage that, but for now, I'd just like to be able to build.)

Build trouble on the 3.02 branch for DuetWifi. Last successful merge was from 10 June, AFAICT.
The problem is something about templates with extern linkage. Partial error log at end.
Build RepRapFirmware with the Duet2 config (hoping that's the right one for DuetWifi) using 2018-q4-major.

I had to work around a few other problems:

• Needed dev branch (not main) of FreeRTOS to build CANlib. (BuildInstructions.md is out of date on 3.02 branch.)
• Building RepRapFirmware, got errors about SAME5x not set for configuration Duet2. (Worked around this by setting SAME5x=0)

=======================================================================
arm-none-eabi-g++ -std=gnu++17 -D__SAM4E8E__ -DRTOS -DDUET_NG -D_XOPEN_SOURCE -DSAME5x=0 -I"C:\Users\JARK\Repos\RRFLibraries" -I"C:\Users\JARK\Repos\FreeRTOS" -I"C:\Users\JARK\Repos\CoreNG" -I"C:\Users\JARK\Repos\CoreNG\cores\arduino" -I"C:\Users\JARK\Repos\CoreNG\libraries\Flash" -I"C:\Users\JARK\Repos\CoreNG\libraries\Wire" -I"C:\Users\JARK\Repos\CoreNG\asf" -I"C:\Users\JARK\Repos\CoreNG\asf\common\utils" -I"C:\Users\JARK\Repos\CoreNG\asf\common\services\clock" -I"C:\Users\JARK\Repos\CoreNG\asf\common\services\ioport" -I"C:\Users\JARK\Repos\CoreNG\asf\sam\drivers" -I"C:\Users\JARK\Repos\CoreNG\asf\sam\services\flash_efc" -I"C:\Users\JARK\Repos\CoreNG\asf\sam\utils" -I"C:\Users\JARK\Repos\CoreNG\asf\sam\utils\cmsis\sam4e\include" -I"C:\Users\JARK\Repos\CoreNG\asf\sam\utils\header_files" -I"C:\Users\JARK\Repos\CoreNG\asf\sam\utils\preprocessor" -I"C:\Users\JARK\Repos\CoreNG\asf\thirdparty\CMSIS\Include" -I"C:\Users\JARK\Repos\CoreNG\variants\duetNG" -I"C:\Users\JARK\Repos\RepRapFirmware\src" -I"C:\Users\JARK\Repos\RepRapFirmware\src\DuetNG" -I"C:\Users\JARK\Repos\RepRapFirmware\src\Networking" -I"C:\Users\JARK\Repos\DuetWiFiSocketServer\src\include" -I"C:\Users\JARK\Repos\FreeRTOS\src\include" -I"C:\Users\JARK\Repos\FreeRTOS\src\portable\GCC\ARM_CM4F" -I"C:\Users\JARK\Repos\RRFLibraries\src" -Os -Wall -c -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -ffunction-sections -fdata-sections -fno-threadsafe-statics -fno-rtti -fexceptions -nostdlib -Wundef -Wdouble-promotion -Werror=return-type -fsingle-precision-constant "-Wa,-ahl=DhtSensor.s" -fstack-usage -MMD -MP -MF"src/Heating/Sensors/DhtSensor.d" -MT"src/Heating/Sensors/DhtSensor.o" -o "src/Heating/Sensors/DhtSensor.o" "../src/Heating/Sensors/DhtSensor.cpp"

In file included from C:\Users\JARK\Repos\CoreNG\cores\arduino/RingBuffer.h:23,
from C:\Users\JARK\Repos\CoreNG\cores\arduino/UARTClass.h:23,
from C:\Users\JARK\Repos\CoreNG\variants\duetNG/variant.h:43,
from C:\Users\JARK\Repos\CoreNG\cores\arduino/Core.h:190,
from C:\Users\JARK\Repos\RepRapFirmware\src/Libraries/sd_mmc/ctrl_access.h:76,
from ../src/Libraries/Fatfs/diskio.cpp:47:
c:\program files (x86)\gnu tools arm embedded\8 2018-q4-major\arm-none-eabi\include\c++\8.2.1\cstddef:68:3: error: template with C linkage
template<typename _IntegerType> struct __byte_operand { };
^~~~~~~~
In file included from ../src/Libraries/Fatfs/diskio.cpp:47:
C:\Users\JARK\Repos\RepRapFirmware\src/Libraries/sd_mmc/ctrl_access.h:64:1: note: 'extern "C"' linkage started here
extern "C" {
^~~~~~~~~~
In file included from C:\Users\JARK\Repos\CoreNG\cores\arduino/RingBuffer.h:23,
from C:\Users\JARK\Repos\CoreNG\cores\arduino/UARTClass.h:23,
from C:\Users\JARK\Repos\CoreNG\variants\duetNG/variant.h:43,
from C:\Users\JARK\Repos\CoreNG\cores\arduino/Core.h:190,
from C:\Users\JARK\Repos\RepRapFirmware\src/Libraries/sd_mmc/ctrl_access.h:76,
from ../src/Libraries/Fatfs/diskio.cpp:47:
c:\program files (x86)\gnu tools arm embedded\8 2018-q4-major\arm-none-eabi\include\c++\8.2.1\cstddef:69:3: error: template specialization with C linkage
template<> struct __byte_operand<bool> { using __type = byte; };
^~~~~~~~
In file included from ../src/Libraries/Fatfs/diskio.cpp:47:
C:\Users\JARK\Repos\RepRapFirmware\src/Libraries/sd_mmc/ctrl_access.h:64:1: note: 'extern "C"' linkage started here
extern "C" {
^~~~~~~~~~
In file included from C:\Users\JARK\Repos\CoreNG\cores\arduino/RingBuffer.h:23,
from C:\Users\JARK\Repos\CoreNG\cores\arduino/UARTClass.h:23,
from C:\Users\JARK\Repos\CoreNG\variants\duetNG/variant.h:43,
from C:\Users\JARK\Repos\CoreNG\cores\arduino/Core.h:190,
from C:\Users\JARK\Repos\RepRapFirmware\src/Libraries/sd_mmc/ctrl_access.h:76,
from ../src/Libraries/Fatfs/diskio.cpp:47:
c:\program files (x86)\gnu tools arm embedded\8 2018-q4-major\arm-none-eabi\include\c++\8.2.1\cstddef:70:3: error: template specialization with C linkage
template<> struct __byte_operand<char> { using __type = byte; };
^~~~~~~~

Re: crc32appender now needed for RRF?

The BuildInstructions file on the dev branch is missing the setup instructions on windows for crc32appender, which is needed on the v3.02-dev branch.

Something like:
Add the RepRepFirmware/Tools subdirectory for your platform to the PATH environment variable. This allows the build process to find the crc32appender tool. You can do this in Eclipse in the "Window->Preferences->C++->Build->Environment"
dialog. Click "Add..." and add PATH as the variable. For the value, use the path to the directory. If you've been following these directions closely on Windows, this would be "C:\Eclipse\Firmware\RepRapFirmware\Tools\crc32appender\win-x86_64". Ensure "Append variables to environment" is selected before clicking "Apply and Close"

Thanks @dc42

Thanks. Which branch's build instructions should I follow? The dev branch instructions mention v3, and v3.02-dev build instructions look older.

Is there a page that describes which branch is best for a given purpose? I'm looking to implement some new kinematics with a Duet 2 Wifi. Which branch should I be starting from at this point? Thanks

No spaces in my path. It is on a different drive, due to available disk space, and the path is a bit longer.

I ran into linking problems on windows where the path for flash.ld was converted to backslashes by Eclipse, and then the backslashes stripped as it was handed to the linker.

I was able to work around this by adding html quotes in the .cproject, modifying:
-T ${workspace_loc:/${CoreName}/variants/duetNG/linker_scripts/gcc/flash.ld}
to:
-T&quot;${workspace_loc:/${CoreName}/variants/duetNG/linker_scripts/gcc/flash.ld}&quot;
I had to enquote the map path as well.

While having quotation marks seems quite reasonable, it seems strange to me that this isn't broken for other people as well. I am using Eclipse oxygen, as the build instructions direct. Building otherwise appears successful - should I be concerned?

Hi. My Duet wifi just arrived. Build quality looks very nice, except the power connector wasn't fully inserted before soldering. This makes it mechanically vulnerable to cracked traces down the road. Easy enough to fix up front with a soldering iron. Mostly wanted to give your assembly team an alert, as well as any owners out there.