Використання молока в PIC

Як я можу використовувати malloc()та free()функціонувати в PIC? Я перевірив stdlib.hзаголовок і про них не згадується. Я використовую MCC18.

Хтось мав ними користуватися?

Мені вони потрібні, оскільки я переношу бібліотеку з Windows XP в PIC. Посібник з перенесення говорить до

адаптувати конкретні функції Операційної системи до моїх функцій PIC

Але я не знаю, як "перекласти" функції malloc()та free()функції.

У багатьох програмах потрібно буде виділити пам'ять, але нічого не потрібно звільняти, зберігаючи щось, що було виділено після нього. У такій системі все, що потрібно зробити, - це використовувати лінкер для визначення масиву з використанням усієї доступної оперативної пам’яті, встановити покажчик на початок цього масиву, а потім використовувати приємну функцію легкого malloc:

char * next_alloc;
void * malloc (розмір int)
{
    char * this_alloc;
    this_alloc = next_alloc;
    якщо ((END_OF_ALLOC_SPACE - this_alloc) <розмір)
      повернення -1;
    next_alloc + = розмір;
    повернути this_alloc;
}
void free (void * ptr)
{
    if (ptr)
        next_alloc = (char *) ptr;
}

Приємно і просто, і всього два байти загальних накладних витрат на будь-яку кількість виділень. Виклик free () на блоці буде розміщувати цей блок і все після нього.

Трохи складнішими схемами розподілу можна керуватись за допомогою двох покажчиків - одного, який виділяє матеріал з нижньої частини пам’яті, що рухається вгору, а один з них йде зверху пам’яті вниз. Можливо також використовувати компактний збірник сміття, якщо дані в купі є однорідними і знається, де всі зовнішні посилання на нього.

malloc()в мікроконтролерах взагалі вважається «поганою справою». Але якщо вам це абсолютно потрібно, ви захочете знайти сторонні версії.

Якщо вам пощастить, код, який ви переносите, може не покладатися на повторне використання блоків пам'яті. Якщо це так, ви можете написати простий розподільник, який повертає вказівник у буфер ОЗУ, а потім переміщує вказівник на запитуваний розмір блоку.

Я успішно використовував цей підхід до перенесення бібліотек ПК на мікроконтролери.

Нижче ви встановите алокатор за допомогою my_malloc_init()і розподілити пам'ять за допомогою my_malloc(). my_free()є, щоб задовольнити залежність, але насправді нічого не зробить. Врешті-решт, у вас просто не вистачить місця.

Щоб зробити цю роботу, вам потрібно буде виміряти найгірший обсяг пам'яті свого коду (зробіть це на ПК, якщо можливо), а потім налаштувати HEAP_SIZEвідповідним чином. Перш ніж зайти до тієї частини вашої бібліотеки, яка потребує динамічної пам'яті, зателефонуйте my_malloc_init(). Перед повторним використанням переконайтесь, що все ще нічого не вказує 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
}

(зверніть увагу: у реальному світі вам може знадобитися розглянути вирівнювання вказівника, тобто округлення heap_ptrна 2 або 4 байти)

Інший варіант - використовувати більш просту структуру розподілу, ніж malloc()зазвичай надає, як FreeList , хоча це може не дозволяти виділяти блоки змінного розміру.

Це навряд чи є відповіддю на ваше запитання, але динамічне розподіл пам’яті, як правило, спокушається на невеликих середовищах оперативної пам’яті та за відсутності операційної системи (наприклад, у світі мікроконтролерів)… типовий купольний простір, який ви маєте у вбудованому середовищі, як правило вимірюється сотнями байт ...

Реалізація malloc та free - це, по суті, підтримка пов'язаного списку структур "вільного сегмента", і як ви можете собі уявити, метадані, пов'язані з вільними сегментами, не є істотними порівняно з типово наявним об'ємом пам'яті ... тобто "накладними" "управління динамічним пулом пам'яті вимагає значної кількості доступних ресурсів.

