I don't understand west

RE: I don't understand west

arv — Mon, 14 Mar 2022 15:11:25 GMT

Hello,

I actually think I do understand now, yes. I think. What I'm trying to build is here: https://github.com/diagprov/firmware-demos/tree/master/nrf52-ncs-52840dk-bluetooth

There would be two ways to build this:

1. west init -m https://github.com/diagprov/firmware-demos/tree/master/nrf52-ncs-52840dk-bluetooth/firmware (I am not sure if west can cope with parts of git repositories like this, but ho hum).

2. clone the whole git, cd into nrf52-ncs-52840dk-bluetooth/firmware, west init --local, cd .., then use west normally.

So I think I understand how west expects to be laid out. I am not sure I _like_ it at all because it appears to be in conflict with how git repositories actually work, but, there's a lot of people who can't adapt to a non-subversion mental model.

I'm now onto the next set of problems: specifically, west build -b nrf52840dk_nrf52840 has the following complaint:

firmware-demos/nrf52-ncs-52840dk-bluetooth/firmware/src/main.c:23:33: error: 'CONFIG_BT_DEVICE_NAME' undeclared here (not
in a function)
23 | #define DEVICE_NAME CONFIG_BT_DEVICE_NAME

but I guess this is another thread/discussion (this demo is entirely unmodified from the ncs tree, so basically it just doesn't work, but what's new).

I'll be honest, I think it may actually be easier simply to eschew west entirely, require the nordic tree to be checked out in a well known location and go from there. West seems to have a very opinionated, and frankly utterly wrong, understanding of git's capabilities. For example, here I was trying to start with a local git repository first and test before pushing up to github, but west wants to take over the cloning. Here are some things I suspect west totally cannot cope with:

The fact my git repositories frequently contain multiple remotes. Some are to github, some not.
The fact I may or may not monorepo, and west doesn't own the whole repository.
The fact that branches can track remotes not all in the same repository if I want.

Thanks a lot!

Antony

RE: I don't understand west

Charlie — Tue, 01 Mar 2022 09:03:12 GMT

Hi Arv,

Can the CI solution for nRF9160: Asset Tracker v2 FW can satisfy your needs?

Firmware — nRF Asset Tracker 911cbddce975ab27b806dcae9c65630b36211fd2 documentation (nordicsemiconductor.github.io)

Best regards,

Charlie

RE: I don't understand west

arv — Mon, 28 Feb 2022 22:20:58 GMT

Yes, I can confirm I'm trying to follow workflow 4, with a slightly non-trivial example (shell_bt_nus) to demonstrate that it correctly pulls in Nordic components. All code in application/ is taken from the nordic sdk and I'm following the west templates as on the wiki.

No IDEs or even browsers pretending to be IDEs, sorry. I'm after a scriptable command line build that can be fed into a CI pipeline at a later date: launching an IDE on a machine with no graphical console is obviously a no go. For what its worth, I am a professional developer, I have built with all kinds of gnarly makefiles. My Linux kernel is custom, I've written firmware for ppc, stm32, avr, I have all kinds of compilers on my system. I've also shipped software in Rust and Go, and in a past life I wrote Windows drivers people are, to my knowledge, still using in production. For a hobby project at some point I need to build the latest stable rust compiler for OpenBSD and I have a sneaking suspicion this will be easier to do than using your SDK.

I've also compiled for the nordic board using mynewt.

So I'm pretty comfortable with building stuff and I can't figure out how to combine your build with version control in any kind of sane way from 1-2 days of reading your wiki and trying to build the shell_bt_nus example this way. I gave up and posted here instead to see if I could get some help.

So what I really need is a set of instructions (ideally) or standalone example (ideally slightly more than LED blinking demonstrating a dependency on some nordic specific component, not just zephyr) I can use to understand the workflow 4 process and adapt this to my needs. It can be assumed arm-none-eabi-gcc is on the path (in this case, ARM's official compilers kept at their latest versions and these have been used to write firmware for other boards) as is west. My goal would be to type "west build" and have a firmware image compiled (or alternatively what ever the correct command line arguments to do that are), and then flash with nrfjprog.

Thanks!

RE: I don't understand west

Charlie — Wed, 23 Feb 2022 15:41:58 GMT

Hi Antony,

I assume you are following Workflow 4: Application as the manifest repository and develop under the Linux system. Can you confirm?

This workflow is quite similar to the current NCS(nRF Connect SDK), your project builds on top NCS/Zephyr, just like NCS(sdk-nrf) builds on top of Zephyr. You still cannot avoid managing messy environment variable setups like NCS does with manual installation on Linux.

I suggest you set up an NCS development environment with nRF Connect for Desktop one-click installation on Windows or Mac(all the toolchain is configured automatically) and use VS code + nRF Connect Extention for your development. You can put your application project folder anywhere in the system, just add the folder to nRF Connect Extention when you need them. The whole process is quite smooth, even people without professional building environment knowledge can do it, so developers can focus on their own application.

Best regards,

Charlie