Перейти к содержанию
    

jcxz

Свой
  • Постов

    13 223
  • Зарегистрирован

  • Посещение

  • Победитель дней

    32

jcxz стал победителем дня 11 мая

jcxz имел наиболее популярный контент!

Репутация

191 Очень хороший

4 Подписчика

Информация о jcxz

  • Звание
    Гуру
    Гуру
  • День рождения 01.12.1974

Контакты

  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

27 843 просмотра профиля
  1. А причём тут "криптографическая стойкость", если вопрос был про генерацию случайного числа (или псевдослучайного) с большим периодом повторения? PS: Имхо - любой ГПСЧ будет криптографически нестоек, так как закон генерации известен, значит - теоретически возможно найти следующее значение, зная предыдущее. Но вопрос темы вообще не про "криптографическую стойкость".
  2. Тогда часть генерируемого числа будет всё время константой. Что явно плохо. Вроде как очевидно.
  3. Я ранее приводил ссылки и на описание и на примеры исходников: Я в исходниках не разбирался - не нужно мне. Возможно там только для одного размера периода. Но наверное можно доработать под себя. Размер исходников выглядит не страшным. Ещё какие-то исходники здесь: http://www.math.sci.hiroshima-u.ac.jp/m-mat/MT/MT2002/emt19937ar.html Там и описание имеется, судя по беглому взгляду.
  4. А сколько всего уникальных значений должно сгенерить устройство за свою жизнь? Максимум? Если принять скажем, что каждое из устройств может сгенерить максимум K значений Мерсенна, то можно реализовать такой алгоритм: Каждое устройство генерит значения Мерсенна начиная с некоего базового (B), которое у каждого экземпляра устройства - своё. Теперь производите первое устройство. Придумываете некоторое случайное число BBB. Генерите на мощном ПК Мерсенном BBB значений. Запоминаете состояние алгоритма Мерсенна в этом первом устройстве (оно продолжит генерацию новых Мерсеннов с этой позиции). Производите 2-е устройство. Генерите на мощном ПК, продолжая с предыдущей сохранённой позиции алгоритма, K шт. значений Мерсенна (т.е. - делаете пропуск K значений последовательности). Запоминаете состояние алгоритма Мерсенна в этом втором устройстве (оно продолжит генерацию новых Мерсеннов с этой позиции). И так далее.... Т.е. получается - весь диапазон периода Мерсенна разбивается на куски размером = K, и каждое устройство работает в своём куске диапазона. Даже если скажем каждое устройство за свою жизнь может генерить миллион значений M (K = 1e+6), то думаю - сделать миллион итераций Вихря Мерсенна на мощном ПК не должно занять много времени. А может - и миллиард итераций для мощного ПК будет не проблема. Надо пробовать.
  5. Я изначально понял, что речь шла об энкодере вращения шарика мышки в старой (не оптической) мыши. Там как раз такие энкодеры стояли по X и по Y. Если речь о колесе прокрутки, то да - это другое.
  6. Разумеется можно использовать м/с памяти для хранения уже сформированных кодов (ключей). Я такого не говорил! Не нужно мне приписывать чужие слова! Если количество ваших устройств - сравнительно небольшое (например <= 256), то можно сделать просто: Присваиваем каждому устройству уникальный 8-разрядный порядковый номер (N); генерим Мерсенном очередное число (M); считаем от последовательности байтов полученного M какую-нить функцию с 8-битным результатом (f(M)), типа CRC8 или просто XOR всех байтов; если f(M) != N - отбрасываем данное M и генерим следующее M и снова сравниваем f(M) == N?; и так продолжаем пока не найдём M у которого f(M) == N. Всё - получили искомое значение, уникальное во всех устройствах. Период получаемых M станет конечно меньше в 256 раз, но так его можно заранее выбрать с 256-кратным запасом, выбрав бОльший период Мерсенна.
  7. А зачем вообще эта схема? Я так понимаю - импульсы перемещения вы собираетесь передавать через какие-то из сигналов: CTS, DSR, DCD, RI? Если так, то драйвер мыши для ПК вам придётся всё равно писать самому. Тогда почему не бороться с дребезгом программно в этом драйвере на ПК? И вообще бОльшую часть схемы выкинуть, сделав просто 4 формирователя уровней для 4-х сигналов энкодера и пустив их напрямую на CTS, DSR, DCD, RI? Вся остальная обработка - в драйвере на ПК. Просто 4 повторителя или инвертора с триггерами Шмитта на входе и всё.
  8. Нормально и легко дребезг давится программно. При наличии микроконтроллера. Логикой программы опроса. Но в вашем случае, можно хотя-бы сделать: RC-цепочку заряда + RC-цепь разряда + лог.элементы U3.1/U3.2 должны быть с триггерами Шмитта на входе. Тогда будет задержка срабатывания в обе стороны и чрезмерных токов не будет. И да - как уже посоветовали ранее - минимальный набор измерительных инструментов нужно иметь. Самого дешёвого лог.анализатора вполне хватит.
  9. Какая "внешняя микросхема памяти"? И какое она имеет отношения с теме обсуждения? - вообще непонятно... Здесь вроде как ГПСЧ обсуждаются, если что.
  10. Грамотным является хотя бы прочитать то, что пишут оппоненты. А вы видимо даже не читали то, что я предложил. Если бы прочитали, то уяснили бы что: Т.е. - период 4,3•106001 (о котором я писал) - это не константа. И можно выбрать свой период, наиболее удобный. Из ряда простых чисел Мерсенна. Ряд этот имеется по приведённой мною ссылке. Например в нём есть число = 170141183460469231731687303715884105727. (что даёт разрядность = ln(170141183460469231731687303715884105727)/ln(2) = ~127 бит). Т.е. - реализуем Вихрь Мерсенна с базой = 170141183460469231731687303715884105727 и получаем период = ~2^127. И этот период математически обоснован, а не голословное утверждение. ТСу 2^127 вроде как - вполне достаточно.
  11. Что примерно на 100 десятичных порядков меньше чем у "Вихря Мерсенна". Сомнительное утверждение. Чем оно обосновано?
  12. Совершенно не понятно - куда автор собрался подавать свои выходные импульсы 10-100мсек? В какие именно линии COM-порта? Входных (в ПК) сигналов от COM-порта всего 4шт.: CTS, DSR, DCD, RI. Автору же нужно минимум 8 таких сигналов: 4шт. для импульсов перемещения + 2шт. - для колеса мыши + 2шт. - для минимум 2-х кнопок мыши. А если добавить ещё и: То получается ещё больше. Или это будет возложено на некий "контроллер клавиатуры", с нормальным UART-выходом (TXD)? Это уже не говоря о том, что макс. частота импульсов перемещения = 50 или 100(?) Гц - маловата для нормальной работы с мышкой. Тем более - для игр (о которых пишет ТС). И не говоря о сомнительном решении с постоянным замыканием 5V-питания на 4шт. 100нФ ёмкости. Сколько протянут контакты замыкающиеся в таком режиме постоянно с частотой 50Гц? - большой вопрос. Ещё и источник этого 5V-питания - TXD(от ПК), RTS, DTR - маломощный. Но должен выдерживать эти импульсные токи замыкания 200нФ (или 400нФ?) на GND без просадок. И одновременно должен питать и всю схему и 5 выходных сигналов COM-порта. И с дребезгом борятся совсем не так. PS: Самое правильное решение тут - выкинуть весь этот колхоз (вместе с контроллером клавиатуры) и заменить его на простейший микроконтроллер с UART.
  13. STM32CubeIDE

    И не нужно ничего прибивать гвоздями к фиксированным адресам.
  14. STM32CubeIDE

    Для MPU нет никакой необходимости в: Как уже писал выше. Помещаем все такие переменные в секции называемые например ".dma", а в командном файле компоновщика говорим "компоновать эти секции в регион ОЗУ с установленными как надо атрибутами MPU". Всё.
×
×
  • Создать...