Pull to refresh
57
0
Алексей @DSarovsky

Пользователь

Send message
Это если нарушитель внешний, то бояться нечего. Дать подкупленному сотруднику коробочку и инструкцию, куда и как ее надо поставить — почему бы и нет.
Спасибо за наводку, бегло по описанию пробежался, если верно понял, то VirtualKD — это инструмент уровня даже не ОС, а гипервизора? То есть можно Kernel Patch Protection пытаться отладить?
Интересно, то есть MS каким-то образом проверяют, что драйвер действительно прошел тесты, а не разработчик результаты подменил?
Документация — это самая боль, да. В студенчестве достаточно плотно работал с Windows, даже с учетом того, что на официальный API документация была приличная, значительную часть информации приходилось получать или путем дизассемблирования/декомпиляции, или из открытых проектов.
Кстати, исходники ReactOS очень помогали. Хотя где-то на хабре видел комментарий одного из участников проекта о том, что им нельзя смотреть в утекшие исходники Windows, почему-то мне кажется, что настолько одинаково думать люди вряд ли умеют.

На Windows 7 даже не надо отключать проверку подписи, можно добавить сертификат в список доверенных и всё будет работать.

Спасибо за оценку и развернутый комментарий!
Да, в Win10 есть режим (среди особых вариантов загрузки F8) «Отключить требование подписи драйверов», но у меня на указанной системе работало и просто после включения TestSigning (возможно, работает только в связке с отладочным режимом, честно говоря, не проверял).
По поводу сертификации ничего не могу сказать, никогда не было задачи разработать драйвер «в продакшн», но насколько я понял, главное условие — прохождение их тестов WHQL, про железо не слышал (странное требование, разработчик же может заглушку в железку прошить и толку от нее для MS примерно 0).
Я так понимаю, что формат обмена (и драйвер, соответственно) весьма нетривиальны. Не так давно нужно было подумать над возможностью запускать сканирование из браузера, я оптимистично предположил, что WireShark-ом гляну протокол и через WebUsb его повторю, думая, что там просто команда на скан с очевидными параметрами типа размеров, разрешения и т.п., а ответ — сырая картинка.
Но все оказалось не так, даже в простое хост на сканер слал несколько пакетов в секунду, так что с форматом запроса так и не разобрался (хотя ответ с изображением был действительно простой). Думаю, что с принтерами +- то же самое.

UART, видимо, оправдывает букву 'U' в своём названии:) Через него, как оказалось, удобно также реализовать 1-wire путем включения полудуплексного режима.

Точно, не в ту сторону думал:)

На таймере тоже можно сделать, но, скорее всего, ценой оперативной памяти под счётчик тиков.

Не понял, зачем считать тики отдельно?

И вообще, честно говоря, до сих пор не до конца понимаю: зачем что-то делать на ардуино (AVR), если есть те же Stm, в которых за меньшую цену больше памяти и флеша, куча таймеров, куча EXTI и прочего? Единственный аргумент, который нашел - это наличие невероятного количества готовых библиотек.

Так с SPI в этом смысле как раз никаких проблем не будет (в отличие от i2c, например, если бы его так же применить для сторонней задачи): снять СS со всех устройств и гнать по шине все, что угодно. Или в реальных задачах надо беспрерывно менять состояние диодов?

Спрошу в ветке про тормоза: а насколько уместно вставлять большие задержки (целых 50 мс) в основном цикле (ну почти) для устранения дребезга? Может, как-то на таймере можно отсчитать?

И вообще, приветствуются ли в принципе конструкции типа delay(xx)?

Автор, может вы подскажете, а как под эти дешевые китайские модули на TLSR82XX программировать? На оф.сайте Telink есть страшный SDK, но завести хоть что-то решительно невозможно. А ведь судя по описанию, там плюшек немало, GPIO, таймеры, ШИМ, UART и прочее.

Это здорово, тем более, хабр предоставляет возможность редактирования (то есть их можно учесть прямо в этой статье).

Возможно, это отсылка к "Маленькому принцу", только тут змея съела не слона, а верблюда :)

Игнорируя, что в сети итак полно разборов этой задачи, допускаю, что начинающие C++ программисты вполне могут на Вашу статью натолкнуться и подчерпнуть, помимо, возможно, полезной (что, честно говоря, сомнительно) информации, ряд недочетов, связанных именно с языком программирования:
  • лишние включения в заголовочных файлах, которые нужны только в соответствующем *.cpp;
  • using namespace std; в заголовочном файле;
  • хардкод и магические числа (например, конструктор класса Graph);
  • возврат неконстатного указателя на данные в константном методе класса;
  • смешивание кода на языке C с кодом на C++. Если в вашем решении важно, что в одном классе используются именно массивы, а в другом подошел и std::vector, то это стоит пояснить, так как статья явно ориентирована на начинающих;
  • сложилось впечатление, что не было оценки возможного количества вершин: почему-то матрица у вас в динамической области, а путь (поле класса Path) в стеке. Если так задумано, то стоит пояснить;
  • возврат контейнеров по значению — слишком жирно и вряд ли нужно;
  • странная композиция классов, почему внутри Solution своя матрица для графа, а не поле типа Graph?
  • в конструкторе Solution присваивание просто указателя (то есть создание плоской копии). Это так задумано, что нигде деструкторов нет и поэтому работает или все-таки недоработка?
  • как это в методе Solution::Dijkstra вы создаете статический массив неизвестного размера? Раз материалы и код ориентирован на начинающих, хорошо бы, чтобы проект все же компилировался.

Даже после беглого просмотра кода (а кроме него в статье, в общем-то, ничего нет) получилось найти очевидные замечания (про стиль не стал писать, это уже более субъективно).
Еще раз хочется отметить, что наличие подобных материалов — это хорошо, потому что у тех, кто начинает изучать программирование (и в частности C++) больший выбор. Вместе с тем появляется дополнительная ответственность: не научить человека писать код неправильно.
Спасибо за разъяснения! В целом-то я понимал, что есть эти секции, в text попадает код, в RODATA константы и т.д., а также что Flash/RAM составляют единое пространство, только диапазоны адресов разные, однако только из Вашего комментария теперь сложилась картина, как в итоге все работает: код одинаково обращается как к адресам в ROM, так и к Flash, у второго разве что меньше скорость и большее количество тактов необходимо:)
Надо все-таки будет как-то более подробно изучить вопрос преобразования кода в исполняемые модули, чтобы лучше понимать работу компилятора и компоновщика.

Скорее всего, у меня понимание такого низкого уровня уже сломалось. Например, в ПК образ программы лежит на диске и в момент загрузки размещается в RAM. В контроллерах, в том числе ARM, насколько понимаю, это не так. Есть RAM и Flash, RAM для данных, Flash для кода (я так думал), или доступ к flash-памяти из программы прозрачен и не отличается от доступа к участку RAM?

А в книге Джосаттиса рекомендовано наоборот передавать по значению, если специально не нужно другое, что он связывает с ограничениями низведения типов при передаче по ссылке. (Шаблоны C++. Справочник разработчика, глава 7.)
По поводу кеша, наткнулся на статью из которой подчерпнул, что на значительной части линейки Cortex-M (в частности, и на M3), кеша нет совсем.

Information

Rating
Does not participate
Registered
Activity