잘 규제된 개발 주기부터 엄격한 실행 및 시스템 검사에 이르기까지 신뢰성이 높은 임베디드 시스템을 개발하는 데는 다양한 기술이 있습니다.
조작하기 쉽고 오랫동안 사용할 수 있는 7가지 팁을 소개합니다. 시스템을 보다 안정적으로 실행하고 비정상적인 동작을 포착하는 데 매우 도움이 됩니다.팁 1 - 알려진 Value Filled ROM을 사용하세요소프트웨어 개발자는 매우 낙관적인 경향이 있으며 자신의 코드가 오랫동안 충실하게 실행되기를 원합니다. 마이크로컨트롤러가 애플리케이션 공간을 벗어나 의도하지 않은 코드 공간에서 실행되는 경우는 매우 드문 것 같습니다. 그러나 이런 일이 발생할 가능성은 버퍼 오버플로 또는 잘못된 포인터가 참조를 잃는 것보다 적지 않습니다. 그것은 일어난다! 이 일이 발생한 후의 시스템 동작은 정의되지 않습니다. 메모리 공간은 기본적으로 모두 0xFF이거나 메모리 영역은 일반적으로 기록되지 않기 때문에 그 안에 있는 값은 신에게만 알려질 수 있습니다. 그러나 이러한 이벤트를 식별하고 이벤트로부터 시스템을 복구하는 데 사용할 수 있는 매우 완전한 링커 또는 IDE 기술이 있습니다. 비결은 FILL 명령을 사용하여 사용되지 않은 ROM을 알려진 비트 패턴으로 채우는 것입니다. 사용되지 않은 메모리를 채우기 위해 사용할 수 있는 다양한 조합이 있지만 보다 안정적인 시스템을 구축하려는 경우 가장 확실한 선택은 ISR 오류 처리기를 이러한 위치에 배치하는 것입니다. 시스템에 문제가 발생하고 프로세서가 프로그램 공간 외부에서 코드를 실행하기 시작하면 ISR이 트리거되어 수정 조치를 결정하기 전에 프로세서, 레지스터 및 시스템 상태를 저장할 수 있는 기회를 제공합니다. 임베디드 엔지니어에게 큰 이점은 IDE와 툴체인이 애플리케이션 프로그램 또는 메모리 공간 체크섬(체크섬)을 자동으로 생성할 수 있다는 점입니다. ) 이 체크섬을 기반으로 애플리케이션이 손상되지 않았는지 확인합니다. 흥미롭게도 대부분의 경우 체크섬은 프로그램 코드를 장치에 로드할 때만 사용됩니다.그러나 CRC 또는 체크섬이 메모리에 유지되는 경우 예기치 않은 일이 발생하지 않도록 시작 시(또는 장기 실행 시스템의 경우 주기적으로) 애플리케이션이 그대로 유지되는지 확인하는 것이 매우 중요합니다. 방법. 현재 프로그래밍된 애플리케이션이 변경될 확률은 매우 적지만, 매년 수십억 개의 마이크로컨트롤러가 출하되고 잠재적으로 열악한 작업 환경을 고려하면 애플리케이션이 충돌할 가능성은 0이 아닙니다. 시스템 결함으로 인해 섹터에서 플래시 쓰기 또는 플래시 삭제가 발생하여 애플리케이션의 무결성이 손상될 가능성이 높습니다. 보다 안정적이고 견고한 시스템을 구축하려면 시스템 하드웨어가 제대로 작동하는지 확인하는 것이 중요합니다. . 결국 하드웨어는 실패할 수 있습니다. (다행히도 소프트웨어는 결코 실패하지 않습니다. 그것이 옳든 그르든 코드가 지시하는 대로만 수행합니다.) 부팅 시 RAM 내부 또는 외부에 문제가 없는지 확인하는 것은 하드웨어가 예상대로 작동하는지 확인하는 좋은 방법입니다. RAM 검사를 수행하는 방법에는 여러 가지가 있지만 일반적인 방법은 알려진 패턴에 쓴 다음 잠시 기다린 후 다시 읽는 것입니다. 결과적으로 읽은 내용은 쓰여진 내용이어야 합니다. 사실 대부분의 경우 RAM 검사가 통과되는데, 이것이 바로 우리가 원하는 것입니다. 그러나 검사가 통과되지 않을 가능성은 매우 낮으며 이는 시스템이 하드웨어 문제를 표시할 수 있는 좋은 기회를 제공합니다.많은 임베디드 개발자에게 스택은 다소 신비한 힘인 것 같습니다. 이상한 일이 일어나기 시작하자 엔지니어들은 마침내 어리둥절해하며 어쩌면 스택에 무슨 일이 벌어지고 있을지도 모른다고 생각하기 시작했습니다. 그 결과 스택의 크기와 위치 등을 맹목적으로 조정하게 됩니다. 그러나 오류는 스택에 구애받지 않는 경우가 많지만 어떻게 그렇게 확신할 수 있습니까? 결국, 실제로 최악의 스택 크기 분석을 수행한 엔지니어는 몇 명입니까? 스택 크기는 컴파일 타임에 정적으로 할당되지만 스택은 동적으로 사용됩니다. 코드가 실행됨에 따라 애플리케이션에 필요한 변수, 반환 주소 및 기타 정보가 스택에 지속적으로 저장됩니다. 이 메커니즘을 사용하면 스택이 할당된 메모리 내에서 지속적으로 증가합니다. 그러나 이러한 증가는 때때로 컴파일 타임에 결정된 용량 제한을 초과하여 스택이 인접한 메모리 영역의 데이터를 손상시키는 원인이 됩니다. 스택이 올바르게 작동하는지 확인하는 한 가지 방법은 시스템의 "상태" 코드의 일부로 스택 모니터를 구현하는 것입니다(몇 명의 엔지니어가 이 작업을 수행합니까?). 스택 모니터는 스택과 "다른" 메모리 영역 사이에 알려진 비트 패턴으로 채워진 버퍼 영역을 생성합니다. 그러면 모니터는 패턴의 변화를 지속적으로 모니터링합니다. 해당 비트 패턴이 변경되면 스택이 너무 커져서 시스템을 어두운 지옥으로 밀어넣을 것이라는 의미입니다! 이 시점에서 모니터는 나중에 문제 진단에 사용할 수 있도록 이벤트 발생, 시스템 상태 및 기타 유용한 데이터를 기록할 수 있습니다. 스택 모니터는 MPU(메모리 보호 장치)를 구현하는 대부분의 RTOS(실시간 운영 체제) 또는 마이크로 컨트롤러 시스템에서 사용할 수 있습니다. 무서운 점은 이러한 기능이 기본적으로 꺼져 있거나, 개발자가 의도적으로 꺼두는 경우가 많다는 것입니다. 웹에서 빠르게 검색해 보면 56바이트의 플래시 공간을 절약하기 위해 실시간 운영체제에서 스택 모니터를 끄는 것을 권장하는 사람들이 많다.잠깐만요, 이건 이득을 얻을 가치가 없어요! 예전에는 작고 저렴한 마이크로컨트롤러에 메모리 보호 장치(MPU)를 찾기 어려웠는데, 이런 상황 변화하기 시작했습니다. 이제 고급형부터 저가형까지 마이크로컨트롤러에는 MPU가 있으며, 이러한 MPU는 임베디드 소프트웨어 개발자에게 펌웨어의 견고성을 크게 향상시킬 수 있는 기회를 제공합니다. MPU는 처리가 분리되거나 작업이 밟힐 염려 없이 코드를 실행할 수 있는 메모리 공간을 만들기 위해 점차 운영 체제와 결합되었습니다. 어떤 일이 발생하면 통제되지 않은 처리가 취소되고 기타 보호 조치가 구현됩니다. 이 구성 요소가 포함된 마이크로 컨트롤러를 주의 깊게 살펴보고, 그렇다면 이 기능을 활용하십시오. 가장 인기 있는 감시 구현 중 하나 자주 찾을 수 있는 구현 예, 감시가 활성화된 경우(좋은 시작입니다) ), 그러나 주기적인 타이머를 사용하여 워치독을 지울 수 있는 경우에도 타이머 활성화는 프로그램에서 발생하는 모든 것과 완전히 독립적입니다. watchdog을 사용하는 목적은 오류가 발생할 경우 watchdog이 지워지지 않도록 하는 것입니다. 즉, 작업이 일시 중지되면 시스템이 강제로 하드웨어 재설정(하드웨어 재설정)을 수행하도록 하는 것입니다. 회복. 시스템 활동과 독립적인 타이머를 사용하면 시스템에 장애가 발생하더라도 워치독이 지워진 상태로 유지됩니다.임베디드 개발자는 애플리케이션 작업이 감시 시스템에 통합되는 방식을 신중하게 고려하고 설계해야 합니다. 예를 들어, 한 가지 기술을 사용하면 특정 기간 동안 실행되는 각 작업이 해당 작업을 성공적으로 완료했음을 나타낼 수 있습니다. 이 경우 워치독은 지워지지 않고 강제로 재설정됩니다. 메인 프로세서의 성능을 모니터링하는 데 사용할 수 있는 외부 감시 프로세서 사용과 같은 고급 기술도 있으며 그 반대의 경우도 마찬가지입니다. 신뢰할 수 있는 시스템을 위해서는 강력한 감시 시스템을 구축하는 것이 중요합니다. 기술이 너무 많기 때문에 이 문단에서 모두 다루기는 어렵지만 앞으로 이 주제에 관한 관련 기사를 게재할 예정입니다. 7 휘발성 메모리 할당을 사용할 수 있는 언어입니다. 결국 이는 필요할 때만 메모리를 할당하는 계산기 시스템에서 자주 사용되는 기술이다. 예를 들어, C로 개발할 때 엔지니어는 힙에 공간을 할당하기 위해 malloc을 사용하는 경향이 있습니다. 작업이 수행되고 완료되면 free를 사용하여 할당된 메모리를 반환하여 힙을 사용할 수 있습니다. 리소스가 제한된 시스템에서는 이는 재앙이 될 수 있습니다! 휘발성 메모리 할당을 사용할 때의 문제점 중 하나는 오류나 부적절한 기술로 인해 메모리 누수 또는 메모리 조각화가 발생할 수 있다는 것입니다. 이러한 문제가 발생하면 대부분의 임베디드 시스템에는 힙을 모니터링하거나 적절하게 처리할 수 있는 리소스나 지식이 없습니다. 그리고 애플리케이션이 공간을 요청했지만 요청한 공간을 사용할 수 없다면 어떻게 될까요? 휘발성 메모리 할당을 사용하여 발생하는 문제는 매우 복잡하며 이러한 문제를 올바르게 처리하는 것은 악몽이라고 할 수 있습니다! 대안은 단순히 정적 방식으로 직접 메모리를 할당하는 것입니다. 예를 들어, malloc을 통해 이 크기의 메모리 버퍼를 요청하는 대신 프로그램에서 256바이트 길이의 버퍼를 생성하기만 하면 됩니다.이렇게 할당된 메모리는 힙이나 메모리 조각화 문제에 대한 걱정 없이 애플리케이션 수명 내내 유지됩니다. 이러한 방법은 개발자가 보다 안정적인 임베디드 시스템 구축을 시작할 수 있는 몇 가지 방법일 뿐입니다. 좋은 코딩 표준 활용, 비트 플립 감지, 배열 및 포인터 경계 검사 수행, 어설션 사용 등의 다른 기술도 많이 있습니다. 이 모든 기술은 디자이너가 보다 안정적인 임베디드 시스템을 개발할 수 있는 비결입니다
위 내용은 몇 가지 실용적인 임베디드 개발 루틴 및 기술의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
