Таких людей мы называем "неудачниками" ("losers") (по историческим причинам это слово иногда пишется как "lusers" - пользователи-неудачники)
Или это:
Быть грубым - нормально
Или это:
приходится безжалостно "фильтровать базар"
И я, в целом, согласен с подобной жёсткой тональностью данной статьи - сам стараюсь формулировать вопросы согласно ей. Но что прикажете делать, если вопрос был сформулирован качественно, а в ответ - полнейший мусор (к примеру, на Вас выпрыгивает Первый! )? Есть ли повод относиться к дурным советчикам как-то иначе, чем к дурным вопрошающим? На мой взгляд - нет. На мой взгляд подобные советчики вырождают сообщество в чат чайников не хуже, чем плохие вопрошающие, о которых вы говорите.
Это будет самый лучший вариант, как для одной стороны, так и для другой.
Тогда при подобном подходе одна сторона (инженеры с их техническими проблемами) останется, а другую сторону (экспертные сообщества) можно навсегда закрывать за ненадобностью.
В мануале на корки, например трансиверы, конечно, в общем виде описано, куда копать. Но там полно частностей, на которые можно потратить много времени не умеючи. <...> И дело может быть не в человеке, а в неадекватной структуре некоторых мануалов, глюках сред разработки, ОС
Именно это я имею ввиду. Именно об этом-то я и толкую. По сути, опыт, нормальный опыт (а не вышеприведённый "киньте 22 пФ и всё починится") опирается исключительно на документацию. Кто больше знает больше документации, тот более опытен - всё просто.
Поэтому, говоря "Фуууу, даташит прочитал, а эррату не прочитал" или "Чего ты спрашиваешь здесь, почитай лучше документацию", сам говорящий, по-сути (ну вот, лично для меня), автоматически заменяет себя не то, что на Chat-GPT или даже на скрипт, а просто на лозунг. Человек-лозунг :) Пользы от него мм... я даже не знаю. Пожалуй, что - никакой.
И обижаться на посылку в RTFM не стоит, если это действительно так.
Вариантов получить проблему всего три:
Вы не прочитали документацию
Вы прочитали документацию, но ошиблись при реализации её положений на практике
Проблема заключается в недокумнтированной работе устройства
Во всех трёх случаях сообщество может помочь. С другой стороны, объективно, во всех трёх случаях можно обойтись без сообщества и экспертов с их ценным опытом. С третей - запросив помощь у сообщества, вы можете услышать от "эксперта", что вам можно обойтись и своими силами. Ну можно, да. Всегда можно. Абсолютно всегда. Вопрос, зачем нужны "эксперты" и подобные "ценные" мнения остаётся открытым.
И нет у меня никакой гипотезы, я просто сказал, что ярлыки - это плохо, и делить всё на чёрное и белое тоже неправильно
Я так понимаю, что от дискуссии Вы вежливо отказываетесь, переходя к тезисам "за всё хорошее". Ну ладно.
При этом, ваши технические статьи весьма хороши, я даже несколько в закладки добавил.
Спасибо :) Черт побери, это всегда приятно слышать :) Можете, к слову полайкать мои две предыдущие технические статьи и поднять мне карму, раз такое дело. )))) И ещё подписывайтесь и ставьте лайки. И оставляйте Ваши комментарии )))))
- чем Ваш опыт, на Ваш взгляд, может быть кому-то полезен? - А ваш?
Я считаю свой опыт полезным в связке с умением донести его в удобочитаемой и концентрированной (сжатой) форме.
Пользуясь отладчиком, всегда была интересно: "что происходит внутри микросхемы?". БОльшая часть статей, как вы и упомянули, написана так, что терпения и желания дочитать даже до середины не хватало:)Отличная статья, все красиво нарисовано, описано буквально по шагам - очень жду продолжения цикла;)
...я понимаю, что я на верном пути.
Вышеприведённый комментарий оставлен под статьёй про JTAG. Можно сказать "Ну и зачем эта статья, ведь есть же стандарт. Нужно не лениться и прочитать (а лучше - вызубрить) его". Но я с подобным буду категорически не согласен.
Смотрите, Вы упираете на необходимость досконального чтения документации. На мой (субъективный и претенциозный) взгляд, если абсолютизировать данный подход, то в мироздании не остаётся места для профессиональных сообществ. Вся электроника, все её компоненты, все её технологи, на мой субъективный взгляд делаются людьми и для людей. Здесь нет места и для какой-то науки (науки "переднего края", разумеется). "Опыт", о котором Вы говорите, в контексте Вашей мм... гипотезы становится замкнутой в специалисте сущностью. Ну зачем нужен ваш уникальный опыт, когда есть документация и есть техподдержка?
Если у Вас есть чем подкрепить Ваши соображения - я с радостью их почитаю. Статья-то и задумывалась, как дискуссионная. Отшифруйте, что вы имеете ввиду, говоря слово "опыт". И какое место в электроники занимает этот "опыт" на Ваш взгляд.
О-о! Здесь хотелось бы поподробнее :) Что Вы подразумеваете под опытом и чем Ваш опыт, на Ваш взгляд, может быть кому-то полезен? Хотелось бы услышать пример. Можно - реальный, можно - воображаемый.
Ну или предположим, что вы Эксперт С Опытом, а у меня возникла проблема с неким устройством. Я прочитал всю-всю-всю документацию (прежде чем заговорить с Экспертом С Опытом) - ответа не нашёл. Вопрос, зачем мне Ваш опыт? В рамках взаимной психотерапии? :) Послушать, как у вас тоже не заработало, обняться и поплакать? :)
Во-первых, мой пост был о том, что развешивать ярлыки можно с обеих сторон.
Если говорить вашими словами, то ярлыки с той стороны развешаны 22 года назад в руководстве "Как правильно задавать вопросы на технических форумах". Я убеждён, что "было бы справедливо так же остроумно и ёмко" указать на то, что и отвечающие далеко не всегда святые.
Хороший тон - задавать вопрос, когда доки и гугл не помогли
Возвращаясь к моему вопросу: задавать вопрос кому? Официальной техподдержке или эксперту из сообщества? Если техподдержке, то зачем нужны эксперты и сообщества? Если эксперту, то что сверх того, что написано в официальной документации может сообщить эксперт? Свои предположения и домыслы о недокументированных особенностях того или иного изделия? А что в них ценного, в этих предположениях и домыслах, раз он не является ни разработчиком конкретного изделия, ни официальным лицом?
В рамках данной дискуссии, любопытно было бы узнать, какого типа вопросы Вы считаете достойными ответа Монахов (именно они обычно красуются фразами "Эрраты не читай, вопрос задавай")?
Просто, как было написано в самом начале статьи:
Академические курсы не всегда успевают за прогрессом. А их первоисточник — техническая документация — бывает крайне обширна. Например, базовая документация на микроконтроллеры STM32F103xB насчитывает 1252 страницы. Помимо неё имеются ещё 54 документа типа application note и десятка полтора документов других типов. Поэтому достаточно востребованным источником знаний оказываются профильные сообщества.
Именно эти причины являются основой существования Монахов. Думаю, Вы согласитесь: если некий идеальный вопрошающий прочитал всю Википедию каждую эррату, каждый апноут и практически наизусть знает юзер мануал, то советы от Монахов (как и сами Монахи) ему, банально, не нужны. Потому, что при возникновении проблемы такой вопрошающий пойдёт не к "мудрому" Монаху, а в официальную техподдержку.
Да, это действительно прямо отдельный самобытный класс :)
Единственное, что я бы отметил: практик несмотря на свою анти-теоретичность зачастую действительно стремится помочь, а не показать себя при помощи сигнальных сообщений.
Хочу отметить, что когда я начинал писать данную статью, FT232RL числился в базе Маузера, хоть и с пометкой "нет в наличие". А сейчас его даже в базе нет. Похоже, NRND - не фигура речи и FTDI взяли решительный курс на сворачивание производства чипа-легенды.
Я просто понять не могу, допустим есть некое отражение, которое за один стоп-бит не успокаивается, а за два стоп-бита успокаивается. Ну ок. Стоп-биты теперь распознаются. Но в "теле" символа будет белиберда как ни крути. Если мы передаём символ 00010000, то мы точно так же получим на принимающей стороне 00011000 или 00010100 из за отражений.
Гипотетически, такое требование может взяться из необходимости моментального ответа на пришедший байт. Но это мой, несколько надуманный пример, чтобы оправдать наличие двойного стоп-бита.
К слову, не совсем понял ваш пост про
Дать время успокоиться каналу между пакетами, например для длинных линий.
Если линия согласована, то нечему в ней успокаиваться.
Если линия не согласована, да так, что это мешает передаче, то по какой причине её не согласовали?
В любом случае, двойной стоп-бит от этого точно не поможет.
Тут вот какое дело. В упоминаемой замечательной статье "Как правильно задавать вопросы в технических форумах" есть, например, это:
Таких людей мы называем "неудачниками" ("losers") (по историческим причинам это слово иногда пишется как "lusers" - пользователи-неудачники)
Или это:
Быть грубым - нормально
Или это:
приходится безжалостно "фильтровать базар"
И я, в целом, согласен с подобной жёсткой тональностью данной статьи - сам стараюсь формулировать вопросы согласно ей. Но что прикажете делать, если вопрос был сформулирован качественно, а в ответ - полнейший мусор (к примеру, на Вас выпрыгивает Первый! )? Есть ли повод относиться к дурным советчикам как-то иначе, чем к дурным вопрошающим? На мой взгляд - нет. На мой взгляд подобные советчики вырождают сообщество в чат чайников не хуже, чем плохие вопрошающие, о которых вы говорите.
Тогда при подобном подходе одна сторона (инженеры с их техническими проблемами) останется, а другую сторону (экспертные сообщества) можно навсегда закрывать за ненадобностью.
Именно это я имею ввиду. Именно об этом-то я и толкую. По сути, опыт, нормальный опыт (а не вышеприведённый "киньте 22 пФ и всё починится") опирается исключительно на документацию. Кто больше знает больше документации, тот более опытен - всё просто.
Поэтому, говоря "Фуууу, даташит прочитал, а эррату не прочитал" или "Чего ты спрашиваешь здесь, почитай лучше документацию", сам говорящий, по-сути (ну вот, лично для меня), автоматически заменяет себя не то, что на Chat-GPT или даже на скрипт, а просто на лозунг. Человек-лозунг :) Пользы от него мм... я даже не знаю. Пожалуй, что - никакой.
Вариантов получить проблему всего три:
Вы не прочитали документацию
Вы прочитали документацию, но ошиблись при реализации её положений на практике
Проблема заключается в недокумнтированной работе устройства
Во всех трёх случаях сообщество может помочь. С другой стороны, объективно, во всех трёх случаях можно обойтись без сообщества и экспертов с их ценным опытом. С третей - запросив помощь у сообщества, вы можете услышать от "эксперта", что вам можно обойтись и своими силами. Ну можно, да. Всегда можно. Абсолютно всегда. Вопрос, зачем нужны "эксперты" и подобные "ценные" мнения остаётся открытым.
Я так понимаю, что от дискуссии Вы вежливо отказываетесь, переходя к тезисам "за всё хорошее". Ну ладно.
Спасибо :) Черт побери, это всегда приятно слышать :) Можете, к слову полайкать мои две предыдущие технические статьи и поднять мне карму, раз такое дело. )))) И ещё подписывайтесь и ставьте лайки. И оставляйте Ваши комментарии )))))
Я считаю свой опыт полезным в связке с умением донести его в удобочитаемой и концентрированной (сжатой) форме.
Когда мне пишут комментарии вроде
Пользуясь отладчиком, всегда была интересно: "что происходит внутри микросхемы?". БОльшая часть статей, как вы и упомянули, написана так, что терпения и желания дочитать даже до середины не хватало:)Отличная статья, все красиво нарисовано, описано буквально по шагам - очень жду продолжения цикла;)
...я понимаю, что я на верном пути.
Вышеприведённый комментарий оставлен под статьёй про JTAG. Можно сказать "Ну и зачем эта статья, ведь есть же стандарт. Нужно не лениться и прочитать (а лучше - вызубрить) его". Но я с подобным буду категорически не согласен.
Смотрите, Вы упираете на необходимость досконального чтения документации. На мой (субъективный и претенциозный) взгляд, если абсолютизировать данный подход, то в мироздании не остаётся места для профессиональных сообществ. Вся электроника, все её компоненты, все её технологи, на мой субъективный взгляд делаются людьми и для людей. Здесь нет места и для какой-то науки (науки "переднего края", разумеется). "Опыт", о котором Вы говорите, в контексте Вашей мм... гипотезы становится замкнутой в специалисте сущностью. Ну зачем нужен ваш уникальный опыт, когда есть документация и есть техподдержка?
Если у Вас есть чем подкрепить Ваши соображения - я с радостью их почитаю. Статья-то и задумывалась, как дискуссионная. Отшифруйте, что вы имеете ввиду, говоря слово "опыт". И какое место в электроники занимает этот "опыт" на Ваш взгляд.
О-о! Здесь хотелось бы поподробнее :) Что Вы подразумеваете под опытом и чем Ваш опыт, на Ваш взгляд, может быть кому-то полезен? Хотелось бы услышать пример. Можно - реальный, можно - воображаемый.
Ну или предположим, что вы Эксперт С Опытом, а у меня возникла проблема с неким устройством. Я прочитал всю-всю-всю документацию (прежде чем заговорить с Экспертом С Опытом) - ответа не нашёл. Вопрос, зачем мне Ваш опыт? В рамках взаимной психотерапии? :) Послушать, как у вас тоже не заработало, обняться и поплакать? :)
Если говорить вашими словами, то ярлыки с той стороны развешаны 22 года назад в руководстве "Как правильно задавать вопросы на технических форумах". Я убеждён, что "было бы справедливо так же остроумно и ёмко" указать на то, что и отвечающие далеко не всегда святые.
Возвращаясь к моему вопросу: задавать вопрос кому? Официальной техподдержке или эксперту из сообщества?
Если техподдержке, то зачем нужны эксперты и сообщества?
Если эксперту, то что сверх того, что написано в официальной документации может сообщить эксперт? Свои предположения и домыслы о недокументированных особенностях того или иного изделия? А что в них ценного, в этих предположениях и домыслах, раз он не является ни разработчиком конкретного изделия, ни официальным лицом?
В рамках данной дискуссии, любопытно было бы узнать, какого типа вопросы Вы считаете достойными ответа Монахов (именно они обычно красуются фразами "Эрраты не читай, вопрос задавай")?
Просто, как было написано в самом начале статьи:
Именно эти причины являются основой существования Монахов. Думаю, Вы согласитесь: если некий идеальный вопрошающий прочитал
всю Википедиюкаждую эррату, каждый апноут и практически наизусть знает юзер мануал, то советы от Монахов (как и сами Монахи) ему, банально, не нужны. Потому, что при возникновении проблемы такой вопрошающий пойдёт не к "мудрому" Монаху, а в официальную техподдержку.О, вы прочитали пункт 2.8.7! Это - хорошо.
Следующие вопросы:
Зачем, на Ваш взгляд, нужны 15 пунктов воркэраунда, если "никогда ничего не залипает"?
Разобрались ли вы в схеме входных фильтров, которой в этой Errata нет?
Как вы понимаете фразу из этой Errata "Consequently, the I2C BUSY flag is set, and the I2C cannot enter master mode"?
Приведите пример. Интересно почитать.
Руководствуйтесь относительным :) А всё многообразие вариантов можете изложить в комментарии :)
Всегда пожалуйста :)
Спасибо вам за любопытный кейс.
Неа :) Из нескольких выбирайте тот единственный вариант, который подходит больше всего :)
У меня встречный вопрос: вы прочитали пункт 2.8.7 из документа ES096, ссыклу на который я привёл в начале того абзаца, который Вы обильно цитируете?
О-о, это вообще золотой стандарт :)
Практик, советующий "повесить 22 пф на шину", но никогда не вешавший их туда сам.
Монах, прочитавший из Хоровица и Хилла две главы и приказывающий всем прочитать их от корки до корки
Академист, оспаривающий определение термина до тех пор, пока ему не сообщают, что оно из IEC60050.
Классика.
Да, это действительно прямо отдельный самобытный класс :)
Единственное, что я бы отметил: практик несмотря на свою анти-теоретичность зачастую действительно стремится помочь, а не показать себя при помощи сигнальных сообщений.
Он не только подорвал, но и еще ничему не научил - FTDI изобретателтно и задорно повторили :)
В разделе про драйверы я упомянул данную череду скандалов :)
Хочу отметить, что когда я начинал писать данную статью, FT232RL числился в базе Маузера, хоть и с пометкой "нет в наличие". А сейчас его даже в базе нет. Похоже, NRND - не фигура речи и FTDI взяли решительный курс на сворачивание производства чипа-легенды.
Я просто понять не могу, допустим есть некое отражение, которое за один стоп-бит не успокаивается, а за два стоп-бита успокаивается. Ну ок. Стоп-биты теперь распознаются. Но в "теле" символа будет белиберда как ни крути. Если мы передаём символ 00010000, то мы точно так же получим на принимающей стороне 00011000 или 00010100 из за отражений.
Гипотетически, такое требование может взяться из необходимости моментального ответа на пришедший байт. Но это мой, несколько надуманный пример, чтобы оправдать наличие двойного стоп-бита.
К слову, не совсем понял ваш пост про
Если линия согласована, то нечему в ней успокаиваться.
Если линия не согласована, да так, что это мешает передаче, то по какой причине её не согласовали?
В любом случае, двойной стоп-бит от этого точно не поможет.