전송 프로토콜 비교 (xmodem, ymodem, zmodem)

1. 흐름제어.

1.1. HW flow control(Serial port)

Serial port(HW)에서 지원하는 방법으로, HW상의 serial buffer의 상태에 따라서 전송을 계속할지 멈출지 결정한다. 이 방법은 보통 HW의 지원으로 이루어지며, SW는 해당 장치를 enable하기만 하면 된다. 

1.2. SW flow control

선로상에서 서로간의 buffer상태에 따라서 data를 전송하거나 멈추기 위해서 특별한 data를 전송하는 방법이다. 추가의 HW가 불필요하지만, 송/수신 SW에서 적절한 반응을 해야만 한다.

수신단에서는 저장되는 데이타의 양이 버퍼의 용량에 도달하면 (경우에 따라서는 도달 전에) 전송단에 XOFF를 보내고, 이후 데이터 처리가 끝나고 buffer라 준비가 된 경우, XON을 보냄으로써 전송을 재개한다.

2. Protocol의 종류.

Flow control은 단순히 속도를 맞추는 기능을 수행할 뿐, 본격적인 전송 프로토콜이라고 하기에는 부족하다. 그래서 필요에 따라 새로운 전송프로토콜들이 개발되었다.

2.1. XModem

가장 보편화된 프로토콜로 아래 포멧에 따라 128 bytes를 포함한 packet을 보내고 수신측의 응답을 받으면 다른 packet을 보내는 방식으로 구현되어 있다. 

XON/OFF 대비 handshaking overhead가 적기 때문에 좀 더 효율적이지만, response를 기다려야 한다는 점에서는 패킷교환망에서는 효율이 떨어진다.

초기 버전의 경우, 1byte의 checksum을 통해서 에러 검출을 했지만, 이후에 CRC (XModem/crc)로 대체되었다. 

이후 packet size를 더 키워서 효율을 높인 버전(XModem-1K)과 response를 기다리지 않고 다음 packet을 전송하는 버전(XModem-G)이 개발되었다. 

XModem-G의 경우 뒤늦게 전송실패 response를 받는 경우, 재전송이 없이 전송을 중단하기 때문에 선로가 좋지않은 경우 권장되지 않는다.

2.2 YModem

YModem은 XModem을 발전시켜 효율을 높인 프로토콜로 packet size의 조절이 가능하며, 파일이름 등과 같은 부가 정보까지 전송이 가능하고, 여러 파일을 한번에 전송하는 batch기능까지 추가 되었다.

Ymodem에서 개선된 버전이 있는데, Xmodem-G와 비슷하게 수신측의 응답을 기다리지 않고 다음 블럭을 전송한다.

2.3 ZModem

앞서 나온 프로토콜들의 단점을 보완하는 가장 빠르고 안정된 프로토콜이다.

Ymodem을 이어받아서 파일의 이름과 크기를 처음에 전송하며, CRC도 32비트로 강화되었다. 

프레임의 크기를 전송선로의 상태에 따라 실시간으로 변화시킬 수 있다는 점도 장점이다. 예를 들어 최초 1KB packet 전송결과 실패했다면 즉시 다음 packet은 512 bytes packet으로 바꾸어 전송할 수 있다.

Ymodem에서 아쉬웠던 재전송 기능도 추가되었다. 전송중에 에러가 발생하여 전송이 중단되었을 경우 후에 다시 같은 파일을 전송하게되면 스스로 에러가 난 부분 다음부터 전송을 한다는 점이다. 여기에 와일드카드 지원, 파일압축기능, 파일암호화기능과 같은 많은 기능 지원으로 현재는 전 세계에서 가장 많이 사용하고 있는 프로토콜의 표준이 되었다.

저비용 비선점형 멀티태스킹, Part 3 - 스케쥴링과 처리량 밸런싱

