DWC Portability and Common Library

This is the documentation for the DWC Portability and Common Library.

Introduction

The DWC Portability library consists of wrapper calls and data structures to all low-level functions which are typically provided by the OS. The WUDEV driver uses only these functions. In order to port the WUDEV driver, only the functions in this library need to be re-implemented, with the same behavior as documented here.

The Common library consists of higher level functions, which rely only on calling the functions from the DWC Portability library. These common routines are shared across modules. Some of the common libraries need to be used directly by the driver programmer when porting WUDEV. Such as the parameter and notification libraries.

Portability Library OS Wrapper Functions

Any function starting with DWC and in all CAPS is a low-level OS-wrapper that needs to be implemented when porting, for example DWC_MUTEX_ALLOC(). All of these functions are included in the dwc_os.h file.

There are many functions here covering a wide array of OS services. Please see dwc_os.h for details, and implementation notes for each function.

Common Library Functions

Any function starting with dwc and in all lowercase is a common library routine. These functions have a portable implementation and do not need to be reimplemented when porting. The common routines can be used by any driver, and some must be used by the end user to control the drivers. For example, you must use the Parameter common library in order to set the parameters in the WUDEV module.

The common libraries consist of the following:

• Connection Contexts - Used internally and can be used by end-user. See dwc_cc.h
• Parameters - Used internally and can be used by end-user. See dwc_params.h
• Notifications - Used internally and can be used by end-user. See dwc_notifier.h
• Lists - Used internally and can be used by end-user. See dwc_list.h
• Memory Debugging - Used internally and can be used by end-user. See dwc_os.h
• Modpow - Used internally only. See dwc_modpow.h
• DH - Used internally only. See dwc_dh.h
• Crypto - Used internally only. See dwc_crypto.h

Prerequistes For dwc_os.h

Data Types

The dwc_os.h file assumes that several low-level data types are pre defined for the compilation environment. These data types are:

• uint8_t - unsigned 8-bit data type
• int8_t - signed 8-bit data type
• uint16_t - unsigned 16-bit data type
• int16_t - signed 16-bit data type
• uint32_t - unsigned 32-bit data type
• int32_t - signed 32-bit data type
• uint64_t - unsigned 64-bit data type
• int64_t - signed 64-bit data type

Ensure that these are defined before using dwc_os.h. The easiest way to do that is to modify the top of the file to include the appropriate header. This is already done for the Linux environment. If the DWC_LINUX macro is defined, the correct header will be added. A standard header <stdint.h> is also used for environments where standard C headers are available.

Variable Arguments

Variable arguments are provided by a standard C header <stdarg.h>. it is available in Both the Linux and ANSI C enviornment. An equivalent must be provided in your enviornment in order to use dwc_os.h with the debug and tracing message functionality.

Threading

WUDEV Core must be run on an operating system that provides for multiple threads/processes. Threading can be implemented in many ways, even in embedded systems without an operating system. At the bare minimum, the system should be able to start any number of processes at any time to handle special work. It need not be a pre-emptive system. Process context can change upon a call to a blocking function. The hardware interrupt context that calls the module's ISR() function must be differentiable from process context, even if your processes are impemented via a hardware interrupt. Further locking mechanism between process must exist (or be implemented), and process context must have a way to disable interrupts for a period of time to lock them out. If all of this exists, the functions in dwc_os.h related to threading should be able to be implemented with the defined behavior.

---