Typically if you want to use a WSTK to program an external device you can change the Debug Mode using Simplicity Studio. However if you're only working with WGM110 and no other Silicon Labs product which requires Simplicity Studio installation you can change the Debug Mode with (and old version) of Simplicity Commander within the WGM110 SDK.

The commander executable is located in C:\SiliconLabs\WizardGeckoSDK\WGM110-1.0.1\bin\commander and you can change the Debug Mode by selecting "Kit" on the left-hand side.

Q: Why is the WF121/WGM110 throughput lower when the module is in AP mode?

A: When WF121/WGM110 is in AP mode it must re-transmit multicast traffic coming from any of its clients. The multicast traffic has to be sent right after a beacon and until it is sent all the unicast TX traffic is blocked. 

If there is on-going TCP communication this can cause lost frames, forcing the TCP to re-transmit and decreasing the throughput. This is mostly observable when the clients are Windows/MAX/Linux PCs which use multicast traffic for service discoveries and other purposes.

Also multicast sent from the module itself (by the application) causes the same behavior, not just re-transmitting multicast coming from the clients.

On Windows this can be improved by disabling some of the native discovery services as shown below if they are not required.

Introduction

The Wizard Gecko WGM110 Wi-Fi module supports AP (Access Point) or station mode and the role can change during run-time without having to reset the module.

Command/Event Sequence Flowchart

Attached is a project that exemplifies how to switch between AP and station modes in run-time (you have to fill-in your AP details in the bgscript code). With this project the WGM110 boots into AP mode and then by pressing PB0 in the WSTK it will switch between AP and station modes.

If you have PB1 pressed while pressing PB0 to switch from station to AP it will start AP mode with WPA2 security, otherwise it will be an open AP. You can follow the BGScript code execution by opening BGTool and looking at the command window.

The flowchart below shows the recommended commands/events sequence to switch modes in a safe way. It's worth pointing out that:

• Before switching from station to AP you should disconnect from the AP.
• Before switching from AP to station you should stop AP mode. If you don't do this and go straight to turning off the Wi-Fi then the firmware becomes stuck and can only be recovered through a reset.

AP to Station

The image below shows the commands (or more accurately, the command responses) and events between pressing PB0 and receiving the sme_interface_status event which confirms that the Wi-Fi interface is ready.

This trace is taken with BGTool and edited to remove some of the events for simplicity purposes. When a BGScript application is running and there is a UART enabled in BGAPI mode all the command responses and events are sent out via the BGAPI UART and they can be parsed with BGTool.

The time to switch from AP to station depends strongly on the AP that the module is connecting to, more specifically how fast it can assign an IP with DHCP protocol. In this example the total time to switch from AP to station mode is about 7 seconds.

Station to AP

The image below shows the switch from station to AP with WPA2 security.

When WPA2 security is enabled it takes longer to have the AP ready. The switch time is more deterministic in switching from station to AP as there are no external dependencies. Switching from station to a WPA2 secured AP takes about 6 seconds.

The image below shows the switch from station to an open AP. When the AP is insecure it takes significantly less time than with a secure AP, which is about 2 seconds.

Introduction

This article aims to explain the differences between WF111 and WF121/WGM110 modules in terms of their built-in functionality and host requirements to integrate them into your application.

In practice we are here summarizing information which you can find across a few documents, in order to help you understand better what are the benefits and trade-offs of each of the modules so that you can pick the most suitable module for your application.

What's on Board?

The WF121/WGM110 modules contain a Wi-Fi chipset and an MCU. The Wi-Fi chipset runs the PHY and lower MAC layers and the MCU runs the upper MAC and TCP/IP stack.

On the other hand the WF111 only contains the Wi-Fi chipset so there is no on-board TCP/IP stack. This means that the upper MAC and TCP/IP stack must run on the host controller.

Software Architecture

