Me relying on relaying BLE?

Started 7Dec2017. Concluded 23Dec2017

This page is in group Technology (plus My XMOS pages) and is a blog note where I will discuss the route ahead. Should I do the My WiFi101 library port as I promised myself to try, or should I add a second box that I talk with over BLE (Bluetooth Low Energy)? Conclusion 23Dec2017: I did neither; I went for a simpler(?) radio solution, discussed in my next note My aquarium’s data radioed through the shelf. This note will still take you through the general architecture, much of it is also present in the radio solution.

Disclaimer

Standard disclaimer, this is just for fun. No money, gifts, ads etc. Also, my non-association with any of the companies mentioned here. Other than some times exchanging technical matters, mostly in open forums. I am basically positive until I may have experienced the opposite; this is reflected in all my blog notes.

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

Example

Use «Expand All» (above) to make all folds expanded: visible, searchable and printable!

You may want to use Expand All while printing from the browser or while doing text searches.

Me relying on relaying BLE?

Fig.1 Sum of suggestions (Press for PDF)

I am folding these chapters since they are so tied to the figure:

Rationale

I want to show the measured values in the aquarium (like its temperature) and the calculated values of the controller (like power delivered to the heating elements) and logged values (in the form of tables or curves) from a web server to any person who enters the room with a mobile. She must enter the ip address, but that’s all. I don’t want to make an app that picks up these values over Bluetooth. Apps are not that interesting (at the moment), embedded programming (especially in xC) is to me interesting. And the new Apache mynewt OS would certainly adds to the list of interesting things.

The above figure shows several alternatives that I will discuss here.

Don’t discard this because you think I’m headed for a complicated solution. As I said in an earlier note (151):

As an engineer I am concerned that I should end up with a «product». However, as a retired engineer I will try to enjoy the road even more than I did at work. Therefore I am not after the shortest path, but the most interesting part.

Decomposing Fig.1 Sum of suggestions

The figure shows the existing Aquarium Controller Box (ACBox) and a new unit, the Relay Box (RBox). They are both XMOS boards. The ACBox is a startKIT. I have tested and discarded one web server and WiFi board there. It runs, but is unstable and the WiFi SW has been parked by Texas Instruments. Even using the WiFi board W.2a (Adafruit 2999) and the WiFi101 library (by Arduino) I have delayed or dropped on the startKIT (ACBox) (discussed in My WiFi101 library port) since I don’t think I have resources enough there. It may still be that I will port it to the RBox:

I have concluded that this would fail, so I added a second box, the Relay Box (RBox) situated on the shelf below the aquarium. It would take its data from ACBox over Bluetooth Low Energy (BLE) boards. Either the BLE-51.1 (Adafruit 2479 with UART) or BLE-51.2 (Adafruit 2633 with SPI) inside ACBox (piggy-backed to be plugged into the vacant SPIe slot there). Observe that unlike the Aquarium Controlled Box, which has relays, the Relay Box does not have any relays! It just relays data.

The chosen board on the left side would talk over BLE with the right side and the BLE-52 board in the RBox. The exciting thing with BLE-52 is that it contains a new, free operating system by Apache. (Cut and paste from Wikipedia’s Apache Mynewt article): Apache Mynewt is a modular real-time operating system for connected Internet of things (IoT). (..) The name Mynewt is wordplay on the English word minute, meaning very small: the kernel is only 6 KB in size. The OS is designed for connectivity, and comes with a full implementation of the Bluetooth low energy 4.2 stack. It’s got preemptive multithreading, semaphores, mutexes and event queues. With the mentioned xC language and the xCORE boards, that’s basically what’s in the hardware and the language on that side. Still, I just can’t wait to see how it’s built.

The RelayBox (RBox) is an XMOS board that has been extensively described in My xCORE-200 eXplorerKIT notes (WiFi). Moving the WiFi board W.2a over there and call it W.2b to run a port of WiFi101 is one option. But then I have to do that port. Another possibility is to connect it over the RJ45 Ethernet connector (E) to a switch that’s just below the aquarium, too – and run the XMOS web server on the RBox. (Below you’ll see that this is a far stretch..)

These Adafruit boards and the porting jobs would start on the Desktop Catalyst (DCat) (Adafruit 2772) running the Arduino IDE. W.2a already runs on DCat, but not on ACBox.

Bluetooth must be plug and play in all aspects

