User Manual

System Architecture

One of the key challenges creating the WICED Feather is that it is based on the Broadcom WICED WiFi stack, and due

to the license terms we're unable to release any of the source files.

This poses a bit of a dilemma since we tested almost every embedded WiFi stack out there, and WICED easily climbed

to the top in terms of features, performance and reliability. We want that reliability and speed, but we also want to

make sure customers have the flexibility to bring all kind of projects to life as well, without having to sign restrictive

license agreements themselves.

So how do we make this available to customers in a way they can use in the real world, without signing NDAs

themselves?

The answer wasn't obvious at first, but FeatherLib was the end result of a lot of head scratching and firmware dead

ends.

WICED WiFi + RTOS + SDEP = FeatherLib

The proprietary Broadcom WICED WiFi stack is designed around an RTOS (Real Time Operating System), which

handles all of the various tasks involved in WiFi, such as async data requests, security and cryptography, etc. (If you're

not familiar with them, an RTOS breaks tasks into 'threads', and then shares MCU cycles between those threads,

allowing you to effectively multi-task on a single MCU.)

The RTOS and all of the proprietary Broadcom WiFi stack and code runs behind the scenes in a binary black box we

call the FeatherLib (see the Flash Memory Layout section below for details). By providing a binary black box, we solve

the legal hurdles of working with WICED, but this still leaves the problem of exposing the WiFi functionality to end user.

We solved this by essentially 'wrapping' every useful function in the WICED stack with a custom command (using an in

house protocol called SDEP), and then routing these commands between the Broadcom SDK in FeatherLib and end

users. We can freely expose the source related to the SDEP commands (since we wrote 100% of it), while still hiding

the proprietary Broadcom functions, header files and structs. The lawyers are happy, and hopefully our customers are

too!

By basically reimplementing the entire Broadcom WICED WiFi stack with a new set of SDEP commands and a more

focused custom API, you get access to Broadcoms high quality stack, without any of the legal headaches. The

headaches were all on our side reimplementing the wheel just to solve a legal problem. :)

Arduino User Code

This left the problem of how to allow users to write code themselves that talks to FeatherLib via SDEP.

Since FeatherLib runs on an RTOS, we start a single RTOS 'thread' at startup that is used for the user code. FeatherLib

will start the Broadcom WiFi stack, and as part of that process it also start the 'user code' thread that runs the custom

code that you write and compile in the Arduino IDE.

This custom user code is built in the Arduino IDE like you would for any other MCU, and gets written into a dedicate

section of flash memory with it's own chunk of SRAM reserved purely for the user code in Arduino land.

This setup allows you to share the MCU processing time between your own code and the lower level WiFi stack, but

the process should normally be invisible to you, and you never really need to worry about the FeatherLib black box.

Inter Process Communication (SDEP)

Communication between the user code and the Feather lib happens via an in-memory messaging system, sending and