• 아래 링크의 글을 구글번역 + 다듬었습니다.
• https://www.embedded.com/design/prototyping-and-development/4208576/Low-cost-cooperative-multitasking-Part-3-Scheduling-and-throughput-balancing
• 이 시리즈의 이전 1 부와 2 부에서는 마이크로 컨트롤러 기반 임베디드 시스템을 더 작은 구성 요소로 분류 한 다음 이들 구성 요소가 서로 작동하여 시스템 기능을 수행하는 방법을 살펴 보았습니다. 상태 머신 기반 멀티 태스킹 시스템에 대한 태스크 설계 및 인터 태스킹 통신이 논의되었습니다.
• 이 기사 시리즈의이 부분에서는 모든 하위 시스템을 하나로 묶고 강력한 작업 전환 및 CPU 처리량 균형을 유지하기위한 스케줄링 방법에 대해 설명합니다.
• 간단한 방법
  • 스케줄링 작업의 가장 간단한 형태는 무한 루프입니다. 이 기사 시리즈의 첫 번째 부분에서 설명한 것처럼 모든 작업은 올바른 실행 순서로 호출됩니다. 목록의 끝에 있으면 맨 위로 이동합니다.
  • 물론이 시스템은 작업 실행에 대한 주기성이 엄격하지 않으며 MP3 플레이어와 같은 복잡한 시스템에는 적합하지 않을 수 있습니다.
  • 이 시스템에서도 작업 실행 시간을 신중하게 측정하고 유휴 작업을 추가하여 다음 밀리 초로 반올림함으로써 타이밍 감각을 도입 할 수 있습니다. 예를 들어, Task1에서 Task 4까지는 4.1ms를 합한 것으로 가정합니다. 이 경우 루프를 5ms로 반올림하기 위해 0.9ms 동안 실행되도록 IdleTask ()에 지연 루틴을 작성할 수 있습니다. 이 체계는 각 작업이 정해진 시간이 걸리거나 타이밍 제약 조건이 엄격하지 않은 간단한 시스템에서 작동합니다. 이 보다 더 복잡한 스케줄링을 필요로 하지 않는 수많은 시스템이 있습니다.
  • 느긋하게 실행해야하는 작업에는 내부 카운터가 있고 일부 호출을 건너 뛰어 처리량을 관리 할 수 ​​있습니다.
  • 여기서 task X는 짝수 번째의 호출에서만 실행되도록 설정되어 있습니다. 마찬가지로 다른 작업을 홀수 번째의 호출에서 실행되도록 설정할 수도 있습니다. 우리는 원하는 CPU 처리량의 균형을 달성하기 위해 두 개 이상의 작업을 엇갈리게하여 조금 더 멋진 경험을 할 수 있습니다.