Since my interest is along the xCORE processors and xC language, plus anything that smells concurrency and operating system these matters are in ultimate form. (21dec2017: I have not successfully asked about this at Stack Overflow, see Bluetooth BLE everything automatic. Shared on Twitter and Facebook for once.)

  • I don’t want to delve into native Bluetooth tools, like the Software Development Kit for Bluetooth from Nordic. They show these tools here. This is the reason I go for the Adafruit breakout boards, that have Adafruit code also added to the Nordic chips embedded inside the Raytac modules. I guess Adafruit has had to relate to the Nordic tools. Some (?) of these tools are supported by Keil, IAR or GCC. To a home-programmer that’s not good news. I have worked with all of those at work, and I’d like something less licence-ridden, less Windows-centric now!
    • In other words (1) I want to do precompiled bonding and pairing (all needed keys etc. stored as constants in the code or as data in FLASH), and I want connecting and reconnecting to be automatic when each unit is powered, without user interaction. I think that Secure Simple Pairing (SSP) of type Just works is what I’m after (more on Wikipedia). The connection must be permanent in all aspects of it
    • In other words (2) I don’t (too much anyway) want to associate, pair, scan, or worry about connections (so I have to worry..? Freely from Adafruit LoRa packet radio break out board description, see here.
    • In other words (3) I don’t want to be a member or pay fees to the Bluetooth organisation at https://www.bluetooth.com
  • I don’t want to buy the Segger J-Link JTAG/SWD debugger box (here). I think that’s what ARM developers need when they want more than printf and a LED debugging. So it’s really necessary if it’s ARMs I’m going to work extensively with. I’ll try to avoid that now. (Until I might get time to port/rewrite a CSP channel based scheduler that runs all over the world in cruise ships at the moment, see here). The DCat (below) does not have a connection for JTAG/SWD, but the BLE-52 would
    • That being said, I do have an xCORE board with a processor with 7 logical xCOREs and one ARM core on the chip. It cross-debugs across those two platforms with the xTIMEcomposer tool. But XMOS obsoleted it. See here
  • The price for my limited wishes may be that I probably will not be able to update the Nordic chips, should that be necessary. Both the BLE protocol stacks for nRF51822 and nRF52832 are available for download through a scheme called SoftDevice (here)

Where to find these boards

I have used the texts in Fig.1. Some of these boards have been described in other blogs, but I have (or will) refere more directly to those notes when needed. These urls are directly to the sources:

ACBox = Aquarium Controller Box dev

The processor on the startKIT board has 1 tile with 8 logical cores for the user. The programming language I have used is xC, but when I ported other people’s stuff it’s mostly done in C. The XMOS xTIMEcomposer Suite is the development tool. It runs on Eclipse/Java. Here’s my build:

Constraint check for tile[0]:
  Cores available:            8,   used:          7 .  OKAY
  Timers available:          10,   used:          8 .  OKAY
  Chanends available:        32,   used:         27 .  OKAY
  Memory available:       65536,   used:      53232 .  OKAY
    (Stack: 5572, Code: 41634, Data: 6026)

See, it’s quite different (Cores, Timers, Chanends) from the Arduino, which when I compile the SimpleWebServerWifi would show something this:

Sketch uses 42192 bytes (16%) of program storage space. Maximum is 262144 bytes.
Atmel SMART device 0x10010005 found
Device       : ATSAMD21G18A
Chip ID      : 10010005
Version      : v2.0 [Arduino:XYZ] Mar  5 2016 17:46:52
Address      : 8192
Pages        : 3968
Page Size    : 64 bytes
Total Size   : 248KB
Planes       : 1
Lock Regions : 16
Locked       : none
Security     : false
Boot Flash   : true
BOD          : true
BOR          : true
Arduino      : FAST_CHIP_ERASE
Arduino      : FAST_MULTI_PAGE_WRITE
Arduino      : CAN_CHECKSUM_MEMORY_BUFFER
Erase flash
done in 0.789 seconds

Write 42592 bytes to flash (666 pages)

[==                            ] 9% (64/666 pages)
[=====                         ] 19% (128/666 pages)
[========                      ] 28% (192/666 pages)
[===========                   ] 38% (256/666 pages)
[==============                ] 48% (320/666 pages)
[=================             ] 57% (384/666 pages)
[====================          ] 67% (448/666 pages)
[=======================       ] 76% (512/666 pages)
[=========================     ] 86% (576/666 pages)
[============================  ] 96% (640/666 pages)
[==============================] 100% (666/666 pages)
done in 0.236 seconds

Verify 42592 bytes of flash with checksum.
Verify successful
done in 0.028 seconds
CPU reset.

The xCore processors are multicore Microcontroller: XMOS Multicore Microcontrollers are programmable devices that consist of one or more xCORE tiles, each running up to eight 32bit logical processing cores. Each logical core can process I/O, DSP and application code concurrently, and shares an integrated SRAM memory. xTIME schedulers make sure that each core runs to completion without deadlock, providing a completely deterministic software programmable device that can be used to implement tasks traditionally implemented in hardware. (From the XMOS glossary of terms, here)

ACBox = Aquarium Controller Box inside

It has three buttons, a display, it measures 3 temperatures and controls 2 heating elements underneath the aquarium and several LEDs above it. It contains a clock/calendar with battery backup, plus a FRAM board. This exists. I would not want to rebuild it. There is a PCIe connector that I can use. Plus the little memory, timers and channels available.

W.2a = WiFi board direct usage

Here’s the Adafruit ATWINC1500 WiFi Breakout (2999) (With Atmel/Microchip module). If I end up with WiFi only (and not BLE) this will be the board I will base it on since I have over the past months dropped the XMOS WiFi sliceCARD that was based on the TI CC3000MOD module. Texas Instruments hasn’t updated it for years. See My Piggyback WiFi1500 sliceCARD. The ATWINC1500 runs beautifully on the Adafruit board that I call DCat here, described in the same ref just shown. It may be updated by a client that runs under the Arduino IDE, it downloads their latest SW from Microchip (see link above). However, the critical part is whether I am able to fit the WiFi101 library on the vacant resources I have left on ACBox. (As mentioned I have concluded that I won’t.) My problem is that fitting the BLE-51.1 or BLE-51.2 might be just as problematic if the libraries used are as extensive as the WiFi101. And I don’t want to cable between ACBox and RBox. But then, if all this fails I would have learned a lot and visitors don’t want to see the aquarium temperature anyhow, do they? But I would want to!

Another matter is that should I be able to fit a web server into the Aquarium Controller Box ACBox (as mentioned, I won’t), then building html pages may be another far stretch. Plus, I want to do much more logging, like seeing what’s happening with the temperature regulator when the night’s lowering of the room temperature is active. The electrical ovens do this automatically, but the aquarium’s regulator has of course to follow to keep the 25 deg C water temperature. For this logging the xCORE-200 eXplorerKIT RBox would be a perfect fit. And of course, do the html building.

BLE-51.1 or BLE-51.2 = BLE as left relay board

I think that the Adafruit Bluefruit LE UART Friend (UART is Adafruit 2479 while SPI is 2633) containing a Raytac MDBT40 with Nordic nRF51822 with ARM Cortex M0 is the simplest way to have BLE connected. I am not certain to which degree I would be able to fill some functionality into the board or just use what Adafruit has put in there. My idea is the latter, since really, really, it’s XMOS and xC I want to learn more about. But I have always tried to learn more than what I think I need to know. Selecting between UART and SPI may make some difference, since I hope that the «one UART per port pin» (?) concept of the XMOS processor (and support for them in the xC language) may be used directly, whereas for SPI there’s a whole library. Another critical point.

Low level comms

I am interested in the low-level communication with the Adafruit UART Friend, since I need to figure out if it’s easier to talk with it from the xCORE than using SPI.

Nordic NRF51822 / Bluefruit LE
  • UART. Standard with start bit, 8 data bit, optional(?) parity bit and optional(?) stop bit. Needs CTS and RTS as well
    • I had to dig to try to establish this: From Adafruit: «Transport: UART @ 9600 baud with HW flow control (CTS+RTS required!)». From here: reflecting Nordic’s nRF51 UART I/O: Pin 10 TXO is data out of Bluefruit LE, pin 9 RXI is data into Bluefruit LE, pin 11 CTS pulls data from Bluefruit LE while pin 8 RTS must be low to push data to Bluefruit LE. They are 3.3V or 3.5V level. The nRF51822 data sheet (above) shows in 4.12 that «The Universal Asynchronous Receiver/Transmitter offers fast, full-duplex, asynchronous serial communication with built-in flow control (CTS, RTS) support in hardware up to 1 Mbps baud. Parity checking is supported. The GPIOs used for each UART interface line can be chosen from any GPIO on the device and are independently configurable. This enables great flexibility in device pinout and efficient use of board space and signal routing.» It doesn’t even specify data width! I just assume it’s data 8 bits, as most UARTs have been fom the beginning of time. See Wikipedia. It looks to me from here that the data sent or received is indeed standard 8 bit – size_t (uint8_t c). From here (point 12)  it looks like there is also is an optional stop bit. It must be when it’s a UART and not a USART. Likewise there must be a start bit
  • SPI. Standard SPI. I’ve already tested this on the W.2a WiFi board
XMOS
  • UART. The Generic UART SW (here) uses 2110 bytes of code, two 1-bit ports and two channel ends. But I would have to add CTS and RTS myself
  • SPI. I have already used this, search for sci_slave (older) and lib_spi (newer) in My xCORE-200 eXplorerKIT notes (WiFi). From here I read that it uses 4 one-bit ports and about 0.8k code

From this it seems like I should go for SPI.

BLE-52 = BLE as right relay board

The Adafruit Feather nRF52 Pro (3574) with Raytac MDBT42Q with Nordic nRF52832 with ARM Cortex M4F is at least two steps up as compared to the BLE-51 boards. Firstly it’s moving from nRF51 to nRF52, containing a more powerful ARM and faster clock rate. Using the same clock rate for the same program would increase battery life. Not interesting to me, but anyhow. Then the processor has an internal architecture where Nordic has just added needed, rather standard functionality. I guess that the ARM base sets the pace on this. I just wonder how that picture would have looked if Nordic had used the XMOS architecture rather than the ARM (spec, technology and policy allowing it). Nordic Semiconductor (located just a couple of km from where I live here in Trondheim) has a blog: New features in nRF52. I just quoted unabashedly from it. Plus, as far as I can see nRF52 should encompass all nRF51 communication since they both do the BLE stack. Secondly, Adafruit has put the Apache mynewt OS (it’s supposed to be minute) into the 3574 board. So I can’t use the Arduino for it, but the Newt Tool (even written in Go/Golang that also has channels etc!). These days «everything» seems to be available on Macs, which helps, since I haven’t become familiar with Windows 10 running on Parallels Desktop, even if it’s just a click or ten away. Guess whether I am eager to learn some about mynewt! It supports board support packages for the nRF52832. This is where Adafruit comes in. This project not critical since the RBox eXplorerKIT would have enough cores, memory, threads and channels for me. This is just exciting.

W.2b = WiFi board RBox usage

This is equal to W.2a, except that it would be plugged into RBox. Also here I reckon to port the WiFi101 library. See above. There would be little risk with this, and it would be a good solution if the wired Ethernet cable E were not there. But it is! Next chapter:

E = Wired RJ45 Ethernet

This would be the final piece of SW, to get the data out of the final box. I would run the XMOS web server lib_webserver. I am investigating it at the moment.

Update 19Dec2017. This turned out not to be so simple if I’m going to use XMOS SW. It doesn’t seem to exist for the xCORE-200 eXplorerKIT which uses RGMII (not MII) with its PHY. However, it should be possible to use RGMII, since [lib_ethernet] supports both RGMII and MII! See note My single-board boards and why notes chapter Conclusion and todo list point 3 – that will point you to other places. (Aside: I can find a converter out there from GMII (not MII) to RGMI, but that’s of course an ASIC FPGA library from Intel. It’s at Embedded Peripherals IP User Guide, Intel UG-01085 at 2017.11.06, chapter Intel FPGA GMII to RGMII Converter Core, here.)

Aside: Search for «lib_webserver» in My xCORE-200 eXplorerKIT notes (WiFi). But the XMOS url is here: https://www.xmos.com/support/libraries/lib_webserver. I have a quite interesting question at the xCore Exchange, about a pattern that they use in module_mutual_thread_comm where they do mutual bidirectional communication between two threads with only one channel. See here (however, it hadn’t been answered by any last time I checked).

DCat = Desktop Catalyst

The Adafruit Feather M0 Basic Proto ATSAMD21 Cortex M0 (2772) is a nice little board that I basically use with the Arduino tool. I have shown this in My WiFi101 library port. This means I have W.2a/W.2b running on it. Plus, if I buy BLE-51.1 or BLE-51.2 than it’s on this board I need to be able to get it running first. Only after that will I need to try to port that SW to the ACBox startKIT. As mentioned, the I will not use the DCat to debug BLE-52, which has its own USB port for my Mac and the Newt Tool. Exciting times!

Questions

  1. Adafruit Forum: Code size for Bluefruit LE UART/SPI Friend? (Dec2017)
  2. Adafruit Forum: Bluefruit nRF51 talking with Feather nRF52 Pro plug and play? (Dec2017)

Conclusion

I think I will continue to keep all my conclusions to the same chapter, in a previous blog note. See My single-board boards and why note, chapter Conclusion and todo list. Since I have written so many notes that at first glance look like they’re all equal, that may help connect the threads. That being said and since I have already mentioned it, I did go for a simpler(?) radio solution, as discussed in my next note My aquarium’s data radioed through the shelf.

Leave a Reply

Dette nettstedet bruker Akismet for å redusere spam. Lær om hvordan dine kommentar-data prosesseres.