My Piggyback WiFi1500 sliceCARD

Started 6Oct2017. Udated 10Aug2018

This page is in group Technology (plus My XMOS pages) and is a blog note where I will try to describe a WiFi card (that I call PiggyBack WiFi1500 sliceCARD) that is meant to replace another WiFi board (XMOS WiFi sliceCARD) and be a pin plug-in replacement, meant for the two XMOS boards startKIT and xCORE-200 eXplorerKIT. But I will start with its almost native platform, the Adafruit Feather ARM M0 basic proto board, a variant of the Arduino Zero.

It’s really a technology move from building on the Texas Instrument’s TI CC3000 IoT platform (that the XMOS WiFi sliceCARD does) to building on the Atmel/Microchip ATWINC1500 platform (that the Adafruit ATWINC1500 WiFi Breakout board does).

I will also try to show the process of porting the SW to the multi-core processors on those boards. It would include the standard web server.

Disclaimer

Standard disclaimer, this is just for fun. No money, gifts, ads etc. Also, my non-association with any of the manufacturers and vendors mentioned here.

Fold handling

This blog note uses the Collapse-O-Matic WordPress plugin to handle text folding. In addition to expanding and closing them individually you may here:

Expand All
Collapse All

Intro

Blog notes leading up to this are newest to oldest: My single-board boards and why notesMy xCORE-200 eXplorerKIT notes (WiFi) and My XMOS notes. I have repeated these links more in the correct context below.

Piggyback WiFi1500 sliceCARD used on three boards

Fig.1 Overview of Adafruit ATWINC1500 WiFi breakout on Adafruit Feather M0 basic proto and XMOS startKIT and xCORE-200 eXplorerKIT (press for more pixels)

The picture (above) shows how I have now made it ready to try to port the WiFi software using the Adafruit ATWINC1500 WiFi Breakout on three different boards. I have described how I have landed on these three boards in note My single-board boards and why notes. I also have shown the background for why I’m now trying WiFi board in note My xCORE-200 eXplorerKIT notes (WiFi).

(Aside: I only have two WiFi boards. A camera stand, two shots with one of the WiFi boards moved around, plus the Adobe Photoshop Elements clone function was all I needed to make the picture above look real!)

Adafruit ATWINC1500 WiFi Breakout connected to an Adafruit Feather M0 basic proto

Fig.2 Adafruit ATWINC1500 WiFi Breakout connected to an Adafruit Feather M0 basic proto (press for more pixels)

The Adafruit Feather ARM Cortex-M0+ Basic Proto board (here) I have described somewhat in note My single-board boards and why notes. Also the Adafruit ATWINC1500 WiFi Breakout board (here). Aside: If you are interested in how I went on and did the set up for the radio board instead of the WiFi (and not even BLE), then have a look at Fig. 2 of My aquarium’s data radioed through the shelf.

Installing the Arduino IDE and the Adafruit Feather M0

  1. I downloaded the Arduino IDE as described in Arduino IDE Setup
    • It had version 1.8.5 for me (11Oct2017)
    • By the way, I have OS X (10.11.16 El Capitan) (->macOS)
    • It seems to accept Java Runtime Environment JRE 1.8 1.8.0_144. After I installed it I ran the XMOS xTIMEcomposer, that didn’t complain about it either. It shouldn’t since that JRE didn’t come with the Arduino IDE
    • To get the below to work I had to remove any proxy setting: | Arduino |Preferences | Network | No Proxy |
  2. Setup with Adafruit Feather M0 Basic Proto is as described on the same. Then from the list of things to do, here are the results. First these two(?) board support packages:
    • Arduino SAMD Boards (32-bits ARM Cortex-M0+) by Arduino version 1.6.16 INSTALLED
      • Will this also install the SPI built-in library, or…
    • Adafruit SAMD Boards by Adafruit version 1.0.19 INSTALLED
      • …will this install the SPI built-in library?
    • Board Info
      BN: Adafruit Feather M0
      VID: 239A
      PID: 800B
      SN: (null)
    • Port: “/dev/cu.usbmodem1431 (Adafruit Feather M0)”
  3. Then I ran the blink code and it blinks! The Adafruit tutorial also was piece if cake! The code that is preprogrammed soft-blinks the LED, and this code hard-blinks it. So it’s easy to spot the difference. Observe that the LED positioned to the right of the USB connector on the picture above is connected to digital pin 13 as output. So it was probably smart not to use it for the WiFi board
    • The upload log starts like this:
      Atmel SMART device 0x10010005 found
      Device : ATSAMD21G18A
      Chip ID : 10010005
      Version : v2.0 [Arduino:XYZ] Mar 5 2016 17:46:52

