• State Not Answered
  • Replies 2 replies
  • Subscribers 88 subscribers
  • Views 628 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 270201
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Segger and the SDK

wz2b

This isn't really a question, it's more feedback, and also a solicitation to expand my knowledge (if I'm just flat out wrong).

Yesterday I attempted to upgrade my SDK to the latest.  My real goal was just to update Segger.  I started by following the manual installation instructions, because I'm stubborn.  I noticed there are a lot of dependencies now - Zephyr, West, Chocolatey, possibly gccarm.  Obviously some of that also means you have to have python.  I couldn't get any of this to work, so I fell back to just installing it all with nRF Connect.  It did install that way, so I am thankful for having that installation vector provided.

One of the things I find most tedious about any embedded environment is having to deal with the tool chain.  Is it just me or is the nRF tool chain / sdk getting heavier and more complicated with the passage of time?  I think the reasons include that they want to make all of their projects easily set up to support multiple platforms.  I get that, but it's not really a concern of mine, so all that stuff just seems to get in my way all the time. I think the complexity is underscored by looking at the questions people have about creating new projects.  The vast majority of answers tell you to find a close-enough example project and clone it, then work from there.  So this morning I tried exactly that.  I selected "open nRF SDK Project" and selected iBeacon on an nRF52840_DK.  What it did was opened up a project with no source files:

To see some actual source code I have a few choices: "Open file in project" and "Open file in solution."  There are no significant files in the 'project' but the 'solution' does have a main.c but it also has a dozen or two files named arch.c.  I opened main.c and then it showed me that maybe my file really was in the solution after all:

So I guess I'm wondering if other people find this obvious, or is it just me?

What I really want is a flat project structure with a src/ include/ and out/ and not a whole lot more.  What would I lose by saying forget all this and just use my own C++ IDE and makefiles, compile it all with GCC, and use one of nordic's linker configuration files to make sure it's all targeted to the right address for whatever device I'm on?  Then rather than having all of these board-specific files just use #ifdefs to handle the few cases I really have - for example, developing and debugging on a 52840DK then targeting a 52840 dongle.  Is the main thing I lose there having an interactive debugger?  Or can I just use gdb (I have no actual jlink, just the jlink emulation on the 52840-DK).

I'm really interested in hearing some thoughts on all of this from the community.

 

Parents
  • 0

    I figured some things out.  There is a Zephyr bluetooth stack that doesn't use any soft device.  The beacon example uses that by default.  Then there is a soft device implementation that I could use if I needed those features.  I don't know how I would do that, but I suspect that it would be that I add nrfxlib\softdevice_controller to my solution then somehow disable Zephyr.  I don't need extended advertising so maybe there is no reason for me to do this.  What I do need is very low power; the ability to control how often I advertise (again, to save power); and the ability to eventually move this project to whatever chip (maybe not the nRF52840, or maybe it is) is best suited to just being a battery powered beacon.

Reply
  • 0

    I figured some things out.  There is a Zephyr bluetooth stack that doesn't use any soft device.  The beacon example uses that by default.  Then there is a soft device implementation that I could use if I needed those features.  I don't know how I would do that, but I suspect that it would be that I add nrfxlib\softdevice_controller to my solution then somehow disable Zephyr.  I don't need extended advertising so maybe there is no reason for me to do this.  What I do need is very low power; the ability to control how often I advertise (again, to save power); and the ability to eventually move this project to whatever chip (maybe not the nRF52840, or maybe it is) is best suited to just being a battery powered beacon.

Children
Related