임베디드 애플리케이션의 메모리 관리를위한 리소스

Question

미션 크리티컬 임베디드 애플리케이션에서 메모리를 어떻게 관리해야합니까?

Google에서 몇 가지 기사를 찾았지만 실제로 유용한 가이드를 찾을 수 없었습니다.

DO-178b은 동적 메모리 할당을 금지하지만 메모리를 어떻게 관리합니까? 모든 것을 미리 할당하고 할당이 필요한 각 함수에 대한 포인터를 보냅니 까? 스택에 할당 하시겠습니까? 전역 정적 할당자를 사용합니다 (그러나 동적 할당과 매우 유사합니다).

정답은 정답, 리소스 참조 또는 좋은 opensource 임베디드 시스템에 대한 참조 형식 일 수 있습니다.

설명 : 여기서 문제는 임베디드 시스템에서 메모리 관리를 사용할 수 있는지 여부입니다. 그러나 임베디드 시스템의 신뢰성을 극대화하기위한 좋은 설계는 무엇입니까?

정적으로 버퍼 풀을 사전 할당하고 동적으로 가져오고 놓는 이유가 메모리를 동적으로 할당하는 것과 다릅니다.

Answer 1

:

• 당신은 U-부팅 부트 로더를 보면, 많은입니다 세계적으로 배치 된 구조로 완성되었습니다. 정확한 응용 프로그램에 따라 글로벌 구조와 스택으로 벗어날 수 있습니다. 물론 부트 로더에는 실제로 적용되지 않지만 사용자에게 도움이 될 수있는 재진입 및 관련 문제가 있습니다.
• preallocate, preallocate, preallocate. 디자인 타임에 배열 /리스트 구조체/etc의 크기를 바인드 할 수 있다면 전역 (또는 정적 전역보기 Ma, 캡슐화)으로 선언하십시오.
• 스택은 매우 유용합니다. 필요하면 스택을 사용하십시오.하지만 스택 공간이 없을 때까지 할당을 계속하기가 쉽기 때문에주의하십시오. 한 번 내가 디버깅을 한 번 발견 한 코드는 여러 함수에서 문자열 관리를 위해 1k 버퍼를 할당합니다 ... 가끔 기본 스택 크기가 4k 인 경우 버퍼의 사용이 다른 프로그램의 스택 공간을 차지합니다.
• 버퍼 풀의 경우는 구현 방법에 따라 달라질 수 있습니다. 컴파일 타임에 알려진 크기의 고정 크기 버퍼를 전달해야하는 경우 버퍼 풀을 처리하는 것이 완전한 동적 할당 자보다 정확성을 입증하는 것이 더 쉽습니다. 버퍼가 손실 될 수 있는지 확인하고 처리가 실패하지 않는지 확인해야합니다. 여기에 몇 가지 좋은 팁이 될 것 같다 :

http://www.cotsjournalonline.com/articles/view/101217 정말하지만, 당신의 대답은 내가 DO-178B 환경 (항공기에 대한 시스템)에서 근무했습니다 http://www.do178site.com/

Answer 2

스택에서 모든 것을 할당하는 것은 일반적으로 임베디드 시스템이나 할당 실패의 가능성이 용인 할 수없는 곳에서 이루어집니다. 나는 DO-178b가 무엇인지 모르지만 문제는 malloc을 플랫폼에서 사용할 수 없다면 스스로 구현할 수도 있지만 (자신의 힙 구현) 여전히 실행할 때 할당이 실패 할 수 있습니다 물론 우주에서.

Answer 3

실시간으로 실행되는 중요한 시스템은 힙에서 동적으로 메모리를 할당하고 해제하지 않아야합니다. 에이 필요하다면 주변에 디자인하여 자신의 할당 및 고정 풀 관리 체계를 작성할 수 없습니다. 가능합니다. 가능할 때마다 미리 고정되어 있습니다. 다른 것은 궁극적 인 문제를 요구하고 있습니다.

