![](https://electronix.ru/forum/uploads/set_resources_23/84c1e40ea0e759e3f1505eb1788ddf3c_pattern.png)
![](https://electronix.ru/forum/uploads/set_resources_23/84c1e40ea0e759e3f1505eb1788ddf3c_default_photo.png)
jcxz
Свой-
Постов
13 619 -
Зарегистрирован
-
Посещение
-
Победитель дней
38
Весь контент jcxz
-
Плавный переход C -> C++ под МК
jcxz ответил Arlleex тема в Программирование
Я же вроде писал: См.выделенную часть цитаты. Перегруженная операция приведения типа как раз и должна заменить свойство чтения борланда. Клацаете настолько быстро, что даже вопрос, на который отвечаете, не успеваете полностью прочитать? -
Это только для самых узких полос нужно. 7.8кГц, 10.4кГц, ... На ~20.8кГц, ~31.25кГц уже вроде как и точности обычного кварца должно хватить. К тому же - неизвестно какой у вопрошающего требуемый температурный диапазон работы.
-
Плавный переход C -> C++ под МК
jcxz ответил Arlleex тема в Программирование
Разве перегрузка операторов присваивания и приведения типа - не оно? Конечно запись их определения будет не такой компактной (может даже дополнительные типы данных придётся создать), но конечный результат вроде должен дать примерно то же самое. -
Конечно - сужать полосу. Сами же пишете. И при этом почему-то выбрали самые широкие полосы. Можно же вплоть до 7800Гц сужать. Чем уже полоса - тем более компактно сосредоточена энергия сигнала и меньше помех влетает в более узкую полосу. Соответственно - больше дальность.
-
Прошу помощи в разработке энкодера колеса мыши
jcxz ответил Darmok тема в Схемотехника
У КР580ИК80 все сигналы/шины торчат наружу. Память - тоже снаружи. Также имеются подробные описания диаграмм работы всех этих шин/сигналов. А значит вполне возможно взять любой МК, подключиться им к шинам/сигналам КР580ИК80 и написать программу на МК, которая будет анализировать передаваемые по шинам данные, выдавать управляющие сигналы (HALT и т.п.) на КР580ИК80. И реализовать все необходимые функции отладочного эмулятора: Просмотр содержимого регистров/памяти (по захваченным и сохранённым с шин данным), breakpoint-ы (анализируя адрес выбираемой из памяти команды и остановку в нужный момент) и т.д. Т.е. - сваять собственный J-Link для КР580ИК80. Если знакомый хоть немного умеет программировать микроконтроллеры (а он должен это уметь), то такое сделать несложно. Да даже на абдурине можно слепить. Если конечно овчинка стоит выделки..... -
Прошу помощи в разработке энкодера колеса мыши
jcxz ответил Darmok тема в Схемотехника
Разве в тех мамонтах были какие-то отладочные интерфейсы? Насколько помню - там была возможность потактового исполнения с помощью сигнала HALT (или как-то так назывался). По-крайней мере были учебные стенды, которые позволяли пошагово выполнять программу. И можно захватывать передаваемое по шинам процессора. Но вот - как смотреть содержимое регистров процессора и ячеек ОЗУ? не ясно.... Имхо: ему наверное будет лучше воспользоваться каким-либо программным симулятором i8080. -
Прошу помощи в разработке энкодера колеса мыши
jcxz ответил Darmok тема в Схемотехника
"Ошибки" никакой нет. Не несите чушь. Дальше то что??? Значит для вас STM - истина в последней инстанции. В том числе почему-то и в вопросах русскоязычной и англоязычной терминологии. Это странно. Но это ваше личное дело. Каждый сходит с ума по своему. Называю и впредь буду называть J-Link и St-link и т.п. - отладочными эмуляторами. Вопрос закрыт. -
Прошу помощи в разработке энкодера колеса мыши
jcxz ответил Darmok тема в Схемотехника
А в чём ошибка то? которую нужно признать. Вот 2 ваших ложных высказывания, которые я опроверг конкретными фактами выше: И где именно вы признали свою ошибку? Чего-то не видно..... Может не будем переходить на личности? ok? -
Категорически не использую ни PL2303 ни CH340. Исключительно только CP21xx и FTDI. Может поэтому и не сталкиваюсь с проблемами с USB-UART?
-
Прошу помощи в разработке энкодера колеса мыши
jcxz ответил Darmok тема в Схемотехника
В те былинные доисторические времена я отлаживался исключительно с помощью лампочек и UART-а. А потом появилась внутрисхемная отладка и JTAG-и. Пришла цивилизация. -
Прошу помощи в разработке энкодера колеса мыши
jcxz ответил Darmok тема в Схемотехника
А причём тут англоязычные термины, если говорим о русскоязычном термине "эмулятор"? Впрочем и в англоязычном мире эти девайсы называются частенько также - "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. Или же в драйверах.
-
Прошу помощи в разработке энкодера колеса мыши
jcxz ответил Darmok тема в Схемотехника
В первый раз о таком слышу. После четверти века работы с разными МК/DSP. А можно ссылочку/пруфы на такое диво дивное? Только - для каких-либо современных микроконтроллеров, а не времён царя Гороха. Да ладно! J-Link и St-Link - это как раз эмуляторы. Курите матчасть! -
А зачем? Ведь через отладчик обычно отлаживают. Зачем для этого контрольная сумма? Но если сильно надо, то можно например где-то хранить флажок "присутствует CRC" и при старте прошивки читать его и, если он не установлен, то самой прошивкой и генерить. Или же делать это если CRC=0 (установленная в исходнике). PS: Вообще-то при отладке логично вообще никакую флешь не шить. Даже прошивкой, не то что её CRC. А отлаживаться в ОЗУ. Коего в вашем МК - как у дурака фантиков.
-
Прошу помощи в разработке энкодера колеса мыши
jcxz ответил Darmok тема в Схемотехника
А в чём отличие? 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) из внешней памяти. Значит прошивка однозначно во внешнем чипе.
-
Прошу помощи в разработке энкодера колеса мыши
jcxz ответил Darmok тема в Схемотехника
Откуда инфа? Можно пруфы? На сайте STM не вижу NRND: Наверное им ещё не сообщили. Да и какая разница - рекомендованы или нет? если они продаются и ещё долго будут продаваться на али. Речь ведь не о серийном производстве. А для x51 есть эмуляторы? Можно ссылку? И архитектура у STM8 поудобнее, чем у x51. Если писать на асме. -
Прошу помощи в разработке энкодера колеса мыши
jcxz ответил Darmok тема в Схемотехника
Помнится (из 90-хх), что в некоторых мышах шарики были металлические. Без резиновой оболочки. Такие не должны разложиться. (разве что поржаветь ) Хотя - из чего сделаны внутри ролики (которые крутит шарик)? вопрос. Возможно, что они обрезиненные в таких мышках. В мышах с обрезиненным шариком, ролики внутри были пластиковые. -
Прошу помощи в разработке энкодера колеса мыши
jcxz ответил Darmok тема в Схемотехника
Я же предлагал не "поднимать", а "взять готовый, уже поднятый". И даже написал - где можно взять. Даже для начинающего это должно быть несложно. PS: IAR-овские примеры имеют свойство работать "из коробки". -
Документация на USB Power Delivery 3.0
jcxz ответил jcxz тема в Документация
Ещё может зарядка или кабель от какой-то старой версии стандарта PowerDelivery. Может есть какая-то несовместимость по версиям PD? -
Прошу помощи в разработке энкодера колеса мыши
jcxz ответил Darmok тема в Схемотехника
Где-то читал, что это - миф. Никакого угасания из-за собственно только возраста нет. Угасание происходит из-за неиспользования этих самых функций мозга (как и любая другая функция организма - если не используется, то атрофируется со временем; природа не любит ненужных излишеств). Большинство пенсионеров просто не хотят изучать ничего нового, отсюда и угасание функций их мозга. Тогда можно идти двумя путями: Взять простейший МК (несложный для изучения) и реализовать схему мышки на нём, подключив к нему датчик перемещения и кнопки. Выдавая наружу через UART. Не знаю - что за датчики перемещения стоят в оптических мышках. Но думаю их вполне возможно подключить к обычному МК. В качестве удобного МК думаю вполне подойдёт STM8: он имеет минимальный набор стандартной периферии, периферия у него простая, код пишется на си, есть эмуляторы. И сам STM8 и эмуляторы к нему - дешёвые. Сделать преобразователь интерфейсов: На какой-либо плате с МК (с USB) поднять USB-хост, воткнуть в него мышку и все получаемые от неё данные пересылать на любой порт этого МК (UART например). Если начинающий, то: Ставим IAR for ARM, в списке примеров идущих с ним в комплекте есть примеры USB-хостов для мышки для разных МК. Выбираем один из этих МК. Запускаем и изучаем проект. Изучив проект, можно найти в нём данные получаемые от мыши и немного доработать его, чтобы эти данные далее пересылались на какой-то интерфейс МК (UART). Имхо - 2-й путь лучше. Так как даёт возможность использовать любые готовые мыши. Выдержка из readme.txt одного из таких IAR-овских демо-проектов для мышки: Т.е. - если его запустить, думаю будет несложно найти откуда вытащить нужные данные, чтобы переслать их в UART. PS: А лазерный утюг, да ещё с DIP - это тупиковый путь. Как уже сказали выше... -
Документация на USB Power Delivery 3.0
jcxz ответил jcxz тема в Документация
Не должно такого быть. Стандарт не дураки писали, поэтому такую ситуацию конечно предусмотрели. У приёмника энергии 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.