상세정보

2015년 대한민국학술원 우수학술도서

에이콘 임베디드 시스템 프로그래밍 시리즈. 이 책에서는 임베디드 엔지니어가 성공하기 위해 알아둬야 할 모든 핵심 주제들, 즉 설계와 개발, 프로그래밍, C/C++와 UML 언어, 실시간 운영체제 고려사항, 네트워킹 등을 다룬다. 특히 개정판에서는 리눅스와 안드로이드, 멀티코어와 관련한 새 내용을 추가해 엔지니어가 성공하는 데 필요한 최신의 실전 노하우를 제공한다.

저자 콜린 월즈가 실무에서 얻은 경험과 통찰력을 이용해 임베디드 소프트웨어 개발의 전체 주기, 즉 설계와 개발, 관리, 디버깅 절차, 라이선싱, 재사용을 설명한다. 임베디드 분야에 처음인 초보 엔지니어들은 물론, 기술을 확장하고 싶어 하는 숙련된 엔지니어들을 위해 상세한 팁과 기술, 테크놀로지에 대한 세부적인 설명을 제공한다.

이 책은 폭넓은 범위의 내용을 다루므로 숙련가뿐 아니라 초보자에게도 유용할 것이다. 일반 소프트웨어 개발에 종사하는 사람이라면, 일부 글에서는 하드웨어에 관한 글이라는 느낌도 받을 것이다. 하드웨어 설계 분야에 종사하는 사람이라면 소프트웨어 세계에 대해 이해하게 될 것이다. 교육 현장에서 교재로 사용한다면, 실무든 이론 교육이든 학생들에게 유용한 배경 지식을 줄 수 있을 것이다.

이 책은 임베디드 소프트웨어 개발자가 알아야 할 종합 상식을 다룬다. 즉,임베디드 소프트웨어 개발 시에 고려해야 할 다양한 측면인, 설계와 개발 도구, 프로그래밍 언어, 특히 C/C++에서 고려할 점, 실시간 시스템, 네트워킹, 리눅스나 안드로이드 같은 오픈소스 플랫폼, 최신의 멀티코어까지 매우 광범위한 내용을 다룬다. 또한 임베디드 시스템 개발에서 소프트웨어 개발 방법이 어떻게 발전되어 왔는지에 관한 역사도 엿볼 수 있다.

★ 이 책에서 다루는 내용 ★

임베디드 분야가 커짐에 따라, 개발자가 더 정교한 디바이스에 대한 요구사항을 만족하려면 더 빠르고 더 효율적이며 더 강력한 소프트웨어를 만들기 위해 다양하고 복잡한 주제를 제대로 이해하고 있어야 한다.

이 책에서는 임베디드 엔지니어가 성공하기 위해 알아둬야 할 모든 핵심 주제들, 즉 설계와 개발, 프로그래밍, C/C++와 UML 언어, 실시간 운영체제 고려사항, 네트워킹 등을 다룬다. 특히 개정판에서는 리눅스와 안드로이드, 멀티코어와 관련한 새 내용을 추가해 엔지니어가 성공하는 데 필요한 최신의 실전 노하우를 제공한다.

저자 콜린 월즈가 실무에서 얻은 경험과 통찰력을 이용해 임베디드 소프트웨어 개발의 전체 주기, 즉 설계와 개발, 관리, 디버깅 절차, 라이선싱, 재사용을 설명한다. 임베디드 분야에 처음인 초보 엔지니어들은 물론, 기술을 확장하고 싶어 하는 숙련된 엔지니어들을 위해 상세한 팁과 기술, 테크놀로지에 대한 세부적인 설명을 제공한다.

* 리눅스와 안드로이드, 멀티코어 등 최신 임베디드 소프트웨어 개발 내용 추가
* 각 장을 소개하고 연결 관계를 보여주는 로드맵 제공
* 소스코드와 파워포인트 슬라이드를 통해 유용한 학습 자료와 실전 경험을 제공

