TinyOS Tutorial Lesson 1 : Getting Started with TinyOS and nesC (Hanback’s zigbeX & TinyOS ver.1.1.7) 수정. TinyOS ver 1.1.11에선 오동작 가능성이 있으므로, ver 1.1.7을 설치하셔야합니다. 안녕하세요. 자료 만든이 김현수입니다. (이 자료는 한백 zigbeX용으로 만들어 집니다.) 제가 USN 개념에 대해서 아직 2주일 밖에 안 된 상태에서 시작하는 것이라 미흡한 점이 많더라도 이해해 주셨음 합니다. (뿐만 아니라 부끄럽긴 하지만 아직 MCU를 아직 유재석으로 밖에 모르고 있습니다. ㅡ_ㅡㅋ) 이 자료는 순수하게 좀 더 쉽게 배우거나 접근할 수 없을까? TinyOS 배우고 nesC도 알아야 하는데… Tutorial에는 뭔 Lesson이 1~8까지 있는데 왜 그렇게 해 놓은거야? 아.. 이거 못해 먹겠넹. 막막하넹.. 답답해. 우우우악~ 모얌~ 짜증나~ 이러시는 분들께 조금이나마 도움이 되셨음 합니다.(아니.. 제가 지금 그렇습니다.) 이 자료는 제가 세미나용으로 만든 자료이기 때문에 그냥 번역 안하거나 두리뭉실 넘어가는 부분이 다소 있는데, 부족한 부분은 직접 소스를 찾아가면서 확인해 보시기 바랍니다. 참고로 현재 폴더 포함 하위 폴더내에 존재하는 파일내에서 특정 문자를 찾고 싶을때는 < find . | xargs grep –nr 특정 문자 > 위와 같이 해주면 찾을 수 있습니다. 참고로 … source insight 와 같은 프로그램을 통해서 쉽게 특정 문자(함수명) 찾을 수도 있습니다. 그럼 시작하겠습니다. 어려운 부분이나 모르는 부분은 http://cafe.naver.com/bluegio 까페를 참고하시면 좋은 정보 얻으실 수 있습니다. ※ 공부 자료로 슬라이드 노트 프린트해서 보시면 편리합니다. Embedded System Lab. 2007. 1. 11 HyounSoo. Kim

Contents 1 Introduction to TinyOS 2 Installation and Configuration - zigbeX 3 Example : Blink ① Introduction to Blink ② Main & RealMain Component ③ Blink Component ④ SingleTimer Component 먼저 Lesson1을 진행하기 위한 목차입니다. 간단하게 TinyOS가 뭔지 알아보고 실제로 한백전자의 zigbeX(이건 … 그냥 제품 이름인듯.. ㅡ_ㅡㅋ)를 만들기 위한 환경을 구현하기 위해서 Windows에 환경을 구축하는 방법을 알아봅니다. (그냥 TinyOS 알고 싶은 분은 시뮬레이터로 하면 되니깐 장비 없어도 됩니다. 하지만, 똑같이 실행 되더라도 있는게 뭔가 느낌이 잘 옵니다.) 그리고 실제로 C를 배울때 처음에 Hello.c를 배우듯 여기서는 처음 예제로 Blink를 배웁니다. 딱 보니 느낌이 오나요? 그냥 장비에 LED 하나 껌뻑거리도록 하는겁니다. Hello World 찍는 기분으로 그냥 따라하시면 됩니다. 개념을 알고 들어가면 더욱 좋지만… 이 자료의 목적상 그냥 쉽게 따라가면서 배워보자이기 때문에 그냥 이거 보시면서 따라 오시면 되겠습니다. Blink 예제에 대해 간단히 소개하고 이 녀석이 어떻게 생겨 먹었는지 전체적인 흐름은 어떻게 돌아가는지에 대해서 알아봅니다. 그리고 이제 세부적으로 볼건데 가장 먼저 실행되어진다고 생각되어지는 C언어에서 처럼 Main 부분에 관해 알아보고, Blink가 실제 하는 일이 뭔지 module을 통해 알아보고 그에 부가적으로 실행되는 SingleTimer의 역할도 알아보겠습니다. 그리고 마지막으로 작성되어진 프로그램이 제대로 동작하는지 TinyOS용 시뮬레이터 TinyViz를 실행하는 방법을 알아보고, 실제로 이미지를 Fusing 하는것까지 알아보도록 하겠습니다. 4 TinyOS Simulation - TinyViz 5 Fusing the application - PonyProg2000