Let's now look at the software architecture for WF111 and WF121/WGM110 so that it helps understanding the different host requirements for each.

WF111

On WF111 the Wi-Fi chipset runs the radio (PHY) and lower MAC and everything else runs on the host.

As the TCP/IP stack must run on the host and that prevents this module from being used with 'less resourceful' processors which might not have enough Flash/RAM or other resources to run the stack. It's also worth noting that you cannot run your application on the WF111, it must run on the host device.

WF121/WGM110

For WF121/WGM110 the TCP/IP stack runs on the module and the module's functionality is controlled through the BGAPI protocol.

* Note: This diagram represents both WF121 and WGM110 but WF121 does not support TLS

On WF121/WGM110 there are 3 development options:

• Standalone mode: all software including the application software runs on the module. The application must be written using BGScript.

• Hosted mode: an external host runs the application software which controls the module using a well-defined binary based transport protocol called BGAPI.

• Mixed mode: a part of the application runs on the module while the rest of the application runs on an external host. One example is to have the network management part in BGScript while the host handles the higher level application tasks.

Host Requirements

Now that we are more aware of what each module offers we can understand the different host requirements. For the case of standalone mode on WF121/WGM110 there is no requirement to have a host at all so we will leave that out of the discussion.

WF111

The WF111 requires an SDIO interface to the host and also that the host is running Linux operating system (typically ARMvX based processors). The software package provided by Silicon Labs includes the Linux drivers which must be cross compiled in a separate build machine running Linux. Instructions on how to build and install the drivers can be found in AN995: WF111 Android Driver Installation.

Once the drivers are installed the standard Linux wireless tools can be used to manage the new wireless interface such as iwlist for scanning for Access Points or iwconfig to connect to a wireless network.

WF121/WGM110

WF121/WGM110 can be interfaced via UART/USB/SPI using BGAPI protocol. Because the TCP/IP stack is running on the modules they can be controlled by very small and resource constrained MCUs, depending of course on the use case and the needs of the actual application.

The SDKs contain the BGLib which is a lightweight host library in C that implements the BGAPI binary protocol and parser so that you can abstract from the binary format of the protocol.

The host controller doesn't have any visibility to the IP frames or TCP/UDP/TLS protocols. From a data transfer stand-point it only exchanges raw TCP/UDP/TLS payload using either BGAPI commands or transparent data connection (UART/USB in streaming mode). The exception is with higher level or application specific protocols (e.g. SMTP) which then need to be handled by the host and channeled through a TCP/UDP/TLS connection.

FAQ

Q: Is it possible to use SPI with WF111?

A: No, it's not possible. The drivers are only prepared to use SDIO interface.

Q: Can I bypass the TCP/IP stack on WF121/WGM110?

A: This is only possible on WF121 when using bridge mode. In this mode the RMII interface must be used (connected to an ethernet PHY or another device) and the WF121 only bridges the MAC frames between the Wi-Fi and ethernet interfaces. 

Q: Can I get higher throughput with WF111?

A: Yes because the Wi-Fi chipset is being handled by a more powerful processor compared to the MCUs running the TCP/IP stack on WF121/WGM110. The throughput will be mostly dependent on how much CPU time can be dedicated to the Wi-Fi interface compared to other tasks running on the CPU. As a ballpark we have tried and tested up to 12Mbps but in ideal conditions, with the device fully dedicated to the Wi-Fi.

Introduction

This article shows how you can use the Wizard Gecko WGM110 Wi-Fi Module to trigger actions using IFTTT.

The example shown here allows you to add a row into a spreadsheet in your google drive by double tapping the accelerometer in the WSTK expansion board. For the accelerometer configuration it uses code from the spi_master example from the WGM110 SDK which configures the accelerometer to give an interrupt signal when you double-tap it.

To run the example code you need:

- IFTTT account

- Google account

