Интересный, хороший проект. И в перспективе можно добавлять туда новые функции, ресурсов микроконтроллера более чем достаточно.
Меня только очень оттолкнула эта броская картинка "Гаечки" на заднем плане. Как оттолкнула бы любая другая броская картинка человека, котика или другого объекта, не имеющего отношения к функционалу прибора. Даже если бы там красивое фото какой-нибудь печатной платы было изображено - не нужно это. Такие картинки - как рекламные баннеры, привлекают к себе внимание и заставляют напрягать мозг для того, чтобы не пялиться на них, а использовать прибор по прямому назначению.
К сожалению, ввод новых стандартов C и C++ не решает проблем, стоящих перед программистами на практике.
На практике, к примеру, у нас на фирме пишется портируемый код на Си. Который предназначен для исполнения на 32-битных микроконтроллерах (несколько архитектур, не только ARM); на Линуксе (в режиме ядра и пользователя) и на Windows (32- и 64-бит).
Ладно, я давно отказался от идеи использовать "новые" стандарты Си, такие как C17 или C11. Остановился на C99 - вроде бы, прошло уже достаточно лет с момента его выпуска, чтобы этот стандарт поддерживался всеми компиляторами для наших целевых платформ. Так и было какое-то время. arm-gcc, Native GCC, MinGW-GCC компилировали код без проблем.
Но недавно возникло два крупных разочарования. 1) MSVC. Нам понадобилось использовать этот компилятор в одном из проектов. А он не поддерживает C99! Нет поддержки комплексных чисел (была важна для проекта). 2) Режим ядра в Линуксе - там обязательно использование C89 для версии ядра 4.x.
В итоге даже 24-летней давности C99 оказалось невозможным использовать.
Сейчас введут какой-нибудь новый C++24, C24 - но боюсь, что и через 20 лет на нем не будет возможно писать реально портируемый код, который поддерживается основной массой компиляторов.
Люди ценят эмпатию не за форму (что кто-то рядом высказывает слова сопереживания или ругается). А за то, что рядом живой человек находится в той же лодке; страдает так же, как ты, и тратит на это драгоценное и невосполнимое время своей жизни.
Сколько было недавно этих озарений на тему: "А давайте спросим у пользователя, понравилось ли ему! А давайте спросим его мнение о нашем продукте! А давайте скажем ему, что его мнение очень важно для нас!" Да, поначалу люди на это велись. Пока не обнаружили, что интерес их мнением - показной. Что на самом деле никто их мнением не интересуется. И оставлять отзывы и участвовать во всевозможных опросах - напрасная трата времени в лучшем случае. Фраза: "Ваше мнение очень важно для нас" и вовсе стала издевательской.
Так и здесь. Как только я пойму, что "сопереживает" и "грустит" со мной не живой человек, сидящий рядом (а в этом нетрудно убедиться, осмотревшись вокруг!), а скрипт, совершенно обстоятельствами не затронутый; время своей жизни не тратящий, а просто желающий ко мне подлизаться - то кроме отвращения к такому "помощнику", других чувств к нему испытывать не буду.
В самом деле, что мы испытываем к окружающим, которые кривят душой в своих изображаемых эмоциях? Которые нам фальшиво сопереживают или фальшиво радуются вместе с нами?
Я читал в нескольких книгах об основах рынка, что продавец и покупатель, встречаясь, каждый имеет свою "последнюю цену". Продавец - минимальную цену, за которую он готов продать; покупатель - максимальную, за которую он готов купить.
Далее стороны торгуются, т.е. блефуют. Однако (в книгах это тоже написано), информация дает преимущество. Если продавец откуда-то точно знает "последнюю" цену покупателя - то он может вести себя в торгах непреклонно, так, что сделка состоится именно по этой цене. И наоборот, покупатель, зная предельную цену продавца, может проявить твердость и сбить цену до предельно низкой.
Бизнес всегда стремился получать больше информации о клиентах. Как думаете, для чего? Чтобы лучше удовлетворить наши желания? Или чтобы проводить сделки по предельно возможным (максимально невыгодным для нас) ценам?
Цель предпринимательства - извлечение прибыли, не больше и не меньше. Интересы клиента и бизнеса - противоположны. И в ситуации, когда информация дает преимущества - остается только пожать плечами, что мы, зная все это, преподносили бизнесу информацию о нас на блюдечке с голубой каемочкой. "Мне нечего скрывать, я законопослушный гражданин", - говорил каждый.
Floppy Disk Analyzer, Teledisk и т.п. досовые утилиты были все ограничены возможностями чипа контроллера дисковода i8272, повсеместно применявшемся на PC (сначала отдельно, а потом в составе чипа южного моста). Но компьютеры Amiga использовали другой контроллер дисковода, более гибкий в отношении формата дискет. Там можно было создавать такие форматы и защиты, которые никаким софтом на PC с контроллером i8272 уже ни прочитаешь, ни скопируешь.
В современных реалиях возможности значительно расширились. С помощью FPGA можно реализовать свой контроллер дисковода с полным контролем низкоуровнего кодирования данных. Скажем, заменив формат MFM на какой-нибудь RLL или 8b/10b, можно было бы в полтора-два раза повысить полезную ёмкость дискет. Для восстановления нечитаемых дискет можно оцифровать "самый низкоуровневый" сигнал данных считывания дискеты с высоким разрешением во времени. И потом декодировать данные; обнаруживать и устранять повреждения информации в оффлайне, с помощью методов цифровой обработки сигналов.
Но можно пойти и дальше. На разъеме дисковода данные считывания доступны только в цифровом виде. Хакнув электронику дисковода, можно получить доступ к аналоговому выходу усилителя воспроизведения магнитной головки и оцифровать этот сигнал с высоким разрешением во времени. Возможности оффлайн-анализа, декодирования и восстановления ошибок при этом повышаются многократно. Мои знакомые энтузиасты реализовали этот подход с помощью модуля SDR (Software-Defined-Radio) и оцифровали сигналы воспроизведения на частоте 4МГц. Я смотрел и прослушивал (на пониженной скорости) эти WAV-файлы. Просто фантастика. Звучит, как запись с магнитной ленты!
Химические реакции, возможно, и происходят. Но характерная энергия химической связи - единицы электронвольт, а характерная энергия теплового движения ионов в ядре звезды - десятки килоэлектронвольт. При первом же столкновении образовавшейся молекулы с какой-нибудь другой частицей плазмы химическая связь будет разорвана, будто ее и не было.
Я вообще для компиляции proto-файлов использую исключительно nanopb. Как в микроконтроллерных проектах, так и на "больших" компьютерах. По мне, оригинальный компилятор в C++ генерирует слишком тяжелый код с кучей ненужного багажа.
Чем более зеркальная поверхность — тем меньше она излучает собственного теплового излучения. Высокой погрешности можно ожидать только при измерении температуры объектов с зеркальными поверхностями сравнимого качества.
В химических лабораториях еще используются т.н. «азотные ловушки» — вредные газы проходят около поверхностей, охлаждаемых жидким азотом. При этом всякая органика и прочее непотребство конденсируется.
А это потому, что в нашем мозгу имеется встроенный «раскрашиватель». Хотя результаты его работы и не воспринимаются так, как будто их видят глаза, но на эмоции явно влияют.
А тут, на раскрашенной с помощью нейронки фотографии, внутренний «раскрашиватель» отключается, так как кажется, что его работа не нужна. Отсюда и худшее эмоциональное восприятие.
Здесь я вижу сходство с системами подавления шума в аудиозаписях. Большинство «отреставрированных» записей я бы лучше слушал с шумом, который там изначально был. Ведь в ходе «реставрации» теряются слабые звуки заднего плана, придававшие музыке особый колорит.
У нас была где-то в 1996г лабораторка по голограммам. Записывали как плоские, которые можно было смотреть только в лазерном свете, так и объёмные, методом Денисюка. Потом еще рассчитывали параметры, вроде глубины, на которую можно было рассматривать изображение. И тогда еще все студенты мечтали о голографическом кино, а преподы их обламывали.
С видимым светом всё понятно — тут все зависит от нанотехнологий. Но поскольку само явление не зависит от среды и природы волн, а присуще всем волновым явлениям вообще — то возможны интересные применения звуковых, радио- или дальних инфракрасных движущихся голограмм.
Жизнь не всегда настолько добра к нам, чтобы была возможность использовать любой из перечисленных методов отладки. И тогда выход может быть найден только за счет изобретательности разработчика. Приведу пару примеров из моей практики, какие приходилось применять решения.
1) Подмена выходных сигналов отладочной информацией. В той ситуации было совершенно невозможно использовать другие методы отладки. Ни эмулятора, ни точек останова, ни debug printf, ни GPIO/LED. Вместе с тем, прошивка формировала некие выходные сигналы. Временно заменив эти сигналы отладочной информацией, удалось вывести эту информацию наружу и по ней обнаружить и исправить ошибки в программе.
2) Создание эмулятора цифрового датчика. Был создан эмулятор, поддерживающий протокол датчика, но вместо измерения физической величины, он гнал на выход тест-сигналы. Специальным образом подобранные сигналы, рассчитанные на уязвимость алгоритмов их обработки к накоплению ошибок округления, позволили надежно воспроизвести редко возникающий на практике сбой.
3) Опрос регистров причины сброса и вывод их на консоль. Применялось для отладки редко возникающего краха прошивки, приводящего к перезапуску микроконтроллера. Сбивалось раз в сутки или двое, могло без перебоев работать часами. Вывод детальной информации о сбое позволил его несколько локализовать, с последующим выводом более подробной информации и, в конце концов, окончательно отследить и исправить ошибку.
4) Создание «пыточной» программы установления сетевых соединений. Изредка затыкался сетевой стек. Ошибка была практически невоспроизводима «на заказ». С помощью программы, постоянно устанавливающей и рвущей соединения, удалось воспроизвести ошибку за полчаса-час «пыток». Дальше дело техники — внутрисхемный отладчик, останов программы, изучение ее состояния — и вот ошибка найдена и исправлена, повторные несколько суток «пыток» показали, что результат достигнут.
Да, что еще важно… Никогда не отмахиваться от сообщений коллег или клиентов о сбоях. Оно обычно само не проходит, не рассасывается — как беременность.
Тут вопрос, где они будут запускать эти тесты. Правила сертификации за последние годы несколько раз менялись в сторону ужесточения. Многие веб-страницы с информацией по теме (в том числе на сайте Microsoft) устарели.
Если я правильно понял результаты своего последнего поиска — то тесты должны исполняться на компьютере Microsoft. А поскольку драйвер не работает без железа — то в Microsoft необходимо выслать по почте железо, с которым будет работать драйвер. Может быть, вместе с компьютером. Там в тексте были слова «Submit your hardware». Может, их можно толковать как-то иначе, но бесплатно разъяснять сотрудники Microsoft отказались.
Мы бы и не против выслать в Microsoft железо. Но связанные с этим манипуляции со стороны Microsoft (вставить карточку в компьютер; включить; рисковать поломкой компьютера) требуют довольно высокой квалификации персонала и могут стоить немалых денег. Знать бы, какого порядка сумма. У нас просто решалась судьба проекта: сколько надо в него вложить денег для того, чтобы были дрова под новые версии Windows; и окупились ли бы эти вложения.
По-моему, людей отпугивают не столько сложности разработки драйверов, как сложности получения на них сертификации от Microsoft.
Мне пришлось однажды по работе заниматься драйвером. Не с нуля разработать, а портировать под 64 бит. Это оказалось достаточно легко, но потом… Просто режим TestSigning работал в Windows 7, но в Windows 10 всё гораздо сложнее. Необходимо сначала особым образом вызвать перезагрузку системы, тогда при старте появится специальное меню. И там, в глубине, есть один пункт, который позволяет снять требование сертификации загружаемых драйверов. На один раз. При следующей перезагрузке процедуру необходимо повторить заново.
В конце концов всё заработало, и мы попытались связаться с Microsoft для выяснения стоимости и условий сертификации. Даже дозвониться до службы поддержки проблема — телефоны открыто не публикуются, а веб-интерфейс стремится перенаправить человека на форумы и т.д., где цены не публикуются, а условия указаны расплывчато. Ожидаемо, сотрудники телефонной поддержки даже не знали, что это такое — сертификация драйверов. После открытия бесчисленного количества тикетов и перенаправлений к другим сотрудникам в другие офисы и другие страны, наконец-то, удалось поговорить с кем-то, кто хоть чуть-чуть в курсе дела. Они обещали помочь, но… Перезвонили и сообщили, что «из соображений безопасности» до того, как наша фирма получит EV сертификат (который стоит около 2000$ и сам по себе не связан с Microsoft или сертификацией драйверов) с нами вообще не будут разговаривать, в том числе не назовут цену за получение ЭЦП драйвера от Microsoft.
Так и похоронили этот вопрос.
А у вас есть какая-либо информация о том, как подписать драйвер в Microsoft? Сколько это стоит, что для этого нужно? Правда ли, что нужно направлять железо, к которому разрабатывается драйвер, на тестирование в Microsoft?
В Windows есть structured exception handling, в юниксы — не завезли.
Создать exception другому потоку не так просто. В юниксах есть сигналы — один поток может послать другому что-то типа аппаратного прерывания. В рамках потока-«жертвы» исполнение кода приостанавливается, поток исполняет процедуру обработки прерывания и возвращается к прерванному коду (если обработчик этому не помешает). Насчет межпоточных сигналов в юниксе не знаю, но межпроцессовые сигналы точно прерывают код.
А вот в Windows этого нет. В User-mode нет никаких средств, с помощью которых один поток может прервать исполнение другого в произвольном месте. Можно прервать код с помощью Kernel-mode APC, но этот механизм доступен только из ядра и не документирован официально. User-mode APC код не прерывают (см. доку на QueueUserAPC). Они срабатывают только когда поток-жертва войдет в специальный режим ожидания.
Кстати, интересно, как вы себе представляете всякие lock-free алгоритмы, адаптированные к тому, что в них в любой момент может произойти исключение? Не может ли от этого существенно снизиться производительность?
Если код той сложной обработки рассчитан на это, то он будет аккуратно производить все свёртки
Отладка численных методов, шифрования, компрессии и т.д. — чрезвычайно сложный процесс. И чтобы начать перепахивать код таких алгоритмов — должны быть очень веские основания и очень квалифицированные разработчики.
Я бы все же предпочел иметь систему, где malloc возвращает NULL в случае нехватки памяти. Пусть даже придется проверять результат — это значительно проще, чем переделать все алгоритмы так, как вы предлагаете. Пусть даже программу, которой не хватило памяти, прибивают сразу. Но не та система, что есть сейчас — когда вместо одной программы может быть прибита другая, и не в момент malloc, а в произвольном месте.
Предлагаемое вами решение может, конечно, снизить остроту проблем, создаваемых принципом Overcommit. Но, боюсь, оно не решит их в корне.
Если в старых системах, где malloc() при исчерпании памяти возвращает NULL, программа могла продолжить работу, хотя бы воздержавшись от дальнейшего выделения памяти — то в современных системах этого недостаточно. Надо не только прекратить запрашивать память, но активно и срочно освобождать память, выделенную ранее.
Допустим, у вас многопоточное приложение. Один поток получает уведомление, что в системе заканчивается память. Что он может с этим сделать? Самому потоку, ждущему уведомлений, обычно память не нужна, и освобождать ему нечего. Нужно послать сигнал другим потокам, которые используют в данный момент память и могут ее освободить. Если потоки заняты в данный момент вычислениями, архивацией, шифрованием и т.д. — то во все эти алгоритмы необходимо вставить опрос флага, сигнализирующего о необходимости срочно прекратить работу.
Если опрашивать этот флаг редко — то за время между опросами поток может потребить больше памяти, чем имеется в «сейфе на 1000 талеров». Если опрашивать часто — то придется глубоко лезть в сложные алгоритмы расчетов, архивации, шифрования, видеокодеки. Возможно, придется лезть в сторонние библиотеки. Придется разбивать большие операции чтения файлов на маленькие части, чтобы проверять между ними флаг. Риски и трудозатраты, связанные с такой доработкой алгоритмов и библиотек, представляются мне гигантскими.
И самое печальное, что все эти ухищрения нужны только для того, чтобы снизить (но не устранить) последствия порочного подхода, принятого в конкретной операционной системе.
В технике, гарантия обычно даётся на дефекты, допущенные в процессе производства, которые повлекли за собой преждевременный выход изделия из строя. Гарантия не распространяется на нормальный износ изделия в процессе эксплуатации. Как в стоматологии — не знаю, но, наверное, что-то подобное.
Отличный проект, давно ждал следующего поколения автокомпозиторов! Первым успешным, который я видел, была программа AlgoMusic для компьютеров Amiga. Также интерес представляет одна из новых программ, cgMusic. Все они работают на «классическом» принципе — музыкальная теория + случайные числа. cgMusic интересна тем, что может генерировать в нескольких жанрах на выбор (рок, поп, марш и т.д.). Algomusic генерирует только техно, но некоторые его «произведения» мне так понравились, что попали в фонотеку.
Ваша система с ранжировщиком напоминает архитектуру GAN. Интересно, а можно ли здесь прикрутить GAN в чистом виде? Например, одна сеть создает музыку, а второй на вход приходит музыка, и она пытается классифицировать, человек ее сочинил или машина. И обе сети развиваются в гонке друг против друга. Одна пытается обмануть другую, а другая пытается найти более тонкие признаки, чтобы распознать обман.
На принципе GAN построены сетки, генерирующие фотографии людей с пугающе высокой правдоподобностью, что не каждый человек не всегда поймет, что перед ним «мираж».
Интересный, хороший проект. И в перспективе можно добавлять туда новые функции, ресурсов микроконтроллера более чем достаточно.
Меня только очень оттолкнула эта броская картинка "Гаечки" на заднем плане. Как оттолкнула бы любая другая броская картинка человека, котика или другого объекта, не имеющего отношения к функционалу прибора. Даже если бы там красивое фото какой-нибудь печатной платы было изображено - не нужно это. Такие картинки - как рекламные баннеры, привлекают к себе внимание и заставляют напрягать мозг для того, чтобы не пялиться на них, а использовать прибор по прямому назначению.
К сожалению, ввод новых стандартов C и C++ не решает проблем, стоящих перед программистами на практике.
На практике, к примеру, у нас на фирме пишется портируемый код на Си. Который предназначен для исполнения на 32-битных микроконтроллерах (несколько архитектур, не только ARM); на Линуксе (в режиме ядра и пользователя) и на Windows (32- и 64-бит).
Ладно, я давно отказался от идеи использовать "новые" стандарты Си, такие как C17 или C11. Остановился на C99 - вроде бы, прошло уже достаточно лет с момента его выпуска, чтобы этот стандарт поддерживался всеми компиляторами для наших целевых платформ. Так и было какое-то время. arm-gcc, Native GCC, MinGW-GCC компилировали код без проблем.
Но недавно возникло два крупных разочарования. 1) MSVC. Нам понадобилось использовать этот компилятор в одном из проектов. А он не поддерживает C99! Нет поддержки комплексных чисел (была важна для проекта). 2) Режим ядра в Линуксе - там обязательно использование C89 для версии ядра 4.x.
В итоге даже 24-летней давности C99 оказалось невозможным использовать.
Сейчас введут какой-нибудь новый C++24, C24 - но боюсь, что и через 20 лет на нем не будет возможно писать реально портируемый код, который поддерживается основной массой компиляторов.
Очередная идея обмануть людей красивой формой.
Люди ценят эмпатию не за форму (что кто-то рядом высказывает слова сопереживания или ругается). А за то, что рядом живой человек находится в той же лодке; страдает так же, как ты, и тратит на это драгоценное и невосполнимое время своей жизни.
Сколько было недавно этих озарений на тему: "А давайте спросим у пользователя, понравилось ли ему! А давайте спросим его мнение о нашем продукте! А давайте скажем ему, что его мнение очень важно для нас!" Да, поначалу люди на это велись. Пока не обнаружили, что интерес их мнением - показной. Что на самом деле никто их мнением не интересуется. И оставлять отзывы и участвовать во всевозможных опросах - напрасная трата времени в лучшем случае. Фраза: "Ваше мнение очень важно для нас" и вовсе стала издевательской.
Так и здесь. Как только я пойму, что "сопереживает" и "грустит" со мной не живой человек, сидящий рядом (а в этом нетрудно убедиться, осмотревшись вокруг!), а скрипт, совершенно обстоятельствами не затронутый; время своей жизни не тратящий, а просто желающий ко мне подлизаться - то кроме отвращения к такому "помощнику", других чувств к нему испытывать не буду.
В самом деле, что мы испытываем к окружающим, которые кривят душой в своих изображаемых эмоциях? Которые нам фальшиво сопереживают или фальшиво радуются вместе с нами?
Я читал в нескольких книгах об основах рынка, что продавец и покупатель, встречаясь, каждый имеет свою "последнюю цену". Продавец - минимальную цену, за которую он готов продать; покупатель - максимальную, за которую он готов купить.
Далее стороны торгуются, т.е. блефуют. Однако (в книгах это тоже написано), информация дает преимущество. Если продавец откуда-то точно знает "последнюю" цену покупателя - то он может вести себя в торгах непреклонно, так, что сделка состоится именно по этой цене. И наоборот, покупатель, зная предельную цену продавца, может проявить твердость и сбить цену до предельно низкой.
Бизнес всегда стремился получать больше информации о клиентах. Как думаете, для чего? Чтобы лучше удовлетворить наши желания? Или чтобы проводить сделки по предельно возможным (максимально невыгодным для нас) ценам?
Цель предпринимательства - извлечение прибыли, не больше и не меньше. Интересы клиента и бизнеса - противоположны. И в ситуации, когда информация дает преимущества - остается только пожать плечами, что мы, зная все это, преподносили бизнесу информацию о нас на блюдечке с голубой каемочкой. "Мне нечего скрывать, я законопослушный гражданин", - говорил каждый.
Floppy Disk Analyzer, Teledisk и т.п. досовые утилиты были все ограничены возможностями чипа контроллера дисковода i8272, повсеместно применявшемся на PC (сначала отдельно, а потом в составе чипа южного моста). Но компьютеры Amiga использовали другой контроллер дисковода, более гибкий в отношении формата дискет. Там можно было создавать такие форматы и защиты, которые никаким софтом на PC с контроллером i8272 уже ни прочитаешь, ни скопируешь.
В современных реалиях возможности значительно расширились. С помощью FPGA можно реализовать свой контроллер дисковода с полным контролем низкоуровнего кодирования данных. Скажем, заменив формат MFM на какой-нибудь RLL или 8b/10b, можно было бы в полтора-два раза повысить полезную ёмкость дискет. Для восстановления нечитаемых дискет можно оцифровать "самый низкоуровневый" сигнал данных считывания дискеты с высоким разрешением во времени. И потом декодировать данные; обнаруживать и устранять повреждения информации в оффлайне, с помощью методов цифровой обработки сигналов.
Но можно пойти и дальше. На разъеме дисковода данные считывания доступны только в цифровом виде. Хакнув электронику дисковода, можно получить доступ к аналоговому выходу усилителя воспроизведения магнитной головки и оцифровать этот сигнал с высоким разрешением во времени. Возможности оффлайн-анализа, декодирования и восстановления ошибок при этом повышаются многократно. Мои знакомые энтузиасты реализовали этот подход с помощью модуля SDR (Software-Defined-Radio) и оцифровали сигналы воспроизведения на частоте 4МГц. Я смотрел и прослушивал (на пониженной скорости) эти WAV-файлы. Просто фантастика. Звучит, как запись с магнитной ленты!
Химические реакции, возможно, и происходят. Но характерная энергия химической связи - единицы электронвольт, а характерная энергия теплового движения ионов в ядре звезды - десятки килоэлектронвольт. При первом же столкновении образовавшейся молекулы с какой-нибудь другой частицей плазмы химическая связь будет разорвана, будто ее и не было.
Я вообще для компиляции proto-файлов использую исключительно nanopb. Как в микроконтроллерных проектах, так и на "больших" компьютерах. По мне, оригинальный компилятор в C++ генерирует слишком тяжелый код с кучей ненужного багажа.
А тут, на раскрашенной с помощью нейронки фотографии, внутренний «раскрашиватель» отключается, так как кажется, что его работа не нужна. Отсюда и худшее эмоциональное восприятие.
Здесь я вижу сходство с системами подавления шума в аудиозаписях. Большинство «отреставрированных» записей я бы лучше слушал с шумом, который там изначально был. Ведь в ходе «реставрации» теряются слабые звуки заднего плана, придававшие музыке особый колорит.
С видимым светом всё понятно — тут все зависит от нанотехнологий. Но поскольку само явление не зависит от среды и природы волн, а присуще всем волновым явлениям вообще — то возможны интересные применения звуковых, радио- или дальних инфракрасных движущихся голограмм.
1) Подмена выходных сигналов отладочной информацией. В той ситуации было совершенно невозможно использовать другие методы отладки. Ни эмулятора, ни точек останова, ни debug printf, ни GPIO/LED. Вместе с тем, прошивка формировала некие выходные сигналы. Временно заменив эти сигналы отладочной информацией, удалось вывести эту информацию наружу и по ней обнаружить и исправить ошибки в программе.
2) Создание эмулятора цифрового датчика. Был создан эмулятор, поддерживающий протокол датчика, но вместо измерения физической величины, он гнал на выход тест-сигналы. Специальным образом подобранные сигналы, рассчитанные на уязвимость алгоритмов их обработки к накоплению ошибок округления, позволили надежно воспроизвести редко возникающий на практике сбой.
3) Опрос регистров причины сброса и вывод их на консоль. Применялось для отладки редко возникающего краха прошивки, приводящего к перезапуску микроконтроллера. Сбивалось раз в сутки или двое, могло без перебоев работать часами. Вывод детальной информации о сбое позволил его несколько локализовать, с последующим выводом более подробной информации и, в конце концов, окончательно отследить и исправить ошибку.
4) Создание «пыточной» программы установления сетевых соединений. Изредка затыкался сетевой стек. Ошибка была практически невоспроизводима «на заказ». С помощью программы, постоянно устанавливающей и рвущей соединения, удалось воспроизвести ошибку за полчаса-час «пыток». Дальше дело техники — внутрисхемный отладчик, останов программы, изучение ее состояния — и вот ошибка найдена и исправлена, повторные несколько суток «пыток» показали, что результат достигнут.
Да, что еще важно… Никогда не отмахиваться от сообщений коллег или клиентов о сбоях. Оно обычно само не проходит, не рассасывается — как беременность.
Тут вопрос, где они будут запускать эти тесты. Правила сертификации за последние годы несколько раз менялись в сторону ужесточения. Многие веб-страницы с информацией по теме (в том числе на сайте Microsoft) устарели.
Если я правильно понял результаты своего последнего поиска — то тесты должны исполняться на компьютере Microsoft. А поскольку драйвер не работает без железа — то в Microsoft необходимо выслать по почте железо, с которым будет работать драйвер. Может быть, вместе с компьютером. Там в тексте были слова «Submit your hardware». Может, их можно толковать как-то иначе, но бесплатно разъяснять сотрудники Microsoft отказались.
Мы бы и не против выслать в Microsoft железо. Но связанные с этим манипуляции со стороны Microsoft (вставить карточку в компьютер; включить; рисковать поломкой компьютера) требуют довольно высокой квалификации персонала и могут стоить немалых денег. Знать бы, какого порядка сумма. У нас просто решалась судьба проекта: сколько надо в него вложить денег для того, чтобы были дрова под новые версии Windows; и окупились ли бы эти вложения.
По-моему, людей отпугивают не столько сложности разработки драйверов, как сложности получения на них сертификации от Microsoft.
Мне пришлось однажды по работе заниматься драйвером. Не с нуля разработать, а портировать под 64 бит. Это оказалось достаточно легко, но потом… Просто режим TestSigning работал в Windows 7, но в Windows 10 всё гораздо сложнее. Необходимо сначала особым образом вызвать перезагрузку системы, тогда при старте появится специальное меню. И там, в глубине, есть один пункт, который позволяет снять требование сертификации загружаемых драйверов. На один раз. При следующей перезагрузке процедуру необходимо повторить заново.
В конце концов всё заработало, и мы попытались связаться с Microsoft для выяснения стоимости и условий сертификации. Даже дозвониться до службы поддержки проблема — телефоны открыто не публикуются, а веб-интерфейс стремится перенаправить человека на форумы и т.д., где цены не публикуются, а условия указаны расплывчато. Ожидаемо, сотрудники телефонной поддержки даже не знали, что это такое — сертификация драйверов. После открытия бесчисленного количества тикетов и перенаправлений к другим сотрудникам в другие офисы и другие страны, наконец-то, удалось поговорить с кем-то, кто хоть чуть-чуть в курсе дела. Они обещали помочь, но… Перезвонили и сообщили, что «из соображений безопасности» до того, как наша фирма получит EV сертификат (который стоит около 2000$ и сам по себе не связан с Microsoft или сертификацией драйверов) с нами вообще не будут разговаривать, в том числе не назовут цену за получение ЭЦП драйвера от Microsoft.
Так и похоронили этот вопрос.
А у вас есть какая-либо информация о том, как подписать драйвер в Microsoft? Сколько это стоит, что для этого нужно? Правда ли, что нужно направлять железо, к которому разрабатывается драйвер, на тестирование в Microsoft?
Создать exception другому потоку не так просто. В юниксах есть сигналы — один поток может послать другому что-то типа аппаратного прерывания. В рамках потока-«жертвы» исполнение кода приостанавливается, поток исполняет процедуру обработки прерывания и возвращается к прерванному коду (если обработчик этому не помешает). Насчет межпоточных сигналов в юниксе не знаю, но межпроцессовые сигналы точно прерывают код.
А вот в Windows этого нет. В User-mode нет никаких средств, с помощью которых один поток может прервать исполнение другого в произвольном месте. Можно прервать код с помощью Kernel-mode APC, но этот механизм доступен только из ядра и не документирован официально. User-mode APC код не прерывают (см. доку на QueueUserAPC). Они срабатывают только когда поток-жертва войдет в специальный режим ожидания.
Кстати, интересно, как вы себе представляете всякие lock-free алгоритмы, адаптированные к тому, что в них в любой момент может произойти исключение? Не может ли от этого существенно снизиться производительность?
Отладка численных методов, шифрования, компрессии и т.д. — чрезвычайно сложный процесс. И чтобы начать перепахивать код таких алгоритмов — должны быть очень веские основания и очень квалифицированные разработчики.
Я бы все же предпочел иметь систему, где malloc возвращает NULL в случае нехватки памяти. Пусть даже придется проверять результат — это значительно проще, чем переделать все алгоритмы так, как вы предлагаете. Пусть даже программу, которой не хватило памяти, прибивают сразу. Но не та система, что есть сейчас — когда вместо одной программы может быть прибита другая, и не в момент malloc, а в произвольном месте.
Вот тут не понял. Кто чем соблазнился?
Если в старых системах, где malloc() при исчерпании памяти возвращает NULL, программа могла продолжить работу, хотя бы воздержавшись от дальнейшего выделения памяти — то в современных системах этого недостаточно. Надо не только прекратить запрашивать память, но активно и срочно освобождать память, выделенную ранее.
Допустим, у вас многопоточное приложение. Один поток получает уведомление, что в системе заканчивается память. Что он может с этим сделать? Самому потоку, ждущему уведомлений, обычно память не нужна, и освобождать ему нечего. Нужно послать сигнал другим потокам, которые используют в данный момент память и могут ее освободить. Если потоки заняты в данный момент вычислениями, архивацией, шифрованием и т.д. — то во все эти алгоритмы необходимо вставить опрос флага, сигнализирующего о необходимости срочно прекратить работу.
Если опрашивать этот флаг редко — то за время между опросами поток может потребить больше памяти, чем имеется в «сейфе на 1000 талеров». Если опрашивать часто — то придется глубоко лезть в сложные алгоритмы расчетов, архивации, шифрования, видеокодеки. Возможно, придется лезть в сторонние библиотеки. Придется разбивать большие операции чтения файлов на маленькие части, чтобы проверять между ними флаг. Риски и трудозатраты, связанные с такой доработкой алгоритмов и библиотек, представляются мне гигантскими.
И самое печальное, что все эти ухищрения нужны только для того, чтобы снизить (но не устранить) последствия порочного подхода, принятого в конкретной операционной системе.
Ваша система с ранжировщиком напоминает архитектуру GAN. Интересно, а можно ли здесь прикрутить GAN в чистом виде? Например, одна сеть создает музыку, а второй на вход приходит музыка, и она пытается классифицировать, человек ее сочинил или машина. И обе сети развиваются в гонке друг против друга. Одна пытается обмануть другую, а другая пытается найти более тонкие признаки, чтобы распознать обман.
На принципе GAN построены сетки, генерирующие фотографии людей с пугающе высокой правдоподобностью, что не каждый человек не всегда поймет, что перед ним «мираж».