CC3000 Host Programming Guide

From Texas Instruments Embedded Processors Wiki

Jump to: navigation, search
Translate this page to   


This wiki addresses the software package that is provided by TI for an external microcontroller that acts as a host processor. The software package implements the CC3000 host driver and a demonstration application.

Contents

Related Documents

  1. CC3000 Host Driver API document
  2. CC3000 First-Time Configuration

Assumptions

Familiarity with:

CC3000 Host Driver Architecture Overview

Overview

The CC3000 product is designed to be a WLAN peripheral device that is simple to integrate and easy to use. For this purpose, the CC3000 device integrates a fully-featured 802.11 protocol stack, personal security supplicant for 802.11, and an internet protocol (IP) networking stack. The CC3000 host driver is designed to enable access to the CC3000 hardware with minimal burden to the host platform.

The key properties of the CC3000 host driver are:

System Block Diagram

The figure below shows the CC3000 host driver modules
Cc3000 driver diagram.PNG

Description

The system has two demarcation lines:
• CC3000 user application programming interfaces (APIs)
• Transport layer APIs

This document focuses on the user APIs and architecture and the serial peripheral interface (SPI). The CC3000 user APIs define interfaces (I/Fs) exposed to the end user that allow interaction with the CC3000 device. Interaction with the device occurs over an SPI transport layer according to the device-specific APIs. APIs reside on top of an encapsulation layer called the host controlled interface (HCI). APIs are defined in a manner that is agnostic to the SPI layer.

The user APIs are organized into four silos to reflect the four different entities that correspond within the device (see figure below). These are:


Cc3000 host api.PNG

Each API group has associated commands and events. Events include two main types: unsolicited events and events triggered by the device.

By Structure

API Function Calls

API function calls are commands issued by the user from the application layer that trigger an activity of the device. The resulting behavior is function-specific and determined by the definition of the function and the context to which it is applied. The description of each API function reflects its expected behavior and use context. Unless otherwise specified, all functions have a return code that is delivered from the device using a command completion sequence specified in the events section.

*Queuing of commands or events is not available as part of the CC3000 host driver. As a result, only one outstanding command is processed at a time.
*ALL API function calls are blocking unless stated otherwise; thus, the user context is blocked until the API call executes. This does not imply, for example, that the function call does not return until the whole process triggered by the API command is finished. The function call returns as soon as the command is passed over transport to the device and the command response event is received (as described in the Command Response Events section).

Events

An event is a device-triggered behavior that results in an interruption of the host processor. Two types of events are generated by the CC3000 device:

Command Response Events

Command response events are generated as a result of a command issued to the device when the command has reached the point that either the command is completed or the long-term process is triggered. It is used by the device to return control to the caller with the appropriate result. Command response events carry an opcode that corresponds to the opcode of the command (API) that generates them and a status that reflects the return code of the calling function.

Unsolicited Events

The system provides unsolicited events triggered by the device. These events are generated asynchronously to indicate an occurrence of a system event. The following figure shows the basic event sequences:
Unsolicited Events Sequence.jpg

Unsolicited events that are generated by the device have their own unique opcode.

A callback function that corresponds to the event is invoked and carries on event handling thereafter, if the callback is registered by the user application.

All unsolicited events can be masked using a special command that controls the event mask. Command completion events cannot be masked (because they deliver the result code and thus are required to maintain API integrity) and are not passed to the user application.

Because there is no queuing mechanism within the CC3000 host drive, the hci_unsolicited_event_handler function must be called by the user periodically each 500 ms. The function determines if unsolicited event handling is required and, if so, triggers the appropriate callback function. The periodic call to the function can be executed either in the dedicated context of the timer interrupt, for example, or within the main loop of the user application, as occurs in the Basic WiFi Applications.


Unsolicited Events list

The following lists all of the asynchronous events that can be generated by CC3000 device:

Special Events

There is one exceptional unsolicited event for which a callback is not possible: The purpose of the unsolicited Number Of Completed Packets event is to notify the host driver that data packet transmission has occurred. For more information, see the section on Data Transmission and Reception.

Callbacks

Callbacks are user-provided functions that carry a predefined template and deliver unsolicited events to a user-controlled implementation or to trigger a system behavior of the user application. The number of callbacks used by the CC3000 driver is minimized to avoid any processing overhead incurred by the callback mechanism. The callbacks inform on asynchronous events that occur during operation. It is impossible to call an API function from the callback context. The callbacks supported by the CC3000 driver are:

