Is there any valid tutorial using Eclipse IDE for development on nRF52 devices?

[Stavros Makridis]

I have found a few "how to" on cofiguring Eclipse for application development on nRF52 devices. After some point things are not as described in this guides. So, Is there any solid and updated tutorial on how to use Eclipse? Something that actually works and preferbly on windows.

Currently I am using SES but it is so primitive compared to other IDEs (for example microsoft visual studio or atmel studio or even MPLab-X) that make my everyday life hard. For instance, indexer is so slow that it is faster to find the definition of a function by myself than waiting the atl+G key combination to take me there. Imagine using an SDK (like the one Nordic offers) with tens of files and dependencies between them, to have to remember or even more search for a particular variable or function. Can anyone be productive working like this?

I don't want to complain but poor implementation of tools like that affect directly my work and make me less productive. Time is money after all.

Thanks in advance,

Stavros Makridis.

[Mark]

if there is a good one, I sure would like to know : )

I started working on this for ARM Cortex M3 (Not Nordic) this spring and i had a very experienced developer leading the way and I still had a very hard time.  We were coming from IAR which 'just works' but desired to use the open source toolchain for a variety of reasons.

In the end I left the project in IAR because the conversion created more questions than it answered.  I also was very frustrated with Eclipse so I am not convinced you will be happy with it even if you do succeed in a setup. 

I am working with Nordic now I am using Segger Embedded Studio.  If you have a speed problem would it be reasonable to consider upgrading your pc?

I documented my steps but I am extremely hesitant to share it because I am not experienced and may lead someone astray and also these things change constantly.  In general I had these steps:

Install Java JRe runtime
Install Eclipse
Download Arm GCC toolchain
Install a MAKE toolchain
set environment variables.


This is not specific to Nordic but the best document I have found is here:
JBLopen Eclipse ARM

[Andrew Lentvorski]

At this point, if you're going to fight through a toolchain, I would recommend VSCode rather than Eclipse.  Microsoft is simply pouring so much resource at VSCode that nobody can keep up.

If you feed the VSCode Cortex-Debug extension the correct svd file, it seems to work just fine with a J-Link.

I used the armgcc projects from the Nordic SDK (since they're Makefile-based) as examples to extract the include paths, linker files, and compile options.

I then fed these to meson in a meson.build and the meson-cross.build cross compiling file.  ninja then picks up the correct compilation tools.  I was kind of skeptical, but I have to admit that the meson/ninja build system combination is growing on me.

Your prize for fighting through the mess is that your builds are *SMOKING* fast.  An additional bonus is that VSCode recognizes meson, picks up the compile_commands.json file from your build directory and configures IntelliSense correctly--so if you get your *build* correct your IDE follows the build and you eliminate the IDE/build mismatch that always seems to plague things.  An even additional bonus is that your builds and IDE now work on Windows, Linux, and OS X.

Is this tweaky?  Yes.  But I find that *every* embedded IDE is a PITA to get your include paths, linker files, etc. correct.  The only reason why anything "just works" is because somebody at one of the companies did all the "tweaky bits" for you in a sample project.  Sure, I can get a "blinky" up and runnign quickly, but I find that I always eventually have to figure out the "tweaky" part of any IDE for professional work (Why the h*ll do I have to set the include path on *that* category in Keil/SES/IAR, etc.) so by embracing VSCode I'm just frontloading the pain.  However, once it is set up, everything is explicit, and there is no more guesswork as to why something fails.

The first embedded company that actually embraces VSCode for their system is going to make everybody else look like chumps.

Open Source Caution: While lots of VSCode is open-source, the C/C++ extension is maintained by Microsoft and is *NOT* open-source.  If you're used to using proprietary tools with license keys, this probably doesn't matter to you, but if you're using Eclipse because it's a fully open-source toolchain, it might.

[Stavros Makridis]

First of all I would like to thank you for responding to my post. I really apprecaite it.

I have almost forgotten this ticket. To be honest I was disappointed because it seemed that everybody was happy using SES and I thought that maybe it is just me considering SES as on of the most improductive IDEs I have ever used the last 10years.

Anyway, Microsoft's dev tools are so familiar to me that I would be more than happy if I could use the same tools for embedded apps as I am doing for .Net apps. The problem is that I have no previous experience on meson/ninja combination. If you could help me to start, it would be great.

Thank you again.

[Andrew Lentvorski]

I am by no means an expert at the meson/ninja tools.  The most important part for me was getting a "cross" file up and running.  Once I got that going, the normal meson tutorial stuff mostly just worked the way the manual said.

The biggest issue is just that there are a *LOT* of include directories and magic flags that you are going to have to dig out of the IDE setup.  No one can help you with that as everyone has a different project structure.  To me, that's not such a big deal as I'm pretty used to digging out the compiler commands.  I *HATE* magic, because it always works great--until it doesn't.  And then you have to go hunt down the underlying compiler commands anyway.  For reference--I have about 20 c_args and 10 link arguments and about 20 include directories--and that's just for a *blinky*--the Nordic SDK doesn't help matters on include directories, either.  So, when you're thinking "Good grief.  Does it *really* take that many flags?"  The answer is "Yes, it really does".

In addition, you might want to take a look at the folks doing Rust on embedded.  Even if you're not using Rust, they're developing good tools for embedded work--especially for VSCode integration.  (See: https://probe.rs/ for an example)  Sometimes you can find information in that community that you can't really find anywhere else (although they are a bit focused on the STM-F32 series they sometimes integrate Nordic support)

I'm going to warn you, the path isn't easy, and you're not going to find a lot of help.  If you aren't prepared to go digging, give up now.  However, once you *do* get it running, I find that using the external build tools is much more stable over time.  I can pull a 5 year old project with external build tools, and I can rebuild the executable artifact *exactly*.  If I don't archive a virtual machine, it's almost impossible to do that with a vendor IDE.

Good luck.

I'll include my "meson cross file" for reference as nobody talks about it very much.  Maybe that will be of help:

[binaries]
c = '/opt/gnuarmemb/gcc-arm-none-eabi/bin/arm-none-eabi-gcc'
cpp = '/opt/gnuarmemb/gcc-arm-none-eabi/bin/arm-none-eabi-g++'
ld = '/opt/gnuarmemb/gcc-arm-none-eabi/bin/arm-none-eabi-ld'
ar = '/opt/gnuarmemb/gcc-arm-none-eabi/bin/arm-none-eabi-ar'
as = '/opt/gnuarmemb/gcc-arm-none-eabi/bin/arm-none-eabi-as'
size = '/opt/gnuarmemb/gcc-arm-none-eabi/bin/arm-none-eabi-size'
objdump = '/opt/gnuarmemb/gcc-arm-none-eabi/bin/arm-none-eabi-objdump'
objcopy = '/opt/gnuarmemb/gcc-arm-none-eabi/bin/arm-none-eabi-objcopy'
strip = '/opt/gnuarmemb/gcc-arm-none-eabi/bin/arm-none-eabi-strip'


[host_machine]
system = 'none'
cpu_family = 'arm'
cpu = 'cortex-m4'
endian = 'little'

[Stavros Makridis]

Thank you so much for finding the time and even bothering to respond back to me.

I will let you know if I find anything worth sharing.

Good luck to you too.