- 1 Disclaimer
- 2 Fold handling
- 3 3 What I already have done
- 4 4 Resources
- 5 Making the WiFi board pluggable on all my boards
- 6 Observation of the WiFi101 original code
- 7 Next chapter
- 8 References
Started 1Nov2017. Updated 2Nov2017. In work
This page is in group Technology and is a blog note where I will try to work myself through..
- ..having run the Arduino WiFi101 library on an Adafruit Feather ARM M0 basic proto board, a variant of the Arduino Zero using a WiFi board that contains the Atmel/Microchip ATWINC1500 module that sits on an Adafruit ATWINC1500 WiFi Breakout board, using the ARDUIONO IDE
- ..to having that software “more than just recompiled” for the XMOS XCORE boards like startKIT and xCORE-200 eXplorerKIT. The startKIT has 8 “logical threads” for built-in HW concurrency and the eXplorerKIT has two cores with 8 logical threads in each
- Since embedded concurrent SW is what I am used to, I will try to replace callbacks and objects with interface calls and real tasks, like the XC language makes possible. I will use the XMOS xTIMEcomposer IDE
- I will all the time have in mind the XMOS Wifi sliceCARD‘s drivers and example SW when I do this. But even that SW looks a like they haven’t used the full potential of the XCORE architecture; it looks like they have modified as little as possible of the SW of the obsoleted Texas Instruments TI CC3000 module. But they do use XC, so maybe I will change my mind on this when I get there
This blog note uses the Collapse-O-Matic WordPress plugin to handle text folding, as you may see in the “Limited selfrefs” chapter below. It’s used mostly for code examples. In addition to expanding and closing them individually you may here:
This fold is expanded.
Use “Expand All” (above) to make all folds expanded: visible, searchable and printable!
3 What I already have done
My goal is to have a small web server running on the box above. It contains a startKIT, controlling my aquarium. Fishes, a snail and a shrimp plus plants seem to be in good balance. I will blog about it later.[3.x]
- The long start that caused me to see the the TI CC3000 module has become obsoleted: My xCORE-200 eXplorerKIT notes (WiFi)
- Selecting the right solution for me (making things fun, not easy), the Microchip ATWINC1500 module, the ARM-based ARDUINO and then two XMOS boards: My single-board boards and why notes
- Making the Adafruit ATWINC1500 WiFi Breakout pluggable on all my boards: My Piggyback WiFi1500 sliceCARD
And now, this blog note: My WiFi101 library port
4 Resources[4.x] I have added the main contents as well:
- Microchip ATWINC1500 module
- Atmel ATWINC1500-MR210PB DATASHEET
- Microchip ATWINC15x0 Wi-Fi Network Controller Software Design Guide
Contents© 2017 Microchip Technology Inc, Application Note DS00002389A
1. Host Driver Architecture
2. ATWINC15x0 System Architecture
3. WINC Initialization and Simple Application 4. WINC Configuration
5. Wi-Fi Station Mode
6. WINC Socket Programming
7. Transport Layer Security (TLS)
8. Wi-Fi AP Mode
9. Wi-Fi Direct P2P Mode 10. Provisioning
11. Over-The-Air Upgrade
12. Multicast Sockets
13. WINC Serial Flash Memory
14. Wi-Fi Sniffer Mode
15. Host Interface (HIF) Protocol
16. WINC SPI Protocol
17. Appendix A. How to Generate Certificates
18. Appendix B. X.509 Certificate Format and Conversion
- Arduino WiFi101 library
- XMOS WiFi sliceCARD drivers and example. My blog note contains an overiew of what I needed: [3.1] chapter My xCORE-200 eXplorerKIT notes (WiFi) (Installing the drivers)
Making the WiFi board pluggable on all my boards
I did this in the previous blog note [3.3]. All three connections are described:
- Adafruit ATWINC1500 WiFi Breakout connected to:
- Adafruit Feather M0 basic proto
- J1 on XMOS xCORE-200 eXplorerKIT
- PCIe breakout card for XMOS startKIT
I also tested installed the Arduino IDE, downloaded the WiFi101 and compiled and ran examples on the Adafruit Feather M0 basic proto. It works!
Observation of the WiFi101 original code
- The code static const SPISettings wifi_SPISettings takes 12000000L (shown above) is not my way of coding. SPI speed should be set-able by the user. Using a numbered value for the speed, without #define for it isn’t much readable. Especially when there’s no comment either. #define SPI_CLK_SPEED_HZ 12000000L is how we also were required to do it at work
- When I have not got my wired setup to work then the CheckWifi101FirmwareVersion_Teig writes this the to Serial Monitor:
WiFi101 firmware check. WiFi101 shield:
This indicates to me that neither this code (nor the XMOS code shown in note 143) has any type of timeout when the HW goes wrong. I would have coded with some error return instead of a hang there. Waiting for some value definitively is no good idea
- When the web server hung so much when low signal levels (dBm) without a proper warning on the web server side (no log at all) it may be a sign that the error handling is so and so?
- In m2m_wifi.h it says that the “Firmware can be downloaded through a number of interfaces, UART, I2C and SPI.” However, in the ATWINC1500-MR210PB data sheet (here) it says that I2C.SDL and I2C.SCL are “Currently used only for Atmel debug. Not for cus- tomer use. Leave unconnected.”. So no wonder that I2C is mentioned only in m2m_wifi.h, there is no sign of any code
Looping as fast as possible leaves no room for concurrency
SimpleWebServerWiFi_Teig.ino contains loop(). It just loops. I made a counter (unsigned long) and printed out its value every one mill counts. It took about 56 seconds to count to 5 mill, so it’s about 11.2 μs to loop around just counting up that value. It runs as fast as it can.
This is bad architecture. Lucky for the demos that there are no background or foreground tasks that have own state. There is no task / process / thread here. It’s as single threaded as possibly possible.
Arduino Scheduler concurrency is low-level yield-based
Arduino supplies an “experimental” Scheduler (see https://www.arduino.cc/en/Reference/Scheduler) that’s “cooperative” (they don’t cooperate on data, just on passing of control). It’s based on starting an additional loop with Scheduler.startLoop(new_loop). Then new_loop must run a Scheduler.yield so that the original loop also will run. This is the lowest level of concurrency with no support for communication between them and no structured way to avoid busy poll.
Have a look at their blinking LED example (here). No no-skew timer. No communication between the loops. No communication into or out of the loops. Besides, all cycles are burned. And the cognitive understanding av what a task is probably isn’t easy to grasp in the light of how to next solve the missing points.
I will not do my whole story here. Almost all of my technical blog notes deal with concurrency. Just search for yield, generator, CSP, concurrency or blocking in the search window above, or visit the main Technology blog note list here and see if you find a thread to pull.
That being said, to me this Scheduler.yield may be a starting point for building a CSP-type Scheduler on top. This may be interesting in the future.