1. Introduction to TinyOS (1 of 4) What is TinyOS? An operation system An open-source development environment A programming language and model (NesC) A set of services Main Ideology HURRY UP AND SLEEP!! Sleep as often as possible to save power High concurrency, interrupt driven (no polling) Data Memory Model Static Memory allocation Global variables(global) Local variables(stack) : Declared within a method 일단 예제부터 막 시작하면 좋긴하지만, 그래도 정말 아무것도 모르고 들어가면 골 아픕니다. 그래도 조금은 알고 들어가는게 좋습니다. 그럼 우선…. TinyOS란 무엇일까요? OS라구요? 예~ 당연히 이름에 OS가 붙어 있으니깐 운영체제입니다. 근데 Tiny가 접두어로 붙어 있으니 쪼매난 운영체제를 말하는 겁니다. 그래서 실제로 컴파일된 이미지를 보면 엄청나게 작다는것을 알 수 있습니다. 이 TinyOS는 오픈소스로 제공되며, NesC라는 C언어에다가 구조적인 개념이 담긴 컴포넌트들이 서로 연관 있는 인터페이스들로 연결 되어져서 돌아가도록 구성되어집니다. TinyOS에 있어서 가장 큰 목표라 함은 바로 “얼른 자기 할 일 끝내 버리고 잠자기“ 입니다. 그래야지 전기를 아껴 오래 사용하고 효율적으로 쓸 수가 있죠.(Hurry up and Sleep ㅡ_ㅡㅋ) 그래서 고수준의 동시성(차후에 설명)을 지니고 있을 뿐더러 하드웨어적 인터럽트의 발생으로 생기는 이벤트에 대해서 최대한 빨리 후딱 일을 처리하고 또 얼른 잠자기 모드로 들어갑니다. 즉 원래 주기적으로 자기 일 하는 Task(타임 tick 같은 경우)의 개념이 있고, 센서처럼 언제 갑자기 일어날지 모르는 비동기적인 움직임을 잡는 Event 개념이 존재합니다. 데이터를 위한 메모리 구조를 보면 무조건 고정된 메모리 공간을 쓰는 방식으로 동적할당이나 포인터에 의한 연산에 대한 개념 자체가 사용되지 않습니다. 전역 변수가 들어가는 공간이 따로 있고 함수(메서드) 내에서 선언된 지역변수는 스택에서 사용되는 방식으로 데이터 들이 사용됩니다. Stack Free 4KB Global

1. Introduction to TinyOS (2 of 4) Programming Model Separation of construction and composition Programs are built out of components Each component is specified by an interface Provides “hooks” for wiring components together Components are statically wired together based on their interfaces : Increases runtime efficiency Components Components use and provide interfaces, commands and events Specified by a component’s interface The word “interface” has two meanings in TinyOS Components implement the events they use and the commands they provide 프로그래밍 방법은 객체지향적인 방법과 유사합니다. 그냥 간단히 설명하자면 컴포넌트끼리 어떻게 연결되어져서 작동 되어질지 설계한 뒤, 그 설계에 맞게끔 해당 컴포넌트의 동작을 소스로 작성해 주게 됩니다. 그래서 TinyOS에서 말하는 프로그램은 컴포넌트들이 모여서 이루어 지는 겁니다. 각각의 컴포넌트는 인터페이스를 통해 그 관계를 맺을 수가 있습니다. 그러니깐 프로그램 흐름상 다른 컴포넌트와 연관성이 있을 관계를 경우 맺어 줘야 하는데 이런 작업을 인터페이스를 통해서 Wiring(연결) 시켜 주는 것입니다. 이때 컴포넌트들은 해당 컴포넌트가 인터페이스 들에 기초하여 정적으로 서로 Wiring을 시켜주게 되고, 이 때문에 운용 효율성이 증대될 수 있습니다. 아까전부터 컴포넌트, 컴포넌트 하는데 그럼 Component는 뭘까요? 이 녀석은 쉽게 생각하면 개념 덩어리입니다. 실제로 무언가를 하기 위한 개념이 들어갑니다. 컴포넌트는 다시 Configuration과 Module로 크게 두가지로 나누어지는데, 이때 Configuratuion은 현재 컴포넌트의 개념을 수행하기 위해 필요한 다른 개념들에 대해서 Wiring(연결)을 시켜주는 역할을 담당하고, Module은 실제로 개념을 실천하기 위한 구현 부분(소스)이라 생각하면 됩니다. 이때 각각의 컴포넌트를 Wiring 해 줄때 좀 더 구체적으로 명시해 줄 필요가 있습니다. 뭘 통해서 연결해 줄 것인지 그것을 표현해 주어야 합니다. 이게 인터페이스 입니다. 예를 들어서 장치 초기화를 위한 연결이라면 보통 Init();란 함수가 사용될텐데… 일반적인 제어용으로 쓴다면 이때 StdControl 인터페이스를 불러와 컴포넌트에 붙여서 사용하면 됩니다. 일단 개념만 알고 자세한건 예제때 다시 만나 보도록 하죠.