Allows processing on initialization completion and enables an asynchronous initialization procedure for the device. In systems with other activities to commence in parallel with CC3000 system initialization, init callback provides notification that the device is ready to connect and resume WLAN networking-related activity.
Delivers system-triggered events to the user for user-specific handling.
Provides the CC3000 device with an initialization script if it is stored in the host file system by the user application. The user can provide a callback function for the event handler of the patch request event that comes from the CC3000 device.


Example Breakthrough of the API Function Call

Overview

This section provides a brief guided code overview, including a discussion of function calls within an example API function call, starting from the highest layer (API call) to the lowest layer (SPI interaction).

API Call Example

For example, consider an implementation of a socket API:

When a socket function call is executed, the API function socket encapsulates all of the required API-specific parameters in the packet to be sent over the SPI and passes those parameters to the host-controller interface (HCI) layer. The HCI layer adds HCI-specific parameters to the packet and passes the packet to the SPI transport layer. An SPI transport layer sends the packet over the SPI based on the SPI protocol. The following figure shows the resulting packet
API packet structure.jpg

From the code perspective, the following code is within the API call: 

socket(int domain, int type, int protocol)
{
    unsigned short int arg_len;
    int ret;
    unsigned char *ptr;
    bsd_socket_args_t *args;

    arg_len = 0;
    ret = EFAIL;
    ptr = tSLInformation.pucTxCommandBuffer;
    args = (bsd_socket_args_t *)(ptr + HEADERS_SIZE_CMD);
 
    //
    // Fill in HCI packet structure
    //
    arg_len = sizeof(bsd_socket_args_t);

    args->domaint = domain;
    args->protocol = protocol;
    args->type = type;

    //
    // Initiate a HCI command
    //
	hci_command_send(HCI_CMND_SOCKET, ptr, arg_len);

    //
    // Since we are in blocking state - wait for event complete
    //
    SimpleLinkWaitEvent(HCI_CMND_SOCKET, &ret);
      
    //
    // Process the event 
    //
    errno = ret;
    
    set_socket_active_status(ret, SOCKET_STATUS_ACTIVE);
    
    return(ret);
}

You can see that socket parameters, such as socket type and socket domain are inserted into the buffer at the offset: 

args = (bsd_socket_args_t *)(ptr + HEADERS_SIZE_CMD);
args->domaint = domain;

As soon as preparation is complete, the packet is passed to the HCI layer, which updates the HCI layer header of the packet: 

hci_command_send(HCI_CMND_SOCKET, ptr, arg_len);

The function returns only after the Command Complete event returns from the CC3000 device: 

SimpleLinkWaitEvent(HCI_CMND_SOCKET, &ret);

Note the use of the sizeof operator: 

arg_len = sizeof(bsd_socket_args_t);

It is assumed that the arguments bsd_socket_args_t are of packed type and int is defined as 4 bytes. While porting the code to a different MCU, you must stay within these assumptions, or replace each int variable with an explicit long type.

HCI Layer Example

The HCI layer encapsulates a packet received from the API with the opcode total length and submits it for transmission to the SPI transport layer as follows. 

unsigned short 
hci_command_send(unsigned short usOpcode, unsigned char *pucBuff,
                     unsigned char ucArgsLength)
{ 
    hci_cmnd_hdr_t *hci_cmnd_hdr_ptr;
 
    hci_cmnd_hdr_ptr = (hci_cmnd_hdr_t *)(pucBuff + SPI_HEADER_SIZE);

    hci_cmnd_hdr_ptr->ucType = HCI_TYPE_CMND;
    hci_cmnd_hdr_ptr->usOpcode = usOpcode;
    hci_cmnd_hdr_ptr->ucLength = ucArgsLength;

    //
    // Update the opcode of the event we will be waiting for
    //
    SpiWrite(pucBuff, ucArgsLength + sizeof(hci_cmnd_hdr_t));


    return(0);
}

The function receives as an argument an opcode of the command to be sent, a pointer to the buffer, and the length of arguments as part of the buffer. First, space for the SPI header is made at the beginning of the buffer, and then the required fields in the buffer are filled. Because the offset of arguments within the buffer is the same for all commands, there is enough room left for the HCI parameters. Pay attention to the use of the sizeof parameter in the function. Ensure that the structures are packed and int is 4 bytes long or otherwise change the int type to the long type.

The function call to the SPI driver submits a packet for actual transmission: 