Measuring with my PicoScope

I did som scoping on pin 13 LED output and the suggested pulse code. I tried the <delay(ms); call ms down to the shortest 1 ms and scoped on it with my new USB PicoScope. Disclaimer, again, I mention so much products here, but I still don’t get paid for it, no gift, no nothing!

  • I did need to solder some test pins to connect the scope to, also for the WiFi pins. So the picture of the setup isn’t as clean as seen above any more.
  • Some rather private exercises about timing
    • It was quite regular, measuring “high pulse width between rulers” with 20% low and 80% high levels of min 999.6 μs and max 1000.0 μs, and average of  1000.0 μs (?) with capture count of 20. But then, this processor doesn’t have much else to do. It’s not interrupt driven, which would have helped, it only runs a loop in main, so it does burn cycles for the loop code. The XMOS multi-core processors may guarantee deterministic timing as early as at compile time, with any run-time load. This is one of the properties that makes them interesting to me. But I am also eager to see ARMs solution to this
    • A pulse high/on for 200 ms and low/off for 800 ms yields average cycle time of 998 ms. Two ms for the main loop code doesn’t make sense to me, since the 1 ms delays were so ok. Of course, the triggering of the scope counts here, but this is per cycle and I wouldn’t think a repeated pattern would introduce that much. And no printf. Hmm
    • After this I tested bootloader mode. I clicked the RST button twice (as described) and the red LED, pin 13 started to soft blink with a PWM (Pulse Width Modulated) signal. It’s nice to view on the scope. The period is 4.524 ms and the thinnest pulse is some μs (but it’s never gone) and the longest is about 1.1 ms. If I trigger on pulse width then 1.119 ms won’t trigger, but 1.072 ms will. I took it out of bootloader mode simply by unplugging the USB cable, and the 200/800 ms pulsing reappeared when I plugged it in again.

SimpleWebServerWifi

I run “my” SimpleWebServerWifi_Teig that does its WiFi.setPins as described below.

I see that a session, setting the LED on or off, is started by IRQ going low. This starts a session that lasts about 2.3 ms. The IRQ line returns high long before this, after som 140 μs.

This SW is different from the XMOS server that polls the wifi module and doesn’t use the IRQ.

Software for ATWINC1500 and pinning with the Feather M0

I will take this from the Adafruit tutorial here.

  • WiFi101 by Arduino Version 0.14.4 INSTALLED. It is described on the Arduino site here.
    • The 101 term I think stems from the Arduino101 (also called Genuino101) (UNO’s successor) board that’s based on an Intel Curie wearable processor that’s built on the Quark (see Wikipedia Intel Quark). The WiFi board that’s pluggable on it is called Arduino WiFi Shield 101 (here) and it’s not much different from the Adafruit ATWINC1500 WiFi Breakout. They both contain the ATWINC1500 module. So that’s why I have ended up using the WiFi101
  • SPI Built-In by Jonathan BAUDIN, Thibaut VIARD, Arduino Version 1.0.0 INSTALLED
    Enables the communication with devices that use Serial Peripheral Interface (SPI) Bus. Specific implementation for Arduino Zero
    I don’t know when this built-in was loaded. Probably with one of the board support packages?
  • I have used other pins
    • In the recipe they say that since they have also connected differently than the library has, then one should add
      WiFi.setPins(8,7,4); for (CS,IRQ,RST)
      to the start of the code.  So I would need to go
      WiFi.setPins(10,6,5); for (CS,IRQ,RST) – NO!..
    • ..because I discovered that the code in library WiFi101 had this definition:
      void setPins(int8_t cs, int8_t irq, int8_t rst, int8_t en = -1); in WiFi101.h
      and I had connected EN to pin 9, then I needed to supply that optional parameter:
      WiFi.setPins(10,6,5,9); for (CS,IRQ,RST,EN)
      and it worked! (This was after I had inserted a 27 Ohm resistor in the SCK line (see below), but I don’t think that did any difference) I got the following response in the Serial Monitor:
WiFi101 firmware check.

WiFi101 shield: DETECTED
Firmware version installed: 19.4.4
Latest firmware version available : 19.5.2

Check result: NOT PASSED
 - The firmware version on the shield do not match the
   version required by the library, you may experience
   issues or failures.
  • The standard SPI pins are (13,12,11) for (SCK,MISO,MOSI)
    I use (SCK,MISO,MOSI) as named on the Adafruit Feather M0 module

