Read Differential adc and print the value serially using uart

[Nagaraj JP]

Hi all iam trying to read the differential analog voltage between AIN0 and AIN1 which is pin0.02 and pin0.03 and print the voltage which will be in micro volts from 400 micorvolt, and since the examples in sdk uses log_flush i could not get the data or not acess any data from that, i need to acess the data and print the data using uart, can anybody help me out in this, thankyou.

[Nagaraj JP]

Thankyou Ted for the effort you have put for me.

tedhavelka said:

details about your starting point in terms of software libraries and targeted hardware will be useful for the community here to know

My sdk is version 17.1.0 and my target board is nrf 52840 dk board. I can now print the data in uart , only thing is that i could not access the data that the adc has converted, i first tried the single ended adc in the example and tried to integrate it with my code but there was error in compiling.  Since the example code uses log_flush for printing the data i could not find where the data is, but some raw data is been printed which is varied when the adc is varied.So my first aim is to acess the data from the single ended code and to print the data, and then to implement the differential adc and then to print that data.

And im not using any RTOS in the code, it is just simply a basic implementation.

[tedhavelka]

Hello Nagaraj,

Glad to hear you have made some progress in obtaining ADC readings, if so far just the raw readings.  Your original mention of function log_flush() had me curious.  I've searched all of sdk-nrf v1.6.1 and found only a single reference to log_flush():

./modules/lib/mcumgr/cmd/log_mgmt/port/mynewt/src/mynewt_log_mgmt.c:267: rc = log_flush(log);

I cannot tell where this function is defined.  It's definition does not appear to be a part of Nordic nRF SDK v1.6.1 which I am using.  Though there is a chance that it is somehow created at build time for a given project.  I noticed that Zephyr apps have potentially one or more functions that part of Zephyr's sensor API, and described in the documentation for that RTOS, but their definitions don't actually exist (nor prototypes in and header files) until a Zephyr app developer creates them.  Though my understanding is incomplete, there seems to be some kind of meta-compilation step for those sensor and sensor driver API functions.  Perhaps log_flush() is generated similarly, and so its C code would not necessarily be visible before a sample app or project has been built.

Your project sounds interesting, Nagaraj.  I hope you continue to make good progress.  Keep safe,

- Ted

[JONATHAN LL]

Hi, 

I think there might be a mix up of two different SDK's here. 

There is the nRF5 SDK, https://infocenter.nordicsemi.com/topic/struct_sdk/struct/sdk_nrf5_latest.html?cp=8_1 

And the nRF Connect SDK (NCS) , https://infocenter.nordicsemi.com/topic/struct_sdk/struct/sdk_ncs_latest.html?cp=8_0 


And the log_flush is probably refrancing https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/group__nrf__log__ctrl.html?cp=8_1_6_10_30_5_1#ga2d86a60e776a72f918d2f6cf7abc3135 


Regards,
Jonathan