Vielen Danke jetzt weiß ich schon etwas mehr.
dann muss ich mich an Eclipse ran tasten.
Danke noch mal

Ok, it all works

I had to add the PATH in Eclipse.

Project > Properties > C/C++ Build > Environment

Not sure why I had to do that, since the application is accessible in a terminal window

@jml nevermind - I had to sign in in order for github to show Code results. Thanks!
(is there a way to mark this post solved?)

If this form of gcode parameter is generally adopted, it would give a wider range of uses. For example, you could pass a structure that includes a set of parameters and return values. As to me, this form is quite natural and corresponds to the usual way of passing a variable by reference. If I'm not mistaken, the current gcode interface and implementation of meta variables allow this without difficulty.

@dc42 Yes, i added ${EXTRA_FLAGS} in linker command but it did not fix the issue.

I'm having a similar issue, noting that we have to build picosdk, I followed the instructions linked above and I continually get this error (amongst others) but I'll start here...

I should have the pre-reqs done and when I run make-libpico.bat I get errors:

C:\Users\Chris Thompson\git\CoreN2G\src\RP2040\Tools\Build-pico-sdk>make-libpico.bat C:\Users\Chris Thompson\git\CoreN2G\src\RP2040\Tools\Build-pico-sdk>rmdir /S /Q build The system cannot find the file specified. C:\Users\Chris Thompson\git\CoreN2G\src\RP2040\Tools\Build-pico-sdk>mkdir build C:\Users\Chris Thompson\git\CoreN2G\src\RP2040\Tools\Build-pico-sdk>cd build C:\Users\Chris Thompson\git\CoreN2G\src\RP2040\Tools\Build-pico-sdk\build>cmake .. -DIPV6=0 -G "MSYS Makefiles" PICO_SDK_PATH is C:/Users/Chris Thompson/git/CoreN2G/src/RP2040/pico-sdk Defaulting PICO_PLATFORM to rp2040 since not specified. Defaulting PICO platform compiler to pico_arm_gcc since not specified. -- Defaulting build type to 'Release' since not specified. PICO compiler is pico_arm_gcc -- The C compiler identification is GNU 10.3.1 -- The CXX compiler identification is GNU 10.3.1 -- The ASM compiler identification is GNU -- Found assembler: C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2021.10/bin/arm-none-eabi-gcc.exe Build type is RelWithDebInfo PICO target board is pico. Using board configuration from C:/Users/Chris Thompson/git/CoreN2G/src/RP2040/pico-sdk/src/boards/include/boards/pico.h -- Found Python3: C:/msys64/usr/bin/python3.10.exe (found version "3.10.9") found components: Interpreter TinyUSB available at C:/Users/Chris Thompson/git/CoreN2G/src/RP2040/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; enabling build support for USB. cyw43-driver available at C:/Users/Chris Thompson/git/CoreN2G/src/RP2040/pico-sdk/lib/cyw43-driver lwIP available at C:/Users/Chris Thompson/git/CoreN2G/src/RP2040/pico-sdk/lib/lwip -- Configuring done -- Generating done -- Build files have been written to: C:/Users/Chris Thompson/git/CoreN2G/src/RP2040/Tools/Build-pico-sdk/build C:\Users\Chris Thompson\git\CoreN2G\src\RP2040\Tools\Build-pico-sdk\build>set OLDPATH=C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Program Files\PuTTY\;C:\Program Files\Microchip\xc8\v2.36\bin;C:\Program Files\Git\cmd;C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin;C:\Program Files\GNU ARM Eclipse\Build Tools\2.6-201507152002\bin;C:\Users\Chris Thompson\AppData\Local\Microsoft\WindowsApps;C:\msys64\mingw64\bin;C:\msys64\usr\bin C:\Users\Chris Thompson\git\CoreN2G\src\RP2040\Tools\Build-pico-sdk\build>PATH C:\msys64\usr\bin;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Program Files\PuTTY\;C:\Program Files\Microchip\xc8\v2.36\bin;C:\Program Files\Git\cmd;C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin;C:\Program Files\GNU ARM Eclipse\Build Tools\2.6-201507152002\bin;C:\Users\Chris Thompson\AppData\Local\Microsoft\WindowsApps;C:\msys64\mingw64\bin;C:\msys64\usr\bin C:\Users\Chris Thompson\git\CoreN2G\src\RP2040\Tools\Build-pico-sdk\build>c:\msys64\usr\bin\make -j [[ 2 %2]% ] CreBautiilndgi ndgi rAeScMt oorbijeesc tf opri c'o-Psidoka/ssmrBcu/irlpd2'_c ommon/boot_stage2/CMakeFiles/bs2_default.dir/compile_time_choice.S.obj [ 3%] Linking ASM executable bs2_default.elf [ 4%] No download step for 'PioasmBuild' [ 5%] No update step for 'PioasmBuild' [ 5%] Built target bs2_default [ 6%] No patch step for 'PioasmBuild' [ 7%] Generating bs2_default.bin [ 8%] Performing configure step for 'PioasmBuild' [ 10%] Generating bs2_default_padded_checksummed.S loading initial cache file C:/Users/Chris Thompson/git/CoreN2G/src/RP2040/Tools/Build-pico-sdk/build/pico-sdk/src/rp2_common/cyw43_driver/pioasm/tmp/PioasmBuild-cache-RelWithDebInfo.cmake /C/msys64/usr/bin/python3.10: can't open file '/C/Users/Chris Thompson/git/CoreN2G/src/RP2040/Tools/Build-pico-sdk/build/pico-sdk/src/rp2_common/boot_stage2/C:/Users/Chris Thompson/git/CoreN2G/src/RP2040/pico-sdk/src/rp2_common/boot_stage2/pad_checksum': [Errno 2] No such file or directory make[2]: *** [pico-sdk/src/rp2_common/boot_stage2/CMakeFiles/bs2_default_padded_checksummed_asm.dir/build.make:73: pico-sdk/src/rp2_common/boot_stage2/bs2_default_padded_checksummed.S] Error 2 make[1]: *** [CMakeFiles/Makefile2:1460: pico-sdk/src/rp2_common/boot_stage2/CMakeFiles/bs2_default_padded_checksummed_asm.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... -- The CXX compiler identification is GNU 11.3.0 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: C:/msys64/usr/bin/c++.exe - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: C:/Users/Chris Thompson/git/CoreN2G/src/RP2040/Tools/Build-pico-sdk/build/pioasm [ 11%] Performing build step for 'PioasmBuild' [ 10[% ] 2[0B%u ]i3 l0[Bd %[ui5nil ]g0 [ %]5 6 0%C0BBd]X%uui X]iinB ldguolBi nbduiCgjiinX ClldXX dXioeig nbcn ogjt Cb eg CXCcjXXXt C oXMb ajokebecjFtei clCteM saC/keFiMplCeXaies/pkoMc ieasm.oFdaii[rls /mt 7age.o[C0kedsb M%eni/j8a]F/rpe0k ip/ic%elBagot]Feurea isisnsCl/Ble/mMepudrl.asiii.edk/eldcxiopaiiperFnsonpr/igmag..cl .s oCbeCdmc_XjsXi.psX /Xrdpd p /i.koiomro_boba/bpjasimji jno.ueoe.[dtc_cc pptats9pu.i s0 torCe%C.b/Mm]M apabclkBikjpe uoeperi_F.F.ldioicdilblpiseepjnass. gs//o bppiCjX oisXaoeas msbommlb..ejddreii.cctrrp //pChp.Meyoaxtbk_hon_output.cepp.obj ojF uitlpeust/.pcipopa.somb.jd ir/ada_output.cpp.obj [100%] Linking CXX executable pioasm.exe [100%] Built target pioasm [ 12%] No install step for 'PioasmBuild' [ 13%] Completed 'PioasmBuild' [ 13%] Built target PioasmBuild make: *** [Makefile:91: all] Error 2

