Вот окон в таком модуле нет, видимо пока что сложно иллюминаторы надежно крепить к мягким стенкам
Окон и сейчас на МКС не много, кроме двух специальных модулей Destiny (WORF) и Cupola они есть только на российском модуле Звезда (14 штук), два на российском стыковочном модуле, и по одному прилетает на Союзах… и на японском Kibo ещё два. В общем в обычных модулях типа Unity, с которым этот часто сравнивают, окон нет.
Не подскажете программу, которая может слушать то, что посылается в клавиатуру?(USB)
Wireshark в том числе и с USB работает.
По поводу ревесить, может быть так, что скрипты пишутся в память клавиатуры, и по нажатию отдаётся запрограммированный поток сканкодов. Т.е. сама по себе кнопка не шлёт вообще ничего. У меня в Aivia Osmium именно так. Был G-Unit, но было это давно и разбирался с этой клавиатурой недолго, поэтому точнее не подскажу.
Тем не менее, раздел DIY на Geektimes, и не понятно что делать, когда DIY касается микроконтроллера, поскольку хаб о его программировании на Habrahabr. Кто бы разъяснил...
Нет там движения, совсем, в том смысле, что оно физически не возможно. Конечно если речь о спине, а не об орбитальном моменте. Эту характеристику назвали спином, поскольку частица ведёт себя _как если бы_ вращалась. А вот откуда такие свойства взялись, пока никто пояснить не в состоянии.
Спин не связан с вращением, это некое квантовое свойство частицы, которое определяет её способность взаимодействовать с магнитным полем. Конечно не только это, но думаю в статье его упоминали исключительно из-за этого свойства. Если пересказать статью кратко, то из нечто разлетающегося во все стороны, стали образовываться частицы, которые летели дальше, но в виду фундаментальных свойств начали взаимодействовать через магнитные и гравитационные поля, а дальше всё закрутилось по накатанной. Разумеется для этого частицы должны были быть существенно ближе друг к другу, чем например сейчас газ и пыль в облаках, которые могут "висеть" пока, что-нить рядом не пролетит или не бабахнет.
UIO интересный вариант, но несколько более замороченный, чем изначально использованный FUSE. А по поводу CUSE у меня серьёзные сомнения, что он жив. Последний раз слышал о нём, так давно, что даже не сразу вспомнил, что такая штука была.
Оценки качества небольшой выборки, которую собирал кусками недели две, есть в статье. Речи о белом шуме здесь не идёт, диод генерирует, так называемый розовый (электронный) шум, и его наибольшая плотность именно в низкочастотном диапазоне. Так что тут всё неплохо сбалансировано.
Кстати да… даже когда подробно прочёл не сразу вспомнил о чём речь. Вариант очень интересный, но требует существенно больше вычислений, не говоря уже о том, что придётся выбросить половину измерений, в идеальном случае. Но ради эксперимента, вероятно даже проверю этот вариант.
Что-то смысл не уловил, какие два бита вы предлагается взять, чтобы равновероятно выпадали 01 и 10? Если что, то там по сути все 10 бит, в той или иной мере, случайные, но использовать их нельзя. Всегда будут зависимости, как рабочий диапазон, температура, износ. Само по себе это не плохо, если есть возможность откалибровать, но чем больше бит, тем больше требуется вычислений. А использованный метод, прост и надёжен, даже формул не требуется для обоснования.
Калибровка примерно каждые 12 секунд обновляется, поэтому это не проблема в принципе. Если конкретно, то при изменении температуры в помещении от 23 до 32, отсечка плавала 119-126, сейчас стабильно 23°C и стоит фактически на месте — 126.
P.S. Действительно упустил эту мысль, когда зачищал код, сейчас поковырял стандартный watchdog и выяснил, что он ругается немного, но вполне может жить без ioctl запросов. Залил v0.2, там добавлен новый канал, который можно использовать совместно с watchdog. Последнему достаточно указать в настройках:
watchdog-device = /run/wrnd/wdt.fifo
Только нужно иметь в виду, если wrnd заверешит работу раньше чем watchdog, то будет перезагрузка. Драйвер можно использовать, но по сути он уже бесполезен.
Спасибо, посмотрел внимательнее, проверил настройки ядра и /proc/cpuinfo, оказалось он у меня тоже есть. Но в Linux с ним всё не просто, вроде его и не выпилили как во FreeBSD, но то, что он используется не видно. Ядро восстанавливает энтропию со скоростью меньше чем 2 байта в секунду, что в моём случае не приемлемо. А rngd принципиально против этого источника энтропии: RDRAND will be disabled и далее уточнение, что без вариантов. Поэтому эффекта я не заметил, и пришлось решать проблему сначала через /dev/urandom, а потом и доп.устройством.
Да вы правы, наиболее логично здесь открыть в user space сокет и передать его watchdog демону для работы, соответственно весь остальной код будет тоже в user space. Но так сложилось исторически, пока экспериментировал с line discipline и вариантами сделать псевдо-USB драйвер для всего устройства.
Спасибо, но схема этого генератора стандартная, ищется по ключевым "avalanche noise generator", только софт пришлось писать с нуля, поскольку примеры, сопровождающие эти схемы, по моему скромному мнению, не приемлемы.
Окон и сейчас на МКС не много, кроме двух специальных модулей Destiny (WORF) и Cupola они есть только на российском модуле Звезда (14 штук), два на российском стыковочном модуле, и по одному прилетает на Союзах… и на японском Kibo ещё два. В общем в обычных модулях типа Unity, с которым этот часто сравнивают, окон нет.
Wireshark в том числе и с USB работает.
По поводу ревесить, может быть так, что скрипты пишутся в память клавиатуры, и по нажатию отдаётся запрограммированный поток сканкодов. Т.е. сама по себе кнопка не шлёт вообще ничего. У меня в Aivia Osmium именно так. Был G-Unit, но было это давно и разбирался с этой клавиатурой недолго, поэтому точнее не подскажу.
Да, в виндах без AutoHotkey вообще никак. Раскладку тоже меню по CapsLock, есть варианты более суровые, через WinAPI, но остановился на самом простом:
Тем не менее, раздел DIY на Geektimes, и не понятно что делать, когда DIY касается микроконтроллера, поскольку хаб о его программировании на Habrahabr. Кто бы разъяснил...
Спин не связан с вращением, это некое квантовое свойство частицы, которое определяет её способность взаимодействовать с магнитным полем. Конечно не только это, но думаю в статье его упоминали исключительно из-за этого свойства. Если пересказать статью кратко, то из нечто разлетающегося во все стороны, стали образовываться частицы, которые летели дальше, но в виду фундаментальных свойств начали взаимодействовать через магнитные и гравитационные поля, а дальше всё закрутилось по накатанной. Разумеется для этого частицы должны были быть существенно ближе друг к другу, чем например сейчас газ и пыль в облаках, которые могут "висеть" пока, что-нить рядом не пролетит или не бабахнет.
На счёт CUSE был не прав, вполне актуальная технология спасибо, что напомнили.
UIO интересный вариант, но несколько более замороченный, чем изначально использованный FUSE. А по поводу CUSE у меня серьёзные сомнения, что он жив. Последний раз слышал о нём, так давно, что даже не сразу вспомнил, что такая штука была.
Оценки качества небольшой выборки, которую собирал кусками недели две, есть в статье. Речи о белом шуме здесь не идёт, диод генерирует, так называемый розовый (электронный) шум, и его наибольшая плотность именно в низкочастотном диапазоне. Так что тут всё неплохо сбалансировано.
Кстати да… даже когда подробно прочёл не сразу вспомнил о чём речь. Вариант очень интересный, но требует существенно больше вычислений, не говоря уже о том, что придётся выбросить половину измерений, в идеальном случае. Но ради эксперимента, вероятно даже проверю этот вариант.
Что-то смысл не уловил, какие два бита вы предлагается взять, чтобы равновероятно выпадали 01 и 10? Если что, то там по сути все 10 бит, в той или иной мере, случайные, но использовать их нельзя. Всегда будут зависимости, как рабочий диапазон, температура, износ. Само по себе это не плохо, если есть возможность откалибровать, но чем больше бит, тем больше требуется вычислений. А использованный метод, прост и надёжен, даже формул не требуется для обоснования.
Калибровка примерно каждые 12 секунд обновляется, поэтому это не проблема в принципе. Если конкретно, то при изменении температуры в помещении от 23 до 32, отсечка плавала 119-126, сейчас стабильно 23°C и стоит фактически на месте — 126.
P.S. Действительно упустил эту мысль, когда зачищал код, сейчас поковырял стандартный watchdog и выяснил, что он ругается немного, но вполне может жить без ioctl запросов. Залил v0.2, там добавлен новый канал, который можно использовать совместно с watchdog. Последнему достаточно указать в настройках:
Только нужно иметь в виду, если
wrndзаверешит работу раньше чемwatchdog, то будет перезагрузка. Драйвер можно использовать, но по сути он уже бесполезен.Спасибо, посмотрел внимательнее, проверил настройки ядра и /proc/cpuinfo, оказалось он у меня тоже есть. Но в Linux с ним всё не просто, вроде его и не выпилили как во FreeBSD, но то, что он используется не видно. Ядро восстанавливает энтропию со скоростью меньше чем 2 байта в секунду, что в моём случае не приемлемо. А rngd принципиально против этого источника энтропии: RDRAND will be disabled и далее уточнение, что без вариантов. Поэтому эффекта я не заметил, и пришлось решать проблему сначала через /dev/urandom, а потом и доп.устройством.
Да, /dev/urandom примерно так и работает, и нет ничего плохого в его использовании. Но ещё лучше, когда есть выбор. Так что, почему бы и не сделать.
Спасибо, но схема этого генератора стандартная, ищется по ключевым "avalanche noise generator", только софт пришлось писать с нуля, поскольку примеры, сопровождающие эти схемы, по моему скромному мнению, не приемлемы.
Поэтому и спрятал под спойлер. А причина простая — метка tutorial обязывает не пропускать детали.
Устройство собирал под платформу Bay Trail, процессор Celeron J1900, там ничего такого нет. А в целом, конечно вариант хороший.
Ближе к железу, чем драйвер drivers/char/random.c вряд-ли что-то можно найти. Если что, он хорошо документирован.