SpiWrite(pucBuff, ucArgsLength + sizeof(hci_cmnd_hdr_t));

This triggers a Host write operation to the CC3000 device and only after the whole transaction over the SPI finishes does the hci_command_send function return. The same blocking behavior is observed in all HCI layer functions.

CC3000 SPI Operation

Overview

The SPI is based on the five-line, master/slave communication model as shown in the following figure:
Masterslave communication model.jpg

The lines are described as follows:

I/O Description
CLCK(1) Clock (0 to 26 MHz) from host to slave
nCS(2) nCS (active low) signal from host to slave
MOSI Data from host to slave
IRQ(3) Interrupt from slave to host
MISO Data from slave to host


Protocol Description

The SPI protocol is used to communicate with the CC3000 device from the host MCU that is acting as the SPI master while the CC3000 device is the SPI slave. The protocol is an extension of the existing standard SPI. The endianness on transport is assumed to be most-significant bit (MSB) first. The clock and phase settings for the SPI are CPHA 0 and CPOL 0, meaning that the data is sampled on the falling edge of the clock cycle.

All data sent or received over the SPI interface must be 16-bit aligned. A padding byte is added where required. Each packet passing on the SPI bus consists of a 5-byte SPI header followed by user data and optionally by a padding byte so that the whole length is 16-bit aligned, as shown in the next Figure.
SPI header.jpg


The first byte of the header is an operation opcode (READ or WRITE) followed by two bytes that indicate the size of the payload length (including the alignment byte). Two busy bytes then follow to conclude the header.

The data payload directly follows the last byte of the header. The padding byte is added when the length of the payload part of the packet is even.

Master Write Transaction

There is a slight difference between the first master write transaction after power up and the rest of the write transactions. The difference follows from the internal CC3000 implementation of SPI.

Master Write Transaction Header
The header precedes each data packet. The structure of the header (see figure below) is independent of whether or not it is a first write transaction.
Master Write Transaction Header.jpg


The first byte of the header is the write opcode followed by two bytes that indicate the size of the payload length (including the alignment byte). Two busy bytes then follow to conclude the header.

The data payload directly follows the last byte of the header. The following summarizes the header structure: 

Write = Opcode for write is 0x01
M<sub>MSB</sub>, M<sub>LSB</sub> = 16-bit data payload length (including alignment byte)
Busy = Busy byte (0x00)
Busy = Busy byte (0x00)
First Host Write Operation

The first write transaction to occur after release of the shutdown has slightly different timing than the others.

The normal Master SPI write sequence is nCS low, followed by IRQ low (CC3000 host), indicating that the CC3000 core device is ready to accept data. However, after power up the sequence is slightly different, as shown in the following Figure:
CC3000 Master SPI Write Sequence After Power Up.png
The following is a sequence of operations:
  1. The master detects the IRQ line low: in this case the detection of IRQ low does not indicate the intention of the CC3000 device to communicate with the master but rather CC3000 readiness after power up.
  2. The master asserts nCS.
  3. The master introduces a delay of at least 50 μs before starting actual transmission of data.
  4. The master transmits the first 4 bytes of the SPI header.
  5. The master introduces a delay of at least an additional 50 μs.
  6. The master transmits the rest of the packet.
Generic Host Write Operation
  1. The master asserts nCS (that is, drives the signal low) and waits for IRQ assertion.
  2. The CC3000 device asserts IRQ when ready to receive the data.
  3. The master starts the write transaction. The write transaction consists of a 5-byte header followed by the payload and a padding byte (if required: remember, the total packet length must be 16-bit aligned)
  4. After the last byte of data, the nCS is deasserted by the master.
  5. The CC3000 device deasserts the IRQ line.
The following figure shows a master write transaction.
CC3000 Master Write Transaction.png



Master Read Transaction

The master read transaction is initiated by the CC3000 device by asserting (that is, driving low) an IRQ line while the bus is in IDLE state. If a master detects an IRQ assertion while in the process of initialization of the master write transaction, it is up to the master to resolve the order of read and write operations. If the master continues with the master write transaction, the deasserted IRQ can be treated as a deassertion that is required as a response to nCS. The following is a sequence:

  1. The IRQ line is asserted by the CC3000 device.
  2. The master asserts the nCS line.
  3. The master transmits the following 3 bytes: read opcode followed by two busy bytes.
  4. The CC3000 sends back the following data: the first two bytes indicate the payload length and the data payload bytes follow, immediately after.
  5. At the end of read transaction, the master drives nCS inactive.
  6. The CC3000 device deasserts an IRQ line.