- AP with Internet access (you need to write your AP's SSID and password in the sta.bgs file of the attached project so that the WGM110 can connect to it) -> LED0 in the WSTK will turn on once the WGM110 connection to the AP is up and running

IFTTT - Creating a Recipe

To get this up and running on the cloud side you need to create an IFTTT account and connect to the Maker and Google Drive channels. These should be pretty simple steps: once your account is created you can go to the IFTTT channel page and search for the two aforementioned channels and connect them to your IFTTT account.

When you connect to the Maker channel you'll be given a key which you need to use to trigger the actions. This key will always be visible when you access the Maker channel page while logged in as depicted below.

Now we need to setup a recipe which will use the maker channel as a trigger to add a row into a spreadsheet in your google drive. Here goes a short guide on how to do this:

1. There are several ways to create a recipe (like through the Maker channel page) but assuming you're on the IFTTT homepage press on your username on the top-right of the IFTTT page to pull-down the menu and then press 'Create'. Afterwards press "this" in "ifthisthenthat" to continue creating the recipe.

2. Write "Maker" in the channel list and select the maker channel as your recipe's trigger.

3. Choose the web request trigger (it's the only option).

4. Name your event and press "Create Trigger". In this example the trigger is named double_tap.

5. Now press "that" in "ifthisthenthat" and choose Google Drive as the action channel.

6. Choose the action which for this example is "Add row to spreadsheet".

7. To finalize give further details on how you want the data to be written into the spreadsheet. For this example we left it with the default options.

8. To test your recipe just make a POST or GET request as instructed in the Maker channel usage page. Essentially you just need to open a browser window and write https://maker.ifttt.com/trigger/YOUR_EVENT_NAME/with/key/YOUR_KEY and that will trigger the action you created with the recipe. There is an optional JSON body that can be used to send additional data but for this example this is not being used.

Creating the Trigger from WGM110

What we want to do now is to send this POST or GET request from the WGM110 to trigger the action. To do this we need to behave like an HTTP client which means we must open a TCP connection to port 80 in the IFTTT maker channel server and send the HTTP request through that TCP pipe.

To know what to actually put into the HTTP request there is a handy site called Request Maker where you can simply copy the URL used to trigger the event, select POST request type (or GET, but in this example we will use POST) and press Submit. It will then show you the HTTP request content as well as the response (if any).

BGScript implementation

Now that we know what to place in the HTTP POST request it's just a matter of creating some constant buffers with the data.

# IFTTT Maker POST request - generated through http://requestmaker.com/ - You need to replace YOUR_EVENT and YOUR_KEY according to what you setup on IFTTT
const ifttt_trigger_1() = "POST /trigger/YOUR_EVENT/with/key/YOUR_KEY HTTP/1.1\r\n"
const ifttt_trigger_length_1 = 67
const ifttt_trigger_2() = "Host: maker.ifttt.com\r\n"
const ifttt_trigger_length_2 = 23
const ifttt_trigger_3() = "Accept: */*\r\n"
const ifttt_trigger_length_3 = 13
const ifttt_trigger_4() = "Content-Length: 0\r\n"
const ifttt_trigger_length_4 = 19
const ifttt_trigger_5() = "Content-Type: application/x-www-form-urlencoded\r\n\r\n"
const ifttt_trigger_length_5 = 51
const ifttt_response() = "HTTP/1.1 200 OK"
const ifttt_response_length = 15

As the accelerometer interrupt is the trigger for the request the first thing we need to do is to resolve the hostname in the interrupt event. In addition we will turn on LED1 in the WSTK to indicate to the user that the process is on-going. We also trigger a failsafe timer with a 10 second timeout period in case something doesn't go well (like the server not being able to accept our TCP connection request).

event hardware_interrupt(interrupts, timestamp)	
	if (interrupts & WSTK_ACC_INT_PIN_MASK) && (status = STATUS_READY) then # When double tapping the accelerometer
		status = STATUS_REQUEST_ONGOING
		# Resolve ifttt maker server hostname
		call tcpip_dns_gethostbyname(maker_ifttt_server_name_len, maker_ifttt_server_name(:))
		# Turn ON LED1 - indicates request on-going
		call hardware_write_gpio(GPIO_PORTC, $0002, $0002)
		# Failsafe timeout - if we don't get an HTTP response to our POST request within 10 seconds then we'll stop the process
		call hardware_set_soft_timer(10000, 0, 1)
	end if
end

Once the hostname is resolved we can initiate the TCP connection and send the data contained the request buffers. To check if the request was successful we also catch the endpoint_data event and look for the HTTP response. If the response is "HTTP/1.1 200 OK" then we stop the failsafe timer and turn off LED1.

event tcpip_dns_gethostbyname_result(dns_result, server_ip_address, name_len, name_data)
	# Hostname was resolved, now we make a TCP connection to the HTTP server which is on TCP Port 80
	call tcpip_tcp_connect(server_ip_address, maker_ifttt_server_tcp_port, -1)(result, endpoint_maker_ifttt_server_tcp)
end 

# Event received when an endpoint status changes. 
event endpoint_status(endpoint, type, streaming, destination, active)

	if (active = 1) && (endpoint = endpoint_maker_ifttt_server_tcp) then
		# Connection to IFTTT HTTP server is now ready, let's send the POST request
		call endpoint_send(endpoint, ifttt_trigger_length_1, ifttt_trigger_1(:))
		call endpoint_send(endpoint, ifttt_trigger_length_2, ifttt_trigger_2(:))
		call endpoint_send(endpoint, ifttt_trigger_length_3, ifttt_trigger_3(:))
		call endpoint_send(endpoint, ifttt_trigger_length_4, ifttt_trigger_4(:))
		call endpoint_send(endpoint, ifttt_trigger_length_5, ifttt_trigger_5(:))
	end if
	
	if type = 128 then # The IFTTT HTTP server will eventually close the TCP connection after a few seconds
		call endpoint_close(endpoint)
	end if
end

event endpoint_data(endpoint,data_len, data_data)

	# Received some data back from the server, let's see if it was an OK response to our request
	if (endpoint = endpoint_maker_ifttt_server_tcp) && memcmp(data_data(0), ifttt_response(0), ifttt_response_length)				
		# IFTTT response successful (HTTP/1.1 200 OK) - stop the failsafe timer
		call hardware_set_soft_timer(0, 0, 1)		
		# Turn OFF LED1
		call hardware_write_gpio(GPIO_PORTC, $0002, $0000)
		status = STATUS_READY
	end if
end

Once LED1 goes off the WGM110 is ready to make a new request so you can double tap the accelerometer again to trigger the action.

Final result

Double tap the expansion board -> LED1 goes on -> LED1 goes off -> New row is added to the google drive spreadsheet

The Wizard Gecko WGM110 Wi-Fi Module supports the following extensions of WPA2-Enterprise:

• EAP-TLS

• PEAPv0-MSCHAPv2 / PEAPv1-MSCHAPv2

PEAP-MSCHAP uses certificates + username/password, EAP-TLS uses just certificates. User certificate is optional in PEAP but mandatory in EAP-TLS. In all cases the root certificate must be provisioned to the module just like in TLS (for more details on how to manage certificates please refer to "AN974: Wizard Gecko TLS and SMTP Example" available from the WGM110 document library).

Introduction

This article shows how to use the NIST Internet Time Service (ITS) to synchronize the Wizard Gecko WGM110 Wi-Fi module's internal RTC (Real Time Clock).

There are different ways to sync up time through the internet but for this article we selected the Daytime Protocol (RFC-867) over TCP. For this protocol the NIST ITS is listening to TCP port 13 and once a client connects it will send to the client the data representing the current time.

The standard does not specify an exact format for the Daytime Protocol, but requires that the time is sent using standard ASCII characters. Please visit the NIST link above to learn more about format used by NIST.

Requesites

This project is in many ways similar to the gmail example from the SDK.You will need an AP with internet access and the WGM110 WSTK because the LEDs on the kit are used to signal AP connection and on-going NIST query, and the push buttons are used to print the RTC time over UART and initiate the NIST query.

BGScript Project

Before building and flashing the project to the WGM110 it must first be modified with the credentials of your AP with internet access. The file sta.bgs contains the BGScript code that manages the AP connection and the comments there will guide you to write your AP's SSID and password.

Once you flash it to the module on the WSTK it will turn on LED1 which indicates that it has successfully connected to the AP. The application will now be waiting for the user to push PB0 to initiate the NIST query.

NIST Query

To retrieve the current time from the NIST ITS server it is first needed to resolve the hostname with the command below where nist_server_name = "time.nist.gov":

call tcpip_dns_gethostbyname(nist_server_name_len, nist_server_name(:))

When the hostname has been resolved the event tcpip_dns_gethostbyname_result is raised where the hostname's IP is given. Then the TCP connection can be established on port 13 using the command:

call tcpip_tcp_connect(server_ip_address, nist_server_tcp_port, -1)(result, endpoint_nist_server_tcp)

Once this is done it's just a matter of a few seconds and the server will send the ascii string with the current time which is captured with endpoint_data event. When the data is received the string is parsed and the values are used to set the time in the RTC.

  # The response starts with '\n', so the first year character is on index 7
  call util_atoi(2, data_from_server(7:2))(year)
  call util_atoi(2, data_from_server(10:2))(month)
  call util_atoi(2, data_from_server(13:2))(day)
  call util_atoi(2, data_from_server(16:2))(hour)
  call util_atoi(2, data_from_server(19:2))(minute)
  call util_atoi(2, data_from_server(22:2))(second)
  
  # Year needs to be added to 2000
  call hardware_rtc_set_time((year+2000),month,day,hour,minute,second)(result)

The NIST response is also fully printed out to the UART when it's received for visual confirmation by the user.

Printing RTC Time

When the user presses PB1 the WGM110 will print out the current RTC time. This way it is possible to see the time before and after the NIST ITS sync to confirm that it has been done correctly.

    call hardware_rtc_get_time()(result,year,month,day,weekday,hour,minute,second)
	
	# I will purposely ignore printing out the weekday
	call endpoint_send(endpoint_uart0, 27, "Current RTC date and time: ")
	call util_itoa(day)(buffer_len, buffer(0:buffer_len))
	call endpoint_send(endpoint_uart0, buffer_len, buffer(0:buffer_len))
	call endpoint_send(endpoint_uart0, 1, "/")
	call util_itoa(month)(buffer_len, buffer(0:buffer_len))
	call endpoint_send(endpoint_uart0, buffer_len, buffer(0:buffer_len))
	call endpoint_send(endpoint_uart0, 1, "/")
	call util_itoa(year)(buffer_len, buffer(0:buffer_len))
	call endpoint_send(endpoint_uart0, buffer_len, buffer(0:buffer_len))
	call endpoint_send(endpoint_uart0, 1, " ")
	call util_itoa(hour)(buffer_len, buffer(0:buffer_len))
	call endpoint_send(endpoint_uart0, buffer_len, buffer(0:buffer_len))
	call endpoint_send(endpoint_uart0, 1, ":")
	call util_itoa(minute)(buffer_len, buffer(0:buffer_len))
	call endpoint_send(endpoint_uart0, buffer_len, buffer(0:buffer_len))
	call endpoint_send(endpoint_uart0, 1, ":")
	call util_itoa(second)(buffer_len, buffer(0:buffer_len))
	call endpoint_send(endpoint_uart0, buffer_len, buffer(0:buffer_len))
	call endpoint_send(endpoint_uart0, 2, "\r\n")

Result

If you press PB1 before the NIST ITS sync you'll see that the default time after RTC initialization is 1/1/1970 0:00:00. This has not been selected randomly, it's the starting point for the UNIX time which counts the number of seconds elapsed since this point in time.

After sync with NIST ITS you can press PB1 again to confirm that the data was correctly parsed and the RTC was updated correctly. The NIST gives the current UTC time so it needs to be adjusted to your particular time zone.

Introduction

This article will show how you can host a JavaScript-based Space Invaders game on the WGM110 HTTP server and play the game using the push buttons on the WSTK and the expansion board.

For better understanding on how the WGM110 HTTP server works we recommend to read "AN967: Wizard Gecko WSTK Demo Walkthrough" available from the Document Library.

Preparing the Project

Before detailing how the demo works let's setup the project so it can be built and flashed into the WGM110 with the Wizard Gecko BGTool. To learn how to build and flash a project please the WGM110 Getting Started video.

BGScript

Download the zip file attached to this article which contains the BGScript and project/hardware configuration files.

JavaScript Space Invaders

Due to unclear license terms we will not distribute the source code for this space invaders implementation. Instead download the Space Invaders JavaScript source from this git repository and extract it to the same folder where you have the BGScript project. Your folder should then look like the image below.

The files following files are not needed so you are free to remove them:

• .gitignore
• README.md
• screenshot.jpg

Adding WSTK Controls

The game takes input from the keyboard left/right arrow keys and space bar (for shooting the aliens) but we also want to be able to feed those controls from the WSTK and its expansion board. You should then copy the code snippet below and paste it between the toggleMute function's closing bracket and </script> tag in the index.html file.

var myControlObj = { "button_shoot": 0, "button_left": 0, "button_right": 0 };

var xhr = new XMLHttpRequest();
xhr.timeout = 10000; //10 seconds timeout
xhr.onreadystatechange = function() {
	if (xhr.readyState === 4 && xhr.status === 200) {
		myControlObj = JSON.parse(xhr.responseText);
		getButtonsValue();
		readControls();						
	}
};
	
xhr.ontimeout = function() {
	readControls();
};

readControls();

/**
 * Function for requesting the controls
 */
function readControls() {	
	xhr.open("GET", "/api/controls", true);
	xhr.send();
}

/**
 * Function for parsing the button values
 */
function getButtonsValue()
{
	var iButton_shoot = myControlObj.button_shoot;
	var iButton_left = myControlObj.button_left;
	var iButton_right = myControlObj.button_right;
	
	// Sanity checks
	if(iButton_shoot != 0)
		game.keyUp(32)
	if(iButton_shoot == 0)
		game.keyDown(32)
		
	if(iButton_left != 0)
		game.keyUp(37)
	if(iButton_left == 0)
		game.keyDown(37)
		
	if(iButton_right != 0)
		game.keyUp(39)
	if(iButton_right == 0)
		game.keyDown(39)
	
}

What this code does is issuing GET requests for the status of the control buttons on the WGM110 and parsing the response (more details further down).

After this the project is ready to be built and flashed into the WGM110.

Running the Demo

After the project has been flashed you will see LED0 turn ON which means that the WGM110 is in AP mode. If you open your Wi-Fi networks list you should see "Space Invaders" network which you can connect to freely as it is an insecure network.

Once you are connected to the network open the browser and type the WGM110's IP address 192.168.1.1 which will load the front page.

To start playing you can either press Space bar on the keyboard or PB0 on the WSTK which will take you to the game.

To play the game you must use PB0 on the WSTK (for shooting) and BTN3/BTN2 on the expansion board to move left/right.

Project Walkthrough

When you type 192.168.1.1 into the the browser it will issue a GET request for the root resource ("GET / HTTP/1.1") to which the WGM110 responds with the content of index.html file. This is the default behavior of the WGM110 HTTP server when the root path '/' is set to either the Flash or SD-Card. That is followed by GET requests for all the other relevant files. The transactions are visible in the wireshark log below.

The highlighted frame is the GET request for the resource "/api/controls" which is not handled automatically by the WGM110 HTTP server but rather by the BGScript code as the response must be built with the status of each of the push buttons.

Looking closer into the HTTP response to "GET /api/controls" request it is visible the JSON formatted data with a value for each button. If the value is 0 it means that the button is being pressed, otherwise it is different from 0. The value is the direct response result of hardware_read_gpio command with the bitmask set for the relevant pin.

When the BGScript application receives the HTTP requests it will check if any of the buttons has been pressed by looking at the the status of button_change variable. This variable is set inside the interrupt handler which is triggered by either a rising or a falling edge on any of the button pins. This is to make sure that no button press is missed in case it happens in between responding to an HTTP request and receiving a new one.

# Event received when REST API request is called
event https_api_request(request, method, resource_len, resource_data)
  api_request = request
  if resource_len = API_MEASUREMENT_RESOURCE_LEN && memcmp(resource_data(0), API_MEASUREMENT_RESOURCE(0), API_MEASUREMENT_RESOURCE_LEN)
	if button_changed then
	  # If there has been a button change in between sending the last response and getting the new request then responde immediately
	  call api_handle_control_request(request)
	else
	    # Otherwise set a one-shot timer to respond 5 seconds from now at the latest
        call hardware_set_soft_timer(HTTP_REQUEST_TIMEOUT, HTTP_REQUEST, 1)		
	end if
	
  end if
end

If button_changed is already set a response will immediately be sent with the latest button status which are read inside the interrupt handler. If it hasn't been set then a soft timer is initiated with a 5 second timeout. This is because HTTP requests don't need to be responded straight-away and this way we avoid an unnecessary flow of HTTP requests/responses. However, if any of the buttons is pressed during those 5 seconds then a response will immediately be sent, again to ensure minimum latency.

event hardware_interrupt(interrupts, timestamp)	
  if interrupts = $0004 then # When pressing button PB0 at the eval board
	# Flag the button change and read the status
    button_changed = 1
	call hardware_read_gpio(GPIO_PORTA, $0004)(result, button_shoot)
	# If there is a request waiting for response then respond immediately
	if api_request != -1 then
	  call api_handle_control_request(api_request)
    end if
  end if

On the browser side the GET requests are being sent as soon as the response for the previous request has been received. When the JSON formatted response is received it will parse the values to emulate actual keyboard key presses by calling game.keyUp/game.keyDown with the adequate value (32 for space, 37 for left arrow key and 39 for right arrow key).

Final Result

This is a very simple example which samples ADC channel 0 at 1Hz. This ADC channel is mapped to the module's pin PD0 (Pad #2) which is available in the WSTK expansion header on pin 4, right next to the VMCU pin.

The ADC reference is configured as Buffered VDD with the following line in the hardware configuration:

<adc reference="2" />

Any analog signal referenced to the same ground as the module and with a dynamic range of 0V to VDD (which is 3.3V if the kit is powered from USB) can be measured.

The ADC has 12 bits resolution and this example prints out via UART0 the raw ADC result value without any mathematical conversion so you will see values between 0 and 2^12-1 = 4095.

To test this example you can simply put a wire from PD0 to GND and see the result go to 0...

... or wire PD0 to VMCU and see the result go to 4095.

Update

If you don't have a jump wire then it's easier to use the expansion board with the analog joystick. The project 'adc_example_joystick' samples PD4 instead of PD0 at a higher rate of 10Hz and prints out the raw value. You will see it changing when moving the joystick as well as an 'X' when you move the joystick left or right as shown in the screenshot below. The joystick in the expansion board has 9 measurable positions and uses different resistor values to create measurable voltages in each of the 9 positions. A block diagram is available in UG172 - WSTK User Guide.