Gwen, Wow, it was only 15 days ago too. The coincidence! Yes, that is the exact problem. Thank you! I have got mine compiled and I can see that it did build the converter for the neon. Kevin On Fri, Nov 10, 2017 at 2:07 AM, Gwenhael Goavec-Merou via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > maybe this : https://github.com/EttusResearch/uhd/pull/135 > will help you > > Gwen > > On Fri, 10 Nov 2017 00:29:25 -0600 > Kevin McGuire via USRP-users <usrp-users@lists.ettus.com> wrote: > > > I was able to get the compiler flags passed in so that the check for > > the header arm_neon.h passes. I added it to the CMakeList root file > > with SET(CMAKE_CXX_FLAGS, "${CMAKE_CXX_FLAGS} -mfloat-abi=softfp > > -mfpu=neon"). > > > > Then, it would detect neon. However, I spent considerable time > > cleaning up whatever package problems I had since I ended up with a > > bunch of weird errors. > > > > Once I straightened my packages up (Debian), it is compiling with > > neon! And, hopefully, it will actually use the ARM neon routines. > > > > On Thu, Nov 9, 2017 at 3:22 AM, Kevin McGuire <kmcg3413@gmail.com> > > wrote: > > > > > I have noticed that neon support for the converter is not enabling. > > > The CMakeError.log has this output. I am not certain as I am not > > > really familiar with ARM and NEON, but I checked my CPU and it does > > > support it. Also, the error message below is saying it is just a > > > matter of passing certain flags. > > > > > > /mnt/extra/usr/lib/gcc/arm-linux-gnueabihf/4.8/include/arm_ > neon.h:32:2: > > > error: #error You must enable NEON instructions (e.g. > > > -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h > > > #error You must enable NEON instructions (e.g. -mfloat-abi=softfp > > > -mfpu=neon) to use arm_neon.h > > > > > > Normally, I would just fix it myself and move forward, but me and > > > CMake mix like oil and water. It is kind of embarrassing but I > > > swear it never does what I want it do - such as adding a darn flag. > > > I even tried to force the options, lol, and all be danged if CMake > > > finds some way to error. > > > > > > Will work on this tomorrow, but if anyone has a solution I am all > > > ears. If not then no problem and I will reply when I figure it out. > > > > > > This came about when I noticed what really seemed like abnormally > > > high CPU usage on my ARM code for a simple shuffling of data out of > > > the network packets. I traced what I felt like was the biggest > > > possible hot spot to the converter routine. Anyway, that is my plan > > > right now, to see if NEON might help if the converter is having to > > > swap byte order. > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >