Making Capuccino & Program

#include <Timer.h>
#include "BlinkToRadio.h"

configuration BlinkToRadioAppC {
}
implementation {
  components MainC;
  components LedsC;
  components BlinkToRadioC as App;
  components new TimerMilliC() as Timer0;

  App.Boot -> MainC;
  App.Leds -> LedsC;
  App.Timer0 -> Timer0;
}

typedef nx_struct BlinkToRadioMsg {
  nx_uint16_t nodeid;
  nx_uint16_t counter;
} BlinkToRadioMsg;

module BlinkToRadioC {
  ...
  uses interface Packet;
  uses interface AMPacket;
  uses interface AMSend;
  uses interface SplitControl as AMControl;
}

event void Timer0.fired() {
  ...
  if (!busy) {
    BlinkToRadioMsg* btrpkt = (BlinkToRadioMsg*)(call Packet.getPayload(&pkt, NULL));
    btrpkt->nodeid = TOS_NODE_ID;
    btrpkt->counter = counter;
    if (call AMSend.send(AM_BROADCAST_ADDR, &pkt, sizeof(BlinkToRadioMsg)) == SUCCESS) {
      busy = TRUE;
    }
  }
}

implementation {
  ...
  components ActiveMessageC;
  components new AMSenderC(AM_BLINKTORADIO);
  ...
}

implementation {
  ...
  App.Packet -> AMSenderC;
  App.AMPacket -> AMSenderC;
  App.AMSend -> AMSenderC;
  App.AMControl -> ActiveMessageC;
}

이제 슬 무선 통신을 해보도록 하겠습니다.

이번장에서 배울것.
 - message_t 메세지 버퍼
 - 무선을 통해 메세지 버퍼 송신
 - 무선을 통해 메세지 버퍼 수신

Introduction

TinyOS는 기본적인 통신을 지원 하기 위한 추상 인터페이스와 컴포넌트를 제공 합니다. 이 인터페이스들와 컴포넌트는 message_t라는 추상 메세지 버퍼를 사용 합니다.(message_t는 일반 C와 비슷한 nesC 구조체로 되어 있습니다.) message_t 구조체는 직접 접근은 되지 않으며 제공되는 acessor 나 mutator function을 사용 하여 접근 가능 합니다.

Basic Communications Interfaces

message_t를 사용하는 기본적인 인터페이스는 다음과 같습니다.(tos/interface 폴더에 위치 하고 있습니다.)

* Packet - message_t 구조체를 접근 하기위한 인터페이스입니다.,패킷의 길이, 패킷의 데이타 포인터등을 제공 합니다.
* Send - 주소와 관계없는 메세지 송신에 사용 하는 인터페이스 입니다.
* Receive - 패킷 송신에 관련된 인터페이스 입니다. receive이벤트를 가지고 있으니 꼭 구현 해주어야 합니다. 수신패킷에 접근 할 수 있는 기능도 제공 합니다.
* PacketAcknowledgements - 패킷에 기반하여 ACK 기능을 제공 합니다.
* RadioTimeStamping - 패킷 송수신에 대한 시간 정보(?)를 제공 합니다.

Active Message Interface
TinyOS의 인터넷의 패킷 처럼 무선 전송시 다중 접근 할 수 있는 AM layer를 제공 합니다.(이해가 좀 어렵습니다. 인터넷의 그것 처럼 IP,UDP 이런식으로 구조화 되어 있어 다중 레이어로 되어 있다 생각 하면 될것 같습니다.) 위와 달리 AM은 목적지 주소를 가지고 있어 유니캐스트를 지원 합니다. 그리고 AM에 대한 인터페이스 역시 tos/interface에 있습니다.

* AMPacket - 위 Packet과 비슷한 기능입니다, 추상 구조체인 message_t를 AM 으로 제공 합니다. 목적지를 설정하거나 체크 하는등의 기능을 제공 합니다.
* AMSend - Send와 비슷하나, 목적지 주소(AM Address를 가지고 한개의 노드를 향해 메세지를 송신 합니다.

AM address는 컴파일시 결정되나, ActiveMessageAddressC에서 바꿀 수 있습니다.

Components
TinyOS 2.0에서 무선 통신을 위해 기본적으로 제공 하는 컴포넌트들 입니다. tos/system 에 위치 하고 있습니다.

* AMReceiverC - Receive,Packet,AMPacket을 제공
* AMSenderC - AMSend,Packet,AMPacket,PacketAcknowlegements,Acks를 제공
* AMSnooperC - Receive,Packet,AMPacket을 제공
* AMSnooperReceiverC - Receive,Packet,AMPacket을 제공
* ActiveMessageAddresC- Acitve Adress 체크 및 설정에 사용 합니다.주소 재설정을 사용시에는 확실히 알고 하셔야 합니다.

Naming Wrappers
TinyOS는 여러 플랫폼 지원을 위해 송수신 관련 ActiveMessageC Warpper로 하위 추상 클래스를 가지고 있습니다. ActiveMessageC는 위 대부분의 인터페이스를 가지고 있습니다. 각 플랫폼 별 ActiveMessageC는 다음과 같습니다.

* eyesIFX - Tda5250ActiveMessageC
* telosa,telosb,micaz,intelmote - CC2420ActiveMessageC
* mica - CC1000ActiveMessageC
(* ActiveMessageC를 통해 모듈을 추상화 했다고 보면 됩니다.)

TinyOS 2.0 Message Buffer
TinyOS 2.0에서는 기존 메세지 TOS_Msg를 대체하는 message_t를 가지고 있습니다. tos/types/message.h에 선언 되어 있습니다.

typedef nx_struct message_t {
  nx_uint8_t header[sizeof(message_header_t)];
  nx_uint8_t data[TOSH_DATA_LENGTH];
  nx_uint8_t footer[sizeof(message_header_t)];
  nx_uint8_t metadata[sizeof(message_metadata_t)];
} message_t;

위 구조중 header,footer,metadata는 수정 불가 입니다. 이유는 data의 포인터 위치 고정 입니다.

내용이 많은건 아닌데.. 블로그 특징상 길게 쓰면 이상해 보여요 ㅜ.ㅜ; 절대 내용 많은거 아님

Internal Function

이부분은 아주 간단한 내용입니다. 일반 C 언어 처럼 함수를 선언해서 쓸수 있다는 내용 입니다. 함수의 형식은 일반 C를 따르며, command, event등을 쓰지 않으며, 다른 컴포넌트는 내부 함수는 호출 할 수 없습니다.

예는 다음과 같습니다.

module BlinkC {
  uses interface Timer<TMilli> as Timer0;
  uses interface Timer<TMilli> as Timer1;
  uses interface Timer<TMilli> as Timer2;
  uses interface Leds;
  uses interface Boot;
}
implementation
{

  void startTimers() {
    call Timer0.startPeriodic( 250 );
    call Timer1.startPeriodic( 500 );
    call Timer2.startPeriodic( 1000 );
  }

  event void Boot.booted()
  {
    startTimers();
  }

  event void Timer0.fired()
  {
    call Leds.led0Toggle();
  }
 
  event void Timer1.fired()
  {
    call Leds.led1Toggle();
  }
 
  event void Timer2.fired()
  {
    call Leds.led2Toggle();
  }
}

보시다 시피 startTimers() 란 내부함수가 있으며, 같은 컴포넌트 내에서는 제한 없이 사용 할 수 있습니다.

물론 함수를 사용 하기전에 정의는 되어 있어야겠죠.

Split-Phase Operations

command, evnet, 외 중요한 개념입니다. NesC는 와이어 처리를 컴파일시 하게 되어 있어 콜백 즉 event 시스템은 TinyOS에서도 매우 효율적으로 동작 할 수 있습니다.

Blocking 실행을 해야 하기 때문에 TinyOS에서 컴포넌트를 넘어가며 최적화 하는 능력은 매우 중요합니다. Blocking 시스템(절차적 언어)에서는 프로그램이 매우 긴 수행시간의 함수를 실행시 함수가 실행이 종료될때 까지 시스템이 멈처진 상태에 있게 됩니다. 하지만 Split-Phase 시스템에서는 함수는 최대한 빠르게 리턴되며 Operaion이 종료된 후에는 콜백을 사용 하여 "완료" 신호를 날리도록 되어 있습니다.

if (send() == SUCCESS) {
  sendCount++;
}

// start phase
send(); 

//completion phase
void sendDone(error_t err) {
  if (err == SUCCESS) {
    sendCount++;
  }
}

Split-Phase의 이점은 스택메모리를 실행 될 동안 점유 하지 않으며, 함수의 실행 종료를 기다리지 않으므로 시스템의 정체를 줄이며, 스택의 활용도를 늘리게 됩니다.

Split-Phase 시스템은 TinyOS가 여러개의 작업을 동시에 수행 할 수 있게 하며 메모리를 절약 시킵니다.

Timer.startOneShot 은 Split-Phase의 좋은 예입니다.

이제 부터 공부의 속력을 내기 위해 요약 해석 할 예정입니다.

속도가 넘 안나네요.

Interfaces,Commands,and Events

Lesson1의 경험으로 인터페이스를 사용하는 컴포넌트는 인터페이스의 command를 실행 할 수 있으며, 역으로 이벤트는 받아서 처리 해야 한다는걸 알 수 있게 되었습니다. 그럼 BlinkC가 사용 하는 인터페이스를 분석 하도록 하겠습니다. BlinkC가 사용 하는 인터페이스는 Timer,Leds,Boot가 있습니다.

tos/interfaces/Boot.nc:
interface Boot {
  event void booted();
}

tos/interfaces/Leds.nc:
interface Leds {

  /**
   * Turn LED n on, off, or toggle its present state.
   */
  async command void led0On();
  async command void led0Off();
  async command void led0Toggle();

  async command void led1On();
  async command void led1Off();
  async command void led1Toggle();

  async command void led2On();
  async command void led2Off();
  async command void led2Toggle();

  /**
   * Get/Set the current LED settings as a bitmask. Each bit corresponds to
   * whether an LED is on; bit 0 is LED 0, bit 1 is LED 1, etc.
   */
  async command uint8_t get();
  async command void set(uint8_t val);
 
}

tos/interfaces/Timer.nc:
interface Timer
{
  // basic interface
  command void startPeriodic( uint32_t dt );
  command void startOneShot( uint32_t dt );
  command void stop();
  event void fired();

  // extended interface omitted (all commands)
}

Looking over the interfaces for Boot, Leds, and Timer, we can see that since BlinkC uses those interfaces it must implement handlers for the Boot.booted() event, and the Timer.fired() event. The Leds interface signature does not include any events, so BlinkC need not implement any in order to call the Leds commands. Here, again, is BlinkC's implementation of Boot.booted():

apps/Blink/BlinkC.nc:
  event void Boot.booted()
  {
    call Timer0.startPeriodic( 250 );
    call Timer1.startPeriodic( 500 );
    call Timer2.startPeriodic( 1000 );
  }

그럼 여기서 BlinkC가 꼭 구현해야 하는 이벤트는 어떤것이 있을까요? 위에서 보면 알 수 있으시겠지만.
여기서 구현해야 하는 Event는 Boot.booted() Timer.fired() 이벤트가 있습니다.그럼 BlinkC가 구현 하고 있는 Boot.booted() 이벤트를 보도록 하죠.

apps/Blink/BlinkC.nc:
  event void Boot.booted()
  {
    call Timer0.startPeriodic( 250 );
    call Timer1.startPeriodic( 500 );
    call Timer2.startPeriodic( 1000 );
  }

BlinkC는 세개의 타이머 객체를 사용하고 있으며, booted() 이벤트는 세개를 시작 시키는 역활을 하고 있습니다. startPeriodic 은 타이머를 시작 시키며, ()안의 숫자는 MillicSecond를 의미합니다.(<TMilli> 객체 생성시 결정) ()안의 숫자와 객체 생성시 정해진 단위로 타이머는 발생됩니다.

call이란 키워드는 command를 실행 할때 쓰며, 역으로 이벤트 전달시에는 signal을 사용합니다. 일단 BlinkC에는 없으니 넘어가도록 하겠습니다.

 event void Timer0.fired()
  {
    dbg("BlinkC", "Timer 0 fired @ %s.\n", sim_time_string());
    call Leds.led0Toggle();
  }
 
  event void Timer1.fired()
  {
    dbg("BlinkC", "Timer 1 fired @ %s \n", sim_time_string());
    call Leds.led1Toggle();
  }
 
  event void Timer2.fired()
  {
    dbg("BlinkC", "Timer 2 fired @ %s.\n", sim_time_string());
    call Leds.led2Toggle();
  }

앞에서 언급 한것 처럼 이벤트의 처리는 사용자에서 하도록 되어있으므로 위와 같이 BlinkC에서 Timer.fired() 이벤트를 처리 해야 합니다. 그리고 함수의 선언은 interface.function 식으로 구분을 확실히 해야 합니다.