★ 이 책의 대상 독자 ★

임베디드 소프트웨어에 관심이 있다면 유용한 내용이 많다. 폭넓은 범위의 내용을 다루므로 숙련가뿐 아니라 초보자에게도 유용할 것이다. 일반 소프트웨어 개발에 종사하는 사람이라면, 일부 글에서는 하드웨어에 관한 글이라는 느낌도 받을 것이다. 하드웨어 설계 분야에 종사하는 사람이라면 소프트웨어 세계에 대해 이해하게 될 것이다. 교육 현장에서 교재로 사용한다면, 실무든 이론 교육이든 학생들에게 유용한 배경 지식을 줄 수 있을 것이다.

★ 이 책의 구성 ★

책에 넣을 자료를 선택하면서 모든 글이 현재 임베디드 소프트웨어 개발 관행과 기술에 연관 있는지를 확인하는 것을 목표로 했다. 물론 많은 글이 역사적인 관점을 다루지만 단독으로는 책에 포함될 만큼 충분하진 않았다. 상당수 글은 현재 기술 유행에 맞지 않거나 다른 새 기술에 의해 대체돼버린 것이어서 제외했다. 내가 만일 『임베디드 소프트웨어 역사』라는 책을 쓰게 된다면 이런 내용들을 포함할 것이다. '이 모든 것의 시작으로부터 50주년이 되는 해(인텔4004가 출시된 지 50년이 되는 2020년)를 기념해 임베디드 소프트웨어 역사 관련 책을 출판할 계획이다.'

이 책을 올바로 읽기 위한 특정한 방법이 있는 것은 아니다. 앞부터 뒤까지 책을 읽을 때 독자가 이해하기 쉽도록 글의 순서를 정하기 위해 노력했다. 그리고 장 전반에 걸쳐 글을 잘 분류하여 독자가 관심 있어 하는 내용을 찾기 쉽게 하고, 책을 읽을 때 책 여기저기를 넘겨 보는 불편함이 없도록 공을 들였다. 책을 참고할 때 부적절한 색인 때문에 불만스러운 경우가 있다. 그래서 관심 있는 내용을 찾을 때 색인이 효과적인 방법이 될 수 있도록 찾아보기 항목을 고르는 데 신경을 썼다.

★ 저자 서문 ★

- 개정판을 펴내면서 -
책의 초판이 출간된 후로 세상은 많이 달라졌다. 많은 것이 바뀌었지만 그대로 남아있는 것도 있다. 임베디드 소프트웨어 분야에는 새로운 프로세서와 기술이 등장하고 결과적으로 임베디드 소프트웨어 엔지니어의 세상을 변화시켰다. 이런 것을 염두에 두고 엘스비어(Elsevier)에서 개정판의 필요성을 느끼고 내게 연락했다. 나는 개정판 작업을 기쁘게 수락했다.

기존 내용에 덧붙여 새 글을 추가했고 오픈 소스 소프트웨어와 멀티코어를 다루는 단원을 두 개 추가했다. 물론 별로 관련 없어 보이는 내용들을 삭제하기도 했다.

그 외에 내 개인적 상황도 바뀌었다. 내 아내가 최고의 치료를 받았지만 2006년 6월에 저 세상으로 가고 말았다. 그 치료가 없었다면 단지 몇 주밖에 살지 못했을 것이다. 그 치료로 인해 2년을 더 살 수 있었고 어느 정도 기간 동안은 양질의 삶을 누릴 수 있었다. 내 딸들과 나는 잘 지내고 있고 나는 여전히 멘토 그래픽스(Mentor Graphics)에서 일하고 있으며 여전히 임베디드 소프트웨어와 관련된 일을 하고 있다.

다시 한 번 나를 고용해준 분들이 이번 개정판의 수익금도 LINC에 기부할 수 있도록 해준 것에 기쁘게 감사한다. 기부된 돈이 현명하게 사용될 거란 데에 여전히 확신한다.