Any ideas?

@Thugmek with regard to your first question, the Debug build configurations of RRF leave the SWD pins for SWD use. So you should use the Duet3_Debug build configuration for debugging.

The Debug build configurations also enable generation of debug information in the compiler settings, which may go some way towards addressing your second question.

@achrn thanks for reporting this, it is now fixed in the RRF 3.5 source code.

I have it working with the following bash script:

SWCLK=25 SWDIO=24 SRST=18 echo "Exporting SWCLK and SRST pins." echo $SWCLK > /sys/class/gpio/export echo $SRST > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio$SWCLK/direction echo "out" > /sys/class/gpio/gpio$SRST/direction echo "Setting SWCLK low and pulsing SRST." echo "0" > /sys/class/gpio/gpio$SWCLK/value echo "0" > /sys/class/gpio/gpio$SRST/value echo "1" > /sys/class/gpio/gpio$SRST/value echo "Unexporting SWCLK and SRST pins." echo $SWCLK > /sys/class/gpio/unexport echo $SRST > /sys/class/gpio/unexport echo "Ready for OpenOCD." openocd -c "adapter driver bcm2835gpio; \\ bcm2835gpio peripheral_base 0xFE000000; \\ bcm2835gpio speed_coeffs 236181 60; \\ adapter gpio swclk $SWCLK; \\ adapter gpio swdio $SWDIO; \\ adapter gpio srst $SRST; \\ transport select swd; \\ set CHIPNAME samc21; \\ source [find target/at91samdXX.cfg]; \\ reset_config srst_only; \\ adapter speed 276; \\ init; \\ reset; \\ reset; \\ at91samd chip-erase; \\ at91samd bootloader 0; \\ program Duet3Bootloader-SAMC21.elf verify; \\ reset; \\ shutdown" echo "Done."

