dcsimg
Skip to end of metadata
Go to start of metadata

 

 

Background: 

Wi-Fi has long been the de-facto standard for adding wireless connectivity to personal computers. Recently, Wi-Fi has also seen increasing use in the embedded world as the Internet of Things (IOT) concept has increased in popularity. The Atmel Winc1500 is a wireless network controller SoC designed for IOT applications. The Winc1500 allows users with minimal RF and TCP/IP experience to quickly and easily add Wi-Fi connectivity to their embedded designs. This purpose of this article is to give the user some background on the Winc1500 as well as provide several examples to help them get started. 


Wi-Fi Basics: 

General:

  • Wi-FI is the commercial name for IEEE 802.11 wireless LAN standard 

  • Common versions of the standard being used today are 802.11b, 802.11g and 802.11n

  • Wi-Fi certification, which is needed in order to use the Wi-Fi logo, is administered by the non-profit group Wi-Fi Alliance

RF:

  • Operates on the 2.4 GHz and 5 GHz unlicensed bands. Note: At the current time, the Winc1500 only works on the 2.4 Ghz band 

  • Newer and upcoming versions of the Wi-Fi standard (eg. 802.11ah) allows operation on other frequency bands such as the sub 1 GHz unlicensed band and  the "white space spectrum" of the broadcast TV bands.

  • Operates on a static RF channel. No frequency hopping is employed. 

  • The 2.4 GHZ band is divided in to fourteen 20MHz wide channels. The 5 GHz band is divided into twenty-four 20MHz wide channels. 

  • The 802.11n standard also allows the use of 40 MHz wide channels in the 5 GHz band. 
  • Depending on the region, it may not be legal to operate on every channel. For example, in North America, only channels 1 through 11 are available for use in the 2.4 GHz band.

Security:

  • The Wi-Fi standard uses a variety of security algorithms to ensure a secure connect between stations and access points. The current algorithms being uses are: WEP, WPA/WPA2 and WPA Enterprise 

  • WEP/Wired Equivalent Privacy - Oldest security algorithm used for Wi-Fi networks. Superseded by WPA and WPA2. 

  • WPA & WPA 2/ Wi-Fi protected access - Newer standard that implemented several security improvements over WEP. WPA2 fixed several issues present in the original WPA algorithm. Sometimes referred to as WPA-PSK/WPA2-PSK

  • WPA Enterprise- Version of the WPA algorithm that utilizes an authentication server to verify devices that want to connect to a network. Sometimes referred to as WPA 802.1x 

Winc1500 IC's and Modules: 


Integrated Circuits
DeviceDescriptionComments
ATWINC1500A5x5mm 40L QFN pkg, 0.4mm pitch, 4 Mbit flashRevA of the Winc silicon, Obsolete-replaced by the rev B silicon
ATWINC1500B5x5mm 40L QFN pkg, 0.4mm pitch, 4 Mbit flashRevB of the Winc silicon, low power mode added, hardware security engines added (SHA 256 etc...)
ATWINC1510B5x5mm 40L QFN pkg, 0.4mm pitch, 8 Mbit flashSame as RevB silicon, but has more flash memory

 

 

Modules
DeviceDescription
ATWINC1500-MR210PAWINC1500 RevA, pcb antenna, Obsolete
ATWINC1500-MR210PBWINC1500 RevB, pcb antenna
ATWINC1500-MR210UBWINC1500 RevB, ufl connector
ATWINC1510-MR210UBWINC1510 RevB, ufl connector

 

 

Comparing the Winc1500 to other Atmel SmartConnect Wi-Fi Products:

The Atmel SmartConnect line offers three different Wi-Fi solutions, the Winc1500, the Wilc1000 and the SAMW25. This section compares the Winc1500 to those other devices. 

Wilc1000: 

FeatureWinc1500Wilc1000
Access Point Mode1 client onlyUp to 8 clients
Station ModeYesYes
Concurrent AP/STA ModeNoYes
P2P ModeClient only

Client mode and GO mode up to 8 clients

Onboard FlashYes, either 4 or 8 MbNo
Standalone Operation (without a host MCU)YesNo
Over the Air UpdateYesNo
TC/IP and TLS StacksOn Winc1500On host MCU/MPU

 

In general, the Wilc1000 is a better choice for adding wifi connectivity to high end MCUs and MPUs or for devices that need to operate as an access point. The Winc1500 is a better choice for adding wifi connectivity to cost sensitive devices since it is capable of operating without a host microcontroller. The Winc1500 is also a good choice for adding Wifi connectivity to lower end microcontrollers since the TCP/IP and TLS stacks are contained on the Winc1500's stacked flash rather than on the host microcontroller. 