Answer 4

100 % 확신 할 수있는 방법이 없습니다.

FreeRTOS의 메모리 할당 자 예제를 살펴볼 수 있습니다. 실수가 아니라면 정적 풀을 사용합니다.

Answer 5

재미있게도 this question을 발견 할 수 있습니다. 동적 할당은 공간 강화 설정에서 종종 금지됩니다 (실제로 코어 메모리는 여전히 유용합니다).

일반적으로 malloc()을 사용할 수없는 경우 스택을 사용합니다. Tronic이 말했듯이 malloc()을 사용하지 않는 이유는 실패 할 수 있기 때문입니다. 전역 정적 풀을 사용한다면, 내부 malloc() 구현이 실패 증명이 될 수 있다고 생각할 수 있습니다.

정말로 정말로 정말로 당면한 과제와 게시판이 무엇에 노출되는지에 달려 있습니다.

Answer 6

면책 조항 : 특히 DO-178b와 관련하여 일한 적이 없지만 인증 시스템 용 소프트웨어를 작성했습니다. I 개발자이었을하는 인증 시스템에서

...

1. 동적 메모리 할당 만 초기화 단계 으로 허용되었다.
2. 동적 메모리 할당 해제는 절대로 받아 들일 수 없습니다.

이은 ... 다음과 같은 옵션이

• 를 사용하여 정적으로 할당 된 구조를 우리를 떠났다.
• 구조체 풀을 생성 한 다음 구조체의 풀을 풀에서 풀/풀합니다.
• 유연성을 위해 초기화 단계에서 풀 크기 또는 구조 수를 동적으로 할당 할 수 있습니다. 그러나 일단 init 단계를 지나면 우리는 우리가 갖고있는 것에 매달 렸습니다.

우리 회사는 구조 풀을 풀에서 풀/풀을 풀하는 것이 가장 유용하다는 것을 알았습니다. 우리는 모델을 계속 지킬 수 있었고 최소한의 문제로 결정적인 것을 유지할 수있었습니다.

희망이 있습니다. (하지만 나는 DO-178B 읽고,) 아니지만 같은 엄격함에 지금까지 임베디드 시스템 취급이있는 사용자로

Answer 7

에 합류에서 찾을 수 있습니다 생각합니다. 내가 이해 한 것은 동적 할당을 허용하지 않는 주된 이유는 주로 인증이라는 것입니다. 인증은 테스트 (단일, 범위, 통합, ...)를 통해 수행됩니다. 이러한 테스트를 통해 프로그램의 동작이 100 % 예측 가능하다는 것을 입증해야합니다. 즉, 프로세스의 메모리 사용 공간이 한 실행에서 다음 실행으로 동일 할 때까지 모두 예측할 수 있어야합니다. 힙에서 동적 할당이 이루어지기 때문에 (쉽게 실패 할 수 있습니다) 하드웨어를 사용하여 모든 도구를 마스터하면 작성해야하는 코드 조각까지도 가능해야한다고 생각합니다. 정적 할당에이 문제가 없습니다. 또한 C++이 이러한 환경에서 현재 사용되지 않은 이유이기도합니다. (약 15 년 전 변경되었을 수 있습니다 ...)

실제로 구조적 풀과 할당 함수를 많이 작성해야 결정 성이 보장됩니다. 당신은 많은 솔루션을 상상할 수 있습니다. 핵심은 높은 수준의 결정 론적 동작을 증명해야한다는 것입니다.linux + gcc가 메모리를 할당하는 데 결정 론적이라는 것을 증명하기 위해 결정 론적으로 발달 된 작업을 손으로 만들었다는 것을 증명하는 것이 더 쉽습니다.

그냥 2 센트입니다. 오래 전 일이 바뀌었지만 DO-178B와 같은 인증에 관해서는 모든 상황에서 언제든지 앱이 동일하게 작동한다는 것을 증명하는 것이 중요합니다.