• 결정론적 스케줄러
  • MP3 플레이어와 같은보다 복잡한 시스템은 정확한 타이머 틱과 정확한 주기로 작업을 실행해야합니다. 이는 스케줄러에 타이머 인터럽트를 추가하여 쉽게 수행 할 수 있습니다. 타이머는 정해진 간격으로 인터럽트를 제공하도록 구성되어 있습니다.
  • 전역 변수 "TimerTick"은 현재 틱을 갖고 있습니다. 타이머 틱 간격의 경험 법칙은 5ms 또는 7.8125ms입니다 (7.8125 X 2^7 = 1000ms = 1 초, 경우에 따라 유용함). 이 틱 변수는 인터럽트에 의해 비동기 적으로 증가합니다.
  • 스케줄러의 무한 루프는 현재 타이머 틱에 스케줄된 모든 task을 호출 한 후 다음 틱이 도착할 때까지 기다립니다. 여기서 작업 설계의 가장 중요한 기준은 "틱 내에서 완료"입니다.
  • 모든 작업은 각 틱마다 예약 된 모든 작업이 실행되고 다음 틱이 도착하기 전에 스케줄러로 제어권을 되 돌리는 방식으로 설계 및 예약되어야합니다. 작업은 이 "틱 간격"의 다양한 배수로 예약되며 CPU가 고르게 로드되도록 항상 엇갈리게 배치됩니다. 실행하는 데 시간이 오래 걸리는 더 큰 작업은 엇갈리게 분할하여 실행해야합니다.
  • 이 체계를 구현하기 위해 주기 및 오프셋 번호, 연관된 작업 포인터 (C의 함수 포인터)를 가진 데이터 구조가 준비되어야 합니다. 주기는 작업을 실행해야하는 타이머 틱의 배수를 정의하고 오프셋 번호는 실행을 지연시키는 틱 수를 정의합니다.
  • 5ms 틱 시스템에서 {USBTask, 2, 0}을 입력하면 USBTask가 엇갈 리지 않고 10ms마다 (즉, 0ms, 10ms, 20ms 등) 실행해야합니다. {TouchSenseTask, 2, 1}은 10ms의 주기성을 갖지만 1 틱으로 엇갈리게되므로 TouchSenseTask는 5ms, 15ms, 25ms 등에서 실행됩니다. {SystemMonitor, 4, 3} 항목은 SystemMonitor를 15ms, 35ms (20 + 15), 55ms, 75ms 등으로 예약합니다.
  • 마이크로 컨트롤러가 작동하는 속도와 비교하여 사람의 상호 작용은 상당히 느리기 때문에 ServiceUserInput 작업은 매우 느긋하게 예약 할 수 있습니다. ServiceUserInput은 50ms마다 예약되면 {ServiceUserInput, 10, 1}로 나타낼 수 있습니다. (예 : 5ms, 55ms, 105ms) 작업이 올바르게 정의되면 CPU의 부하를 고르게 하는 것이 매우 쉽다는 것을 알 수 있습니다. 작업 테이블은 플래시 메모리에 배치되어 소중한 RAM을 절약합니다.
  • 방금 디자인 한 스케줄러의 의사 코드는 다음과 같습니다.
  • 아래의 그림 1은 5ms 타이머 틱에서 위 작업 테이블의 실행 타임 라인을 보여줍니다. 단순성과 시각화를 위해 DisplayDriver는 호출 당 0.5ms, USBTask는 1.5ms, TouchSenseTask 및 ServiceUserInput는 각각 1ms를 가정합니다.
  • 물론이 숫자는 일반적인 디자인 번호가 아닙니다. 타임 라인의 빈 공간은 각 타이머 틱에서 CPU가 유휴 상태 인 시간을 나타냅니다. 아래 그림 1은 USB MP3 플레이어의 나머지 서브 시스템을 통합하기 위해 여전히 상당한 양의 처리량이 남아 있음을 보여줍니다. 파일 시스템 및 디스플레이 관리자 task은 이제이 타이밍 그래프에서 볼 수있는 유휴 시간으로 예약되어야합니다.
  • 그림 1 : 작업을 부분적으로 통합 한 후 USB MP3 플레이어의 CPU 타임 라인
  • 작업에 우선 순위를 지정하는 것을 검토해 봅시다. 두 작업이 차례로 실행되어야한다고 가정 해보십시오. Task-Description (작업 설명) 테이블에서 하나를 다른 아래에 배치 할 수 있습니다. 이것이 "틱 내 완료"기준을 위반하는 경우, 동일한 기간으로 배치해야하지만 우선 순위가 낮은 작업을 한 번의 틱만큼 엇갈리게 배치해야합니다.