SAMW25:

The SAMW25 is a module that combines a Winc1500 with an Atmel SAMD21 Host microcontroller in a single package.This module also integrates a balun and either a pcb antenna or a ufl connector. The SAMW25 simplifies the hardware design of a project and offers a higher level of integration than a Winc1500 module, but costs significantly more. As far as the Wifi capabilities, the SAMW25 has the same features and limitations as the Winc1500.

Future EEwiki articles will look into the Wilc1000 and SAMW25 in greater depth. 

 

 

Winc1500 System Architecture:

 

A short description of several of the sections are listed below. A full description of each of the sections can be found in the Winc1500 software design guide, which can be found in the "Useful Links" section of this article 

APS3S-Cortus CPU - This 32 bit 40 MHz CPU executes the Winc firmware. This processor can also run a user's application from the stacked flash (i.e. run the Winc1500 in standalone mode) 

Winc TCP/IP Stack - Able to operate up to 7 TCP sockets (as client or server) and up to 4 UDP sockets (client or server). This stack supports IPV4 only. 

SPI Flash - Used to access the Winc's stacked flash. The Stacked Flash stores the firmware image and user's Cortus application. it also stores a "rollback image" when an OTA update is being performed. 

 

Winc Host Driver:

The WinC Host Driver is a C library that provides the API's that the host micro needs in order to control the Winc's Wi-Fi and Socket operations. It also includes a board support package which enables the driver to be ported to a large variety of microcontrollers.  

All of the host driver's API's and functions that are referenced in this article are highlighted in orange to make this article easier to follow. Their parameters are listed in blue

 

 

