Пользуюсь промужеточным вариантом: принтер с картриджами, но прозрачными и пополняемыми, которые ещё и умеют сами себе счётчик сбрасывать. Если раньше оригинального картриджа "хватало" на месяц при незначительном объёме печати, то сейчас читерского картриджа "хватает" на полгода, после чего по факту в нём остаётся минимум 2/3 чернил. С учётом бутылочек с чернилами мне этого комплекта хватит ещё на несколько лет.
Проверьте что будет, если камеру засветить так же как в статье, но ещё красным и зелёным лазером. Что-то мне подсказывает, что от матрицы останется совсем немного рабочих пикселей после этого.
Тут у нас другая лаба. Два неймспейса в виртуалке: в одном DHCP-клиент, в другом — DHCP-сервер. Они соединены друг с другом через veth-пару.
Нет ли здесь какого-то подвоха? Будет ли работать предложенное решение с оригинальной постановкой задачи, или нельзя просто так взять и завести XDP в общем случае?
Мне для своего телефона от Xiaomi удалось нагуглить сервисные утилиты для прошивки через EDL, всё в открытом доступе лежало чуть ли не на официальном сайте. Не знаю, правда, какой набор возможностей предоставлял конкретно этот EDL-лоадер, но само существование его в открытом доступе удивило. Может быть вычитать дамп не получится через него, только записать.
Время ожидания влития — это время, когда PR просто висит без правок. Оно считается от времени последнего коммита. Мы можем видеть тут, что часть PR висит в таком состоянии неделю. Т.к. коммитов нет — это не ревью, иначе могли бы быть правки кода. Что же это?
Мне как-то привычнее вносить мелкие правки в последний (часто единственный) коммит. До ревью всё равно никто этого не увидит. Время коммита при этом не обновляется, что создаёт отсутствие видимости работы. И да, время коммита может не соответствовать времени открытия PR, я могу девелопить в локальной ветке долго и нудно, а потом открыть PR. В общем, довольно спорная метрика получилась, но при определённых условиях наверное даже рабочая.
Можно ещё почитать текст по ссылке, которую вы приводите:
Svace – основной анализатор Samsung с 2015 года. Применяется для проверки собственного ПО компании на базе ОС Android и исходного кода ОС Tizen, которая используется в смартфонах, информационно-развлекательных системах и бытовой технике Samsung. С 2017 года Svace проверяет все изменения, присланные для рецензирования и включения в ОС Tizen. C 2020 года Svace применяется также в компании Huawei.
Этот функционал взялся не "вдруг", он довольно давно разрабатывается. Самая ранняя публикация, которую мне удалось найти, датируется вообще 2011 годом.
На другой плате от Sipeed тоже стоял похожий программатор, и какой же он убогий. Мало того, что прошивка идёт через раз, так даже попытка запустить официальный USB Complience Test для эмулируемого FTDI устройства заканчивается аварийным завершением. Попробуйте взять программатор на настоящем FT2232H, с ним должно быть всё ок.
По поводу Synplify: вроде как он там уже давно не работает, даже в с лицензионным ключом мне был доступен только их собственный Gowin Synthesis. Можно проверить в настройках, что из этого используется для синтеза.
Мне кажется, тут не столько возможность восстановления важна, сколько потенциальная возможность внедрить вредоносный код в процесс загрузки, о котором другие клиенты и знать не будут, особенно если этот код крутится на GPU.
Все эти режимы сделаны намеренно и нужны в разных ситуациях.
Так он не фиксирован. Догадываться не надо, в Reference Manual написано про эту память.
Не очень удобно, но исправлено в более новых контроллерах. Впрочем, DMA должен уметь делать такую конвертацию.
Только DTOG_RX для такого endpoint называется SW_BUF, если Reference Manual почитать. А в остальном — почему бы и нет? Поскольку такой endpoint не может одновременно работать на чтение и на запись, часть битов не имеет смысла и может в теории использоваться как угодно.
Интересно, как вы это сделали, если стандарт USB 2.0 приводит максимальную пропускную способность для Bulk и 64-байтных пакетов равную 1216000, что есть 9.728 Mbit/s. Что-то тут не сходится...
Как-то сложно вы прошиваете, можно же прописать runner = "arm-none-eabi-gdb -q -x openocd.gdb" в .cargo/config и прошивать с помощью gdb командой cargo run --release, без всякой конвертации в bin. Пример этого есть в https://github.com/rust-embedded/cortex-m-quickstart
И ещё: почему в features указан stm32f100, а не stm32f103?
В реальности такое сложно найти, а с точки зрения датчика — легко. Если по его мнению концентрация ниже 400, то он её "округляет" до 400. Это иногда приводит к довольно странным графикам.
Пользуюсь промужеточным вариантом: принтер с картриджами, но прозрачными и пополняемыми, которые ещё и умеют сами себе счётчик сбрасывать. Если раньше оригинального картриджа "хватало" на месяц при незначительном объёме печати, то сейчас читерского картриджа "хватает" на полгода, после чего по факту в нём остаётся минимум 2/3 чернил. С учётом бутылочек с чернилами мне этого комплекта хватит ещё на несколько лет.
Проверьте что будет, если камеру засветить так же как в статье, но ещё красным и зелёным лазером. Что-то мне подсказывает, что от матрицы останется совсем немного рабочих пикселей после этого.
Можно и на микроконтроллере сделать, если постараться: https://github.com/Wren6991/PicoDVI
Подозреваю, что в сервисном центре из платы что-то наоборот выпаяли, поэтому и рекомендовали не ремонтировать.
Нет ли здесь какого-то подвоха? Будет ли работать предложенное решение с оригинальной постановкой задачи, или нельзя просто так взять и завести XDP в общем случае?
А, ну тут статическую ARP запись нужно добавить. С такой схемой настройки всё и через IPv6 должно работать, как мне кажется.
С каких пор WoL стал работать по IPv4?
Мне для своего телефона от Xiaomi удалось нагуглить сервисные утилиты для прошивки через EDL, всё в открытом доступе лежало чуть ли не на официальном сайте. Не знаю, правда, какой набор возможностей предоставлял конкретно этот EDL-лоадер, но само существование его в открытом доступе удивило. Может быть вычитать дамп не получится через него, только записать.
Мне как-то привычнее вносить мелкие правки в последний (часто единственный) коммит. До ревью всё равно никто этого не увидит. Время коммита при этом не обновляется, что создаёт отсутствие видимости работы. И да, время коммита может не соответствовать времени открытия PR, я могу девелопить в локальной ветке долго и нудно, а потом открыть PR. В общем, довольно спорная метрика получилась, но при определённых условиях наверное даже рабочая.
Можно ещё почитать текст по ссылке, которую вы приводите:
Этот функционал взялся не "вдруг", он довольно давно разрабатывается. Самая ранняя публикация, которую мне удалось найти, датируется вообще 2011 годом.
На другой плате от Sipeed тоже стоял похожий программатор, и какой же он убогий. Мало того, что прошивка идёт через раз, так даже попытка запустить официальный USB Complience Test для эмулируемого FTDI устройства заканчивается аварийным завершением. Попробуйте взять программатор на настоящем FT2232H, с ним должно быть всё ок.
По поводу Synplify: вроде как он там уже давно не работает, даже в с лицензионным ключом мне был доступен только их собственный Gowin Synthesis. Можно проверить в настройках, что из этого используется для синтеза.
Мне кажется, тут не столько возможность восстановления важна, сколько потенциальная возможность внедрить вредоносный код в процесс загрузки, о котором другие клиенты и знать не будут, особенно если этот код крутится на GPU.
А требования "пользователь не должен иметь возможность запороть EEPROM/процесс загрузки" у вас нет?
Интересно, как вы это сделали, если стандарт USB 2.0 приводит максимальную пропускную способность для Bulk и 64-байтных пакетов равную 1216000, что есть 9.728 Mbit/s. Что-то тут не сходится...
Упоминался вскользь, зато аж в двух докладах!
Можно же разные модули на разных языках писать. По крайней мере, в теории.
Да. Xargo теперь нужен в очень редких случаях.
Как-то сложно вы прошиваете, можно же прописать
runner = "arm-none-eabi-gdb -q -x openocd.gdb"
в .cargo/config и прошивать с помощью gdb командойcargo run --release
, без всякой конвертации в bin. Пример этого есть в https://github.com/rust-embedded/cortex-m-quickstartИ ещё: почему в features указан
stm32f100
, а неstm32f103
?В реальности такое сложно найти, а с точки зрения датчика — легко. Если по его мнению концентрация ниже 400, то он её "округляет" до 400. Это иногда приводит к довольно странным графикам.