Below is a scratch pad I am working on to nest on pin usage. The circuit diagram of the Adafruit Feather M0 is here. There is more on these pins at Arduino here. I need to connect them physically and in the code.

SPI (SCK,MISO,MOSI)

I will not need to do anything in the SPI built-in library for the Zero, since the Adafruit named pins all correspond:

====  ADAFRUIT FEATHER M0 (ITS PINS) (SCK,MISO,MOSI) FOR (SCK,MISO,MOSI)               SCK  JP1.6 ATSAMD21G18_QFN.PIN.20 SCK  PB11/I11/SERCOM4.3/I2SC?         
MISO JP1.4 ATSAMD21G18_QFN.PIN.21 MISO PA12/I12/SERCOM2+4.0             
MOSI JP1.5 ATSAMD21G18_QFN.PIN.19 MOSI PB10/I10/SERCOM4.2/I2SM?
---- ARDUINO ZERO (ICSP-3,ICSP-1,ICSP-4) FOR (SCK,MISO,MOSI) (SPI lib here)      
The Arduino Zero diagram is here. We see that it corresponds to the above (red);
SCK  ICSP.PIN.3 PB11_S4_SPI_SCK  SAMD21G18A-AUT.PIN.20 SCK  PB11/EIC/SCOM4PAD3/TC5
MISO ICSP.PIN.1 PB12_S4_SPI_MISO SAMD21G18A-AUT.PIN.21 MISO PA12/I2C/EIC/SCOM2PAD0+/TC2
MOSI ICSP.PIN.4 PB10_S4_SPI_MOSI SAMD21G18A-AUT.PIN.19 MOSI PB10/EIC/SCOM4PAD2/TC5
ASIDE:
---- ARDUINO UNO (not ARM but ATMEGA, here) (13,12,11) for (SCK,MISO,MOSI)
SCK  IOL.PIN.6 ICSP.PIN.3 ATMEGA328P-PU.PIN.19 D13 (SCK)PB5
MISO IOL.PIN.5 ICSP.PIN.1 ATMEGA328P-PU.PIN.18 D12 (MISO)PB4
MOSI IOL.PIN.3 ICSP.PIN.4 ATMEGA328P-PU.PIN.17 D11 (MOSI)PB3

SPI (CS,IRQ,RST)

Here I only should need to change the pinning with WiFi.setPins:

==== ADAFRUIT FEATHER M0 (MY PINS) WiFi.setPins(10,6,5); for (CS,IRQ,RST)  
CS   JP3.7  ATSAMD21G18_QFN.PIN.27 D10 PA18/I2 /SERCOM1+3.1        
IRQ  JP3.9  ATSAMD21G18_QFN.PIN.29 D6  PA20/I4 /SERCOM3+5.2/I2SSC  
RST  JP3.10 ATSAMD21G18_QFN.PIN.24 D5  PA15/I15/SERCOM3+4.3        
ASIDE:
---- ARDUINO UNO (ADAFRUITs PINS, here) WiFi.setPins(8,7,4); for (CS,IRQ,RST) 
None of these (8,7,4) pins are available on the ADAFRUIT FEATHER M0, 
that's why I have (MY PINS) above

Running the SW

CheckWifi101FirmwareVersion_Teig

  1. I can see on my PicoScope that SCK runs at 12 MHz, which makes sense since static const SPISettings wifi_SPISettings takes 12000000L as its first value, in file nm_bus_wrapper_samd21.cpp in the WiFi101 library code. There is a lot of ringing on my 83 ns pulses, but they should be ok. I did try to add a 27 Ohm serial resistor on SCK, and the ringing was reduced from 0.9 V to the half. But so far without any change in behaviour

Updating ATWINC1500 with WiFi101 Firmware/Certificates Updater

Since I got firmware 19.4.4 and the newest is 19.5.2 (above) I need to download and update the firmware. Adafruit has the recipe here. And Arduino has a recipe here. Microchip (formerly Atmel) has all about the ATWINC1500 here. In the Arduino IDE top menu it’s called WiFi101 Firmware Updater, but in the updater’s window they have added the certificates update in the heading.

