jcxz

Я же вроде писал: См.выделенную часть цитаты. Перегруженная операция приведения типа как раз и должна заменить свойство чтения борланда. Клацаете настолько быстро, что даже вопрос, на который отвечаете, не успеваете полностью прочитать?

Это только для самых узких полос нужно. 7.8кГц, 10.4кГц, ... На ~20.8кГц, ~31.25кГц уже вроде как и точности обычного кварца должно хватить. К тому же - неизвестно какой у вопрошающего требуемый температурный диапазон работы.

Разве перегрузка операторов присваивания и приведения типа - не оно? Конечно запись их определения будет не такой компактной (может даже дополнительные типы данных придётся создать), но конечный результат вроде должен дать примерно то же самое.

Конечно - сужать полосу. Сами же пишете. И при этом почему-то выбрали самые широкие полосы. Можно же вплоть до 7800Гц сужать. Чем уже полоса - тем более компактно сосредоточена энергия сигнала и меньше помех влетает в более узкую полосу. Соответственно - больше дальность.

У КР580ИК80 все сигналы/шины торчат наружу. Память - тоже снаружи. Также имеются подробные описания диаграмм работы всех этих шин/сигналов. А значит вполне возможно взять любой МК, подключиться им к шинам/сигналам КР580ИК80 и написать программу на МК, которая будет анализировать передаваемые по шинам данные, выдавать управляющие сигналы (HALT и т.п.) на КР580ИК80. И реализовать все необходимые функции отладочного эмулятора: Просмотр содержимого регистров/памяти (по захваченным и сохранённым с шин данным), breakpoint-ы (анализируя адрес выбираемой из памяти команды и остановку в нужный момент) и т.д. Т.е. - сваять собственный J-Link для КР580ИК80. Если знакомый хоть немного умеет программировать микроконтроллеры (а он должен это уметь), то такое сделать несложно. Да даже на абдурине можно слепить. Если конечно овчинка стоит выделки.....

Разве в тех мамонтах были какие-то отладочные интерфейсы? Насколько помню - там была возможность потактового исполнения с помощью сигнала HALT (или как-то так назывался). По-крайней мере были учебные стенды, которые позволяли пошагово выполнять программу. И можно захватывать передаваемое по шинам процессора. Но вот - как смотреть содержимое регистров процессора и ячеек ОЗУ? не ясно.... Имхо: ему наверное будет лучше воспользоваться каким-либо программным симулятором i8080.

"Ошибки" никакой нет. Не несите чушь. Дальше то что??? Значит для вас STM - истина в последней инстанции. В том числе почему-то и в вопросах русскоязычной и англоязычной терминологии. Это странно. Но это ваше личное дело. Каждый сходит с ума по своему. Называю и впредь буду называть J-Link и St-link и т.п. - отладочными эмуляторами. Вопрос закрыт.

А в чём ошибка то? которую нужно признать. Вот 2 ваших ложных высказывания, которые я опроверг конкретными фактами выше: И где именно вы признали свою ошибку? Чего-то не видно..... Может не будем переходить на личности? ok?

Категорически не использую ни PL2303 ни CH340. Исключительно только CP21xx и FTDI. Может поэтому и не сталкиваюсь с проблемами с USB-UART?

В те былинные доисторические времена я отлаживался исключительно с помощью лампочек и UART-а. А потом появилась внутрисхемная отладка и JTAG-и. Пришла цивилизация.

А причём тут англоязычные термины, если говорим о русскоязычном термине "эмулятор"? Впрочем и в англоязычном мире эти девайсы называются частенько также - "emulator". "Некоторые" - это кто? Открываем утилиту обновления прошивок от одного из ведущих мировых производителей отладочных эмуляторов - Segger. Видим: Видите слово "emulator"? И там этих слов много. Открываем его же документацию, читаем: Открываем сайт другого крупного и серьёзного производителя отладочных эмуляторов - Texas Instruments: https://news.ti.com/2013-08-08-TI-introduces-XDS200-JTAG-emulator,-providing-software-designers-a-mid-range-option-for-embedded-designs?keyMatch=emulator Также читаем: Достаточно? А ваш некривой, как переводит термин "emulator"? PS: С чудо-юдами не сталкивался наверное потому, что с PIC работал давным-давно и совсем недолго. А с x51 - и подавно.

Не понял... При чём бутлоадер, если речь об отладке? При отладке отлаживаемая программа грузится в память МК отладочным эмулятором. J-Link например. Бутлоадер тут не нужен. Не "прошивать", а "грузить". Вроде как очевидно: не насиловать лишний раз флешь (ресурс которого не бесконечен), и во-вторых - увеличить скорость работы (так как в ОЗУ грузится часто многократно быстрее). И кроме того: При компиляции и отладке программы в разных режимах, часто вылазят скрытые баги. Которые иначе не были бы замечены.

ACK в USB не может быть причиной задержки. Так как даже в FS-USB отправляется внутри того же 1мсек фрейма, что и сам кадр данных. Т.е. - в следующем USB-фрейме уже может идти следующий кадр данных. Что уж говорить о HS-USB с его 125мксек фреймами.... Имхо - задержки скорее всего из-за некорректной работы прикладной программы с Serial WinAPI. Или же в драйверах.

В первый раз о таком слышу. После четверти века работы с разными МК/DSP. А можно ссылочку/пруфы на такое диво дивное? Только - для каких-либо современных микроконтроллеров, а не времён царя Гороха. Да ладно! J-Link и St-Link - это как раз эмуляторы. Курите матчасть!

А зачем? Ведь через отладчик обычно отлаживают. Зачем для этого контрольная сумма? Но если сильно надо, то можно например где-то хранить флажок "присутствует CRC" и при старте прошивки читать его и, если он не установлен, то самой прошивкой и генерить. Или же делать это если CRC=0 (установленная в исходнике). PS: Вообще-то при отладке логично вообще никакую флешь не шить. Даже прошивкой, не то что её CRC. А отлаживаться в ОЗУ. Коего в вашем МК - как у дурака фантиков.

А в чём отличие? 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.