반디앤루니스 인터넷서점
전체

로고이미지

검색

  • ▼
HOT ISSUE

네비게이션 실시간 인기 책

    임베디드 소프트웨어의 모든 것 - 에이콘 임베디드 시스템 프로그래밍 시리즈

    임베디드 소프트웨어의 모든 것 - 에이콘 임베디드 시스템 프로그래밍 시리즈 임베디드 시스템 개발에 필요한 기초 기술부터 고급 해법까지

    시리즈 : 에이콘 임베디드 시스템 프로그래밍 시리즈 [19]

    원제 : Embedded Software, Second Edition: The works

    • 콜린 월즈 저
    • 허준영 역
    • 에이콘출판
    • 2014년 08월 28일
    • 정가
      35,000원
    • 판매가
      31,500원 [10% 할인]
    • 결제 혜택
      무이자
    • 적립금
      1,750원 적립 [5%P]

      NAVER Pay 결제 시 네이버페이 포인트 5% 적립 ?

    품절된 상품입니다.

    위시리스트
    회원리뷰
    - [0]
    ISBN: 9788960775992 528쪽 188 x 250 (㎜)

    지금 이책은

    이 분야의 베스트셀러

    이 책과 함께 구매한 책

    이 책이 속한 분야

    이 책의 시리즈

    전체 선택 쇼핑카트 담기
    시리즈 에이콘 임베디드 시스템 프로그래밍 시리즈 (19)

    책 소개

    상품문의 / 정보수정 요청 >

    출판사 리뷰

    출판사 서평
    ★ 요약 ★
    이 책은 임베디드 소프트웨어 개발자가 알아야 할 종합 상식을 다룬다. 즉,임베디드 소프트웨어 개발 시에 고려해야 할 다양한 측면인, 설계와 개발 도구, 프로그래밍 언어, 특히 C/C++에서? 고려할 점, 실시간 시스템, 네트워킹, 리눅스나 안드로이드 같은 오픈소스 플랫폼, 최신의 멀티코어까지 매우 광범위한 내용을 다룬다. 또한 임베디드 시스템 개발에서 소프트웨어 개발 방법이 어떻게 발전되어 왔는지에 관한 역사도 엿볼 수 있다.
    ★ 이 책에서 다루는 내용 ★
    임베디드 분야가 커짐에 따라, 개발자가 더 정교한...
    ★ 요약 ★
    이 책은 임베디드 소프트웨어 개발자가 알아야 할 종합 상식을 다룬다. 즉,임베디드 소프트웨어 개발 시에 고려해야 할 다양한 측면인, 설계와 개발 도구, 프로그래밍 언어, 특히 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++ 코드가 있다. 제품 크기, 아주 작은

    추천글

    무엇을 기대하는가? 완벽함인가?
    왜 수많은 펌웨어 프로젝트는 기한을 넘기게 되고 버그 때문에 고생하게 될까? 소프트웨어 복잡도와 버그 원인을 다루는 이론은 차고 넘친다. 하지만 가장 직접적인 원인은 코딩이라는 것이 호모 사피엔스(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) / 『임베디드 시스템 대사전』(에이콘출판) 저자


    저자 소개

    콜린 월즈
    • 구분 : 저서
    • 국적 : 기타
    • 분류 : 과학/공학 저자
    • 인기지수 : 31
    최근저서

    25년 이상 전자 산업, 특히 임베디드 소프트웨어에 경험을 쌓아 왔다. 학회와 세미나에서 발표도 하고, 수많은 기술 문서를 작성했고, 임베디드 소프트웨어에 관한 책도 두 권 썼다. 현재 멘토 그래픽스 임베디드 소프트웨어 부서의 마케팅 팀에서 근무한다. 멘토 웹사이트(blogs.mentor.com/colinwalls)에 자주 글을 올린다.

    역자 소개

    허준영
    • 국적 : 대한민국
    • 분류 : 과학/공학 저자
    • 인기지수 : 31
    최근저서

    서울대학교 컴퓨터공학과를 졸업하고 원격 감시 시스템 개발 회사에서 소프트웨어 개발을 시작했다. 여기에서 처음으로 임베디드 시스템을 접하게 되었다. 그 후 잠시 보안 회사에 몸담았다가 서울대학교 컴퓨터공학과 대학원으로 진학해 시스템 소프트웨어와 임베디드 시스템에 대한 연구를 했다. 특히, 초소형 임베디드 시스템인 센서 노드의 시스템 소프트웨어에 대한 연구를 주로 했다. 그리고 2009년에 박사 학위를 받았고 서울대 차세대 융합 기술 연구원에서 웨어러블 컴퓨팅에 대한 연구를 잠시 했다. 그 후 2009년 2학기부터 한성대학교 컴퓨터공학과 교수로 임용되어 현재까지 학생들을 가르치고 있다. 또한 임베디드 소프트웨어 기술 포럼에서 정보기기 소프트웨어 분과장을 맡고 있고, 한국정보통신기술협회(TTA)의 임베디드 소프트웨어 PG에서 위원으로 활동하고 있다. 그리고 임베디드 소프트웨어 경진대회 심사위원으로도 활동하고 있다.

    목차

    목차
    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 주요 개념
    ____

    머리말

    ★ 저자 서문 ★

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

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

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

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

     

    ★ 옮긴이의 말 ★

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

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

     

    배송 시 유의사항

    - 반디앤루니스에서 구매하신 도서는 물류 대행 위탁업체 웅진 북센을 통해 배송됩니다.
     (배송 포장에 "웅진 북센"으로 표기될 수 있습니다.)

    - 구매한 상품의 품질과 배송 관련 문의는 반디앤루니스로 문의 바랍니다.

    - 천재지변 및 택배사의 사정에 따라 배송이 지연될 수 있습니다.

    - 결제(입금) 완료 후 출판사 및 유통사의 사정으로 품절 또는 절판 되어 상품 구입이 어려울 수 있습니다. (별도 안내 예정)

    - 도서산간지역의 경우 추가 배송비가 발생될 수 있습니다.

    반품/교환

    상품 설명에 반품/ 교환 관련한 안내가 있는 경우 그 내용을 우선으로 합니다. (업체 사정에 따라 달라질 수 있습니다)

    반품/교환

    반품/교환
    반품/교환 방법 홈 > 고객센터 > 자주찾는질문 “반품/교환/환불” 안내 참고 또는 1:1상담게시판
    반품/교환 가능 기간 반품,교환은 배송완료 후 7일 이내, 상품의 결함 및 계약내용과 다를 경우 문제발견 후 30일 이내에 신청가능
    반품/교환 비용 변심 혹은 구매착오의 경우에만 반송료 고객 부담(별도 지정 택배사 없음)
    반품/교환 불가 사유
    • 소비자의 책임 사유로 상품 등이 손실 또는 훼손된 경우
    • 소비자의 사용, 포장 개봉에 의해 상품 등의 가치가 현저히 감소한 경우
    • 복제가 가능한 상품 등의 포장을 훼손한 경우 : 예)만화책, 잡지, 화보집 등
    • 시간의 경과에 의해 재판매가 곤란한 정도로 가치가 현저히 감소한 경우
    • 전자상거래등에서의 소비자보호에 관한 법률이 정하는 소비자 청약철회 제한 내용에 해당되는 경우
    • 해외주문 상품(해외 원서)의 경우(파본/훼손/오발송 상품을 제외)
    소비자 피해보상
    환불지연에 따른 배상
    • 상품의 불량에 의한 반품, 교환, A/S, 환불, 품질보증 및 피해보상 등에 관한 사항은
      소비자 분쟁해결 기준(공정거래위원회고시)에 준하여 처리됨
    • 대금 환불 및 환불지연에 따른 배상금 지급 조건, 절차 등은 전자상거래 등에서의
      소비자 보호에 관한 법률에 따라 처리함
    반품/교환 주소 경기도 파주시 문발로 77, 웅진북센(반디앤루니스)
    • 회사명 : (주)서울문고
    • 대표이사 : 김홍구
    • 개인정보 보호책임자 : 김홍구
    • E-mail : bandi_cs@bnl.co.kr
    • 소재지 : (06168) 서울 강남구 삼성로 96길 6
    • 사업자 등록번호 : 120-81-02543
    • 통신판매업 신고번호 : 제2023-서울강남-03728호
    • 물류센터 : (10881) 경기도 파주시 문발로 77 반디앤루니스
    copyright (c) 2016 BANDI&LUNI'S All Rights Reserved