| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
- 백트레이더
- 토플
- 확률
- 토플 라이팅
- 비트코인
- 클라우드
- 자동매매
- AUTOSAR
- realtimesystem
- 블록체인
- Cloud
- 실시간시스템
- can
- 임베디드
- 자동차sw
- 프로그래밍
- 아마존 웹 서비스
- GeorgiaTech
- toefl writing
- 파이썬
- it
- python
- 개발자
- probability
- 오토사
- backtrader
- AWS
- 암호화폐
- TOEFL
- 퀀트
- Today
- Total
목록RTOS (7)
Leo's Garage
느낀점 Problem Statement전통적인 MAC(Medium Access Control) 프로토콜과 제안하는 것과 차이는?논문에 따르면 전통적인 MAC 프로토콜은 센서 네트워크에 적합하지 않다. 이는 센서 네트워크가 기존 Ad hoc 네트워크와 근본적인 면에서 다르기 때문이다. 주요 차이점은 아래와 같다.트래픽 특성: 전통적인 프로토콜은 네트워크 트래픽이 본질적으로 무작위라고 가정하는 경향이 있다. 그러나 이 가정은 센서 네트워크에서는 적용되지 않는다. 센서 네트워크의 메시지는 주로 주기적이며 유한한 지연이 보장되어야 한다. 목표: 전통적인 CSMA 및 그 변형은 시스템 처리량 극대화에 초점을 맞춘다. 센서 네트워크에서는 최적화 목표가 원시 처리량에서 타이밍 제약 조건을 충족하는 비 중복 데이터..
Real Time System을 공부하다보면, Scheduler라는 걸 학습하게 된다.이것은 왜 필요하게 되었을까? 자원은 한정되어 있고, 요청은 많아지기 때문에CPU, Memory, Bus 등 시스템 자원은 유한하다. 동시에 여러 작업이 실행을 요구하는 상황에서, "누가 먼저, 얼마나 오래 실행되는가?"를 정할 필요가 있다.이것이 바로 Scheduling 문제의 본질이다. Scheduler 진화 배경시대시스템 구조스케줄링 필요성해결책1950s단일 프로세스없음 (순차적 실행)수동 제어1960sMultiprogramming 등장CPU idle 줄이기 위해 Task 전환 필요Round Robin, FCFS 등1970sReal-Time OS 등장Task마다 데드라인 생김Rate Monotonic, EDF20..
앞 서 Monolithic Design Approach에 대해서 알아보았다. 말한 것과 같이 Monolithic Design Approach는 구성 요소를 구분하기 보다는 하나의 Binary 형태로 모든 기능 요소를 구성하는 특징이 있다. 만들기 쉽고, 특히나 빠른 개발이 필요한 상황에서는 빛을 발하기 쉽다. (프로토 타입 개발)그러나 이러한 개발방법은 유지보수가 어렵고, 해당 개발을 기준으로 파생 제품을 만들고자 할 때 어려움이 생긴다.가령 데이터 통신 프로토콜 함수 부분과 통신 처리 부분, 연산 부분이 모두 하나로 합쳐져 있는 구조라면, 통신 프로토콜이 변경되었다고 해서 간단하게 그 부분만 수정하기 어려울 수 있다는 것이다. 게다가 Super Loop를 주로 사용하는 개발방법으로 복잡한 시스템을 개발..
임베디드 개발 초기에 사용 가능한 리소스가 적을 때 개발하던 방식이다.좀 뭉뜨그려서 말하면, 하나의 거대한 프로그램 (함수, 바이너리)에 모든 기능을 때려박은 느낌이라고 할까. OS(Operating System)이 아니라 시간 순서에 따라 정해진 Task들이 수행되는 Scheduler를 주로 사용했다.sheduler(){uint32 scheduler_timer = 0;while(){schdeuler_timer++; if(scheduler_timer%0x5 == 0x0) { task_5ms(); } if(scheduler_timer%0xA == 0x0) { task_10ms(); }}아주 간략하게 표현하면 위와 같이 표현할 수 있다. 이런 개발 방..
RTOS의 특징 1. Hard Realtime 2. Scalability 3. Preemptive 4. Multitasking 5. Deterministic 6. Portability 7. Robustness Realtime System : 정해진 시간 내에 임무를 수행하는 시스템 - 소프트 리얼타임 시스템 (Soft RealTime System) : 가능한 한 빠르게 임무를 수행하지만 반드시 정해진 시간 내에 수행할 필요는 없다. (timeout이어도 계속 수행) - 하드 리얼타임 시스템 (Hard RealTime System) : 어떤 사건이 발생했을 때 정확히 동작하는 것은 물론이고 반드시 정해진 시간 내에 그 임무를 마쳐야 한다. (timeout 이면 failure) BootLoader 간단하게 ..
Interrupt - 비동기적인 이벤트의 발생을 처리하기 위한 메커니증 - 인터럽트 발생 시, 문맥을 정리하고 ISR(Interrupt Service Routine)로 점프 - 활성 / 비활성 가능 : 비활성화 시간은 가능한 짧게 해야함 - 지연 시간 (Interrupt Latency) : 비활성화 최대시간 + ISR 최초 명령 시간 [1] Disk -> Interrupt Controller [2] Interrupt Controller -> CPU 위의 두가지를 Masking해서 개별적으로 Interrupt Source를 막을 수 있다. [RTOS에서는 주로 [2]을 Masking한다] Interrupt의 SW 동작은 위와 같다. Main Program을 수행하다가 Interrupt가 발생하면, Inte..
RTOS - Real Time Operating System 쉽게 말해서 실시간 컴퓨팅을 보장하는 운영체제를 뜻한다고 생각하면 된다. RTOS는 일반적으로 임베디드 시스템에서 활용하는데, 보통 임베디드 시스템의 경우 일반 PC보다 성능이 낮다. 그런데 어떻게 성능이 낮은데 실시간을 보장하냐고 할 수도 있지만 High Performance를 보장하는 것과 Real Time을 보장하는 것은 같은 의미가 아니다. High Performance 시스템의 경우 0.1초만에 Task를 수행할 수 있는데 다른 Task에 의해 우선순위를 잃게 되면 2초가 걸릴 수도 있는 시스템이다. 이와 반면에 Real Time System은 어떤 상황에서도 1초 안에 해당 Task를 완료해야 한다면 그것을 최우선 과제로 두고 운영되..