This is adapted from here.

@dc42 thank you.
i am not try to build it. but it's not working and giving error.
310eafdf-9b7d-4057-af6e-ca4e5c8a2da5-image.png

@Thugmek we've never used debuggers with Duet 2. Older version Duet 2 boards do expose the JTAG/SWD pins but newer ones don't. All Duet 3 boards expose the SWD pins.

If the firmware crashes, the crash details are written to flash memory and can be retrieved using M122. We use the linker map file and assembler files generated by the compiler to identify the exact point at which it crashed. We usually find that sufficient to identify the bug.

@wieman01 Note that the dependencies and branches for the 3.5beta are not yet documented on the wiki, you may need to figure that out unless it's added before you start.

@dc42 thank you! (confirmed: works for me too now)

@dc42 I watch a lot of videos about electronics engineering and the stuff people are doing these days is pretty cool given the high level interfaces are available right at the hardware now.

I'm curious, my impression of the product line is that it's meant to be very stable, prioritizing it above everything else.

Do you think it would be beneficial to open up more of the toolset to people who want to develop, debug, etc. at a more causal commitment level? Just one example is to document how to build a test rig? Maybe that's too complicated, so the next best thing would be to figure out how to make it less complicated and start from there? I don't really know the subject material that well, so my suggestions could be way off, but I think you get the gist.

One of the great things about open source is the amount of human-power you can get for effectively free if you make it easy enough for people to contribute.

For myself,

I wanted to try to write unit tests for algorithms, but I couldn't find a way to "run" the code. I didn't know if there were any entry points already there to make it possible to write unit tests; aside from starting from scratch with some OTS unit testing framework and start figuring out how to mock, exec, etc. Any pointers?

@Mark_XYZ Custom array variables will be supported in 3.5-b1.

@dc42 “you could either detect USB disconnection/reconnection in your C# program…” Yes, I was asking how to do that. It is possible but not trivial to get notification for this on a particular device. Further, it needs deeper knowledge of the actual driver providing the serial interface to the application, which I don’t have. So I asked if anyone might have this.
But my approach was wrong. I don’t have that info, but I don’t need it either: The right way to do it is to hook to the general device event and know that some device dis-/reconnected. That is enough, I can then look at the uptime or a variable to find out if it was the Duet.

@gnydick yes I've read about that interesting algorithm before. I know of one place where the reciprocal of a square root is used, so it could perhaps be used there. However, most of the processors we use now support a fast floating point square root instruction.

@T3P3Tony HI Tony, installed the new board, uploaded the latest firmware and all is well, This issue is closed on my end. Thanks so much for your assistance to all @elmoret @droftarts @Phaedrux @dc42

It was in fact the librairies, marked solved

@KOlasmics I'm glad you found a solution!