추가 적립 안내

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

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

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

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

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

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

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

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

무엇을 기대하는가? 완벽함인가?
왜 수많은 펌웨어 프로젝트는 기한을 넘기게 되고 버그 때문에 고생하게 될까? 소프트웨어 복잡도와 버그 원인을 다루는 이론은 차고 넘친다. 하지만 가장 직접적인 원인은 코딩이라는 것이 호모 사피엔스(Homo Sapiens)에게 맞는 일이 아니라는 데 있다. 코딩을 할 때는 정말이지 슈퍼맨 수준의 정확도가 필요하다. 그러나 당연한 말이지만 슈퍼맨은 없다. 동굴에 살던 원시인들은 사냥한 가젤을 모두 소유할 이유가 없었다. 배고픔을 견딜 정도면 충분했다. 농부는 뿌린 씨앗에서 모두 싹이 날 거라고 기대하지 않는다. 어느 정도의 손실을 감안하고 받아들인다. 상인은 대다수 고객이 만족하기를 바라는 것이지 모든 고객이 만족할 서비스를 할 수 있을 거라고 기대하지는 않는다. 자녀가 모든 과목 점수로 '수'를 받아온다면 부모는 정말 신날 것이다. 하지만 90점 이상이면 수에 해당한다. 즉 100점이 아니어도 받을 수 있다는 말이다. 인생에서 목표 점수를 10% 이상 벗어나지 않는다면 수를 받을 것이고 노력한 결과로 성공을 얻을 수 있다.

하지만 소프트웨어는 다르다. 90% 수준에 머무르면 완전한 재앙이라고 봐야 한다. 결국 소프트웨어가 쓸모없는 제품이 되고 만다. 99.9%가 완료된 제품도 쓸모 없게 된다. 정확도가 99.9%인 10만 라인짜리 코드라도 드러나지 않은 에러는 100개나 있게 된다. 이걸로는 불충분하다. 소프트웨어는 완벽에 가까워야 한다. 하지만 이는 실수하기 쉬운 인간의 본성에 반한다. 또한 소프트웨어에는 높은 엔트로피 특성이 있다. 완벽한 100라인짜리 코드로 된 시스템을 작성할 수는 있다. 하지만 코드의 크기가 커지면 완벽 또는 완벽에 가까운 시스템 제작에 더욱 더 많은 노력이 들어간다. 비트가 울타리를 벗어나려는 소라고 한다면, 코딩 목동은 소 무리가 커질수록 길 잃은 소가 생기지 않게 더욱더 열심히 일해야 하는 이치와 같다.

그러면 해결책은 무엇일까? 답이 있기는 할까? 펌웨어는 얼마나 좋아야 하고 얼마나 좋아질 수 있을까? 완벽이나 완벽에 가까움을 추구하는 게 헛된 일일까? 복합 시스템(complex system)은 새로운 개념이다. 많아야 대여섯 개 정도의 능동 부품(active device)으로 동작하는 초기 트랜지스터 라디오를 기억할 것이다. 1970년대에 흔했던 진공관 텔레비전은 15개에서 20개의 진공관으로 동작했는데, 이 진공관은 정도의 차이는 있어도 대략 같은 수의 트랜지스터와 비슷한 성능을 낸다. 1940년경 에니악(ENIAC) 컴퓨터는 1만 8,000개의 진공관을 사용했다. 이 컴퓨터를 작동하려고 많은 기술자들이 여분 진공관을 담은 쇼핑 카트를 끌고 다니면서 타버린 진공관을 계속 교체해야 했다. 엄청나게 많은 능동 부품이 있는 것 같지만, 25년이 된 Z80 칩조차도 애니악 의 진공관 한 개보다 수십만 배 작은 다이(die) 공간에 애니악이 지닌 진공관의 1/4 만큼이나 들어간다.

컴퓨터의 구성 요소 중 하나인 펜티엄IV에는 4,500만 개나 되는 트랜지스터가 있다. 좀 큰 메모리 칩에는 약 3억 개 정도 되는 트랜지스터가 있다. 인텔에서는 10년 내로 프로세서에 10억 개의 트랜지스터가 들어갈 것으로 예상한다. 인사말을 담는 전자 카드와 같은 단순한 임베디드 시스템조차도 능동 부품이 수천 개나 들어간다.

