Проблема не столько в написании драйверов (не сложнее, чем написать «ответную часть» в самом устройстве), сколько в возникающих организационных сложностях по их нормальному использованию в винде — 1) требуется подпись, 2) валидация в MS, 3) борьба с антивирусами, которые где-нибудь непременно посчитают ваш драйвер вирусом.
Надежность одной системы — да, ненадежности перемножаются. Но дублирование и прочее резервирование — это параллельные системы, их перемножать не нужно, т.к. они не в одной цепи. Вот понятная аналогия — у нас два глаза, каждый из которых легко повредить, но лишиться сразу двух глаз труднее, чем одного. Один выколотый глаз может быть «напоролся на ветку», но два выколотых глаза — это уже результат чьего-то злого умысла. Так и с космосом: один вырубившийся выч.модуль может быть случайностью «шальная пуля», а два вырубившихся одновременно модуля — это хуже, это где-то серьезная ошибка.
ПЗУ там есть, а перепрограммируют flash, eeprom и т.д. — тоже своего рода ПЗУ (в смысле данные не пропадают без питания), но стираемые. И они обычно намного надежнее, чем ОЗУ.
Скорее всего просто софт недотестировали. Сразу всего не предусмотришь, нужно множество испытаний «в ситуациях приближенных к боевым».
Пишу простые земные встраиваемые приложения на железе, в котором мало что может поломаться — никто их в печку не ставит, рентгеном не просвечивает, молотком не бьёт и даже на пол не роняет. Но вот сегодня при прошивке очередной партии устройств три штуки не прошли последующие испытания — не включается USB, тупо виснет при попытке включить этот модуль контроллера. И в моей программе возможность этого невключения никак не предусматривалась, и в результате вся система висит, хотя всё остальное и без USB могло бы свои функции выполнять, т.е. на 90% работать. И даже пока не знаю, как такую ситуацию обрабатывать — о том, что USB не пашет, не узнать, пока его не включишь, а при попытке включения — железо виснет, включая watchdog. Т.е. нужен «внешний наблюдатель», которого в устройстве нет — есть живой оператор, который может перевключить систему, и отнести её в ремонт, если не пашет. В космосе такие штуки не пройдут, поэтому надо все возможные ситуации заранее просчитать, промоделировать и отладить…
В Win8 можно только вообще отключить проверку всех подписей драйверов при загрузке — фича для разработчиков — (при массовом применении чревато ловлей какого-нибудь «стухнета»), а индивидуально разрешить один неподписанный драйвер вроде как нельзя.
Вот, кстати, хотел спросить у автора статьи — почему он, отказавшись от чипа rs232-usb, отказался заодно и от виртуального com-порта (CDC ACM)? Ведь он работает именно с USB, не требуя наличия rs232/uart в устройстве. И с устройством можно работать теми же ReadFile/WriteFile через COM, используя штатный виндовый драйвер usbser (и в линуксе готовый драйвер, дающий устройста ttyACM или ttyUSB), не изобретая своего драйвера. У виртуального ком.порта и другие плюсы — например, с ним можно работать через консоль (HyperTerminal, TeraTerm, PuTTY...), а не только самодельной программой, а если на нем эмулировать модем и PPP (как сделано в iron.snop.ru/), то и по «виртуальной сети».
И еще у самодельных драйверов, кроме лишних затрат времени, есть еще один минус — последние версии винды не любят неподписанные драйверы…
В общем, хотелось бы узнать мотивацию, подвигшую на подвиги с самодельным драйвером. Я знаю только один недостаток виртуального com-порта — ограничения скорости в штатном usbser в 921Кбит (хотя может это мне так кажется, а на деле и это как-нибудь обходится?).
В брелках слишком уж мелко всё внутри, как в мобильниках, не подключиться. Можно плату с аккумулятором засунуть вот в такой относительно карманный корпус: iron.snop.ru/ (этот толстый за счет Ethernet'ного magjack'а, но такие же корпуса бывают более тонкие).
Не врублюсь, а чем лучше использование CloudFront вместо прямой раздачи из S3? (где тоже можно через CNAME через свой домен раздавать корзину). У S3 ограничения по масштабируемости что ли?
Для своих форумов на PhpBB делал такую защиту от роботов: дописал в страничку js-скрипт, который перед отправкой формы добавляет в неё еще одно поле, а на сервере соответственно проверку его наличия, т.е. по паре строк кода в двух файлах. И всё, боты отвалились. За пару лет ни одного (что странно — я ожидал, что хотя бы часть ботов умеет выполнять скрипты каким-нибудь встроенным IE). Позже перевел форум на другой движок, поэтому не могу сказать, насколько действенен этот метод сейчас; на новом сайте тоже без капчи, формы отправляются ajax'ом, и тоже ни одного бота по сей день — почти три года прошло с перехода. А до добавления этих js-штук спамеры просто замучили модераторов PhpBB-форумов.
У Гугла есть еще один нестандартный ускоритель сайтов — они подкрутили TCP на своих серверах: отключили 'slow start' (или как он там называется) — постепенный разгон TCP, который для борьбы с congestion используется. Т.е. сходу «флудит», и это действительно быстрее ;) Только вот за счет других сетевых приложений и чужих сайтов…
При записи данных в порт может следом идти сигнал «данные готовы», который и является «тактом» для того ядра, кому эти данные предназначены. Приемник выполняет действие и «сдвигает» такт следующему (или самому себе на следующее действие). Т.е. локальное тактирование («триггерирование» :), конечно, есть, но глобального распределения clock не требуется. Соответственно ядро, у которого следующего такта не оказалось, спит до следующих входных данных (в межьядерном порту или на внешней ноге). Как-то так.
Нет, особый склад ума в сравнении с традиционным программированием. А синтаксически он как раз ближе к естественным языкам, чем другие языки программирования. Никаких там лишних скобок и т.п. И подлежащие-сказуемые идут в традиционном порядке, а не как у Йоды.
Скорее всего просто софт недотестировали. Сразу всего не предусмотришь, нужно множество испытаний «в ситуациях приближенных к боевым».
Пишу простые земные встраиваемые приложения на железе, в котором мало что может поломаться — никто их в печку не ставит, рентгеном не просвечивает, молотком не бьёт и даже на пол не роняет. Но вот сегодня при прошивке очередной партии устройств три штуки не прошли последующие испытания — не включается USB, тупо виснет при попытке включить этот модуль контроллера. И в моей программе возможность этого невключения никак не предусматривалась, и в результате вся система висит, хотя всё остальное и без USB могло бы свои функции выполнять, т.е. на 90% работать. И даже пока не знаю, как такую ситуацию обрабатывать — о том, что USB не пашет, не узнать, пока его не включишь, а при попытке включения — железо виснет, включая watchdog. Т.е. нужен «внешний наблюдатель», которого в устройстве нет — есть живой оператор, который может перевключить систему, и отнести её в ремонт, если не пашет. В космосе такие штуки не пройдут, поэтому надо все возможные ситуации заранее просчитать, промоделировать и отладить…
И еще у самодельных драйверов, кроме лишних затрат времени, есть еще один минус — последние версии винды не любят неподписанные драйверы…
В общем, хотелось бы узнать мотивацию, подвигшую на подвиги с самодельным драйвером. Я знаю только один недостаток виртуального com-порта — ограничения скорости в штатном usbser в 921Кбит (хотя может это мне так кажется, а на деле и это как-нибудь обходится?).
Что имеется в виду? Заглянул в HTTPS-лог своего сервера, реферер на месте.