• 처리량 관리
  • 마이크로 컨트롤러와 관련된 처리량은 CPU가 1 초 안에 실행할 수있는 명령의 양으로 정의 될 수 있습니다. 마이크로 컨트롤러의 처리량은 제한된 자원이며 종종 비용과 관련이 있습니다. 지금까지 멀티 태스킹 시스템에서 CPU 오버 헤드가 거의없는 소프트웨어를 구축했습니다. 이것은 지능적인 작업 디자인과 스마트 스케줄링으로 이루어졌습니다.
  • 우리 시스템에서는 새로운 서브 시스템이나 소프트웨어 스택을 쉽게 연결하고 기존 소프트웨어를 업그레이드로 쉽게 교체 할 수 있습니다. 그러나 이러한 변경으로 인해 RTOS 시스템에도 공통적 인 문제가 발생합니다. 소프트웨어가 변경되면 실행 시간이 변경되고 "틱 내 종료"기준을 위반할 수 있습니다. 따라서 시스템 디버깅에 도움이되는 몇 가지 진단 방법을 추가하는 것이 좋습니다.
  • 편리한 툴은 각 스케줄러 루프 전후에 타이머를 기록하여 틱 간격을 초과 한 정확한 틱을 캡처 할 수 있도록하는 것입니다. 이 시차는 작업 목록에서 가장 큰주기와 동일한 크기의 배열로 저장됩니다. 최대주기가 30 틱이면 로깅 배열에 30 개의 요소가 필요합니다. TimerTick이이 수에 도달하면 로그 배열이 처음부터 채워집니다. 변경된 스케줄러의 의사 코드는 다음과 같습니다.
  • #ifdef DEBUG는 디버깅 중에 DEBUG 기호가 사용될 때만 코드를 포함하는 C 언어 지시문입니다. 오버 슈트하는 작업을 포착하고 수정하면 로깅을 비활성화 할 수 있습니다. 이러한 방식으로 RAM 및 CPU 사용량은 영향을받지 않습니다. 시스템이 한계를 넘어가더라도 이 로깅 방법을 사용하여 남은 CPU 처리량을 파악하고 업그레이드를 계획 할 수 있습니다.
  • 어떤때에는 모든 작업이 완료되기 전에 타이머 틱이 도착하는 것이 괜찮을 때도 있습니다. 다음 틱에 로드가 거의없는 것으로 확인되고 해당 틱에서 시간이 중요한 작업이 실행되지 않는 경우 틱 사이의 간격을 초과해도됩니다. 이 경우 스케줄러는 틱를 기다리지 않기 때문에 단순히 틱를 따라 잡습니다.
• 몇 가지 팁과 요령
  • 시스템의 견고성, 결정론적 특성 및 저비용 기능은 신중한 작업 설계 및 스마트 스케줄링으로 달성됩니다. 그러나 소프트웨어를 코딩하기 전에 신중하게 계획해야하기 때문에 이 멀티 태스킹 시스템을 처음 구현하는 동안 쉽게 실수할 수 있습니다. 다음은 이 과정에에 도움이되는 몇 가지 팁입니다.
    • 1. 모든 것을 문서화하십시오. 상태 시스템의 수가 증가함에 따라, 특히 상호 작용이 증가함에 따라 길을 잃어버리기 쉽습니다. 시간을 들여 설계 문서를 작성하고 모든 작업과 그 종속성을 서로 나열하십시오. 코드를 자세히 기록하십시오. 모든 공유 변수의 목적과 범위를 문서화해야합니다. 올바른 코딩 표준을 따르는 것은 항상 가독성을 높이는 데 도움이되며 업그레이드 또는 버그 수정을 위해 코드를 다시 볼 때 도움이됩니다.
    • 2. 어떤 형태의 진단을 구현하십시오. 양산 또는 디버그 시간 전용 기능에 내장 될 수 있습니다. 서브 시스템을 변경하거나 새 기능을 추가하면 시스템 타이밍이 필연적으로 변경됩니다. 작업의 균형을 다시 조정해야 할 수도 있습니다. 타이밍 진단을 구현하는 것이 편리합니다.
    • 3. 길을 잃었을 때 두 가지 작업으로 시작하여 시스템을 다시 구축하십시오. 모든 작업을 시스템에 처음 통합 할 때 지옥이 펼쳐질 수 있습니다. 한 번에 한 task씩 인내심을 갖고 통합하십시오. 이런 식으로 CPU와 함께 도망가는 통합 작업을 해결할 수있는 범인 작업을 찾을 수 있습니다.
    • 4. WaitForTimerTick () 루틴에 들어갈 때 마이크로 컨트롤러를 절전, Doze 또는 유휴 모드와 같은 저전력 상태로 전환 할 수 있는지 확인하고 타이머 인터럽트에서 깨어나게 합니다. 마이크로 컨트롤러가 상당한 시간 동안 유휴 상태인 경우 시스템의 전력 소비가 줄어 듭니다. 일부 저전력 마이크로 컨트롤러에서는 슬립 전류가 매우 낮아서 시스템이 배터리에서 더 오래 실행될 수 있습니다.
    • 5. 상태 머신 스위치 케이스에는 자연수를 사용하십시오. 컴파일러는 case번호가 자연수일 때 스위치 케이스를 최적화하여 CPU 명령의 "decrease and check for zero and jump"로 바꿔줍니다. 다른 방법으로 점프하는 것보다 명령이 훨씬 적게 필요하므로 처리량이 줄어 듭니다.
