This page is in group Technology (plus My XMOS pages) where I will try to add matters about my XMOS xCORE-200 eXplorerKITs that I haven’t found elsewhere. I purchased two of these boards in the summer of 2017. It turned out to become an XMOS embedded WiFi blog note.

This note has ended up with more than «WiFi» since I also have included the XMOS general Embedded webserver library. However, I dropped WiFi in all aspects of it. For exporting data from the aquarium box I ended up with an RFM69 radio board that sends in the 433 MHz band. See this described in My aquarium’s data radioed through the shelf. Such an RFM69 board is then also used in my xCORE-200 eXplorerKIT box that picks up those data. Quite done in Oct2018. Then export from that box will be done over the RJ45 RGMII Ethernet connection, from an embedded web server.

Please study the whole table of context first, that may save you a lot of time if you are looking for something special. You may even want have a glimpse first at Notes 5: WiFi sliceCARD with TI CC3000 is doomed – if you are here for the WiFi part.

Disclaimer

Standard disclaimer, this is just for fun. No money, gifts, ads etc. Also, my non-association with XMOS, see here.

Intro

The board is described in [1].

Fig.1 – XMOS xCORE-200 eXplorerKIT idle current measurement. Older 1A Apple iPhone USB power adaptors seen

Notes 1: Some detail

1. Idle current consumption as it comes out of the box @ USB 5V is about 75 mA (→375 mW). Measured with no code and when not connected to xTIMEcomposer. Update: After this I discovered USB power meters at Adafruit like USB Charger Doctor – In-line Voltage and Current Meter or USB Voltage Meter with OLED Display. I bought the latter. (Disclaimer: no money, gifts etc. This is purely a ref for you, like all other refs here)
2. The xTAG3 1V2 [7] (that comes in the box) doesn’t seem to add anything to the idle current consumption
3. Most of the components are on the top. There are some capacitors and low-power resistors  underneath. They would be low-temp and little to be afraid of. Besides, the four plastic mounting pieces do add some air. So I guess it’s ok to mount them in something I think is polystyrene foam, even it was flammable when I tested it. I could glue it with my standard contact adhesive (or double sided tape that it came glued with) – and nicely cut it with my FET table saw. eXplorerKIT sadly isn’t shipped in a nice foam like the startKIT. So I found some from my pile of different kinds that I have not ditched over the years
4. The MAC address is on a label at the bottom. I made a new label for the top so that it’s available when the board is quite fastened in my fixture

Notes 2: Power-good LEDs

The hardware manual [2] doesn’t tell where the 5V power-good LED is. It’s seen below (press on it to get a PDF to print out, cut and glue in place; but screen layout is here). 3.3V was already shown as P, but I made it look the same. (Press picture for a PDF):

Fig.2 – xCORE-200 eXplorerKIT Hardware Manual with 5V LED (press to get PDF)

Notes 3: WiFi sliceCARD via PCIe/GPIO?

I didn’t order the xCORE-200 sliceKIT (here) simply because I wanted a smaller board with Ethernet on the board. (I wasn’t in time-scope to consider its obsoleted forerunner up to Jan 2017, the xCORE-200 general purpose sliceKIT (here))

I did know that I would have to connect my WiFi sliceCARD myself. I want to test out the WiFi sliceCARD SW with the XMOS xCORE-200 eXplorerKIT but later see if I could move that SW to the startKIT. I would learn a new board, and I would not in the first round be bound by pins already having been used by my aquarium controller that uses a startKIT (picture here). The long goal is to try to get the aquarium controller visible over WiFi. (WiFi sliceCARD is also written: Wi-Fi sliceCARD)

I have made a summary of how the PCIe connector is used (press picture for a PDF):

Fig.3 – XMOS slice I/O with examples from xCORE-200 sliceKIT, startKIT and WiFi sliceCARD (press for PDF)

Looking in [2] we see that we might have trouble picking up 25M_STAR, 25M_TRI and SLI_RST_N that on the xCORE-200 sliceKIT are connected to a tile 0 sub circuit, and not to any pin that would available on the xCORE-200 explorerKIT. However, by looking at the WiFi sliceCARD we see that these pins are not used. (More about STAR, SQUARE, TRIANGLE and CIRCLE at XCore: Wi-Fi sliceCARD and ports on startKIT.)

I conclude from this that I cannot on the xCORE-200 explorerKIT connect a general one-to-one PCIe sliceCARD connector break-out board that I might solder myself.

However, I would be able to find pins to connect the WiFi sliceCARD to the xCORE-200 explorerKIT since 25M_STAR, 25M_TRI and SLI_RST_N are not used. (I have a Sullins Connector Solutions NWE18DHHN-T931 CONN PCI EXP FEMALE 36POS 0.039 that I found here).

XCore: Connecting a WiFi sliceCARD to xCORE-200 eXplorerKIT?

I queried about this at XCore Exchange, see Connecting a WiFi sliceCARD to xCORE-200 eXplorerKIT?

My WiFi sliceCARD breakout board

I made the board! Also, the code runs! (Not without problems, 11Sept2017: stay tuned)

• The SPI slave in the library runs at 12.5 MHz
• The LSR Research TiWi-SL chip [8] is an SPI Slave and handles clock rates of 0-16 MHz, and I have shown it to work also on the eXplorerKIT
• It uses Texas Instrument SimpleLink™ Wi-Fi® CC3000 Software [9].
• As we see later the Wi-Fi TiWi-SL Module Driver supports TCP connections.

I connect it on J1 on eXplorerKIT to the same port pins as the SLICE CONNECTOR on the startKIT. So I won’t have to redefine the port pins. Not that it would have mattered, but it was OK to make the breakout board that way since it became wide enough to be solid enough. I’ve wiped out the MAC address label on this picture (press for more pixels):

Fig.4 – WiFi sliceCARD starKIT-like breakout board for J1 on eXplorerKIT (press for more pixels)

I used a standard breadboard (1/10″ spacing = 2.54 mm) and a non-holed glass fibre board that I bored 1.5 mm holes in (1 mm spacing but zic-zac layout made it not that tight for the holes). I soldered with wires underneath. No shaking hands! I removed unused breadboard matter above J1, so that it’s easier to use the free I/O ports at the same time.

+3.3V isn’t available on J1 so I pick it from the centre pin (P2) of J14. Since +5.0V is P1 I have made it impossible to connect it wrongly with an interlock part filling up J14 entirely.

And here’s the diagram. Observe that the XMOS diagram correctly shows B8 as GND but also wrongly shows the unconnected B3 and B16. See this with Fig.3 above. (Press picture for a PDF):

Fig.5 – Diagram of WiFi sliceCARD starKIT-like breakout board for J1 on eXplorerKIT (press for PDF)

SPI_MO->SPI_DI, SPI_CLK, SPI_DO->SPI_MI, SPI_CS, SPI_EN, SPI_IRQ defines

on tile[0]: spi_master_interface tiwisl_spi =
{
    XS1_CLKBLK_1, // Clock block 1
    XS1_CLKBLK_2, // Clock block 2
    XS1_PORT_1K,  // MOSI SPI_MO  Data Out (when Master). Input  SPI_DI at WiFi module
    XS1_PORT_1J,  // CLK  SPI_CLK
    XS1_PORT_1I,  // MISO SPI_MI  Data In (when Master).  Output SPI_DO at WiFi module
};

on tile[0]: wifi_tiwisl_ctrl_ports_t tiwisl_ctrl =
{
    XS1_PORT_4C, // Was XS1_PORT_4E in downloaded code
                 // nCS     #SPI_CS   Chip Select  is port BIT0 low
                 // nPWR_EN #SPI_EN   Power Enable is port BIT1 low
    XS1_PORT_1L, // nIRQ    #SPI_IRQ  Interrupt    is port BIT  low
};

typedef struct spi_master_interface
{
    clock blk1;               // at XS1_CLKBLK_1
    clock blk2;               // at XS1_CLKBLK_2
    out buffered port:8 mosi; // at SPI_MO  8-bit buffered output (MOSI: Master Output Slave Input)
    out buffered port:8 sclk; // at SPI_CLK 8-bit buffered output
    in buffered port:8 miso;  // at SPI_MI  8-bit input input     (MISO: Master Input Slave Output)
} spi_master_interface;

Installing the drivers

I am not certain if this is structured correctly. Maybe it’s not structured at all. Bear with me, once I find a structure of what I’m trying to structure I’ll try to structure it. (Disclaimer: this doesn’t necessarily mean that XMOS hasn’t given it any structure).

From when I started (but didn’t finish) trying this for the startKIT I had the first three modules installed in xTIMEcomposer:

1. 1. [sc_wifi] – 1v0. These  have the same tag
      1. Status: installed – module_wifi_tiwisl 
      2. Status: installed – app_tiwisl_simple_webserver (also written «web server»)
      3. Status: installed – test_webclient_pkt_gen but it doesn’t show [sc–wifi] in xTIMEcomposer
      4. Status: ? – I assume this is a newer version of module_wifi_tiwisl? However, the [Wi-Fi TiWi-SL Module Driver –  1.1.1rc0.a November 11, 2013] (Wi-Fi TiWi-SL Module Driver) is probably what I’m after. It says «This component drives the TiWi-SL Wi-Fi module fitted on the XA-SK-WIFI sliceCARD. The TiWi-SL module is a SPI slave and is clocked at 12.5 MHz. Supports TCP connections.» I think the code are the three first points here
         In xtcp_client.h we see XTCP_PROTOCOL_TCP (Transmission Control Protocol) and XTCP_PROTOCOL_UDP (User Datagram Protocol. Not supported in this version)
      5. Status: ? – Demo code: [TiWi-SL Simple Webserver Demo Quickstart Guide – 1.1.1rc0.a November 11, 2013], at here. It says «This application uses the XA-SK-WIFI sliceCARD together with the xSOFTip module_wifi_tiwisl and demonstrate: Connecting to a wireless access point, Run a simple HTTP webserver to display a “Hello World!” webpage.»
      6. Status: installed – Embedded Webserver Library [lib_webserver – 2.0.1 January 07, 2016]. See https://www.xmos.com/support/libraries/lib_webserver
         • This library includes its own description. It’s also at Embedded Webserver Library
           • Its usage is described in AN00122: Using the XMOS embedded webserver library. This also includes example code called [AN00122_using_webserver_library]. Observe: Before you go on, this code runs on SliceKIT Core Board (XP-SKC-L2) with Ethernet Slice (XA-SK-E100) and GPIO Slice (XA-SK-GPIO) with Ethernet PHY device through an MII (Media Independent Interface). The problem is that eXplorerKIT uses RGMII. (But it should be possible to use RGMII, since [lib_ethernet] supports both RGMII and MII! (see below)). (The XMOS Programming Guide (here) contains a mention of MII: «For example, if the device was connected to an Ethernet PHY using the MII protocol, a clock block could be attached to a port connected to the RXCLK signal, which could then be used to drive the port which samples the data of the RXD signal.» (page 62). This may be useful if one is going to try to undersdtand the code or write one’s own.) To follow the «not possible» path see, ie. start at note Me relying on relaying BLE? chapter E = Wired RJ45 Ethernet.
             It requires these two libraries that I installed from the Libraries window in xTIMEcomposer:
           • Status: installed – TCP/IP Library [lib_xtcp – 6.0.0]
           • Status: installed – Ethernet MAC library [lib_ethernet – 3.3.0].  However, observe that the [lib_ethernet] (as used by AN00122 runs both on MII and RGMII! It features «Media Independent Interface (MII) and Reduced Gigabit Media Independent Interface (RGMII) to the physical layer» (here).
         • And the embedded webserver is further described in Embedded Webserver Library Programming Guide
         • Don’t forget to have a look at the non-websever library actually written first for the eXplorerKIT. See See AN00199 Gigabit Ethernet demo
      7. 1.1-3h have I once downloaded from GiHub; the WiFi Repository [sc_wifi – 1.1.2rc0] at GitHub (https://github.com/xcore/sc_wifi). The bundle sc_wifi-master comes with the modules and apps above, but also with the extra files Makefile, LICENSE.txt,  README.rst  (lLatest release: 1.1.2rc0), xpd.xml and CHANGELOG.rst. (Changes to dependencies: sc_spi: 1.4.0rc0 – so it’s not been tested with 1.4.0rc1)
   2. [sc_spi] – 1v0. These  have the same tag
      1. Status: installed – module_spi_master
      2. Status: installed – module_spi_slave
      3. Status: installed – app_spi_loopback_demo
      4. Status: installed – app_spi_master_demo
      5. 2.1-4 I once downloaded from GitHub; the SPI SOFTWARE COMPONENT [1.4.0rc1]. See https://github.com/xcore/sc_spi/blob/master/README.rst. The bundle sc_spi_master comes with the modules and apps above, but also with the extra files Makefile, LICENSE.txt,  README.rst (latest release 1.4.0rc1), xpd.xml and CHANGELOG.rst (Changes to dependencies: sc_slicekit_support: 1.0.4rc0)
   3. I deleted 1.1 and 2.1-2 to try to start afresh. But as the list below grew longer and longer I undid that. (I undid by using «Import», «Import Existing Projects into Workspace» from my backup.) The scheme right now is to install every piece of code I can find and then see. After all I am a sw engineer, it’s not magic!
   4. But I did start with rereading a thread I started on XCore a while ago: Chicken and egg: xTIMEcomposer and GitHub.
   5. Status: installed – SPI Library [lib_spi –  3.0.2 January 07, 2016]. Found in the Libraries tab that searches content from https://www.xmos.com in xTIMEcomposer.
      • See a version of spi_master called spi_master_2 that I made, that runs on the startKIT, here. The code also is there
      • Also see https://www.xmos.com/support/libraries/lib_spi and my errata here
   6. There is no xCORE-200 eXplorer support module or library. But there may be something in these two:
   7. Status: installed – module_slicekit_support [sc_slicekit_support]. Unknown version, probably 1.0.4rc0 since it’s mentioned above
   8. Status: installed – Slicekit Core Board Support Library [lib_slicekit_support – 2.0.1 January 07, 2016] from Libraries tab in xTIMEcomposer. See https://www.xmos.com/support/libraries/lib_slicekit_support
   9. Now maybe it’s time to start at the present presentation WiFi sliceCARD [3] (or here). It presents these papers:
      1. sliceKIT Modular Development System Product Brief [1.3 – April 16, 2014]
      2. sliceKIT Selector Sheet [4.0 – May 30, 2014]
         • WI-FI sliceCARD
           The Wi-Fi sliceCARD uses a high performance 2.4GHz WLAN module to bring 802.11b/g wireless connectivity to sliceKIT, with throughput of up to 7Mbps. Using the ready-built xSOFTip SPI component, it allows you to easily integrate the wireless module into your application. Our xSOFTip Explorer tool includes demo apps and full documentation to get you started quickly
      3. sliceKIT daughtercard port mappings [1.0 – April 27, 2014]
      4. GPIO Wi-Fi Demo Quick Start Guide [1.0.4rc0.a – March 12, 2013]
         • It is here. It says «This example demonstrates the use of two Slice Cards, XA-SK-GPIO and XA-SK-WIFI slice together with the xSOFTip components for Wi-Fi, SPI, I2C and WebServer to provide access to the GPIO slice features via a simple embedded webserver.»
      5. Status: installed – lib_logging [lib_logging – 2.1.0 – October 27, 2016]. Imported directly in xTIMEcomposer. From Debug Printing Library : It «Features Low memory usage, Ability to enable or disable printing via compile options and Ability to enable or disable printing for sets of source files». «This function works like C-standard printf except that it only accepts d, x, s, u and c format specifiers with no conversions.» Just import and replace #include print.h with #include debug_print.h. (I have some more about it here, search «lib_logging»). An older version of some if this is Debug Printing Module.
   10. Dead end:
       Instead I went to GitHub at https://github.com/xmos where I found [lib_wifi – 0.0.2]: lib_wifi. But I think this is a newer, more generalised library and not what I’m looking for. It’s dependent on lib_xtcp(>=5.1.0) lib_ethernet(>=3.0.3) lib_gpio(>=1.0.0) lib_filesystem(>=0.0.1) lib_xassert(>=2.0.0) lib_logging(>=2.0.0) lib_locks(>=2.0.2) but it doesn’t say anything about tiwisl. (Update: Gothmag on XCore Exchange replied that «lib_wifi does seem to be a newer lib if they properly supported it but I’m not sure they do, as in it seems almost entirely abandoned by them and I don’t think a slice with that wifi module was ever released. They also don’t seem to have any lib/module/examples accessible from within xTimeComposer itself as you mentioned.»)
   11. I’ll keep you posted about how I pick the SW as it develops. I want to end up with something that should run on the startKIT as well as the xCORE-200 eXplorerKIT
   12. Status: installed – app_mutual_comm_example
       28Nov2017: When I started working with My WiFi101 library port I needed to learn the app_tiwisl_simple_webserver architecture. I also looked at lib_webserver and lib_xtcp. Then I discovered a file in the former called mutual_thread_comm.h/.c. «This method allows a form of mutual bi-direction communication over a single channel. See app_mutual_comm_example for a simple example of its use.» Ok, I downloaded as a bundled zip from GitHub at https://github.com/xcore/sc_util (because the other mechanisms didn’t work, see XCore Exchange http://github.xcore.com/sc_util does not exist).

       Importing sources from another directory

       (Out-of-order chapter, for the url. I needed to refer it from here)

       Using files that are not in present workspace

       I then «imported» (since not using the Import menu) the app_mutual_comm_example by | File | New | xTIMEcomposer Project Based on Existing Application or Module. I had placed the sc_util-master directory that came with the downloaded zip not in the workspace directory. But I pointed to it in the dialogue box and bingo, it was properly imported and usable, but at the original position! But versioning is lost! I have done this many times before, but now I’ve written it down. It’s only easy when you see how easy it actually is. I must admit that I have always tried several alternatives along the import path before it did find the right one.

       1. Observe that I the modern method (mentioned earlier) is using the Libraries window in xTIMEcomposer to fetch libraries directly from www.xmos.com. It also takes care of versioning. At least I hope so even if I haven’t seen it do it, as I did see the Arduino update projects the other day
          
       2. As an aside I’ll study the app_mutual_comm_example, with this comment in mind: note 141 chapter Using a chanend in both directions

       Importing library files from another location into workspace

       I am still struggling with this! I made a new project of the correct type in the present workspace, with the same name as one I was going to move the files from. I then drag and dropped the files that were in another directory (put there from an imported zip file?) with the Finder into this new project. (6Aug2018).

1. There also is a separate non-webserver Application Note: AN00199 XMOS Gigabit Ethernet application note . It also contains code called [AN00199_gigabit_ethernet_demo]. Since this is written on the eXplorerKIT first, I suspect it would have the facit of the internal MII (Media Independent Interface IEE802.3u) (The eXplorerKIT uses the Reduced gigabit media-independent interface, (RGMII) see the [lib_ethernet] documentation where it says that «xCORE-200 XE/XEF devices have a set of pins that are dedicated to communication with a Gigabit Ethernet PHY or switch via RGMII, designed to comply with the timings in the RGMII v1.3 specification») connections to the PHY (Physical layer chip). In addition to [lib_ethernet] it needs:
   • Status: installed – OTP reading library [lib_otp – 2.0.1]

WELCOME TO THE SIMPLE WEBSERVER DEMO worked!

1. In Makefile I changed the target to XCORE-200-EXPLORER
2. And of course I now use XTAG3 ([7])
3. In xhttpd.xc I inserted my values for WIFI_SSID and WIFI_PASSWORD
4. In main.xc I modified wifi_tiwisl_ctrl_ports_t bit0 from XS1_PORT_4E to XS1_PORT_4C
5. Bingo! It worked the absolute first time I ran it! The XMOS WiFi and SPI (++) code worked, my WiFi sliceCARD SPI breakout board worked, as well as the WiFi sliceCARD. Here’s the proof: The xTIMEcomposer window. The Apple AirPort Utility (I removed most of the values) plus a Safari browser tab. «Hello world!»

Fig.6 – XMOS **WELCOME TO THE SIMPLE WEBSERVER DEMO** (press for fullpixel)

Here’s the build log, built with xTIMEcomposer 14.3.0. I have added colours: module_wifi_tiwisl module_spi_master and _app_tiwisl_simple_webserver to see what belongs to where:

Build log

xmake all 
Checking build modules

Analyzing httpd.c
Analyzing hci_helper.c
Analyzing hci_pkg.c
Analyzing tiwisl_event_handler.c
Analyzing main.xc
Analyzing xhttpd.xc
Analyzing xtcp_client.xc
Analyzing wifi_tiwisl_server.xc
Analyzing wifi_tiwisl_spi.xc
Analyzing spi_master.xc
Creating dependencies for spi_master.xc
Creating dependencies for wifi_tiwisl_spi.xc
Creating dependencies for wifi_tiwisl_server.xc
Creating dependencies for xtcp_client.xc
Creating dependencies for xhttpd.xc
Creating dependencies for main.xc
Creating dependencies for tiwisl_event_handler.c
Creating dependencies for hci_pkg.c
Creating dependencies for hci_helper.c
Creating dependencies for httpd.c
Compiling httpd.c
Compiling hci_helper.c
Compiling hci_pkg.c
Compiling tiwisl_event_handler.c
Compiling main.xc
Compiling xhttpd.xc
Compiling xtcp_client.xc
Compiling wifi_tiwisl_server.xc
Compiling wifi_tiwisl_spi.xc
Compiling spi_master.xc
Creating app_tiwisl_simple_webserver.xe
Constraint check for tile[0]:
  Cores available:            8,   used:          2 .  OKAY
  Timers available:          10,   used:          2 .  OKAY
  Chanends available:        32,   used:          2 .  OKAY
  Memory available:       262144,   used:      15292 .  OKAY
    (Stack: 2108, Code: 9184, Data: 4000)
Constraints checks PASSED.
Constraint check for tile[1]:
  Cores available:            8,   used:          1 .  OKAY
  Timers available:          10,   used:          1 .  OKAY
  Chanends available:        32,   used:          0 .  OKAY
  Memory available:       262144,   used:       1064 .  OKAY
    (Stack: 348, Code: 596, Data: 120)
Constraints checks PASSED.
Build Complete

Wireless device roles

I think that the roles [4] here go as follows: The WiFi sliceCARD logs onto the master wireless router and gets its ip address from it. After this the WiFi sliceCARD communicates with client itself, directly. This is a according to a range of protocol, starting (I think) with 802.11up to TCP, and these are all handled by the LSR Research TTiWi-SL board’s ARM processor (again: [8]). I can actually observe this direct communication by seeing that getting the Hello World! text on the phone and then walking around the house, I lose it quite fast, while the network itself is well within range. My routers (master and bridge) don’t seem to be involved.

However, should my application need to get something from the internet the communication would of course be routed over the WiFi router into the Wide Area Network (WAN) wire to my Internet Service Provider (ISP).

Of course, the ip address needs to be on your wireless network. I have an internal Wi-Fi network with access to my network disks, and one for guest. So, to impress my kids who come home every now and then and fire up a connection on the guest network, I’d have to do my homework first.

Analysis and xSCOPE

1. I made a project _app_tiwisl_simple_webserver derived from app_tiwisl_simple_webserver to get my own changes in there
2. I added a counter seen as  «Hello World! 123» that was incremented for every http GET
3. I saw that even if parse_http_request was run within some hundred ms when I pressed update in the browser it took 1-2 seconds before the Hello World! 124 was seen in the browser. Where is the delay? I want to analyse with the tools that are integrated with xTIMEcomposer. So this certainly is about time:
4. I hadn’t used xSCOPE before so I downloaded AN00196 Getting started with real time xSCOPE in xTIMEcomposer Studio. The scope sw reminds me of the rather strange gui of my bitscope USB scope (described here). What is a button’s name and what is a state, rather confusing. The PDF that came with AN00196 didn’t describe it all; I should have started with xTIMEcomposer User Guide, Part G: Application Instrumentation and Tuning [5].
   – The code just sending 64 values values to xSCOPE took about 0.1 ms. But when I added a printf (or even two) it took 3000 ms, a decrease of time of 30.000 times. I also added a round count and made that a second probe. This was an interesting exercise, because that linear curve didn’t fill up as much of the window as the sine. It only went from first trigger to last trigger of the sine (press for full screen):
   

   Fig.7 – xSCOPE short «round»

   – But this is logical, it shows the calls to xscope_int in that range. When I instead put the call to both values’ xscope_int inside the loop both were visible full width (press for full screen):

   

   Fig.8 – xSCOPE wide «round»

   – It also took me some time to learn to increase or decrease values in the gui; like Samples/Div. Increase by left mouse button, decrease by right button. And that the granularity of Offset is defined by the Samples/Div value.
   – The above screen clips are Real-Time Mode, with no axis names. However, ticking Offline Mode in the Run configurations file will generate a log file (.xmt) that when opened is seen in a client that sets up axis names and gives me better tools to analyse

5. Aside: When I analyse the code I see XC transaction being used. This is the first time I see it. In the main webserver thread in xhttpd.xc in _app_tiwisl_simple_webserver the transaction xtcp_event is the only event that hangs on the main select. But xtcp_event resides in i completely different library, in module_wifi_tiwisl file xtcp_client.xc. This is rather nice and certainly couldn’t be done in occam
6. I have added printouts in function httpd_handle_event in file httpd.c, called from the main webserver thread, like this – so that I can remove the printouts easily. Courtesy C #define macro for debug printing at stackoverflow (for a timed version of this, see debug_tc_printf later on):

   #define DEBUG_PRINT_HTTPD 1 // 0 no printouts and no code
   #define debug_printf(fmt, ...) \
       do { \
           if(DEBUG_PRINT_HTTPD) \
               printf(fmt, __VA_ARGS__); \
       } while (0) // gcc-type ##__VA_ARGS__ doesn't work
   ..
   debug_printf ("not httpd_handle_event %u %s\n", conn->event, "XTCP_IFUP new ip address");

In the Loading SPI_CLK is no good thread at xCORE Exchange I learned that XMOS has a much faster and lighter debug_printf that they adviced me to use instead. In order to use it, import lib_logging, already mentioned. It has a scheme to enable or disable printing via compile options and a scheme to enable or disable printing for sets of source files. Use that instead of my suggestion above! (But I guess the timed debug debug_tc_printf scheme below would live its own life).

Loading SPI_CLK is no good

If I connect the SPI_CLK output pin (search to see its definition) to my BitScope USB scope I get a crash when I run in xTIMEcomposer. That goes even if I use a USB isolator. The scope has internal impedance of 1M||50pF. The crash I get looks like this:

[  555 ms] **WELCOME TO THE SIMPLE WEBSERVER DEMO**
[  606 ms] Switching on Wi-Fi module.... 
[  657 ms] init
[ 1761 ms] WriteN 1 10   // In wifi_tiwisl_spi_first_write
[ 2416 ms] read2 1 ff.ff // After last spi_master_in_buffer in wifi_tiwisl_spi_read 
                         // in file wifi_tiwisl_spi.xc in module module_wifi_tiwisl
xrun: Program received signal ET_ILLEGAL_PC, Illegal program counter.
      [Switching to tile[0] core[1]]
      0xffffffff in ?? ()

This is 100% repeatable. If I connect the scope when it’s started OK then all is fine. Red text is mine.

• If connect a 1M||47pF between SPI_CLK and GND then it hangs after the «init» text. Repeatable
• If connect a 1M||47pF between SPI_CLK and 3V3 then it hangs after the «WriteN 1 10» text. Repeatable
• If I connect any of these when it’s started OK, it stops. I even see it stop during startup with just the 20 cm wire hanging on SPI_CLK

I can understand the complete stop behaviour since the code does blocking calls waiting for things to go high or low with no timeout. But then, the SPI_CLK is just an output, isn’t it?

But the elegant message from xrun is more than I understand. How can the program counter become illegal? What’s going on?

Some adjacent search words: load, float, floating, oscilloscope probe, crash.

XCore Exchange «Loading SPI_CLK is no good»

I made an XCore Exchange entry for this point. See https://www.xcore.com/viewtopic.php?f=8&t=6068. I have added lots of scope pictures there (read with my new PicoScope, blogged at My PicoScope notes). User infiniteimprobability has a hypotheses that I think should be investigated by the XMOS engineers:

Hmm – does definitely sound like this issue about cascaded clocks going via the output pad.

Loading the SPI_CLK pin (that has bursts of eight 12.5 MHz pulses) with 1M par 47pF to GND causing it to fail running correctly is, the least, a situation XMOS should inform about. If not, a sound exception should be given, like ET_CASCADED_CLOCK_VIA_PORT_PIN_HAS_STOPPED_PROCESSOR

Fig.13 – SPI_CLK as seen with a PicoScope 2208B MSO (press for more pixels)

The SPI_CLK looks like seen above, done with PicoScope.

Update 27Feb2019: This problem seems to have reappeared with my code. I am working on the problem. Stay tuned or mail me if you have the problem of  «don’t know why this change of code causes this difficult-to-catch error» or when connecting a scope causes a stop. Maybe those are two problems. Back in Sep2017 infiniteimprabability also wrote:

Regarding loading the CLK output, I wonder if it is related to the way clocks are handled in the architecture? If you make an I/O pin an output from a clock block AND carry that clock into another clock block then the carried signal is actually derived from the pad (after the output buffer). This gives the unwanted side effect that loading the clock output pin can affect the downstream logic. For example, in the old I2S scheme where the BCLK was a port output that also clocked the BCLK clock block (which clocks the data and LR), poor SI on the BCLK line could cause double clocking due to reflections coming back along the transmission line. Good SI/board design and/or using series resistors (22–33R) will avoid this as will using a buffer.

Hello World! works, but it takes long time to finish (1)

1. Here are two Hello World! sequences (in blue, colours and bold added for blog note only). Without using xSCOPE now I can easily see that the wasted time is between XTCP_SENT_DATA and XTCP_CLOSED. The conn->event enum values are nice to have for later, when analysing an xSCOPE curve offline. Later I have also added the timing as observed in xSCOPE Offline mode. They would fluctuate some:
   

   Hello World internal log (1)

   TCP in operation:

   **WELCOME TO THE SIMPLE WEBSERVER DEMO**
   Switching on Wi-Fi module.... ok!
   Connecting to OM11-4
   IP Address: 192.168.1.6
   not httpd_handle_event 9 XTCP_IFUP new ip address
   httpd_handle_event 0 XTCP_NEW_CONNECTION // Time: 0.00 sec
   httpd_handle_event 1 XTCP_RECV_DATA      // Time: 0.05 sec
   GET "Hello World!" 1 
   httpd_handle_event 2 XTCP_REQUEST_DATA   // Time: 0.27 sec
   httpd_handle_event 3 XTCP_SENT_DATA      // Time: 0.32 sec
                                            //       What is it doing now?
   httpd_handle_event 7 XTCP_CLOSED         // Time: 1.39 sec
   
   httpd_handle_event 0 XTCP_NEW_CONNECTION
   httpd_handle_event 1 XTCP_RECV_DATA
   GET "Hello World!" 2
   httpd_handle_event 2 XTCP_REQUEST_DATA
   httpd_handle_event 3 XTCP_SENT_DATA
   httpd_handle_event 7 XTCP_CLOSED

   Next is #hello_world_internal_log_2 (below)

2. The xTIMEcomposer xSCOPE screen clip in Offline mode for the above is seen below. Press for fullpixel. (Well, there are 5 sequences). There seems to be some x-axis offset error, 2 is not at 2 and 7 is just above 6.
   

   Fig.9 – xSCOPE of the above

3. When I, in the web browser pressed update quite fast (in order to see if the web client then didn’t close the connection) I got this error message. I will investigate later on.

   xrun: Program received signal ET_ILLEGAL_RESOURCE, Resource exception.
         send_cmd (conn_id=0, cmd=XTCP_CMD_CLOSE, c_xtcp=2147614978) at /module_wifi_tiwisl/src/xtcp_client.xc:14
         14            c_xtcp <: cmd;
   
   <terminated>_app_tiwisl_simple_webserver.xe [xCORE Application]
           <terminated, exit value: 125>xrun (13:58 23.08.17)
   <terminated>_app_tiwisl_simple_webserver.xe [xCORE Application]
           <terminated, exit value: 125>xrun (13:59 23.08.17)
   

4. Observe that wifi_tiwisl_server.xc causes these warnings if -Wall is set in Makefile:  -Wshadow, -Wsign-compare, -Wswitch-default. XMOS should have issued an update to avoid them as they are totally unnecessary. I didn’t do that, so I can’t have -Wall

Profiling

Now is the time for profiling the code. xTIMEcomposer may generate files for Gprof. It’s described in [6]. It looks to me like tile[1]:core[1] is used for xSCOPE and that user code is placed in tile[0].core[1]. Here’s the gprof window:

Fig.10 – Gprof window

The code spends 68% of its time in function wifi_tiwisl_spi_read in file wifi_tiwisl_spi.xc in module_wifi_tiwisl. Below is the xmos code. I think it must be the line that waits for the irq line that would be the one that burns most of the cycles. The location is 0x41a9e, but how do I ensure that this is the place? I couldn’t find it in the mapfile (see how to make it here). I’ll research some more. (Trying to debug with asm window)

// spi_master_read
void wifi_tiwisl_spi_read(spi_master_interface &spi_if,
                          wifi_tiwisl_ctrl_ports_t &spi_tiwisl_ctrl,
                          unsigned char buffer[],
                          unsigned short num_bytes,
                          int bypass_cmd)
{
  // Wait for IRQ to be low

spi_tiwisl_ctrl.p_spi_irq when pinseq(0) :> void;

  // Assert CS
  spi_tiwisl_ctrl.p_cs_pwr <: ASSERT_NCS;
  if (!bypass_cmd)
  {
    // Issue the read command
    spi_master_out_buffer(spi_if, spi_read_header, SPI_READ_SIZE);
  }
  // Read the SPI data from device
  spi_master_in_buffer(spi_if, buffer, num_bytes);
}

It’s probably no problem to burn cycles here. I assume that the rest of the code can’t do anything before the TiWi-SL chip has data for it. Any such spin-loop (passive in the code, that nice one-liner) that would block for any other task would have gotten a separate core. Since the xmos coder hasn’t done that then I assume it’s ok. So I don’t think this explains the long time after XTCP_SENT_DATA before XTCP_CLOSED. Of course, if this spinning reflects some application level protocolling back and forth that takes a lot of time then that would probably falsify my conclusion above.

Adding a get_time_now function to use with c files

In order to print out present time in us in front of every debug_printf (see above) I made this new macro.

Observe that «On XMOS XS-1 devices the clock will run at 100MHz» (XMOS Programming Guide). Therefore it counts to 100 in a μs (XS1_TIMER_MHZ in timer.h), which we have to divide by. This also means that it wraps around after 2exp32=4294967296 100 MHz pulses = 42949 ms. So in our case we use ms by dividing with XS1_TIMER_KHZ (100*1000):

#define debug_t_printf(fmt, ...) \ /* not thread safe, see below */
do { \
    if(DEBUG_TIWISL_SERVER) { \
        timer p_time; \
        unsigned p_time_now; \
        p_time :> p_time_now; \
        printf ("[%5u ms] ", p_time_now/XS1_TIMER_KHZ); \
        printf(fmt, __VA_ARGS__); \
    } \
} while (0) // gcc-type ##__VA_ARGS__ doesn't work for XC

You’ll find timed printf also discussed at XCore Exchange here. Observe that the %5u formatting is not done if you use lib_logging ande debug_printf.h. It resolves to %u.

However, it could only be used in an .xc file, since the global timer isn’t available from c. I needed this from httpd.c. I then added this function in xtcp_client.xc since it was used by httpd.c:

unsigned get_time_now (void) {
    timer p_time;
    unsigned p_time_now;
    p_time :> p_time_now;
    return p_time_now; // Wraps at 2expp32 = 4294967296 100 MHz counts (42949 ms)
}

I then could get the time and print it out in httpd.c like this:

#define debug_tc_printf(fmt, ...) \ /* not thread safe, see below */
do { \
    if(DEBUG_PRINT_HTTPD) { \
        unsigned p_time_now = get_time_now(); \
        printf ("[%5u ms] ", p_time_now/XS1_TIMER_KHZ); \
        printf(fmt, __VA_ARGS__); \
    } \
} while (0) // gcc-type ##__VA_ARGS__ doesn't work (correction in debug_tc_printf2)

Observe that the above debug_tc_printf macros are not atomic (ie. not thread safe). In this example I see this when it prints from module_wifi_tiwisl and httpd_handle_event which are par placed on different logical cores. I solved this by adding [..] around every debug_t_printf on one core and (..) around the other. It would look like this on one crash core crash (I added colour coding for this note):

-- Not thread safe --
[ 2160 ms] [readN 2390 N=21]
[ 2211 ms] [deassert]
( 2262 ms) (httpd_handle_event 2 XTCP_REQUEST_DATA)
( 2313 ms) [ 2313 ms] (httpd_handle_event 3 XTCP_SENT_DATA)
[writeN 1193 N=202]
[ 3425 ms] [read2 2391 00.0b]

It’s not elegant. I’ll look at the suggestion in XCore Exchange shown above, but if this one isn’t safe I guess it isn’t either. I guess they have to be collapsed into one single printf, which seems to be thread safe. Update: the XCore Exchange shown above solution is not atomic either. I tried it for those above.

Atomic, thread safe version timed printf

I have posted a question on stackoverflow about this. See How do I use variadic arguments with printf in a macro?. Kerrek SB did come up with an atomic thread safe solution. Observe the sequence of params to printf and no comma (token pasting) before fmt:

// Wraps at 2exp32 = 4294967296 100 MHz counts (42949 ms)
#define debug_t_printf2(fmt, ...) \ /* is thread safe */
do { \
    if(DEBUG_TIWISL_SERVER) { \
        timer p_time; \
        unsigned p_time_now; \
        p_time :> p_time_now; \
        printf("[%5u ms] " fmt, p_time_now/XS1_TIMER_KHZ, __VA_ARGS__); \
    } \
} while (0) // gcc-type ##__VA_ARGS__ doesn't work

// Shortest usage since ## not allowed for XC: 
debug_t_printf2 ("%s", "Hello World!\n");

and for C. Observe that ##__VA_ARG__ is allowed:

// Wraps at 2exp32 = 4294967296 100 MHz counts (42949 ms)
#define debug_tc_printf2(fmt, ...) \ /* is thread safe */
do { \
    if(DEBUG_PRINT_HTTPD) { \
        unsigned p_time_now = get_time_now(); \
        printf("[%5u ms] " fmt, p_time_now/XS1_TIMER_KHZ, ##__VA_ARGS__); \
    } \
} while (0) // gcc-type ##__VA_ARGS__ allowed

// Shortest usage since ## is allowed for C: 
debug_tc_printf2 ("Hello World!\n");

Again observe that the %5u formatting is not done if you use lib_logging ande debug_print.h. It resolves to %u. The thread safe log now goes like this. After this I will remove the [..] and (..) decorations:

-- Thread safe --
[28241 ms] [readN 9132 N=21]
[28293 ms] [deassert]
(28344 ms) (httpd_handle_event 2 XTCP_REQUEST_DATA)
(28394 ms) (httpd_handle_event 3 XTCP_SENT_DATA)
[28394 ms] [writeN 4562 N=202]
[29504 ms] [read2 9133 00.0b] 

Hello World! works, but it takes long time to finish (2)

The reason for the long timing seems to be the rather large amount of bytes being sent across the SPI bus. The only thing I need to understand now is why the connection is closed every time, when that seems to take most of the time.

Previous was #hello_world_internal_log_1 (above).

Hello World internal log (2)

[ 1647 ms] poll-b
[ 1697 ms] writeN 79 N=14: 01.00.09.00.00.01.05.10.04.00.00.00.00.00
[ 1803 ms] read2 161 00.15
[ 1854 ms] readN 162 N=21: 04.05.10.11.00.00.00.00.00.02.00.00.00.02.00.45.f7.95.01.a8.c0
[ 1955 ms] deassert
[ 2006 ms] writeN 80 N=34: 01.00.1d.00.00.01.09.10.18.02.00.00.00.ff.ff.00.00.01.00.00.00.08.00.00.00.04.00.00.00.05.00.00.00.00
[ 2163 ms] read2 163 00.09
[ 2214 ms] readN 164 N=9: 04.09.10.05.00.00.00.00.00
[ 2266 ms] deassert
( 2317 ms) httpd_handle_event 0 XTCP_NEW_CONNECTION
[ 2367 ms] writeN 81 N=22: 01.00.11.00.00.01.04.10.0c.02.00.00.00.b0.04.00.00.00.00.00.00.00
[ 2469 ms] read2 165 00.11
[ 2520 ms] readN 166 N=17: 04.04.10.0d.00.02.00.00.00.5f.01.00.00.01.00.00.00
[ 2624 ms] deassert
( 2675 ms) httpd_handle_event 1 XTCP_RECV_DATA
[ 2675 ms] read2 167 01.7d
[ 2779 ms] readN 168 N=381: 02.85.18.77.01.02.00.00.00.0c.00.00.00.5f.01.00.00.00.00.00.00.00.00.00.00.00.00.00.00.47.45.54.20.2f.20.48.54.54.50.2f.31.2e.31.0d.0a.48.6f.73.74.3a.20.31.39.32.2e.31.36.38.2e.31.2e.36.0d.0a.55.70.67.72.61.64.65.2d.49.6e.73.65.63.75.72.65.2d.52.65.71.75.65.73.74.73.3a.20.31.0d.0a.41.63.63.65.70.74.3a.20.74.65.78.74.2f.68.74.6d.6c.2c.61.70.70.6c.69.63.61.74.69.6f.6e.2f.78.68.74.6d.6c.2b.78.6d.6c.2c.61.70.70.6c.69.63.61.74.69.6f.6e.2f.78.6d.6c.3b.71.3d.30.2e.39.2c.2a.2f.2a.3b.71.3d.30.2e.38.0d.0a.55.73.65.72.2d.41.67.65.6e.74.3a.20.4d.6f.7a.69.6c.6c.61.2f.35.2e.30.20.28.4d.61.63.69.6e.74.6f.73.68.3b.20.49.6e.74.65.6c.20.4d.61.63.20.4f.53.20.58.20.31.30.5f.31.31.5f.36.29.20.41.70.70.6c.65.57.65.62.4b.69.74.2f.36.30.33.2e.33.2e.38.20.28.4b.48.54.4d.4c.2c.20.6c.69.6b.65.20.47.65.63.6b.6f.29.20.56.65.72.73.69.6f.6e.2f.31.30.2e.31.2e.32.20.53.61.66.61.72.69.2f.36.30.33.2e.33.2e.38.0d.0a.41.63.63.65.70.74.2d.4c.61.6e.67.75.61.67.65.3a.20.6e.62.2d.6e.6f.0d.0a.41.63.63.65.70.74.2d.45.6e.63.6f.64.69.6e.67.3a.20.67.7a.69.70.2c.20.64.65.66.6c.61.74.65.0d.0a.43.6f.6e.6e.65.63.74.69.6f.6e.3a.20.6b.65.65.70.2d.61.6c.69.76.65.0d.0a.0d.0a.00

Non-ascii in [..]:
…[2][133][24]w[1][2][0][0][0][12][0][0][0]_[1][0][0][0][0][0][0][0][0][0][0][0][0][0][0]GET / HTTP/1.1[13][10]Host: 192.168.1.6[13][10]Upgrade-Insecure-Requests: 1[13][10]Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8[13][10]User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8[13][10]Accept-Language: nb-no[13][10]Accept-Encoding: gzip, deflate[13][10]Connection: keep-alive[13][10][13][10][0]
[ 3761 ms] deassert
[ 3815 ms] poll-e used 2168 ms
( 3815 ms) GET "Hello World! 2"
[ 3916 ms] poll-b
[ 3970 ms] writeN 82 N=14: 01.00.09.00.00.01.05.10.04.00.00.00.00.00
[ 4072 ms] read2 169 00.15
[ 4122 ms] readN 170 N=21: 04.05.10.11.00.00.00.00.00.fe.ff.ff.ff.02.00.00.00.00.00.00.00
[ 4224 ms] deassert
[ 4275 ms] writeN 83 N=22: 01.00.11.00.00.01.04.10.0c.02.00.00.00.b0.04.00.00.00.00.00.00.00
[ 4614 ms] read2 171 00.11
[ 4649 ms] readN 172 N=17: 04.04.10.0d.00.02.00.00.00.00.00.00.00.01.00.00.00
[ 4750 ms] deassert
[ 4803 ms] poll-e used 887 ms
[ 4854 ms] cmd 5
[ 4905 ms] poll-b
[ 4956 ms] writeN 84 N=14: 01.00.09.00.00.01.05.10.04.00.00.00.00.00
[ 5059 ms] read2 173 00.15
[ 5114 ms] readN 174 N=21: 04.05.10.11.00.00.00.00.00.fe.ff.ff.ff.02.00.00.00.00.00.00.00
[ 5219 ms] deassert
( 5269 ms) httpd_handle_event 2 XTCP_REQUEST_DATA
( 5320 ms) httpd_handle_event 3 XTCP_SENT_DATA
[ 5320 ms] writeN 85 N=202: 01.00.c5.00.00.02.81.10.c0.00.02.00.00.00.0c.00.00.00.b0.00.00.00.00.00.00.00.48.54.54.50.2f.31.2e.30.20.32.30.30.20.4f.4b.0a.53.65.72.76.65.72.3a.20.78.63.32.2f.70.72.65.2d.31.2e.30.20.28.68.74.74.70.3a.2f.2f.78.6d.6f.73.2e.63.6f.6d.29.0a.43.6f.6e.74.65.6e.74.2d.74.79.70.65.3a.20.74.65.78.74.2f.68.74.6d.6c.0a.0a.3c.21.44.4f.43.54.59.50.45.20.68.74.6d.6c.3e.0a.3c.68.74.6d.6c.3e.3c.68.65.61.64.3e.3c.74.69.74.6c.65.3e.48.65.6c.6c.6f.20.77.6f.72.6c.64.3c.2f.74.69.74.6c.65.3e.3c.2f.68.65.61.64.3e.0a.3c.62.6f.64.79.3e.48.65.6c.6c.6f.20.57.6f.72.6c.64.21.20.32.20.3c.2f.62.6f.64.79.3e.3c.2f.68.74.6d.6c.3e

Non-ascii in [..]:
[1][0][197][0][0][2][129][16][192][0][2][0][0][0][12][0][0][0][176][0][0][0][0][0][0][0]HTTP/1.0 200 OK[10]Server: xc2/pre-1.0 (http://xmos.com)[10]Content-type: text/html[10][10]<!DOCTYPE html>[10]<html><head><title>Hello world</title></head>[10]<body>Hello World! 2 </body></html>

[ 6888 ms] read2 175 00.0b
[ 6945 ms] readN 176 N=11: 04.00.41.07.00.01.00.02.01.01.00
[ 6996 ms] deassert
[ 7047 ms] writeN 86 N=22: 01.00.11.00.00.01.04.10.0c.02.00.00.00.b0.04.00.00.00.00.00.00.00
[ 7314 ms] read2 177 00.11
[ 7353 ms] readN 178 N=17: 04.04.10.0d.00.02.00.00.00.00.00.00.00.01.00.00.00
[ 7456 ms] deassert
[ 7510 ms] poll-e used 2604 ms
[ 7562 ms] cmd 7
[ 7613 ms] close_socket
[ 7668 ms] writeN 87 N=14: 01.00.09.00.00.01.0b.10.04.02.00.00.00.00
[ 7775 ms] read2 179 00.09
[ 7823 ms] readN 180 N=9: 04.0b.10.05.00.00.00.00.00
[ 7877 ms] deassert
[ 7927 ms] poll-b
( 7927 ms) httpd_handle_event 7 XTCP_CLOSED

[ 7981 ms] writeN 88 N=14: 01.00.09.00.00.01.05.10.04.00.00.00.00.00
[ 8188 ms] read2 181 00.15
[ 8239 ms] readN 182 N=21: 04.05.10.11.00.00.00.00.00.fe.ff.ff.ff.02.00.00.00.00.00.00.00
[ 8345 ms] deassert
[ 8396 ms] poll-e used 468 ms

Screen recording to see how Hello World! feels

Observe that pressing the Fig.11 causes a 9.2 MB MPEG-4 (.mp4) movie download!

It was produced on a Mac with QuickTime Player’s screen recording having Safari and xTIMEcomposer running. One sequence with little debug and one with much debug, into two QuickTime (.mov) movies with 1-1 pixel resolution from my 4096 pixel width screen. I made a single longer movie in iMove from both and exported as .mp4 1080 height. So it’s not as nice looking as the real thing. Another thing; I have cheated above, I actually added printf with always taking 5 char width after this recording!

You’ll have to scroll through the movie to try to correlate the logs with the behaviour of the browser. I also tried Chrome, it behaves like Safari but doesn’t visualise it as well. So no movie of Chrome.

What I don’t understand is the long interval after Hello World! 2 has arrived in the browser. It’s probably because I haven’t been this close to http before. The embedded fire detector software I have worked with didn’t use http. I’m climbing the http learning curve. That being said, this board behaves somewhat differently than other sites. It’s so much slower. Why, and does it have to be? Now I’ll scope the signals.

Fig. 11 – PRESS TO DOWNLOAD 9.2MB SCREEN RECORDING MOVIE

An «unsolicited event»

There is a TODO in tiwisl_event_handler.c in function event_checker:

int event_checker(int opcode, unsigned char *rx_buf)
{
  if (opcode == 0)
  {
    //TODO: process_unsolicited_event(c_xtcp, rx_buf);
    debug_tc_printf ("#### #### Unsolicited event %u\n\n", *rx_buf); // Teig
    return 1;
  }
  ...
}

Hello World internal log (3)

(23884 ms) httpd_handle_event 3 XTCP_SENT_DATA
[23884 ms] writeN 5014 N=202: 
[24947 ms] read2 10035 00.0b
[25004 ms] readN 10036 N=11: 
[25005 ms] deassert
(25055 ms) #### #### Unsolicited event 4

[25162 ms] writeN 5015 N=22: 
[25167 ms] read2 10037 00.11
[25216 ms] readN 10038 N=17: 
[25216 ms] deassert
[25267 ms] writeN 5016 N=14: 
[25278 ms] read2 10039 00.09
[25320 ms] readN 10040 N=9: 
[25320 ms] deassert
(25374 ms) httpd_handle_event 7 XTCP_CLOSED

I also see this unsolicited event at other places! Stay tuned, I think I know what that is.

Digging deeper: SPI, HCI, TCP

Digging deeper, not finished yet:

HCI events compared

#define HCI_EVNT_WLAN_UNSOL_BASE (0x8000)
#define HCI_EVNT_WLAN_UNSOL_CONNECT            (0x0001 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_UNSOL_DISCONNECT         (0x0002 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_UNSOL_INIT               (0x0004 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_TX_COMPLETE              (0x0008 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_UNSOL_DHCP               (0x0010 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_ASYNC_PING_REPORT        (0x0040 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_ASYNC_SIMPLE_CONFIG_DONE (0x0080 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_KEEPALIVE                (0x0200 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_BSD_TCP_CLOSE_WAIT            (0x0800 + HCI_EVNT_WLAN_UNSOL_BASE)
// Only in Adafruit code:
#define HCI_EVNT_ASYNC_ARP_DONE                (0x0400 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_ASYNC_ARP_WAITING             (0x0900 + HCI_EVNT_WLAN_UNSOL_BASE)

#define HCI_EVNT_WLAN_UNSOL_BASE               (0x8000)
#define HCI_EVNT_WLAN_UNSOL_CONNECT  	       (0x0001 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_UNSOL_DISCONNECT         (0x0002 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_UNSOL_DHCP               (0x0010 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_ASYNC_PING_REPORT        (0x0040 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_ASYNC_SIMPLE_CONFIG_DONE (0x0080 + HCI_EVNT_WLAN_UNSOL_BASE)
#define HCI_EVNT_WLAN_KEEPALIVE                (0x0200 + HCI_EVNT_WLAN_UNSOL_BASE)

SPI HOST CONTROLLER INTERFACE
The main interface to the TiWi-SL Module is a Serial Peripheral Interface (SPI).
This section describes the SPI Host Controller Interface (HCI).

It then goes on to describe the pins SPI_CLK, SPI_DI, SPI_CS, SPI_IRQ, SPI_DO. By seeing the HCI_EVNT_WLAN_UNSOL_BASE (in fold, above) I then infer that HCI is a memory mapped protocol in the layer above the hardware SPI pins. And XMOS has the spi_master_interface in file spi_master.h that takes care of the same pins (clocks and ports).

XMOS: HCI commands from TCP tag like HCI_CMND_SIMPLE_LINK_START

// XMOS

#define HCI_CMND_SOCKET                            0x1001
#define HCI_CMND_BIND                              0x1002
#define HCI_CMND_RECV                              0x1004
#define HCI_CMND_ACCEPT                            0x1005
#define HCI_CMND_LISTEN                            0x1006
#define HCI_CMND_CLOSE_SOCKET                      0x100B
#define HCI_CMND_SETSOCKOPT                        0x1009
#define HCI_CMND_SEND                             (0x81)
#define HCI_CMND_READ_BUFFER_SIZE                 (0x400B)
#define HCI_CMND_SIMPLE_LINK_START                (0x4000)
#define HCI_CMND_WLAN_IOCTL_SET_SCANPARAM          0x0003
#define HCI_CMND_WLAN_IOCTL_GET_SCAN_RESULTS       0x0007
#define HCI_CMND_WLAN_CONNECT                     (0x0001)
#define HCI_CMND_WLAN_IOCTL_SET_CONNECTION_POLICY (0x0004)
#define HCI_CMND_EVENT_MASK                       (0x0008)

// adafruit and TI

 (only one shown)
#define  HCI_CMND_SIMPLE_LINK_START 0x4000

// XMOS

// Teig annotated with numbers:
typedef enum xtcp_cmd_t {
  XTCP_CMD_LISTEN,             //  (0) 0x00
  XTCP_CMD_UNLISTEN,           //  (1) 0x01
  XTCP_CMD_CONNECT,            //  (2) 0x02
  XTCP_CMD_BIND_LOCAL,         //  (3) 0x03
  XTCP_CMD_BIND_REMOTE,        //  (4) 0x04
  XTCP_CMD_INIT_SEND,          //  (5) 0x05
  XTCP_CMD_SET_APPSTATE,       //  (6) 0x06
  XTCP_CMD_CLOSE,              //  (7) 0x07
  XTCP_CMD_ABORT,              //  (8) 0x08
  XTCP_CMD_TIMED_OUT,          //  (9) 0x09
  XTCP_CMD_SET_POLL_INTERVAL,  // (10) 0x0a
  XTCP_CMD_JOIN_GROUP,         // (11) 0x0b
  XTCP_CMD_LEAVE_GROUP,        // (12) 0x0c
  XTCP_CMD_GET_MAC_ADDRESS,    // (13) 0x0d
  XTCP_CMD_GET_IPCONFIG,       // (14) 0x0e
  XTCP_CMD_ACK_RECV,           // (15) 0x0f
  XTCP_CMD_ACK_RECV_MODE,      // (16) 0x10
  XTCP_CMD_PAUSE,              // (17) 0x11
  XTCP_CMD_UNPAUSE,            // (18) 0x12
  XTCP_CMD_UPDATE_BUFINFO,     // (19) 0x13
  XTCP_CMD_ACCEPT_PARTIAL_ACK, // (20) 0x14
  XTCP_CMD_WIFI_ON,            // (21) 0x15 sends 
                               //           HCI_CMND_SIMPLE_LINK_START
                               //           HCI_CMND_READ_BUFFER_SIZE
                               //           HCI_CMND_EVENT_MASK
                               //           HCI_CMND_WLAN_IOCTL_SET_CONNECTION_POLICY
  XTCP_CMD_WIFI_OFF,           // (22) 0x16
  XTCP_CMD_DISCONNECT          // (23) 0x17
} xtcp_cmd_t;

For each HCI_CMND… (fold, above) there is a blocking wait for the response in function read_and_wait_for_event in file  wifi_tiwisl_server.xc, the nice XCORE XC select with wait for the IRQ is not used. Function wifi_tiwisl_spi_read hangs on a pin change like this: spi_tiwisl_ctrl.p_spi_irq when pinseq(0) :> void; but if WiFi module doesn’t work it will hang forever, but the channel c_xtcp/c_wifi reply from wifi_tiwisl_server might be timed out by its controlling task xhttpd. But it doesn’t.

TI: HCI command by function like SimpleLink_Init_Start

Texas Instruments: For TI (can’t find it in Adafruit code) the HCI_CMND_SIMPLE_LINK_START is wrapped in a function call SimpleLink_Init_Start in file wlan.c with the text «send HCI_CMND_SIMPLE_LINK_START to CC3000». It then does a blocking wait for the response in SimpleLinkWaitEvent. Also, since hci_event_handler must have some response to terminate, a faulty CC3000MOD will cause the entire application to hang.

Aside 1: some Adafruit points

Adafruit done that with the TI CC3000MOD module

The Adafruit company in New York is very good on documentation. Even if their HUZZAH CC3000 WiFi Shield [10] has been discontinued (before Sept2017), there is lots of documentation and code there. (Update: but there is a newer HUZZAH board, see here.)

As we saw above the Adafruit protocol talking with that module over SPI is the same as talking with the LSR Research TiWi-SL module on the XMOS WiFi sliceCARD since the latter runs the same protocol (Texas Instrument SimpleLink™ Wi-Fi® CC3000) on board their built-in ARM. Files hci.h (TI, Adafruit) and hci_defines.h (XMOS) have the same code base.

Below is the highlight from [10]. Of course, the CC3000 on the Adafruit board may be newer and thus implement more:

The CC3000 hits that sweet spot of usability, price and capability. It uses SPI for communication (not UART!) so you can push data as fast as you want or as slow as you want. It has a proper interrupt system with IRQ pin so you can have asynchronous connections. It supports 802.11b/g, open/WEP/WPA/WPA2 security, TKIP & AES. A built in TCP/IP stack with a «BSD socket» interface. TCP and UDP in both client and server mode, up to 4 concurrent sockets. It does not support «AP» mode, it can connect to an access point but it cannot be an access point.

Notes 4: XTAG3 LEDs

[7] tries to explain where the LEDs are positioned on the XTAG3 (XTAG-3) but since I didn’t understand it I made my own from it. (Press picture for a PDF, also to print tabs to tape beside it):

Fig.12 – XTAG-3 LED layout (Disclaimer: only checked by me) (Press for PDF, also to print out tabs)

The text about each LED is of course XMOS’, so you have to read [7]. It says that the LEDs function is «clockwise, starting from the power button on the bottom right» that I didn’t grasp. That power button probably is SW1. It’s not mounted and it’s not at the bottom right.

I started clockwise from the one and only LED that lit when I powered the XTAG3. It is D7 in the print. So the «first» is D7 (Power). Clockwise from it we have in the print D2 (Run), D3 (Status), D1 (Target), D4 (xSCOPE) and D8 (JTAG).  When I ran the debugger the behaviour did make sense. But I need a disclaimer: don’t send it to Mars based on this.

Notes 5: WiFi sliceCARD with TI CC3000  is doomed

Epitaph

You will see from this note that I have been too tempted by a stuttering WiFi sliceCARD and alas been unfaithful. After having got the Atmel/Microchip ATWINC1500-based module up and working fluently with the Arduino IDE, and ARM based board and the WiFi101 library (in note 154: My Piggyback WiFi1500 sliceCARD) I retested the this WiFi sliceCARD TI CC3000 based module. The truth is that it’s doomed. (Disclaimer: at least I haven’t succeeded with it. But then I haven’t dived deep into the XMOS demo code. Some of the problems might be be hidden there)

Here is a log with very strong signal level, probably around -40 dBA. It does hiccups all the time. And finally it just stops. Compare that to the ATWINC1500-based module that I, with strong signal at least, never have seen fail.

Hello World internal log (4)

[459 ms] **WELCOME TO THE SIMPLE WEBSERVER DEMO**
[514 ms] Switching on Wi-Fi module.... 
[2837 ms] Connecting to OM11-kontor
(9816 ms) not httpd_handle_event 9 XTCP_IFUP new ip address
[9816 ms] #### #### IP Address:  192.168.1.12

(18819 ms) httpd_handle_event 0 XTCP_NEW_CONNECTION
(18849 ms) httpd_handle_event 1 XTCP_RECV_DATA
(18900 ms) GET "Hello World! 1" // COMMENT: SESSION 1: SEEN IN BROWSER: "Hello World! 1"

(19112 ms) httpd_handle_event 2 XTCP_REQUEST_DATA
(19162 ms) httpd_handle_event 3 XTCP_SENT_DATA
(21034 ms) #### #### Unsolicited event 4

(22034 ms) httpd_handle_event 7 XTCP_CLOSED

(22072 ms) httpd_handle_event 0 XTCP_NEW_CONNECTION
(22141 ms) httpd_handle_event 1 XTCP_RECV_DATA
(22194 ms) GET "Hello World! 2" // COMMENT: SESSION 1: NOT SEEN IN BROWSER

(22255 ms) httpd_handle_event 2 XTCP_REQUEST_DATA
(22303 ms) httpd_handle_event 3 XTCP_SENT_DATA
(23357 ms) #### #### Unsolicited event 4

(24036 ms) httpd_handle_event 7 XTCP_CLOSED

(22167 ms) httpd_handle_event 0 XTCP_NEW_CONNECTION
(22218 ms) httpd_handle_event 1 XTCP_RECV_DATA
(22269 ms) GET "Hello World! 3" // COMMENT: SESSION 2: SEEN IN BROWSER: "Hello World! 3"

(22407 ms) httpd_handle_event 2 XTCP_REQUEST_DATA
(22449 ms) httpd_handle_event 3 XTCP_SENT_DATA
(23502 ms) #### #### Unsolicited event 4

(23700 ms) httpd_handle_event 7 XTCP_CLOSED

(23758 ms) httpd_handle_event 0 XTCP_NEW_CONNECTION
(23810 ms) httpd_handle_event 1 XTCP_RECV_DATA
(23862 ms) GET "Hello World! 4" // COMMENT: SESSION 2: NOT SEEN IN BROWSER

(24207 ms) httpd_handle_event 2 XTCP_REQUEST_DATA
(24263 ms) httpd_handle_event 3 XTCP_SENT_DATA
(25318 ms) #### #### Unsolicited event 4

(25699 ms) httpd_handle_event 7 XTCP_CLOSED

(4384 ms) httpd_handle_event 0 XTCP_NEW_CONNECTION
(4413 ms) httpd_handle_event 1 XTCP_RECV_DATA
(4465 ms) GET "Hello World! 5" // COMMENT: SESSION 3: SEEN IN BROWSER: "Hello World! 5"

(4652 ms) httpd_handle_event 2 XTCP_REQUEST_DATA
(4679 ms) httpd_handle_event 3 XTCP_SENT_DATA
(5737 ms) #### #### Unsolicited event 4

(6070 ms) httpd_handle_event 7 XTCP_CLOSED

(6126 ms) httpd_handle_event 0 XTCP_NEW_CONNECTION
(6177 ms) httpd_handle_event 1 XTCP_RECV_DATA
(6228 ms) GET "Hello World! 6" // COMMENT: SESSION 3: NOT SEEN IN BROWSER

(6287 ms) httpd_handle_event 2 XTCP_REQUEST_DATA
(6335 ms) httpd_handle_event 3 XTCP_SENT_DATA
(7389 ms) #### #### Unsolicited event 4

(8069 ms) httpd_handle_event 7 XTCP_CLOSED

// COMMENT: After this I pressed the browser's update button several times somewhat fast and then it just hung. Like it always has. Goodbye WiFi sliceCARD!

Still crazy, after all these years

But I am not giving up on XMOS and WiFi. Rather the opposite. What I will do next I have described in note 151 chapter Conclusion at My single-board boards and why notes

Notes 6: Alternatives

In these IoT times there would be many alternatives. Standard disclaimer!

Atmel/Microchip ATWINC1500 module

Adafruit now has two products (Arduino WiFi Shield 101 and ATWINC1500 WiFi Breakout) that contains the Atmel/Microchip module ATWINC1500. (ATWINC1500-MR210PB has PCB antenna (here) and ATWINC1500-MR210UB has U.FL connector for external antenna, Adafruit sell both). Adafruit says that it has «SSL support, soft-AP capability, and is more reliable.». This may mean that the CC3000 isn’t that reliable? The Shield 101 also contains an Atmel/Microchip CryptoAuthentication chip type ATECC508. However, I see Adafruit points to Arduino’s page for the  Arduino WiFi Shield 101 product (code: ASX00001) where it says RETIRED.

I queried about this at the Adafruit forum at ARDUINO WIFI 101 SHIELD RETIRED? AND WHAT NOW? Here is the main response from an Adafruit person:

the atwinc modules do not have any EOL info, so we dont know anything. however, they seem to be readily available so we have no plans to discontinue our boards!
the cc3000 modules were essentially discontinued by TI many years ago, with slow but steady ‘refusal to fix bugs or respond to support requests’ so we discontinued them. the atwinc work much better and cost less, anyhow 🙂

Hands on the Adafruit ATWINC1500 board for eXplorerKIT or startKIT?

I bought two of them. I could connect it to the xCORE-200 eXplorerKIT by not using the 36 pins PCIe connector, but any other connector which is unused in that world right now. But if I later were to put it into my aquarium controller then I would have to have a sliceCARDbreadboard since I would have to use the PCIe there. Most other pins are used. So I queried about this at the xCORE Exchange: Any «sliceCARDbreadboard» out there?. Yes, there was! I bought four from Axxon in Canada (two LF1037KB and two LF1036KB XMOS Slice Breakout Card LF1037KB).

I have taken this into a new blog note: My single-board boards and why notes

Adafruit does a Cloud thermometer server

Another nice thing Adafruit shows is a Cloud thermometer that from the embedded board only uses very little code (even if the signing process requires multiple SHA-256 hash computations) to refer to Javascript that’s handled by Amazon DynamoDB, entered by the AWS browser javascript SDK [11]. Could this be somewhat related to how Netatmo can take over data for me?

TI CC3200 IoT WiFi has theirs and yours in one chip

I just jot this down here because TI seems to be on a leading edge. There is the CC3200 SimpleLink™ Wi-Fi® and Internet-of-Things solution, a Single-Chip Wireless MCU [12]. It’s active now (Sept2017) and probably very interesting. It’s a wireless MCU (microcontroller unit) that doesn’t need an extra processor, where the CC3000 did need one such external MCU.

I guess this would be only so and so interesting for me, since I’m not after making super-simple IoT boxes for the world. I would say I want the extra processor! It’s a tool to learn by and have fun by. I am a computer scientist not a gadget inventor. Ref the red text above (where Texas Instruments isn’t mentioned, that’s why this chapter is here).

ESP8266 processor from Espressif

This module is at http://espressif.com/en/products/hardware/esp8266ex/overview where they write «Low-power, highly-integrated Wi-Fi solution. A minimum of 7 external components. Wide temperature range: -40°C to +125°C. ESP8285 — 8 Mbit flash embedded.» It has an ARM/SAM ARDUINO core.

Adafruit has a breakout board with this WiFi module, the Adafruit HUZZAH ESP8266 Breakout. It’s at https://www.adafruit.com/product/2471. It comes with the Lua interpreter from NodeMCU that looks rather nice. Therefore the board can be controlled directly from a serial console like CoolTerm or Putty. I like it, perhaps especially for my use (I am here to learn XC mostly, not so much IoT (meaning I like IoT at a high functional level like these modules have come to)) – even if Adafruit says that the ARDUINO IDE «is the best and most-tested programming interface».

The Lua scripting language is cross-platform, so I assume that it has been put on several other WiFi modules. This smells like a portable platform?

MikroElectronica does ESP8266 and CC3100 based WiFi modules

In the Any «sliceCARDbreadboard» out there? url just above here, some other modules are mentioned by one respondant:  (The Espressif) «ESP8266 or the more current ESP32″. ESP32 contains both LoRa, Wifi and Bluetooth Low Enery (BLE). I reply that I have already chosen, first XMOS WiFi sliceCARD, then Adafruit’s ATWINC1500. I want to do XC on XCORE basically, not just any IoT device! (The ESP32-C from 2020 runs on the RISC-V instruction set, here – just like the new XMOS X4 processor, announced in Dec2022, also runs on the RISC-V instruction set.)

But since I also follow MikroElectronika in Belgrade some, I see that they also sell such modules, as well as a board based on TI’s modules

• WiFi ESP click – » WiFi ESP click carries the ESP-WROOM-02 module that integrates ESP8266EX»
• CC3100 click
  • MikroElectronika also have a CC3100 vs CC3000 comparison chart
• By the way, Adafruit also has a breakout board with Espressif ESP32. It’s Pycom LoPy 1.0 – LoRa + WiFi + BLE

Embedded Webserver Library

See #lib_webserver_ref (above).

References

Wikipedia: falsifiability, Gprof,  ISP (Internet Service Provider), SHA-1 (Secure Hash Algorithm 1, also including SHA-256),  SPI (Serial Peripheral Interface Bus), TCP (Transmission Control Protocol), U.FL RF connector, WAN (Wide Area Network), Wi-Fi (WiFi)

1. xCORE-200 eXplorerKIT, see https://www.xmos.com/support/boards?product=18230. Part: XK-EVK-XE216. Silicon on Board: XE216-512-TQ128, xCORE-200 XE/XEF: GIGABIT ETHERNET, see http://www.xmos.com/products/silicon/xcore-200/xe-series
2. xCORE-200 explorerKIT Hardware Manual, (XM007647C) 2015/10/20, see https://www.xmos.com/download/private/xCORE-200-explorerKIT-Hardware-Manual%281.2%29.pdf
3. WiFi sliceCARD by XMOS, see https://www.xmos.com/support/boards?product=15833
4. Types of Wireless Networks, see https://commotionwireless.net/docs/cck/networking/types-of-wireless-networks/
5. xTIMEcomposer User Guide, see http://www.xmos.com/published/tools-user-guide
6. XMOS Application Note: AN10124: How to profile an executable on hardware, see https://en.wikipedia.org/wiki/Gprof
7. xTAG v3.0 Hardware Manual, XMOS 2015. It’s called XTAG3 or XTAG-3. It contains an XS1-U8, see https://www.xmos.com/support/boards?product=19480
8. TiWi-SL Self-contained 802.11 b/g WLAN module, see https://www.lsr.com/embedded-wireless-modules/wifi-module/tiwi-sl that contains lots of documentation. Like:
   (1) Product Brief:
   TiWi-SLTM 802.11 b/g Wi-Fi® Module with Application Processor, see https://www.lsr.com/downloads/products/337-0004.pdf. It states that:
   «TiWi-SL is the industry’s first industrial temp-rated 802.11 b/g Wi-Fi module. It has been designed for simple connectivity to the industry’s most popular microcontroller platforms. It utilizes Texas Instruments’ CC3000 SimpleLinkTM technology to move nearly all the functions required for Wi-Fi off the host processor and onto the module.»
   (2) Datasheet:
   TiWi-SL MODULE DATASHEET Integrated 802.11 b/g WLAN Module, see https://www.lsr.com/downloads/products/330-0085.pdf. It points to [9] and it mentions HCI (Host Controller Interface)
   (3) EM BOARD User Guide
   TIWI-SL EM BOARD User Guide
   https://www.lsr.com/downloads/products/330-0086.pdf where they show that «Texas Instruments has developed Wireless LAN software examples that run on the MSP-EXP430FR5739 Experimenter Board. Further specifics on the examples can be found on the Connectivity wiki at …» first link below.
   (4) Getting Started with TiWi-SL
   It points to [9]
9. Texas Instrument’s data base of CC3000 Software
   The problem is that in Sept2017 the Texas Instruments (TI) documents that LS Research (LSR) refers to in their page and documents (above) have been removed and replaced with newer versions: 
   (1) Documents removed by TI
   Getting Started with TiWi-SL. The TI CC3000 Wiki contains a wealth of information to quickly start developing applications with TiWi-SL. Information on supported hardware platforms and example software can be found there. Even if it’s removed, see http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_for_MCU
   (2) Active documents by TI
   Texas Instrument SimpleLink™ Wi-Fi® CC3000 Software, see http://www.ti.com/tool/CC3000-SW?keyMatch=CC3000&tisearch=Search-EN.
   (3) C code library
   CC3000-PLATFORMDRIVER: CC3000 Platform Independent Wi-Fi Driver, ACTIVE 1.11.1 29-OCT-2013, see http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=swrc263&fileType=zip
10. Adafruit HUZZAH CC3000 WiFi Shield with Onboard Antenna, see https://www.adafruit.com/product/1491
11. Adafruit Cloud thermometer, see https://learn.adafruit.com/cloud-thermometer
12. Texas Instruments: CC3200 SimpleLink™ Wi-Fi® and Internet-of-Things solution, a Single-Chip Wireless MCU, see http://www.ti.com/product/cc3200