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

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

  • 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

  • Yes absolutely! I have changed it now. :) 

  • 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

  • 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

  • Hi Heidi,

    Your developer has actually provided a binding specific to our needs. So, I do not have to create my own bindings :). Happy days!

    How do I download the code for the sample?

    Thank you.

    Kind regards

    Mohamed

  • Here there is a green button called "Code". You can hit "Download" zip to get the zip-file or run git clone https://github.com/pabigot/fw-nrfconnect-nrf.git to clone the git repository. 

    Make sure to use the ncs environment the sample was made in (so don't extract the sample folder and place it in another ncs tag) and make sure to run west update, to update the other repositories as well. 

Reply Children
  • Thank you Heidi,

    Make sure to use the ncs environment the sample was made in (so don't extract the sample folder and place it in another ncs tag)

    I was going to extract only the sample I was interested in (https://github.com/pabigot/fw-nrfconnect-nrf/blob/sample/20201020a/samples/myapp/) and run it in my current environment. Why can't I do that?

    I have my current zephyr installation here C:\Zypher\v1.3.0\... 

    06/08/2020 14:04 <DIR> .
    06/08/2020 14:04 <DIR> ..
    29/07/2020 17:21 <DIR> .west
    29/07/2020 17:25 <DIR> bootloader
    05/08/2020 11:38 1,664 Go_west.bat
    29/07/2020 17:26 <DIR> mbedtls
    29/07/2020 17:29 <DIR> modules
    29/07/2020 17:21 <DIR> nrf
    29/07/2020 17:25 <DIR> nrfxlib
    29/07/2020 17:25 <DIR> test
    29/07/2020 17:21 <DIR> toolchain
    29/07/2020 17:29 <DIR> tools
    29/07/2020 17:39 <DIR> zephyr

    make sure to run west update, to update the other repositories as well.

    Which folder should I run the command 'west update' from?

    Which other repositories will it update?

    Kind regards

    Mohamed

  • Hi

    Learner said:
    Why can't I do that?

    You can, it's just that some changes might be needed. If you want to guarantee it works out of the box, you should use the NCS environment it's written in. But, just try to build and run and see how that goes. 

    You should run west update in the folder that contains the "west.yml" file, so ncs/nrf. This will update all the repositories in the NCS folder (so zephyr, mcuboot, bootloader, nrfxlib, etc)

     Best regards,

    Heidi

  • Thank you Heidi. I understand.

    Just in case I did not mention it before, I am using nRF5340 SoC under zephyr RTOS. So, I have two west.yml files. one under C:\Zypher\v1.3.0\nrf and another one under C:\Zypher\v1.3.0\zephyr. So, I think I should be running west update from C:\Zypher\v1.3.0\zephyr.

    What do you think?

    Kind regards

    Mohamed

Related