최근 Microblaze 용 C-Application을 작성했으며 uC/OS-II를 사용했습니다. uC/OS-II는 고정 된 크기의 메모리 블록을 할당하고 할당을 해제하는 메모리 풀을 제공합니다. 지금은 FreeRTOS를 사용하는 STM32 용 C-Application을 작성하고 있습니다. FreeRTOS 같은 메커니즘을 제공하지 않는 것 또는 뭔가 놓친 않았다 것? 나는 다섯 가지 힙 구현이 내가 원하는 것을 생각하지 않는다.uC/OS II와 같은 FreeRTOS의 메모리 풀
실제로 메모리 풀이없는 경우 특별한 이유가 있습니까?
FreeRTOS의 원래 버전은 메모리 풀을 사용했습니다. 그러나 사용자가 풀 크기를 결정하는 데 어려움을 겪었으므로 지속적인 지원 요청이 이어졌습니다. 또한 FreeRTOS의 원래 버전은 매우 제한된 RAM 시스템을 대상으로했기 때문에 크기가 큰 풀을 사용하여 낭비되는 RAM은 용인 할 수없는 것으로 나타났습니다. 따라서 하나 이상의 스키마가 하나의 응용 프로그램 서브 세트 이상에 적합하고 사용자가 자신의 스키마를 제공 할 수 있다는 점을 고려하여 메모리 할당을 휴대용 계층으로 이동하기로 결정했습니다. 거의 모든 응용 프로그램을 다루는 there are five example implementations provided을 언급했지만, 반드시 메모리 풀 구현을 사용해야하는 경우에는 자신의 pvPortMalloc() 및 vPortFree() 구현을 제공하여 쉽게 추가 할 수 있습니다 (메모리 풀은 더 쉬운 것 중 하나임) 구현).
또한 FreeRTOS V9에는 모든 것을 정적으로 할당 할 수 있으므로 메모리 할당 체계가 필요하지 않습니다.
힙의 다섯 가지 구현 예 중 하나는 OS (작업, 대기열 등)에 RAM을 할당하는 데 적합 할 수 있습니다. 이는 내 응용 프로그램의 경우 일 수도 있습니다. 하지만 같은 크기의 메시지 (기본적으로 바이트 배열)를 저장하고 싶다면? 이 경우에는 pacPortMalloc() 또는 vPortFree()를 사용할 수 없기 때문에 스레드 안전 메모리 풀을 구현해야합니다 (어쨌든 heap_1을 사용합니다). – Semaphor