• 결론
  • 이 3 부 기사 시리즈에 제시된 상태 머신을 사용한 저비용 협업 멀티 태스킹 방법은 기능이 많고 리소스가 적은 시스템에 효과적입니다.
  • 성공을 위해서는 세심한 계획과 디자인이 필요하지만, 일단 방법을 마스터하면 새로운 프로젝트와 기존 프로젝트의 확장으로 쉽게 확장됩니다.
  • 이 방법은 메모리 사용량이 제한된 저비용 8 비트 및 16 비트 시스템에서 멀티 태스킹이 필요한 경우에 적합합니다.
  • 이 방법은보다 복잡한 시스템에도 적용 할 수 있지만 상태 머신을 구현하는 엔지니어링 노력은 상용 RTOS를 사용하는 것보다 훨씬 더 큰 것으로 입증 될 수 있습니다. 프로젝트 수명주기 초기에 결정을 내려야합니다. 비용을 줄이려면 상태 머신을 사용하는 것이 좋습니다.

저비용 비선점형 멀티태스킹, Part2 - MP3 플레이어 만들기.

• 아래링크의 글을 구글 번역 + 다듬은 것입니다.
• https://www.embedded.com/design/real-time-and-performance/4207793/Low-Cost-Cooperative-Multitasking-Part-2-Building-an-MP3-Player
• 이 기사 시리즈의 Part 1에서는 매우 간단한 예를 통해 상태 머신 기반 멀티 태스킹 시스템의 기본 사항을 살펴보았습니다. 이 두 번째 Part에서는 시스템의 소프트웨어를 구축하기위한 설계 방법론을 공부합니다. USB, 파일 시스템, LCD 및 정전 식 터치 감지 기능이 통합 된 MP3 플레이어 시스템을 구축함으로써 task설계, task간 통신, 우선 순위 지정 등에 대해 논의합니다.
• 시스템 소프트웨어 설계
  • 다음은 1 부에서 설명한 기본 원칙을 요약 한 것입니다.
    • 1. 각 기능은 짧은 시간 내에 완료 할 수있는 작은 하위 작업 또는 상태로 나뉩니다.
    • 2. 작업 컨텍스트 저장 및 복원은 상태 머신 및 상태 변수에 의해 수행됩니다.
    • 3. 각 task는 작업의 작은 부분을 수행하고 스케줄러로 제어권을 다시 부여합니다. 시스템은 여러 가지 task/함수에 의해 만들어지며 반복적으로 호출됩니다.
    • 4. 여러 task가 서로 다른 상태에서 교차실행되는 것은 모든 상태 시스템을 동시 실행되는 것처럼 보여줍니다.
    • 5. 스케줄러는 모든 작업을 반복적으로 거르면서 현재 반복에 schedule된 task을 실행하는 무한 루프입니다.
    • 6. 간단한 언어 구성은 가능한 한 많이 사용되어 오버 헤드를 최소화합니다.
  • 상태 머신 기반 멀티 태스킹 시스템의 설계에는 하향식 접근법이 포함됩니다. 스케줄러 자체는 계층 구조의 최상위에 있지만이 기사의 마지막 섹션에서 설명합니다. 먼저 시스템의 소프트웨어를 설계 할 때 어떤 방법을 사용해야하는지 살펴 보겠습니다.
  • 시스템 소프트웨어 설계는 다음 세 가지 하위 범주로 나눌 수 있습니다.
    • 1. 서브 시스템 정의 및 작업 분류
    • 2. 작업 상호 작용 및 우선 순위
    • 3. 작업 일정
