Device Tree: 'reg' node property

[Learner]

Hello,

I need someone to shed some light on how to use the 'reg' node property because I am confused.com .

On this page https://docs.zephyrproject.org/latest/guides/dts/intro.html 'reg' is described as follows,

reg

Information used to address the device. The value is specific to the device (i.e. is different depending on the compatible property).

The reg property is a sequence of (address, length) pairs. Each pair is called a “register block”. Here are some common patterns:

• Devices accessed via memory-mapped I/O registers (like i2c@40003000): address is usually the base address of the I/O register space, and length is the number of bytes occupied by the registers.

• I2C devices (like apds9960@39 and its siblings): address is a slave address on the I2C bus. There is no length value.

• SPI devices: address is a chip select line number; there is no length.

However, looking zephyr.dts in the build folder of the example 'light intensity controller' in this tutorial nRF Connect SDK Tutorial - Part 2  NCS v1.3.0 I can see the 'reg' property used in a different way,

spi0: spi@8000 {
#address-cells = < 0x1 >;
#size-cells = < 0x0 >;
reg = < 0x8000 0x1000 >;
interrupts = < 0x8 0x1 >;
status = "disabled";
label = "SPI_0";
};

Can someone please explain what is going on here?

Thank you.

Kind regards

Mohamed

[Simon]

I looked into this, and I think I understand how this works

There is a difference between Devices accessed via memory-mapped and SPI devices.

This is an example of Devices accessed via memory-mapped.

• There is not defined any reg property here, so it will get the default value from here
• In this case the reg property will be on the form reg = <address length>, which gives information on where this peripheral is placed in memory and how much memory it occupies. It should coincide with the values defined here.

This is an example of SPI device.

• In this case the reg property will be on the from reg = <address>, which is the chip select line number

The values you see in zephyr.dts comes from here

Best regards,

Simon

[Learner]

Hi Simon,

Thank you for your answer.

Can both methods of accessing devices over SPI (memory-mapped and SPI devices) be used with zephyr RTOS?

Simon said:

This is an example of SPI device.

So, sub-node adxl362@0 is an SPI device that is connected to spi3 and uses the pins defined below. Pin 8 is the CS for spi device adxl362@0 and pin 7 is the CS for spi device adxl372@1. Is this right? 

What is the 0 in the chip select line below (cs-gpios) for?

status = "okay";
sck-pin = <3>;
mosi-pin = <4>;
miso-pin = <5>;
cs-gpios = <&gpio0 8 0>, <&gpio0 7 0>;

Let me put it to you what I think I understood from your answer and relate to what I am trying to implement on our own proprietary board.

I need to communicate with a device over SPI using nRF5340 and zephyr RTOS. I have the source code for the driver.

For example if I wanted to communicate with  the device over spi1 I need to implement the following in an overlay file.

&spi1 {
   compatible = "nordic,nrf-spim";
   status = "okay";
   sck-pin = <13>;
   mosi-pin = <09>;
   miso-pin = <40>;
   cs-gpios = <&gpio0 19 0>;

};

I am not sure about what to do with the source code for the device driver. I do not want to create a full blown zephyr based driver for this device. I have read on DevZone this

Drivers-wise, you essentially have two options (zephyr choice is divided into two options):

1. Use the generic Zephyr driver API

    a. Hard way: Create a full-blown zephyr based driver - this is normally not done unless you plan to do a pull-request to the zephyr-rtos project.

    b. Easier way: Setup the SPI instance in your application, then add the communication protocol on-top.

2. Use the nordic specific nrfx driver directly

You can use the Zephyr API to create your own driver. This includes creating Kconfig menu, device tree, and developing the sensor src and porting to use the spi.h API. This would then be a portable driver, which can theoretically run on any of the supported SPI "backends" (ie: x86, arm, xtensa, etc), but its not a straight forward process.

You also have the option to use the nrfx_spim driver directly in your application, by adding CONFIG_NRFX_SPIM=y, then adding for instance CONFIG_NRFX_SPIM1=y.

I favour option 1b. Can you please help me with the steps I need to take to implement this?

Thank you.

Kind regards

Mohamed

[Learner]

Simon said:

This is an example of SPI device.

• In this case the reg property will be on the from reg = <address>, which is the chip select line number

You are saying the value assigned to reg property is the chip select line (cs). What is meant by line in this context? is it the pin number on a particular port? I thought the chip select line is specified by the line below.

Learner said:

cs-gpios = <&gpio0 8 0>, <&gpio0 7 0>;

Please clarify. Thank you.

Kind regards

Mohamed

[Simon]

I think the zeros below are SPI device's chip select GPIO flags. See this

cs-gpios = <&gpio0 8 0>, <&gpio0 7 0>;

I believe the value assigned to reg shows whether an SPI device have a chip select line configured or not, 1 if yes and 0 if no. See this.

Best regards,

Simon

[Learner]

Thank you Simon.

I am clear about the chip select question. However, I asked 3 more questions further up in this trail. You will find them if you search for the character '?'.

Please provide answers. Thank you.

Kind regards

Mohamed

[Simon]

Learner said:

Can both methods of accessing devices over SPI (memory-mapped and SPI devices) be used with zephyr RTOS?

I am not sure what you mean by "accesing devices". But both methods can be used in Zephyr. Read this for more information. You should just set the reg field appropriately, and then you don't have to worry about it more in your main code. The underlying drivers will use the reg fields and handle everything for you.

The sensor (e.g. the apds sensor) can be accessed from the code by using device_get_binding(<label>), where <label> is what you have set label equal to in the overlay/dts-file. E.g. this sensor is accessed by using device_get_binding("ADXL362").

Learner said:

I favour option 1b. Can you please help me with the steps I need to take to implement this?

This question was about how to implement the sensor into your application and if you should create your own driver or not, and you decide to go for option b: "b. Easier way: Setup the SPI instance in your application, then add the communication protocol on-top."

However, this question is out-of-scope for this ticket, which was about the reg node property. Could you open a new ticket and ask about this? In this way we keep DevZone more organized and it easier for future users to navigate. Thanks for your understanding

Learner said:

So, sub-node adxl362@0 is an SPI device that is connected to spi3 and uses the pins defined below. Pin 8 is the CS for spi device adxl362@0 and pin 7 is the CS for spi device adxl372@1. Is this right? 

 Yes, you have understood it correctly.

Best regards,

Simon