Jump to content

    

Forger

Свой
  • Content Count

    1476
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Forger

  • Rank
    Профессионал

Recent Profile Visitors

3492 profile views
  1. Нормально отнесется, просто, не надо использовать эту кучу в Keil RTX, там есть такая возможность. Я так делаю. Такую же ось использую, перешел на нее с freeRTOS. Штатная куча у меня всего 16 байт, опытом установлено, что это - необходимый минимум.
  2. Я же говорю - отказаться от использования штатной кучи , используйте стороннюю.
  3. Есть простое решение - отказаться от использования штатной кучи. Вообще. Во всех своих проектах именно так и сделал - одной головной болью меньше ;)
  4. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0349a/CJAGAAHA.html Нужно переопределить библиотечную функцию __user_setup_stackheap() или __user_initial_stackheap() и учесть, что они вызывается автоматом ДО вызова main().
  5. А как вы собираетесь из кода выяснять какого объема ОЗУ стоит снаружи? Кстати, какой компилятор?
  6. Есть и другой способ - при создании самостоятельно выделять области для стека каждой задачи (не обязательно одинакового размера) и при ее перезапуске использовать те же самые области. Практически во всех RTOS есть такая возможность.
  7. https://doc.micrium.com/display/kernel304/Task+Control+Blocks+TCBs
  8. Шучу я )) Если серьезно, то функционал, который описал выше, можно встроить прямо в саму RTOS, добавив соотв. поле в TCB каждой задачи. Ведь по сути watchdog task работает с максимальным приоритетом и вызывается чуть ли не каждый системный такт. В таком случает нет смысла создавать для этого отдельную задачу. Т. е. делаем соотв. hook в task sheduler и немного расширяем структуру TCB. Наверняка в более серьезных ОС это и так уже сделано.
  9. А кто контролирует внешний?
  10. При своем создании задача сразу объявляет свой индивидуальный timeout, помещается в список отслеживаемых задач и запускается. По сути реализуется работа диспетчера задач как в винде, где зависший процесс через некоторое время (настраивается в реестре) будет убит. Тут убивать задачи нельзя, но можно делать соотв. запись в журнал событий и идти на ресет. WDT по сути вырождается в некую watchdog task, которая мониторит другие задачи. Т.е. что-то по типу программного вочдога. Но аппаратный WDT все же нужен, он может работать в паре с watchdog task, а может даже и ее саму контролировать.
  11. Скорее выяснится что земля оказывается плоская :)
  12. Стоимость этой "процедуры" будет превышать стоимость вашего нового прибора во много-много-много-много-много-много-много раз :)
  13. Изначально вопрос звучал совсем другой: Подскажите как правильно организовать сброс сторожевика? Теперь оказывает вам нужно совсем другое: контролировать вотчдог (из кода), хотя по логике все должно происходить с точность наоборот. Определитесь уже :) Кстати, в статье по ссылке все расписано вполне доступно.