How to switch to https://github.com/nrfconnect/sdk-zephyr main branch in ncs/v2.0.2?

[Wols]

After 

west init -m github.com/.../sdk-nrf --mr v2.0.2

west update

I notice ncs/v2.0.2/zephyr has huge difference with github.com/.../sdk-zephyr main

Like there is no 52840 overlay in ncs/v2.0.2/zephyr/sample/driver/adc/board.

I try to delete ncs/v2.0.2/zephyr and git clone https://github.com/nrfconnect/sdk-zephy.

But not working still got message:

=== updating zephyr (zephyr):
Updating files: 100% (10642/10642), done.
HEAD is now at be360e7db2 [nrf fromtree] net: openthread: enable default software tx security in 1.3
WARNING: left behind zephyr branch "main"; to rebase onto the new HEAD:
git -C zephyr rebase be360e7db2db7e1f0e9fcac686a08e62e350bf55 main

How can I switch to sdk-zephyr main?

[Karl Ylvisaker]

Hello,

You can unfortunately not mix-and-match different nRF Connect SDK versions and different Zephyr versions - each nRF Connect SDK release is made using a specific Zephyr release, and so it will expect to find everything as it was in this Zephyr release.

In your case, if you are missing a single file - such as a board file - from the Zephyr main branch, I would instead incorporate this specific file into your nRF Connect SDK, rather than changing the entire Zephyr version that the nRF Connect SDK is using.
This should also avoid the issue you are encountering now, where something has changed somewhere else in the Zephyr release that the nRF Connect SDK does not expect.

Best regards,
Karl

[Wols]

Hi Karl,

Thanks, that is the problem that I face. 

Like I can build SDK/zephyr/samples/drivers/led_ws2812 on ubuntu.

But on Windows and Mac, Ban... always miss some file. etc. zephyr/drivers/adc.h

And when I copy adc.h from Linux to Windows, another error again.

In file included from C:\Users\canic\ncs\v2.0.2\zephyr\include\zephyr\toolchain.h:50,
                 from C:\Users\canic\ncs\v2.0.2\zephyr\include\zephyr\init.h:10,
                 from C:\Users\canic\ncs\v2.0.2\zephyr\include\zephyr\device.h:29,
                 from C:\Users\canic\ncs\v2.0.2\zephyr\include\zephyr\drivers\adc.h:16,
                 from C:\Users\canic\ncs\v2.0.2\boards\arm\furry_project\furry_project.dts:9,
                 from <command-line>:
C:\Users\canic\ncs\v2.0.2\zephyr\include\zephyr\toolchain\gcc.h:89:10: fatal error: stdbool.h: No such file or directory
   89 | #include <stdbool.h>
      | 

[Wols]

Hi Karl,

Sorry for the late reply.

It's really confusing me that I can't find the correct ncs SDK for useing ADC example on nrf52840dk_nrf52840.

I think that beacause in page 
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.2/zephyr/samples/drivers/adc/README.html

This sample does not work on Nordic platforms where there is a distinction between channel and analog input that requires additional configuration.
See samples/boards/nrf/battery for an example of using the ADC infrastructure on Nordic hardware.

So again I have no idea why i can build om linux, but ncs SDK do not suppout zephyr ADC example.

I think I have to rewrite my adc code.

[Karl Ylvisaker]

Hello again,

Wols said:

Sorry for the late reply.

No problem at all - we can continue this whenever you have the chance, no worries! :) 

Wols said:

It's really confusing me that I can't find the correct ncs SDK for useing ADC example on nrf52840dk_nrf52840.

I am not sure what you mean by this, could you elaborate?
We do not have a dedicated SAADC usage example in the nRF Connect SDK (similar to the peripheral example we had in the nRF5 SDK) if this is what you mean, but you could take a look here to see how you easily can use the SAADC in the nRF Connect SDK.

Did you have a look at my remining questions from my previous comment? Did you do a fresh reinstallation of the nRF Connect SDK through the Toolchain Manager?