정보제공 :

1장 임베디드 소프트웨어 
__1.1 임베디드 애플리케이션 동작 
____1.1.1 개발 시 문제점 
____1.1.2 소프트웨어 재사용 
____1.1.3 실시간 운영체제 
____1.1.4 파일 시스템 
____1.1.5 USB 
____1.1.6 그래픽 
____1.1.7 네트워킹 
____1.1.8 결론 
__1.2 임베디드 시스템 메모리 
____1.2.1 메모리 
____1.2.2 구현 시 문제 
____1.2.3 모두 잘못되는 경우 
____1.2.4 모두 올바른 경우 
__1.3 메모리 구조 
____1.3.1 옵션 
____1.3.2 균일한 단일 공간 메모리 
____1.3.3 세그먼트 메모리 
____1.3.4 뱅크 교환 메모리 
____1.3.5 다중 공간 메모리 
____1.3.6 가상 메모리 
____1.3.7 캐시 메모리 
____1.3.8 메모리 관리 장치 
____1.3.9 결론 
__1.4 소프트웨어가 하드웨어 설계에 미치는 영향 
____1.4.1 누가 하드웨어를 설계하는가? 
____1.4.2 하드웨어를 이끄는 소프트웨어 
____1.4.3 소프트웨어와 하드웨어 간 균형 조정 
____1.4.4 하드웨어 디버깅 
____1.4.5 자가 진단 지원 
____1.4.6 결론 
__1.5 기존 소프트웨어를 새로운 프로세서 아키텍처로 이전 
____1.5.1 타겟 특화 
____1.5.2 RTOS 이슈 
____1.5.3 프로세서 이동과 공개 표준 
____1.5.4 결론 
__1.6 운송 애플리케이션용 임베디드 소프트웨어 
____1.6.1 소개 
____1.6.2 운송 시스템 특징 
____1.6.3 프로그래밍 이슈 
____1.6.4 실시간 운영체제를 사용하는 이유 
____1.6.5 결론 
__1.7 시스템온칩 설계 시 CPU를 선택하는 방법 
____1.7.1 설계 복잡도 
____1.7.2 설계 재사용 
____1.7.3 메모리 구조와 보호 
____1.7.4 CPU 성능 
____1.7.5 전력 소모 
____1.7.6 비용 
____1.7.7 소프트웨어 이슈 
____1.7.8 멀티코어 SoC 
____1.7.9 결론 
__1.8 USB 소프트웨어 소개 
____1.8.1 USB란? 
____1.8.2 USB 주변장치 
____1.8.3 USB 통신 
____1.8.4 USB 소프트웨어 
____1.8.5 USB와 임베디드 시스템 
____1.8.6 결론 
__1.9 USB 3.0 소개 
____1.9.1 소개 
____1.9.2 버스 구조 
____1.9.3 케이블과 커넥터 
____1.9.4 패킷 라우팅 
____1.9.5 양방향 프로토콜 흐름 
____1.9.6 벌크 스트리밍 
____1.9.7 USB 3.0 전원 관리 
____1.9.8 USB 3.0 허브 
____1.9.9 xHCI - 새로운 호스트 제어기 인터페이스 
____1.9.10 USB의 향후 응용 
____1.9.11 결론 
____추가 참고 도서 목록 

