[USRP-users] Compiling UHD Host Library: Problem Enabling ARM Neon Support

Gwenhael Goavec-Merou gwenj at trabucayre.com
Fri Nov 10 03:07:34 EST 2017


maybe this : https://github.com/EttusResearch/uhd/pull/135
will help you


On Fri, 10 Nov 2017 00:29:25 -0600
Kevin McGuire via USRP-users <usrp-users at 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 at 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. 

More information about the USRP-users mailing list