• State Not Answered
  • Replies 48 replies
  • Subscribers 74 subscribers
  • Views 11821 views
  • Users 0 members are here
Attachments (3) Download All
Nordic Case Info
  • Case ID: 257472
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • 0

    Hi again!

    So, first of all, to answer your questions about SPI:

    You are right, I did not catch that part. I have sent a message to the Nordic developer that has written this, but since they are based in LA I won't have an answer on this until tomorrow.

    I just received an answer about this.

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

    The spi1 node has a cs-gpios property, which means that the unit addresses for node a and b (0 and 1 respectively) are indexes into the cs-gpios array (an index representing the peripheral's chip select line number). The spi1 node has no cs-gpios, so node c has no chip select configured in the device tree, and therefore its unit address is left at 0 (if there is no chip select line, 0 is used). 

    In all your overlay examples you're still instantiating the ADC peripheral, which we don't want to do. 

    This is the template you want to follow:

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

    The forward slash indicates the root node and is very important to include.

    To include multiple ADC io-channels, just refer to the adc-node each time like this (not &adc5 and &adc7):

    io-channels = <&adc 26>, <&adc 28>;

    and if you want to use a different compatible property for the two nodes, you need to create two separate nodes like this:

    / {
    n: node_a {
        compatible = " ";
        io-channels = <&adc 26>;
	    label = "AIN_5";
	};
	
    n: node_b {
        compatible = " ";
        io-channels = <&adc 28>;
	    label = "AIN_7";
	};
};

    For you question about voltage-divider

    The lower leg is not a resistor, but the other one is a resistor? Or are you using a capacitive divider where both elements are capacitors?


    For your binding question, yes this is the correct way to do it, using the label you defined in the node.

    adc_dev_5 = device_get_binding("AIN_5");

    adc_dev_7 = device_get_binding("AIN_7");

    To do the binding for the two analog inputs, this is how to do it for AIN_5 and AIN_7 respectively.

    device_get_binding(DT_IO_CHANNELS_LABEL_BY_IDX(DT_NODELABEL(n),0))
device_get_binding(DT_IO_CHANNELS_LABEL_BY_IDX(DT_NODELABEL(n),1))

    Best regards,

    Heidi

  • 0 in reply to Heidi

    If I include in main.c 

    #include <hal/nrf_saadc.h>

    and use this overlay file 

    &pwm0 {
       ch0-pin = < 29 >;
    };

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

    then I get a different error,

    devicetree error: 'output-ohms' is marked as required in 'properties:' in C:/Zypher/v1.3.0/zephyr/dts/bindings\adc\voltage-divider.yaml, but does not appear in <Node /node in 'nrf5340pdk_nrf5340_cpuapp.dts.pre.tmp'>

    This suggests I need to add these two lines to the device tree fragment in the overlay file

    output-ohms = <???>;
    full-ohms = <(??? + ???)>;

    But I am not sure if the "voltage-divider" works with an R-C circuit?

    Finally, get_binding() does not bind AIN_0, it can only bind ADC_0.

    Are you sure the label line can have something other than ADC_0?

    Maybe I Should make changes to the source code (the light intensity controller example) in main.c when I am using the overlay file ?

    Kind regards

    Mohamed

  • 0 in reply to Heidi

    Hi Heidi,

    Heidi said:
    Did it work with the analog device plugged into GPIO pin 28 or pin 6?

    Apologies, it was NOT P0.28 that I am connecting the pot to but P0.06. 

    The reason I got confused is because the labelling on the top and bottom of the nRF5340pdk board is different. I looked on the bottom side where the pot was soldered on and there it says P0.28 (A2). This morning, by accident, I was looking at the top of the pdk board and noticed there was a pin labelled P0.06 which also happens to be the pin the pot is connected to. So, I think P0.28 (A2) is for another board not the nRF5340PDK.

    Kind regards

    Mohamed

  • 0 in reply to Heidi

    Hi Heidi,

    Thank you. It is much clearer now.

    p_reg->CH[channel].PSELP = pselp;

    where
    NRF_SAADC_Type * p_reg = NRF_SAADC
    uint8_t channel = ADC_1ST_CHANNEL_ID
    nrf_saadc_input_t pselp = ADC_1ST_CHANNEL_ID

    I think you meant to say nrf_saadc_input_t pselp = ADC_1ST_CHANNEL_INPUT. Right?

    Kind regards

    Mohamed

  • 0 in reply to Learner

    Yes absolutely! I have changed it now. :) 

  • 0 in reply to Heidi

    Thank you Heidi.

    I would like to 'Verify Answer' but there bits bits of information spread over multiple posts. One way to do this would be to add the bits of missing information to the post that has most of the correct info. Please let me know and I will Verify. 

    Kind regards

    Mohamed

  • 0 in reply to Learner

    Hi! I can try to summarize the most important parts of this very long thread in this comment. :) 

    To set up the ADC peripheral as IO-channels in the overlay file, we need to create a new node under the root node like this:

    / {
    my,node {
        compatible = " ";
        io-channels = <&adc 0>, <&adc 1>;
        io-channel-names = "CHANNEL_0_LABEL", "CHANNEL_1_LABEL";
    };
};

    where the &adc node is now connected with the analog input channels 0 and 1. Please note that you still need to configure the actual analog inputs (AIN0 to AIN7) in the main file. You can configure any analog input to any analog input channel. 

    All nodes need a "compatible" property. Even though it may seem like a logical choice for this node, you cannot use "nordic,nrf-saadc" as the compatible. This is a binding written specifically to instantiate the ADC peripheral and cannot be used with a node. 

    The only one available in NCS as of now is the "voltage-divider" binding in zephyr/dts/bindings/iio/adc/voltage-divider.yaml. 

    Users can create their own bindings and then use this as the compatible property. See the Zephyr Bindings documentation before you start writing it, for the file syntax and conventions, etc. Make sure to use a `[compatible]` that's namespaced to avoid conflict with other devicetree node identifiers; use something like `[companyname,rc-divider]`.

    The &adc node does not need to be defined or set to status = "okay", because both of these things are taken care of in the board folder.

    One of our developers wrote a simple sample for your use case (RC-divider and OP-AMP) that can be found here. 

    Also, please note that the documentation for the pin mapping on the nRF5340 PDK has some errors (both in the Getting Started guide and on the actual board).

    This is the correct mapping, and on the nRF5340 PDK, the front of the board has the correct labels for the GPIO pins. 

    AIN0 P0.04
    AIN1 P0.05
    AIN2 P0.06
    AIN3 P0.07
    AIN4 P0.25
    AIN5 P0.26
    AIN6 P0.27
    AIN7

    P0.28

    As for the unit-address with regard to the SPI peripheral, it is defined as:

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

    Using this example as the explanation: The spi1 node has a chip select (cs-gpios) property, which means that the unit addresses for node a and b (0 and 1 respectively) are indexes into the cs-gpios array (an index representing the peripheral's chip select line number). The spi1 node has no cs-gpios, so node c has no chip select configured in the device tree, and therefore its unit address is left at 0 (if there is no chip select line, 0 is used). 

    This might seem a bit confusing, but you cannot look at the unit-addresses of nodes alone, you always have to look at the unit-address in context to the parent node. And when you look at the parent node of sub-node a versus sub-node c it becomes clear that sub-node a's "0" means an index into the cs-gpios array and sub-node c's "0" is just "NULL". 

    Let me know if there's anything missing and I'll add it in!

    Also thank you for all your questions!

    Best regards,

    Heidi

Reply
  • 0 in reply to Learner

    Hi! I can try to summarize the most important parts of this very long thread in this comment. :) 

    To set up the ADC peripheral as IO-channels in the overlay file, we need to create a new node under the root node like this:

    / {
    my,node {
        compatible = " ";
        io-channels = <&adc 0>, <&adc 1>;
        io-channel-names = "CHANNEL_0_LABEL", "CHANNEL_1_LABEL";
    };
};

    where the &adc node is now connected with the analog input channels 0 and 1. Please note that you still need to configure the actual analog inputs (AIN0 to AIN7) in the main file. You can configure any analog input to any analog input channel. 

    All nodes need a "compatible" property. Even though it may seem like a logical choice for this node, you cannot use "nordic,nrf-saadc" as the compatible. This is a binding written specifically to instantiate the ADC peripheral and cannot be used with a node. 

    The only one available in NCS as of now is the "voltage-divider" binding in zephyr/dts/bindings/iio/adc/voltage-divider.yaml. 

    Users can create their own bindings and then use this as the compatible property. See the Zephyr Bindings documentation before you start writing it, for the file syntax and conventions, etc. Make sure to use a `[compatible]` that's namespaced to avoid conflict with other devicetree node identifiers; use something like `[companyname,rc-divider]`.

    The &adc node does not need to be defined or set to status = "okay", because both of these things are taken care of in the board folder.

    One of our developers wrote a simple sample for your use case (RC-divider and OP-AMP) that can be found here. 

    Also, please note that the documentation for the pin mapping on the nRF5340 PDK has some errors (both in the Getting Started guide and on the actual board).

    This is the correct mapping, and on the nRF5340 PDK, the front of the board has the correct labels for the GPIO pins. 

    AIN0 P0.04
    AIN1 P0.05
    AIN2 P0.06
    AIN3 P0.07
    AIN4 P0.25
    AIN5 P0.26
    AIN6 P0.27
    AIN7

    P0.28

    As for the unit-address with regard to the SPI peripheral, it is defined as:

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

    Using this example as the explanation: The spi1 node has a chip select (cs-gpios) property, which means that the unit addresses for node a and b (0 and 1 respectively) are indexes into the cs-gpios array (an index representing the peripheral's chip select line number). The spi1 node has no cs-gpios, so node c has no chip select configured in the device tree, and therefore its unit address is left at 0 (if there is no chip select line, 0 is used). 

    This might seem a bit confusing, but you cannot look at the unit-addresses of nodes alone, you always have to look at the unit-address in context to the parent node. And when you look at the parent node of sub-node a versus sub-node c it becomes clear that sub-node a's "0" means an index into the cs-gpios array and sub-node c's "0" is just "NULL". 

    Let me know if there's anything missing and I'll add it in!

    Also thank you for all your questions!

    Best regards,

    Heidi

Children
Related
Terms of service