• 서브 시스템 정의
  • 하향식 설계 방식과 마찬가지로 먼저 시스템을 주요 하위 시스템으로 분류합니다. 서브 시스템은 하나의 단일 기술 또는 기능에 속하는 논리적 작업 세트입니다. 이전 줄에서 암시 한 것처럼 하위 시스템은 단일 기능 일 필요는 없지만 서로 상호 작용하는 일련의 기능 일 필요가 있습니다. 디자인의 첫 번째 단계에서 시스템을 최상위 서브 시스템으로 분할해야합니다. 그런 다음 서브 시스템 내에서 각각의 독립적인 하위 기능을 정의할 수도 있습니다.
  • 이제 이 기사의 1 부에서 설명한 FM 플레이어보다 더 복잡한 시스템 인 LCD 디스플레이와 터치 감지 입력이 있는 USB MP3 플레이어를 살펴 보겠습니다. 시스템에 다음과 같은 하드웨어가 있다고 가정 해 봅시다.
    • 1. MP3 디코더 ASIC
    • 2. 정전 식 터치 감지 입력 패드
    • 3. 분할 LCD 디스플레이
    • 4. USB 호스트 마이크로 컨트롤러
  • 시스템의 최상위 수준은 아래 그림 1과 같습니다.
    • 그림 1 : 가상 USB MP3 플레이어 시스템의 블록 다이어그램
  • 우리가 구축한 이 USB MP3 플레이어 시스템에서 다양한 하위 시스템과 내부 구성 요소를 정의할 수 있습니다.
    • 1. USB 서브 시스템
    • 2. 파일 시스템
    • 3. MP3 서브 시스템
      • A. MP3 오디오 관리자
        • i) 버퍼 관리자
        • ii) 파일 관리자
        • iii) 재생 관리자
      • B. MP3 ASIC 드라이버
    • 4. 터치 감지 입력 서브 시스템
      • A. 정전 식 터치 감지 드라이버
      • B. 터치 감지 알고리즘
    • 5. 디스플레이 서브 시스템
      • A. 디스플레이 관리자
      • B. 디스플레이 드라이버
    • 6. 시스템 모니터 및 하우스 키핑
  • 이제부터는 각 하위 시스템 구성 요소를 기능과 하위 기능으로 나눕니다. 예를 들어, MP3 오디오 관리자는 빨리 감기, 되감기 등과 같은 모드를 처리하기 위해 MP3 ASIC 버퍼 관리, 파일 관리자 및 MP3 재생 관리자로 분류되어야합니다.
  • 이 기사의 첫 번째 섹션에 설명 된대로 실행하는 데 1 밀리 초 이상 걸리는 모든 기능은 상태 머신으로 만들어야합니다. 따라서 시스템 분석이 끝나면 간단한 함수 모음과 많은 상태 머신이 남게 됩니다.
  • 모든 독립 기능이 정의되면 스케줄링을 위해 서로 다른 task들로 그룹화해야합니다. 예를 들어 MP3 하위 시스템에는 4 개의 상태 시스템이 필요합니다.
  • "ASIC 드라이버"및 "버퍼 관리자"는 최우선 순위로 실행하고 처리량을 소비해야합니다. “파일 관리자” 및 “재생 관리자”상태 시스템은 보다 느긋하게 실행될 수 있습니다. 파일 관리자와 재생 관리자가 단일 작업으로 그룹화 될 수도 있습니다.
  • 따라서 이 경우 Task는 스케줄링을 위해 함께 그룹화 된 함수 호출 세트입니다. 우리 시스템에는 task이름을 가진 공식적인 함수는 없지만 대신에 스케줄러의 최상위 상태 시스템에 대한 호출 목록이 있을 수 있습니다.
  • 좋은 task디자인을 구성하는 데 시간을 할애하는 것은 중요합니다. task가 너무 많으면 코드 공간이 낭비되고 schedule 오버 헤드가 늘어납니다. 태스크가 너무 적고 단일 태스크이 너무 많은 처리량을 사용하면 멀티 태스킹 효과가 줄어 듭니다.
  • 다음 규칙이 적용됩니다.
    • 1. 동일한 작업에서 서로 의존하는 두 개의 연관된 상태 머신을 그룹화하십시오.
    • 2. 실행하는 데 시간이 오래 걸리는 함수는 다른 작업에 배치하고 스케줄러 루프에서 실행을 지연하십시오 (나중에 자세히 설명).
    • 3. 처리량 균형이 방해받지 않는 한 관련없는 작업을 함께 스케쥴하십시오.
    • 4. 다른 기능 (예 : 터치 감지)에 속하더라도 느린 응답 함수(예 : 입력 처리)에 대해 별도의 작업을 만듭니다. 이러한 작업을 여유롭게 스케쥴하십시오.
  • 시스템의 하위 시스템은 다양한 방식으로 상호 작용합니다. 일부 서브 시스템은 데이터, 타이밍 및 출력을 위해 다른 서브 시스템에 의존합니다. 서로 다른 작업이 서로 통신하는 방식에 따라 작업 간 통신 전략뿐만 아니라 우선 순위와 빈도가 결정됩니다. 이 섹션에서는 먼저 실행 빈도와 우선 순위를 결정하는 방법을 살펴보고 작업 간 통신 방법을 검토합니다.
