jcxz

А в чём отличие? PS: Для STM8 есть как дешёвые отладочные платы так и дешёвые эмуляторы. На том же али. Стоящие буквально копейки. Для x51 их надо ещё искать. Непонятно где и непонятно за какую цену и не факт, что они вообще есть (скорее всего - только для некоторых из x51). Так что - только из одного этого факта можно сделать вывод о преимуществах STM8 vs x51. ТС мог бы купить отладку на STM8 и прямо как есть - вставить её в свою мышку. Подпаяв всё что нужно к ней проводками. Без лазерного утюга и DIP-ов.

Да. Там вполне может быть прошит например - уникальный номер экземпляра DSP. И прошивка может быть зашифрована ключом, привязанным к этому номеру (если бутлоадер умеет такое). Надо читать доку. Это совет ТСу. Раз уж он взялся ремонтировать станок.

См. выше. Если бы программа пользователя находилась во внутренней памяти DSP, то не было бы никакой необходимости грузить внешний AIS-образ.

Может вместо того, чтобы фантазировать, стоило хотя-бы бегло просмотреть документацию на ваш DSP? раз уж решили его чинить... Естественно никакую рабочую прошивку считать с него нельзя, по причине отсутствия в данном семействе DSP энергонезависимой памяти программ пользователя. Также - крайне сомнительны ваши предположения насчёт предназначения чипов flash на плате. Во-первых: загрузчик AIS-образов есть в ROM самого DSP. Во-вторых: логично предположить, что программа пользователя находится в M25P64, а 24C512 содержит настройки программы. Поэтому - скопировав в 24C512 содержимое от другого станка, вы просто снесли все настройки пациента. Точно определить - откуда грузится прошивка, можно прочитав SPRS277 (раздел "Bootloader (BOOT ROM)") и изучив плату/схему в которой стоит DSP. Совет: Почитать - что такое AIS, про его формат. И проанализировать считанное из M25P64 на предмет наличия в его начале AIS-образа. Надеюсь - вы сохранили оригинальное содержимое чипов 24C512 и M25P64? Если нет, то возможно - стерев их старое содержимое, вы безвозвратно потеряли возможность восстановить станок, так как (вполне возможно), что там хранился какой-нить ключ, привязывающий содержимое 24С512 или M25P64 к каким-либо серийным номерам компонентов данного станка. Либо какие-то настройки важные для работы механики станка (какие-нить калибровочные данные или подобное). В SPRS277 есть описание содержимого ROM: А сам текст ошибки: как бы намекает, что идёт попытка чтения AIS-образа (в котором хранятся программы пользователя для DSP семейства C67xx) из внешней памяти. Значит прошивка однозначно во внешнем чипе.

Откуда инфа? Можно пруфы? На сайте STM не вижу NRND: Наверное им ещё не сообщили. Да и какая разница - рекомендованы или нет? если они продаются и ещё долго будут продаваться на али. Речь ведь не о серийном производстве. А для x51 есть эмуляторы? Можно ссылку? И архитектура у STM8 поудобнее, чем у x51. Если писать на асме.

Помнится (из 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), то думаю - сделать миллион итераций Вихря Мерсенна на мощном ПК не должно занять много времени. А может - и миллиард итераций для мощного ПК будет не проблема. Надо пробовать.