[an error occurred while processing this directive]
Просто держись подальше от С++ в MCU-системах. Надежность-в простоте Си. Иначе WatchDog замучает.
(«Телесистемы»: Конференция «Микроконтроллеры и их применение»)
Отправлено
ETM
03 июля 2006 г. 02:01
В ответ на:
так вот, возращаясь к теме надёжности ПО (+)
отправлено DASM 03 июля 2006 г. 01:51
Составить ответ
|||
Конференция
|||
Архив
Ответы
не вижу повода не использовать ++ и STL при условии детерминированности расхода памяти. 32 кила рама мне хватает на ++ за уши, вопрос только поиска своих ошибок в виде утечек
—
DASM
(03.07.2006 02:03
212.58.192.14
,
пустое
)
В RealTime системе диагностика ошибок адресации - это что-то!!!
—
ETM
(03.07.2006 02:10
62.117.85.87
,
пустое
)
да не надо мне это. Мне надо к паре new/delete поиметь ф-цию, типа GetFreeMem и GetFragmentStatus.... ясно выражаюсь ?
—
DASM
(03.07.2006 02:12
212.58.192.14
,
пустое
)
К паре это важно, конечно. Особенно если пары и не наблюдается вовсе.
—
-=ВН=-
(03.07.2006 09:25
82.208.94.245
,
пустое
)
А компилятор какой?
—
ETM
(03.07.2006 02:17
62.117.85.87
,
пустое
)
IAR хотя какая разница
—
DASM
(03.07.2006 02:17
212.58.192.14
,
пустое
)
Напиши свой аналог NEW через MALLOC c проверкой на NULL
—
ETM
(03.07.2006 02:27
62.117.85.87
,
пустое
)
Ну допустим, ты будешь знать в любой момень размер кучи и что это тебе даст? Если идёт утечка, значит надо прогу исправлять.
—
Дokтоp TyамOcec(Бан)
(03.07.2006 02:24
62.118.143.205
,
пустое
)
Ну однозначного решения с жтой проблемой пока не существует. Не будешь же ты в микроконтроллере использовать сборщик мусора
—
Дokтоp TyамOcec(Бан)
(03.07.2006 02:08
62.118.147.251
,
пустое
)
мне не собирать его надо, мне надо отслеживать размер доступной кучи, и, по возможности степень её фрагментации. Перефразирую, есть ли исходники malloc в debug варианте с указанными фичами
—
DASM
(03.07.2006 02:10
212.58.192.14
,
пустое
)
Наверняка должны быть. Не знаю как в Си++, но когда я работал на Borland Pascalе то там были библиотечные средства как для контроля размера кучи, так и ещё какие то функции (уже не помню) работы с кучей
—
Дokтоp TyамOcec(Бан)
(03.07.2006 02:16
62.118.145.73
,
пустое
)
это точно не подойдет для MCU. Нужен экономный по памяти вариант
—
DASM
(03.07.2006 02:17
212.58.192.14
,
пустое
)
Сдается мне это невозможно в принципе. Если тебе взбрендится разместить 100 тыс объектов а потом каждый второй удалить. Либо держи в памяти карту, либо дефрагментируй постоянно.
—
Codavr
(03.07.2006 09:48
193.233.48.103
,
пустое
)
Вы забываете что это не ПиСюк с его 4 Гигами оперативки. DASM же сказал на всё про всё 32 к. И я удивляюсь какие графические объеты можно втюхать в эти 32 к. Хотя можно: линия кодируется 4-мя байтами, окружность 3-мя.
—
Дokтоp TyамOcec(Бан)
(03.07.2006 11:07
62.118.145.164
,
пустое
)
32 кбайт это 256 кбит - вполне приличный монохромный монитор .
—
Codavr
(03.07.2006 15:26
193.233.48.103
,
пустое
)
Ответ: DASM пишет: "...кроме десятка других задач". Так шта...
—
Дokтоp TyамOcec(2хБан)
(03.07.2006 15:49
62.118.146.37
,
пустое
)
У меня десяток других задач обходится 500 байтами. Так шта....
—
Codavr
(03.07.2006 16:16
193.233.48.103
,
пустое
)
Наколько я понимаю DASM не использует ЖЕ память микроконтроллера как память графического адаптера, где каждый битик соответствует пикслелу на экране. И графические объекты он хранит в памяти микроконтролера не как матрицу пикселов, а как некие структуры данных, типа записей.
—
Доктор ТуамОсес(2хБан)
(03.07.2006 16:38
62.118.144.179
,
пустое
)
Тогда и подавно можно такую графику наворотить...
—
Codavr
(03.07.2006 16:45
193.233.48.103
,
пустое
)
Да уж..Можно микровинду забубенить.. Одно хреново - утечки памяти..Кстати, DASM, а как ты определил, что у тебя присходит утечка памяти?
—
Доктор ТуамОсес ++
(03.07.2006 17:10
62.118.144.39
,
пустое
)
Ответ:
—
Доктор ТуамОсес(Бан)
(03.07.2006 02:11
62.118.144.58
,
пустое
,
ссылка
)
уже лучше, но - ALLOC_INFO [] в AddTrack займет кучу памяти сама. Просто припоминая строения кучи думаю должна быть функция, котрая может просто просканировать heap и выдать нужную инфу.
—
DASM
(03.07.2006 02:15
212.58.192.14
,
пустое
)
"Множественное наследование делает процесс нахождения ошибки настолько трудоемким, что лучше не ошибаться совсем (например, процесс добавления указателя требует инициализации указателя во всех конструкторах и удаления указателя в деструкторе. Если код базовых классов недоступен, то утечки памяти неизбежны)"
—
Доктор ТуамОсес(Бан)
(03.07.2006 02:16
62.118.145.73
,
пустое
)
да какое нахрен множественное. Нету множественного. И код базовых мой
—
DASM
(03.07.2006 02:18
212.58.192.14
,
пустое
)
ладно, может утренние птахи чего придумают. Спать пора
—
DASM
(03.07.2006 02:23
212.58.192.14
,
пустое
)
Отправка ответа
Имя (обязательно):
Пароль:
E-mail:
NoIX ключ
:
Запомнить
Тема (обязательно):
Сообщение:
Ссылка на URL:
Название ссылки:
URL изображения:
Перейти к списку ответов
|||
Конференция
|||
Архив
|||
Главная страница
|||
Содержание
E-mail:
info@telesys.ru