I agree to the license terms to get the tool-chain download as your describe. No problem downloading/installing that. When I try to take the next step to get the on-board package using wget from a linux terminal that is when there is no file - error 404. Is this address correct for that step?
wget https://www.decawave.com/dwm1001_on-board_package_v1p0.tar
Please advise, Tom
I would recommend to download it using mozilla rather than the terminal in the virtual box. wget will not work since you have to agree with the disclaimer.
You can also download it in Windows and place it in a shared folder.
Once you have downloaded and extracted the zip archive above, you will find what you’re looking for at:
“DWM1001&DEV Source_and_Docs_v2”/Source_Code/dwm1001_on-board_package_v1p0.tar
Below are some unix commands you may use:
1 unzip -q "DWM1001&DEV Source_and_Docs_v2.zip" // Unziping archive in download directory
2 cd DWM1001\&DEV\ Source_and_Docs_v2/Source_Code/ // Accessing path containing tar
3 tar -xvf dwm1001_on-board_package_v1p0.tar // extracting the tar you are looking for
Thanks. I found the file in the other download package as you suggested. The wget suggestion in the firmware guide threw me off.
So I have hit another newby setup roadblock following the dwm1001_firmware_user_guide.pdf section 4.2.2. I successfully installed the virtual box image with Unix/Eclipse and opened eclipse and imported the dwm project and opened the dwm/examples/dwn-simple/ in the editor. I assume all the project and eclipse paths are already correct/preset in the image but I am getting “Unresolved Inclusion” errors with #include <stdio.h>. Creates 80 errors during fw2 build like not recognizing what FALSE or BOOL means …
I can see the file in /usr/include/stdio.h using the file directory.
I tried it on both a windows and MAC machine at had the same issue. Any hints what is wrong?
Thanks Yves,
I looked at dwm.h file and #include <stdbool.h> is already there (but has the same unresolved inclusion error). There must be something wrong with the paths/includes with the decawave image that the dwm program can’t see standard C libraries.
If I create a new test C++ hello world project I can add #include <stdio.h> #include <stdbool.h> #include <stdint.h>
and compile with no problems. Any thoughts about what I need to do to fix it?
Out of curiosity, if you’re waiving the errors in the "problems "window and start debugging, is the tool proceeding ?
Because in my case, it seems they are not preventing eclipse from generating the binary dwm-simple_fw2 and flashing the mcu.
I’m trying to find the rootcause and make the environment cleaner, but at the mean time, if it compiles you can go ahead and play a bit with the device !
So are you getting the same errors? I have tried it again on a 3rd computer (windows) and if you follow the firmware user guide section 4.2.2 line-by-line you will get the same issue. I am not an eclipse or C master by any means but it sure seems like there are some paths wrong so the DWM-simple program is not seeing the standard C libraries when compiling.
Screenshots of the errors I see:
[color=#e4af09][size=x-small][font=Helvetica]https://imgur.com/qpbSAXh[/font][/size][/color]
[color=#e4af09][size=x-small][font=Helvetica]https://imgur.com/8lnjRSQ[/font][/size][/color]
[color=#e4af09][size=x-small][font=Helvetica]https://imgur.com/o3trp4V[/font][/size][/color]
[color=#333333]If I [color=#333333]switch USB to J-Segger and [/color]connect the device and run through debug mode it does look like something is [/color][color=#333333]uploaded to the device (LEDs stop flashing anyway), but I’d be very suspicious of what is uploaded if the compiler cant see even basic C libraries.[/color]
[color=#333333]Screenshot of Debugger:[/color]
[color=#333333][color=#e4af09][size=x-small][font=Helvetica]https://imgur.com/PXLWuPU[/font][/size][/color][/color]
[color=#333333]Any luck finding root cause? I am really looking forward to “playing with the device” and appreciate the detailed step by step manual but I am still at a frustrating roadblock.[/color]
So I had a look at what is happening, and I have an explanation.
The first thing to know if that PANS firmware used on the MDEK boards is built around a compiled library and some C source code allowing user customization.
The compiled library contains the standard C library.
When compiling, eclipse is not able to see what is defined in this compiled library, unlike gcc, which is called through the make file dwm.mak.
Under the provided environment, when you compile, Eclipse will call the make file which calls GCC. You can see the log in the console window, and only errors or warning in this window should mater.
By default, Eclipse has standard libraries in the /usr/include path. If you look there, you will see that stdbool.h is missing, and this is why Eclipse complains about the “true” and “false” statements. It doesn’t matter since we actually use GCC to compile through the makefile, and that stdbool.h is included in the PANS compiled lib.
If you want to fix the eclipse false errors, you can add stdbool.h in /usr/include. It will remove the error but have no impact on the current compilation since it goes through the make file.
Only the errors and warning in the console window should matter.