Jump to content

    

Beginning

Свой
  • Content Count

    501
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Beginning

  • Rank
    Знающий
  • Birthday 06/09/1983

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array
  1. Давным давно делал опыт, и эти самые PolySwitch грелись не слабо при КЗ. Вроде как вообще не предназначены для долговременной сработки. Кто использовал? При КЗ сроком более 24 часа деградируют или нет? P.S. Планирую использовать 12V 1A.
  2. Походу трабл был в следующем. Я скопипастил рабочий проект и в ручную переименовал все файлы проекта на новое имя. К моему удивлению проект запустился и компилировался не выдовая ни каких ошибок. Возможно из-за этого и глючил. З.Ы. Создал новый проект -симуляция заработала как надо.
  3. Так я и не утверждаю что keil виноват. Но имею факт глюка. Для помощи в разборке причины и создал топик. P.S. Пример попробую.
  4. Ну как бы да. А вы нет? Если я нажимаю RUN то ожидаю что программа запустится, и остановится только тогда, когда я нажму stop или точка останова встретится.
  5. Дело вот в чём. Работал через отладчик (jetlink). Всё было OK. Решил попробовать через симулятор. Мне надо было отладить только алгоритм. Выбрал камень ARM cortex M3. IROM1 поставил 0/1000 IRAM1 - 2000000/1000 Запускаю программу на отладку. И что я вижу... работает только пошаговая отладка. Все кнопки (run, step over и т.д.) работают только в пошаговом режиме Это глюк или "фича" такая?
  6. Ну тут я вижу потенциальную проблему. Допустим памяти 100 байт. Есть две задачи. Сообщение занимает 100 байт. Какой стек вы выделите каждой задаче? Правильно по 100 байт и того получается 200, уже не влазим. Если есть куча, то система работоспособна. Разумеется память используется по очереди. Т.е. я хочу сказать что при использовании стека в качестве хранилища данных, мы должны зарезервировать его максимальный размер при старте. Т.е. это первый вариант.
  7. Я не очень понимаю выражения "не использовать кучу". Тут 2 варианта, либо ты резервируешь память раз и навсегда, либо динамически выдаёш, забираеш. В первом варианти торетически память в большинстве случаев будет простаивать.
  8. Наверняка так и есть. Но по поводу этого я не сильно переживаю, тут более менее всё понятно. Сильно напрягает наложение специальных требований на программу. Это основной костыль. Любые за уши притянутые паттерны я расматриваю как зло. Программа должна быть максимально естественна (проста) с точки зрения кода.
  9. Ну хотябы, если дефрагментация началась, то её уже не остановить наполовину, и в этот момент если более приоритетному потоку надо что то сделать то он этого не сделает - тоесть все остальные потоки автоматически становятся с более низким приоритетом.
  10. Не ну я прикидывал, мол если например кусок не разлочен в конце, а в начале все разлоченные, то можно только начало дефрагментировать, но это такие грабли, что и работать будет соответствующе.
  11. Я так понимаю это компромис. Зарезервировал память. Хочеш попользоваться -получай поинт, пользуйся. Не пользуешся разлочивай. Данные при этом не пропадают, но могут переместится. Отсюда два минуса - надо постоянно получать поинты и лочить/разлочить. Пока все не разлочат кучу, её не дефрагментируешь. Как по мне костыль номер один достаточно геморойный. Ну и как эта система, себя оправдала?
  12. Я уже писал про **p. Придётся везде лепить. А потом начнётся ***p и т. д.
  13. Картина собственно ясна. А теперь вопрос. Стоит ли ради дефрагментации накладывать на программу кучу обязательств - для всех манипуляций с указателями пользоваться только специальными функциями, иначе, если вдруг произошла дефрагментация, будет такой глюк, который практически нереально просчитать. Да же не так, интересует случай из практики, когда применялась дефрагментация и все + и - с этим связанные, и какое такое преимущество вынудило использовать дефрагментацию.
  14. Я тут немного поразмыслил и пришел к выводу что дефрагментация кучи это практически невыполнимая задача без костылей. Вначале я быстро прикинул алгоритм примерно такой. При выделении памяти в начале кучи выделяется собственно память а с конца (например, можно и в начале) выделяется указатели на понтеры, которые собственно и "получат память". Тогда выделение памяти будет выглядеть не так: byte *p = alloc(100); а так byte *p; alloc(&p,100); if(p!=NULL)... Делается это для того, что бы сохранить адрес понтера, и при дефрагментации кучи мы могли бы занести туда новое значение адреса. Но поразмыслив я понял что это накладывает кучу ограничений. Нельзя использовать: byte *pp,*p = alloc(100); pp = p; или p += x; т.е. изменять адрес Придётся использовать функции которые грамотно копировали бы поинтеры. Использовать **p тоже не хочется, усложнение на пустом месте. Есть ли простой способ, без костылей, дефрагментировать кучу?