jcxz

Помнится (из 90-хх), что в некоторых мышах шарики были металлические. Без резиновой оболочки. Такие не должны разложиться. (разве что поржаветь ) Хотя - из чего сделаны внутри ролики (которые крутит шарик)? вопрос. Возможно, что они обрезиненные в таких мышках. В мышах с обрезиненным шариком, ролики внутри были пластиковые.

Я же предлагал не "поднимать", а "взять готовый, уже поднятый". И даже написал - где можно взять. Даже для начинающего это должно быть несложно. PS: IAR-овские примеры имеют свойство работать "из коробки".

Ещё может зарядка или кабель от какой-то старой версии стандарта PowerDelivery. Может есть какая-то несовместимость по версиям PD?

Где-то читал, что это - миф. Никакого угасания из-за собственно только возраста нет. Угасание происходит из-за неиспользования этих самых функций мозга (как и любая другая функция организма - если не используется, то атрофируется со временем; природа не любит ненужных излишеств). Большинство пенсионеров просто не хотят изучать ничего нового, отсюда и угасание функций их мозга. Тогда можно идти двумя путями: Взять простейший МК (несложный для изучения) и реализовать схему мышки на нём, подключив к нему датчик перемещения и кнопки. Выдавая наружу через UART. Не знаю - что за датчики перемещения стоят в оптических мышках. Но думаю их вполне возможно подключить к обычному МК. В качестве удобного МК думаю вполне подойдёт STM8: он имеет минимальный набор стандартной периферии, периферия у него простая, код пишется на си, есть эмуляторы. И сам STM8 и эмуляторы к нему - дешёвые. Сделать преобразователь интерфейсов: На какой-либо плате с МК (с USB) поднять USB-хост, воткнуть в него мышку и все получаемые от неё данные пересылать на любой порт этого МК (UART например). Если начинающий, то: Ставим IAR for ARM, в списке примеров идущих с ним в комплекте есть примеры USB-хостов для мышки для разных МК. Выбираем один из этих МК. Запускаем и изучаем проект. Изучив проект, можно найти в нём данные получаемые от мыши и немного доработать его, чтобы эти данные далее пересылались на какой-то интерфейс МК (UART). Имхо - 2-й путь лучше. Так как даёт возможность использовать любые готовые мыши. Выдержка из readme.txt одного из таких IAR-овских демо-проектов для мышки: Т.е. - если его запустить, думаю будет несложно найти откуда вытащить нужные данные, чтобы переслать их в UART. PS: А лазерный утюг, да ещё с DIP - это тупиковый путь. Как уже сказали выше...

Не должно такого быть. Стандарт не дураки писали, поэтому такую ситуацию конечно предусмотрели. У приёмника энергии Vbus должна быть притянута к GND резистором ~2.2кОм ... ~8кОм (за точность номиналов не ручаюсь - выяснял этот диапазон экспериментально на своём экземпляре USB-PD-источника и пишу по-памяти). Обычно ставят резистор 4.7кОм или 5.1кОм. Поэтому источник энергии может обнаружить выдёргивание приёмника по обнулению тока потребления. И в этот момент он должен выключить выдачу питания на Vbus (вообще выставить туда 0V) и выполнить сброс своего внутреннего состояния (сбросить все согласованные через USB-CC настройки). При следующем втыкании приёмника он обнаружит появление подтяжки (скорее всего в выключенном состоянии он выдаёт какое-то минимальное напряжение, чтобы детектировать появление подтяжки), выставит дефолтное состояние (5V, 1A) и запустит процедуру согласования по протоколу через линию CC. Падение выдаваемого напряжения на выходе источника происходит очень быстро (несколько миллисекунд). Физически невозможно успеть переткнуть кабель за такое время. Но... видел в инете схемы кабелей для USB-CC от разных "умельцев". Которые или не читали стандарт или забили на него. И в некоторых из тех кабелей видел резисторы подтяжки Vbus на GND. Резистор находится в самом кабеле! А значит: если скажем в кабеле стоит такой резистор и в подключаемом устройстве - тоже, и их суммарное сопротивление находится в диапазоне ~2.2кОм ... ~8кОм и кабель отключается не полностью, а только тот его конец, где приёмник энергии. То в таком случае источник энергии скорее всего не обнаружит факта отключения приёмника и продолжит выдавать согласованное ранее напряжение. Могу предположить такой сценарий, приведший к попаданию высокого U на вход приёмника без согласования. PS: Ну либо - могли втыкать некий китайский источник, просто имеющий USB-C-разъём на конце и всегда выдающий туда 20V без реализации протокола USB-PD.

А индихатор хде?

А причём тут "криптографическая стойкость", если вопрос был про генерацию случайного числа (или псевдослучайного) с большим периодом повторения? PS: Имхо - любой ГПСЧ будет криптографически нестоек, так как закон генерации известен, значит - теоретически возможно найти следующее значение, зная предыдущее. Но вопрос темы вообще не про "криптографическую стойкость".

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

Я ранее приводил ссылки и на описание и на примеры исходников: Я в исходниках не разбирался - не нужно мне. Возможно там только для одного размера периода. Но наверное можно доработать под себя. Размер исходников выглядит не страшным. Ещё какие-то исходники здесь: 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 должны быть с триггерами Шмитта на входе. Тогда будет задержка срабатывания в обе стороны и чрезмерных токов не будет. И да - как уже посоветовали ранее - минимальный набор измерительных инструментов нужно иметь. Самого дешёвого лог.анализатора вполне хватит.

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