• 실행주기 및 순서
  • 작업 내에서 다양한 상태 시스템과 기능을 식별 했으므로 작업의 실행 순서를 알아보겠습니다. 먼저이 용어를 정의하겠습니다.
  • 실행주기는 작업이 스케줄러에서 호출되는 빈도입니다. 일부 작업은 다른 작업보다 더 자주 호출할 필요할 수 있습니다. 이는 모든 작업이 스케줄러 루프 반복에서 매번 스케쥴 될 필요는 없다는 의미이기도 합니다.
  • 이것은 많은 CPU 처리량을 절약합니다. 위의 MP3 플레이어 예에서 LCD 드라이버는 버퍼에서 디스플레이로 단일 문자를 쓰고 다시 스케줄러로 제어권을 되돌려주는 상태 머신입니다. 완전한 디스플레이 작성을 위해서 이 task는 가장 높은 빈도로 호출해야합니다.
  • USB 드라이버 작업은 USB 호스트 신호를 전송하고 연결된 장치를 활성 상태로 유지하기 위해서 자주 호출되어야 하지만, 가장 자주 호출되는 것은 아닙니다. 정전 용량 데이터를 캡처하려면 터치 감지 드라이버 작업을 자주 호출해야합니다. 그러나 터치 감지 감지 알고리즘 작업은 유용한 기능을 수행하기 전에 많은 정전 용량 데이터 샘플이 필요하기 때문에 여유있게 호출될 수 있습니다.
  • 실행 순서는 task 내에서 그룹화된 함수의 호출 순서 및 task가 스케줄러에서 호출되는 순서입니다. task 우선 순위는 task 순서를 결정합니다. 실행 순서는 자연스러운 데이터 흐름 순서를 따릅니다.
  • 아래의 그림 2는 MP3 플레이어 시스템의 "다음 트랙" 터치 패드를 터치했을 때의 데이터 흐름을 보여주는 최상위 데이터 흐름 다이어그램의 일부입니다. "재생 관리자"작업이 "시스템 모니터"작업에 어떻게 의존하고 어떻게 입력에 대한 "터치 감지 감지 알고리즘"작업에 의존하는지 주목하십시오. 처리량 기준이 충족되면 시스템 모니터 및 터치 감지 감지 작업 후에 동일한 실행 빈도로 "재생 관리자"작업을 예약하는 것이 좋습니다.
  • 그림 2 : USB MP3 플레이어 시스템의 데이터 흐름 다이어그램의 일부
  • 스케줄러 루프의 두 단계에서 실행을 비틀어 작업의 우선 순위를 지정할 수 있습니다. 우선 순위가 높은 작업은 첫 번째 단계에서 예약하고 우선 순위가 낮은 작업은 나중에 예약해야합니다. 이 내용은이 기사의 "작업 예약"섹션에서보다 명확 해집니다.
