Смысл в том, что данные приходящие по UART сбрасываю в буфер RS232_RX_BUFFER. Потом при его заполнении выставляю флаг. Главная программа если видит флаг, то создает динамический массив того же размера что и RS232_RX_BUFFER и начинает его декодировать. Зачем сделана двойная буферизация? - Отвечаю: так надо

В коде происходит так:


если же динамический массив не использовать то проверка на валидность пакета проходит без проблем. Вот так работает:


Вот обработчик пакета:


Вот считалка контрольной суммы. Функция - табличная.


В общем если кто может сказать почему у меня возникли проблемы при обработки динамич. массивов - заранее огромное спасибо!!!

P.S. Контроллер: AT90USB162, у него RAM 512 байт.

Складывается ощущение, что вы должны уложиться со всеми этими копированиями-декодированием за время от момента возникновения сигнала overflow до прихода следующего символа по rs232 (не так уж много). Это так, или com порт у вас с fifo? В любом случае попробуйте на время обработки буфера запретить прерывания и посмотреть, есть ли разница.

Когда придумаете , тогда и пишите программы с менеджерами памяти для контроллеров с 512B
Заодно всякую ненужную галиматью типа buf1 = memcpy() уберите. Ну а дальше пойдут времена, правильная работа с флагами, критичесими секциями....

Кстати о двойной буфферизации. А кто мешает второй буфер сделать статическим, если он уж очень нужен?

sergeeff

Пакеты с ПК я выдаю вручную. Так что копирование-перекодирование успевает 100 пудов.

Тут явно проблема либо с нехваткой ОЗУ (которую я попытаюсь явно выявить) либо глупая ошибка при передачи массива по указателю в функцию.


Ничего не мешает. Причем опытные железячные программисты так и советуют сделать (в случае избежания случая если ОЗУ не хватит, а если делать статически - то компилятор хотя бы выдаст ошибку переполнения ОЗУ) - но тем не менее не понятно почему так происходит. Еще одна причина - у меня не только буфер по УАРТу но и по другим интерфейсам - поэтому в теле main была идея использовать один динамический массив чем несколько статических под каждый буфер.

zltigo

Да, ну так расскажите где тут "галиматья"? Или знаете как по-другому и по-быстрее скопировать один массив в другой (при одинаковых размерах)?


работаю последовательно. так что пальцы гните перед другими!

Галиматья специально отцитирована "buf1 =" она и есть родная.

Да хоть зигзагами, только думать и обрабатывать ошибки возвращаемые malloc() по любому надо.

zltigo

согласен. но на тот момент обработчика не придумал.
malloc(), кстати, возращает одну ошибку - это 0.
щас напишу обработчик malloc() и посмотрю что он возвращает.

Дополнил код вот так:


По УАРТу когда отослал пакет в контроллер вернулся код 99. Т.е. malloc() память не выдел. При компиляции вот что выдается:
Bit variables area: 2h to 2h
Bit variables size: 1 byte(s)

Data Stack area: 100h to 17Fh
Data Stack size: 128 byte(s)
Estimated Data Stack usage: 42 byte(s)

RAM Global variables area: 180h to 1D4h
RAM Global variables size: 85 byte(s)

Hardware Stack area: 1D5h to 2FFh
Hardware Stack size: 299 byte(s)

Heap size: 0 byte(s)

EEPROM usage: 0 byte(s), 0,0% of EEPROM
Program size: 2927 words (5854 bytes), 35,7% of FLASH

Слабо вериться что в ОЗУ не нашлось куска в 10 байт.

А куча (heap) вообще-то существует? И размер ее?

sergeeff

не знаю что это такое но после компиляциии и линковки пишет что

Вообще-то он возвращает NULL, что в 'C' (void *)0.

Это и так ясно было с самого начала.

Ну и зачм по прежнему болтается это присвоение buf1 и ненужные письмена для явного преобразования buf1 и чего-то (зачем-то коcящего под макрос) к указателю на байт, хотя он buf1 сам по жизни такой, а аргументы memcpy() вообще универсальные void *


Написано-же, что не существует, как класс:

Раз не знаешь, что такое heap, не пользуйся функциями выделения/освобождения памяти или разберись с этим вопросом. Похоже, что динамический массив в данной задачи на фиг не нужен, как, впрочем, и двойная буферизация, особенно учитывая дефицит RAM.