1. Introduction to TinyOS (3 of 4) Types of Components There are two types of components: Modules: Implement the application behavior Configurations: Wires components together A component does not care if another component is a module or configuration A component may be composed of other components TinyOS Thread Model Tasks: Time flexible Longer background processing jobs Atomic with respect to other tasks (single threaded) Preempted by events 그래서 크게 Component는 두 가지로 나누어 구분 지을수 있습니다. 첫째 Configuration은 컴포넌트이 서로 연결되어지는 관계를 기술하는 것이고, 둘째 Module은 실제 프로그램에서 해당 Component에서의 동작을 구현해 놓은 것입니다. 쉽게 생각해서 “소스 작성은 Module에다가 한다”라고 생각하시면 됩니다. 여기서 작성된 하나의 Component는 다른 Component의 Module이나 Configuration에는 관여하지 않지만, 다른 컴포넌트에 기반하여 작성되어질 수는 있습니다. 이때 Component간에 Wiring 해주기 위해서 Configuration을 작성할 때에는 Interface를 통해서 연결해 준다고 했는데, 해당 Interface가 현재 Component를 다른 Componet로 제공(provides)하는 역할인지, 아니면 다른 Component에서 뭔가 발생된 걸 감지하여 현재 Component에 사용(uses)하는 역할인지, 아니면 단순히 다른 Component의 Interface와 연계되어 그대로 똑같은 입장에 놓고 사용 할 것인지, 그 관계에 대해서 명확하게 잘 기술(Specified)해 줘야합니다. 그리고 TinyOS는 쓰레드 모델입니다. TinyOS의 경우 Taks들과 Hardware Event Handler들로 구성되어 집니다. 이 OS의 경우 각 태스크에 고유한 우선순위가 부여된 것은 아니지만, 자기 할일 다해야 끝나는 시간에 유연한 태스크로 돌아가게 됩니다. 이때 태스크들의 경우 태스크끼리는 선점이 일어나지 않습니다. 하지만, Event들에 의해서 선점이 일어날 수 있습니다. 그리고 전역변수를 사용하다 보니 다른 태스크에 의해서 간혹 문제가 발생할 수 있는데 이때는 Atomic을 통해서 임계영역을 꾸며 놓꼬 써야 합니다. 이런 원칙을 준수하지 않으면 컴파일러가 알아채고 에러 메시지를 출력합니다.

1. Introduction to TinyOS (4 of 4) TinyOS Thread Model Events: Time critical, Interrupt task Shorter duration (hand off to task if need be) Last-in first-out semantics (no priority among events) Component Hierarchy Components are wired together by connecting users with providers Forms a hierarchy Commands: Flow downwards, Control returns to caller Flow upwards, Control returns to signaler Events can call Commands but not vice versa 이벤트는 태스크와는 달리 언제 발생할지 모르는 그야말로 전방지축 같은 녀석입니다. 갑자기 빛이 들어와서 조도 센서가 “야 빛 들어온다~ 근데 빛이 좀 많이 쎄네~” 요런 아름다운 일을 눈치채고 끼어 드는 녀석이 바로 Event입니다. 이 Event는 Task를 선점하여 사용되기도 하기 때문에 되도록이면 최소한의 시간동안 빨리 그에 대한 작업을 마쳐주는게 서로간의 예의입니다. 그래서 실행구조를 보면 Task들은 먼저 들어온 것부터 차례대로 처리하는 FIFO 구조이고, Event에 관한건 나중에 들어온게 오히려 당장 처리되는 LIFO 구조를 가집니다. 이 Event들도 역시 우선순위가 없기 때문에 그냥 LIFO 구조로 돌아갑니다. 컴포넌트들은 그 역할에 따라서 계층별로 구분 됩니다. 보통 인터페이스를 통해 무언가를 제공하는 컴포넌트 들이 하위에 위치하며, 뭐해라 뭐해라 명령을 하는 쪽이 상위에 들어가게 됩니다. 그래서 차후에 Blink의 Overall을 보시면 아실테지만,(차후 Docs로 확인 가능) Component의 상단에 위치한 Interface는 Provide를 위한 Interface이고, 하단에 위치한 Interface가 Uses를 위한 Interface가 됩니다. 이때 하위 Component에다가 뭐 하라고 지시를 내리는 걸 Command, 하위 Component에서 발생되는 신호에 대해 상위 Component로 올리는 신호에 대해서 Event라고 합니다. 이때 Event들은 Command들에 의해 불려져 사용되어 질 수 있지만, Command가 Event로 인해 불려져 사용되는건 불가능합니다. (예를 들면 1초마다 Tick Event(fired();)를 발생시키라고 Command를 주는 행위) 여기까지 TinyOS에 대해서 간략하게 알아보았습니다. 제가 2주간 Blink만 보며 느낀것이라 이게 다는 아닐꺼 같지만 아마 크게 벗어나지 않을겁니다.

2. Installation and Configuration - zigbeX (1 of 2) Download TinyOS from : http://www.tinyos.net/dist-1.1.0/tinyos/windows/ This Version 1.1.7 (or whatever is the latest) Version release notes available here: http://www.tinyos.net/tinyos-1.x/doc/ The install puts TinyOS in C:\Program Files\UCB\ TinyOS is installed C:\Program Files\UCB\cygwin\opt\tinyos-1.x Patch the Hanback zigbeX Connect the Hanback Webpage - http://www.hanback.co.kr Login  다운로드  유비쿼터스 센서 네트워크 ZigbeX 프로그램 Version 1.3  다운로드 hanback_zigbex_ProgramV1_3.zip C:\Program Files\UCB\cygwin\opt\ 폴더에 압축을 풀어서 복사 Cygwin 실행해서 \opt\폴더로 이동 후 Install.sh 실행  ./install.sh 그럼 이제 한백전자의 zibeX를 위한 설치를 해보겠습니다. 우선 Windows XP에 설치를 하는 겁니다. (이미 Cygwin 설치 되어 있으면 다 지워주세요) 제가 Test해 본 결과 TinyOS 1.1.7 이전 버전에서는 zigbeX가 정상적으로 설치되지 않기 때문에 반드시 1.1.7 이상의 버전을 사용하셔야 합니다. 그렇다고 TinyOS 2.0을 설치하시면 곤란합니다. 저 말고… 한백전자 입장에서 ㅡ_ㅡㅋ 설치 방법 위에 나오는 그대로 하면 됩니다. 친절하게 사이트 주소까지 링크 걸어주는 센스 모든게 귀찮아 하실분들을 위해 그냥 누르면 다운이 됩니다.(아니면 제가 나중에 못 찾음) 아래 보면 버전에 따른 Doc 있다는데…. 영어 투성이인지라.. 저는 안좋아합니다. 패스~ 그리고 인스톨 경로는 C:\Program Files\UCB\로 해줍시다. 간혹 C:\TinyOS\ 이렇게 하자고 칭얼거리는데… 보통 위의 방식으로 많이 깔더군요. 그리고 다운 인스톨 해주면 좀 걸리지만 다 설치가 됩니다. Install done. 이런 메시지박스가 뜰테니 느긋하게 기다려 줍니다. 다 설치 하면 이제 zigbeX 플랫폼으로 컴파일 하기 위한 파일을 설치합니다. 한백전자꺼니깐 한백전자 홈피에 가면 구할 수 있습니다. 방법은 위에 나온 그대로 하시면 됩니다.

