Blog

articles and technical details

Developing for CC2540: Part I

Posted on Dec 18, 2011 | 6 comments

IAR Development Environment

TI’s CC2540 is both the host microcontroller and a bluetooth LE chip, commonly referred to as SoC (System on Chip). You would think that the host microcontroller might be just tacked-on, an after-thought, since the bluetooth LE chip is the star of the show. If that might have been your first impression, you’d be dead wrong. The microcontroller (SoC) component of CC2540 is a full-blown 8051 core with impressive array of  peripherals and functionalities. This 8051 chip boasts 256kB flash for programming space, 8kB ram, USB driver, 2 hardware controlled UART, and many more features.  In comparison, the ever-popular Arduino Uno only has 32Kb, merely 8 time smaller than this 8051 core in CC2540.

With such a beefy spec on their 8051 core, Chipcon (subsidiary of TI since 2006) developers went all-out designing a significant software stack for their line of newer chips. This software stack relies on abstracted layers of software, delineating the logical separation of hardware interface, operating system, and user application. With the exception of the BLE stack, the part of the library that implements Bluetooth LE communication, rest of the source code is provided with the download. The code is well-thought out and nicely laid out, with ample comments that serve as documentation in itself.

This software stack takes up over 100kB of 256kB total flash space. On my machine, the compiled code took up about 110kB. It could be the differences between the IAR version and the library version (mine’s on 1.1a).

HAL Layer

The HAL (Hardware Abstraction Layer) sits on top of IAR’s device-specific defines for CC2540 (ioCC2540.h). It gives convenient mappings for IO peripherals, and macros for accessing hardware functions within CC2540 such as UART, SPI, USB, Timers, etc.

This layer also defines which ports are tied to which peripherals are mapped to which IO modules on the Evaluation board. The Chipcon’s SmartRF05EB Evalulation Board is the one that comes with CC2540 development kit. This board as many IO goodies such as LCD, led’s, eeprom, push buttons, directional joy stick. The file hal_board_cfg.h defines these mappings, and the documentation suggests modifying this file when using CC2540 on a different board (obviously!).

 

OSAL Layer

The development of CC2540 requires knowledge of layers of software stack that are rather involved. For example, series of tasks are handled by event-based operating system layer called OSAL (Operating System Abstract Layer). This layer is not a full operating system, however.

The OSAL layer gives wrappers and interfaces to execute linear set of operations in an organized manner. It does this by largely defining actions into 2 categories: tasks and events. Each task can handle multiple events, and each event corresponds to a specific task. You can think of this as array of tasks, each task item containing 16 bits. Each bit per task would correspond to an event that is associated with such task. Thus, you can define at most 15 (-1 for reserved) events per task.

The implementation of this task / event handling is found under OSAL.c, within the function osal_run_system.

  uint8 idx = 0;

  osalTimeUpdate();
  Hal_ProcessPoll();

  do {
    if (tasksEvents[idx])  // Task is highest priority that is ready.
    {
      break;
    }
  } while (++idx < tasksCnt);

  if (idx < tasksCnt)
  {
    uint16 events;
    halIntState_t intState;

    HAL_ENTER_CRITICAL_SECTION(intState);
    events = tasksEvents[idx];
    tasksEvents[idx] = 0;  // Clear the Events for this task.
    HAL_EXIT_CRITICAL_SECTION(intState);

    activeTaskID = idx;
    events = (tasksArr[idx])( idx, events );
    activeTaskID = TASK_NO_TASK;

    HAL_ENTER_CRITICAL_SECTION(intState);
    tasksEvents[idx] |= events;  // Add back unprocessed events to the current task.
    HAL_EXIT_CRITICAL_SECTION(intState);
  }

Notice it scans from the lowest idx (highest priority task), finds the task with any event set on it. It then drops into the if block that checks to make sure the idx of the task is not the max of tasks registered. Within this block, it simply calls the callback function registered within tasksArr which is a global variable containing all registered callback functions. Prior to the execution of this function, the data arrays tasksEvents and tasksArr needs to be created during compile time.

Read More

BLE Protocol Stack

Posted on Dec 17, 2011 | Comments Off on BLE Protocol Stack

The Bluetooth LE’s protocol is comprised of several layers of both hardware and software implemented inter-communication paradigm. The picture below describes how the protocol stack is organized:

ble-stack

The developers typically deal with both GAP and GATT layers when implementing their applications. The GAP layer defines several roles the bluetooth LE end-device will be classified as. The GATT layer defines profiles, which is organized set of data and services the end-device will support. Through these layers, each BLE device can not only be identified, but its characteristics and attributes can be determined by other nodes wanting to pair against it. The lower layers of the protocol stack is both a combination of hardware implementation and software enforced interface.

New GATT profile specifications are being proposed and adopted by the members of Bluetooth SIG. These specifications provide guidelines across wide range of end-user applications and scenarios. A complete list of these profiles can be found here.

In order to draw a parallel against the internet world, the GAP can be thought of as a type of application protocol such as FTP, HTTP, SSH. Furthermore, once an application has been classified as HTTP, it would support protocol specific commands such as GET or POST requests, among others. These protocol-specific set of functions and data can be thought of as GATT in the BLE world.

For more detailed description of the BLE protocol stack, the following documents by TI can be very useful in understanding the basic concepts.

ti-ble-dev

ti-ble-sample

Read More

A Foray Into Bluetooth LE

Posted on Dec 17, 2011 | Comments Off on A Foray Into Bluetooth LE

Bluetooth Low Energy, or otherwise known as Bluetooth v4.0, is the new wireless standard targeted for new generation of low-power applications. With the advent of smartphone technologies and mobile computing, the need for portable sensors and near-communication networks have become a new found interest among vendors as well as consumers.

We are at the cusp of technological convergence and advancement that will make significant impact in the way we live. Low-power wireless sensors can be literally embedded everywhere, from wearable devices to buildings, and common objects that we associate with day-to-day. These monitors can be designed to transmit useful data from their physical surroundings and environments, and the collected data can be harvested for practical applications.

One of the primary areas where we envision the general use of wireless technology is within the consumer monitoring industry. Bluetooth LE can enable telemonitoring, or remote monitoring, of consumers. The vital signals and the data can be transmitted wirelessly. These sensors can not only provide detailed data for personnel caring for the consumers, but also trigger alerts upon specific body conditions. This will allow continuous active monitoring of consumers who need intensive care and will help improve the quality of diagnose and treatment.

There are many useful resources online in order to learn more about Bluetooth LE. To list a few:

We will focus on developing useful and exciting devices with Bluetooth LE. While our products will not be limited to using Bluetooth LE, it will be interesting to see cool applications come out of this new wireless standard in the coming few years. Stay tuned!

Read More