임베디드250702 - RTOS
Thread가 여러개 동작하고 있을 때 Thread에 값을 직접 전달하는 방식은 사용하지 말아라
❌ 데이터 일관성 보장 실패
어떤 스레드는 hour, min, sec 등을 업데이트하고 있을 때
다른 스레드가 그 구조체를 참조하면 불완전한 값을 참조하게 됨
❌ RTOS의 철학에 어긋남
RTOS는 스레드 간 독립성을 강조합니다.
직접 전달은 의존성이 강하고 결합도가 높아집니다.
안전한 방식설명
| 큐 (Queue) | RTOS가 제공하는 스레드 간 통신용 구조. 데이터를 복사해서 전달하므로 안전 |
**"Stack Size"**는 **각 쓰레드(thread)**나 함수 호출 시 사용할 수 있는 임시 저장 공간의 크기
그리고 그 단위가 **“Words”**(Words의 크기는 CPU마다 다름, CPU가 한 번에 몇 비트를 읽고 쓸수 있냐)
인텔/AMD의 현대적인 CPU (예: i5, i7, Ryzen 등)는 모두 64-bit 아키텍처
heap 영역에 각 thread의 독립 공간이 만들어짐
thread마다 register(정보, 즉 program counter, stack pointer, register 연산 등)가 필요. 이 register를 또 따로 저장해줘야하는 공간이 필요
->TCB라고 하는 저장공간을 가지고 있음
TCB( Task Control Block ): Thread를 관리하는 정보가 있다~ 이정도만
Ready에 있는 것중 우선순위가 가장 높은 것을 Running에 올림
우선순위가 낮은게 동작중이었는데 우선순위 높은게 들어오면 Running에 있던 것이 Ready로 빠짐
또한 전부 task 우선순위를 대부분 높이면 실행되지 않는 task가 생길 수도 있음
에어백 이런 것들은 우선순위를 제일 높여놓고 일반적으로는 RoundRobin Scheduling
✅ Round Robin 스케줄링이란?
⏲️ **시간을 일정한 단위(Time Slice)**로 쪼개서
모든 태스크에게 차례로 CPU를 나눠주는 방식
- 모든 태스크는 순서대로 돌아가면서 실행됨
- 실행 시간(Time slice)이 끝나면 다음 태스크로 자동 교체
Hard RT(real time), Soft RT(real time)이 있는데 에어백, 무기 같은 것들은 ns단위까지 측정하는 Hard RT를 사용
✅ 우선순위 높은 태스크가 Ready로 오면,
현재 실행 중인 태스크가 끝나지 않았더라도
→ 즉시 선점하고 실행됩니다 (선점형 스케줄러일 경우)
❌ 실행 중인 태스크가 끝날 때까지 기다리진 않아요.
우선순위가 높은 task가 낮은상태의 것을 running에서 빼내고 본인이 running상태로 간다!
(즉 코드 실행중에 우선순위 낮은 task는 코드를 중간에 멈추고 다시 실행 그래서 TCB가 필요!)
센서랑 통신 중이었는데(연속성이 필요한 경우) 만약 우선순위가 높은 task가 들어오면 그 센서 data는 날라감?
->문제가 생길 수 있음, 우선순위 높은게 더 중요하니깐
-> 다시 동작하게 하거나 그래야 함
현재 우리의 RTOS stack
우리가 흔히 말하는 SW는 맨 윗단, 실제로 HW적으로 구성된 것들이 아랫단
그 사이에 있는 것을 "Middle ware"라고 하며 대표적으로 OS가 들어감
Middleware에서 HW까지를 platform이라고 함
주의할 점 Task안에 꼭 osDelay(1)이상인 명령어가 있어야 한다.
extern으로 qBtnLed를 선언해서 공유메모리에서 사용하게 함
freertos.c에
헤더 추가하고
button task에 위와 같이 작성
Led task에 위와 같이 작성
교육용으로 공유자원 LCD 추가!
Button과 Led가 동시에 사용할려고하니깐 LCD 깨지는 현상 발생
-> mutex사용
LCD 잘 나옴
즉, 스레드 간에 구조체 데이터를 주고받기 위한 큐를 만드는 정의문
자동으로 que를 만들어줌
위와 같이 mail queue를 이용해서 btnData에 동적 메모리를 할당하고 , 값 채워서 큐에 넣는 절차를 만들어줌
그럼 Led에서는 이 주소를 get하면 됨
큐를 만드는 생성절차인데
이 4개의 공간이 꽉찰 수 있음.
따라서 이것이 자리가 빌때까지 대기를 하는 이유임
그전에 btnMail을 선언해줘야 함
thread하나 만들 때 메모리를 꽤 많이 사용 (stack영역도 잡히고, 관리해주는 TCB 공간도 잡히고 등)
인터럽트하고 thread는 다름
인터럽는 HW, thread는 SW
HW가 더 절대적으로 우선순위가 높을 수 있음
과제
FND 정지 스타트
공유메모리는 보통 thread 2개가 공유하는게 맞음 다른 곳에서 get하면 다른 thread에서 못 쓸수도 있으니깐