Host library for controlling a WiConnect enabled Wi-Fi module.

Dependents:   wiconnect-ota_example wiconnect-web_setup_example wiconnect-test-console wiconnect-tcp_server_example ... more

Embed: (wiki syntax)

« Back to documentation index

Library Overview

Library Overview

Overview

The WiConnect Library runs on a host MCU and controls a WiConnect enabled WiFi module. This library is essentially a programming API for the WiConnect serial command set. More infomation about the serial command set may be found here: WiConnect Reference Guide

The library may be downloaded from here: WiConnect Repository

Important Notes

  • This class is implemented as a 'singleton'. This means it only needs to be instantiated once.
  • The WiConnect library does NOT call the global 'new' or 'malloc' functions. All memory allocation (if required) comes from a user supplied malloc function pointer or buffer

Library Settings

The WiConnect Library has multiple settings so as to allow for the most flexibility within a user's application.

Some of these configurations are as follows:

  • Blocking / Non-blocking
  • Dynamic / Static allocation
  • Asynchronous Processing

Blocking / Non-blocking Modes

The WiConnect Library may be configured for either 'blocking' or 'non-blocking' operation:

  • blocking - API calls do not return until they complete successfully or timeout.
  • non-blocking - API calls return immediately. The caller should check the return code to see if the command is still processing, completed, or an error occurred. The caller should continue to call the API function (as often as possible) until it returns either a success or error code.

Blocking Mode

In blocking mode, an API function will block until it completes. More details to come...

Non-Blocking Mode

In non-blocking mode, an API function returns immediately. More details to come...

Dynamic / Static Allocation

There are two cases when memory allocation is required:

  • Buffer allocation
  • Class instantiation

In both cases, either static or dynamic memory allocation may be used.

In cases when memory allocation is needed, the API call requires a buffer pointer and length parameters. If both are supplied, the library uses the supplied external buffer. This is considered static allocation (however the buffer could have been dynamically allocated). The caller is responsible for maintaining the supplied buffer.

If, however, only the buffer length is supplied and the buffer pointer is NULL the Wiconnect Library will call the user supplied malloc() function. This is considered dynamic allocation. In this case, the library will maintain the buffer and release it when necessary using the user supplied free() function.

Note:
To use dynamic allocation the WiConnect Library must be compiled with WICONNECT_ENABLE_MALLOC defined, and the Wiconnect() constructor must be supplied with pointers to malloc() and free() functions.
The Wiconnect Library does NOT call the global 'new' operator. Classes that are internally instantiated overload the 'new' operator and either call the user supplied malloc() function or use the supplied static buffer.

Asynchronous Processing

When applicable, the WiConnect Library will asynchronously process commands in the background. When the background processing completes, the supplied callback is called.

User commands may also be executed in the background using the enqueueCommand() API function.

Note:
The WiConnect Library must be compiled with WICONNECT_ASYNC_TIMER_ENABLED defined for background processing to be enabled.

Sending Commands To WiFi Module

More details to come...