Chapter 194. Configuration
This chapter shows how to include the WWD support into an eCos configuration, and to configure it once installed.
194.1. Configuration Overview
The WWD driver is contained in the
CYGPKG_NET_WIFI_BROADCOM_WWD. However, it depends on the
services of a collection of other packages for complete
functionality. Currently the WWD implementation is tightly bound with
the lwIP TCP/IP networking stack provided by
Incorporating the WWD support into your application is
straightforward. The essential starting point is to incorporate the
WWD eCos package (
into your configuration.
This may be achieved directly using ecosconfig add on the command line, or the Build->Packages… menu item within the eCos Configuration Tool.
Prior to the first configuration attempt the 3rd-party WICED-SDK sources need to be installed into the eCosPro source tree as per Section 193.2, “WICED-SDK Installation”.
The package also relies on specific WWD functionality being provided by the platform (or variant) HAL for supported targets. See Chapter 195, Platform/Variant HAL for an overview of the HAL support required.
194.2. Chipset Firmware
The Cypress/Broadcom WICED WiFi chipsets require a binary firmware image to be downloaded to the WiFi chip for correct operation. For some platforms the required binary firmware image is available as part of the installed WICED SDK. However, the WICED SDK does not have support all platforms and the configuration world allows for the firmware binary images to be located outside the user installed WICED SDK tree.
For example the Raspberry Pi platforms use binary images
included as part of the
CYGPKG_NET_WIFI_BROADCOM_WWD package. For
reference these images are located in individual
sub-directories in the eCosPro
- This directory holds the 3rd party binary firmware image for the Raspberry Pi 3B and and Raspberry Pi 0W platforms.
- This directory holds the 3rd party binary firmware image for the Raspberry Pi 3B+ platform.
README.txt is present in each
sub-directory describing from where the 3rd-party binary blobs
When porting the WWD driver to a new platform it may be necessary to acquire a suitable binary-blob to match the Cypress chipset being used and the hardware I/O configuration of the platform.
194.3. Configuration Options
Once added to the eCos configuration, the WWD package has a number of configuration options. As well as the core CDL options for the common WWD support, a WICED-SDK version specific set of CDL options are also available.
Most Cypress/Broadcom WICED WiFi chipsets require a binary firmware image to be downloaded to the WiFi chip.
Where the platform provides the necessary support, this option can be enabled to configure the application to access non-memory-mapped resource images. If disabled then the resource binaries are built into the application binary. For example, with platforms where limited amounts of (on-chip) direct memory are available the size of the required firmware binary blob could severely limit the usable application code size.
Please read the relevant platform specific documentation for details of any requirements, or processes, involved in initialising the non-memory-mapped firmware storage.
This option allows the selection of the base WICED module to be targetted. Normally the configured eCos target (platform HAL) configuration will force a suitable value, and the developer should not need to manually configure this setting.
Similarly, depending on the configured module, the
CYGPKG_NET_WIFI_BROADCOM_WWD_CHIPSEToption defines the Cypress/Broadcom WiFi chipset to be configured.
- This option selects the transport bus used between the WICED module host CPU and the WiFi controller Normally the configured eCos target (platform HAL) configuration will force a suitable value, and the developer should not need to manually configure this setting.
This is the main option for selecting the supported WICED-SDK version to be used. As mentioned in Section 193.2, “WICED-SDK Installation” the relevant WICED-SDK source should be present in the package
As appropriate, WICED-SDK version specific CDL options are then made available to the system. These are not normally user-editable since they are primarily hooks for the config and build systems.
This option, and its associated sub-options, are primarily for development of the driver internals. It is not normally expected that the application developer making use of the WWD package will ever need to enable the debug features.
If enabled this option provides access to a set of individually controllable diagnostic options. These can be used to provide low-level
diag_printf()diagnostic output. It should be noted that some diagnostics if enabled will adversely affect the performance of the system such that incorrect behaviour can result.
As well as the WWD package specific options, the lwIP configuration
will affect how the WWD driver is configured. For example the
for the MTU of the WWD layer is limited to what will fit within a
single lwIP buffer, and so the setting is based on the relevant lwIP
package configuration. The developer may need to tune the lwIP memory
footprint to reflect both the expected usage of the system and the
available memory at run-time.
|2021-10-22||eCosPro Non-Commercial Public License|