2. Installation and Configuration - zigbeX (2 of 2) Customizing the Environment Add aliases to C:\Program Files\UCB\cygwin\etc\profile alias cdjava="cd /opt/tinyos-1.x/tools/java" alias cdtos="cd /opt/tinyos-1.x/tos" alias cdapps="cd /opt/tinyos-1.x/apps“ The make System From within the application’s directory: make (re)install.<node id> <platform> <node id> is an integer between 0 and 255 <platform> may be zigbeX, mica2, mica2dot, or all make <platform> docs Generates documentation in <tos>/doc/nesdoc/<platform> make pc Generates an executable that can be run a pc for simulation make clean 이번 장은 좀 쉽게 사용해 보고자 약간의 꼼수를 부려보는 겁니다. 솔직히 환경변수 설정하는게 좀 더 좋은 방법 같은데, 여기서는 별명 짓기 쓰네요. 매번 Cygwin 실행할때마다 자동으로 별명이 지어지도록 C:\Program Files\UCB\cygwin\etc\profile의 하단에 3가지 위 별명 짓는 명령을 추가해 주면 됩니다. cdajava는 java 실행을 위한 명령어가 있는 폴더로 이동하기 위한 단축어가 되고, cdtos는 TinyOS의 각종 라이브러리라 할 수 있는 컴포넌트 소스가 있는 곳이고, Cdapps는 TinyOS를 위한 예제가 다량 함량되어 있는 곳입니다. 저런 설정을 하고 나면 손 쉽게 폴더 이동이 가능합니다. 그리고 실행 이미지를 만들기 위한 make 방법은 다음과 같습니다. make <platform>이라고 하면 실제 Top Level의 Component를 찾아서 (이때 Top Level의 Component의 Confiuration은 마지막에 Component를 뜻하는 C가 빠져 있습니다. 따라서 Blink 예제는 BlinkC.nc가 Blink.nc가 됩니다.) 실제적인 컴파일을 시작하고 C언어 형태로 먼저 소스를 바꾸어 준후, 실행이미지를 생성하게 됩니다. make zigbeX로 하면 실제 mote에 넣을 이미지를 만드는 것이고, make pc라 하면 PC상에서 java 시뮬레이터를 통해 가상적으로 확인이 됩니다. make pc docs라면 각 컴포넌트간의 관계에 대한 문서를 만드는데, 이걸 보면 어떻게 컴포넌트들간에 연결되어져서 동작되는지 확인이 가능합니다.

3. Example : Blink ① Introduction to Blink (1 of 2) "Blink" found in apps/Blink in the TinyOS tree. 1Hz 간격으로 모트의 빨간 LED Toggle(On and Off) Blink application is composed of two components: configuration : “Blink.nc” Blink 프로그램에서 컴포넌트 간의 전체적인 흐름을 이어주는 역할 module : "BlinkM.nc" 실질적인 Blink 프로그램에 대한 구현을 제공한 모듈 드디어 첫 예제 실습입니다. 두서가 상당히 길었습니다. 예제는 TinyOS가 설치된 폴더의 apps/Blink라는 곳에 위치해 있습니다. 1초마다 빨간 LED가 깜빡거리도록 만드는 예제입니다. 실제 디렉토리를 확인해 보면 2개의 Component가 보입니다. Blink Component들이 있고, SingleTimer Component들이 있습니다. 모든 Component들은 configuration과 module 이렇게 두 개씩 구성되는데, 실제로 그렇게 파일이 두개씩 나눠어져서 구성되어져 있음을 알 수 있습니다. 그리고 각 구성에 대한 간략한 설명이 위에 나와져 있습니다.