Best regards,
Karl

[Wols]

Hi Karl,

I have had reinstall nRF Connect SDK through the Toolchain Manager, but the sample " ncs/v2.0.2/zephyr/sample/driver/adc " still not working. (I guess this example works on my Linux just beacuse my environment is nasty... :'(  )

And I think the reason I can't use the sample " ncs/v2.0.2/zephyr/sample/driver/adc ", is because there is no any nrf board config in adc/board, which means it's not support this example on nrf board.

Now I am using " ncs/v2.0.2/zephyr/sample/board/nrf/bettery ", and trying to rewrite to fit my nrf52832dk(Which I currently have.).

What the difference between the light_control example and " ncs/v2.0.2/zephyr/sample/board/nrf/bettery ",

Are they both support nrf52832?

 

[Karl Ylvisaker]

Wols said:

but the sample " ncs/v2.0.2/zephyr/sample/driver/adc " still not working. (I guess this example works on my Linux just beacuse my environment is nasty... :'(  )

And I think the reason I can't use the sample " ncs/v2.0.2/zephyr/sample/driver/adc ", is because there is no any nrf board config in adc/board, which means it's not support this example on nrf board.

Ah, now I understand what you meant in your previous comment, thank you for clarifying!

The example does indeed not work on the Nordic platforms, since we differentiate between Analogue inputs and channels in our devices, as mentioned in the note you referred to earlier. The reason why our devices does this is the 'GPIO Crossbar' feature, that makes all the GPIOs available for most all of the peripherals - this flexible routing is the reason for the differentiation between Analogue inputs and ADC channels (which usually is 1-1 in other, less flexible devices).

Wols said:

What the difference between the light_control example and " ncs/v2.0.2/zephyr/sample/board/nrf/bettery ",

Are they both support nrf52832?

Yes, they are both supported. The main difference between the two is that the battery example is specific for the battery use-case (it outputs a battery charge percentage based on an approximation made of the specific battery's discharge curve), while the 'light_control' example I referenced earlier is more generic, i.e it only samples the voltage of a pin - without concern for what it is actually measuring.
You can use either one as your guide to how you could use the SAADC on the nRF52832, but the light control example is likely easier to familiarize with, and more straight-to-the-point with regards to SAADC usage, in this case.

Best regards,
Karl

[Wols]

Thanks Karl,

But the light_control examle not work for me.
Here is the erroe message.

../src/main.c: In function 'main':
/home/wols/ncs/v2.0.2/boards/arm/furry_project/light_controller/build/zephyr/include/generated/devicetree_unfixed.h:4495:36: error: 'DT_N_S_soc_S_pwm_4001c000_P_label' undeclared (first use in this function); did you mean 'DT_N_S_soc_S_pwm_4001c000_P_reg'?
 4495 | #define DT_N_NODELABEL_pwm0        DT_N_S_soc_S_pwm_4001c000
      |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~

And in the battery  " ncs/v2.0.2/zephyr/sample/board/nrf/bettery " , when I connect pa0.03 to GND, the console still out put 3V, did I miss some thing?

*** Booting Zephyr OS build v3.0.99-ncs1-4913-gf7b06162027d  ***                
[0:00:00.375]: 2971 mV; 0 pptt                                                  
[0:00:05.312]: 2892 mV; 0 pptt                                                  
[0:00:10.248]: 2965 mV; 0 pptt                                                  
[0:00:15.185]: 2954 mV; 0 pptt                                                  
[0:00:20.124]: 2983 mV; 0 pptt  

The 52dk52832 overlay I used.

/ {
	zephyr,user {
		io-channels = <&adc 0>, <&adc 1>, <&adc 7>;
	};
};

&adc {
	#address-cells = <1>;
	#size-cells = <0>;

	channel@0 {
		reg = <0>;
		zephyr,gain = "ADC_GAIN_1_6";
		zephyr,reference = "ADC_REF_INTERNAL";
		zephyr,acquisition-time = <ADC_ACQ_TIME_DEFAULT>;
		zephyr,input-positive = <NRF_SAADC_AIN1>; /* P0.03 */
		zephyr,resolution = <12>;
	};

	channel@1 {
		reg = <1>;
		zephyr,gain = "ADC_GAIN_1_6";
		zephyr,reference = "ADC_REF_INTERNAL";
		zephyr,acquisition-time = <ADC_ACQ_TIME_DEFAULT>;
		zephyr,input-positive = <NRF_SAADC_AIN2>;
		zephyr,resolution = <12>;
		// zephyr,oversampling = <8>;
	};

	channel@7 {
		reg = <7>;
		zephyr,gain = "ADC_GAIN_1_5";
		zephyr,reference = "ADC_REF_VDD_1_4";
		zephyr,vref-mv = <750>;
		zephyr,acquisition-time = <ADC_ACQ_TIME_DEFAULT>;
		zephyr,input-positive = <NRF_SAADC_AIN6>; /* P0.30 */
		zephyr,input-negative = <NRF_SAADC_AIN7>; /* P0.31 */
		zephyr,resolution = <12>;
	};
};

&pwm0 {
	//LED 2
	ch0-pin = <14>;
};

[Wols]

OK, so in light control example this version is old dts type see Pin control.

First step just delete  "ch0-pin = <14>;" to fix " rror: static assertion failed: "/soc/pwm@4001c000 has legacy *-pin properties defined although PINCTRL is enabled" " error.

After this when compile will got error below

light_controller/build/zephyr/include/generated/devicetree_unfixed.h:4337:36: 
error: 'DT_N_S_soc_S_pwm_4001c000_P_ch0_pin' undeclared (first use in this function); 
did you mean 'DT_N_S_soc_S_pwm_4001c000_P_ch0_inverted'?

I think is because it can not get pwm pin, but I have no idea how to fix it, so just block all pwm code.

And you can build then flash, you will see chanel 1  ADC(In my case is p0.02).

You can edit ADC_1ST_CHANNEL_INPUT to select which AINx to read.

But I am still lookin for the way to read muilt AINx same time

Like read AIN1 AIN2 in a for loop.

	for (size_t i = 0U; i < ARRAY_SIZE(adc_channels); i++) {
		debug("- %s, channel %d: ",
				adc_channels[i].dev->name,
				adc_channels[i].channel_id);

		(void)adc_sequence_init_dt(&adc_channels[i], &sequence);

		err = adc_read(adc_channels[i].dev, &sequence);
		if (err < 0) {
			debug("Could not read (%d)\n", err);
			continue;
		} else {
			debug("%"PRId16, buf);
		}

		/* conversion to mV may not be supported, skip if not */
		val_mv = buf;
		err = adc_raw_to_millivolts_dt(&adc_channels[i],
							&val_mv);
		if (err < 0) {
			debug(" (value in mV not available)\n");
		}
	}

[Karl Ylvisaker]

Hello again,

Wols said:

But the light_control examle not work for me.
Here is the erroe message.

Ah, yes, you can remove all the PWM specific code from the light-controller project, if they are not relevant for your application.
I primarily meant for the light controller example to be a point of reference for you on how you could use the SAADC in your existing application.
If you merge the SAADC usage from the light controller example into your existing v2.0.2 application you will not need to make any changes wrt. the devicetree and pin-ctrl module.

Wols said:

And in the battery  " ncs/v2.0.2/zephyr/sample/board/nrf/bettery " , when I connect pa0.03 to GND, the console still out put 3V, did I miss some thing?

The battery example explicitly sets VDD as the input pin for its measurements if no voltage divider circuit is specified.

Wols said:

But I am still lookin for the way to read muilt AINx same time

Like read AIN1 AIN2 in a for loop.

If you would like to use the SAADC in scan mode (the link is for the nRF52832 documentation, but the same goes for the nRF52840 SAADC peripheral, in this case) you can enable more channels in the channels argument for the adc_sequence.

Best regards,
Karl