떡밥위키
최근 변경
최근 토론
특수 기능
파일 올리기
작성이 필요한 문서
고립된 문서
고립된 분류
분류가 되지 않은 문서
편집된 지 오래된 문서
내용이 짧은 문서
내용이 긴 문서
차단 내역
RandomPage
라이선스
IP 사용자
216.73.216.107
설정
다크 모드로 전환
로그인
서버 점검 공지
|
개인정보 처리방침 개정 안내
임베디드 시스템
(r1 문단 편집)
닫기
RAW 편집
미리보기
== 특징 == * 안정성 임베디드 시스템을 쓰는 가장 큰 이유이자 목적이다. 필요 없는 기능을 최대한 제거하고 필수적인 기능만 남겨 장기간 동안 해당 목적에 대해 안정적인 동작을 보장해 줘야 하며 이 때문에 시스템에는 최대한 검증된 부품들과 하드웨어와 소프트웨어를 넘나드는 안전장치가 탑재되어 사용자의 별도 조치 없이도 리셋이나 백업 장치 작동으로 작업의 안정성을 보장해 주며 이런 조치 덕분에 일반적인 소비자용 전자 기기보다 장기간 가혹한 환경에서도 오래 버텨주며 극단적으로 갈 경우 수십 년 지나도 멀쩡해서 그냥 쓰는 경우도 많다.[* 대표적인 예시로 미 공군 전략 사령부가 쓴 [[https://www.yna.co.kr/view/AKR20191025058600009|IBM 시리즈 1과 8인치 플로피 시스템]]으로 50년 가까이 되었으나 퇴출 안 된 이유가 "아직 작동하니까" 일 정도다.] * 하드웨어 지식 펌웨어를 포함하는 임베디드 시스템은 시스템 회로 및 관련 하드웨어에 대한 지식이 필수적이다. 펌웨어나 단순한 앱 프로그래밍 정도 알아서는 디렉팅 및 기획을 할 수가 없다. 시스템 아키텍처, 아날로그 회로, 디지털 로직, 네트워크 통신, EMI/EMC, Safety, 프로토타입 제작, 메커니컬 디자인까지 알아야 한다. 즉, 하드웨어/펌웨어/소프트웨어 디자인을 모두 섭렵한 사람만이 임베디드 시스템 디자인이 가능하다.[* 이건 좀 알아두어야 할 것이 별도의 HW팀이 존재하는 경우, 기초정도만 알아도 큰 문제는 없다. ] * [[프로그램 최적화]] 임베디드 시스템의 디바이스들은 절제된 리소스를 사용하므로 메모리 리크, 힙/스택 관리 등과 함께 효율적 코딩이 필요하다. 같은 동작을 하는 앱을 일반 응용 소프트웨어 개발자가 작성한 코드와 임베디드 설계자가 작성한 코드를 비교해 보면 임베디드 코드가 압도적으로 간결하고 정갈한 경우가 많다. 2010년대 중반에 접어들면서 마이크로프로세서의 성능 향상과 더불어 고급 라이브러리들이 많이 공개되면서 예전과 같은 어려운 코딩의 필요성이 줄어들었다. 플래시나 SRAM 등 메모리 용량이 적은 로 코스트 칩 경우 프로그램 최적화가 중요한 편이며 위와 같은 문제 때문에 개발의 편의성을 내세우는 인터프리터 언어들이 주류가 된 2000년대 이후에도 임베디드 시스템들은 C/C++ 등의 언어가 주도하며 어셈블리어도 자주 사용된다. [* 아주 특이한 케이스가 아닌 이상은 컴파일러의 발전으로 C/C++로 프로그래밍 해도 어셈블리 어로 작성하는것과 최종 바이너리의 사이즈 차이가 나지 않는 경우가 많아져 어셈블리 어까지 가는 경우는 거의 보기 힘들어지긴 했으나 어셈블리 언어가 쓰이는 경우는 (1)HAL등 추상화 라이브러리에서 발생하는 오버헤드를 어떻게든 줄여 성능을 극한으로 끌어내거나 uA 단위의 절전 최적화를 위한 일환 (2)1KB 이하의 초 저용량 프로그래밍 (3)제조사가 C/C++ 사용을 위한 툴체인을 제공하지 않는 구형 칩인 경우 등등이 있다. ] * 주변 디바이스와 연관된 알고리즘 마이크로프로세서에 의해 수행되는 명령은 주변 디바이스를 직접 제어하기 때문에 안전성이나 정밀도 요구 사항이 더 높다. 자동차 엔진을 컨트롤하는 [[ECU]] 마이크로프로세서의 경우 차의 연비를 높이면서 공기 오염을 최소화함과 동시에 차의 퍼포먼스를 높이기 위한 복잡한 필터링 알고리즘을 수행한다. * 실시간 처리 지원 임베디드 RTOS에서 말하는 실시간이란 빠른 실행을 의미하는 것이 아니라 어느 시간 때 태스크가 실행됨을 파악할 수 있음을 의미한다. Tick 타임과 Task Priority 등의 태스크 스케줄링이 특징이다. Async, 멀티태스크/스레드, 멀티코어 등의 Concurrent/Parallel 프로그래밍 기법이 필요하다. 1997년 화성에 착륙한 탐사선 [[마스 패스파인더]]는 착륙 후 화성의 기상 정보를 지구로 전송하는 과정에서 RTOS의 Priority Inversion 버그가 생기는 바람에 데이터들이 제시간 안에 처리되지 못했고, Watchdog 타이머에 의해 시스템은 스스로를 리셋했다. 이후 다시 기상 정보를 수집해 지구로 보내는 과정에서 같은 일이 반복해서 발생하면서 탐사 임무를 제대로 수행하지 못한 일이 발생한 적이 있다. 이런한 태스크 우선순위 버그를 해결하기 위한 RTOS 프로그래밍 기법들이 있다. RTOS에는 무료인 freeRTOS와 유료인 Nucleus, VxWorks 등이 있다. [[Linux]] 또한 실시간 처리를 지원하고 있다. * UX 특정 목적의 사용자 인터페이스를 디자인한다. 임베디드 시스템의 유저 인터페이스는 마이크로컨트롤러 전용의 GUI 라이브러리를 사용하는 경우 또는 리소스가 넉넉한 시스템에서는 기존 OS의 애플리케이션 GUI 라이브러리를 사용하며 양쪽 시스템간의 독립된 안정성을 보장하기 위해 UX를 그리는 시스템과 실제 제어를 담당하는 시스템이 별도로 제작되어 연동되는 방식인 경우도 많다[* 주로 산업기계용 PLC-HMI(휴먼-머신-인터페이스)등이 대표적이다.] * 멀티레이트(Multirate) 멀티스트림 등의 실시간 작업은 여러 개가 동시에 일어나기도 한다. 태스크별로 slow rate과 fast rate로 수행되도록 동시에 컨트롤해야 한다. 멀티미디어를 예로 들면, 스트리밍되는 오디오 부분과 비디오 부분은 서로 rate가 다르지만, 반드시 동기화되어야 한다.
요약
문서 편집을
저장
하면 당신은 기여한 내용을
CC BY-NC-SA 2.0 KR
또는
기타 라이선스 (문서에 명시된 경우)
로 배포하고 기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다. 이
동의는 철회할 수 없습니다.
비로그인 상태로 편집합니다. 로그인하지 않은 상태로 문서 편집을 저장하면, 편집 역사에 본인이 사용하는 IP(216.73.216.107) 주소 전체가 영구히 기록됩니다.
저장
사용자
216.73.216.107
IP 사용자
로그인
회원가입
최근 변경
[불러오는 중...]
최근 토론
[불러오는 중...]