2장 설계와 개발 
__2.1 최신 임베디드 시스템 소프트웨어 개발 기술 
____2.1.1 마이크로프로세서 장치 기술 
____2.1.2 시스템 구조 
____2.1.3 설계 구성 
____2.1.4 소프트웨어 내용물 
____2.1.5 프로그래밍 언어 
____2.1.6 소프트웨어 팀 크기와 배치 
____2.1.7 UML과 모델링 
____2.1.8 주요 기술 
____2.1.9 결론 
__2.2 개발 툴 선택 
____2.2.1 개발 툴 체인 
____2.2.2 컴파일러 특징 
____2.2.3 임베디드 시스템을 위한 확장 
____2.2.4 최적화 
____2.2.5 빌드 툴: 주요 이슈 정리 
____2.2.6 디버깅 
____2.2.7 디버그 툴: 주요 이슈 정리 
____2.2.8 표준과 개발 툴 통합 
____2.2.9 개발 툴을 고려한 선택 
____2.2.10 결론 
__2.3 이클립스: 임베디드 툴 통합 환경 
____2.3.1 소개 
____2.3.2 이클립스 플랫폼 철학 
____2.3.3 플랫폼 
____2.3.4 임베디드용 이클립스 
____2.3.5 결론 
__2.4 RTOS 경계를 넘는 개발 시스템 
____2.4.1 표준으로 해결이 될까? 
____2.4.2 이클립스를 통한 해결 
____2.4.3 이클립스 플러그인 
____2.4.4 이클립스 라이선스 
____2.4.5 이클립스 사용 장점 
____2.4.6 퍼스펙티브 
____2.4.7 임베디드용이 아닌 플러그인 
__2.5 임베디드 소프트웨어와 UML 
____2.5.1 왜 UML로 모델링하는가? 
____2.5.2 애플리케이션과 구조의 분리 
____2.5.3 xtUML 코드 생성 
____2.5.4 결론 
__2.6 사용자 인터페이스 개발 
____2.6.1 다양한 사용자 인터페이스 
____2.6.2 사용자 인터페이스 구현 
____2.6.3 합리적 UI 솔루션 
____2.6.4 결론 
__2.7 소프트웨어와 전력 소모 
____2.7.1 소개 
____2.7.2 소프트웨어 이슈 
____2.7.3 소프트웨어에서 전력 제어 
____2.7.4 멀티코어 
____2.7.5 하드웨어 이슈 
____2.7.6 가상 프로그래밍 
____2.7.7 결론 

3장 프로그래밍 
__3.1 이국적 메모리 프로그래밍 
____3.1.1 이국적 메모리 
____3.1.2 비휘발성 RAM 
____3.1.3 공유 메모리 
____3.1.4 결론 
__3.2 임베디드 시스템 자가 테스팅 
____3.2.1 메모리 테스팅 
____3.2.2 입/출력 디바이스 
____3.2.3 멀티스레딩 이슈 
____3.2.4 와치독 
____3.2.5 자가 테스트 실패 
____3.2.6 마지막 사항 
__3.3 명령 행 인터프리터 
____3.3.1 임베디드 시스템 진단 
____3.3.2 임베디드 시스템 동작 개시 
____3.3.3 명령 행 인터프리터: 요구사항 
____3.3.4 명령 행 인터프리터 설계 
____3.3.5 CLI 구현 
____3.3.6 CLI 프로토타입 코드 
____3.3.7 결론 
__3.4 교통신호등: 임베디드 소프트웨어 애플리케이션 
____3.4.1 애플리케이션 
____3.4.2 하드웨어 설정 
____3.4.3 프로그램 구현 
____3.4.4 메인 루프 
____3.4.5 인터럽트 
____3.4.6 시간 지연 
____3.4.7 신호등 
____3.4.8 전역 변수 사용 

