I guess this is a little late, but you can pass in compiler flags on the
command line with -DCMAKE_CXX_FLAGS. For example:
cmake -DCMAKE_CXX_FLAGS:STRING="-mfloat-abi=hard -mfpu=neon
-mtune=cortex-a15" ../
Ron
On 11/10/2017 12:07 AM, Gwenhael Goavec-Merou via USRP-users 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 <kmcg3...@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
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
