Yes, but math_neon.h isn't in it:
ssh root@192.168.7.2 find /root/Bela -name "math_neon.h" // returns nothing
Here's where it is:
Andys-MacBook-Pro-3:~ Andy$ ssh root@192.168.7.2 find / -name "math_neon.h"
/usr/include/math_neon.h
.. and that folder is not included in the rsync list in the script file
a few months ago math_neon.h has been moved from /root/Bela/include to /usr/include/. You shall copy the content of that folder over as part of creating the minimal sysroot
Ah, that will be the problem then.
When I get back home I will do a run through with the new image and update anything that needs changing.
AndyCap When I get back home I will do a run through with the new image and update anything that needs changing.
The other thing that has moved are the NE10/ includes. These (and libmathneon) are now provided as packages in Bela/stretch/deb/ and installed in the destination location when the board is updated.
Yes those were the same two issues I found. If AndyCap can fix up the transfer script for SysRoot and make any project changes, I'll reload everything as a test to make sure we are all up to date.
Since I'm just bringing the system up, I could also reflash the Bone if the image is out of date. So two questions a) is bela_image_v0.3.5b.img still the correct image and b) do I need to do anything like load packages once I flash the image (if I need to flash the image).
you should just need to replace
rsync -avz root@192.168.7.2:/usr/include/alsa /usr/local/linaro/BelaSysroot/usr/includewith
rsync -avz root@192.168.7.2:/usr/include /usr/local/linaro/BelaSysroot/usr/Thanks for that. It solves the problem with math_neon.h but not the problem with NE10.h. Looking at the include paths in the Eclipse file and the organization of files in the Sysroot and the linaro tools folder, I could probably figure a way to get the files in the right places, but I'd rather mirror what @AndyCap is doing for compatibility. So maybe he will get home soon and update the instructions.
that should copy the ne10/ folder as well. What is the #include line that fails, exactly? In what file? If it is
#include <ne10/NE10.h>, it should work!
My bad. The script file wasn't getting saved out because of permissions. Now I don't have include file errors, but I do have the error below and a bunch more just like it. I just pulled from the dev branch.
In file included from ../core/AuxTaskRT.cpp:3:0:
../core/../include/xenomai_wraps.h: In function 'int create_and_start_thread(pthread_t*, const char*, int, int, void* (*)(void*), void*)':
../core/../include/xenomai_wraps.h:160:43: error: '__wrap_pthread_setname_np' was not declared in this scope
__wrap_pthread_setname_np(*task, taskName);Right. I think that the order of the -I parameters is wrong. You should have -I"/usr/local/linaro/BelaSysroot/usr/xenomai/include" second, just after -I"/Users/Andy/Dropbox/Developer/Bela/include". I think in Eclipse you fix this by changing the order of the include path in the C++ build settings, but I haven't used Eclipse in ages.
Doesn't seem to help:
Building file: ../core/I2c_Codec.cpp
Invoking: GCC C++ Compiler
arm-linux-gnueabihf-g++ -D_GNU_SOURCE -D_REENTRANT -D__COBALT__ -D__COBALT_WRAP__ -DXENOMAI_SKIN_posix -DXENOMAI_MAJOR=3 -DBELA_USE_RTDM -I"/Users/Andy/Dropbox/Developer/Bela/include" -I"/usr/local/linaro/BelaSysroot/usr/xenomai/include" -I"/usr/local/linaro/BelaSysroot/root/Bela/include" -I"/usr/local/linaro/BelaSysroot/usr/include" -I"/usr/local/linaro/BelaSysroot/usr/local/include" -I"/usr/local/linaro/BelaSysroot/usr/xenomai/include/cobalt/" -I/usr/local/linaro/arm-bela-linux-gnueabihf/lib/gcc/arm-bela-linux-gnueabihf/6.3.1/include/ -O0 -g3 -Wall -c -fmessage-length=0 -Wpointer-arith -Wunused-result -fpermissive -march=armv7-a -mtune=cortex-a8 -mfloat-abi=hard -mfpu=neon --fast-math -ftree-vectorize -ftree-vectorizer-verbose=10 -pthread -MMD -MP -MF"core/I2c_Codec.d" -MT"core/I2c_Codec.o" -o "core/I2c_Codec.o" "../core/I2c_Codec.cpp"
In file included from ../core/AuxTaskRT.cpp:3:0:
../core/../include/xenomai_wraps.h: In function 'int create_and_start_thread(pthread_t*, const char*, int, int, void* (*)(void*), void*)':
../core/../include/xenomai_wraps.h:160:43: error: '__wrap_pthread_setname_np' was not declared in this scope
__wrap_pthread_setname_np(*task, taskName);BTW, what do you use instead of Eclipse? I'm always keeping my eye out for something better.
can you post the output of
ls /usr/local/linaro/BelaSysroot/usr/xenomai/include?
Incidentally, you can probably workaround that by adding
int __wrap_pthread_setname_np ( pthread_t thread, const char * name );
at the top of xenomai_wraps.h, but I am more curious about the underlying issue.
jandyman BTW, what do you use instead of Eclipse?
For Bela, I just compile on the board.
giuliomoro ncidentally, you can probably workaround that by adding
int __wrap_pthread_setname_np ( pthread_t thread, const char * name );
at the top of xenomai_wraps.h, but I am more curious about the underlying issue.
Actually, in hindsight, both the changes suggested above should not make any difference, because the declaration is there already, though conditional to #if XENOMAI_MAJOR == 3. So the problem seems to be that -DXENOMAI_MAJOR=3 is - for some reason - not reaching the file?
Can you try adding these lines at the top of include/xenomai_wraps.h?
#if XENOMAI_MAJOR == 3
#error XENOMAI_MAJOR is in fact equal 3
#endif
#ifdef XENOMAI_MAJOR
#error XENOMAI_MAJOR is defined but not equal 3
#endifI’m guessing the changes I made to the bela project have gone missing somehow, this all looks like compile and probably linker settings are incorrect in the project.
I’m back on the 4th and will have a look then...
Don’t worry, I can see it in the GCC command line you sent, something must be undefineing it?
That is meant to be 3 on al v0.3 and above images (all images since October 2017).
Sounds like @AndyCap has answered @giuliomoro 's question, and the current issue is what might be redefining it. I can wait until the 4th for this to be unraveled.
In the meantime, I'm hoping to make some progress on the issue of wireless control of DSP running on Bela, over BLE or Wifi. I'm surprised it isn't a more popular subject and a path more travelled. The need seems obvious. I'm willing to do some trailblazing, especially in terms of developing a useful protocol on top of a raw byte or text stream, but I'm not a Linux expert so I'm afraid of falling into a black hole getting a basic link working.
Look at “open sound control” for the controller side. There are some Bela code examples.