소프트웨어의 길이가 기하급수적으로 늘고 있다. 특히 임베디드 애플리케이션에서는 더욱 그렇다. 1975년에 길이가 1만 라인 정도 되는 어셈블리 코드는 매우 큰 편에 속했다. 그 당시 개발 툴이 종이테이프, 대용량 저장장치용 카세트, 조잡한 콘솔용 텔레타이프였다는 점을 고려해보면 이정도 크기의 프로젝트를 진행하기는 매우 어려웠다. 요즘에는 1만 라인이나 되는 C코드(어셈블리 코드로 만들려면 아마 3만 라인에서 5만 라인 정도를 코딩해야 한다)라도 작은 프로그램으로 여겨진다. 휴대전화에는 500만 라인이나 되는 C 코드 또는 C++ 코드가 있다. 제품 크기, 아주 작은 전력 소모, 놀랄 만큼 짧은 개발 기간을 고려해보면 대단한 일인 셈이다.

메모리 사용량으로 소프트웨어 크기를 재기도 한다. 1975년에는 256바이트(오타가 아님) EPROM에 4,000바이트 크기 프로그램을 저장하려면 EPROM 16개가 필요했다. 작은 임베디드 시스템이라도 매우 비쌀 수밖에 없었다. 요즘은 어떤가? 아주 작은 앱에도 128,000 크기 플래시 메모리가 필요할 정도다. 그리고 실제 메모리 크기 때문이라기보다는 주소 공간 지정에 필요한 이유로 프로세서가 8비트에서 16비트로, 16비트에서 32비트 이상으로 변화해 왔다. 1970년대 후반에 시게이트(Seagate)에서 최초의 소형 윈체스터(Winchester) 하드디스크를 출시했다. 이 하드디스크는 약 4.5kg 무게에 5MB 용량을 지녔으며 가격은 무려 1,500달러였다. 그때는 5MB라는 크기가 대부분의 사용자에게 충분한 크기였다. 지금은 20GB용량 디스크도 셔츠 주머니에 들어갈 정도이고, 매우 저렴할 뿐만 아니라 데이터를 순식간에 채울 수도 있다.

이처럼 시스템은 크기나 복잡도 면에서 급속도로 커지고 있다. 개발자들이 이런 거대한 애플리케이션을 올바르게 만들 만큼 뛰어날까? 간단한 애플리케이션조차도 완벽하게 만드는 게 쉽지 않다. 하물며 큰 애플리케이션에 결함이 없을 수는 없다. 소프트웨어가 커지면 점점 더 꼬이게 되므로, 한 부분을 변경하면 다른 부분에 영향을 주고, 때로 그 영향이 엄청난 경우도 있다. 설계를 잘못해서인 경우도 있고, 시스템이 커지면서 생긴 문제인 경우도 있다.

분명한 점은 하드웨어를 완벽하게 만드는 일도 매우 어렵다는 점이다. 오래된 프로세서조차도 정오표(errata sheet)가 딸려 나온다. 정오표가 얼마나 큰지, 데이터시트와 경쟁할 정도다. 악명 높은 펜티엄 나눗셈 버그는 수많은 버그 중 하나일 뿐이다. 요즘에도 펜티엄III의 정오표(스펙 업데이트, Specification Update라는 말로 바꿈)에는 83개의 이슈가 있다. 모토롤라의 MPC555에는 거의 100개나 되는 문제가 있다.

임베디드 시스템 분야에서 현재 기술을 어느 정도 신뢰할 수 있을까? 아무도 모른다. 연구가 거의 없는 분야기도 하다. 하지만 이런 연구에 사용할 원 데이터는 많으며, 일부 데이터에 따르면 개발자들은 제대로 연구하지 않는 듯이 보인다.

화성 탐사선 패스파인더가 착륙선이 하강 중 소프트웨어 중단이라는 심각한 오류에 도 불구하고 성공적으로 임무를 마쳤다. 지상에서 이미 알고 있었던, 작은 문제로 치부하고 무시했던 우선순위 역전 문제(priority inversion problem)가 원인이었다. 하지만 잘 설계한 와치독(watchdog) 타이머 복구 정책 덕에 임무를 마칠 수 있었다. 이는 외부 하드웨어나 소프트웨어를 추가해 예상치 못한 소프트웨어 오류를 다루는 기술의 중요성을 보여주는 좋은 사례이다.