4장 C 언어 
__4.1 C 커먼 
__4.2 C 함수 프로토타입 사용 
____4.2.1 프로토타입 이전 
____4.2.2 프로토타입 적용 
____4.2.3 프로토타입 사용 
____4.3 인터럽트 함수와 ANSI 키워드 
____4.3.1 인터럽트 함수 
____4.3.2 ANSI C의 const 키워드 
____4.3.3 ANSI C Volatile 키워드 
__4.4 비트 
____4.4.1 비트 연산자 
____4.4.2 이진 상수 
____4.4.3 구조체의 비트 필드 
____4.4.4 마이크로프로세서 비트 필드 명령어 
____4.4.5 I/O 장치와 비트 필드 
____4.4.6 결론 
__4.5 부동 소수점 애플리케이션 프로그래밍 
____4.5.1 테스트 케이스 
____4.5.2 테스트 케이스 실행 
____4.5.3 문제 해결 
____4.5.4 결론 
__4.6 다른 관점에서 본 C 언어 
____4.6.1 정적인 것 
____4.6.2 세미콜론의 모든 것 
____4.6.3 포인터와 포인터 연산 
__4.6.4 영악해서 덜 똑똑해지고 마는 때 
____4.6.5 결론 
__4.7 함수 호출 오버헤드 줄이기 
____4.7.1 컴파일러와 구조화된 코드 
____4.7.2 인라인 함수 
____4.7.3 함수 호출 
____4.7.4 인자 전달 
____4.7.5 지역 저장소 
____4.7.6 스택 프레임 생성 
____4.7.7 리턴 값 
____4.7.8 결론 
__4.8 구조체 레이아웃으로 전문가 되기 
____4.8.1 주요 개념 
____4.8.2 비트 필드 
____4.8.3 조언과 기법 
__4.9 C의 메모리와 C 프로그래밍 
____4.9.1 메모리 
____4.9.2 섹션 
____4.9.3 결론 
__4.10 C/C++의 포인터와 배열 
____4.10.1 포인터와 포인터 연산 
____4.10.2 배열과 포인터 
____4.10.3 결론 
__4.11 C/C++의 동적 메모리 사용 
____4.11.1 C/C++ 메모리 공간 
____4.11.2 C에서 동적 메모리 
____4.11.3 C++에서 동적 메모리 
____4.11.4 이슈와 문제 
____4.11.5 메모리 단편화 
____4.11.6 RTOS와 메모리 
____4.11.7 실시간 메모리 해결책 
____4.11.8 결론 

5장 C++ 
__5.1 관리 관점에서 보는 임베디드 시스템의 C++ 
____5.1.1 임베디드 시스템 개발 팀 
____5.1.2 객체 지향 프로그래밍 
____5.1.3 팀 관리와 객체 지향 기술 
____5.1.4 객체 지향 언어로서 C++ 
____5.1.5 오버헤드 
____5.1.6 성공으로 가는 길 
__5.2 C에서 C++로 전환하는 이유 
____5.2.1 구현 상세 내용 숨김 
____5.2.2 클래스 코드 재사용 
____5.2.3 제네릭 클래스 재사용 
____5.2.4 확장 연산자 
____5.2.5 베이스 클래스에서 클래스 상속 
____5.2.6 함수 프로토타입을 통해 오류 줄이기 
____5.2.7 함수 호출을 변경하지 않고 인자 추가하기 
____5.2.8 더 안전하고 단순한 I/O 
____5.2.9 빠른 인라인 함수로 성능 개선하기 
____5.2.10 함수 이름 오버로드 
____5.2.11 임베디드 시스템 지원 
____5.2.12 전환에 필요한 노력 
____5.2.13 C 코드를 C++에서 사용하기 
____5.2.14 어려운 부분: 객체 설계 
____5.2.15 깨지지 않았다면 고치지 말 것 
__5.3 C++로 전환하는 과정 
____5.3.1 전환 정책 
____5.3.2 점진적인 단계 
____5.3.3 재사용 적용 
____5.3.4 클린 C 작성하기 
____5.3.5 C++에 근접한 C+ 
____5.3.6 결론: 앞으로 나갈 길 
__5.4 C++ 템플릿의 장단점 
____5.4.1 템플릿이 무엇인가? 
____5.4.2 템플릿 인스턴스화 
____5.4.3 템플릿 사용시 문제점 
____5.4.4 다중 템플릿 인자 
____5.4.5 기타 템플릿 애플리케이션 
____5.4.6 결론 
____5.4.7 후기 
__5.5 C++의 예외 처리 
____5.5.1 C에서 오류 처리 
____5.5.2 인터럽트와 무관함 
____5.5.3 C++ 예외 처리 
____5.5.4 특수한 경우 
____5.5.5 EHS와 임베디드 시스템 
____5.5.6 결론 
__5.6 C++의 코드 크기와 성능 살펴보기 
____5.6.1 C에 비해 C++는 얼마나 효율적인가? 
____5.6.2 C++가 애플리케이션 메모리 요구량에 미치는 영향 
____5.6.3 C++를 올바르게 쓰기 
____5.6.4 결론 
__5.7 C++의 쓰기 전용 포트 
____5.7.1 전문 지식의 캡슐화 
____5.7.2 문제 정의 
____5.7.3 C를 사용한 해결책 
____5.7.4 C++를 사용한 첫 번째 해결책 
____5.7.5 오버로드 연산자 사용하기 
____5.7.6 클래스 wop 개선 
____5.7.7 재진입 해결 
____5.7.8 RTOS 사용 
____5.7.9 전문 지식의 캡슐화 
____5.7.10 다른 가능성 
____5.7.11 앞으로 갈길 
__5.8 C++의 비휘발성 RAM 사용 
____5.8.1 C++의 비휘발성 RAM 사용을 위한 요구사항 
____5.8.2 NVRAM 구현 
____5.8.3 C++ nvram 클래스 
____5.8.4 nvram 클래스 개선 
____5.8.5 결론 
__참고 문헌 

