Comments 62
Есть еще один довольно любопытный тип советчиков - практик. Человек не пытающийся разобраться в теории процесса, а решающий проблемы исключительно методом тыка. То есть для приведённого примера его совет будет примерно в стиле "попробуй на обе линии i2c повесить по конденсатору на 22 пФ. Была у меня как-то подобная проблема, решилась таким способом". Что интересно - часто это люди, действительно имеющие огромный опыт. И иногда их советы почему-то помогают. Но в большинстве случаев - либо не помогают, либо приводят к сложно предсказуемой работе.
Да, это действительно прямо отдельный самобытный класс :)
Единственное, что я бы отметил: практик несмотря на свою анти-теоретичность зачастую действительно стремится помочь, а не показать себя при помощи сигнальных сообщений.
и ещё отдельный тип людей: "джедаи". те, которые дают советы, но сами не (непонятно) следуют ли им. они точно знают что делать в той или иной ситуации, но обычно это приводит к следующим проблемам, решение которых они точно знают, но решение обычно всё усугубляет, и ваше общение прекращается на этапе вызова скорой.
те, которые дают советы, но сами не (непонятно) следуют ли им
О-о, это вообще золотой стандарт :)
Практик, советующий "повесить 22 пф на шину", но никогда не вешавший их туда сам.
Монах, прочитавший из Хоровица и Хилла две главы и приказывающий всем прочитать их от корки до корки
Академист, оспаривающий определение термина до тех пор, пока ему не сообщают, что оно из IEC60050.
Классика.
"Суть ошибки в том, что при пропадании напряжения на подтягивающих резисторах интерфейса I2C, входные аналоговые фильтры модуля I2C «западают» в некоторое перманентное значение, и модуль I2C переключается в состояние BUSY, переставая реагировать на любые команды извне. Проблема усугубляется тем, что элементы встроенных аналоговых фильтров имеют значительный разброс параметров"
Что такое "«западают» в некоторое перманентное значение"?
Можно ссылку на схему этих входных аналоговых фильтров. И чуть подробнее о влиянии разбросов параметров их параметров в цифровых чипах. Очень интересно узнать что-то новое.
Прим: состояние BUSY в I2C это ноль на шине. Или Вы знаете иное?
У меня встречный вопрос: вы прочитали пункт 2.8.7 из документа ES096, ссыклу на который я привёл в начале того абзаца, который Вы обильно цитируете?
Отвечать вопросом на вопрос - это приём, когда человек не хочет отвечать на него.
Полагаю, Вы не поняли то, что прочитали.
«западают» в некоторое перманентное значение -это Вы тоже там прочитали.
Так зачем цитировать то, что не понимаете?
Вы выдернули из песни слова а дальше читали:
Обходной путь
Выходные данные аналоговых фильтров SCL и SDA обновляются после того, как происходит переход на линии SCL и SDA соответственно.
Переход SCL и SDA может быть принудительным с помощью программного обеспечения, настраивающего I2C I/Os в режиме вывода. Затем, как только
аналоговые фильтры разблокированы и выводят уровень линий SCL и SDA, флаг ЗАНЯТОСТИ может быть сброшен с помощью программного
сброса, и I2C может перейти в основной режим. Следовательно, необходимо применять следующую последовательность:
Отключите периферийное устройство I2C, очистив бит PE в регистре I2Cx_CR1.
Сконфигурируйте SCL и SDA I/Os как выходные данные общего назначения с открытым стоком, высокого уровня (запись 1 в GPIOx_ODR).
Проверьте высокий уровень SCL и SDA в GPIOx_IDR.
Сконфигурируйте ввод-вывод SDA как выход общего назначения с открытым сливом, низкий уровень (запишите 0 в GPIOx_ODR).
Проверьте низкий уровень SDA в GPIOx_IDR.
Сконфигурируйте ввод-вывод SCL как выход общего назначения с открытым сливом, низкий уровень (запишите 0 в GPIOx_ODR).
Проверьте низкий уровень SCL в GPIOx_IDR.
Сконфигурируйте ввод-вывод SCL как выход общего назначения с открытым стоком, высокого уровня (запишите 1 в GPIOx_ODR).
Проверьте высокий уровень SCL в GPIOx_IDR.
Сконфигурируйте ввод-вывод SDA как выход общего назначения с открытым стоком, высокого уровня (запишите 1 в GPIOx_ODR).
Проверьте высокий уровень SDA в GPIOx_IDR.
Сконфигурируйте SCL и SDA I/Os в качестве альтернативной функции Open-Drain.
Установите SWRST-бит в регистре I2Cx_CR1.
Очистите SWRST-бит в регистре I2Cx_CR1.
Включите периферийное устройство I2C, установив бит PE в регистре I2Cx_CR1.
Сначала разберитесь, а не несите вздор в массы.
--------------------
Я собрал кучу схем и особенно с I2C Интерфейс банально простой и никогда ничего не залипает, если Вы понимаете, что делаете, а не исполняете роль мартышки с очками.
О, вы прочитали пункт 2.8.7! Это - хорошо.
Следующие вопросы:
Зачем, на Ваш взгляд, нужны 15 пунктов воркэраунда, если "никогда ничего не залипает"?
Разобрались ли вы в схеме входных фильтров, которой в этой Errata нет?
Как вы понимаете фразу из этой Errata "Consequently, the I2C BUSY flag is set, and the I2C cannot enter master mode"?
А вот и академисты подтянулись... :)
в 2015 я ловил подобную проблему на STM32F4x. Ситуация проявлялась хаотично после нескольких часов работы в климокамере или во время тестов на статические разряды.
Оказалось что ошибка в... документации на I2C сороколетней давности. Если детально изучить автомат состояния, то можно обнаружить что если прилетит помеха, которую приемник I2C воспримет как синхробит, то автомат может оказаться в состоянии бесконечного ожидания следующих импульсов, которые не поступают потому что слейва ни о чем не спрашивали.
В спецификации Филипс всегда прямо указывалось что I2C шина исключительно внутриплатная. У нас же сплошь и рядом делают её межплатной.
Ситуацию разрулили программно. Просто если обнаруживаем проблемы на шине, то переводим ножки в режим GPIO (софтверно имитируем окончание передачи для слейва), а потом опять в режим I2C.
Написал ли я об этому на какой-нибудь форум? Конечно же нет. Я думаю что если вы тратите на подобное больше 20 минут в неделю, вы делаете что-то не так. В том чтобы найти подобную ошибку нет ничего героического. Это проблемы производителя чипов и нужно сообщить ему. Не нужно стесняться нужно сразу садиться к нему на шею и бомбить техподдержку запросами. Они легко идут на контакт. Можно высыслать им дизайны схемы и даже свои электронные платы в их лаборатории.
ловил подобное на PIC32MZEF, думал что я уже разучился =) В итоге перешли на PIC32MZEM (там этот баг устронили)
подключаю датчики по этой шине на расстояние до 10 метров и все работает
А указанная Вами проблема решается с помощью тайма ожидания ответа.
Если за установленное время ответа нет, то делается сброс шины.
Вопрос на чём будет обучен Chat GPT. А то выйдет нейросетевой монах.
Но знающий Хоровица и Хилла наизусть.
"Хоровиц и Хилл" это для меня отдельный юмор. Я встретил за жизнь только одного разработчика который как и я решал по книжке задачи. Оказалось что русский текст переводился какими-то студентами и вредителями и без заглядывания в английский оригинал решить ничего не возможно. Просто чудовищное количество ошибок.
Отсюда делаю вывод - все кто хвалит или закатывает глаза книгу не изучали, а только разглядывали картинки.
Спасибо, посмеялся.
I2C действительно очень своеобразная (багастая) шина и описанный эффект "залипания" (I2C hog) может быть вызван не только ведущим устройством (микроконтроллером), как описано в статье, но и любым ведомым если его схема сбороса недостаточно хорошо продумана (в большинстве случаев это RC цепочка). А так как ведомых устройств на шине бывает много, "определить кто виноват и что делать" бывает очень и очень затруднительно.
Пример из жизни. В нашем процессорном модуле RanetkaPC есть несколько шин I2C, одна из которых очень часто подвешивается при перезагрузке, да та так что сброс по питанию не всегда помогает. Долгими и упорными ночными бдениями выяснилось, что на этой шине сидит, среди прочих устройств, аудио-кодек, он-то шину и завешивает при сбросе. Проблема решилось добавлением диода Шоттки в цепь сброса аудио-кодека: от конденсатора на линию питания, для того, чтобы при отключени питания конденсатор оперативно разряжался, а не удерживал ведомое устройство в непонятном состоянии.
Спасибо, посмеялся.
Всегда пожалуйста :)
Спасибо вам за любопытный кейс.
По стандарту сброс шины возможен 9 импульсами по SCL - вы пробовали такой вариант?
Поскольку в ведомых устройствах крайне редко используется SCL stretching и еще реже возможно зависание в этом состоянии, это всегда помогает (в моих устройствах) . И возможно это более правильно, чем 22пФ на шину Шоттки. )
В голосовании надо разрешить множественный выбор.
У меня есть подобная подборка диалогов экспертных сообществ обсуждающих тему на стыке того чем все они занимаются, при том что между всем этим есть темная буферная зона, которую они не пересекали, или не подозревали о наличии таковой. Смотрят на это как на НЛО. Причем они традиционно сами между собой стоят по разные стороны баррикад, это ПЛК-шники и эмбеддеры. Тема НЛО никому не понятна и у всех набор своих прутензий и критики. После демонстрации им технологии в работе, по каждому замечанию, они молчат, а монах откровенно хамит, или страсти переходят в заявления - диво дивное, прикольненько, но что с этим делать не понятно, мне оно точно не нужно, причем с изрядной долей не аргументированного сарказма.
Есть еще один вид советчиков: ОФИЦИАЛЬНАЯ ТЕХПОДДЕРЖКА.
Их советы звучат так: "Обновите драйвер, поставьте последние обновления системы, проверьте систему на вирусы".
Пример. Существует такая звукокарта Focusrite 18i6, она всем хороша, кроме того, что... иногда подвисает. Т.е. может прекратить воспроизвоить звук на половине песне. Несколько лет толпы людей страдали, обсуждали на форумах, и рекомендовали друг другу различные способы танцев с бубном, ну там - активный USB-порт, укороченный шнур, и т.п... А техподдержка... писала то, что выше!
(Потом производитель таки выпустил новую версию драйверов и... всё стало лучше, но появилась новая неприятность - система стала иногда фризиться, а выключаешь звукокарты - и норм. Пока думаю связано с банальным перегревом).
Программист на SystemVerilog
Я звоню в полицию! :D
На самом деле острая реакция HDL-щиков на этот термин связана не с формальной терминологией а с неиссякаемым потоком убеждённых в том, что просто подправить синтаксис С-кода до формального соответствия SV - это единственное что нужно чтобы получить работоспособный RTL.
И ладно бы они делали эту ошибку один раз, по незнанию. Но не счесть случаев, когда пациент надевает каску из фразы "у меня в симуляторе работает" и дальнейший диалог развивается по шаблону "как сварить яйцо в микроволновке". И вот как раз такие пациенты употребляют термин "программист на Верилоге" достаточно часто чтобы выработать соответствующий рефлекс у тех, кто разницу между симулятором и аппаратной реализацией отчётливо понимает по долгу службы.
Согласен с вами. Ведь если посмотреть не на один пункт из спецификации SystemVerilog окажется что в ней есть две части. Синтезируемое и не синтезируемое подмножество. Одно для реализации цифровых схем, другое для использования в симуляции. И конечно синтезируемое подмножество поддерживается симуляторами, но синтезатор не поддерживает преобразование несинтезируемого подмножества в цифровую логику.
И получается что есть HDL-инженеры которые в первую очередь пишут код на SV для реализации конкретного дизайна. А с другой есть верификаторы где конечно используются и классы и программные модели. И действительно верификационное окружение можно считать программным продуктом которое проверяет соответствие дизайна спецификации. Даже вот есть, например cocotb использующий python, более доступная вариация инструмента для верификации вместо SV. Но еще с кучей ограничений и более медленный!
И если программист перейдет в разработку цифровой электроники ему легче стать верификатором и делать эффективные верификационные решения, чем проектировать и писать дизайн который пойдет в чипы.
Какая-то мифологизация. Больше двадцати лет разрабатываю электронику, в частности, самостоятельно освоил AVR и STM32, общение на специализированных форумах всегда было крайне спокойным и информативным.
И кстати, Errata надо читать до Datasheet, на этапе выбора МК.
И кстати, Errata надо читать до Datasheet, на этапе выбора МК.
И машина времени для получения Errata из будущего должна входить в комплект оборудования любого эмбеддера.
Понимаю ваш сарказм, но не разделяю его. Я действительно читаю документацию на МК в порядке Brief - Errata - Datasheet (выборочно) - Reference Design - Reference Manual (выборочно) - App Notes. Конечно, возможна ситуация, когда МК совсем свеженький, без Errata, но надо ли закладывать такой МК в серийное изделие?
Какая-то мифологизация. Больше двадцати лет разрабатываю электронику, в частности, самостоятельно освоил AVR и STM32, общение на специализированных форумах всегда было крайне спокойным и информативным.
Назовёте два примера специализированных форумов, о которых вы говорите?
По моему глубокому убеждению. Чуть из другой отрасли, но все-же.
Книги, в большинстве случаев, оцениваются по следующему алгоритму: у меня было описываемое или не было. Если было - надо почитать, если не было, но может быть - тоже надо отложить и прочитать. В остальных случаях книга - фуфел.
Масса знаний есть у большинства. Большая часть возникающих вопросов - некие граничные вещи. Поэтому и начинаешь выходить за рамки личного багажа знаний. Само по себе это не плохо. А для тех, у кого эти знания основные - вызывает раздражение и иногда неадекватные ответы.
Мой личный опыт. Я веду кучу личный файликов - типа "полезности тепло", "полезности пожарка" и т.д. Куда запихиваю материалы по стыковке разных разделов, отдельные нормативные кусочки, которые следует учесть, и всякую полезность, которая может пригодится. По мере возможности - со ссылками на источник. очень помогает в сложных ситуациях разрулить и понять кто прав.
Хорошо бы теперь вопрошающих так же подробно классифицировать. Первый тип, пожалуй "Эрраты не читай, вопрос задавай" :)
В рамках данной дискуссии, любопытно было бы узнать, какого типа вопросы Вы считаете достойными ответа Монахов (именно они обычно красуются фразами "Эрраты не читай, вопрос задавай")?
Просто, как было написано в самом начале статьи:
Академические курсы не всегда успевают за прогрессом. А их первоисточник — техническая документация — бывает крайне обширна. Например, базовая документация на микроконтроллеры STM32F103xB насчитывает 1252 страницы. Помимо неё имеются ещё 54 документа типа application note и десятка полтора документов других типов. Поэтому достаточно востребованным источником знаний оказываются профильные сообщества.
Именно эти причины являются основой существования Монахов. Думаю, Вы согласитесь: если некий идеальный вопрошающий прочитал всю Википедию каждую эррату, каждый апноут и практически наизусть знает юзер мануал, то советы от Монахов (как и сами Монахи) ему, банально, не нужны. Потому, что при возникновении проблемы такой вопрошающий пойдёт не к "мудрому" Монаху, а в официальную техподдержку.
Во-первых, мой пост был о том, что развешивать ярлыки можно с обеих сторон. И раз уж вы "пересчитали" отвечающих, было бы справедливо так же остроумно и ёмко обозвать вопрощающих.
Во-вторых, раз уж вас это так задело (о причинах можно только догадываться), отвечу по существу.
Разработчик железа в первую очередь читает даташит, во вторую - эррату, в третью - юзер мануал и аппноты. Программисту микроконтроллера желательно делать то же самое, но подробности из даташита ему обычно не очень нужны. По этому первым документом для вдумчивого чтения должна быть эррата. А уж тем более при непонятных программно-аппаратных ошибках (а в аппаратуру он уже залез, меняя номиналы подтяжек).
Хороший тон - задавать вопрос, когда доки и гугл не помогли. Оправдание объёмом мануала в 1252 страницы - не оправдание. Кто-то же их читает, раз может дать ответ на форуме. К тому же, часть про I2C страниц 20, не больше. И "каждую" эррату читать не обязательно, достаточно только ту, которая относится к микроконтроллеру. А она обычно совсем на 1252 страницы.
К сожалению, тенденция такая, что вопрошающих, но не читающих (даже не гуглящих) становится только больше.
Во-первых, мой пост был о том, что развешивать ярлыки можно с обеих сторон.
Если говорить вашими словами, то ярлыки с той стороны развешаны 22 года назад в руководстве "Как правильно задавать вопросы на технических форумах". Я убеждён, что "было бы справедливо так же остроумно и ёмко" указать на то, что и отвечающие далеко не всегда святые.
Хороший тон - задавать вопрос, когда доки и гугл не помогли
Возвращаясь к моему вопросу: задавать вопрос кому? Официальной техподдержке или эксперту из сообщества?
Если техподдержке, то зачем нужны эксперты и сообщества?
Если эксперту, то что сверх того, что написано в официальной документации может сообщить эксперт? Свои предположения и домыслы о недокументированных особенностях того или иного изделия? А что в них ценного, в этих предположениях и домыслах, раз он не является ни разработчиком конкретного изделия, ни официальным лицом?
то ярлыки с той стороны развешаны 22 года назад в руководстве "Как правильно задавать вопросы на технических форумах".
Не вижу ярлыков и осуждения в этой прекрасной статье. Только объективные рекомендации.
что сверх того, что написано в официальной документации может сообщить эксперт?
Опыт. Ведь за этим люди сидят на форумах, для обмена опытом.
И не нужно впадать в крайности. Между "прочитать эррату" и "прочитать 1252 страницы и всю Википедию" - пропасть. И отношение отвечающих в этих случаях будет совершенно разное. Одно дело не очень внимательно прочитать мануал, и совсем другое полениться придумать вопрос для Гугла.
Опыт.
О-о! Здесь хотелось бы поподробнее :) Что Вы подразумеваете под опытом и чем Ваш опыт, на Ваш взгляд, может быть кому-то полезен? Хотелось бы услышать пример. Можно - реальный, можно - воображаемый.
Ну или предположим, что вы Эксперт С Опытом, а у меня возникла проблема с неким устройством. Я прочитал всю-всю-всю документацию (прежде чем заговорить с Экспертом С Опытом) - ответа не нашёл. Вопрос, зачем мне Ваш опыт? В рамках взаимной психотерапии? :) Послушать, как у вас тоже не заработало, обняться и поплакать? :)
чем Ваш опыт, на Ваш взгляд, может быть кому-то полезен?
А ваш? Вот конкретно эта статья несёт какую практическую ценность, кроме почесания вашего собственного ЧСВ? При этом, ваши технические статьи весьма хороши, я даже несколько в закладки добавил.
При этом, ваши технические статьи весьма хороши, я даже несколько в закладки добавил.
Спасибо :) Черт побери, это всегда приятно слышать :) Можете, к слову полайкать мои две предыдущие технические статьи и поднять мне карму, раз такое дело. )))) И ещё подписывайтесь и ставьте лайки. И оставляйте Ваши комментарии )))))
- чем Ваш опыт, на Ваш взгляд, может быть кому-то полезен?
- А ваш?
Я считаю свой опыт полезным в связке с умением донести его в удобочитаемой и концентрированной (сжатой) форме.
Когда мне пишут комментарии вроде
Пользуясь отладчиком, всегда была интересно: "что происходит внутри микросхемы?". БОльшая часть статей, как вы и упомянули, написана так, что терпения и желания дочитать даже до середины не хватало:)Отличная статья, все красиво нарисовано, описано буквально по шагам - очень жду продолжения цикла;)
...я понимаю, что я на верном пути.
Вышеприведённый комментарий оставлен под статьёй про JTAG. Можно сказать "Ну и зачем эта статья, ведь есть же стандарт. Нужно не лениться и прочитать (а лучше - вызубрить) его". Но я с подобным буду категорически не согласен.
Смотрите, Вы упираете на необходимость досконального чтения документации. На мой (субъективный и претенциозный) взгляд, если абсолютизировать данный подход, то в мироздании не остаётся места для профессиональных сообществ. Вся электроника, все её компоненты, все её технологи, на мой субъективный взгляд делаются людьми и для людей. Здесь нет места и для какой-то науки (науки "переднего края", разумеется). "Опыт", о котором Вы говорите, в контексте Вашей мм... гипотезы становится замкнутой в специалисте сущностью. Ну зачем нужен ваш уникальный опыт, когда есть документация и есть техподдержка?
Если у Вас есть чем подкрепить Ваши соображения - я с радостью их почитаю. Статья-то и задумывалась, как дискуссионная. Отшифруйте, что вы имеете ввиду, говоря слово "опыт". И какое место в электроники занимает этот "опыт" на Ваш взгляд.
Смотрите, Вы упираете на необходимость досконального чтения документации.
Нет, я упираю на хотя бы попытки её чтения. И обижаться на посылку в RTFM не стоит, если это действительно так.
если абсолютизировать
Не нужно.
И нет у меня никакой гипотезы, я просто сказал, что ярлыки - это плохо, и делить всё на чёрное и белое (монахов и каких-то там ещё сказочных персонажей) тоже неправильно. И если уж разделили одних, то делите и других, для баланса. Инь и Янь, в конце концов.
И обижаться на посылку в RTFM не стоит, если это действительно так.
Вариантов получить проблему всего три:
Вы не прочитали документацию
Вы прочитали документацию, но ошиблись при реализации её положений на практике
Проблема заключается в недокумнтированной работе устройства
Во всех трёх случаях сообщество может помочь. С другой стороны, объективно, во всех трёх случаях можно обойтись без сообщества и экспертов с их ценным опытом. С третей - запросив помощь у сообщества, вы можете услышать от "эксперта", что вам можно обойтись и своими силами. Ну можно, да. Всегда можно. Абсолютно всегда. Вопрос, зачем нужны "эксперты" и подобные "ценные" мнения остаётся открытым.
И нет у меня никакой гипотезы, я просто сказал, что ярлыки - это плохо, и делить всё на чёрное и белое тоже неправильно
Я так понимаю, что от дискуссии Вы вежливо отказываетесь, переходя к тезисам "за всё хорошее". Ну ладно.
объективно, во всех трёх случаях можно обойтись без сообщества и экспертов с их ценным опытом
Это будет самый лучший вариант, как для одной стороны, так и для другой.
Я так понимаю, что от дискуссии Вы вежливо отказываетесь
А смысл? Всё, что хотел, я сказал в первом сообщении. Переливать из пустого в порожнее не очень хочется.
Это будет самый лучший вариант, как для одной стороны, так и для другой.
Тогда при подобном подходе одна сторона (инженеры с их техническими проблемами) останется, а другую сторону (экспертные сообщества) можно навсегда закрывать за ненадобностью.
При обратном подходе будет то же самое. Экспертное сообщество выродится в чат чайников, т.к. эксперты устанут отвечать на вопросы, ответы на которые можно найти во второй строке поиска гугла.
А чтобы этого не было, нужно уважительно относиться друг к другу (и не развешивать ярлыки друг на друга). И это большей мере касается вопрошающего, потому что он просит об услуге, а эксперт никому ничего не должен.
[здесь должна была быть фотография дона Карлеоне]
А чтобы этого не было, нужно уважительно относиться друг к другу (и не развешивать ярлыки друг на друга)
Тут вот какое дело. В упоминаемой замечательной статье "Как правильно задавать вопросы в технических форумах" есть, например, это:
Таких людей мы называем "неудачниками" ("losers") (по историческим причинам это слово иногда пишется как "lusers" - пользователи-неудачники)
Или это:
Быть грубым - нормально
Или это:
приходится безжалостно "фильтровать базар"
И я, в целом, согласен с подобной жёсткой тональностью данной статьи - сам стараюсь формулировать вопросы согласно ей. Но что прикажете делать, если вопрос был сформулирован качественно, а в ответ - полнейший мусор (к примеру, на Вас выпрыгивает Первый! )? Есть ли повод относиться к дурным советчикам как-то иначе, чем к дурным вопрошающим? На мой взгляд - нет. На мой взгляд подобные советчики вырождают сообщество в чат чайников не хуже, чем плохие вопрошающие, о которых вы говорите.
О-о! Здесь хотелось бы поподробнее :) Что Вы подразумеваете под опытом и чем Ваш опыт, на Ваш взгляд, может быть кому-то полезен? Хотелось бы услышать пример. Можно - реальный, можно - воображаемый.
Опыт -- набор навыков и знаний, полученных в ходе решения проблем, а также кругозор. Такое пойдёт?
Например, при поднятии сетевых интерфейсов в FPGA человек может столкнуться с широким спектром проблем, которые можно дебажить неделями. В мануале на корки, например трансиверы, конечно, в общем виде описано, куда копать. Но там полно частностей, на которые можно потратить много времени не умеючи.
А иногда ответы на вопросы лежат совсем не там, где человек ищет. И дело может быть не в человеке, а в неадекватной структуре некоторых мануалов, глюках сред разработки, ОС, ошибках разводки плат и т.д. и т.п.
Всё же чужой опыт хождения по граблям способствует прогрессу, не надо его обесценивать.
В мануале на корки, например трансиверы, конечно, в общем виде описано, куда копать. Но там полно частностей, на которые можно потратить много времени не умеючи. <...> И дело может быть не в человеке, а в неадекватной структуре некоторых мануалов, глюках сред разработки, ОС
Именно это я имею ввиду. Именно об этом-то я и толкую. По сути, опыт, нормальный опыт (а не вышеприведённый "киньте 22 пФ и всё починится") опирается исключительно на документацию. Кто больше знает больше документации, тот более опытен - всё просто.
Поэтому, говоря "Фуууу, даташит прочитал, а эррату не прочитал" или "Чего ты спрашиваешь здесь, почитай лучше документацию", сам говорящий, по-сути (ну вот, лично для меня), автоматически заменяет себя не то, что на Chat-GPT или даже на скрипт, а просто на лозунг. Человек-лозунг :) Пользы от него мм... я даже не знаю. Пожалуй, что - никакой.
Именно это я имею ввиду. Именно об этом-то я и толкую. По сути, опыт, нормальный опыт (а не вышеприведённый "киньте 22 пФ и всё починится") опирается исключительно на документацию. Кто больше знает больше документации, тот более опытен - всё просто.
Не соглашусь. Вот например корка имеет два варианта интерфейсов X и Y. Среда генерит корку под Х нормальную, а под Y -- с неправильным направлением одного порта. По документации -- всё норм, корке без разницы с какими интерфейсами её юзают. А по факту Y в этой версии использовать нельзя. Если точились на него -- переделывайте.
Или корка генерит неправильную обёртку, заменяет STD_LOGIC порты на STD_LOGIC_VECTOR(0 downto 0). Вляпавшись в это ранее, опытный человек уже будет знать, что обёртку можно исправить и всё будет работать. А не зная, первый раз придётся до этого дойти. Доки опять молчок про это.
корка имеет два варианта интерфейсов X и Y. Среда генерит корку под Х нормальную, а под Y -- с неправильным направлением одного порта.
Формально, путь стандартен: техподдержка -> эррата -> багфикс в одном из следующих релизов. Формально, на этом пути сообщество нигде не фигурирует. В реальности вендоры регулярно заморачиваются налаживанием симбиоза с сообществом, но об этом я бы хотел написать отдельно.
«X — это <определение X, скопированное из Википедии>. А Y — это <определение Y, скопированное из Википедии>. Кстати, по ссылкам <ссылки на статьи Википедии про X и Y> вы можете ознакомиться с данными сущностями более подробно»
я прочитал про молоко и селедку пряного посола, но вопрос их совместного употребления так и остался нераскрыт
Об особенностях электротехнических (и не только) сообществ: вредные советы