Customizing The System Architecture And File Structure - Analog Devices ADRV9005 Reference Manual

Reference Manual
SOFTWARE SYSTEM ARCHITECTURE DESCRIPTION
/c_src/devices:
The device folder includes the main API code for the ADRV9001 transceiver as well as the auxiliary devices the APIs used for the demo of
the ADRV9001. The /ADRV9001 folder contains the high-level function prototypes, data types, macros, and source code used to build the
final software system. Do not modify the files contained in the /ADRV9001 or other devices in this section. There is no software support
when these files are modified. Analog Devices maintains this code. The only exception is that the user can modify #define macros in
adi_ADRV9001_user.h, such as modifying polling timeouts and interval settings for various functions.
/c_src/platforms:
The /platforms folder allows a developer to insert custom platform hardware driver code for system integration with the ADRV9001 API. The
HAL interface is described later in this document. The adi_platform.c/.h files contain function pointers and the required prototypes necessary
for the ADRV9001 API to work correctly. Do not modify the function prototypes in adi_platform.c. The developer is responsible to implement
the code for each function to ensure the correct hardware drivers are called for the platform hardware. In the example code provided by ADI in
the customer\ folder, there are placeholder functions left empty to fill their platform-specific code.
/c_src/third_party:
This section contains third-party APIs to help the field programmable gate array (FPGA) control the system. For example, this includes a JSON
parser and the FMC field replaceable unit (FRU) info manipulator.

CUSTOMIZING THE SYSTEM ARCHITECTURE AND FILE STRUCTURE

The system architecture and file set are uniquely suited for the evaluation platform, and change when users progress to developing their own
unique solution. This paragraph is designed to give users at this stage of development a good starting point to build from, as well as build up
to more in-depth details, which are provided in the next chapter
on a custom platform. The goal here is to migrate from the evaluation platform to a custom, bespoke platform. To do so, take the evaluation
platform APIs and HDL out of the TARGET compilation and replace them with the APIs specific to the bespoke platform. To accommodate this
migration, use the TES in a slightly different way. Use the TES package to generate C code rather than connecting directly to the TARGET
platform through a client-server setup. Make minor edits to the generated files and then deploy the files to the target platform.
These Minor Edits listed in Figure 16
default, the generated code seeks to initialize the Evaluation Platform by making calls to adi_fpga9001_ functions. Given the migration away
from this platform, it is necessary to remove those function calls. In a similar fashion, insert any initialization functions needed for the user
platform into the generated C code, where they are necessary.
Most Minor Edits occur in the main.c and initialize.c files of the generated code base. For example, near the beginning of the main(...)
function, the linux_uio_initialize(...) function is called. This function is defined in linux_uio_init.c, found under platforms\linux_uio\.
Inspecting this function, the following code snippet is found early in the definition:
if (NULL != fpga9001)
{
fpga9001->common.devHalInfo = linux_uio_fpga9001_open();
if (NULL != adrv9001)
{
analog.com
(Software
Figure 16. Modified ADRV9001 API Software Architecture
consist mostly of removing function calls targeting unused hardware components. For example, by
Integration). Figure 16 shows the steps to begin the development
ADRV9001
Rev. A | 35 of 377