하드웨어와 소프트웨어가 복잡도뿐 아니라 크기도 계속 커진다는 것은 분명한 사실이다. 패스파인더의 우선순위 역전 문제는 RTOS가 필요 없던 마이크로프로세서 초기에는 알려지지 않은 문제였다. 현재에는 대부분의 임베디드 시스템에는 운영체제가 들어있고 위와 같은 위험에 노출돼 있다.

복잡도가 폭발적으로 증가하면 개발자는 무엇을 해야 할까? 새로운 기술을 배우는 일에 계속 시간을 투자해야 한다는 점은 분명하다. 물론 기존 기술도 학습해야 한다. 이미 배웠지만 잊어버린 것들도 공부해야 한다. 결국 예전 개요서와 새로운 개요서, C 프로그래밍의 필수 내용부터 UML과 그 이상의 것들을 다룬 책에 파묻혀 매일 저녁 내내 쭈그리고 책이나 봐야 할 것이다. 이 책의 저자인 콜린은 숙련된 기술자로서, 이러한 일을 어떻게 했는지 실질적인 많은 조언과 경험을 책을 통해 이야기한다.

우리는 경험에서 배운다. 하지만 지식을 습득하는 데는 큰 대가가 따르는 방법이다. 그러므로 거장의 지혜를 듣는 것이고 최소한 이 책을 읽는 동안이라도 거장의 견습생이 되는 편이 더 낫다. 독자는 새로운 통찰력을 갖게 되고 더욱 다양한 도구들로 복잡한 문제를 해결하는 능력을 갖추게 될 것이다. 완벽에 이르기가 어려울지라도 현명한 개발자는 부단히 완벽함에 이르고자 노력할 것이다.
- 잭 갠슬(Jack Ganssle) / [임베디드 시스템 대사전](에이콘출판) 저자

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 결론

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

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

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

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

대학 졸업 후 임베디드 시스템 분야에서 오랫동안 일해왔고, 지금은 대학생들을 가르치는 입장에서, 임베디드 소프트웨어를 다루는 좋은 책을 갈망해 왔다. 물론 웹을 검색해 보면 다양한 자료가 있지만, 특히나 수업에서 쓰거나 누군가에게 개론서로 추천해 줄만한 책이 마땅하지 않았다. 대부분의 책이 ARM 계열 하드웨어와 디바이스 드라이버나 BSP 정도를 다루는 내용으로 협소한 내용만 다루고 있었다. 그리고 소프트웨어 개발자의 관점에서 다루는 내용이 많이 부족한 것이 아쉬운 점이었다. 물론 임베디드 시스템은 데스크톱이나 서버 시스템과 달리 하드웨어의 종류가 너무 다양하기 때문에 이 모든 것을 다루는 것이 불가능할 것이다. 그런데 이 책은 소프트웨어 개발자에게 임베디드 소프트웨어 개발에 대한 최소한의 필요한 내용을 거의 다 설명해주고 있다. 각각에 대한 깊이 있는 내용이 부족할 수 있으나, 최소한 독자가 헤매지 않도록 길을 보여주고 있다.

이 책이 임베디드 소프트웨어 개발을 막 시작하려는 개발자나 학생들에게 아주 좋은 지침서가 될 것이라 확신이 들었고, 학생들에게 조금이라도 쉽게 전달해줄 생각으로 번역을 시작했다. 하지만 강의와 연구 중에 틈틈이 번역을 하다 보니 거의 2년 만에 책이 나오게 되었다. 이 책의 내용들은 대부분 저자나 관련 전문가가 과거에 기고했던 단편들을 모아서 최신 경향에 맞도록 수정하고 편집한 것이다. 90년대에 썼던 글도 포함되어 있는데, 오래되었지만 최신 글이라고 해도 믿을 만큼 최근 임베디드 소프트웨어 경향을 잘 반영하고 있다. 원서가 출판된 지 2년이 지나 번역서가 나오게 되었으나, 여전히 임베디드 소프트웨어의 핵심들을 잘 짚고, 초급 임베디드 개발자나 학생들에게 많은 도움이 될 것이라 생각한다.
(/ 옮긴이의 말 중에서)