반응형
250x250
Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 | 29 | 30 | 31 |
Tags
- toefl writing
- python
- backtrader
- 퀀트
- realtimesystem
- 파이썬
- 토플
- 개발자
- 토플 라이팅
- 확률
- 클라우드
- it
- 아마존 웹 서비스
- probability
- 자동차sw
- 블록체인
- 프로그래밍
- Cloud
- AWS
- TOEFL
- 실시간시스템
- AUTOSAR
- 임베디드
- 암호화폐
- 오토사
- 백트레이더
- GeorgiaTech
- can
- 비트코인
- 자동매매
Archives
- Today
- Total
Leo's Garage
Monolithic Design Approach 본문
728x90
반응형
임베디드 개발 초기에 사용 가능한 리소스가 적을 때 개발하던 방식이다.
좀 뭉뜨그려서 말하면, 하나의 거대한 프로그램 (함수, 바이너리)에 모든 기능을 때려박은 느낌이라고 할까.
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없이 특정 센서나 특정 동작을 반복해서 수행하는 어플리케이션에 사용된다.
복잡한 기능은 기대하기 어려운 방식이다.
이런 경우에 한 번 개발을 완료해 놓으면, 수정이 쉽지 않은데 모든 기능요소들이 하나의 바이너리에 구성되어 있기 때문이다.
단적인 예로 이런 구조는 Single Core에 Single Application에 적합하지 Multi Core, Multi Application에 사용하기는 적절하지 않다.
각 Task들이 정해진 순서로만 동작하기 때문에 가장 마지막에 실행되는 Task는 위에 모든 Task들을 거쳐온 다음에야 실행이 가능하다.
따라서 현대의 Multi Core 기반 Application들은 이 방식을 채택하지 않는다.
728x90
반응형
'Study > Real Time Systems' 카테고리의 다른 글
| Priority-Driven Scheduling of Periodic Tasks (Dynamic Priority) - 2 (1) | 2025.06.08 |
|---|---|
| Priority-Driven Scheduling of Periodic Tasks (Dynamic Priority) - 1 (1) | 2025.06.08 |
| Scheduler라는 개념은 왜 필요한가? (0) | 2025.05.12 |
| RTS 환경 하에 Mutex, Semaphore 그리고 Spinlock 비교 (0) | 2025.04.22 |
| Reference Model (0) | 2025.04.20 |
