Kernel = 핵심, '운영체제'
: 시스템이 시작할 때부터 메모리에 상주하면서 기본적이고 핵심적인 역할을 수행하는 운영체제의 일부를 말한다.
- Monolithic Structure : 커널에 많은 기능을 모아 합쳐 놓은
- Micro Structure : 핵심적인 부분만 커널에, 나머지는 외부 모듈 형태로 구
- Hybrid
커널은 운영 체제(OS)의 핵심 부분으로, 하드웨어와 소프트웨어 간의 상호 작용을 관리하고 시스템 리소스를 효율적으로 관리합니다. 커널은 운영 체제의 핵심 기능을 제공하며, 다음과 같은 주요 역할을 수행합니다:
1. **자원 관리(Resource Management)**:
- 커널은 시스템 자원을 효율적으로 관리합니다. 이러한 자원에는 CPU 시간, 메모리, 입출력 장치 등이 포함됩니다. 커널은 프로세스 간 자원을 공유하고 할당하여 각 프로세스가 적절한 자원을 사용할 수 있도록 합니다.
2. **프로세스 관리(Process Management)**:
- 커널은 프로세스를 생성, 종료, 일시 정지 및 다시 시작하는 등의 작업을 관리합니다. 이를 통해 여러 프로세스가 동시에 실행될 수 있으며, 프로세스 간의 스케줄링과 우선 순위 부여도 관리됩니다.
3. **메모리 관리(Memory Management)**:
- 커널은 시스템의 메모리를 효율적으로 관리합니다. 이를 위해 가용한 메모리를 할당하고 해제하며, 가상 메모리 관리와 페이지 교체 알고리즘을 사용하여 메모리의 사용량을 최적화합니다.
4. **입출력 관리(I/O Management)**:
- 커널은 입출력 장치와의 통신을 관리하고 데이터 전송을 조정합니다. 이를 통해 디스크, 네트워크, 그래픽 등의 입출력 장치를 효율적으로 사용할 수 있습니다.
5. **파일 시스템 관리(File System Management)**:
- 커널은 파일 및 디렉터리의 생성, 삭제, 읽기, 쓰기 등과 같은 파일 시스템 작업을 관리합니다. 이를 통해 데이터의 영구 저장과 관리가 가능해지며, 사용자 및 응용 프로그램은 파일 시스템을 통해 데이터에 접근할 수 있습니다.
커널은 운영 체제의 중심적인 부분이므로, 시스템의 안정성, 보안성 및 성능에 큰 영향을 미칩니다. 따라서 커널은 신뢰성과 효율성을 높이기 위해 지속적으로 개발되고 최적화되어야 합니다.
플랫폼 Platform
: OS + Middleware + Software
ex) iOS, Android → 임베디드 시스템과 일반 PC는 다르다! Windows는 customizing과 optimizing이 제한적 / 임베디드에서는 Linux 같은 open source를 선호한다.
"Real-Time"
범용 OS와 임베디드 OS의 가장 큰 차이점 : Real-time processing(기능적으로 + 시간적으로 correct 해야한다!)
리얼타임(Real-time) 처리를 위해 범용 운영 체제(General Purpose OS)와 임베디드 운영 체제(Embedded OS)의 차이를 살펴보겠습니다:
1. **반응 시간(Responsiveness)**:
- 범용 운영 체제는 다양한 작업을 처리하기 위해 설계되었으며, 일반적으로 상대적으로 긴 응답 시간을 가집니다. 이는 운영 체제가 여러 작업을 관리하고 사용자와 상호 작용하기 위해 작업을 스케줄링하고 우선순위를 부여하기 때문입니다.
- 임베디드 운영 체제는 주로 실시간 응용 프로그램을 지원하기 위해 설계되었으며, 정확한 시간 요구 사항을 충족하기 위해 특별한 관리 기법을 사용합니다. 이는 응용 프로그램이 명확한 시간 제한 내에 작업을 완료해야 하는 경우에 매우 중요합니다.
2. **스케줄링(Scheduling)**:
- 범용 운영 체제는 다양한 우선순위를 가진 작업을 효율적으로 관리하기 위해 다양한 스케줄링 알고리즘을 사용합니다. 이는 다양한 응용 프로그램 및 사용 사례를 지원하기 위해 유연성을 제공합니다.
- 임베디드 운영 체제는 주로 실시간 응용 프로그램을 위해 선점형 스케줄링(preemptive scheduling)을 사용합니다. 이는 높은 우선순위의 작업이 낮은 우선순위의 작업을 중단시킬 수 있으므로, 시간 제한 내에 작업을 완료할 수 있습니다.
3. **자원 관리(Resource Management)**:
- 범용 운영 체제는 다양한 응용 프로그램이 공유하는 리소스를 효율적으로 관리합니다. 이는 여러 사용자 및 응용 프로그램이 동시에 실행되는 멀티태스킹 환경에서 중요합니다.
- 임베디드 운영 체제는 주로 특정 장치 또는 응용 프로그램에 대한 리소스 관리에 중점을 둡니다. 이는 특정 하드웨어 또는 시스템 제어를 위한 용도로 사용되는 경우가 많습니다.
4. **크기와 성능(Size and Performance)**:
- 범용 운영 체제는 다양한 기능과 사용자 환경을 지원하기 위해 일반적으로 크고 복잡한 구조를 가질 수 있습니다. 이로 인해 리소스 사용량이 높을 수 있으며, 특히 임베디드 시스템에서는 부적절할 수 있습니다.
- 임베디드 운영 체제는 주로 작고 경량화된 구조로 설계되어 있으며, 작은 메모리 공간에서도 효율적으로 실행될 수 있습니다. 따라서 리소스 사용량이 적고 빠른 응답 시간을 제공하는 것이 중요합니다.
이러한 차이점들은 각각의 운영 체제가 다른 사용 사례와 요구 사항을 충족하기 위해 설계되었음을 보여줍니다. 따라서 리얼타임 처리를 위한 시스템을 선택할 때는 해당 시스템의 요구 사항과 환경을 고려하여 적절한 운영 체제를 선택하는 것이 중요합니다
- Soft Real Time
: 요청에 대한 응답 시간이 확정적이지는 않다 / 완료시점을 예측할 수 없다 / ex- File Copy
- Hard Real Time
: 요청에 대한 응답 시간이 확정적이다 / 편차가 어느 정도는 있을 수 있다 / ex- 의료용 기기, video streaming
Realtime OS를 쓰면 Hard Real Time이 보장될까?
· RTOS vs bare metal
· Multitasking vs Single Task
Real-time OS(RTOS)를 사용하는 것이 Hard Real Time을 보장한다는 것은 항상 참이 아닙니다.
하드 리얼타임(Hard Real Time)을 보장하려면 여러 가지 요소를 고려해야 합니다.
여기에는 RTOS의 설계, 구현, 하드웨어 및 소프트웨어의 특성 등이 포함됩니다.
1. **RTOS vs Bare Metal**:
- RTOS를 사용하는 경우, 운영 체제가 시스템 리소스 및 작업을 관리하기 때문에 여러 작업 간의 우선순위 및 스케줄링을 관리할 수 있습니다. 이를 통해 하드 리얼타임 요구 사항을 충족하는데 도움이 될 수 있습니다.
그러나 RTOS 자체가 하드 리얼타임을 보장하지는 않습니다. 운영 체제의 내부 동작, 스케줄링 알고리즘 및 시스템 부하에 따라 하드 리얼타임 요구 사항이 충족되지 않을 수 있습니다.
- Bare Metal 환경에서는 RTOS가 아닌 운영 체제가 없으므로 시스템의 전체 제어를 프로그래머가 직접 관리해야 합니다. 이 경우 하드웨어와 소프트웨어의 상호 작용을 더 명확하게 이해하고 제어할 수 있으며, 이로 인해 하드 리얼타임 성능을 더 잘 보장할 수 있습니다.
2. **Multitasking vs Single Task**:
- Multitasking 환경에서는 여러 작업이 동시에 실행되고, 우선순위 및 스케줄링 알고리즘에 따라 작업이 관리됩니다. 이러한 환경에서는 하드 리얼타임 성능을 보장하기 위해 RTOS가 사용될 수 있습니다. 그러나 실제로 하드 리얼타임을 보장하기 위해서는 작업의 우선순위, 스케줄링 및 인터럽트 처리 등의 요소를 고려해야 합니다.
- Single Task 환경에서는 하나의 작업만 실행되며, 우선순위 및 스케줄링에 대한 복잡성이 줄어들지만, 하드 리얼타임을 보장하기 위한 추가적인 제어 및 최적화가 필요합니다. 일부 하드 리얼타임 응용 프로그램에서는 Single Task 환경이 더 적합할 수 있습니다.
요약하면, RTOS를 사용하는 것이 하드 리얼타임을 보장한다는 것은 단순히 말할 수 없습니다.
시스템의 전반적인 설계, 구현 및 운영 환경에 따라 달라질 수 있습니다.
RTOS는 하드 리얼타임 요구 사항을 충족하는 데 도움이 되지만, 이를 보장하기 위해서는 추가적인 설계 및 검증이 필요할 수 있습니다.
Real-Time Embedded Systems 특성
1) Multi-tasking
: appear to be performing multiple tasks simultaneously ; generally acceptable to rapidly switch from performing one task, to the next
Example.
전기 모터 제어 작업을 50Hz 속도로 업데이트하고
사용자 상태 표시를 10Hz 속도로 업데이트
- 모터 제어코드 실행 시간 worst 5ms
- 사용자 상태표시 인터페이스 전송 10ms
- 누굴 먼저?
- 모터제어작업의 시간적 정밀도가 더 높으므로 우선순위 높음 : hard real time
- 사용자는 수ms 차이를 알아채기 어려우므로 우선순위 낮음 : soft real time
* Embedded system control loop timing
Preemptive multitasking은 운영 체제(OS)의 한 종류로, 여러 프로세스 또는 스레드가 동시에 실행되는 것처럼 보이도록 하는 기술입니다. 이것은 각 프로세스나 스레드가 CPU를 고유하게 소유하는 것이 아니라, 일정한 시간 간격으로 CPU를 차지할 수 있는 권한을 부여받습니다. 그리고 운영 체제는 이러한 프로세스나 스레드들 간에 우선순위를 관리하여 시스템의 전체적인 효율성을 유지합니다.
Preemptive multitasking의 핵심은 시스템이 일시적으로 실행 중인 작업을 중단하고 다른 작업에 CPU를 할당할 수 있다는 점입니다. 이것은 각 프로세스나 스레드가 일정 시간 동안 CPU를 독점적으로 사용하는 것을 방지하고, 여러 작업들이 동시에 진행되는 것처럼 보이게 합니다.
이러한 방식으로 운영 체제는 다양한 프로그램들이 동시에 실행되는 것처럼 보이도록 하며, 시스템 자원을 효율적으로 활용할 수 있도록 지원합니다. 이는 현대 운영 체제에서 매우 일반적인 기능 중 하나이며, 다중 사용자 시스템과 다중 작업 환경에서 필수적입니다.
* Status update split into two parts(2개의 task를 별도 루틴으로 분할, 각 루틴은 최대 10ms 까지만 실행되도록 설계)
* Task 1이 실행되는 도중에도 Task 2가 간섭하여 제어 루프의 정확한 타이밍을 유지하기 위해 Task 1을 중단하고 Task 2를 실행할 수 있습니다.
임베디드 시스템에서의 멀티 테스킹은 다양한 작업들을 동시에 수행하면서 시스템의 효율성과 신뢰성을 유지하는 것을 의미합니다. 여기서는 Embedded system control loop timing과 Status update split into two parts 두 가지 관점에서 각각 2개의 task를 예시로 들어 설명하겠습니다.
1. Embedded system control loop timing 관점:
- Task 1: 센서 데이터 수집 및 처리
- Task 2: 액추에이터 제어 및 출력
Embedded system은 주로 실시간 제어를 위해 사용되며, 제어 루프의 타이밍이 매우 중요합니다.
Task 1은 주로 센서로부터 데이터를 읽어와서 이를 처리하는 작업을 수행합니다.
Task 2는 이러한 처리된 데이터를 기반으로 액추에이터를 제어하여 시스템의 동작을 조절합니다.
이 경우, 제어 루프의 주기는 매우 중요합니다.
예를 들어, Task 1은 10ms마다 센서 데이터를 읽고, Task 2는 그 데이터를 바탕으로 액추에이터를 제어하고 출력을 업데이트합니다. 이러한 제어 루프의 시간은 각 task의 우선순위와 실행 시간에 따라 스케줄되어야 합니다.
이를 위해 Preemptive multitasking이 사용될 수 있습니다. Task 1이 실행되는 도중에도 Task 2가 간섭하여 제어 루프의 정확한 타이밍을 유지하기 위해 Task 1을 중단하고 Task 2를 실행할 수 있습니다.
2. Status update split into two parts 관점:
- Task 1: 상태 업데이트 전 처리
- Task 2: 상태 업데이트 후 처리
이러한 경우, 시스템은 상태 업데이트를 수행하는 데 시간이 소요되며, 이를 두 부분으로 분할하여 처리할 수 있습니다. Task 1은 상태 업데이트 전 처리를 담당하고, Task 2는 상태 업데이트 후 처리를 담당합니다.
Task 1은 이전 상태를 저장하고 새로운 데이터를 받아들여 처리합니다.
Task 2는 이전 상태와 새로운 상태 간의 변화를 분석하고, 이에 따른 동작을 수행합니다.
이 경우에도 Preemptive multitasking이 사용될 수 있습니다. Task 1이 실행되는 도중에도 Task 2가 실행되어야 할 필요가 있을 때, 운영 체제는 Task 1을 일시 중단하고 Task 2를 실행할 수 있습니다. 이를 통해 시스템은 상태 업데이트를 신속하게 처리하고, 동시에 다른 작업을 수행할 수 있습니다.
2) Rate-monotonic scheduling
Rate Monotonic Scheduling(RMS)은 실시간 시스템에서 사용되는 작업 스케줄링 알고리즘 중 하나입니다. 이 알고리즘은 각 작업에 대해 주기가 고정된 환경에서 사용됩니다. RMS는 작업의 주기에 따라 우선순위를 할당하여 스케줄링을 수행합니다. 주기가 더 짧은 작업일수록 더 높은 우선순위를 부여받습니다. 다음은 RMS의 주요 특징과 동작 방식입니다:
1. **고정된 주기(Periodic Task)**:
각 작업은 고정된 주기로 반복 실행됩니다.
즉, 작업이 주기적으로 발생하며, 주기는 변하지 않습니다.
2. **우선순위 할당**:
작업의 주기가 짧을수록(즉, 주기가 더 빠를수록) 해당 작업에 더 높은 우선순위가 할당됩니다.
이는 Rate Monotonic Priority Assignment Rule에 따라 결정됩니다.
이 규칙에 따르면 주기가 더 짧은 작업이 더 높은 우선순위를 가집니다.
3. **최소 반복 시간 스케줄링(Minimum Slack Scheduling)**:
RMS에서는 작업의 최소 반복 시간을 고려하여 스케줄링을 수행합니다.
즉, 주어진 작업이 실행될 수 있는 최소 시간까지 대기한 후에야 다음 작업을 수행합니다.
4. **스케줄 가능성(Test for Schedulability)**:
RMS는 스케줄 가능성을 평가하는 데 사용될 수 있습니다.
즉, 모든 작업이 주어진 시간 내에 실행될 수 있는지 여부를 확인할 수 있습니다.
Rate Monotonic Scheduling은 간단하고 효율적인 알고리즘이지만, 모든 상황에서 최적의 성능을 보장하지는 않습니다. 특히, 작업의 실행 시간이 주기보다 길거나 작업 간의 우선순위가 바뀌는 경우에는 다른 스케줄링 알고리즘이 더 적합할 수 있습니다.
RMS에서 "작업 스케줄링 및 컨텍스트 전환에 소요되는 시간은 무시할 만하다"는 것은 이러한 작업들이 시스템의 전체 성능에 미치는 영향이 매우 작다는 것을 의미합니다.
여기서 "작업 스케줄링"은 새로운 작업이 도착할 때 이를 스케줄링하여 실행 시간을 할당하는 과정을 의미합니다. "컨텍스트 전환"은 현재 실행 중인 작업에서 다음으로 실행될 작업으로 CPU의 제어권을 전환하는 과정을 의미합니다.
RMS에서는 작업들의 주기에 따라 우선순위를 할당하고, 스케줄링을 수행할 때에는 이러한 작업들의 주기를 고려하여 진행됩니다. 그리고 이 알고리즘에서는 작업 스케줄링과 컨텍스트 전환이 빠르게 이루어진다고 가정합니다. 이러한 전제 아래에서는 이러한 작업들이 시스템의 전체 성능에 미치는 영향이 무시할 만큼 작다고 가정할 수 있습니다.
따라서, "시간을 무시할 만하다"는 것은 해당 작업들이 전체 시스템의 동작에 미치는 영향이 미미하며, 시스템의 성능을 평가할 때 고려할 필요가 없다는 것을 의미합니다.
RMS에서 최대 프로세서 활용도(최대 CPU 사용률)가 발생하는 이유는 작업의 주기와 우선순위에 따라 CPU가 할당되는 방식에 있습니다. RMS에서는 작업의 주기가 짧을수록 더 높은 우선순위를 가지므로, 주기가 짧은 작업이 CPU를 더 많이 사용하게 됩니다. 따라서, 모든 작업의 주기가 매우 짧고 CPU 사용률이 최대화되는 상황에서 최대 프로세서 활용도가 발생합니다.
이러한 최대 프로세서 활용도에 대한 상한선은 RMS 알고리즘에서의 한계를 나타내는데 사용됩니다. 이 상한선은 모든 작업이 동시에 CPU를 최대로 활용할 때 시스템이 적절히 작동할 수 있는 한계를 나타냅니다. 만약 이 상한선을 초과하는 경우, 시스템이 과부하 상태에 빠지거나 작업들이 높은 우선순위 작업에 의해 늦추어질 수 있으므로 스케줄링 불가능한 상황이 될 수 있습니다.
따라서, RMS에서의 최대 프로세서 활용도와 그에 대한 상한선은 시스템의 스케줄링 가능성을 평가하고, 시스템이 안정적으로 동작할 수 있는지를 결정하는데 중요한 요소입니다.
RMS에서 "total processor utilization (전체 프로세서 활용도)"는 모든 n개의 작업에 대한 프로세서 활용도의 합을 의미합니다. 여기서 n은 작업의 수를 나타냅니다.
식 "n(2^(1/n) - 1)"은 RMS의 스케줄링 가능성을 평가하는데 사용되는 Upper Bound를 나타냅니다.
여기서 "2^(1/n)"은 n개의 작업 중 가장 높은 우선순위 작업의 주기를 가지고 있는 작업의 CPU 사용률을 의미합니다. 이 값을 1에서 뺀 이유는 CPU 사용률이 아닌 Idle 시간(사용되지 않는 시간)을 나타내기 위함입니다. 따라서 "2^(1/n) - 1"은 가장 높은 우선순위 작업의 CPU 사용률입니다.
그런 다음, n을 곱하여 모든 작업에 대한 CPU 사용률을 합산합니다. 이 값은 "n(2^(1/n) - 1)"입니다.
이 값이 1보다 작거나 같은 경우, 모든 작업이 스케줄링 가능하다는 것을 의미합니다. 즉, 주어진 시스템에서 RMS가 작업들을 성공적으로 스케줄링할 수 있는지를 확인하는데 사용됩니다.
??
RMS에서의 최대 프로세서 활용도를 계산하는 방법은 다음과 같습니다:
1. **Rate Monotonic Priority Assignment Rule 확인**:
먼저, 각 작업에 대해 Rate Monotonic Priority Assignment Rule을 적용하여 우선순위를 결정합니다. 이 규칙에 따라 주기가 짧은 작업에 더 높은 우선순위가 할당됩니다.
2. **작업의 CPU 사용률 계산**:
각 작업에 대해 CPU 사용률을 계산합니다. CPU 사용률은 작업의 실행 시간을 주기로 나눈 값입니다. 즉, 작업의 CPU 사용률은 실행 시간 / 주기로 계산됩니다.
3. **최대 프로세서 활용도 계산**:
각 작업의 CPU 사용률을 합산하여 최대 프로세서 활용도를 계산합니다. 이것은 모든 작업의 CPU 사용률의 합으로 표현됩니다.
여기서 중요한 점은 RMS에서는 모든 작업의 CPU 사용률의 합이 특정한 상한선 이하여야 합니다. 이것이 바로 RMS의 스케줄링 가능성을 평가하는데 사용되는 조건 중 하나입니다. 만약 이 상한선을 초과한다면, 시스템이 스케줄링 불가능한 상태에 빠질 수 있습니다.
따라서, RMS에서의 최대 프로세서 활용도를 계산하는 방법은 각 작업의 CPU 사용률을 합산하여 이 값을 확인하는 것입니다.
RTOS Linux
1) 개방성
- 리눅스 배포판 : 리눅스의 표준 요소들과 여러 가지 관리 툴, 필수 application의 집합 (Ubuntu, Debian, Android)
2) 네트워킹
- 초고속 연결시대 : 메타버스, 사물인터넷 등
- 성능 + 보안이 핵심
- Linux는 오픈 소스이지만 침입하기가 매우 어렵기 때문에 다른 운영 체제와 비교할 때 매우 안전한 OS
· User Privilege
- 슈퍼 유저(root)
- 일반 유저
· Kernel Space에서 실행되는 프로세스는 당연히 root 권한으로 동작, User Space에서는 일반 유저 모드 동작 가능
· User Space의 프로세스들이 시스템 리소스들에 접근하고 싶으면 - System Call(Recall - 프로세서에서의 System Call)
*Android
: Linux의 수많은 후손 중 하나이지만 임베디드 OS에서의 괴물 Platform - 구글의 서포트 + 하드웨어의 발전
: 안드로이드 어플리케이션은 Virtual Machine 상에서 동작 / VM이 가능한 수준으로 하드웨어가 발전
가상 머신(Virtual Machine, VM)은 하나의 물리적인 컴퓨터 시스템 안에서 여러 개의 가상적인 컴퓨터 시스템을 구축하는 기술이나 소프트웨어 환경을 말합니다. 각 가상 머신은 독립적으로 운영 체제(OS)와 응용 프로그램을 실행할 수 있습니다. 이러한 VM은 물리적인 하드웨어 리소스를 가상화하여 여러 개의 가상 환경을 동시에 운영할 수 있도록 합니다.
가상 머신은 다음과 같은 주요 특징을 갖습니다:
1. **하드웨어 가상화**:
가상 머신은 물리적인 하드웨어를 가상화하여 여러 개의 가상 시스템을 동시에 실행할 수 있게 합니다.
각 가상 머신은 가상 CPU, 메모리, 디스크, 네트워크 인터페이스 등을 갖습니다.
2. **독립성**:
각 가상 머신은 독립적인 운영 체제를 실행하며, 하나의 가상 머신이 다른 가상 머신에 영향을 미치지 않습니다.
이는 가상 머신 간에 서로 영향을 주지 않고 독립적으로 운영 체제 및 응용 프로그램을 설치하고 실행할 수 있음을 의미합니다.
3. **리소스 분할 및 관리**:
가상 머신은 물리적인 하드웨어 리소스를 분할하여 여러 개의 가상 환경에 할당할 수 있습니다.
이를 통해 서버의 리소스를 효율적으로 관리하고 가상 환경 간에 리소스를 공유할 수 있습니다.
4. **이식성**:
가상 머신은 호스트 시스템의 하드웨어와 운영 체제에 독립적이므로, 다양한 호스트 시스템에서 동일한 가상 머신을 실행할 수 있습니다.
이는 애플리케이션의 이식성을 향상시키고, 개발 및 배포 프로세스를 간소화할 수 있습니다.
가상 머신은 다양한 용도로 사용되며, 개발 및 테스트 환경, 서버 가상화, 클라우드 컴퓨팅 등에서 널리 사용됩니다. 주요 가상화 소프트웨어로는 VMware, VirtualBox, Hyper-V 등이 있습니다.
*라즈비안
: Linux 배포판 중 하나인 데비안으로부터 만들어진 라즈베리파이 전용 OS - 가볍지만 mini PC를 위한 OS에 가까움
*리눅스 빌드
: 리눅스 커널 다운로드 - 빌드 in target board / cross compile
부트로더
: 임베디드 전용 SW
임베디드 디바이스에서 가장 우선적으로 필요한 것 = 켜지는 것(booting)
→ HW와 SW 협업이 필요한 부분
(회로 설계 - 보드&하드웨어 디버깅 - 보드 브링업(target board에 불이 켜지고 동작하는 상태로 만드는 초기 작업) - 안 켜지면 cold booting 실패)
· Cold booting
- 완전히 리셋된 상태에서 시스템을 깨우는 것
- 통상적인 booting이라고 불리는 프로세스
· Warm booting
- 간단히 IDLE에서 벗어나는 SW적 프로세스
"idle"은 컴퓨팅에서 사용되는 용어로, 시스템이 현재 아무런 활동을 수행하지 않는 상태를 가리킵니다.
즉, CPU가 어떠한 작업도 처리하지 않고, 시스템이 대기 상태에 있는 것을 의미합니다.
일반적으로 CPU가 idle 상태에 있을 때는 다음과 같은 상황이 발생할 수 있습니다:
1. **작업 부족**:
시스템에 실행할 작업이 없거나, 현재 실행 중인 모든 작업이 완료된 상태입니다.
CPU는 어떠한 작업도 처리하지 않고 대기하고 있습니다.
2. **대기 시간**:
시스템이 외부 이벤트나 입력을 기다리는 경우에도 CPU는 idle 상태에 있을 수 있습니다.
예를 들어, 사용자 입력이나 외부 디바이스의 응답을 기다리는 동안 CPU는 대기 상태에 있을 수 있습니다.
3. **절전 모드**:
일부 컴퓨터 시스템은 사용자가 설정한 조건에 따라 CPU나 다른 하드웨어를 절전 모드로 전환할 수 있습니다.
이 경우에도 CPU는 idle 상태에 있지만, 전력 소비를 최소화하여 에너지를 절약합니다.
CPU가 idle 상태에 있을 때는 시스템 자원을 다른 작업에 할당할 수 있습니다.
예를 들어, 다른 프로세스나 스레드가 실행되거나, 시스템 리소스가 다른 목적으로 사용될 수 있습니다.
따라서 idle 상태는 시스템의 효율성을 유지하고 자원을 효과적으로 활용하기 위해 중요한 개념입니다.
·Power saving mode
- standby mode
- 기본 HW들은 active한 상태 (micro processor or power management IC)
- power on하면 micro processor가 시스템을 깨움
· Boot, Bootstrap, Bot code : 모두 같은 말 / Firmware / 시스템에 전원 들어오면 가장 먼저 수행되는 SW
· Loader
- 다른 SW를 읽어서 실행시키는 SW
- OS에 들어가는 부트로더, OS 없는 부트로더, SoC vendo에서 제공하는 부트로더
- 임베디드 월드의 일반적인 부트로더 -> u-boot
· U-boot
- 리눅스나 안드로이드 운영체제를 사용하는 거의 모든 임베디드 디바이스의 부트로더
- 대다수 플랫폼에 활용 가능 + 다양한 툴 제공
- Command line interface로 UART를 통해 수행