6장 실시간 
__6.1 실시간 시스템 
____6.1.1 RTS 구현 
____6.1.2 처리 루프 
____6.1.3 인터럽트 
____6.1.4 멀티태스킹 
____6.1.5 RTOS 사용 
__6.2 임베디드 시스템 프로그램 모델의 시각화 
____6.2.1 실시간 시스템을 만드는 데 어떤 프로그래밍 모델이 좋은가? 
____6.2.2 모델을 어떤 목적으로 실시간 시스템에서 사용하는가? 
____6.2.3 모델들 간에 차이점은 무엇이고 무엇을 희생해 무엇을 얻을 수 있는가? 
____6.2.4 단일 스레드 프로그래밍 모델이란? 
____6.2.5 단일 스레드 프로그래밍 모델의 장점과 단점은? 
____6.2.6 폴링 루프가 단일 스레드 프로그램인가? 
____6.2.7 상태 머신은 단일 스레드 프로그램인가? 
____6.2.8 다중 스레드 시스템이란? 
____6.2.9 다중 스레드 프로그래밍 모델의 장점과 단점은? 
____6.2.10 단일 CPU에서 정말로 여러 스레드가 동시에 수행 가능한가? 
____6.2.11 실시간 시스템에서 다중 스레드 환경을 어떻게 사용할 수 있나? 
__6.3 임베디드 시스템 이벤트 처리 
____6.3.1 이벤트란? 
____6.3.2 시그널은 이벤트와 같은 것인가? 
____6.3.3 이벤트를 대부분 긴급하게 처리해야 하는가? 
____6.3.4 마이크로프로세서가 예외를 감지하면 무엇을 하는가? 
____6.3.5 모든 예외는 같은가? 
____6.3.6 동기 예외란? 
____6.3.7 비동기 예외란? 
____6.3.8 인터럽트는 어떻게 발생하고 처리되는가? 
____6.3.9 CPU가 저장하는 상태는 무엇인가? 
____6.3.10 머신 상태와 스레드 상태는 같은 것인가? 
____6.3.11 예외 처리기를 어셈블리나 C로 작성해야 하는가? 
____6.3.12 예외 처리기에서 어떻게 작업량을 줄이는가? 
__6.4 인터럽트 프로그래밍 
____6.4.1 인터럽트 설정 
____6.4.2 인터럽트 처리 루틴 
____6.4.3 인터럽트 벡터 
____6.4.4 초기화 
____6.4.5 결론 