Ну все когда-то чего-то не знали... Динамическее выделение памяти во многих случаях весьма эффективно в том числе и для экономии памяти, однако делить остатки микроскопических 512 байт стандартым неуклюжим менеждером требующим и ресурсов и, что еще более неприятно, требующим явного резервировния хипа, сколее всего очень неудачная идея. При необдуманом использовании предстоит познакомится и со словом дефрагментация . Для микроскопических контроллеров в большинстве проще и много эффективнее размещать (при необходимости) динамические объекты в стеке. Ну недостаток, конечно, отсутствие штатных средств конроля, но зато минимум накладных и равноправный доступ к столь ограниченным ресурсам, как память.

Что-то у меня про эффективность динамической памяти не сильно язык поворачивается так сказать. Я бы сказал, что это компромиссное решение, когда программных модулей много, а свободных ресурсов памяти - не очень. И как обычно бывает за такой компромисс приходится расплачиваться накладными расходами на резервирование/освобождение памяти и ее фрагментацию.

Жаль что тут никто реальным советом не помог. "Раз не знаешь - то мол не трогай" - это ко мне не относиться и к подобным высказываниям в свой адрес отношусь негативно т.к. не учился на домохозяку. А раз так то пришлось разобраться самому с этим heap.
Heap - как я понял почитав пару статей в инете - это и есть область памяти где работает malloc и смежные ей функции при динамическом распределении ОЗУ. Но чтобы было всё хорошо её надо определить в компоновщике. В своем компиляторе (CAVR) я ей (свалке) выделил 20 байт - и вуаля, всё заработало!!! malloc теперь NULL не возвращает. Другое мне не понятно - почему компилятор на счет примененного мной malloc() ничего не вякнул.



Отсюда следует - что 20 байт компоновщик отнял от области памяти стека. ВОт это уже интересно!

Вы так считаете . Тогда Вы зря чрезмерно дистанциируетесь от домохозяйки



Потому, что Вы описали сегмент heap, хотя и нулевого размера. Уберите сегмент и будет вякать.

Cюрприз, если, конечно не читали предыдущий пост. Впрочем, Вы можете и сами реализовать свой менеджер памяти сгладив особо мешающие Вам лично недостатки.

А Вы полагали, что он материализует их из окружающего пространства . 20 байтовый heap это точно профанация идеи, может создаваться ну разве только для нужд библиотечных функций типа time().

Забудьте как страшный сон попытки использовать динамическое распределение памяти на таких контроллерах,
это возможно только с памятью ~8Kб+ хотя я например и на 32Кб стараюсь все в статике распределить.

Не стоит только этот один козий библиотечный malloc и встроенный heap ассоциировать со всем многообразием "динамического распределения" памяти.

Пусть есть некий пул состоящий из 5-ти буферов, объявленный статически:
TBUFFER pool[5];

Если подумать, то можно без накладных расходов по скорости и без всяких проблем с фрагментацией брать из этого массива свободный буфер, поработав - возвращаеть его на место. Это тоже будет __динамическое__ распределение памяти.

надо только написать свои:
TBUFFER *pool_alloc();
pool_free( TBUFFER *);

Совершенно никакой разницы нет в том, как именно вы собираетесь выделить память под heap. А автору топика, вместо того, чтобы "накатывать" на форумчан, что "мало" помогают, неплохо было бы разобраться в том, как современные с/с++ компиляторы распределяют сегменты RAM для различных типов данных. А heap на 20 байт - это полная и бессмысленная фигня. Вы прикиньте, сколько места сожрали программы для ее обслуживания.

Кроме того, при использовании heap, у вас и озу было потрачено. При чём соотношение затрат к размеру кучи в % уже говорит в пользу отказа от такого подхода.
Даже в учебных целях, размер кучи (собственно выбор камня) неудачен.

В тоже время, это совершенно не значит, что для работы с динамической памятью нет места в однокристалках. Многие используют динамическую память. Есть кристаллы с 4/8/64к оперативки. Там это применимо. В одном случае я применял динамику в м88 (1к). Там, конечно, нет полной работы с кучей, а только выделение памяти и освобождение её всем куском, но всё-же.

Ну, тогда по большому счету и запись переменных в union тоже можно назвать динамическим ну если не распределением, то использованием памяти.
Флаги занятости добавить - и гордое слово "распределение".

Нет там было честное выделение памяти. Работа с датчиками 1-ware. При соединении - выделялась память для датчика и туда заносился номер его. А вот удаление не по штучно, "а разом"
Ну так задача стояла. Никто по большому счёту не мешал и полному управлению с поштучным удалением и дефрагментацией. Не такие уж накладные расходы.