In the drop-dwon box of the Updater I get these choices (below). I have failed to find out what WINC1501 is. I see no trace of it on the net:

  • WINC1501 Model B (19.5.2)
  • WINC1501 Model B (19.4.4)
  • WINC1501 Model A (19.4.4)
  1. I had to update with WiFi.setPins(10,6,5,9); for (CS,IRQ,RST,EN) again
  2. I Save As and call it FirmwareUpdater_Teig. And compile and run it on the target. I went straight to the Firmware Updater at first, and got proper error messages when I tried what the recipe said
  3. My USB port is /dev/cu.usbmodem1431 as shown earlier
  4. I did “Test connection” and “The programmer is working!”
  5. I select Firmware WINC1501 Model B (19.5.2). 416604 bytes programmed. “The firmware has been updated!” I exit the FirmwareUpdater and ran the test program and got this response:
    WiFi101 firmware check.WiFi101 shield: DETECTED
    Firmware version installed: 19.5.2
    Latest firmware version available : 19.5.2
    
    Check result: PASSED
  6. I have not updated the SSL certificates of the WINC1500 yet (here).

Now, I’ve already come much further than with the XMOS WiFi sliceCARD that was based on the TI CC3000MOD module that Texas hasn’t updated. And had they done so, XMOS (via TI I presume) wouldn’t have supplied me with any Firmware Updater client like this. (But then, the Updater is part of the WiFi101 library with a small GUI, so it would have come with an extensive enough library.) I have discussed some of this in the notes mentioned at the top. This really was the main reason to go for the ATWINC1500!

WiFi101 Firmware Updater says not latest version

Not newest anyhow? I see there that the latest version is 19.5.3 (here), probably it indicates that the client doesn’t check this by asking a server. Clinically observed it’s compiled in. Yes it is, in file WiFi101.h there is a define #define WIFI_FIRMWARE_LATEST_MODEL_B "19.5.2".  At the Adafruit recipe they say that “If you don’t see the right/matching version you may need to update the IDE”. Sound strange to me. And I don’t know what happens if I replace the #define with “19.5.3”. And don’t even know if the IDE will allow me to build with a (allowed or not) recompiled library. And I want to be sure that I don’t do anything with the firmware that will not take me back again. It depends on the bootloader in the ATWINC1500.

I queried about this at the Arduino Forum at WiFi101 Firmware Updater says not latest version. And then pointed to that one from the Adafruit Forum here.

The Arduino WiFi101 page (here) also states what I have done, but it still fails to give me 19.5.3:

This library requires that your board or shield has a matching firmware installed. When the library is updated, also the firmware might be updated, but it is not mandatory. To avoid any issue and ensure that you have the most up to date setup, we suggest that you check your WiFi101 library with the Arduino Software (IDE) Library Manager. There is an option in the Preferences that enables the check for updates of any of the installed libraries at startup.

The solution may be as simple as the fact that (as seen in the WiFi101 CHANGELOG) WiFi101 0.14.0 – 2017.03.22 added support for firmware 19.5.2, but up until the the newest WiFi101 0.14.3 – 2017.06.01 there is nothing mentioned about support for 19.5.3. Do I then just lean back and wait until un update message arrives and do what I’m told?

Update 17Oct2017: Now, with the KRACK or Key Reinstallation Attack (here) probably leaving the WPA2 implementation also here in need of mending, there probably should be a 19.5.4 or even 20.0.0? But then, this is the client side, I don’t know if the KRACK problem applies here?

Web servers

I do get web servers up and running! And do get to switch the LED (which is at pin 13 on this board, not 9) by pressing the correct html. It’s not 100% fluent yet. The reason seems to have been the signal level:

Signal level was too weak with router downstairs

I bought the Adafruit ATWINC1500 WiFi Breakout with on-board (not external) antenna. When I tested the web server the browser hung more than I liked. Messages were lost. I used (1. below) only. I saw that the signal strength ranged from -78 dBm to -67 dBm if I moved the unit up 15 cm. (dBm or decibel-milliwatts (here) is 10 times more watt per 10 dBm. Since it’s negative, the less negative the better signal). When I raise it it seemed to work better with the SimpleWebServerWiFi_Teig. (My XMOS sliceCARD must have been subject to the same limitations, but I don’t know how it saw the signal level. But I did test it right now, good signal level doesn’t help it. TI’s CC3000 is doomed.) The router I used (1. below) was simply too far away.