3. Example : Blink Overview ① Introduction to Blink (2 of 2) RealMain StdControl HardwareInit Pot HPLPotC HPLPot PotM PotC HPLInit Init Main BlinkM Timer Leds LedsC SingleTimer TimerC TimerM Clock PowerManagement NoLeds ClockC HPLPowerManagementM HPLClock Component Interface(uses) Interface(provides) 아~ 이것이 노력의 결정체 입니다. … 약간의 거짓이 들어가 있을지도 모릅니다만… 거의 맞을겁니다. ㅡ_ㅡㅋ 실제로 make docs pc를 통해서도 이런 전체적인 흐름을 볼 수 있습니다. 바로 apps.Blink.Blink.nc.app.html 이 문서를 열어보면 전체적인 흐름에 대한 각 Component간의 Wiring 상태를 확인할 수 있습니다. Index.html을 통해서 이 프로그램에 사용된 각 Component의 관계 및 기능에 대해 알아 볼 수 있고, 실제 파일의 위치도 알 수 있습니다. 프로그램의 이해를 위해서는 한번식 학습하는게 좋습니다. 우선 순서도처럼 위에서 아래로 흘러가듯이 실행되어진다고 생각하면 됩니다. 실제로 Blink 예제는 Main, BlinkM, LedsC, SingleTimer Component 4개를 사용한다고 했지만, 내부적으로는 각 Component들의 Configuration을 통해 위와 같이 막 꼬이고 꼬여서 저렇게 연결되어지게 됩니다. 바로 이렇게 Component들이 Wiring 되어 구현되는 프로그램이 TinyOS입니다. 여기서 파란 부분이 Component를 말하고, 약간 녹색 희끄무리한 부분이 Interface입니다. Component 상단에 붙은 Interface는 provides 역할을 하는 것이고, Component 하단에 붙은 Interface는 uses 역할을 하는 겁니다. 비록 LED 하나 켰다가 껐다가 하는 예제이긴 하지만 이런 구조를 가지고 동작이 되어진다는거에 대해서 알면 좀 더 이해가 쉬울거 같습니다. 이제부터 실제로 어떤 순서로 프로그램이 동작되는지 첫 예제이니만큼 되도록 간단하게 살펴 보도록 하죠~

