Internet of Things Platform: TI CC1310, CC2630 and CC2650 Chips

    Hi GT.


    A few months ago, we already wrote about what communication protocols are used (and are not used) on the Internet of Things. In short, in general, the whole IoT topic in the basis comes down to providing a communication channel to devices that did not have a communication channel before - and in order for it to make sense, the means of providing such communication should be:


    1. Compact - so as not to increase the size of devices
    2. Economical - to work even on batteries for a long time
    3. Cheap - so that their use has some economic meaning

    To everyone's happiness, now there are quite a lot of such tools - starting with more or less successful attempts to adapt the good old Wi-Fi to these requirements (I am now more about battery-powered Wi-Fi devices, from ESP8266 to QCA 4004 and TI CC3200) and ending with specialized protocols, originally made for these requirements: first of all ZigBee, Z-Wave and 6LoWPAN.


    The most flexible, convenient and promising of these is 6LoWPAN (and if you heard the word “Aspirant” aspirated, it actually runs over 6LoWPAN) - and, in fact, we are developing modules and devices using 6LoWPAN.


    But network protocols are obviously only half the trouble. The second half is “iron”, on which they will work.



    868 MHz modules of our development on TI CC1310


    Recently, a fashion appeared to glue the label “IoT” to literally everything that somehow can work with “wireless” - starting with the Arduino with attached BLE or Wi-Fi shield and ending with all sorts of obsolete chips that have been for ten years released the "official" ZigBee stack back. In a person who, for the first time, is immersed in it, the head will spin rather quickly and at an unpleasantly high speed.


    In our work, we clearly decided on the choice of platform for the foreseeable future - this is the latest generation of SoC Texas Instruments SimpleLink series, chips CC1310, CC2630 and CC2650.


    Under Habrakat - an explanation of why the choice is such and why we consider it right.


    So, first we modify the requirements a bit - so that they describe exactly the chip:


    1. Energy efficiency. The chip should be able to at least three modes - deep sleep with memory preservation and awakening from an external interrupt, the “sleeping router” mode (the radio channel works, everything else wakes up if something has flown into the radio channel) and normal operation
    2. Compactness. Since IoT has to be built into the most unexpected places, the chip in the LQFP-100 with its 2.5 cm² of occupied space is a bad option that does not allow making a compact solution.
    3. Cost It does not have to be a three-gross, but it must be reasonable. However, 15-dollar monsters are usually eliminated at the previous point.
    4. Software support, that is, in our case, Contiki or, better, RIOT OS. Of course, you can take FreeRTOS and start slinging an IPv6 network stack into it yourself, but this is not for the faint of heart.

    The SimpleLink line in its latest incarnation consists of four main models:


    ModelHousingMemoryCPURF CPUCoprocessorRadio802.15.4Ble
    CC1310QFN-48, QFN-32128 kb flash + 20 kb ramCortex-M3Cortex-M016-bit SC<1 GHzthere isNot
    CC1350QFN-48, QFN-32128 kb flash + 20 kb ramCortex-M3Cortex-M016-bit SC<1 GHz + 2.45 GHzthere isthere is
    CC2630QFN-48, QFN-32128 kb flash + 20 kb ramCortex-M3Cortex-M016-bit SC2.45 GHzthere isNot
    CC2650QFN-48, QFN-32128 kb flash + 20 kb ramCortex-M3Cortex-M016-bit SC2.45 GHzthere isthere is

    Now let's go through the list items - why we like this particular line, and not some other one.


    Energy efficiency . In addition to the usual for all microcontroller sleep modes - there are several of them, from "die all living things" with a consumption scale of 0.1 μA to Idle while preserving memory, registers and ticking clocks with a consumption of 1 μA, the latest generation of tsetseshek has several fun features.


    First, there are three (three, Karl!) Processor cores. The main one is Cortex-M3 at 48 MHz, with its operation the total power consumption will be about 2.5 mA in the absence of radio activity. It is, in general, the same as all other MCUs on ARM.


    The second is the Cortex-M0 with proprietary firmware (users are not allowed into it directly), serving only the radio. Its independence allows you to do funny things - for example, a sleeping router, in which the radio operates normally, and the main core wakes up only if the radio saw the preamble on the air. Consumption in this dream - 550 μA, is not very small, but several times less than that of a fully active chip.


    The third core is a specialized 16-bit Sensor Controller Hub, something with a non-advertised architecture and a firmware generator. This micro-consuming core, which is responsible for a significant part of the periphery, including the ADC - you can, for example, catch various events on the analog inputs and wake up the main core, and then the radio, and then the rest of the world. SC can also work with touch buttons, timers, I²C, SPI and UART (sic!). All this - with the main core turned off and with the consumption of microamper scale.


    Finally, all the chips in the line have built-in DC / DC (sic!). The trick is that the radio part of the chips is powered by low voltage - and in previous years, you had to either install external DC / DC, or put up with losses on the built-in LDO. CC13xx / CC26xx allow you to choose from three options - completely external power, built-in DC / DC or built-in LDO. In the case of DC / DC external elements - one choke.


    Finally, in order to do everything perfectly well, in CC13xx and CC26xx, compared to the previous generation, the radio part was sawed - and the power consumption at the reception and transmission (that is, with the active radio channel) decreased a couple of times.


    Compactness . All chips are in three QFN packages - 7x7, 5x5 and 4x4 mm. The cases are largely compatible with each other on the legs - it is clear that you cannot make 2450 MHz and 868 MHz with a universal board due to the very different matching of antennas, but if you need to develop a line of universal modules, the task of switching between different chips is greatly simplified.


    Between themselves, the cases differ in the number of GPIO - 31, 15 or 10. For most projects, a 5x5 mm chip seems a reasonable compromise, but I cannot help but notice that due to the lack of them for sale at the end of last year, we made all our modules on 7x7 chips mm


    Cost . The retail price tag for chips in Russia is around $ 6-7 (individual heroes, of course, sell $ 12 each, but 6-7 is the price tag we regularly and calmly take when we need ten or twenty chips) , the official wholesale price tag on the TI website goes down to $ 2.5 to its fullest.


    It is not cheap and not expensive. Taking into account the capabilities of the chips - the optimal average level; You can find chips cheaper, but they will be easier. You can find more expensive, but their capabilities in 99% of cases will not be needed. You can do it on the wonders of the Chinese industry, but in general I don’t think that you dream of being responsible for the stability of some SCADA system on a large industrial facility, having made it on ESP8266.


    With ready-made modules on these chips, the case is somewhat more complicated - until recently the only acquisition option was a developer kit for $ 299 and additional radio modules for it for $ 99 a pair. Now there LaunchPad for $ 29 .


    Our own modules in single-piece retail cost $ 20 - although it would be more correct to say “will cost”, since while the firmware and some related services are being developed, we sell them only by direct agreement, for example, to friendly integrators and other interested parties.


    The wholesale price of such a module with a fairly large batch easily drops to $ 10. Again, quite reasonable value for money.


    Software support . It's Complicated. Here, to be honest, in general, everything is difficult for everyone - I have not yet met those who would have it easy.


    For its chips, TI releases a native TI RTOS, in which there is good support for the existing peripherals - but there are no network stacks. And the network stack is what distinguishes IoT from non-IoT.


    Traditionally, IoT uses Contiki OS - and so we do. Formally, it supports these chips. But ... but ...


    At the end of last year, out of the box, neither 6LoWPAN in Contiki actually worked, nor 6lbr on the gate (it’s also the server of the 6LoWPAN network). After their repair, it turns out that the level of applications available in Contiki ... well, it's almost not there, to be brief. After writing the code for the things we need - the usual set of sensors, GPIO, ADC, etc. - about 95% of the implementation of the application level turned out to be ours


    The situation with the drivers is even worse, that is, the layer between the very level of applications and the chip's periphery itself - out of the box was the UART driver and GPIO (only for output), as well as the driver for buttons on the GPIO, which worked so that it would not be better It was. Timers, PWM, ADC, interrupts on GPIO, normal button bounce suppression, i²C, in the end - we wrote all this ourselves.


    It was especially fun with timers and PWM, because at that time, even in the TI documentation, the information on working with them was, let's say, fragmentary (but then thanks to TI support - they gave answers for a few days, even if they were politically inconvenient: for example, to write a PWM driver, it was necessary to read the documentation from another chip, and to take code samples from almost a third).


    The next entertainment theme is sleep modes. Contiki on these chips supports exactly two - everything is on and everything is off. In the first, the system eats 2.5 mA in the absence of any activity; after leaving the second, it searches for a minute where there was a gateway with which to communicate. Neither Idle with preservation of registers and memory (and, accordingly, information about the address and route to the gateway), nor, especially, sleeping routers simply do not exist.


    As you have already guessed, we do support full Idle with selective disconnection of unnecessary peripherals (including the radio module). Already almost done.


    Finally, the radio channel would be nice to encrypt. The level of applications — so as not to steal data, the level of network — so that the channel is not blocked by the simplest DoS attack with valid headers and garbage in the body. Encryption in Contiki is not that not at all - but what is in the public domain, is in its infancy. In general, consider that it is not.


    At the same time, Contiki has a significantly more recent competitor -  RIOT OS . But in the RIOT there is no support for these chips yet.



    Control module 75-watt LED lamp : on / off, dimming 0-10 V, monitoring the integrity of two LED bars


    Instead of a conclusion . The reader, who has come to this point, has only one question left in his mind - why don't we abandon this venture and do something simpler?


    Because, alas, with all the loud and pretentious speeches about the coming dominance of the “Internet of things” there is nothing simpler.


    First, there are no chips with capabilities comparable to the CC1310 and CC2650 - in terms of computing power, peripherals, and energy saving opportunities ... There are chips that are cheaper and simpler, which can successfully solve some particular tasks, for example, transceivers with an integrated 8051 core You can take two to three times cheaper. Here, only 8051 is, for example, not quite the core on which you want to raise a mesh network or even write processing of some complex set of sensors in order not to load the radio channel with raw data. The same applies to all sorts of options ESP8266 - a great thing for amateur crafts, but the network of street lighting control on Wi-Fi, I imagine pretty bad, if only because Wi-Fi on the street is not unlicensed (and even worse, I imagine


    Secondly, as I said, this is a fairly typical state of the industrial “Internet of Things” in our day. As soon as someone starts telling you about “a real IoT project in the evening” - click a page down a couple of times, there will not be an IoT, but another smart socket from the arduin with a BLE shield.


    Thirdly, we have hope to bring to the IoT industry a fresh stream of affordable, understandable and stably operating devices with a technological level corresponding to 2016 rather than 2006. Now we are working quite closely with several system integrators and manufacturers of end devices on the integration of 6LoWPAN network support into their projects and products - and, of course, we already have a stable and stable Contiki OS, with support for all the peripherals we need, drivers for various sensors and other weight .


    However, we have a few more plans for the summer - to make the CC2650 + Contiki = 6LoWPAN platform accessible to amateurs and education (and preparing students who understand what IoT is is a separate sore subject due to the total lack of modern and at least to some extent open IoT-platforms suitable for training). We have already begun to provide our devices for various events (yes, we must not forget to tell about soil moisture sensors separately, this is an interesting topic), and we have definite plans to release the Unwired Kit rapid prototyping kit for free sale .


    And as for Contiki - well, you have to make a web service for assembling firmware. With the choice of functionality and the ability to add its top-level functions to ready and debugged drivers and network stacks.


    Do not force people to go through seven circles of hell.


    Also popular now: