Contiki-NG
Modules | Files | Functions

The OpenMote-CC2538 is based on the CC2538, the new platform by Texas Instruments based on an ARM Cortex-M3 core and a IEEE 802.15.4 radio. More...

Modules

 OpenMote-CC2538 antenna switch
 Driver for the OpenMote-CC2538 antenna switch.
 
 OpenMote-CC2538 platform
 The OpenMote-CC2538 platform was designed at UC Berkeley in 2013 and is comercialized by OpenMote Technologies since 2014.
 
 OpenMote-CC2538 sensors
 Generic module controlling sensors on the OpenMote-CC2538 platform.
 
 OpenMote-CC2538 user button
 Generic module controlling the user button on the OpenMote-CC2538.
 
 TPS62730 voltage regulator
 Driver for the TPS62730 voltage regulator, to enable power from the battery voltage (bypass, Vout=Vin, Iq < 1uA) or through the buck regulator (on, Vout=2.1V, Iq = 30uA)
 

Files

file  board.c
 Board-initialisation for the OpenMote-CC2538 platform.
 
file  board.h
 This file provides connectivity information on LEDs, Buttons, UART and other OpenMote-CC2538 peripherals.
 
file  platform.c
 Main module for the OpenMote-CC2538 platform.
 

Functions

void board_init (void)
 Board specific iniatialisation.
 
void platform_init_stage_one (void)
 Basic (Stage 1) platform driver initialisation. More...
 
void platform_init_stage_two ()
 Stage 2 of platform driver initialisation. More...
 
void platform_init_stage_three ()
 Final stage of platform driver initialisation. More...
 
void platform_idle ()
 The platform's idle/sleep function. More...
 

OpenMote-CC2538 LED configuration

LEDs on the OpenMote-CC2538 are connected as follows:

  • LED1 (Red) -> PC4
  • LED2 (Yellow) -> PC6
  • LED3 (Green) -> PC7
  • LED4 (Orange) -> PC5
#define LEDS_ARCH_L1_PORT   GPIO_C_NUM
 
#define LEDS_ARCH_L1_PIN   4
 
#define LEDS_ARCH_L2_PORT   GPIO_C_NUM
 
#define LEDS_ARCH_L2_PIN   6
 
#define LEDS_ARCH_L3_PORT   GPIO_C_NUM
 
#define LEDS_ARCH_L3_PIN   7
 
#define LEDS_ARCH_L4_PORT   GPIO_C_NUM
 
#define LEDS_ARCH_L4_PIN   5
 
#define LEDS_CONF_RED   1
 
#define LEDS_CONF_YELLOW   2
 
#define LEDS_CONF_GREEN   4
 
#define LEDS_CONF_ORANGE   8
 
#define LEDS_CONF_COUNT   4
 

USB configuration

The USB pullup is driven by PC0

#define USB_PULLUP_PORT   GPIO_C_NUM
 
#define USB_PULLUP_PIN   0
 

UART configuration

On the OpenMote, the UART is connected to the following ports/pins

  • RX: PA0
  • TX: PA1
  • CTS: PB0 (Can only be used with UART1)
  • RTS: PD3 (Can only be used with UART1)

We configure the port to use UART0. To use UART1, replace UART0_* with UART1_* below.

#define UART0_RX_PORT   GPIO_A_NUM
 
#define UART0_RX_PIN   0
 
#define UART0_TX_PORT   GPIO_A_NUM
 
#define UART0_TX_PIN   1
 
#define UART1_RX_PORT   GPIO_B_NUM
 
#define UART1_RX_PIN   0
 
#define UART1_TX_PORT   GPIO_D_NUM
 
#define UART1_TX_PIN   3
 
#define UART1_CTS_PORT   (-1)
 
#define UART1_CTS_PIN   (-1)
 
#define UART1_RTS_PORT   (-1)
 
#define UART1_RTS_PIN   (-1)
 

OpenMote-CC2538 Button configuration

Buttons on the OpenMote-CC2538 are connected as follows:

  • BUTTON_USER -> PC3
#define BUTTON_USER_PORT   GPIO_C_NUM
 BUTTON_USER -> PC3.
 
#define BUTTON_USER_PIN   3
 
#define BUTTON_USER_VECTOR   GPIO_C_IRQn
 
#define PLATFORM_HAS_BUTTON   1
 
#define PLATFORM_SUPPORTS_BUTTON_HAL   1
 

SPI (SSI0) configuration

These values configure which CC2538 pins to use for the SPI (SSI0) lines.

The SSI0 is currently used to interface with the Ethernet driver (ENC28J60) on the OpenBase board.

#define SPI_CLK_PORT   GPIO_A_NUM
 
#define SPI_CLK_PIN   2
 
#define SPI_MOSI_PORT   GPIO_A_NUM
 
#define SPI_MOSI_PIN   5
 
#define SPI_MISO_PORT   GPIO_A_NUM
 
#define SPI_MISO_PIN   4
 

SPI (SSI1) configuration

These values configure which CC2538 pins to use for the SPI (SSI1) lines.

The SSI1 is currently not used.

#define SPI1_CLK_PORT   GPIO_C_NUM
 
#define SPI1_CLK_PIN   4
 
#define SPI1_TX_PORT   GPIO_C_NUM
 
#define SPI1_TX_PIN   5
 
#define SPI1_RX_PORT   GPIO_C_NUM
 
#define SPI1_RX_PIN   6
 

I2C configuration

These values configure which CC2538 pins to use for the I2C lines.

#define I2C_SCL_PORT   GPIO_B_NUM
 
#define I2C_SCL_PIN   3
 
#define I2C_SDA_PORT   GPIO_B_NUM
 
#define I2C_SDA_PIN   4
 

CC2538 TSCH configuration

#define RADIO_PHY_OVERHEAD   CC2538_PHY_OVERHEAD
 
#define RADIO_BYTE_AIR_TIME   CC2538_BYTE_AIR_TIME
 
#define RADIO_DELAY_BEFORE_TX   CC2538_DELAY_BEFORE_TX
 
#define RADIO_DELAY_BEFORE_RX   CC2538_DELAY_BEFORE_RX
 
#define RADIO_DELAY_BEFORE_DETECT   CC2538_DELAY_BEFORE_DETECT
 

Device string used on startup

#define BOARD_STRING   "OpenMote-CC2538"
 

Detailed Description

The OpenMote-CC2538 is based on the CC2538, the new platform by Texas Instruments based on an ARM Cortex-M3 core and a IEEE 802.15.4 radio.

Function Documentation

◆ platform_idle()

void platform_idle ( void  )

The platform's idle/sleep function.

This function will be called as part of the main loop after all events have been serviced. This is where you will normally put the device in a low-power state. Waking up from this state and tidying up the hardware is the port's responsibility.

It is the port developer's responsibility to implement this function.

Definition at line 186 of file platform.c.

◆ platform_init_stage_one()

void platform_init_stage_one ( void  )

Basic (Stage 1) platform driver initialisation.

This function will get called early on in the Contiki-NG boot sequence.

In this function, the platform should initialise all core device drivers. For example, this is where you will normally want to initialise hardware timers/clocks, GPIO, LEDS. Normally this function will also enable the MCU's global interrupt.

The Contiki-NG process scheduler, software clocks and timers will not be running yet, so any platform drivers that rely on it should not be initialised here. Instead, they should be initialised in platform_init_stage_two() or in platform_init_stage_three()

It is the port developer's responsibility to implement this function.

See also
platform_init_stage_two()
platform_init_stage_three()

Definition at line 123 of file platform.c.

References leds_init(), and soc_init().

◆ platform_init_stage_three()

void platform_init_stage_three ( void  )

Final stage of platform driver initialisation.

Initialisation of platform-specific drivers that require networking to be running. This is also a good place to initialise sensor drivers.

When this function returns, the main routine will assume that the hardware is fully initialised.

It is the port developer's responsibility to implement this function.

See also
platform_init_stage_one()
platform_init_stage_two()

Definition at line 170 of file platform.c.

◆ platform_init_stage_two()

void platform_init_stage_two ( void  )

Stage 2 of platform driver initialisation.

This function will be called by the Contiki-NG boot sequence after parts of the core have been initialised. More specifically, when this function gets called, the following modules will be running:

  • Software clock
  • Process scheduler
  • Event timer (etimer)
  • Callback timer (ctimer)
  • rtimer
  • Energest (if enabled)

Therefore, any platform driver that relies on any of the above modules should be initialised here or in platform_init_stage_three(), but not in platform_init_stage_one()

The Contiki-NG network stack will not be running yet, so any platform drivers that rely on networking should not be initialised here.

When this function returns, the main routine will assume that the platform has enabled character I/O and can print to console. When this function returns, main() will attempt to initialise the network stack. For this to work properly, this function should also populate linkaddr_node_addr.

It is the port developer's responsibility to implement this function.

See also
platform_init_stage_one()
platform_init_stage_three()

Definition at line 132 of file platform.c.

References i2c_init(), SERIAL_LINE_CONF_UART, serial_line_input_byte(), uart_init(), uart_set_input(), usb_serial_init(), and usb_serial_set_input().