The following figure shows the master read transaction process.

CC3000 Master Read Transactoin v2.png


Master Read Transaction Header

The following summarizes the master read transaction header structure: 

Read = Opcode for write is 0x03
SMSB, SLSB = 16-bit data payload length (including alignment byte)
Busy = Busy byte (0x00)

Example Implementation of SPI

The following two sections present two example implementations of the CC3000 SPI interface in terms of state-machines. The first implementation is based on the MSP430, which does not use DMA during read/write operations (also called the busy waiting approach) and thus the state-machine is much easier but more MCU tight. The second implementation is based on the LM3S9B96 Stellaris, which uses DMA for data transfer to or from the SPI.

Busy Waiting SPI Implementation

Write operation
The following figure shows the write operation flow.
CC3000 Write Operation Flow.png

In this implementation the write operation is performed from the context of the interrupt on the IRQ line.


Read operation
The following figure shows the read operation flow.
CC3000 Read operation flow.png

In this implementation the interrupt on the IRQ line is enabled after processing the received data.

DMA based SPI implementation

Direct memory access (DMA)-based operation has more states to handle compared to nonDMA-based operation. Moreover, it is a more asynchronous-like implementation based on interrupts from the DMA module.

Write operation

The following two figures show SPI write implementation for the DMA-based SPI.

A limitation of the LM3S9B96 data buffer prevents more than 1024 bytes from being copied in one transaction of the DMA from RAM to the SPI FIFO; thus, two DMA transactions are required.
CC3000 DMA-Based Write Operation Flow (1 of 3).png
After the nCS is activated, the host continues operating in main loop until IRQ interrupt detected.
CC3000 DMA-based write operation flow (2 of 3).png

After triggering DMA in the context of the IRQ interrupt handler to write the whole packet or part of the packet as described, the context returns to the main loop, while the SPI portion waits for the DMA-complete interrupt (see figure below).
CC3000 DMA-based write operation flow (3 of 3).png

Read operation
The following figure shows an SPI read operation of the DMA-based implementation of the SPI interface. The read operation is triggered by an IRQ line activation and reception of the interrupt on the IRQ line.
Interrupt on IRQ low.jpg


After triggering a DMA to read first 10 bytes, the control returns back to the non-interrupt context, waiting for DMA complete interrupt.

DMA complete.jpg

CC3000 NVMEM API’s

Overview

The CC3000 device uses an NVMEM (EEPROM) to store radio frequency (RF) calibration parameters, network configuration parameters, and patches.

Most NVMEM locations are not written directly by the CC3000 host driver but rather indirectly by API calls that trigger NVMEM changes; for example, the wlan_add_profile API call triggers the addition of the WLAN profile to the NVMEM.

Nevertheless, special API functions allow read or write operations on the NVMEM by the CC3000 host driver.

EEPROM structure overview

The table below describes the EEPROM structure.
Cc3000 eeprom org.PNG

     (1) Offsets 0, 1, 3, 7, 9: CC3000 generated section: Refers to the part of NVMEM that is self-generated by the CC3000 device or to the section that is generally updated by module vendors.

     (2) Offsets 2, 6, 8, 11: Customer configurable section: Refers to the section that is configured by the customer, mainly indirectly.

     (3) Offsets 4, 5, 10: TI service pack section: Programmed with the help of APIs but with content provided by TI.

EEPROM data consists of several files accessible either directly or indirectly. The indirect approach triggers the CC3000 host, which at the end writes to EEPROM. The direct approach triggers CC3000 NVMEM API calls to directly write to the file within EEPROM. Each file has a unique ID and, depending on the file, either a constant or variable size. The following files are modified by customers by triggering the appropriate APIs (indirect approach):

The content of these files is a patch provided by Texas Instruments for different parts of the CC3000 device. Patches can be upgraded but only using the files provided by TI.

EEPROM Update

MAC Address update process

The EEPROM can be updated directly using NVMEM APIs of the CC3000 device and indirectly using different APIs that invoke updates, such as the addition of profiles, which stores a profile in the NVMEM. It is recommended that most EEPROM content not be altered directly. The file that can be altered using NVMEM_Write operation is: MAC Address file – file ID NVMEM_MAC_FILEID.

The following figure shows the MAC update process.
MAC update process.png

Patches Update Process – Download of Patches from Host

