jcxz

Тогда часть генерируемого числа будет всё время константой. Что явно плохо. Вроде как очевидно.

Я ранее приводил ссылки и на описание и на примеры исходников: Я в исходниках не разбирался - не нужно мне. Возможно там только для одного размера периода. Но наверное можно доработать под себя. Размер исходников выглядит не страшным. Ещё какие-то исходники здесь: http://www.math.sci.hiroshima-u.ac.jp/m-mat/MT/MT2002/emt19937ar.html Там и описание имеется, судя по беглому взгляду.

А сколько всего уникальных значений должно сгенерить устройство за свою жизнь? Максимум? Если принять скажем, что каждое из устройств может сгенерить максимум K значений Мерсенна, то можно реализовать такой алгоритм: Каждое устройство генерит значения Мерсенна начиная с некоего базового (B), которое у каждого экземпляра устройства - своё. Теперь производите первое устройство. Придумываете некоторое случайное число BBB. Генерите на мощном ПК Мерсенном BBB значений. Запоминаете состояние алгоритма Мерсенна в этом первом устройстве (оно продолжит генерацию новых Мерсеннов с этой позиции). Производите 2-е устройство. Генерите на мощном ПК, продолжая с предыдущей сохранённой позиции алгоритма, K шт. значений Мерсенна (т.е. - делаете пропуск K значений последовательности). Запоминаете состояние алгоритма Мерсенна в этом втором устройстве (оно продолжит генерацию новых Мерсеннов с этой позиции). И так далее.... Т.е. получается - весь диапазон периода Мерсенна разбивается на куски размером = K, и каждое устройство работает в своём куске диапазона. Даже если скажем каждое устройство за свою жизнь может генерить миллион значений M (K = 1e+6), то думаю - сделать миллион итераций Вихря Мерсенна на мощном ПК не должно занять много времени. А может - и миллиард итераций для мощного ПК будет не проблема. Надо пробовать.

Я изначально понял, что речь шла об энкодере вращения шарика мышки в старой (не оптической) мыши. Там как раз такие энкодеры стояли по X и по Y. Если речь о колесе прокрутки, то да - это другое.

Разумеется можно использовать м/с памяти для хранения уже сформированных кодов (ключей). Я такого не говорил! Не нужно мне приписывать чужие слова! Если количество ваших устройств - сравнительно небольшое (например <= 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-кратным запасом, выбрав бОльший период Мерсенна.

А зачем вообще эта схема? Я так понимаю - импульсы перемещения вы собираетесь передавать через какие-то из сигналов: CTS, DSR, DCD, RI? Если так, то драйвер мыши для ПК вам придётся всё равно писать самому. Тогда почему не бороться с дребезгом программно в этом драйвере на ПК? И вообще бОльшую часть схемы выкинуть, сделав просто 4 формирователя уровней для 4-х сигналов энкодера и пустив их напрямую на CTS, DSR, DCD, RI? Вся остальная обработка - в драйвере на ПК. Просто 4 повторителя или инвертора с триггерами Шмитта на входе и всё.

Нормально и легко дребезг давится программно. При наличии микроконтроллера. Логикой программы опроса. Но в вашем случае, можно хотя-бы сделать: RC-цепочку заряда + RC-цепь разряда + лог.элементы U3.1/U3.2 должны быть с триггерами Шмитта на входе. Тогда будет задержка срабатывания в обе стороны и чрезмерных токов не будет. И да - как уже посоветовали ранее - минимальный набор измерительных инструментов нужно иметь. Самого дешёвого лог.анализатора вполне хватит.

Какая "внешняя микросхема памяти"? И какое она имеет отношения с теме обсуждения? - вообще непонятно... Здесь вроде как ГПСЧ обсуждаются, если что.

Грамотным является хотя бы прочитать то, что пишут оппоненты. А вы видимо даже не читали то, что я предложил. Если бы прочитали, то уяснили бы что: Т.е. - период 4,3•106001 (о котором я писал) - это не константа. И можно выбрать свой период, наиболее удобный. Из ряда простых чисел Мерсенна. Ряд этот имеется по приведённой мною ссылке. Например в нём есть число = 170141183460469231731687303715884105727. (что даёт разрядность = ln(170141183460469231731687303715884105727)/ln(2) = ~127 бит). Т.е. - реализуем Вихрь Мерсенна с базой = 170141183460469231731687303715884105727 и получаем период = ~2^127. И этот период математически обоснован, а не голословное утверждение. ТСу 2^127 вроде как - вполне достаточно.

Что примерно на 100 десятичных порядков меньше чем у "Вихря Мерсенна". Сомнительное утверждение. Чем оно обосновано?

Совершенно не понятно - куда автор собрался подавать свои выходные импульсы 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.

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

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

Ещё раз повторю вопрос: Где именно вы включаете это самое "кеширование"??? Или речь про атрибуты MPU? Включения кеша флеша или кеша внутреннего ОЗУ? PS: Если речь про разные регионы ОЗУ с различными атрибутами MPU, то можно создать отдельно регион обычной ОЗУ (с включенным битом "cacheable") и отдельно - регион с выключенным атрибутом "cacheable" для DMA. И скомпоновать во 2-й все секции ОЗУ с которыми работает DMA. Я именно так и делаю в своих проектах. И не прибиваю никаких переменных гвоздями к фиксированным адресам ОЗУ в командном файле компоновщика.

Какое "кеширование памяти" для внутреннего ОЗУ МК? На кой оно сдалось в STM32? И как вы его собрались включать? И о каком STM32 вообще речь? В каком STM32 это необходимо?