Например, по такому принципу, можно построить работу с таблетками или RFID картами.

На мой взгляд если говорить о динамической памяти, то она должна, как минимум поддерживать malloc/free.

Я бы перефразировал это в что-нить типа:
... должна иметь эффективный алгоритм отведения/освобождения памяти для элементов РАЗНОГО размера.

Эффективность алгоритма - дело десятое. Важнее - функциональность. Тут коллеги приводят примеры, когда выделение/освобождение может вообще раз-другой и производится.

Под эффективностью я имел в виду не только скорость алгоритма но и то что под 5 байт не будет выделяться 100байт.
Такой "обобщенный" параметр сводящийся к общей эффективности решения.

Вообще-то эффективность менеджера памяти - понятие разностороннее. Например, у меня в последнее время хитрозадый менеджер сделан с точки зрения минимизации времени нахождения внутри критической секции. В двух словах - там кэш уже аллоцированных кусочков. Но, правда, это ведет к некоторому перерасходу по памяти. Зато критическая секция теперь представляет из себя просто запрещение прерываний на время удаления/добавления элемента в односвязный список, причем, в исключительно в начало. Типа такого:

и


А остальная обвязка выполняется в незаблокированном состоянии.

Я бы не стал перефразировать и конкретизировать.
Динамическое распределение, как было сказано, - это возможность захватить и освободить ресурс - alloc/free.
Размеры это уже дело десятое.


Если знаете что там всегда 5 байт, то выделите себе 5 байт статически.
А если не знаете сколько, то чем не устраивает брать по 100?

мда, как говориться - начали за здравие и заканчиваем - за упокой.
Не надо на меня наговаривать что мол "гоню по чём зря" - как всегда народ тут отвечает общими фразами не предлагая никаких конкретных мыслей. Причем сопровождая "пальцевращением"

Поскольку malloc() аппаратно контроллером не поддерживается то создам статический буфер т.к. его размер и когда/кем будет использован знаю.
Вопрос на счет "материализовался": почему когда создается куча то память отбирается у области ОЗУ где Hardware Stack а не, скажем, у Data Stack ? Почему так?

Извиниться не хотите, перед теми, кто тратил на Вас свое время?

zltigo мне не за что извиняться т.к. никого тут не оскорблял. и, кстати, решение проблемы нашел сам тогда как некоторые тут откровенно стебались и разводили демагогии.

Сам?
Значит, этого так таки и не читали:




мдя...
Таки гоните. Причём нагло.


Так навскидку - в используемом Вами инструментарии где-то задан размер стека данных. Стек данных просто пошёл на правах статически выделенного массива, а стеку управления было отдано всё, что осталось. После выделения памяти для кучи осталось меньше. Т.е. стек управления просто получает то, что осталось от всех остальных.

Только вот думаю - был ли смысл отвечать, если аффтар "не читатель, а писатель"? И опять заявит, что

Особенно понравилось у автора про аппаратную поддержку malloc()

Аппаратный malloc - это гениальная идея не менее гениального автора. Успехов вам, дорогой товарищ!

Именно об этом мы и говорим. И я конкретно.
Только если мы говорим об AVR, то кроме этого практически ничего нет. То есть функциональность диспетчера нулевая. Если у меня будет "дырка", то он даже не вставит.
Именно по этому некоторые присутствующие писали свой диспетчер и приводили его фрагменты на форуме. Например, zltigo. Тоже себе ставлю такую задачу, но это длительная работа. Желательно оценить надёжность работы перед активным применением, а времени не хватает.


С точки зрения программы, если не один раз - то дальше без разницы - 2,3... Если речь о функциональности. А если о эффективности, - тогда дело другое.
Если рассматривать общий случай, то производительность системы будет падать, так как на работу с динамикой придётся затратить ресурсы. А вот с точки зрения эффективности потребления памяти - выигрыш может оказаться решающим.

Особенно очевидным, является применение динамики там, где размер объектов, помещаемых на кучу, имеет переменное значение.

Например станок с ЧПУ. Имеет 5 инструментов. Из внешнего источника подгружается прога с операциями. Операция может иметь много полей (одним сверлом - 10 отв). Я могу динамически размещать операцию и удалять по исполнению. А размещать для того, чтобы эффективней расчитать работу инструмента.

