То есть сами понимаете слабость своих аргументов. Если не выдирать из контекста (ведь для HID совсем не обязателен аппаратный модуль), доказать нужность своего «изобретения» становится сложнее.
Для того чтобы понять в чем преимущество аппаратного USB в сравнении с программным, код не нужен.
Код нужен чтобы улучшать устройство и допиливать его под свои нужды. Ну или хотя бы посмотреть реализацию и применить в другом месте.
Впрочем, вы правы: вряд ли от вашего кода будет какая-то польза.
Если нет 100% гарантии то не вариант. Объясните зачем пользоваться программной эмуляцией когда большой выбор МК с USB?
Например, если они есть под рукой. Да и жалко тратить целую stm'ку для задачи, с которой AVR справится ничуть не хуже. Впрочем, сама задача все еще непонятна.
Посмотрите в заявленных характеристиках
Вот если бы привели код, можно было бы смотреть внимательнее. А так проглядел по диагонали — зачем уделять лишнее время настолько бесполезной рекламе?
В добавок много потоков на одну точку дополнительно снизит скорость эмуляции.
Не-а. Определение номера точки это чтение пары битов, оно почти ничего не стоит.
vusb это не моя библиотека, я только расписал как она работает.
опрос каждые 10 мс и максимум 8 байт в пакете. И если не ошибаюсь есть ограничения на количество конечных точек.
Опрос скорее всего будет с периодом 1 мс, причем это никак не скажется на стабильности.
8 байт на пакет и 3 конечные точки? А вам сколько нужно? Размер пакета для HID фиксирован, все общение так и так идет через endpoint0.
Что-то я сильно сомневаюсь, что вы заморачивались с составным устройством из 6 клавиатур, одной мышки и одной проприетарщины (с которой работает ваша библиотека).
Да уж куда нам, убогим.
Для справки, некоторые хосты игнорируют ограничение на частоту опроса и вполне допускают опрос раз в миллисекунду даже для низкоскоростных устройств.
Но смысл гоняться за скоростью клавиатуры для меня непонятен.
ссылка на архив с примерами которая есть на сайте
Вы бы лучше описали алгоритм поиска этой ссылки. Все равно повторять ваше устройство вряд ли кто-то будет.
А где ну… хоть что-нибудь? Какую пользу несет эта статья? Здесь не рассказано о сложностях и тонких моментах, здесь нет оригинальной идеи, здесь даже нет красивой реализации.
Может быть, вы предлагаете готовое решение для какой-то задачи? Наверное, я плохо искал, но ссылок систему контроля версий для доработки кода, ни хотя бы бинарника не нашел.
При том, что эмуляция клавомыши уже реализована не то что на stm, но даже на программном usb на всяких atmega8 — с исходниками и всем остальным.
А какое отношение это имеет к назначению портов?
То есть внутри того же «lcd_44780.h» имеет смысл реализовать стандартные функции вывода текста (графику-то он не поддерживает). С этим никто не спорит. Но при разводке платы бывает удобно поменять порты, к которым он подключен. Не лезть же каждый раз внутрь библиотеки! И абстракции вокруг портов должны решать именно эту задачу, а вовсе не лезть во внутренности библиотек.
Скажем, я пишу библиотеку для дисплея на hd44780, нужно объявить 4 подряд идущие ноги для линии данных, одну под RS и одну под E. Две последние для удобства разводки могут оказаться на разных портах.
На макросах я могу сделать так:
Да, в библиотеке будет немного шаманства чтобы развернуть 4 байта из структуры, предназначенной для хранения одного. Но это делается один раз. А подключается она потом к произвольным выводам, как видите, просто.
Так потому и просим продемонстрировать настройку и выхлоп ассемблера на какой-то практической задаче. Насколько подход очередного слоя абстракции лучше или хуже других.
Чего-то более оригинального, сложного и необычного.
Подробного описания периферии, принципов ее работы, эмуляцию и запуск на аппаратном модуле.
Красивого законченного устройства.
Полноценной библиотеки, которая бы действительно делала взаимодействие с контроллером более удобным.
Но если необходимо сконфигурировать несколько пинов, а тем более динамически менять конфигурацию <...> то гораздо проще обернуть всю работу с регистрами в класс, и пользоваться методами типа setPin/resetPin.
Было бы не плохо продемонстрировать удобство вашего способа. Ну, скажем, вывод на семисегментник, у которого сегменты разбросаны по разным портам в произвольном порядке.
Что считается «оригинальной докой»? Я его видел в документации на ядро bumblebee
Естественно, это не единственное решение. В других ядрах могут заводить просто ядерные спец регистры общего назначения. Собственно, в «компьютерном» применении скорость реакции на прерывания не так критична, там можно и правда обойтись одним-двумя лишними регистрами без особого «мозга» и с ручной проверкой режима.
Можно подробнее почему при постоянном напряжении выгорание одного из включенных параллельно диодов с ограничительными резисторами приведет к выгоранию остальных?
И что такого криминального в окунании паяльника в канифоль?
Насколько я понял из описания, там то ли команда csrrw проверяет режим, то ли сам доступ к регистру так хитро устроен. Точно сказать не могу, разделение прав доступа не ковырял.
В документации приведен такой псевдокод:
Линуксы, говорят, отказываются монтировать раздел с виндой если она ушла в гибернацию.
Подтверждаю. Даже не обязательно системный раздел, а любой, который был подмонтирован в винде когда она «выключалась». Мне пришлось специально искать способ заставить ее именно выключаться, а не засыпать.
Обновлять не значит перезаписывать. Скажем, это может быть чтение сектора и повторная запись без стирания. В любом случае, контроллер конкретного SSD справится с этим лучше, чем дефрагментатор, который, вообще-то, даже не все файлы перезапишет.
Насколько я знаю, рост файла происходит двоичным способом: пока незначительный, будет дописываться куда найдет (а находит обычно рядом с предыдущим), потом происходит перестройка дерева и файл запросто может переместиться.
Только вот скорость линейного доступа всё равно на порядок больше произвольного
Можно ссылку где на порядок? Потому что «в разы» еще можно понять, но в 10 раз это уж слишком.
Ну и опять же, сама структура хранения файла далеко не линейная
Дефрагментация нужна не для HDD/SSD/flash, а для устаревших файловых систем вроде fat32. Современные ФС сами размещают файлы максимально слитно, для них даже нет специальной утилиты дефрагментации.
А для SSD/flash дефрагментацию стоит отключать даже для fat, поскольку скорость доступа к произвольному блоку не так сильно отличается как в HDD, зато износ увеличивается.
Код нужен чтобы улучшать устройство и допиливать его под свои нужды. Ну или хотя бы посмотреть реализацию и применить в другом месте.
Впрочем, вы правы: вряд ли от вашего кода будет какая-то польза.
А непонятная dll'ка это, конечно, верх совместимости. Она там хоть крипту не майнит, пока никто не видит?
Вот если бы привели код, можно было бы смотреть внимательнее. А так проглядел по диагонали — зачем уделять лишнее время настолько бесполезной рекламе?
Не-а. Определение номера точки это чтение пары битов, оно почти ничего не стоит.
Опрос скорее всего будет с периодом 1 мс, причем это никак не скажется на стабильности.
8 байт на пакет и 3 конечные точки? А вам сколько нужно? Размер пакета для HID фиксирован, все общение так и так идет через endpoint0.
Что-то я сильно сомневаюсь, что вы заморачивались с составным устройством из 6 клавиатур, одной мышки и одной проприетарщины (с которой работает ваша библиотека).
Для справки, некоторые хосты игнорируют ограничение на частоту опроса и вполне допускают опрос раз в миллисекунду даже для низкоскоростных устройств.
Но смысл гоняться за скоростью клавиатуры для меня непонятен.
Вы бы лучше описали алгоритм поиска этой ссылки. Все равно повторять ваше устройство вряд ли кто-то будет.
Может быть, вы предлагаете готовое решение для какой-то задачи? Наверное, я плохо искал, но ссылок систему контроля версий для доработки кода, ни хотя бы бинарника не нашел.
При том, что эмуляция клавомыши уже реализована не то что на stm, но даже на программном usb на всяких atmega8 — с исходниками и всем остальным.
Да, слои абстракции могут не добавлять тормозов, но это надо показать.
То есть внутри того же «lcd_44780.h» имеет смысл реализовать стандартные функции вывода текста (графику-то он не поддерживает). С этим никто не спорит. Но при разводке платы бывает удобно поменять порты, к которым он подключен. Не лезть же каждый раз внутрь библиотеки! И абстракции вокруг портов должны решать именно эту задачу, а вовсе не лезть во внутренности библиотек.
На макросах я могу сделать так:
Да, в библиотеке будет немного шаманства чтобы развернуть 4 байта из структуры, предназначенной для хранения одного. Но это делается один раз. А подключается она потом к произвольным выводам, как видите, просто.
Подробного описания периферии, принципов ее работы, эмуляцию и запуск на аппаратном модуле.
Красивого законченного устройства.
Полноценной библиотеки, которая бы действительно делала взаимодействие с контроллером более удобным.
Естественно, это не единственное решение. В других ядрах могут заводить просто ядерные спец регистры общего назначения. Собственно, в «компьютерном» применении скорость реакции на прерывания не так критична, там можно и правда обойтись одним-двумя лишними регистрами без особого «мозга» и с ручной проверкой режима.
И что такого криминального в окунании паяльника в канифоль?
В документации приведен такой псевдокод:
Можно ссылку где на порядок? Потому что «в разы» еще можно понять, но в 10 раз это уж слишком.
Ну и опять же, сама структура хранения файла далеко не линейная
А для SSD/flash дефрагментацию стоит отключать даже для fat, поскольку скорость доступа к произвольному блоку не так сильно отличается как в HDD, зато износ увеличивается.