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.
Hello Nagaraj JP,
Not sure if I can assist you, but a few details about your starting point in terms of software libraries and targeted hardware will be useful for the community here to know. Are you working with Nordic Semi's nRF Connect SDK, such as found at https://github.com/nrfconnect/sdk-nrf/tags? This was my starting point a few months back. I am using Nordic's sdk-nrf release version 1.6.1.
If yes to this question you are most likely then working with a Zephyr RTOS based app. I've seen some posts here, however, in which developers are working with a non-Zephyr code base or project.
If your application is Nordic SDK plus Zephyr based, then you may be able to get your targeted board's UART functioning quickly via the "hello world" sample app in downloaded SDK. For myself there were several steps to download and configure the various tools and SDK software pieces, but in the end I have a `west` workspace (where `west` is, you may already know, a Python based project manager at the command line). In that `west` workspace the `west` utility has eased the git cloning of Nordic's SDK, an associated fork of the Zephyr project, and some nice sample apps both from Nordic and from Zephyr.
In about a day's time I was able to enable any of three on-chip UARTs in my development board's microcontroller. The "hello world" sample in [west_workspace]/zephyr/samples/hello_world contains almost no code, and its prj.conf file is effectively empty. But as the sample app builds part of the build toolchain goes out and reads a DTS (device tree source) board file for my particular targeted board. Capturing and reviewing the build messages, I could then study that board.dts file, and see how the UART is assigned to pins, given a default BAUD rate, and enabled in the context of Zephyr RTOS. Those things allowed me to correctly configure my terminal emulator, and later to move between UART instances and change BAUD rate settings as needed.
The minimal source file from "hello_world" provided me an include statement which I have used many times since in development versions of code:
`#include <sys/printk.h>`
In Zephyr based apps (Zephyr 2.6.0 in my case) this include permits me to call `printk()` family functions. Printk() seems to behave just like `printf()`.
If I have shared things you already know my apologies. If you are just getting started in a Zephyr based project, you will likely want to study some about Device Tree Source, and the .dts and .overlay files you will and can use in Zephyr RTOS based projects.
Once you can build and see correct "hello world" output, you can start to add your own custom routines and code to that project. To pull the sample app out of Nordic's larger SDK will require some additional project configuration steps. Those lay outside the scope of your question, and are better answered by a couple of good tutorials and likely some further interaction with the forum community.
Hope this helps.
- Ted
Hello Nagaraj JP,
Not sure if I can assist you, but a few details about your starting point in terms of software libraries and targeted hardware will be useful for the community here to know. Are you working with Nordic Semi's nRF Connect SDK, such as found at https://github.com/nrfconnect/sdk-nrf/tags? This was my starting point a few months back. I am using Nordic's sdk-nrf release version 1.6.1.
If yes to this question you are most likely then working with a Zephyr RTOS based app. I've seen some posts here, however, in which developers are working with a non-Zephyr code base or project.
If your application is Nordic SDK plus Zephyr based, then you may be able to get your targeted board's UART functioning quickly via the "hello world" sample app in downloaded SDK. For myself there were several steps to download and configure the various tools and SDK software pieces, but in the end I have a `west` workspace (where `west` is, you may already know, a Python based project manager at the command line). In that `west` workspace the `west` utility has eased the git cloning of Nordic's SDK, an associated fork of the Zephyr project, and some nice sample apps both from Nordic and from Zephyr.
In about a day's time I was able to enable any of three on-chip UARTs in my development board's microcontroller. The "hello world" sample in [west_workspace]/zephyr/samples/hello_world contains almost no code, and its prj.conf file is effectively empty. But as the sample app builds part of the build toolchain goes out and reads a DTS (device tree source) board file for my particular targeted board. Capturing and reviewing the build messages, I could then study that board.dts file, and see how the UART is assigned to pins, given a default BAUD rate, and enabled in the context of Zephyr RTOS. Those things allowed me to correctly configure my terminal emulator, and later to move between UART instances and change BAUD rate settings as needed.
The minimal source file from "hello_world" provided me an include statement which I have used many times since in development versions of code:
`#include <sys/printk.h>`
In Zephyr based apps (Zephyr 2.6.0 in my case) this include permits me to call `printk()` family functions. Printk() seems to behave just like `printf()`.
If I have shared things you already know my apologies. If you are just getting started in a Zephyr based project, you will likely want to study some about Device Tree Source, and the .dts and .overlay files you will and can use in Zephyr RTOS based projects.
Once you can build and see correct "hello world" output, you can start to add your own custom routines and code to that project. To pull the sample app out of Nordic's larger SDK will require some additional project configuration steps. Those lay outside the scope of your question, and are better answered by a couple of good tutorials and likely some further interaction with the forum community.
Hope this helps.
- Ted
