Jump to content

    

Beginning

Свой
  • Content Count

    501
  • Joined

  • Last visited

Posts posted by Beginning


  1. Давным давно делал опыт, и эти самые PolySwitch грелись не слабо при КЗ. Вроде как вообще не предназначены для долговременной сработки.

    Кто использовал? При КЗ сроком более 24 часа деградируют или нет?

    P.S. Планирую использовать 12V 1A.

     

  2. Походу трабл был в следующем. Я скопипастил рабочий проект и в ручную переименовал все файлы проекта на новое имя. К моему удивлению проект запустился и компилировался не выдовая ни каких ошибок.

    Возможно из-за этого и глючил.

    З.Ы. Создал новый проект -симуляция заработала как надо.

  3. Дело вот в чём. Работал через отладчик (jetlink). Всё было OK.

    Решил попробовать через симулятор. Мне надо было отладить только алгоритм. Выбрал камень ARM cortex M3. IROM1 поставил 0/1000 IRAM1 - 2000000/1000

    Запускаю программу на отладку. И что я вижу... работает только пошаговая отладка. Все кнопки (run, step over и т.д.) работают только в пошаговом режиме

    Это глюк или "фича" такая?

     

  4. Ну тут я вижу потенциальную проблему. Допустим памяти 100 байт. Есть две задачи. Сообщение занимает 100 байт. Какой стек вы выделите каждой задаче? Правильно по 100 байт и того получается 200, уже не влазим. Если есть куча, то система работоспособна. Разумеется память используется по очереди.

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

     

  5. Я не очень понимаю выражения "не использовать кучу". Тут 2 варианта, либо ты резервируешь память раз и навсегда, либо динамически выдаёш, забираеш. В первом варианти торетически память в большинстве случаев будет простаивать.

  6. Наверняка так и есть. Но по поводу этого я не сильно переживаю, тут более менее всё понятно. Сильно напрягает наложение специальных требований на программу. Это основной костыль. Любые за уши притянутые паттерны я расматриваю как зло. Программа должна быть максимально естественна (проста) с точки зрения кода.

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

  8. Не ну я прикидывал, мол если например кусок не разлочен в конце, а в начале все разлоченные, то можно только начало дефрагментировать, но это такие грабли, что и работать будет соответствующе.

  9. Я так понимаю это компромис. Зарезервировал память. Хочеш попользоваться -получай поинт, пользуйся. Не пользуешся разлочивай. Данные при этом не пропадают, но могут переместится. Отсюда два минуса - надо постоянно получать поинты и лочить/разлочить. Пока все не разлочат кучу, её не дефрагментируешь. Как по мне костыль номер один достаточно геморойный. Ну и как эта система, себя оправдала?

  10. Картина собственно ясна. А теперь вопрос. Стоит ли ради дефрагментации накладывать на программу кучу обязательств - для всех манипуляций с указателями пользоваться только специальными функциями, иначе, если вдруг произошла дефрагментация, будет такой глюк, который практически нереально просчитать.

    Да же не так, интересует случай из практики, когда применялась дефрагментация и все + и - с этим связанные, и какое такое преимущество вынудило использовать дефрагментацию.

     

  11. Я тут немного поразмыслил и пришел к выводу что дефрагментация кучи это практически невыполнимая задача без костылей. Вначале я быстро прикинул алгоритм примерно такой. При выделении памяти в начале кучи выделяется собственно память а с конца (например, можно и в начале) выделяется указатели на понтеры, которые собственно и "получат память". Тогда выделение памяти будет выглядеть не так:

    byte *p = alloc(100);

    а так

    byte *p;

    alloc(&p,100);

    if(p!=NULL)...

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

    Но поразмыслив я понял что это накладывает кучу ограничений.

    Нельзя использовать:

    byte *pp,*p = alloc(100);

    pp = p;

    или

    p += x; т.е. изменять адрес

    Придётся использовать функции которые грамотно копировали бы поинтеры.

    Использовать **p тоже не хочется, усложнение на пустом месте.

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

     

  12. Проще говоря вы используете malloc и т.п. из библиотеки или свои? Я вот FreeRTOS изучаю. Решил досконально изучить исходники (heap_2). Честно говоря это треш какой то. Конечно как кому, но для меня такой стиль писания... Все эти x,px и и т.д. километровые имена. Принцип бритвы Оккамы походу не известен разработчикам. Пока всю эту дибилистику не убрал постоянно терялся на середине алгоритма. Как там, мозг не может запомнить одновременно более 7 переменных величин. Но да ладно не об этом. Вобщем мне не понравилась такая реализация - нету дефрагментации кучи. Взял стандартные библиотечные (KEIL RVDS). Но их тоже оказывается 2 реализации http://www.keil.com/support/man/docs/armli...ib_Cihfiabf.htm

    Как они толком работают, не поймешь - исходников я не нашёл.

    Вобщем кто какой реализацией пользуется? Может кто исходниками поделится. Камень Cortex.

     

  13. Отлаживаю контроллер STM32F100C8 через jetlink ultra. В среде можно ходить по шагам и видеть все регистры. USART работает - проверял в реальности на железе. Решил подцепить кейловский hyper terminal/ Но в него ничего не приходит. Облазил всю среду - настроек не нашёл. На сайте keil про этот terminal тоже сказано минимум - включил и должно работать. Поиск по нету дал несколько ссылок где задают такой же вопрос, без ответов.

    Как заставить работать (настроить) serial windows в keil?

  14. Settings->Color&Fonts->AllEditors->TextSelection

    4.53 проверено работает

     

    Проблему с кирилицей решают так. Пишем кирилицей в поле поиск Keil (или в любом месте где душе угодно), CtrlA+CtrlC+CtrlV, впрочем про это всё уже было сказано выше.

  15. Чем выше коэффициент усиления волнового канала тем резонанснее он. Что не очень хорошо для GSM который облодает широкой полосой. А на диапазон 1800 (или 900 если резонанс на 1800), походу вообще работать не будет.