CC3000 patches can be sored in the CC3000 Host and downloaded from it. Please refer to the CC3000 Patch Programmer application and guide.

CC3000 WLAN API

Overview

CC3000 WLAN APIs provide a way for the application to trigger the connection process, update WLAN policy, and perform scans to discover the WLAN AP. This section describes basic activities required to implement WLAN operations. The following basic operations are required to be performed on the CC3000 device related to WLAN.

Creating Profiles and Policies

WLAN policy defines three options available to connect the CC3000 device to the AP:

The device must be reset before a policy can be applied. Profiles must first be added to the CC3000 device before they can be used.

A WLAN profile provides the information required to connect to a given AP, including the SSID, security parameters, and AP keys. Each profile describes one AP. Because profiles are stored in the NVMEM, they are preserved during device reset. To add a profile, use the following API: wlan_add_profile(SSID, security params, priority) ;


Creating WLAN Connection

The following methods can be used to create a WLAN connection:

First time configuration

The first-time configuration is used to set up a WLAN configuration of the device when the final product (for example, a sensor connected to the CC3000 device) has no input/output capability. For more information on the first-time configuration process, see the CC3000 First-Time Configuration Guide Wiki.

The first-time configuration provides a means to create a profile that is stored in the CC3000 NVMEM. The connection behavior depends on the policy. The following figure shows a generic flow of operation for the first-time configuration and assumes that the device wants to connect automatically to the AP described by the profile.
FirstTimeConfig process.PNG

Please note that there is currently a limitation in First Time Configuration: Up to 3 First Time Configuration profiles can be stored in the non-volitile memory. Attempt to run 4-th time First Time Configuration, may succeed, yet the profile will not be stored in the NVMEM and device will not be able to establish a connection. Note also that running first time configuration twice to the same AP, will create 2 different profiles.

Creating WLAN Connection explicitly

If the SSID of the AP to connect is known, the CC3000 device can be required to connect explicitly to this AP. The application can require one-time configuration to the AP, in which case the policy must be set to all zero, or it can require connecting to the same AP each time. The following figure shows the sequence required to connect explicitly to the AP one time.
Creating an explicit connection to AP.png

Using WLAN policy and profiles

WLAN policy determines how the CC3000 device automatically connects to the AP. More specifically, the wlan_set_connection_policy controls the following:

Profiles describe an AP: Each profile includes the SSID of the AP together with the security parameters required to connect to the AP. To add a profile and connect to the AP using the profile, the flow shown in the figure below can be used.
Connecting by a help of policy and profiles.png


Multiple profiles were added In the flow shown in the figure below. In this situation, connection is attempted to the highest priority AP. If connection to the highest priority AP fails, connection is attempted to the next highest-priority AP, and so on until a connection is successful.

Performing WLAN scan

A WLAN scan detects nearby APs along with the received signal-strength indication (RSSI) at which the APs are heard and allows the CC3000 device to connect to the detected APs (see figure below). The first WLAN scans must be enabled using the wlan_ioctl_set_scan_params WLAN API; the following scan results can then be read using the wlan_ioctl_get_scan_results WLAN API.

Enabling and reading scan results.png

CC3000 Socket API

Overview

Socket layer APIs establish TCP/IP connectivity between devices, assuming that the underlying WLAN transport is initialized and connected. Because all API socket layer APIs are blocking by nature, the socket layer APIs are almost identical to the standard BSD layer APIs.

Socket operations must follow a successful WLAN connection.

Data Transmission and reception

Data Transmission Overview

Data transmission occurs through the socket layer interface using the standard commands, Send and Sendto, that are part of the BSD API. Selecting which command to use depends on the socket type: for TCP, use Send; for UDP, use Sendto. The fact that Send and Sendto are blocking APIs does not guarantee that the data has been sent over the air on return from the function call rather than received and stored in the CC3000 internal TX queue. Moreover, the CC3000 host driver and the CC3000 device exchange information on the number of free buffers during device initialization. From that point on, the CC3000 host driver does not submit for transmission packets if there are no free buffers on the CC3000 side. The following figure shows how this is achieved:
Registration process.jpg


At initialization the number of free buffers is stored in a variable on the CC3000 host driver side. Each attempt to send tests the variable. If its value is more than 0, sending the packet proceeds and the value of the variable is reduced by 1. Otherwise, the packet must wait in a busy loop until the value becomes greater than 0. The number of completed packets event comes as an unsolicited event; thus, a frequency of the transmission operation influences a frequency of calls for the unsolicited event handler.

