여러 가지 (> 20) 작업이 서로 다른 우선 순위에서 실행되는 임베디드 시스템이 있습니다. 나는 또한 모든 다른 작업이 갇혀 있지 않은지 확인하기 위해 실행되는 워치 독 작업이 있습니다. 블루 문에 가면 매번 작업이 체크인되지 않기 때문에 시스템을 다시 부팅하기 때문에 워치 독이 작동하고 있습니다.죽은 작업을 확인하는 방법은 무엇입니까?
어떤 작업이 종료되었는지 어떻게 결정합니까?
내키지 않는 우선 순위가 높은 작업에 의해 중단되었을 수 있으므로 가장 오래된 작업이 워치 독을 비난 할 수는 없습니다.
제안 사항?
마다의 작업 감시는 모든 감시를 걷어차 수 있도록 우선 순위가 높은 작업은 충분한 시간을 양보해야합니다 : 냅킨 방식의
선결제입니까? 다른 사람들 중 하나가 붙어 있다면 그렇지 않으면 워치 독 작업이 실행되지 않을 것이기 때문에 나는 모인다. 하나의 작업이 체크되지 않은 경우 감시 작업을 확인할 수있는 경우
당신은 각 작업과 감시 사이의 통신의 별도의 채널이 있어야합니다, OS의 언급을하지 않습니다하지만.
당신은 아마 어떻게 든 체크하고 사후 작업을 수행 할 수 있도록 태스크 제어 블록 및 메모리를 덤프하지 않은 하나의 작업 번호를 덤프 워치 독을 수정해야합니다.
OS에 따라 쉽거나 어려울 수 있습니다.
시스템 및 OS에 따라 다른 접근 방법이있을 수 있습니다. 내가 사용한 한 가지 매우 낮은 수준의 접근법은 각 작업이 실행 중일 때 LED를 깜박이는 것입니다. 매우 빠른 작업 전환을 보려면 LED에 범위를 지정해야 할 수도 있습니다.
인터럽트 구동 식 워치 독의 경우, 전환 할 때마다 작업 전환기가 현재 실행중인 작업 번호를 업데이트하도록하여, 어떤 전환이 발생하지 않았는지 식별 할 수 있습니다.
그러나 워치 독을 직접 작업으로 작성 했으므로 재부팅하기 전에 워치 독이 굶주린 작업을 식별 할 수 있는지 확인하십시오. 메모리를 웜 재부팅 이상의 상태로 저장하거나 디버그 인터페이스로 보낼 수 있습니다. 문제는 굶주린 작업이 문제가 아닌 것일 수 있습니다. 원인을 파악하기 위해 마지막 몇 가지 작업 스위치 (및 시간)를 알고 싶을 것입니다.
int8_t wd_tickle[NUM_TASKS]
void taskA_main()
{
...
// main loop
while(1) {
...
wd_tickle[TASKA_NUM]++;
}
}
... tasks B, C, D... follow similar pattern
void watchdog_task()
{
for(int i= 0; i < NUM_TASKS; i++) {
if(0 == wd_tickle[i]) {
// Egads! The task didn't kick us! Reset and record the task number
}
}
}
가장 단순한, 다시는 이런 일이 될 것입니다. 어떤 작업이 잘못되었는지 확인하려면 다른 작업이 굶주리고있는 작업을 찾아야합니다. 실제 범죄자를 찾기 위해 워치 독 점검 사이의 작업 실행 시간을 측정해야합니다.
심지어 워치 독 리셋 문제로 지난 몇 주간 작업을하고있었습니다. 그러나 나에게 다행스럽게도 ARM 개발 환경의 ramdump 파일에는 각 인터럽트마다 PC와 SLR을 포함하는 하나의 인터럽트 처리기 추적 버퍼가 있습니다. 따라서 추적 버퍼에서 WD 재설정 전에 코드의 어느 부분이 실행되고 있는지 정확히 알 수있었습니다.
PC, SLR을 각 인터럽트마다 저장하는 것과 같은 종류의 메커니즘을 가지고 있다면 범인 작업을 정확하게 찾을 수 있다고 생각합니다.
시스템이 어떻게 작동합니까? 나는 항상 소프트웨어와 하드웨어 워치 독 (watchdogs)의 조합을 사용한다. 설명해 드리죠 ...
필자의 예제에서는 선점 형 실시간 커널로 작업하고 있고 CPU/마이크로 컨트롤러에서 워치 독 지원을한다고 가정합니다. 이 워치 독은 일정 시간 동안 걷지 않으면 리셋을 수행합니다.
1) 주기적 시스템 타이머 ("RTOS clock")가 실행 중입니다 (그렇지 않은 경우 "sleep"과 같은 기능이 더 이상 작동하지 않고 시스템을 사용할 수 없음).
2) 모든 스레드는 적당한 시간 동안 실행할 수 있습니다.
내 RTOS (www.lieron.be/micror2k)는 RTOS 클럭 인터럽트 처리기에서 코드를 실행할 수있는 가능성을 제공합니다. 이것은 하드웨어 워치 독을 새로 고치는 유일한 장소이므로 시계가 항상 실행되고 있는지 확인합니다 (워치 독이 시스템을 재설정하지 않는 경우).
(항상 최저 우선 순위로 실행되는) 유휴 스레드에서 "소프트웨어 워치 독"이 새로 고쳐집니다. 이것은 단순히 변수를 특정 값 (예 : 1000)으로 설정하는 것입니다. RTOS 클럭 인터럽트 (하드웨어 워치 독을 걷어차는 곳)에서이 값을 감소시키고 확인합니다. 0에 도달하면 유휴 스레드가 1000 clock tick 동안 실행되지 않았고 시스템을 재부팅합니다 (하드웨어 워치 독 재부팅을 위해 인터럽트 핸들러 내부를 무한 루프로 반복하여 수행 할 수 있음).
이제 원래의 질문입니다. 시스템 시계가 계속 실행되는 것으로 가정하므로 시스템을 재설정하는 소프트웨어 워치 독이됩니다. RTOS 클럭 인터럽트 처리기에서 소프트웨어 워치 독 상황이 발생할 경우에 대비하여 "통계 수집"을 수행 할 수 있습니다. 시스템을 재설정하는 대신 문제가 발생한 후 각 클록 틱에서 실행중인 스레드를 확인하고 진행 상황을 파악할 수 있습니다. 이상적이지는 않지만 도움이 될 것입니다.
또 다른 옵션은 서로 다른 우선 순위의 여러 소프트웨어 감시기를 추가하는 것입니다. 유휴 스레드가 VariableA를 1000으로 설정하고 중간 우선 순위 스레드가 변수 B를 설정하도록하십시오. RTOS 클럭 인터럽트 처리기에서 두 변수를 모두 확인합니다. 이 정보를 사용하면 루핑 스레드의 우선 순위가 "중간"또는 "중간"보다 높은지 여부를 알 수 있습니다. 원하는 경우 3 번째 또는 4 번째 또는 원하는 소프트웨어 워치 독을 몇 개 추가 할 수 있습니다. 최악의 경우, 사용되는 각 우선 순위에 대해 소프트웨어 워치 독을 추가하십시오 (추가 스레드가 필요함).
문제는 B가 A보다 우선 순위가 높다는 것입니다. B는 잠겨 있지만 A는 워치 독을 걷어 내지 않습니다. A는 B의 유치장에 대한 비난을받습니다. – Robert