Микроконтроллеры PIC

Сегментация (фрагментация) -- это сказочный миф (те кто не пользуют -- особенно хорошо о сегментации знают, ага). Практически же возможность фрагментации зависит от того, каким образом выделяется память в программе и от стратегии выделения памяти. Учебный пример из книг не очень работает в современной glibc и даже в windows, например (спасает, скорей, страничная огранизация памяти в x86). В типичном же случае о фрагментации можно не вспоминать. Если явление таки есть, то проще изменить стратегию выделения памяти для фрагментирующихся данных на уровне прикладной программы, чем вместо того отказываться от работы с линейной организацией выделенных блоков памяти (т.е. все библиотеки, весь код, всё писать своё с нуля). Кроме того, если программа (ембеддед) рано или поздно возвращается в какое-то начальное состояние освобождая всю память, например, то ставить вопрос о фрагментации в долговременном масштабе тоже смысла нет. Во многих случаях когда говорится о фрагментации вообще, повторюсь, стоило бы думать о некачестенной реализации malloc() (в качестве аналогии могу привести FAT -- первые версии DOS тоже были склонны к фрагментации, но по прошествию лет выясняется, что фрагментация в FAT можете мало чем отличаться от фрагментации в ext3, например). Либо особенности прикладной программы, что проще исправить тут же, для вызывающей проблему части программы исключительно. Основываясь на своём опыте могу сказать, что фрагментация, по большей части -- миф, такой же как "нельзя использовать goto" (студентам может и нельзя...) Альтернативы же malloc() я не вижу, разумной. Неразумная: взять в N раз больше физической памяти и всё распределить статически. Или знать, что в один момент времени в A[125] у нас хранится одно, а в другой момент времени диапазон с A[100] под A[150] занимает что-то другое (я и такое своими глазами видел...) Или выделять исключительно блоками фиксированных размеров. Но здесь во-первых тоже скрытая фрагментация (блоки больших размеров делятся на блоки более мелких и можно добиться, что блоков большого размера не останется, либо если не делятся, то памяти физической опять же больше нужно), во-вторых для больших массивов необходимость отказа от библиотечных функций (нелинейная организация памяти). Наименее неразумный вариант: "garbage collector". Касательно ссылки. Наличие BYTE и WORD, отсутствие внятных комментариев и какого-то теста, ни единого assert и отсутствие отладочной печати дают понимание, что доверять таким алгоритмам особенно не стоит. В хорошем malloc() для embedded напрашивается к тому же проверка границ блоков (периодически и при манипуляциях с ними). У меня есть свой (краденный из AVR libc кажется) malloc но я из описанных-то соображений и предпочёл ему библиотечный, но по-ходу дела последний ещё хуже.