3. Example : Blink RealMain Main.nc tos/system/Main.nc ② Main & RealMain Component RealMain Main.nc tos/system/Main.nc TinyOS application에서 맨 처음 수행되는 콤포넌트 Main.StdControl.init() 이 최초로 호출되고, 다음에 Main.StdControl.start() 가 실행된다. configuration Main { uses interface StdControl; } implementation { components RealMain, PotC, HPLInit; StdControl = RealMain.StdControl; RealMain.hardwareInit -> HPLInit; RealMain.Pot -> PotC; ※ TinyOS는 3계층 구조(Hardware Abstraction Architecture – HAA)를 가진다. - HPL : Hardware Presentation Layer - HAL : Hardware Abstraction Layer - HIL : Hardware Independent Layer RealMain StdControl HardwareInit Pot HPLPotC HPLPot PotM PotC HPLInit Init Main 먼저 Main 부분을 보죠~ 컴퓨터에서 돌아가는 모든 프로그램은 시작하는 부분이 정해져 있습니다. C언어의 경우 main함수, java도 main함수, 심지어 이 nesC도 main에서 시작합니다. 단, TinyOS를 위한 nesC Language는 컴포넌트 개념에서 출발해야 한다는 것이죠. 그래서 Top level Component의 Configuration을 들여다 보면 항상 Component를 기술할 적에 Main 컴포넌트를 사용한다고 명시해 주게 됩니다. 그래서 실제적으로 프로그램이 시작하면 Main 컴포넌트에서 시작하게 되는데, 보는바와 같이 Main 컴포넌트는 RealMain이라는 별도의 컴포넌트에 Wiring 되어져 있음을 확인할 수 있습니다. 왜 이렇게 되어져 있을까요? 이건 제 생각이긴 한데, 초기화를 위해서 사용되는것 같습니다. TinyOS 프로그램은 mote와 같은 장비에 펌웨어를 업로드 해주는 식으로 사용하게 되는데, 이런 장비를 사용하기에 앞서서 이걸 쓸 수 있도록 뭔가 환경을 마련해 주어야 하는데 그걸 위해서 사용되어지는 것이 바로 RealMain에서 해 주는것 같습니다. 실제로 하는 일을 보더라도 HPLInit Component를 통해서 가장 Low Level(Hardware쪽)에 관련된 기능을 초기화 시켜 주게 됩니다. 그리고 Pot의 경우 퍼텐셔엄엍어(ㅡ_ㅜ 발음이… 좀.. 글네요.)의 약어인데 이 녀석 역할이 무선 신호를 낮게 조정해서 수명을 오래가게 할지(소비전력↓), 아니면 그 반대로 설정할지 그런 기능을 초기화 시켜주는 역할인것 같습니다.

3. Example : Blink Blink.nc Interface StdControl ③ Blink Component (1 of 3) Blink.nc configuration Blink { } // no external interfaces implementation { components Main, BlinkM, SingleTimer, LedsC; Main.StdControl -> BlinkM.StdControl; Main.StdControl -> SingleTimer.StdControl; // multiple BlinkM.Timer -> SingleTimer.Timer; BlinkM.Leds -> LedsC; // implicit } Main StdControl BlinkM Timer Leds LedsC SingleTimer Interface StdControl tos/interfaces/StdControl.nc init(): 초기화될 때 start(): 최초로 실행될 때 stop(): 실행이 중지될 때 interface StdControl { command result_t init(); command result_t start(); command result_t stop(); } Main Component가 시작하는데 앞장에서 본바와 같이 Wiring만 해주었습니다. 하지만 실제로는 Main Component가 시작됨과 동시에 시작되는게 있으니 그것이 바로 표준 제어 인터페이스인 StdControl Interface입니다. 화면 우측하단에 보시는 바와 같이 총 3개의 함수로 구성되어져 있고, 실제 프로그램 시작과 동시에 Main.StdControl.Init()이 실행되고, Init()가 끝남과 동시에 Main.StdControl.Start()가 실행이 되고, 프로그램을 멈추는 신호에 맞추어 Main.StdControl.Stop()이 실행되나 봅니다. (제가 2주일째 공부중이라 정확하다고 확언을 드리긴 그렇고, 조언 받거나 수정하면서 확정되면 이런 멘트들은 지워집니다.) 그래서 실제 Main의 StdControl이 시작되면 각 함수를 시작시켜주는데, 실제로는 Wiring을 해 주었기 때문에 하위의 컴포넌트인 BlinkM과 SingleTimer Component에 있는 StdControl이 함께 수행되어 집니다. 즉 Main에서 StdControl이 명령(Command)을 준 것이기 때문에, 하단의 두개의 Component에서 실제 각 함수에 대한 코드가 구현되고 실제로 구현되어진 코드가 동작되기 시작합니다. 게다가 BlinkM으로 이어진 Component가 다시 LedsC와 이어지고 있고, Timer Interface를 통해서는 SingleTimer와 다시 이어지고 있습니다. 이번 페이지에서는 프로그램을 실행시키기 위한 Blink Component의 구성인 Configuration에 대해서 알아봤고, 다음 페이지에서 실제적인 Blink Moudle이 하는 일에 대해서 알아 보겠습니다. StdControl init start stop

3. Example : Blink BlinkM.nc provides: uses: ③ Blink Component (2 of 3) BlinkM.nc module BlinkM {     provides { // BlinkM이 구현   interface StdControl;   }     uses { // 인터페이스를 제공하는 모듈이 구현     interface Timer;     interface Leds;   } } implementation {   command result_t StdControl.init() {       call Leds.init();      return SUCCESS;   }   command result_t StdControl.start() {       return call Timer.start(TIMER_REPEAT, 1000) ;   }   command result_t StdControl.stop() {       return call Timer.stop();   }   event result_t Timer.fired()   {       call Leds.redToggle();       return SUCCESS;   } Main StdControl BlinkM Timer Leds LedsC SingleTimer BlinkM에서 M은 moudle 즉 실제 구현이 되는 부분이라 생각하시면 됩니다. BlinkM의 경우 Main Component를 통해서 Command 되어진 StdControl Interface를 통해서 BlinkM.StdControl.init() 안에서서 다시 하단에 있는 LedsC에다가 Leds Interface를 타고 내려가면서 LED를 초기화 시켜주고, BlinkM.StdControl.start()에서는 Timer Interface를 통해 SingleTimer에게 1초 간격으로 반복적으로 Tick을 발생시키라는 명령을 보내게 됩니다. BlinkM.StdControl.stop()이 발동하면 Timer Interface를 통해 동작중인 Timer에 관해 정지시키는 Stop()하라는 함수를 호출해 주게 되고, 실제적으로 Timer Interface를 타고 하단 컴포넌트에서 1초 간격으로 반복적으로 1초가 흘러갔음을 알려주는 fired()함수가 발생되어 오는 신호에 대해거 Leds 인터페이스를 통해 Red LED를 Toggle 시켜 줍니다. 즉 껐다 켰다 이렇게 왔다리 갔다리 하게 하는 것이죠. 이런 가장 핵심적인 일련의 프로그램의 내용은 이 프로그램의 핵심이라할 수 있는 Module은 BlinkM.nc 파일에 담겨져 있습니다. 이때 상단의 Component에 뭔가 자기 것을 사용하게 해주기 위해서 Interface를 provides하고, 하단의 Component에 있는 뭔가를 사용하게 해주기 위한 Interface를 uses라고 합니다. provides: Implements the StdControl interface. uses: Timer와 Leds가 제공하는 command를 호출할 수 있다. Timer와 Leds가 제공하는 events를 구현하여야 한다.

3. Example : Blink Interface Leds interface Leds { ③ Blink Component (3 of 3) Interface Leds interface Leds { async command result_t init(); async command result_t redOn(); async command result_t redOff(); async command result_t redToggle(); // 현재 상태와 반대 async command result_t greenOn(); async command result_t greenOff(); async command result_t greenToggle(); async command result_t yellowOn(); async command result_t yellowOff(); async command result_t yellowToggle(); async command uint8_t get(); // 3비트의 값을 읽음 async command result_t set(uint8_t value); // 3비트의 값으로 설정 } Main StdControl BlinkM Timer Leds LedsC SingleTimer BlinkM 하단에 위치한 LedsC 컴포넌트에 연결되는 Interface인 Leds의 경우 LED를 제어하기 위한 다양한 함수를 제공하고 있다. 위 화면에서와 같이 Command 명령을 통해서 해당 함수를 상단의 Component에서 하단의 Component로 전달시켜 줄 수 있다. 이때 이 명령을 위한 함수들은 정해진 시간에 맞추어 동작하는 것이 아니라 임의의 시간에 갑자기 발생할 수 있기 때문에 async라는 키워드를 앞에 붙여줘서 이 명령이 비동기화된 명령임을 명시해 주게 된다. 여러가지 기능 중 현재의 LED 상태 값을 읽어올때 get()함수만이 유일하게 Return 형으로 Unsigned Int 8bit 값을 다시 받게 되는데, 이것은 3개의 LED를 사용함에 있어서 1Byte만으로도 충분히 다 제어가 가능하므로 Unsigned Int 8 Bit를 사용하는 것이다.

3. Example : Blink SingleTimer.nc TimerC configuration SingleTimer { ④ SingleTimer Component (1 of 2) SingleTimer.nc configuration SingleTimer { provides interface Timer; provides interface StdControl; } implementation { components TimerC; Timer = TimerC.Timer[unique("Timer")]; StdControl = TimerC; SingleTimer Timer StdControl TimerC TimerM Timer[id] Leds Clock PowerManagement NoLeds ClockC HPLPowerMangementM HPLClock TimerC configuration TimerC { provides interface Timer[uint8_t id]; provides interface StdControl; } implementation { ... } SingleTimer Component의 경우 내부적으로 선언되어져 있는 Timer Component를 사용하기 위해서 만들어진 사용자 정의 Component이다. 따라서 BlinkM 모듈과 더불어서 현재 Blink 예제에서 따로 기술해주어야 한다. 먼저 Configuration을 통해서 실제적으로 시간에 관련된 작업을 할 Component이므로 TimerC Component와 관계를 맺게 되고 실제로 Timer와 StdControl Interface를 TimerC Component와 공유하여 사용됨을 구현해 준다. 이때 Timer Interface로 연결해 줄 때 Timer Component가 다수의 Timer Interface를 사용할 수 있기 때문에 배열처럼 나누어서 고유 id를 통해 연결될 수 있도록 설정을 해주게 된다. (Timer Component에서 Interface로 Timer[id]형태로 제공한다.) 그럼 실제적으로 Main Component를 통해 들어온 StdControl에 관한 command 작업이 그림과 같은 Wiring을 통해서 TimerM이라는 Module에서 실질적으로 구현되고, BlinkM Module을 통해 들어온 Timer에 관한 Command 작업 역시 TimerM이라는 Module에서 실질적으로 구현이 되어진다는 것을 확인할 수 있다. 그 아래에도 부지기수로 막 달려 있는 Component들이 있는데, 처음부터 다 들어가면 복잡해 지니깐 그냥 그런게 붙어 있나보다라고 생각하고 넘어가도록 하고, 솔직히 다 알아야지 도저히 이거 안되겠다 싶은 분들은… 아래에 있는 Component를 확인해 보고 알려주시면 저도 공부하는데 참고하도록 하겠습니다. ㅡ_ㅡㅋ

3. Example : Blink Timer Interface two types of timer ④ SingleTimer Component (2 of 2) Timer Interface includes Timer; interface Timer { command result_t start(char type, uint32_t interval); command result_t stop(); event result_t fired(); } SingleTimer Timer StdControl TimerC TimerM Timer[id] Leds Clock PowerManagement NoLeds ClockC HPLPowerMangementM HPLClock start stop fired Timer two types of timer TIMER_REPEAT TIMER_ONE_SHOT Interval (miliseconds) 시간이 지나면 fired event 발생 event는 사용자(uses) 측에서 구현 그럼 여기서 TimerM에 연결되어지는 Interface인 Timer는 어떤 기능을 할까요? (구미 사투리로 가끔씩 ‘~요’자를 붙입니다.) 위에 그림에서와 같이 start(), stop()함수를 command로 전달하고 fired()라는 이벤트에 대해서 받을 수 있는 기능을 제공하네요~ 즉 뭔 말인고 하니~ 1Hz 간격으로 계속 Tick을 발생시키는 Timer를 하나 만들어 주시고~ command result_t start(TIMER_REPEAT, 1000); //  단위가 ms 이걸 정지시켜 줄때는 이렇게 사용해 주시고, cmmand result_t stop(); 위에 사용된 Tick 즉 1000ms 만큼 시간이 흘러서 Timer가 다 돌면 끝이나는건데 그 순간에 발생되는 신호가 있으니 그게 fired입니다. 그 신호가 확인 되면, 그것에 관한 신호를 내게 알려주세요~가 바로 event result_t fired(); 입니다. 즉 TimerM에 이런 명령에 대한 구현이 이루어져 있기 때문에 TimerM 상단의 Component에서 Timer Interface를 uses로 사용하면서 위에 언급한 3개의 함수를 쓰면 된다는 이야기 입니다. 단, 사용할때 event result_t fired() 함수는 그에 대한 직접적인 동작을 코딩해주어야 합니다. 즉 상위 Component의 Implemnetation에 직접 해당 일을(Blink 예제의 경우 Red LED가 Toggle 되는겁니다.) 기술해야 합니다.

4. TinyOS Simulation - TinyViz (1 of 2) TinyViz - Java Application Program for TinyOS Simulation Compiling the Blink application Compile cd apps/<application> directiry make <platform> platform: pc, mica, zigbex Output apps/<application>/build/<platform>/ < Cygwin 1: 먼저 실행> $ <directory>/main –gui n csca_cbnu@csca1 /opt/tinyos-1.x/apps/Blink $ build/pc/main –gui 1 // 1개의 mote를 gui 환경에서 test 하기 위해 실행 < Cygwin 2: 나중 실행> $ cd /opt/tinyos-1/tools/java $ java net/tinyos/sim/TinyViz // TinyViz를 java application으로 실행 여기까지 Blink 예제에 대해서 간략히 알아봤고 이제 실제로 이 Blink 예제를 Test 해봐야겠지요. 여기서 소개할 방법은 크게 2가지 방법이 있습니다. 하나는 PC 상에서 Java application인 TinyViz를 통해 시뮬레이션 하는 방법이고, 나머지 하나는 직접 mote에 올려 놓고 실험해 보는 방법입니다. 우선 TinyViz를 통해서 PC상에서 시뮬레이션하는 방법입니다. TinyViz를 설명드리자면, TinyOS로 구동되는 mote의 모습을 PC상에서 간단하게 확인해 보는 프로그램으로 일일이 올려보고 확인하는 번거로움을 줄여줍니다. 먼저 make pc를 통해 PC에서 실행되도록 make를 해줍니다. 그리고 실행파일이 위치한 폴더로 이동을 하여 실행시켜 줍니다. ./main –gui 1 (or make한 위치에서 build/pc/main –gui 1 이렇게 상대경로를 이용해서 실행) Gui 환경으로 Test하기 위해서 –gui 옵션을 붙여 줍니다. 그리고 실제 생성되는 mote의 수를 적어주는데 여기서는 1개만 만들어 줍니다. 그러면 이제 시뮬레이션이 가능한 상태로 들어가게 됩니다. 이제 TinyViz를 실행을 위해 Cygwin을 하나 더 열어줍니다. 원래 java 명령어가 /opt/tinyos-1/tools/java에 있기 때문에 이 폴더로 이동해야 합니다. (환경변수 설정을 통해 PATH 걸어도 되겠지만, 그냥 이렇게 사용하는군요.) 또는 아까 별명 짓기(alias) 사용했으니 cdjava라고 친다면 바로 이동됩니다. 그리고 TinyViz를 실행합니다. java net/tinyos/sim/TinyViz

4. TinyOS Simulation - TinyViz (2 of 2) Running the TinyViz Delay 설정 시작 or 멈춤 mote 그러면 이렇게 화면에 이쁘장하니 Java Application 프로그램인 TinyViz가 실행이 됩니다. 이쁘죠? 사용법은 모릅니다… 아직 이거에 대해서 자세히 메뉴를 본적이 없어서 ^_^; 대신 간략하게 사용방법은 이렇습니다. 빨간 네모박스 3개 보이시죠? 저기서 mote가 있는 박스가 바로 LED3개가 박혀있는 그 mote입니다. 실제로 빨간 LED가 깜빡이는걸 볼수가 있는거죠. Delay 조정을 통해서 시뮬레이션하는 시간을 조정해줄수도 있습니다. 그냥 바 자체를 움직이면 6단위로 움직이고 옆에를 클릭하면 1단위로 움직입니다. 그리고 오른쪽에 시작 정지 버튼이 있습니다. 일단 위 3개만 사용할 줄 알면 시뮬레이션된 결과 확인이 가능합니다. 이런식으로 TinyViz를 사용할 수 있다는 것을 알고 넘어가는게 이번 페이지의 목표입니다~

5. Fusing the application - PonyProg2000 PonyProg2000 Setup I/O port setup  Probe File Open  Fusing 실제로 mote에 올리는 방법입니다. 우선 PonyProg2000을 다운 받아서 설치를 하시고, I/O Port 설정을 위와 같이 한 후 mote를 연결하고 Probe를 통해 연결이 정상적으로 되었는지 확인해 주세요. 그리고 make zigbex 로 컴파일된 main.hex 이미지를 열어 주신후에 (이러면 화면에 hex code가 열리는걸 확인할 수 있습니다.) 이제 구워주면(Fusing) 해주면 됩니다. 도중에 Verifying 인가… 뜨는데… 다 기다릴 필요 없습니다. 10% 넘어가면 중단시켜버리세요. (TinyOS 자체가 용량이 극히 적어서 쓰는데 아주 다소의 시간이 걸리니깐 그 시간만큼의 Verifying만 정상적으로 되면 되는 것이니깐 패스~) 그럼 이제 정상적으로 동작되는 mote르 보면 되겠습니다. 사진 찍을까 하다가… 당장 옆에 사진기가 없어서 이건 생략합니다. 다음 예제 등등~ 해서 손에 사진기가 들려 있으면 첨부하죠~

E N D 이렇게 해서 길다면 길고 짧으면 짧을 수 있는 TinyOS와의 첫 만남이 끝났습니다. 더 이상 읽으실 필요가 없다는거죠~ 흠.. 아직 부족한게 많고 더불어 설명이 안 맞는 부분도 더러 있을것 같습니다. 단지, 이걸 제작한거 자체가 제가 워낙에 이거 개념이 안 잡혀서 이렇게라도 적다보면 좀 더 이해가 되지 않을까 해서 시작했거든요. (원래 가르치는 입장이 되려고 하다 보면 공부가 더 되는 것인듯) 사실 보다 보니 하드웨어적인 제어와 관련된 hardware.h라든지 다수의 소스를 접하다 보니 시간이 많이 길어진 점은 있으나, 연관된 소스를 찾아 가면서 보면서 따라하다보면 더욱 이해가 빠를것 같단 생각이 들었습니다. 처음 공부하시는 분들께선 이거 보시면서 소스도 직접 따라가면서 어떻게 돌아가는지 원리를 알고 공부하시면 더 큰 도움이 될것 같습니다. 그럼 다음번에 다시 또 자료 올리겠습니다. 2007. 1. 12(금)