1. 먼저 POSIX 규칙을 따른 pthread형식으로 작성된 프로그램은 eCos에서도 동일하게 잘 동작합니다. ^^
2. Micro- ITRON으로 작성된 프로그램도 eCos에서 Compatible함으로 정상동작합니다.
3. EL/IX 기반으로 짜여진 Linux programming은 동일한 API를 가지며, Compatible 합니다. 또한 이를 확장해서 C++로 프로그래밍 할 수 있도록도 지원합니다.
그러나, 일반적인 Linux Programming에서 사용하는 Process 개념은 eCos에서는 지원하지 않습니다. 즉, 자신만의 memory space를 가지진 못합니다. 일반적인 Linux는 thread에 대한 개념이 없이, Process를 fork()해서 thread를 생성해서 task를 만들지만, Real Time Linux(eCos,RTLinux 등등...) 들은 Thread형식으로만 task를 생성할 수 있습니다. 따라서, 만약 process 형식으로 task를 init 한 경우는 thread 로 바꾸어만 주면 됩니다. 그러나, embedded 의 특성상 memory의 한계가 있으니, 수십메가씩 전역메모리를 잡거나 하여서는 안됩니다. Linux의 경우 Virtual Memory를 사용하는 것이 일반적이지만, RT Linux계열은 이를 지원하지 않는 System이 대다수 입니다. 이를 지원하려면, MMU가 지원되는 Chipset과 더불어, HDD나 고용량의 Nand Flash, 각종 Memory Stick등을 써주어야 하기 때문입니다.
스케쥴링방법으로는 기본적으로 priority 기반의 Multi-level Queue를 사용하며, 스케쥴링 방법은 고정되어 있습니다. 여기에 추가적으로 bitmap scheduling도 가능합니다만, priority가 Atomic하게 할당됨으로 같은 priority를 줄 수 없는 문제가 있으나, 보다 빨리 스케쥴링가능하단 이점도 있습니다.
IRQ는 일반적인 ISR과 DSR 로 나뉘어집니다. ISR(Interrupt Service routine)의 경우는 Context Switching을 하지 않으며, DSR(Deffered Service Routine)은 Context Switching이 일어나는 Thread개념의 Service routine입니다. 빨리 끝낼 수 있는 IRQ는 ISR에, 시간이 걸리는 일에는 DSR에 넣는 것이 일반적입니다.
//////////////////////////////////////////////////////////
//RTOS에서는 여러가지 task(예를 들면 play, record ...)들을
//IRQ, 해당 핸들러, scheduling방식, 우선순위등을 지정해서
//처음에 일종의 task 구조체에 쭈욱 등록해 줍니다.
첫댓글부연설명 : interrupt 처리시 ISR에서 scheduler lock을 한 상태에서 처리해야 할 일을 처리하고 난후 scheduler unlock을 하고 이 interrupt에 대한 DSR이 존재함을 알리는 상수를 return합니다. 이 상수가 return되면 kernel내의 interrupt 처리부는 DSR을 호출하여 해당 인트럽트처리를 완료하는 구조로 되어 있습니다.
첫댓글 부연설명 : interrupt 처리시 ISR에서 scheduler lock을 한 상태에서 처리해야 할 일을 처리하고 난후 scheduler unlock을 하고 이 interrupt에 대한 DSR이 존재함을 알리는 상수를 return합니다. 이 상수가 return되면 kernel내의 interrupt 처리부는 DSR을 호출하여 해당 인트럽트처리를 완료하는 구조로 되어 있습니다.