7장 실시간 운영체제 
__7.1 RTOS의 디버깅 기법 
____7.1.1 소개 
____7.1.2 멀티프로세스 개념 
____7.1.3 실행 환경 
____7.1.4 타깃 연결 
____7.1.5 디버깅 모드 
____7.1.6 RTOS 인지 디버깅 기능 
____7.1.7 공유 코드 
____7.1.8 태스크 인지 중단점 
____7.1.9 의존하는 태스크 
____7.1.10 메모리 관리 유닛 
____7.1.11 멀티프로세서 
____7.1.12 결론 
__7.2 자체 제작 실시간 운영체제에서 디버깅하는 방법 
____7.2.1 태스크 인지 디버깅 구현 
____7.2.2 태스크 인지 기능 
____7.2.3 결론 
__7.3 디버깅과 스택 오버플로우 
____7.3.1 결론 
__7.4 상용 RTOS의 장점 활용 
____7.4.1 상용 RTOS vs. 자체 제작 RTOS 
____7.4.2 상용 RTOS의 장점 
____7.4.3 상용 RTOS의 불리한 점 
____7.4.4 RTOS를 자체 제작하는 이유 
____7.4.5 커스텀 RTOS를 만들지 말아야 할 이유 
____7.4.6 결론 
__7.5 잦은 교체 
____7.5.1 다른 RTOS로 이전 
____7.5.2 코드 이전 
____7.5.3 래퍼 
____7.5.4 드라이버와 기타 
____7.5.5 디버깅 이슈 
____7.5.6 결론 
__7.6 RTOS 드라이버 개발 소개 
____7.6.1 디바이스 드라이버의 두 측면 
____7.6.2 데이터 손상 
____7.6.3 스레드 제어 
____7.6.4 프로그램 로직 
____7.6.5 결론 
__7.7 스케줄링 알고리즘과 우선순위 역전 
____7.7.1 서론 
____7.7.2 실시간 요구사항 
____7.7.3 스케줄링 알고리즘 
____7.7.4 운영체제와 애플리케이션에 대한 함축 
____7.7.5 결론 
__7.8 시간과 우선순위 스케줄링 
____7.8.1 RTOS 스케줄링 
____7.8.2 이상 세계 
____7.8.3 우선순위 스케줄링을 하는 실제 세계 
____7.8.4 양보 없는 고정 시간 할당 스케줄링 
____7.8.5 양보가 가능한 고정 시간 할당 스케줄링 
____7.8.6 결론 
__7.9 임베디드 파일 시스템 
____7.9.1 임베디드 파일 시스템의 요구사항 
____7.9.2 MS-DOS 파일 시스템 개요 
____7.9.3 긴 파일이름 
____7.9.4 포맷 
____7.9.5 파티션 구성 
____7.9.6 디바이스 
__7.10 RTOS 표준 중 하나인 OSEK 
____7.10.1 OSEK에 관해 
____7.10.2 OSEK 요구사항 
____7.10.3 OSEK 태스크 
____7.10.4 알람 
____7.10.5 에러 처리 