Data Reception Overview

Data reception is achieved using the Recv or Receive_from command, depending on the socket type. Use Recv for TCP sockets; use Recv_from for UDP sockets.

Concatenation is not supported by the CC3000 host driver. If the socket transmits packets of length N, the reception flow expects to read up to N bytes.
Receive/Receive_from commands function as blocking APIs: The function returns either on timeout of socket activity or when data is received. If it is required to poll for data presence on a given socket, select functionality can be used, as shown in the figure below.
Take action based on return sockets.jpg

The following code describes the use of the select functionality: 
FD_ZERO( &readSet );
FD_ZERO( &writeSet );
FD_ZERO( &exceptSet );
        
FD_SET( ReadSock,  &readSet); 
FD_SET(WriteSock,   &writeSet);  
        
rc = select( MAX(ReadSock, WriteSock)+1, &readSet, &writeSet, &exceptSet, timeout );
        	
// perform send on the write socket if it is ready to receive next chunk of data
if (FD_ISSET(WriteSock, &writeSet) )
{
….
}
            
// perform read on read socket if data available
if (FD_ISSET(ReadSock,  &readSet))
{
// perform receive
}

TCP Socket API

Client TCP socket connection

The following figure shows the flow required to open a regular TCP client connection.
TCP socket connection.png

Server TCP sockets connection

The main distinction between a client connection and a server connection is that when establishing the server TCP connection, a stage occurs during which the device listens on the server socket for incoming connections. The connection is established only after a request arrives. On the other hand, the client TCP connection is established as soon as connect() is called. The following shows the flow used to establish a server connection.
Server side connection establishment flow.png

Sending and Receiving data over TCP socket

Data is transmitted and received over TCP sockets after a connection is established. The BSD API Send and Recv commands are used with TCP sockets; Sendto and Recvfrom API commands are used transmit and receive data with UDP sockets.

Because the data is sent over the TCP connection-oriented socket, the peer device ACKs the data only once when TCP_WINDOW is full or after timeout expires. Usually TCP_WINDOW is 1 KB; thus, sending a TCP packet that is too short significantly decreases network performance.

UDP Socket API

Client UDP socket connection

Because of the connectionless nature of the UDP, the client UDP connection requires only the creation of the socket (see figure below).
Client UDP connection.png

Please note that it is recommended to run a gethostbyname bsd command before the first ever transmission of data over the new socket.In case DNS server, which is required by gethostbyname is unavailable, it is recommended to run netapp_ping_send API command which is available in the group of netapp API's.

Server UDP socket connection

Running the UDP server requires only that the bind operation be performed on the created socket. The Sendto and Recvfrom API commands are used to send or receive data (see figure below).
Server UDP connection.png

CC3000 NETWORK CONFIGURATION API

Overview

Configuration API is provided in order to allow host to perform basic configuration of CC3000 device such as:

Configuring MAC and IP Address

Configuring the MAC address requires running the NVMEM Write API call with file ID 6.

The IP address has two possible configurations: Assignment of the static IP address or using DHCP.

For the static IP configuration, the NetappDHCP API call is triggered with a non-0 IP address and subnetmask parameters. Otherwise, the 0 IP address is passed to the API call and informs a device that DHCP must be used. The following figure shows the required behavior.
Configuring MAC and ip address.png


Reading network status

A user application might want to read the network status of the connection; for example, an IP address received by the DHCP or the AP of a device connected using profiles (if more than one profile is defined).

The following API call can be used to read the network status of the connection: 

void netapp_ipconfig( tNetappIpconfigRetArgs * ipconfig )

Where the pointer to the tNetappIpconfigRetArgs points to the structure filled with the configuration on return from the function call. For details on the structure, see the CC3000 API Doxygen Documentation. 

void netapp_ipconfig( tNetappIpconfigRetArgs * ipconfig )


Site Map



E2e.jpg For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article CC3000 Host Programming Guide here.
Hyperlink blue.png Links
ARM Microcontroller MCU ARM Processor Digital Media Processor Digital Signal Processing Microcontroller MCU Multi Core Processor
Ultra Low Power DSP 8 bit Microcontroller MCU 16 bit Microcontroller MCU 32 bit Microcontroller MCU

Retrieved from "http://processors.wiki.ti.com/index.php/CC3000_Host_Programming_Guide"
Leave a Comment
Personal tools
Namespaces
Variants
Actions
Navigation
Print/export
Toolbox