• 인터 태스크 커뮤니케이션
  • 논리적 기능 단위는 하나의 상태 머신이라는 점을 상기해보면, 독립적으로 스케쥴되는 두 상태 머신 간의 통신에 관심이 생길 것입니다. task는 관련된 혹은 관련없는 일련의 함수 호출입니다.
  • 협동 멀티 태스킹의 state machine 간 통신은 전역 변수에 의해서만 처리됩니다. 이는 모든 작업 전환이 결정적이며 공유 리소스에 동시에 액세스 할 위험이 없기 때문입니다. 우리는 설계상 이 견고성을 갖기 때문에 전역 변수가 작업 간 통신에 사용됩니다.
  • 물론 멀티 태스킹 시스템에서 처리해야하는 많은 유형의 데이터 통신이 있습니다. 많은 종속 작업이 비동기 적으로 실행되기 때문에 입력 및 데이터 구조의 모집단을 사용할 수 있음을 나타내는 "플래그"가 필요합니다.
  • 한 서브 시스템의 이상을 다른 서브 시스템과 통신하려면 “오류 플래그 / 코드”가 필요합니다. 한 상태 머신에서 수집 한 데이터를 다른 작업에서 사용하려면 그것을 보관하는 "버퍼"가 필요합니다. "상태 변수"는 task 상태에 대한 정보를 보유하며, 이는 작업을 전임자에게 위임하는 다른 task에 유용합니다.
  • MP3 플레이어의 예에서, 터치 감지 시스템은 "정전 용량 터치 감지 드라이버"에 의해 읽히는 용량성 패드의 출력을 읽습니다. 이것은 터치 패드의 아날로그-디지털 변환기 ( ADC) 값을 저장하는 버퍼를 사용하여 실행됩니다. "터치 감지 감지"상태 머신은 각 정전식 터치 패드에 대한 플래그 세트를 공유하며 "시스템 모니터"는 이값을 지속적으로 읽습니다.
  • 사용자가 "다음 트랙"터치 패드를 눌렀다고 가정하겠습니다. 터치 감지 감지 상태 머신은 서브 시스템의 하위 계층에서 ADC 버퍼를 분석하고 상위 계층(예 : 시스템 모니터)에 사용될 터치 패드 플래그를 설정합니다.
  • 다음 차례에 시스템 모니터는 재생 관리자에 대해 "다음 파일 열기"플래그와 "디스플레이 관리자"가 사용할 "새 파일 이름 설정"플래그를 설정합니다. 디스플레이 관리자가 “업데이트 된 파일 이름”버퍼에서 현재 재생되는 파일 이름을 구할 수 있습니다.
  • 디스플레이 관리자는이 데이터의 재생 관리자에 의존하며 실행시 재생 관리자를 따라야하므로 우선 순위가 낮습니다. 파일 내용은 다시 버퍼를 통해 MP3 ASIC으로 펌핑됩니다. 이것은 단일 버튼 누름으로 인한 총 데이터 흐름입니다. 이외에 아날로그 모니터나 멀티플렉서등을 가능하게하기 위해 시스템 모니터에 의해 실행된 일부 하드웨어 동작이 있습니다.
  • 잘 설계된 협업 멀티 태스킹 시스템에서는 모든 제어 전환이 미리 결정되어 있으므로 동기화 문제에 대해 걱정할 필요가 없습니다. 따라서 파이프, 메시지 및 세마포어와 같은 값 비싼 동기화 장치을 사용할 필요가 없습니다. 이러한 복잡한 기능은 저렴하고 간단한 플래그, 버퍼 및 대기열을 사용하여 구현됩니다.
• 작업 일정