8장 네트워킹 
__8.1 와이파이 소개 
____8.1.1 무선 데이터 통신 
____8.1.2 IEEE 802.11 
____8.1.3 802.11 기본 
____8.1.4 와이파이와 블루투스 
____8.1.5 향후에는? 
__8.2 웹 서버 활용 
____8.2.1 소개 
____8.2.2 세 주요 기능 
____8.2.3 웹 서버 작업 
____8.2.4 웹 서버 기능 요약 
____8.2.5 다른 고려 사항 
____8.2.6 결론 
__8.3 SNMP 소개 
____8.3.1 SNMP란? 
____8.3.2 네트워크 관리자의 역할 
____8.3.3 아키텍처 모델 
____8.3.4 흔한 오해 
____8.3.5 애플리케이션 수준 관리자/에이전트 
____8.3.6 MIB 작성 방법 
____8.3.7 용어 
____8.3.8 결론 
__8.4 IPv6: 차세대 인터넷 프로토콜 
____8.4.1 인터넷 프로토콜의 제약 
____8.4.2 IP 버전 6 소개 
____8.4.3 이중 스택을 통한 전환 
____8.4.4 IPv6 동작 방식 
____8.4.5 RFC 지원 
__8.5 DHCP 기초 
____8.5.1 DHCP 서버 
____8.5.2 동작 방법 
____8.5.3 RFC 지원 
__8.6 NAT 소개 
____8.6.1 NAT 소개 
____8.6.2 RFC 지원 
____8.6.3 프로토콜 지원 
____8.6.4 애플리케이션 수준 게이트웨이 
____8.6.5 사설 네트워크 주소 할당 
__8.7 PPP - 점대점 프로토콜 
____8.7.1 소개 
____8.7.2 PPP 동작 
____8.7.3 PPP 상세 
____8.7.4 RFC 지원 
__8.8 SSL 소개 
____8.8.1 소개 
____8.8.2 SSL 동작 
____8.8.3 SSL 상세 
__8.9 DHCP 디버깅 팁 
__8.10 IP 멀티캐스팅 
____8.10.1 멀티캐스팅 초기화 
____8.10.2 IGMP 프로토콜 
____8.10.3 멀티캐스팅 구현 
____8.10.4 종합 

9장 오픈소스와 임베디드 리눅스, 안드로이드 
__9.1 임베디드 개발을 위한 GNU 툴체인: 만들거나 사거나 
____9.1.1 소개 
____9.1.2 툴체인 요소 
____9.1.3 툴체인 빌딩 
____9.1.4 툴체인 검증 
____9.1.5 다중 옵션 테스트 
____9.1.6 결론 
__9.2 임베디드 시스템을 위한 리눅스 소개 
____9.2.1 개요 
____9.2.2 공개 소스 사용의 문제 
____9.2.3 오픈임베디드 
____9.2.4 메타데이터의 이해 
____9.2.5 프로젝트 작업 순서 
____9.2.6 요약 
__9.3 안드로이드 아키텍처와 설치 
____9.3.1 안드로이드란? 
____9.3.2 안드로이드 아키텍처 
____9.3.3 애플리케이션 개발 
____9.3.4 안드로이드 UI 
____9.3.5 안드로이드를 모바일 이외 분야로 확장 
____9.3.6 결론 
__9.4 안드로이드와 미고, 수직 시장의 임베디드 리눅스 
____9.4.1 개요 
____9.4.2 수직 시장은 어떻게 다른가? 
____9.4.3 안드로이드의 매력 
____9.4.4 미고의 가능성 
____9.4.5 임베디드 리눅스의 융통성 
____9.4.6 결론 

10장 멀티코어 임베디드 시스템 
__10.1 멀티코어 소개 
____10.1.1 시스템 아키텍처 
____10.1.2 전력 
____10.1.3 문제점 
__10.2 멀티 코어: 멀티 운영체제 
____10.2.1 AMP를 위한 SMP 하드웨어 
____10.2.2 AMP 하드웨어 아키텍처 
____10.2.3 AMP 소프트웨어 아키텍처 
____10.2.4 프로세스 간 통신의 중요성 
____10.2.5 AMP 개발 툴 
____10.2.6 어려움 
____10.2.7 AMP 사용 사례 
____10.2.8 하이퍼바이저 사용 
____10.2.9 결론 
__10.3 멀티 코어를 위한 멀티 운영체제 선택 
____10.3.1 소개 
____10.3.2 운영체제 유형 
____10.3.3 운영체제 선정 
____10.3.4 멀티코어 시스템 
____10.3.5 결론 
__10.4 CPU간 통신: MCAPI 
____10.4.1 소개 
____10.4.2 멀티코어 
____10.4.3 MCAPI 
____10.4.4 결론