Here is a summary of my strengths running SimpleWebServerWiFi_Teig of three different wifi networks that I made for this test. I’ll keep them all on:

  1. DOWNSTAIRS: Apple Time Capsule, connected to the WAN/internet (network:DHCP/NAT, internet:DHCP)
    This router is  -78 dBm to -67 dBm but is on the floor below. It fails setting the LED off and on, loses messages
  2. ON MY DESK: Apple Airport Express (see below) (network:bridge mode, internet:DHCP)
    This router gives -41 dBm. It switches LED off and on without problems. See “SimpleWebServerWiFi_Teig log” below
  3. NEXT ROOM: Apple Airport Extreme 802.11n (network:bridge mode, internet:DHCP)
    It’s also got low level, -76 dBm, but when I switch the LED off and on and compare the logs they are equal

Conclusion: it’s probably not only the signal level, but reflections and other signal transmission properties (like where ground is) that sets the number of retransmissions etc. So, Quality of service (QoS) is more than dBm.

A new Apple Airport Express WiFi router on my desk

Since this started with units (1.) and (3.) above, but only a wifi network on (1.) I decided to get some more decibels. I went down to the shop and fetcthed an Apple Airport Express (standard disclaimer about my mentioning this).

But when I came home I discovered that I had forgotten that it wanted to be connected to a WAN. Had I studied this I wouldn’t have bought it, but then I wouldn’t have known that it turned out to be a success in the end. I went through the set-up procedure without the WAN. But I did connect its ethernet connection on my local Zyxel Ethernet switch. It told me it wasn’t connected to the internet and I did “Ignore” (ti get amber constant LED) of these three error messages (translated from Norwegian):

  1. Ethernet not connected – Strange text. Nothing connected to the WAN-port.
  2. Internet connection missing – saying that it had no IP address . But it did have a LAN IP address! Great!
  3. No DNS-servers – I think this means that I only can use it in the browser by IP address, since it is known all over the local network

When this was done I created a wireless network on it and did the “network” and “internet” settings so that they would all make sense together. See table above, red textThis causes the Airport Express to be connected to the internet even without the WAN port. This at least works for my internet provider (Canal Digital in Norway), but I hear that these days that many of them don’t allow private wifi networks, routers and DHCP (like GET in Norway). (Standard disclaimer).

SimpleWebServerWiFi_Teig log with high signal level

I run on network (2.) above, the new one where the Airport Express is 15 cm away from the Adafruit ATWINC1500 WiFi Breakout. This is visible in the browser:

Click here turn the LED on
Click here turn the LED off

The LED is on at the start, so it starts with http://192.168.1.15/L to switch it off. The rest should be known by WiFi101-fluent people.

I have marked some interesting lines or text bold. I have also coloured some lines blue: SimpleWebServerWiFi_Teig.ino contains loop(). It starts by printing “new client” (when new connection seen) and ends by printing”client disconnected”, but in between characters are read from the WiFi module (if the lower software layer doesn’t add anything of it) and all of that is printed by Serial.write(c); // print it out the serial monitor. Function printWiFiStatus does the initial status print, coloured in green.

I wil have to find out why the “Referer:” line seems to be printing the previous message, not the actual.

SSID: OM11-kontor-ikke-internet
IP Address: 192.168.1.15
signal strength (RSSI):-41 dBm
To see this page in action, open a browser to http://192.168.1.15

new client

