serglg

в последней плате на STM32 вспомнил старый метод, который исправно применял 20 лет назад. И который потом позабыл по причине устойчивости моих МК от Зилога (Z8Encore). А именно конденсатор параллельно выходу оптрона. У оптрона ж проходная емкость в доли пФ. И при разности потенциала в импульсе в несколько сотен вольт на ножке МК может вывалиться импульс вполне приличной амплитуды. Теперь буду ставить 1000 пФ на оптрон.

Печальный опыт есть. Ладно там, когда подаешь на ножку 30 вольт. Понятно дело. Но даже и тут. У какого-нить МК от Зилога (типа Z86E030) выгорает только эта ножка. А к примеру STM32F030 выгорает полностью. Уходит в КЗ по питанию. Для себя понял, что надо изолировать МК вчистую. Не помогут ни конденсаторы, ни последовательные резисторы, ни всякие там диоды на питание/землю.

Недавно такое у меня случилось. :-( Одна ножка оказалось мертвой при первом включении. К ножке подключен выход оптрона с последовательным резистором в 300 Ом. И выход оптрона подтянут к питанию через 3,3 кОм.

Первый совет у любой техподдержки - выключите устройство и опять включите. :-)

Думаю,что как и 20 лет назад в 8-битниках основной объем всех программ - тексты, таблицы и проч. А сейчас - заготовки графики, анимаций и проч. И всё это прекрасно хранится в spi flash. :-)

я как-то изначально на разных STM32 всегда использую DMA ADC. И именно циклический опрос. Настроил, запустил и только заглядывай в массив где хранятся последние считанные данные. Но конечно все процессы у меня обычно медленные, нигде речи нет о привязки уровней с точностью до микросекунд.

Для меня ножки SWCLK и SWDIO мертвые всегда изначально и везде. Это как NRST. Потому даже в голову их не беру.

Цитата(KnightIgor @ Apr 30 2018, 21:08) Сплошная печаль, короче. Когда мне в руки попался F051, я просто прыгал от восторга, запустив его I2C за часика два (с перерывами на напитки). Когда я после ногодрыга для I2C на Z8 впервые запустил аппаратный I2C на STM32L476, то вообще ничего не заметил. :-) Потому что Куб всё сгенерил, я вставил HAL-строки и всё. Память 64К пишется, читается.

Цитата(aaarrr @ Apr 30 2018, 01:21) Да для обоих подойдет. Только так и делаю. У меня нет ни времени ни желания искать обходы для 100500 аппаратных глюков модулей I2C на дюжине используемых платформ. Софтовый же абсолютно надежен и предсказуем, там не приходится ждать приколов типа "мы не поддерживаем clock stretching и repeated start". Все вышесказанное, разумеется, относится к режиму master. Единственный приличный аппаратный контроллер I2C, который я встречал, использовался в мелких AVR типа ATmega48 и процессорах LPC13xx (автор один). Вот там можно было смело полагаться на железо. Забавно. :-) А я столько лет переживал, что в 8-битнике Z8Encore всегда использовал софтовый I2C. Хотя там уже 15 лет как был аппаратный (начинал я еще в 1995, когда его не было). Я всё никак не мог разобраться там с мудреными регистрами и тупо дергал двумя ножками. Там всё понятно. И вот достиг наконец в STM32 аппаратного. Рад был до безумия. Всё прекрасно уже 3-й год. И вдруг оказывается там могут быть проблемы. :-( Кстати, проблем нет у меня ни в STM32L476, ни STM32F446. Ни под дебаггером Кейла 5, ни потом в работе. Но! В последней версии HAL 1.11 для STM32L476 какой-то глюк - вообще память по I2C не работает. Цитата(Allregia @ Apr 29 2018, 20:12) это коллега тут возится с девайсом на STM32L452 и жалуется. Просил спросить: Для тактирования используется MSI + PLL. I2C настроен на 400кгц, тактируется от системного клока. На одной плате, запускаешь под дебаггером - есть 400кгц. Включаешь ее без дебаггера - там около 40кгц. Из 5-ти плат, так ведет себя одна, 4 другие в - вообще кто в лес, кто по дрова. ТЕперь самое интересное - для проверки "на какой- частоте проц работате," вывели махание ножкой в систике - так там четко, 1мс. Есть идеи? Если у него HAL и версия STM32Cube_FW_L4_V1.11.1, то может быть что угодно. :-) А вот STM32Cube_FW_L4_V1.8.1 - всё нормально. У мня для STM32L476 тактирование как раз MSI + PLL.

я как-то точно оставлял точки останова при отладке, потом штатно выходил, отключал СТ-Линк. Потом запускал устройство и оно работало адекватно, не висло в предполагаемых местах остановки.. Отлаживал Кейлом.

Цитата(adnega @ Mar 28 2018, 11:38) Научитесь читать на техническом английском, и перед вами откроются многообещающие перспективы. Еще освоить сам язык Си.

и куда ж такому "программисту" как я податься? :-) Вот и вынужден пользоваться только чужими достижениями.

Цитата(Lagman @ Mar 22 2018, 21:12) А лет так цать назад какой нибудь программист думал и зачем ему какой то ассемблер с компилятором если он сам умеет писать в машинных кодах и все работает. Мы так для К580ИК80 писали программы в 1982 году. :-) Точнее так. На бумажке всё же мнемокоды. Потом рядом столбиком переводили в HEX-код, который уже вручную вписывали в память.

Цитата(SasaVitebsk @ Mar 20 2018, 20:17) Но я у себя в проекте, к примеру, запускаю кварц - проверяю - не запустился - запускаю HSI настраиваю PLL - выставляю признак ошибки оборудования. Аналогично поступаю с RTC кварцем. По крайней мере, на момент написания проекта, в библиотеках ST этого не было. Когда у меня были проблемы с кварцем 32768, то HAL меня прекрасно тыкал носом - "LSE не запустился". Сразу вваливался в ошибку (соответственно начинаю мыть плату :-)). Вы про это?

По даташиту вроде просто. Если после команды антиколлизии CL1 (0х93) в ответе из 5 байт первый 0х88, то значит ID - 7-байтный. И надо считать еще 4 байта командой CL2 (0x95). А вот ни фига не выходит. Не отвечает вообще на 0х95. Кто-нибудь пробовал достать 7 байт?