Как и любую задачу в программировании, эту можно решить десятком способов. С применением динамики и без оного. Как кому удобно. Но если есть данный инструмент, то почему им нельзя пользоваться? Даже если без этого можно обойтись?

Вы для интереса почитайте про такой аллокатор TLSF (http://rtportal.upv.es/rtmalloc/). Там проблемы "дырок" во многом решены и работает он шустро и эффективно. Для AVR можете попробовать портировать. Он целиком на С.

У Вас таки не динамическое распределение получается а нечто
очень похожее на оверлеи, а это совсем другая задачка и там все(ну почти все) можно заранее предусмотреть(в статике)

З.Ы. Собственно мое ИМХО заключается в том что это 2 совсем разные задачки
- распределение(и возврат) памяти(по требованию)
- распределение расположения данных в ранее распределенной памяти

и у каждого способа есть свои + и -
но для процов с маленькой памятью первого способа просто нет...

Так про это самое все и говорят, что не фиг придумывать себе проблемы, там где их нет.

ReAl
гона тут не было. На тот момент времени проблема была решена размещением в ОЗУ "кучи". И имейте разницу понимать такие определения как "подсказка" и "решения". Подсказку дали, за что огромное спасибо, решение наковырял сам. Статический буферный массив был мной применем с самого начала но захотелось поэкспериментировать и для уменьшения используемой ОЗУ (так предполагалось) применить динамический - и цель создание темы - разобраться почему динамика не работала. Не высасывайте из пальца того, чего не было. Это нагло

Сергей Борщ крутите пальцем в другом месте. Если Вы не заметили - то тут раздел называется В помощь начинающему а не Раздел для профессионалов/гуру.


Спасибо!!! И предлагаю на этом закончить!

Даже начинающие должны подкреплять фактами свои утверждения. Итак, пожалуйста, приведите пример хоть одного процессора с аппаратной подержкой malloc(). Ну или хотя бы опишите функциональность этой самой аппаратной поддержки. Заметьте - вы это не спрашивали, вы утверждали. Поэтому ссылка на начинающих не катит. Утверждаете - отстаивайте свое утверждение, даже если вы и начинающий. В противном случае вы будете считаться балаболом.
Что мне писать в каком разделе - позвольте я буду решать сам. Или вы хотите, чтобы в разделе для начинающих ответы писали только начинающие?
P.S. и постарайтесь не использовать дворовый жаргон. Тут это не принято.

О! Так вот в чём была "ПРОБЛЕМА"!
Попытались жарить рыбу без рыбы, не вышло, народ повыяснял насчёт наличия рыбы (Вы сами не смогли проинтерпретировать выдачу используемого Вами компилятора)

и Вы таки догадались посмотреть, где у Вас рыбу берут.

"огромное спасибо" появилсь только сейчас, до этого было, как раз в ответ на выяснение наличия места под кучу:
Кстати, что Вы понимаете под "реальным советом" и "решением"?
"подведи мышку к такому-то пункту меню, войди на такую-то страничку, в таком-то поле ввода набери число 20, нажми кнопку ОК"?
Так, во первых, это и невозможно было сказать, так как до этого Вы не удосужились указать какой у Вас инмтрумент.
А во вторых - это даже не "для начинающих", это в детсад.
Начинающему должно было хватить вопроса "а куча-то выделена?" - и хватило, не спорю, так не опускайте же сами себя до более низкого уровня!

Нет ну вы не совсем меня поняли. Я применил слово "программа", в смысле программа для станка с ЧПУ. То есть там, к примеру, координаты отверстия занесены. Это я так условно задачу привёл.
Никто не будет в станок ЧПУ передавать прогу на AVR для запуска оверлея.
Это уж через чур.

Где граница "малой памяти"? В одном моём проекте на м640 используется куча 5.8 кб. И применить там другое решение даже себе не представляю.

Дык понятное дело - по задаче надо смотреть и головой думать. Вот выделение/освобождение буфера фиксированного размера из пула буферов, как тут сказано, было частью ОС iDCX-51, которая вообще в 192 байтах ОЗУ в i8044 жила.

+1 Можно все навороты свести к функциям memavail(), maxavail() и defrag(void **ptr, size_t size) и пущай в тексте будет явно указано, какие указатели подлежат "перетрахиванию", а какие и трогать не надо. И с ограничением времени исполнения сего действа.

Вот о том и речь. Есть инструмент - можно им пользоваться. Но надо умело им пользоваться. И не фиг на зеркало пенять, когда рожа крива. (Это безотносительно к выступавшим)