Build zephyr.elf versus Build solution

[Learner]

I can see in Segger Embedded Studio v4.52 under the Build Tab, there are two methods to build the project.

1- Build > Build zephyr/zephyr.elf

2- Build > Build solution

What is the difference between the two methods?

Kind regards

[Heidi-Irene Harvey Sollie]

Hi! 

It's been a few days so I just wanted to let you know that I am working on this. But it's proving to be more difficult than expected.

I have successfully built the application with this ADC configuration in the overlay file where the node is compatible with "voltage-divider", based on the Battery Voltage Measurement sample in NCS. 

&adc {
    status = "okay";
};

/ {
    vbatt {
        compatible = "voltage-divider";
        io-channels = <&adc 4>;
        output-ohms = <180000>;
        full-ohms = <(1500000 + 180000)>;
    };
};

However, I have been trying to make the node compatible with "nordic, nrf-saadc", but there are a few issues, like the interrupts-field being required, but then seeing the error:

Warning (interrupts_property): /node@0: Missing interrupt-parent

&adc {
	status = "okay";
};


/ {
	
    n: node@0 { //EDIT: Incorrect
        compatible = "nordic,nrf-saadc";
        io-channels = <&adc 4>;
        reg = <1 2>; //EDIT: Incorrect
	    interrupts = <14 1>;
	    #io-channel-cells = <1>; 
	    label = "ADC_0";
	};
};

I'm still waiting for advice from an NCS developer on how to do this correctly, so I will update you when I hear back.

Hopefully, the information provided above might help you get somewhere in your development in the meantime.

Best regards,

Heidi

[Learner]

Thank you Heidi for persevering with this problem. 

While waiting for a solution I would like you to clarify the following,

n: node@0 {               is the @0 referring to instance 0 (zero) of the adc node named "adc@0"?

label = "ADC_0";       can we put any string for label or must we use "ADC_0" as it is expected                                                      somewhere else or because of the @0?

reg = <1 2>;                what information is the <1 2> conveying to us?

Thank you

Kind regards

Mohamed

[Heidi-Irene Harvey Sollie]

Sure! Disclaimer, by going through all the explanations myself, I see there were a lot of mistakes in my previous overlay file. I also got some input from a developer so I will explain the concepts but the examples in my previous comment were wrong. 

First of all, since there is only one instance of ADC on the nRF5340, that instance will be 0. So any mention of ADC is ADC_0, this is also configured in the board file. The &adc-node is also set with status = "okay" in the board-file here so we don't need to set it again in the overlay file.

n:  node@<unit-address>

node is the "node-name" and the "unit-address" 

The unit-address must match the first address specified in the reg property of the node. If the node has no reg property, the @unit-address must be ommitted. 

label = "ADC_0"

"ADC_0" is a node label. Nodes can be given labels, which are unique shorthands that can be used to refer to the labeled node elsewhere in the device tree. As you can see here the &adc-node in the nRF5340 board-file was give the label "ADC_0". So on second thought, this node's label should not be "ADC_0". It should be something unique so that you can refer to the node elsewhere in the device tree, such as "AIN_0", which you had in your application.

reg = <address size>;

This is a required field for the "nordic-nrf-saadc" compatible nodes. The way I defined it earlier was incorrect.

The reg property describes the address of the device's resources within the address space defined by its parent bus. Most commonly, it means the offset and length of a memory-mapped IO register block, but can have a different meaning in some bus types. Addresses in the address space defined by the root node are CPU real addresses. 

The number of cells required to specify the address and length are bus-specific and are specified by the #address-cells and #size-cells properties in the parent of the device node. If the parent node specifies a value of 0 for #size-cells, the length field in the value of reg shall be omitted. If missing, the default value is 2 for #address-cells, and a value of 1 for #size-cells (reg = <addr addr size>).

Disclaimer, we don't use two addresses in the nrf-chip at all, but this is for example if a peripheral has two separate addresses, one for read and one for write. 

I have posted a new and incomplete overlay file below. I removed the &adc-node, removed some of the properties, and changed the compatible property. When you set the compatible property, then there will be some "required" properties as well, defined in the .yaml file so you will need to add those as well. 

/ {
    n: node {
        compatible = " ";
        io-channels = <&adc 4>;
	    label = "AIN_0";
	};
};

You cannot use compatible = "nordic, nrf-saac", as this is only used to instantiate the NRF_SAADC-peripheral on the chip.

So we will need to figure out which compatible property to set, based on what you want to do with the ADC? For instance, here is an example to measure something with an external sensor on the Thingy:52. Is that similar to what you want to do maybe?

Best regards,

Heidi

[Learner]

Heidi-Irene Harvey Sollie said:

n:  node@<unit-address>

node is the "node-name" and the "unit-address" 

SPI peripherals

An index representing the peripheral’s chip select line number. (If there is no chip select line, 0 is used.)                   

The line above seems to contradict the information found here 

https://github.com/nrfconnect/sdk-zephyr/blob/v2.3.0-rc1-ncs2/include/devicetree/spi.h#L191-L212

The link above shows spi-dev-a@0 has a chip select line defined in the parent node, yet 0 is used as index.

Heidi-Irene Harvey Sollie said:

You cannot use compatible = "nordic, nrf-saac", as this is only used to instantiate the NRF_SAADC-peripheral on the chip.

Aren't we supposed to instantiate a peripheral before starting using it?

Heidi-Irene Harvey Sollie said:

So we will need to figure out which compatible property to set, based on what you want to do with the ADC? For instance, here is an example to measure something with an external sensor on the Thingy:52. Is that similar to what you want to do maybe?

I am trying to read some 2x analogue inputs, one on AIN_5 (R-C potential divider) and another on AIN_7 (output of am opamp).

Thank you for your help.

Kind regards

Mohamed

[Heidi-Irene Harvey Sollie]

Learner said:

The link above shows spi-dev-a@0 has a chip select line defined in the parent node, yet 0 is used as index.

"An index representing the peripheral’s chip select line number. (If there is no chip select line, 0 is used.)

Yes, the SPI controller, which is the parent node, has a chip. But the SPI device, the child node, does not have a chip select. Therefore the unit-address is 0. 

So, if there is no chip select line in that specific node 0 is used.

So, since spi-dev-a has a parent node with a cs-gpios property, the unit-address will be indexes into the cs-gpios array. So spi-dev-a has unit-address 0 and spi-dev-b has unit-address 1. Whereas spi-dev-c's parent node has no cs-gpios property, and therefore its unit-address is 0. 

Learner said:

Aren't we supposed to instantiate a peripheral before starting using it?

 Yes, but the ADC peripheral has already been instantiated in the board folder for nRF5340, here it is defined and here the status is set to "okay".

And we aren't instantiating the ADC peripheral either, we are creating a node to define the connection between the ADC peripheral and the analog input pint AIN_0. 

Learner said:

I am trying to read some 2x analogue inputs, one on AIN_5 (R-C potential divider) and another on AIN_7 (output of am opamp).

 Okay, so for the node for AIN_5, you can use the voltage-divider compatible property. For the output of an opamp, I'm not sure but perhaps a voltage-divider would work there too if the circuit fits.