Я не знаю , якщо С18 стандартної бібліотеки підтримує mallocі free, але Microchip App Note AN914 показує , як можна реалізувати свої власні.

У будь-якому випадку, Томас та інші плакати пропонували використовувати динамічну пам’ять на PIC з їх дуже невеликим простором оперативної пам’яті загрожує небезпекою. Ви можете швидко вичерпати суміжний простір через відсутність більш досконалих менеджерів віртуальної пам’яті, які дають вам повноцінні операційні системи, що призводить до невдалого розподілу та збоїв. Гірше, що це може бути не детермінованим, і, швидше за все, це буде біль налагодження.

Якщо те, що ви робите, по-справжньому динамічно визначається під час виконання (рідкісне для більшості вбудованих речей), і вам потрібно виділити простір лише на пару дуже особливих випадків, я міг би бачити mallocі freeбути прийнятним.

Ну, наскільки великий ваш ПОС щодо пам’яті?

malloc - це дуже неефективний спосіб розподілу пам’яті. Проблема з цим полягає в тому, що пам'ять може роздроблено за допомогою частого звільнення та зловмисних програм, і лише кілька кілобайт пам'яті, помилки розподілу є занадто поширеними. Цілком ймовірно, що якщо ви використовуєте менший чіп або більш ранній PIC18, немає підтримки для malloc, оскільки Microchip або вважав це дуже важким для реалізації (або, можливо, навіть неможливим у деяких випадках), або недостатньо використовувався для того, щоб бути того варто Не кажучи вже про це, але це також досить повільно, ви дивитесь на 1 цикл, щоб використовувати статичний буфер, який уже доступний, і 100s на 1000s циклів, щоб зробити malloc.

Якщо ви хочете виділити статично, створіть такі речі, як буфер для своїх функцій sprintf (якщо такий є, близько 128 байт), буфер для вашої SD-карти (якщо такий є) тощо, поки не усунете необхідність у malloc. В ідеалі ви використовуєте його лише там, де вам це абсолютно потрібно, і не можете уникнути статичного розподілу, але такі ситуації, як правило, рідкісні і, можливо, є ознакою того, що вам слід дивитись на більші / потужніші мікроконтролери.

І якщо ви розробляєте / переносите "операційну систему" на PIC18 і якщо вона підтримує мікроконтролери, вона, ймовірно, має підтримку статичного розподілу. Наприклад, SQLite3 підтримує статичний розподіл - ви виділяєте йому великий масив буфера, і він використовує це, де це можливо, навіть якщо це не для мікроконтролерів. Якщо це не так, то ви впевнені, що він призначений для невеликого PIC18?

Якщо ви розглядаєте malloc()і free()для програмно-апаратних засобів , я пропоную вам поглянути на УНЦ / OS-II і OSMemGet()і OSMemPut(). Хоча malloc()ви дозволяєте виділити довільний блок пам'яті, OSMem*()надайте вам блок фіксованого розміру з попередньо виділеного пулу. Я вважаю такий підхід хорошим балансом між гнучкістю malloc()та надійністю статичного розподілу.

AFAIK, щоб зробити це правильно, вам справді потрібно дивитись на пристрій з якимось блоком управління пам’яттю (MMU). Хоча існують динамічні механізми розподілу для серії PIC18, вони насправді не будуть такими надійними - і, говорячи як хтось, хто працював над прошивкою, що розсуває межі серії PIC18, я можу сказати, що ви не збираєтеся отримувати велика програма там, якщо ви витратите всі накладні витрати на диспетчер пам'яті.

Краще рішення: спробуйте зрозуміти, що це робить, і чому йому потрібно динамічне розподілення. Перевірте, чи не можете ви перефактувати його для роботи зі статичним розподілом. (Може статися так, що це просто неможливо - якщо бібліотека / додаток призначені для того, щоб робити щось, що вільно масштабується, або не має меж кількості вкладених даних, які він може прийняти.) Але іноді, якщо ви дійсно думаєте про те, що ви намагаєтеся зробити, ви можете виявити, що можна (а можливо, навіть досить просто) використовувати замість нього статичне виділення.