The ADRV9001 is family designator assigned to the System Development User Guide (UG-1828 for new ADRV9002, ADRV9003, ADRV9004, and upcoming additional family members). Thus, throughout this document, ADRV9001 designator may be used to refer to either ADRV9002, ADRV9003 or ADRV9004.
This is how the adrv9001 no-OS project looks like as a file tree.
no-OS/projects/adrv9001 ├── Makefile ├── src │ ├── app │ │ ├── app_iio.c │ │ ├── app_iio.h │ │ ├── headless.c │ │ ├── ORxGainTable.h │ │ ├── RxGainTable.h │ │ └── TxAttenTable.h │ ├── firmware │ │ ├── Navassa_EvaluationFw.h │ │ └── Navassa_Stream.h │ └── hal │ ├── adi_platform.h │ ├── adi_platform_types.h │ ├── no_os_platform.c │ ├── no_os_platform.h │ └── parameters.h ├── src.mk └── system_top.xsa / system_top.hdf
Note the presence of the system_top.xsa or system_top.hdf file. In order to build this no-OS project, you need such an .xsa or .hdf file present in the project directory, as shown above. In case you don't have one, either obtain a pre-built file or build it yourself by following the Building HDL guide.
See more about Navassa's HDL and options for building an HDL for CMOS or LVDS interface here.
And this is how the corresponding drivers section looks like as a file tree (the Navassa API can be found under common, devices and third_party directories):
no-OS/drivers/rf-transceiver/navassa/ ├── adrv9002.c ├── adrv9002_conv.c ├── adrv9002.h ├── adrv9002_init_data.c ├── common ├── devices └── third_party
Clone NO-OS with the
git clone --recursive https://github.com/analogdevicesinc/no-OS
If however you've already cloned NO-OS without the
--recursive flag, you may initialize all the submodules in an existing NO-OS clone with:
git submodule update --recursive --init
Prior to building a no-OS project, it is required to set up some environment variables so that the build process may find the necessary tools (compiler, linker, SDK etc.).
Use the following commands to prepare your environment for building no-OS projects:
Go in the project directory that should be built.
The build process creates a build directory in the project folder:
build ├── app ├── bsp ├── obj ├── release.elf └── tmp
.hex file has been generated, make sure the board is powered on, JTAG cable connected and use the following commands to upload the program to the board or debug.
Uploading the binary to target is generically achieved with:
$ make run
Use the following command to launch the SDK associated to the used platform in order to be able to debug graphically by clicking the debug button:
$ make sdkopen
Fore more details about the available make rules, check out this page.
Make sure to connect your adrv9002 evaluation board to the correct FMC connector or the carrier you use:
DAC_DMA_EXAMPLE is a standard example that sends a sinewave on Tx channels using DMA from a lookup table. If you physically loopback a Tx channel to an Rx channel via an electrical wire, you may run the DAC_DMA_EXAMPLE and read the received data at Rx from particular memory address.
To build the DAC_DMA_EXAMPLE demo, edit the Makefile and add -DDAC_DMA_EXAMPLE to CFLAGS and rebuild. Alternatively, you may simply add a #define DAC_DMA_EXAMPLE in a suitable place in code and rebuild.
To run the DAC_DMA_EXAMPLE, you simply need to run the application as usual by:
The application will eventually print something like this:
DAC_DMA_EXAMPLE: address=0x7f170 samples=65536 channels=4 bits=16
This means that the memory address where the data at Rx is stored is 0x7f170, there are in total 65536 samples, 16-bit wide across 4 channels, which is equivalent to 16384, 16-bit samples per channel.
At this point you may use a Tcl script to retrieve data from memory and store it into .csv files for processing:
for Zynq-7000: xsct legacy/scripts/xilinx_capture.tcl ZYNQ_PS7 0x7f170 65536 4 16 for ZynqMP: xsct legacy/scripts/xilinx_capture.tcl ZYNQ_PSU 0x7f170 65536 4 16
TINYIIOD demo is a standard example, provided in most no-OS projects, that launches a TINYIIOD server on the board so that the user may connect to it via an IIO client. Using iio-oscilloscope, the user can configure the DAC and view the ADC data on a plot.
To build the TINYIIOD demo, add the following flag when invoking make which will build the tinyiiod server and the IIO section of the driver.
To run the TINYIIOD demo, first connect to the board via UART to see the runtime output messages with the following settings:
Baud Rate: 115200bps Data: 8 bit Parity: None Stop bits: 1 bit Flow Control: none
Please note that for proper message display, you may need to convert all LF characters to CRLF, if your serial terminal supports it.
With a serial terminal correctly configured and listening to incoming messages, launch the application (
make run or click the debug button in your SDK). Runtime messages specific to the application will apear on your serial terminal screen, and eventually the following message is printed:
Running TinyIIOD server... If successful, you may connect an IIO client application by: 1. Disconnecting the serial terminal you use to view this message. 2. Connecting the IIO client application using the serial backend configured as shown: Baudrate: 921600 Data size: 8 bits Parity: none Stop bits: 1 Flow control: none
This message implies a TINYIIOD server is being run and you may connect to it using a serial-backend enabled iio-oscilloscope and with the settings indicated at the serial terminal.