Winc Peripherals and External Interfaces:

  • 1x Slave SPI- Up to 48 MHz operating speed. Currently the best way to interface the Winc with a host micro. (i.e it's the only interface currently fully implemented in the Winc host driver.) 

  • 1X SDIO- Up to 50 MHz, 4 data lines. SDIO 2.0 compliant 
  • 2x UART- RS232 Standard, 3.25 Mbaud max. UART1 has a 2 pin interface. UART2 has a 4 pin interface. UART2 is implemented in the RevB silicon only.
  • 1x PWM- 10 bit resolution. Programmable from 2.44 KHz to 625 KHz
  • 3x General Purpose Timers- Part of the Cortus processor's subsystem, can generate interrupts
  • 2x General Purpose Timers- Not part of the Cortus's subsystem, can also generate interrupts
  • 1x General Purpose Timer-   Not part of the Cortus's subsystem, can not generate interrupts. 
  • 1x I2C Slave Interface- Can operate in standard mode (100 Kb/s) and fast mode (400 Kb/s)
  • 1x I2C Master Interface- Can operate in standard mode (100 Kb/s), fast mode (400 Kb/s) and high speed mode (3.4 Mb/s) 
  • 9x GPIO pins- Each one can be configured as either an input or an output. Some peripherals are implemented using the GPIO pins. For example, the SDIO uses 2 GPIO pins so when the SDIO interface is used, only 7 GPIO's are available.

Winc Modes of Operation: 

The Winc1500 can function in the following modes. 

  • Idle Mode 
  • Station (STA) Mode
  • Access Point (AP) Mode
  • Peer to Peer (P2P) Mode 
  • Monitoring mode (Sniffer mode) 

Idle mode:

The Winc1500 will enter this mode once the Winc1500 is initialized (when the m2m_wifi_init function is called). In this mode, the Winc's  IEEE 802.11 radio and Cortus CPU are disabled. In addition, any unused peripherals will also be disabled. The Winc1500 will still accept commands from the host microcontroller in this mode. 

Station mode: 

In this mode, the Winc1500 is capable of scanning for and connecting to access points.

Scanning - A user can start a scan by calling the m2m_wifi_request_scan API.

It is possible to adjust how long the Winc1500 scans each Wi-Fi channel before it switches to the next channel. The longer the device spends on each channel, the more likely it is to detect an AP. However, increasing this wait time also causes the Winc1500 to consume more power. The user can adjust the wait time by calling the m2m_wifi_set_scan_options API. The user is able to change which channels the Winc scans by using the m2m_wifi_set_scan_region API. 

 

Connecting - The Winc1500 is capable of connecting to an AP using two different methods which are listed below. 

  1. m2m_wifi_connect API - Calling this function will start a Wi-Fi connection. In order to use this function, the application needs to know the connection parameters for the AP, which also serve as the parameters for the m2m_wifi_connect function
     The m2m_wifi_connect API has the following form: m2m_wifi_connect(char *pcSsid, uint8 u8SsidLen, uint8 u8SecType, void *pvAuthInfo, uint16 u16Ch). The parameters are listed below: 
    1. pcSsid - Buffer holding the AP's SSID 
    2. u8SsidLen - Length of SSID. Note: This does not include the null terminator.
    3. u8SecType - AP Security type. The Winc1500 is capable of connecting to AP's using OPEN, WEP, WPA/WPA2 and WPA enterprise security. 
    4. pvAuthInfo - Authorization parameters (i.e password) needed to complete the connection. These vary with the security type being used. 
    5. u16Ch - Wifi channel used to make the connection. Since the Winc1500 currently only operates in the 2.4 Ghz band, this parameter can vary from 1 to 14. The user can use the value M2M_WIFI_CH_ALL(255) to instruct the Winc to scan each channel until if finds and connects to the specified SSID. 

  2. m2m_wifi_defualt_connect  API - Calling this function will start a Wi-Fi connection with an AP whose profile is cached in serial flash. In order to create a cached profile, the Winc must first successfully connect with the AP using the m2m_wifi_connect API. This method is useful if your application requires the Winc to quickly reconnect to an AP after it exits sleep mode since the m2m_wifi_defualt_connect will create a connection faster than m2m_wifi_connect will. Another method of using this API is to have the AP's profile provisioned in flash beforehand via HTTP provisioning. Atmel provides a very good of example of how to do this in the Winc1500 Software Design Guide which can be found under the "Useful links" section of this article. 

 

When using the m2m_wifi_connect and m2m_wifi_defualt_connect API's , it is important to remember that these functions completing successfully does not guarantee that a Wi-Fi connection will be established. These functions will only return errors when problems occur on the Winc1500's end of the connection.

 


Disconnecting - To disconnect from an AP, simply call the m2m_wifi_disconnect function. This will return the Winc to the Idle mode. 

AP mode:

The Winc1500 is capable of operating as an AP.  While using the Winc1500 in AP mode, it is important to remember the following: 

  • The Winc can only be connected to one station while operating as an AP 
  • OPEN and WEP security are supported 
  • STA/AP concurrence is not supported. 

The Winc1500 can be put into AP mode by using the m2m_wifi_enable_ap function. 


Configuring AP Parameters 

The m2m_wifi_enable_ap  function has a single parameter, the tstrM2MAPConfig structure. This structure contains all the configuration parameters for the AP. 

The AP parameters are as follows: 

  1. au8SSID -  SSID for the AP 
  2. u8ListenChannel - RF channel that the AP will operate on 
  3. u8KeyIndx -  WEP key index
  4. u8KeySz - WEP key size
  5. au8WepKey - WEP key size 
  6. u8SecType  -  AP security type, either WEP or OPEN
  7. u8SsidHide  -  Determines whether of not the SSID is visible to stations or not
  8. au8DHCPServerIP -  Server IP address for the AP 
  9. __PAD24__ - Padding bytes used for aligning the Wi-Fi frames

It is not always necessary to configure each parameter of the structure. For example, there is no need to set the WEP parameters if your AP will be using the OPEN security type.  The code block below shows the minimum amount of configuration needed to configure the Winc for AP mode with OPEN security. 

AP Parameter Config
                  /*Initialze AP parameters*/ 
 	tstrM2MAPConfig strM2MAPConfig;                      // Create AP parameter structure 
	strcpy((char *)&strM2MAPConfig.au8SSID, "Demo AP");  // Set SSID 
	strM2MAPConfig.u8ListenChannel = 6;                  // Set Wi-FI Channel to operate on 
	strM2MAPConfig.u8SecType = M2M_WIFI_SEC_OPEN;        // Set Wifi Security mode 
 
                    /* Enable AP mode */
	m2m_wifi_enable_ap(&strM2MAPConfig);

 

P2P mode:

Also known as Wi-Fi Direct, this mode allows two Wi-Fi enabled devices to communicate with each other without the use of a dedicated access point. This process begins with a Wi-Fi Direct device scanning for other Wi-Fi Direct devices. When another device is discovered, the devices will negotiate which device will function as the Group Owner (GO). The GO functions very similar to an AP. Once the GO is established, the other devices in the P2P group, (known as Clients), are able to connect to the GO in the same manner that STA's connect to AP's. It is important to note, that the role of GO cannot be transferred to one of the Clients in the group. If the GO leaves the P2P group, the group is destroyed and must be reformed in order for the devices to continue to communicate. 

The Winc1500 is capable of operating in Wi-Fi P2P mode as a Client only. The Winc will enter P2P mode when the m2m_wifi_p2p function is called. It will then enter a "Listen State" where it will wait for another Wi-Fi P2P device to initiate a connection. When negotiation occurs, the device which initiates the connection needs to assume the GO role. Once the P2P group is formed, the Winc1500 can connect to the GO as if it were an AP by using the m2m_wifi_connect function. The diagram below illustrates this process. 

 

Winc1500 P2P State Diagram: Image courtesy of Amtel's ATWINC1500 Software Design Guide

Note: There is a minor error in this diagram, the state on the left should read "Idle mode" instead of "Station mode" 

Sniffer mode:

In this mode, the Winc1500 will receive all packets on a selected wireless channel. The user is able to configure filters so that only specific types of packets are passed to the application. To enter the P2P mode from the Idle mode, call the function m2m_wifi_enable_monitoring_mode. This function has the form m2m_wifi_enable_monitoring_mode(tstrM2MWifiMonitorModeCtril *pstrMtrCtrl, uint8 *pu8PayloadBuffer, uint16 BufferSize, uint16 u16DataOffset). It's parameters are as follows:

  1. pstrMtrCtrl - Structure that specifies what type of frames need to be captured.
  2. pu8PayloadBuffer - Buffer used to store incoming packet 
  3. BufferSize -Size of incoming packet 
  4. u16DataOffset - Data offset

In addition to receiving packets in this mode, the Winc can also send raw Wi-Fi frames over the air. The user's application is responsible for creating and formatting the packets, the Winc will transmit the packets without modifying them. Packets can be transmitted by using the function m2m_wifi_send_wlan_pkt which has the form m2m_wifi_send_wlan_pkt( uint8 *pu8WlanPacket, uint16 u16WlanHeaderLength, uint16 u16WlanPktSize). The parameters are as follows.: 

  1. pu8WlanPacket - Buffer used to store the outgoing packet.  
  2. u16WlanHeaderLength - Packet header length 
  3. u16WlanPktSize - Size of the outgoing packet 

Changing from one mode to another: 

After the host MCU intitalizes the via the m2m_wifi_init API, the Winc will enter the Idle mode. To enter another mode from the idle mode, the host MCU needs to call that mode's respective connect/enable API. To enter another mode from a non-Idle mode, the host MCU must call that mode's disconnect/disable API. The disconnect/disable API will force the Winc back into the Idle mode. Once the Winc is in the Idle mode, the host MCU can then call the new mode's connect/enable API and enter that mode. The Winc cannot go from one non-Idle mode to another without first entering the Idle mode. In addition, it is also necessary to close all TCP and UDP sockets before the WINC1500 switches modes. The diagram below illustrates the mode change process. 

 

Winc Modes of Operation: Image courtesy of Amtel's ATWINC1500 Software Design Guide

 

 

 

 

 

Tutorials: 


 Creating a Winc1500 Project from Scractch Using ASF

 Objective

  • Demonstrate setup a Winc1500 project from scratch

Hardware

  • One SAMD21 Xplained Board
  • One Winc1500 Xplained Pro extension board
  • PC with Atmel studio 7 and terminal program installed.
  • One standard USB to USB micro cable.

Project Creation:

  1. Ensure that Atmel studios is at least version 6.2 or greater. Also ensure that the ASF version is 3.26.0 or higher 
  2. In Atmel studio, click on File->New->Project to generate a new project or press Ctlr+Shift+N
  3. In the "New Project" window that pops up, rename the project and select the GCC C ASF Board Project Option. Then click "ok" 
  4. A "board selection" window should now pop up. Select the proper microcontroller and board from the menus. For example, if you were using the SamD21 Xplained board as the host micro, you would select SAMD21J18A as your micro and SAM D21 Xplained Pro as your board. 
  5. You've created a blank project, now you need to add the necessary source files for the WINC1500 to function. Click on the ASF menu and select the ASF wizard or hit alt+W
  6. In the ASF Wizard, Select the Winc1500 from the available modules list. Click the "Add" button. 
  7. Click the "Apply " button, this will apply the changes to your project. 
  8. Next, ensure that the proper header files are included in the main.c file of the project. An example of this is shown below. The socket.h, m2m_wifi.h and nm_common.h files contain many of the APIs you'll need to interact with the Winc, however you may need to include other files depending on your application. 

    #include "socket/include/socket.h"
    #include "driver/include/m2m_wifi.h"
    #include "common/include/nm_common.h"
  9. Finally, the last thing that needs to be configured are the system clocks on the host microcontroller . This is important because if the clocks are not configured correctly, the microcontroller will not be able to communicate with the WINC via SPI. The clock configuration procedure is detailed below.
  10. Once the clocks are configured, build the project. If it builds without errors, you are now ready to start writing you application.

Clock Configuration:

The Slave SPI on the Winc works up to 48 MHz, therefore for the best performance, the SPI bus should run at just under 48 MHz. In order to drive the SPI bus at this frequency, the clock signal from the external oscillator will need to be routed through the SamD21's DFLL multiplier. The Winc host driver will take care of most of this setup by itself, however the user needs to make sure that the clocks and their sources are enabled and configured properly.

Spi Bus Clock Chain


  1. After you have completed the Project Creation procedure listed above, open the conf.clocks.h file. You can find it by searching for the file name in the solution explorer window.
  2. The first thing that needs to be changed is the number of flash wait states, this should be set to 2.

    Flash Wait States
    #  define CONF_CLOCK_FLASH_WAIT_STATES            2
  3. The next thing will be to enable the external crystal oscillator, the configuration should be as follows.

    Crystal OSC config
    /* SYSTEM_CLOCK_SOURCE_XOSC32K configuration - External 32KHz crystal/clock oscillator */
    #  define CONF_CLOCK_XOSC32K_ENABLE               true
    #  define CONF_CLOCK_XOSC32K_EXTERNAL_CRYSTAL     SYSTEM_CLOCK_EXTERNAL_CRYSTAL
    #  define CONF_CLOCK_XOSC32K_STARTUP_TIME         SYSTEM_XOSC32K_STARTUP_4096
    #  define CONF_CLOCK_XOSC32K_AUTO_AMPLITUDE_CONTROL  false
    #  define CONF_CLOCK_XOSC32K_ENABLE_1KHZ_OUPUT    false
    #  define CONF_CLOCK_XOSC32K_ENABLE_32KHZ_OUTPUT  true
    #  define CONF_CLOCK_XOSC32K_ON_DEMAND            true
    #  define CONF_CLOCK_XOSC32K_RUN_IN_STANDBY       false
  4. After that, the DFLL needs to be enabled and configured as shown below. The DFLL multiply factor should be set to a little less than 1500 to avoid exceeding the SPI bus's 48 MHz limit. Atmel uses 1465 in their examples.

    DFLL init and config
    /* SYSTEM_CLOCK_SOURCE_DFLL configuration - Digital Frequency Locked Loop */
    #  define CONF_CLOCK_DFLL_ENABLE                  true
    #  define CONF_CLOCK_DFLL_LOOP_MODE               SYSTEM_CLOCK_DFLL_LOOP_MODE_CLOSED
    #  define CONF_CLOCK_DFLL_ON_DEMAND               false
    
    /* DFLL open loop mode configuration */
    #  define CONF_CLOCK_DFLL_FINE_VALUE              (0xff / 4)
    
    /* DFLL closed loop mode configuration */
    #  define CONF_CLOCK_DFLL_SOURCE_GCLK_GENERATOR   GCLK_GENERATOR_1
    #  define CONF_CLOCK_DFLL_MULTIPLY_FACTOR         1465 
    #  define CONF_CLOCK_DFLL_QUICK_LOCK              true
    #  define CONF_CLOCK_DFLL_TRACK_AFTER_FINE_LOCK   true
    #  define CONF_CLOCK_DFLL_KEEP_LOCK_ON_WAKEUP     true
    #  define CONF_CLOCK_DFLL_ENABLE_CHILL_CYCLE      true
    #  define CONF_CLOCK_DFLL_MAX_COARSE_STEP_SIZE    (0x1f / 4)
    #  define CONF_CLOCK_DFLL_MAX_FINE_STEP_SIZE      (0xff / 4)
  5. Finally, we need to configure the GCLK generators. For this example, we only need to configure generator 0 and 1.

    GCLK config
    #  define CONF_CLOCK_CONFIGURE_GCLK               true
    
    /* Configure GCLK generator 0 (Main Clock) */
    #  define CONF_CLOCK_GCLK_0_ENABLE                true
    #  define CONF_CLOCK_GCLK_0_RUN_IN_STANDBY        false
    #  define CONF_CLOCK_GCLK_0_CLOCK_SOURCE          SYSTEM_CLOCK_SOURCE_DFLL
    #  define CONF_CLOCK_GCLK_0_PRESCALER             1
    #  define CONF_CLOCK_GCLK_0_OUTPUT_ENABLE         false
    
    /* Configure GCLK generator 1 */
    #  define CONF_CLOCK_GCLK_1_ENABLE                true
    #  define CONF_CLOCK_GCLK_1_RUN_IN_STANDBY        false
    #  define CONF_CLOCK_GCLK_1_CLOCK_SOURCE          SYSTEM_CLOCK_SOURCE_XOSC32K
    #  define CONF_CLOCK_GCLK_1_PRESCALER             1
    #  define CONF_CLOCK_GCLK_1_OUTPUT_ENABLE         false


 

 STA Mode Walkthrough

 Objective

  • Demonstrate how to setup the Winc1500 in station mode and connect to an AP.

Description

  • The purpose of this example is to provide a step by step guide on how to program the Winc1500 as a station and have it connect to an AP
  • If you just want to quickly get a station up and running, Atmel has a STA mode example project in Studio 7.

Hardware

  • One SAMD21 Xplained Board
  • One Winc1500 Xplained Pro extension board
  • PC with Atmel studio 7 and terminal program installed.
  • One standard USB to USB micro cable.

Procedure

  1. Begin by creating a blank Winc 1500 project as shown in the example above, or you can download a blank project with all the necessary source files here: Blank Project.zip
  2. Since we'll want to print messages to the UART later on in this example, we'll need to make sure to do is add the necessary asf module. Open the ASF wizard by pressing alt+W , then add the Standard Serial I/O (stdio) driver to the project and click "Apply"
  3. The next thing we need to do is to include the necessary header and driver files in Main.c as shown below. The asf.h file is an automatically generated file that contains the headers for all the files generated by the Atmel Software Framework.

    Include files
    #include "asf.h"
    #include "stdio.h" 
    #include "driver/include/m2m_wifi.h"
  4. Now, we'll define macros for the SSID and security type of the AP that we want the station to connect to. I've setup an AP with the SSID "Demo" that uses OPEN security. You'll need to define these macros to match parameters of whatever AP you wish to connect to.

    AP Macro
    #define MAIN_WLAN_SSID        "DEMO" 
    #define MAIN_WLAN_AUTH        M2M_WIFI_SEC_OPEN 
  5. Next we will create the Wi-Fi call back function. This function will handle any status changes in the Wi-Fi connection. For now we'll just create the bare-bones function, later on in this example we'll add some code to this function so that it actually does something useful. The code block below shows what the Main.c file will look like after the Wi-Fi callback is added.

    Wifi Callback
    #include "asf.h"
    #include "driver/include/m2m_wifi.h"
     
    #define MAIN_WLAN_SSID        "DEMO" 
    #define MAIN_WLAN_AUTH        M2M_WIFI_SEC_OPEN 
    
    static void wifi_callback(uint8_t u8MsgType, void *pvMsg)
    {	
    }
    
    int main(void)
    {	
    }
  6. Before we go and start adding code to the main function, we'll want to configure a uart so we can print debug messages to it. The code below needs to be added outside the main function.

    UART Config
    static struct usart_module cdc_uart_module;
    static void start_uart(void)
    {
    	struct usart_config usart_conf;
    	usart_get_config_defaults(&usart_conf);
    	usart_conf.mux_setting = EDBG_CDC_SERCOM_MUX_SETTING;
    	usart_conf.pinmux_pad0 = EDBG_CDC_SERCOM_PINMUX_PAD0;
    	usart_conf.pinmux_pad1 = EDBG_CDC_SERCOM_PINMUX_PAD1;
    	usart_conf.pinmux_pad2 = EDBG_CDC_SERCOM_PINMUX_PAD2;
    	usart_conf.pinmux_pad3 = EDBG_CDC_SERCOM_PINMUX_PAD3;
    	usart_conf.baudrate    = 115200;
    	stdio_serial_init(&cdc_uart_module, EDBG_CDC_MODULE, &usart_conf);
    	usart_enable(&cdc_uart_module);
    }
  7. In the main function, we'll start by defining two variables, param which is a structure that will hold the Wi-Fi configuration and Ret is an unsigned integer that we will use later to verify that our Wi-Fi module initiated correctly. After that, we'll call the initialization functions for the hardware and and debug uart.

    System Initialization
    int main(void)
    {
    	tstrWifiInitParam param;
    	int8_t ret;
    	
    	/* Initializes hardware and system clocks */ 
    	system_init();
    	/* Initializes the board support package */ 
    	nm_bsp_init();
        /*Configure the UART so you can print to the terminal */ 
    	start_uart();
    	
    }
  8. The next step is to initialize the Winc itself. The first thing we'll need to do is ensure the param structure we created in step 6 is defined properly. After that, we call the m2m_wifi_init

     

    Winc Initialization
        /* Set each member of the param structure equal to 0 */
    	memset((uint8_t *)&param, 0, sizeof(tstrWifiInitParam));
    
    	/* Set the Wi-Fi callback member of the param structure equal to the Wi-Fi callback function created in part 4*/ 
    	param.pfAppWifiCb = wifi_callback;
    	
    	/* Initiate the Winc. If initialization is successful, ret will be set to 0 */
    	ret = m2m_wifi_init(&param);
    	if (M2M_SUCCESS == ret) {
    		printf("Winc Initialized successfully \r\n");
    	}
    	else {
    		printf("Initialization Error! \r\n")
    		while (1) { } // hang the program so no bad things happen. 
        }
  9. Once the Winc is initialized, we can connect to the AP by calling the m2m_wifi_connect function.

    Connect to AP
     m2m_wifi_connect((char *)MAIN_WLAN_SSID, sizeof(MAIN_WLAN_SSID), MAIN_WLAN_AUTH, 0, M2M_WIFI_CH_ALL);
  10. Once we connect to the AP, we'll call the m2m_wifi_handle_events function to receive events from the Winc. This function will initiate the callback function we created in step two to handle the event. We'll place the function within an infinite loop so that the Winc continuously monitor any changes in its connection status.

    Handle Events
    while (1)
    	{
    		while (m2m_wifi_handle_events(NULL) != M2M_SUCCESS) {
    		}
    	}
  11. Now we need to add code to our call back function so that our program can process the Wi-Fi events. For this simple example, we're only concerned if we made a connection or not, so we only need to check if the connection state has changed. Once we've determined if the state has changed, we'll then check to see if the Winc has is connected to an AP or not. If the Winc is disconnected, we'll call the m2m_wifi_connect function again in an attempt to reconnect.

    Call back function
    static void wifi_callback(uint8_t u8MsgType, void *pvMsg)
    {
    	if (u8MsgType == M2M_WIFI_RESP_CON_STATE_CHANGED)
    	 {
    		    /* Extract connection state from pvMsg*/
    			tstrM2mWifiStateChanged *pstrWifiState = (tstrM2mWifiStateChanged *)pvMsg;
    			
    			/*Determine if Winc is connected to the AP */ 
    			if (pstrWifiState->u8CurrState == M2M_WIFI_CONNECTED) {
    				
    				printf("Connected to Demo AP"); 
    				
    				} else if (pstrWifiState->u8CurrState == M2M_WIFI_DISCONNECTED) {
    					
    				printf("Wi-Fi disconnected\r\n");
    				printf("Attempting to Reconnect \r\n");
    				/* Attempt to reconnect to AP */
    				m2m_wifi_connect((char *)MAIN_WLAN_SSID, sizeof(MAIN_WLAN_SSID), MAIN_WLAN_AUTH, 0, M2M_WIFI_CH_ALL);
    			}
    	  }
    }
  12. Now that all the parts are added, the main.c file should look like the code below.

    Main.c
    #include "asf.h"
    #include "driver/include/m2m_wifi.h"
    #define MAIN_WLAN_SSID        "Demo" 
    #define MAIN_WLAN_AUTH        M2M_WIFI_SEC_OPEN // Security type 
    static void wifi_callback(uint8_t u8MsgType, void *pvMsg)
    {
    	if (u8MsgType == M2M_WIFI_RESP_CON_STATE_CHANGED)
    	 {
    		    /* Extract connection state from pvMsg*/
    			tstrM2mWifiStateChanged *pstrWifiState = (tstrM2mWifiStateChanged *)pvMsg;
    			
    			/*Determine if Winc is connected to the AP */ 
    			if (pstrWifiState->u8CurrState == M2M_WIFI_CONNECTED) {
    				
    				printf("Connected to Demo AP"); 
    				
    				} else if (pstrWifiState->u8CurrState == M2M_WIFI_DISCONNECTED) {
    					
    				printf("Wi-Fi disconnected\r\n");
    				printf("Attempting to Reconnect \r\n");
    				/* Attempt to reconnect to AP */
    				m2m_wifi_connect((char *)MAIN_WLAN_SSID, sizeof(MAIN_WLAN_SSID), MAIN_WLAN_AUTH, 0, M2M_WIFI_CH_ALL);
    			}
    	  }
    }
    static struct usart_module cdc_uart_module;
    static void start_uart(void)
    {
    	struct usart_config usart_conf;
    	usart_get_config_defaults(&usart_conf);
    	usart_conf.mux_setting = EDBG_CDC_SERCOM_MUX_SETTING;
    	usart_conf.pinmux_pad0 = EDBG_CDC_SERCOM_PINMUX_PAD0;
    	usart_conf.pinmux_pad1 = EDBG_CDC_SERCOM_PINMUX_PAD1;
    	usart_conf.pinmux_pad2 = EDBG_CDC_SERCOM_PINMUX_PAD2;
    	usart_conf.pinmux_pad3 = EDBG_CDC_SERCOM_PINMUX_PAD3;
    	usart_conf.baudrate    = 115200;
    	stdio_serial_init(&cdc_uart_module, EDBG_CDC_MODULE, &usart_conf);
    	usart_enable(&cdc_uart_module);
    }
    
    int main(void)
    {
    	tstrWifiInitParam param;
    	int8_t ret;
    	
    	/* Initializes hardware and system clocks */ 
    	system_init();
    	/* Initializes the board support package */ 
    	nm_bsp_init();
    	/*Configure the UART so you can print to the terminal */ 
    	start_uart();
    	
    	/* Set each member of the param structure equal to 0 */
    	memset((uint8_t *)&param, 0, sizeof(tstrWifiInitParam));
    	
    	/* Set the Wi-Fi callback member of the param structure equal to the Wi-Fi callback function created in part 4*/ 
    	param.pfAppWifiCb = wifi_callback;
    	ret = m2m_wifi_init(&param);
    	if (M2M_SUCCESS == ret) {
    		printf("Winc Initialized successfully \r\n");
    	}
    	else{
    		printf("Initialization Error! \r\n");
    		
    		while (1) {  }// hang the program so no bad things happen. 
    	}
    	
        /*Connect to AP */ 
    	m2m_wifi_connect((char *)MAIN_WLAN_SSID, sizeof(MAIN_WLAN_SSID), MAIN_WLAN_AUTH, 0, M2M_WIFI_CH_ALL);
    	
    	while (1)
    	{
    		/*Have the winc sit around processing events */ 
    		while (m2m_wifi_handle_events(NULL) != M2M_SUCCESS) {
    		}
    	}
    }
    
    
  13. Build the project and download it to the SAMD21 Xplained board. Also ensure that the Winc1500 Xplained board is connected to extension header 1 of the SAMD21 Board.
  14. Use a terminal program to open up a serial connection to the SAMD21. Once the connection is open, press the rest button on the SAMD21 Board. The output should look like the picture below.

  15. If you are unable to get this demo running, you can download a completed project here: Station_Example.zip

 


 Winc Firmware Update

 Objective

  • Demonstrate how to upgrade the firmware on the Winc1500

Hardware

  • One SAMD21 Xplained Board
  • One Winc1500 Xplained Pro extension board
  • PC with Atmel studio 7 and terminal program installed.
  • One standard USB to USB micro cable.

Procedure

  1. Attach the Winc1500 to extension header 1 on the SAMD21 Board
  2. Use the USB cable to attach the SAMD21 board to the PC. Ensure the USB cable is plugged into the DEBUG USB port on the SAMD21 board.
  3. Use Window's device manager to ensure that a com port has been opened on the SAMD21
  4. In Atmel Studio, select File->New->Create new example project or press (ctrl+shift+e)
  5. From the list of example projects, select "WINC1500_FIRMWARE_UPDATE_PROJECT-SAM D21 XPLAINED PRO" and press ok.
  6. Once the project is created, click on the SRC folder in the Solution Explorer window.
  7. In the SRC folder there are a series of .bat files. Right click on "samd21_xplained_pro_firmware_update.bat" and select "open file location"
  8. Once the folder opens, double click on "samd21_xplained_pro_firmware_update.bat" to run the batch file
  9. The batch file will open a window and begin updating the Winc's firmware. When the firmware is successfully updated, the following message should appear:


 

 

 Mode Change Example

 Objective

  • Demonstrate how to transfer the Winc from one mode to another

Hardware

  • One SAMD21 Xplained Board
  • One Winc1500 Xplained Pro extension board
  • PC with Atmel studio 7 and terminal program installed.
  • One standard USB to USB micro cable.

Procedure

  1. Download the following example project for Atmel Studio 7 or higher.
  2. Extract the project and open it in Atmel Studio.
  3. Ensure that the Winc1500 Xplained board is attached to the EXT1 header of the SAMD21 Xplained board.
  4. Attach the PC to the Debug USB connector of the SAMD21 board with the USB cable.
  5. In Atmel studio, save and build the project.
  6. Program the SAMD21 by pressing the "Start Without Debugging" button in Atmel Studio.
  7. Open a terminal window and setup the serial port as follows:
    • Select the COM port associated with the SAMD21
    • Baud rate 115200
    • Data bits: 8
    • Parity: none
    • Stop bits: 1
    • Flow Control not implemented
  8. Once the terminal window is open, press the reset button on the SAMD21 board.
  9. You should see a message similar to the following:



  10. Every time you push the button SW0 on the SAMD21 board, the Winc will enter a new mode. After two presses, you should see the following message on the terminal.

 

 


Contacting the Author:

Hopefully this article was helpful in introducing you to the Winc1500. Feel free to use the examples in your own projects and modify them as you see fit. If you have any questions or comments about this article, you can reach me at eewiki@digikey.com 

-Matthew Bon 

  • No labels