Sử dụng malloc trong PIC

Làm thế nào tôi có thể sử dụng malloc()và các free()chức năng trong PIC? Tôi đã kiểm tra stdlib.htiêu đề và không có đề cập đến chúng. Tôi đang sử dụng MCC18.

Có ai phải sử dụng chúng?

Tôi cần chúng vì tôi đang chuyển một thư viện từ Windows XP sang PIC. Hướng dẫn porting nói với

điều chỉnh các chức năng cụ thể của Hệ điều hành cho các PIC của tôi

Nhưng tôi không biết làm thế nào để "dịch" các malloc()và free()các chức năng.

Trong nhiều ứng dụng, người ta sẽ cần phân bổ bộ nhớ, nhưng sẽ không cần giải phóng bất cứ thứ gì trong khi vẫn giữ thứ gì đó được phân bổ sau nó. Trên một hệ thống như vậy, tất cả những gì bạn cần làm là sử dụng trình liên kết để xác định một mảng bằng cách sử dụng tất cả RAM có sẵn, đặt một con trỏ đến đầu của mảng đó, sau đó sử dụng hàm malloc dễ dàng:

char * next_alloc;
void * malloc (kích thước int)
{
    char * this_alloc;
    this_alloc = next_alloc;
    if ((END_OF_ALLOCClickACE - this_alloc) <size)
      trả về -1;
    next_alloc + = kích thước;
    trả lại this_alloc;
}
khoảng trống miễn phí (void * ptr)
{
    nếu (ptr)
        next_alloc = (char *) ptr;
}

Đẹp và dễ dàng, và chỉ cần hai byte tổng phí cho bất kỳ số lượng phân bổ. Gọi free () trên một khối sẽ giải quyết khối đó và mọi thứ sau nó.

Các mẫu phân bổ hơi phức tạp hơn có thể được xử lý bằng cách sử dụng hai con trỏ - một mẫu phân bổ các công cụ từ dưới cùng của bộ nhớ di chuyển lên và một trong số đó đi từ đỉnh bộ nhớ xuống. Cũng có thể sử dụng một trình thu gom rác nén nếu dữ liệu trong heap là đồng nhất và người ta biết tất cả các tham chiếu bên ngoài đến nó.

malloc()trong vi điều khiển thường được coi là một "điều xấu". Nhưng, nếu bạn thực sự cần nó thì bạn sẽ muốn tìm phiên bản của bên thứ ba.

Nếu bạn may mắn, mã bạn đang chuyển có thể không dựa vào việc sử dụng lại các khối bộ nhớ. Nếu đây là trường hợp, bạn có thể viết một bộ cấp phát đơn giản trả về một con trỏ vào bộ đệm RAM, sau đó tiến bộ con trỏ theo kích thước khối được yêu cầu.

Tôi đã sử dụng thành công phương pháp này trước khi chuyển thư viện PC sang vi điều khiển.

Dưới đây, bạn sẽ thiết lập bộ cấp phát my_malloc_init()và phân bổ bộ nhớ với my_malloc(). my_free()ở đó để thỏa mãn sự phụ thuộc nhưng thực sự sẽ không làm gì cả. Cuối cùng, bạn sẽ hết dung lượng.

Để thực hiện công việc này, bạn sẽ cần đo yêu cầu bộ nhớ trong trường hợp xấu nhất của mã của bạn (thực hiện điều này trên PC nếu có thể) sau đó thiết lập HEAP_SIZEtương ứng. Trước khi vào một phần của thư viện yêu cầu bộ nhớ động, hãy gọi my_malloc_init(). Trước khi sử dụng lại, đảm bảo không có gì vẫn còn điểm heap.

uint8_t heap[HEAP_SIZE];
uint8_t *heap_ptr;

void my_malloc_init(void)
{
    heap_ptr = heap;
}

void *my_malloc(size_t len)
{
    uint8_t *p = heap_ptr;
    heap_ptr += len;
    if (heap_ptr >= heap + HEAP_SIZE)
        return NULL;
    else
        return p;
}

void my_free(void)
{
    // do nothing
}

(lưu ý: trong thế giới thực, bạn có thể cần xem xét căn chỉnh con trỏ, nghĩa là làm tròn lên heap_ptr2 hoặc 4 byte)

Một tùy chọn khác là sử dụng cấu trúc phân bổ đơn giản hơn malloc()thường cung cấp, như FreeList , mặc dù điều này có thể không cho phép bạn phân bổ các khối có kích thước thay đổi.

Đây không phải là một câu trả lời cho câu hỏi của bạn, nhưng việc phân bổ bộ nhớ động thường bị cau mày trong môi trường RAM nhỏ và không có hệ điều hành (ví dụ như trong thế giới vi điều khiển) ... không gian heap bạn có sẵn trong môi trường nhúng thường là được đo bằng hàng trăm byte ...

Việc triển khai malloc và miễn phí về cơ bản là duy trì một danh sách các cấu trúc "phân đoạn miễn phí" được liên kết và như bạn có thể tưởng tượng, siêu dữ liệu được liên kết với các phân đoạn miễn phí không phải là không đáng kể khi so sánh với lượng bộ nhớ thường có sẵn ... đó là "chi phí chung" "Việc quản lý nhóm bộ nhớ động sẽ tiêu tốn một lượng đáng kể tài nguyên có sẵn.