GET /favicon.ico HTTP/1.1
Host: 192.168.1.15
Connection: keep-alive
Accept: */*
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38
Accept-Language: nb-no
Referer: http://192.168.1.15/
Accept-Encoding: gzip, deflate

client disonnected new client

GET / HTTP/1.1
Host: 192.168.1.15
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38
Accept-Language: nb-no
Accept-Encoding: gzip, deflate
Connection: keep-alive

client disonnected new client

GET /L HTTP/1.1
Host: 192.168.1.15
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38
Referer: http://192.168.1.15/
Accept-Language: nb-no
Accept-Encoding: gzip, deflate

client disonnected new client

GET /H HTTP/1.1
Host: 192.168.1.15
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38
Referer: http://192.168.1.15/L
Accept-Language: nb-no
Accept-Encoding: gzip, deflate

client disonnected new client

GET /L HTTP/1.1
Host: 192.168.1.15
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38
Referer: http://192.168.1.15/H
Accept-Language: nb-no
Accept-Encoding: gzip, deflate

client disonnected

Some comments about the Arduino IDE

It’s new to me. I run it on a Mac under OS X/macOS. It’s very different from the IAR and AVR IDEs I have mostly used over the previous 15 years. Fair enough!

  1. It’s splendidly built so that a starter should not need to fall off. However..
  2. The Board Manager (or “Manage Boards”) is nice. Very
  3. The Library Manager (or “Manage Libraries”) is also nice. Also very
  4. The button “Verify” writes “Compiling sketch…” and “Done compiling.”.
    • I am used to “verification” more as in “formal verification” (as I have done with Promela/Spin and CSPm/FDR, mentioned in lots of blog notes). Why they use “Verify” and actually introduce a somewhat erroneous usage of that term, computer science wise, I don’t understand
    • But in the menu of Sketch the entry is Verify/Compile. Better
  5. I am not allowed to open files from included libraries in the IDE. I tried this from Finder and “Open with” “Arduino.app”. Fair enough, that surely hides them well. And it’s easy to download them from some cloud.
  6. The “built-in” libraries load mystically by the board support packages I assume, like the SPI library. That one I can’t even find by inspecting the files outside of the Arduino IDE. I will query about this
  7. Switching from one USB port to the other doesn’t work out of the box. But you do get an error message (or the standard Java fault tree). Do “Tools | Port” and it will have the new port there. Select that one and it downloads again.
    • Aside: I moved the USB port from the back of my iMac that was “/dev/cu.usbmodem1431 (Adafruit Feather M0)” to the left port on my Apple numeric keyboard with two USB connectors (A1243) – and its address was now /dev/cu.usbmodem14411 (Adafruit Feather M0)”
  8. About concurrency, see My WiFi101 library port chapter Looping as fast as possible leaves no room for concurrency and following

Next step

I can only say that I started with Arduino to get the WiFi board up. It did, very nicely. Now I will see if I could port that SW to the xCORE-200 eXplorerKIT. It has CSP-based concurrency with channels and timers built in (like Go/Golang).

This is what I will start doing now. So, I’m going to start at point 3 in my My single-board boards and why note, chapter Conclusion and todo list. In other words, I’ll now be working on the below HW platform and pulling the WiFi101 along. See next chapter:

Adafruit ATWINC1500 WiFi Breakout connection board for J1 on XMOS xCORE-200 eXplorerKIT

Fig. 4 Adafruit ATWINC1500 WiFi Breakout connection board for J1 on XMOS xCORE-200 eXplorerKIT (press for more pixels)

The XMOS xCORE-200 eXplorerKIT I have also described somewhat in note My single-board boards and why notes. This board does not have a PCIe connector.

Adafruit ATWINC1500 WiFi Breakout piggybacked on a PCIe breakout card for XMOS startKIT

Fig. 3 Adafruit ATWINC1500 WiFi Breakout piggybacked on a PCIe breakout card for XMOS startKIT. Observe PRB (Probe pins) are only connected to A6 and A7, not CFG and RXD (press for more pixels)

This blog note takes the “piggyback” part of its title mostly from this embodiment of these three, more or less board on board boards…

The XMOS startKIT board I have also described somewhat in note My single-board boards and why notes. This board has a PCIe connector. And for my aquarium project many of the other I/O pins are used, and I have kept the PCIe not used. I did plan to use the XMOS WiFi sliceCARD, but this project is to try to see if I can replace it with the ATWINC1500-based board instead.

The PCIe male board is a XMOS Slice Breakout CARD LF1037KB from Axxon in Canada. It appeared in XCore Exchange post, Any “sliceCARDbreadboard” out there?. But I needed to cut it in two. And I made a via-board with wires, and screwed it to the board with nylon screws. I also insulated the rather long wires from RF field from the antenna with a grounded metallic shield. Made from a used colour pencil box.

Update Jan2018: I have now also plugged an Adafruit RFM69HCW Transceiver Radio Breakout 433 MHz RadioFruit, board onto this piggyback board, see My aquarium’s data radioed through the shelf chapter Radio on three boards.

Update Mar2018: I updated Fig. 3 (above) with PCIe bus A6 and A7 going to two probe (scope) points only (PRB_INNER and PRB_OUTER). The reason is that the [lib_spi] (that I have had to rewrite some (see, starting My aquarium’s data radioed through the shelf)) needs a CS (chip select) pin that, in the library is coded as a (an array of) 1-bit ports. On the startKIT these are not available on the PCIe, so I had to use a 4-bit port. Observe that a 4-bit port is not an array of a 1-bit port (discused here). I now use all four bits: CS, EN, PRB_INNER and PRB_OUTER, and they are mapped onto the XS1_PORT_4C port. Now this port is parameterised to the [lib_spi] and the spi driver can handle all these pins. Nice to get it to work (CS, EN) and nice for extra scoping (PRB*2).

Update Aug2018: My solution for the RFM68HCW is described at My aquarium&#8217;s data radioed through the shelf

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.