V2 Build problem

kazolar · 2 Dec 2018, 07:31

Moving from V1 to V2 -- I switched over all the projects, Core builds fine, RTOS builds fine, when I get to the main firmware, I'm getting -- odd errors

In file included from c:\program files (x86)\gnu tools arm embedded\7 2018-q2-update\arm-none-eabi\include\c++\7.3.1\bits\specfun.h:45:0,
from c:\program files (x86)\gnu tools arm embedded\7 2018-q2-update\arm-none-eabi\include\c++\7.3.1\cmath:1914,
from c:\program files (x86)\gnu tools arm embedded\7 2018-q2-update\arm-none-eabi\include\c++\7.3.1\math.h:36,
from C:\eclipse\Firmware\CoreNG\cores\arduino/Core.h:31,
from C:\eclipse\Firmware\RepRapFirmware\src/RepRapFirmware.h:31,
from ../src/Tools/Tool.h:29,
from ../src/Tools/Filament.cpp:8:
c:\program files (x86)\gnu tools arm embedded\7 2018-q2-update\arm-none-eabi\include\c++\7.3.1\bits\stl_algobase.h:243:56: error: macro "min" passed 3 arguments, but takes just 2
min(const _Tp& __a, const _Tp& __b, _Compare __comp)
^
c:\program files (x86)\gnu tools arm embedded\7 2018-q2-update\arm-none-eabi\include\c++\7.3.1\bits\stl_algobase.h:265:56: error: macro "max" passed 3 arguments, but takes just 2
max(const _Tp& __a, const _Tp& __b, _Compare __comp)
^
In file included from c:\program files (x86)\gnu tools arm embedded\7 2018-q2-update\arm-none-eabi\include\c++\7.3.1\bits\specfun.h:46:0,
from c:\program files (x86)\gnu tools arm embedded\7 2018-q2-update\arm-none-eabi\include\c++\7.3.1\cmath:1914,
from c:\program files (x86)\gnu tools arm embedded\7 2018-q2-update\arm-none-eabi\include\c++\7.3.1\math.h:36,
from C:\eclipse\Firmware\CoreNG\cores\arduino/Core.h:31,
from C:\eclipse\Firmware\RepRapFirmware\src/RepRapFirmware.h:31,
from ../src/Tools/Tool.h:29,
from ../src/Tools/Filament.cpp:8:
c:\program files (x86)\gnu tools arm embedded\7 2018-q2-update\arm-none-eabi\include\c++\7.3.1\limits:317:11: error: macro "min" requires 2 arguments, but only 1 given
min() _GLIBCXX_USE_NOEXCEPT { return _Tp(); }

c:\program files (x86)\gnu tools arm embedded\7 2018-q2-update\arm-none-eabi\include\c++\7.3.1\bits\stl_algobase.h:829:12: note: suggested alternative:
In file included from c:\program files (x86)\gnu tools arm embedded\7 2018-q2-update\arm-none-eabi\include\c++\7.3.1\cmath:42:0,
from c:\program files (x86)\gnu tools arm embedded\7 2018-q2-update\arm-none-eabi\include\c++\7.3.1\math.h:36,
from C:\eclipse\Firmware\CoreNG\cores\arduino/Core.h:31,
from C:\eclipse\Firmware\RepRapFirmware\src/RepRapFirmware.h:31,
from C:\eclipse\Firmware\RepRapFirmware\src\Networking/Network.h:12,
from C:\eclipse\Firmware\RepRapFirmware\src\Networking/NetworkInterface.h:11,
from ../src/Networking/W5500Ethernet/W5500Interface.h:12,
from ../src/Networking/W5500Ethernet/W5500Interface.cpp:8:
Did I miss something?

dc42 · 2 Dec 2018, 10:12

Are you using the correct branch of CoreNg, i.e. /main ? https://github.com/dc42/RepRapFirmware/blob/dev/BuildInstructions.md

kazolar · 2 Dec 2018, 15:11

I see master, and v2-dev, I don't see main, tried master again, and it worked. Thought I already did...brr

kazolar · 2 Dec 2018, 15:58

I had the code working to add 2 more drives in v1 -- and I ported everything over to v2, but the 2 more drives are not showing up. No errors, I have pins configured, but I need to get 10 axes to work, and in machine properties I am now not seeing the 2 more drives I added.

kazolar · 2 Dec 2018, 19:04

I think I got it sorted....Gcode3.cpp had a list of valid letters for axes -- I missed that porting over from V1 to V2.
Also how end stop arrays are used appears different -- pins 97,98,99 -- are assigned as end stops then are not technically used as end stops with Duex5, in V1 -- I could re-appropriate them for enable/direction pins for extra drives, but in V2 they get pulled which ever way (not sure) and then I can't address them -- assigning those end stops in the array to NoPin fixes it -- though it's odd that they get used for any purpose since they were not in V1 firmware.

dc42 · 2 Dec 2018, 23:15

The pins for endstop inputs 5 through 9 get reassigned if a DueX2 or DueX5 is detected.

kazolar · 3 Dec 2018, 17:23

@dc42 that wasn't working the same way in v2 firmware as it was in v1 (I was on 1.21 source prior to migrating over to v2) -- I had to set to the values in the arrays as NoPin during the migration -- it had no impact on the end stops since they do get assigned, but it cleared up those pins to be used freely for other purposes. In v2, something is pulling them in high/low (not sure) before it reassigns them -- I wonder if this will impact thermal couple usage with Duex boards.

dc42 · 3 Dec 2018, 17:28

The initialisation in Platform.cpp enables the pullup resistors on all pins that the firmware supports as SPI CS pins.