UG-1828
Preliminary Technical Data
Rev. PrC | Page 32 of 338
/c_src/common
Common code shared between all the devices, this contains error handling facilities, logging facilities, and HAL access facilities. Note: this
is not a folder customers should edit when implementing their own HAL, the files under common\ are designed to work in tandem with
any HAL provided to the codebase and as such do not need to be modified. Nor do any new files need to be added here.
/c_src/devices
The device folder includes the main API code for the ADRV9001 transceiver as well as auxiliary devices APIs used for the demo of
ADRV9001. The /adrv9001 folder contains the high-level function prototypes, data types, macros, and source code used to build the final
user software system. The user is strictly forbidden from modifying the files contained in the /adrv9001 or other devices in this section,
Software support is not provided when these files have been modified. Analog Devices maintains this code. The only exception is that
user may 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 provides the means for a developer to insert custom platform hardware driver code for system integration with the
ADRV9001 API. A description regarding the HAL interface is contained 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. Modification of the function
prototypes in adi_platform.c is forbidden. The developer is responsible for implementing the code for each function to ensure the correct
hardware drivers are called for the user’s platform hardware. In the example code provided by ADI in the customer\ folder, there are
placeholder functions left empty for the customer to fill in their platform-specific code.
/c_src/third_party
This section contains third party APIs used to help the FPGA control the system. This includes a JSON parser and a FMC FRU info
manipulator for example.
CUSTOMISING THE SYSTEM ARCHITECTURE AND FILE STRUCTURE
Given the system architecture and file set are uniquely suited the evaluation platform, these will likely need to change when a customer
progresses to developing their own unique solution. This paragraph is designed to give customers at this stage of development a good
starting point to build from, as well as build up to more in-depth details which will be provided in the next chapter (SOFTWARE
INTEGRATION). Figure 16 provides an illustration of the steps needed to begin development on a custom platform. The goal here is to
migrate from the evaluation platform to a custom, bespoke platform. Doing so requires that the evaluation platform APIs and HDL are
taken out of the TARGET compilation and replaced with the APIs specific to the bespoke platform. To accommodate this migration, the
TES must be used in a slightly different way. Rather than connecting directly to the TARGET platform via a Client-Server setup,
customers must instead use the TES package to generate C code, make minor edits to the generated files and then deploy the files to the
target platform.
Figure 16: Modified ADRV9001 API Software Architecture
These “Minor Edits” listed in Figure 16 consist mostly of removing function calls targeted at hardware components that the customer has
no intention of using. For example, by default the generated code will seek to initialize the Evaluation Platform by making calls to
“adi_fpga9001_” functions. Given that customers will be migrating away from this platform, it is necessary to remove those function calls.
In a similar fashion, any initialization functions needed for the customer platform must be inserted into the generated C code where they
are necessary.