Зависание компьютера было у меня несколько раз при максимальной загрузке процессора под 100% (motion + "motion_webcam не патченый" = сдетектили движение по всем камерам, пишем видео на диск (с конверсией на лету) и при этом еще просматриваем по сети картринки со встроенного в motion вебсервера. Ничего не помогало, даже по сетке через ssh войти не мог, короче только ресет.
Вот для этого дела на микроконтроллере ATmega8 была сделана "следящая собака" watchdog.
Причем применена программная реализация Virtual USB port for AVR Microcontrollers (http://www.obdev.at/products/vusb/index.html там есть схема типового подключения)
Т.е. теперь при начальной загрузке выставляем параметры собаки (к примеру 3 минуты), а затем в кроне или в своем демоне засылаем команду в собаку для сброса натикавшего счетчика, и так до тех пор пока не зависнем или не поменяем настройки. А еще при первом обращении к собаке считываем состояние предыдущее, т.е. была ли сработка собаки и пишем это дело в лог. Ну как-то так.
На уровне прототипов все нормально работает. Миниму деталей для работы с usb. Дешево и сердито.

Для себя я делал чуть посложнее, т.е. схемка еще подключена через max232 к COM порту бесперебойника и из него берет состояние, на основании которого принимает решение что делать:
1. Передать через usb компу данные о питании.
2. Сработала собака, а значит перезагрузить комп.
3. Включать комп если он выключен и 220В есть (ну вроде автозапуска при возобновлении питания, есть в некоторых платах, НО. у меня компы берут инфо о состоянии питания от бесперебойников и если батареи слабые САМИ выключаются, а встроенный в мат.плату автозапуск в этой ситуации уже не сработает, надо тискать кнопку вручную).
4. Не включать комп если он выключен и 220В нет.
При этом вся перезагрузка ведется через кнопку "Power". Т.е. полностью "выключается" питание и остается только дежурка и usb, от которых и питается контроллер. А потом опять по новой (после завершения переходных процессов) включается питание. Такой режим перезагрузки может быть полезен при "зависании" карточек в слотах, обычный резет ей уже не поможет. (правда такого уже лет 5 у меня не было, а до этого модемы внутренние дурили иногда)

Ежели кого заинтересует данная девайсина, давайте обсудим, что нужно добавить и что убрать из собаки.

Полезная штука! У меня тоже один раз "зависание" было - включил мощную нагрузку в одну розетку с сервером.
А подробнее можно? Схема, прошивка, исходники...

Тема очень интересная... Присоединяюсь к просьбе Виктора.

Схема довольно проста. (готовой нарисованной сейчас у меня нет, но сделаю на днях) За основу взят проект obdev.at и схема http://www.obdev.at/Images/vusb/circuit-zoomed.gif.
Одно из отличий - это отказ от использования "гасящих" диодов D1 D2 (что бы снизить напряжение питания). Схема питается 5В на прямую от usb, а уже на ноги 2 и 3 (usb) перед резисторами 68 Ом включены стабилитроны 3.6В (ну это уже детали, нарисую, будет понятнее).
В случае выше указанной схемы к любой свободной ноге порта (8-19) цепляем оптрон (4n33), и заводим его выход на разъем ресет на мат.плате (параллельно "штатному" от кнопки).
(в простейшем случае можно ресет подключить прямо к ноге порта или через транзистор, НО! мне попадалась мат.плата у которой "-" ресета был "отвязан" от земли, поэтому и хочу перестраховаться с оптроном, все же полная развязка).

Т.е. все подключения внутри компа (наружу ничего не торчит):
1. USB (внутренняя гребенка мат.платы)
2. reset мат.платы.

Из программ:
1. Прошивка для контроллера. Пишется на асме или С. Я обленился, и даже такие мелочи пишу на С.
2. Для компа. "самописная" утилитка работы с hid устройством (так прошивка контроллера эмулирует девайс). Читаем и пишем из-в девайс, а дальше уже прошивка по этим данным решает, чего от нее хотят.

На данном этапе уже есть готовый прототип ("конструктор"). Плюс необходимые для него прошивка и программ для основного компа.
За неделю дорисую схему, "причешу" код (стыдно такой бардак показывать). И может, если будет время, вытравлю и распаяю готовую плату девайса.

Ну и еще я в прототипе подвесил 3 канала ШИМ модуляции для регулирования частоты оборотов вентиляторов. Это не так актуально, просто хотелось универсальное устройство, да еще индикаторы работы (светодиодики), маленькую "пищалку", короче разнообразные "плюшки". Это все просто рулится из основного компа, т.е. типа утилитке говоришь "hiddata write 0x01 0x80" и на вентиляторе 1 устанавливается 50% мощности. (один сервер стоит от меня на расстоянии 2м, жужжит однако). И еще преобразователь уровней ТТЛ <-> COM порта подключен к бесперебойнику и регулярно с него дергает инфо о состоянии питания, потом утилитка с основного компа дергает эту инфу из девайса к себе.

Вот примерно такая ситуация на данный момент. Просто вопрос в том, что необходимо иметь на борту данного девайса?
Если достаточно только ресет-функции, то все можно собрать на мальеньком 8 ногом контроллере ATtiny25..45. Будет вообще крохотная платка, кот. можно прямо вместе с разъемом впихивать во внутренний usb, и к ней цеплять проводки от ресета (от кнопки), а от нее уже пускать на мат.плату. Хотя тут видел http://www.linuxfocus.org/Russian/July2002/article239.shtml без всякого контроллера на таймере NE555 плату для собаки. Но там нужен сигнал с СОМ порта, а он уже не всегда бывает в наличии или не всегда свободен.

Было бы хорошо прикрутить сюда 1-Ware датчик температуры (DS1820, DS1821)

PS Aplication note есть на сайте Dalas'a...

О! Спасибо! Забыл совсем про них , а ведь планировал когда-то сюда же воткнуть. А лучше 3 штуки - по числу каналов ШИМ.
Только вот для упрощения считывания температуры думалось сделать не все датчики на одном шлейфе (в итоге нужна процедура поиска устройств или жестко забивать в прошивку их "адреса", и потом выбор устройства и т.д.), а пойти путем "халявщика", т.е. развесить их (датчики) на разные ноги порта и тогда через "SKIP ROM" опрашивать по выбранной ноге. Из плюсов имеем точное знание на каком канале сидит нужный нам датчик. Упрощение обмена. Экономия пямяти ROM и RAM (а софтовый usb и так откусывает изрядный кусок). Из минусов имеем занятые ноги порта (у нас их в меге8 еще хватает), ну и не изящно это, опять же проводов немного больше.

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

Я именно так и сделал-бы. Один канал ШИМ - одна нога - один датчик. Плюс такой реализации - обмен будет происходить быстрее. Только надо предусмотреть возможность ручной регулировки (без датчика).
Если надо, есть подпрограмма обмена 1-Ware на ассемблере для 8051. Писал ее для ключей i-Button.

Я думаю проблем со временем выполнения быть не должно. Предлагаю такой алгоритм: каждые 20 сек. опрашиваем по датчику и регулируем ШИМ, если момент считывания совпадает с обращением по USB - здесь главное не превысить таймаут USB. Т.е. опрашивать сразу все датчики не стоит.

Ну так и сделаем. Еще один плюс этого подхода, команду на преобразование (0xCC, 0x44) можно давать одновременно на все нужные ноги, а уже считывать после задержки на измерение по одиночке.

Ну я наверное неверно ранее выразился. Именно только "ручная" регулировка и предусматривалась. Т.е. внутри контроллера нет подпрограммы изменяющей ШИМ на основе датчиков температуры. Да и вместо датчиков ds1820 можно брать "системную" инфу с sensors и hddtemp. Демон основного компа может получать инфо о температуре (по usb) и на основе совокупности ВСЕХ датчиков (в том числе и "системных") принимать решение о изменении ШИМ (могут быть достаточно сложные зависимости регулирования). Т.е. скрипт демона поправить (настроить) гораздо быстрее, чем перепрограммить контроллер (в идеале, программист вообще не обязан понимать электронику, что там подключено - соединил проводки как в инструкции и вперед, и может оперировать данными о температуре и выдавать команды на увеличение-уменьшение оборотов вентил. с помощью некоего своего скрипта/демона). Девайс ведь не автономный, а тесно связанный с сервером, вот пусть "старший брат" и пораскинет мозгом, как всеми вентил. рулить, а "младшеньки" исполнит команды.

Спасибо, если не жалко, давайте (в хозяйтсве пригодиться). Я тоже сразу хотел заоптимизировать на асме, да потом глянул на тайминги протокола, так там и на Си легко все укладывается в рамки. Может не столь оптимально, но работает.

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

В инфе о софтовом драйвере usb фигурирует цифра 50ms, т.е. это максимальная длительность какого либо непрерывного действия, т.к. в основном цикле необходимо выполнять функцию usbPool с интревалом между запусками не более 50мс.
Все считывание с одного датчика укладывается около 5мс. Так что должно хватить.
Если не хватит, думаю разбить опрос датчика для на фазы, к примеру так:
1. отправить 0xCC
2. отправить 0xBE
3. считать младший байт
4. считать старший байт
5. "сброс"

В общем скоро все попробую и узнаю. Сейчас хочу глянуть пример реализации "мини-ОС" для микроконтроллера от DiHalt (http://dihalt.blogspot.com/2010/01/avr-2.html). Ну и если будет нормально то и этот проектик на ней замутить.

ОК! Завтра выложу. (Сейчас я на работе.)


Поддерживаю, так действительно удобнее.

Все еще "хуже" чем я думал сначала. На прототипе в реальном железе опытным путем выяснилось, что при запрещенных прерываниях на время более 10мкс (МИКРОСЕКУНД) обмен по usb начинает сбоить и чем время больше тем сильнее, так уже с 20мкс - одни ошибки. 12 МГц тактовая на 10мкс всего 120 команд (маловато будет). Так что сейчас при входе в прерывание (по таймеру к примеру) сразу же разрешаю глобальные (что бы не пропустить изменение usb по INT0), со всеми вытекающими возможными "граблями" (надо будет все тщательно выверять). Но пока вроде работает. А то я "раскатал губу" - типа запрет прерываний на время обмена с 1wire, угу, как же. Тут и чихнуть не успеешь, как уже пролет мимо цели.

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

Совпадение! И я тоже на работе, да и завтра, похоже, придется потрудиться.