Tôi không biết thư viện chuẩn C18 có hỗ trợ mallochay không free, nhưng Ứng dụng Microchip Note AN914 cho thấy cách bạn có thể tự triển khai.

Trong mọi trường hợp, Thomas và các áp phích khác đã đề xuất, sử dụng bộ nhớ động trên PIC với không gian RAM rất nhỏ của chúng đầy rủi ro. Bạn có thể nhanh chóng hết dung lượng tiếp giáp do thiếu trình quản lý bộ nhớ ảo tiên tiến hơn mà hệ điều hành đầy đủ mang lại cho bạn, dẫn đến việc phân bổ và gặp sự cố không thành công. Tồi tệ hơn, nó có thể không mang tính quyết định và có thể sẽ là một nỗi đau để gỡ lỗi.

Nếu những gì bạn đang làm thực sự được xác định một cách linh hoạt vào thời gian chạy (hiếm khi xảy ra đối với hầu hết mọi thứ được nhúng) và bạn chỉ cần phân bổ không gian trong một vài dịp rất đặc biệt , tôi có thể thấy mallocvà freeđược chấp nhận.

Chà, PIC của bạn lớn đến mức nào về bộ nhớ?

malloc là một cách phân bổ bộ nhớ rất kém hiệu quả. Vấn đề với nó là bộ nhớ có thể bị phân mảnh với các giải phóng và mallocs thường xuyên và chỉ với một vài kilobyte bộ nhớ, các lỗi phân bổ là quá phổ biến. Rất có khả năng là nếu bạn đang sử dụng một con chip nhỏ hơn hoặc PIC18 trước đó thì không có hỗ trợ cho malloc, vì Microchip đã xem nó rất khó thực hiện (hoặc thậm chí là không thể trong một số trường hợp) hoặc không được sử dụng đủ cho nó đáng giá Không đề cập đến nó, nhưng nó cũng khá chậm, bạn đang xem 1 chu kỳ để sử dụng bộ đệm tĩnh đã có sẵn và 100 đến 1.000 chu kỳ để thực hiện một malloc.

Nếu bạn muốn phân bổ tĩnh, hãy tạo những thứ như bộ đệm cho các hàm sprintf của bạn (nếu có, khoảng 128 byte), bộ đệm cho thẻ SD của bạn (nếu có), v.v., cho đến khi bạn loại bỏ nhu cầu về malloc. Lý tưởng nhất là bạn chỉ sử dụng nó khi bạn thực sự cần nó và không thể thoát khỏi phân bổ tĩnh, nhưng những tình huống này thường rất hiếm và có thể là dấu hiệu bạn nên xem xét các bộ vi điều khiển lớn hơn / mạnh hơn.

Và nếu bạn đang phát triển / chuyển một "hệ điều hành" trên PIC18 và nếu nó hỗ trợ các bộ vi điều khiển thì có lẽ nó có hỗ trợ cho phân bổ tĩnh. Ví dụ, SQLite3 hỗ trợ phân bổ tĩnh - bạn phân bổ cho nó một mảng bộ đệm lớn và nó sử dụng điều đó khi có thể, mặc dù nó không dành cho vi điều khiển. Nếu không, thì bạn có chắc là nó được thiết kế cho PIC18 nhỏ không?

Nếu bạn đang xem xét malloc()và free()cho phần mềm nhúng của mình, tôi khuyên bạn nên xem uC / OS-II OSMemGet()và OSMemPut(). Trong khi malloc()cho phép bạn phân bổ một khối bộ nhớ tùy ý, OSMem*()hãy cung cấp cho bạn một khối có kích thước cố định từ một nhóm được phân bổ trước. Tôi thấy cách tiếp cận này là một sự cân bằng tốt giữa tính linh hoạt malloc()và sự mạnh mẽ của phân bổ tĩnh.

AFAIK, để làm điều này một cách chính xác, bạn thực sự cần phải nhìn vào một thiết bị với một loại đơn vị quản lý bộ nhớ (MMU). Mặc dù các cơ chế phân bổ động cho sê-ri PIC18 vẫn tồn tại, nhưng chúng sẽ không thực sự vững chắc - và nói như một người làm việc trên phần mềm đẩy các giới hạn của sê-ri PIC18, tôi có thể nói rằng bạn sẽ không nhận được một ứng dụng khá lớn trong đó nếu bạn dành toàn bộ chi phí cho trình quản lý bộ nhớ.

Giải pháp tốt hơn: cố gắng hiểu những gì nó đang làm và tại sao nó cần phân bổ động. Xem nếu bạn không thể tái xác định nó hoạt động với phân bổ tĩnh. (Có thể là trường hợp đơn giản là không thể - nếu thư viện / ứng dụng được thiết kế để làm một cái gì đó có tỷ lệ tự do hoặc không có giới hạn về số lượng đầu vào mà nó có thể chấp nhận.) Nhưng đôi khi, nếu bạn thực sự nghĩ về những gì bạn đang cố gắng thực hiện, bạn có thể thấy có thể (và thậm chí có thể khá dễ dàng) để sử dụng phân bổ tĩnh thay thế.