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]

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 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 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 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]

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. 

[Learner]

Heidi said:

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.

I would have accepted your answer if it was not for the definition of node b just below node a. Node b has no chip select line but the index used is NOT 0 but 1. See below an extract from spi.h.

/**
* @brief Does a SPI device have a chip select line configured?
* Example devicetree fragment:
*
* spi1: spi@... {
* compatible = "vnd,spi";
* cs-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>,
* <&gpio2 20 GPIO_ACTIVE_LOW>;
*
* a: spi-dev-a@0 {
* reg = <0>;
* };
*
* b: spi-dev-b@1 {
* reg = <1>;
* };
* };
*
* spi2: spi@... {
* compatible = "vnd,spi";
* c: spi-dev-c@0 {
* reg = <0>;
* };
* };
*
* Example usage:
*
* DT_SPI_DEV_HAS_CS_GPIOS(DT_NODELABEL(a)) // 1
* DT_SPI_DEV_HAS_CS_GPIOS(DT_NODELABEL(b)) // 1
* DT_SPI_DEV_HAS_CS_GPIOS(DT_NODELABEL(c)) // 0
*
* @param spi_dev a SPI device node identifier
* @return 1 if spi_dev's bus node DT_BUS(spi_dev) has a chip select
* pin at index DT_REG_ADDR(spi_dev), 0 otherwise
*/

Heidi said:

Okay, so for the node for AIN_5, you can use the voltage-divider compatible property.

Great news! 

So, how would the overlay file look? and where must I store the .yaml file? Can I put it in the same folder as the prj.conf file?

Kind regards

Mohamed

[Learner]

Please ignore my question about the yaml file.

I have had an attempt at creating this overlay file. Would this overlay file do the job?

&adc {
   compatible = "voltage-divider";

   adc5: {
      label = "AIN_5";
   }

   adc7: {
      label = "AIN_7";
   }

   n: node {
      io-channels = <&adc5 26>, <&adc7 28>;
      io-channel-names = "FOIL", "STRAP";
   };
};

Looking at the yaml file, line 21 is referring to Resistance of the lower leg of the voltage divider. But in our case the lower is not a resistance but a capacitance. Is this ok?

Assuming I can use the "voltage-divider"compatible property, I can do the binding using this

 adc_dev_5 = device_get_binding("AIN_5");                                                                               adc_dev_7 = device_get_binding("AIN_7");

Please confirm if I am on the right path...

Kind regards

Mohamed

[Learner]

Learner said:

io-channels = <&adc5 26>, <&adc7 28>;

The numbers 26 and 28 refer to the pin numbers on PORT0 used for AIN5 and AIN7.

[Learner]

Hi Heidi,

I give up. I tried few flavours of the overlay file and none worked. The project always fail to load.

# Method 1:
&adc {
# compatible = "nordic,nrf-saadc";
 compatible = "voltage-divider";

 adc5:adc@... {
 label = "AIN_5";
 }

 adc7:adc@... {
 label = "AIN_5";
 }

 n: node {
 io-channels = <&adc5 26>, <&adc7 28>;
 io-channel-names = "FOIL", "STRAP";
 };
};

# Method 2:
adc0: adc@4000E000 {
compatible = "nordic,nrf-saadc";
# compatible = "voltage-divider";
label = "ADC_0";
};

n: node {
io-channels = <&adc0 4>;
io-channel-names = "AIN_0";
};

Kind regards

Mohamed