В зоне отрыва скотча ожидаемо начали сиять весьма интенсивные голубые вспышки, и, как заявляют сами исследователи, для них было весьма удивительно видеть, что подобный процесс генерирует просто огромный поток рентгеновского излучения!
Например, они подносили к стеклу этой камеры счётчик Гейгера, и у стрелочного счётчика «ложилась» стрелка (т. е. проходила всю градуированную область и ложилась с противоположной стороны!).
Ээээ. А как датчик, регистрирующий потоки заряженных частиц среагировал на кванты электромагнитного излучения?
Ох уж эти тёплые ламповые расчёты на бумажке в качестве альтернативы холодным и бездушным решателям на конечных элементах.
Ведь как сакрализировать умение пользоваться конечно-элементным решателем? Особо никак: "я тут знаю секретную кнопку, ускоряющую всё в 1000 раз, про которую не рассказано в хелпе" - сомнительно и, главное, не архетипично.
Вот с аналитическими формулами - всё совсем по-другому! "Я знаю Секретную Формулу, которую прочёл в Священной Книге" - это прям позволяет почувствовать себя Гендельфом инженерии.
Тут, правда, вот какое дело - простая аналитика, типа I=U/R, осталась в школе. - чуть более сложная аналитика для простейших случаев, типа Z0=60/sqrt(e) * ln(Rэк/Rж), требует некоторых операций сверх сложения, вычитания, умножения и деления. Будем на бумажке извлекать натуральный логарифм? - чуть более сложная аналитика для практических случаев, представляет из себя полуэмпирическую подгонку под ответ со всякими прикольными ограничениями. Так, для импеданса копланарной линии есть, типа, аналитическая формула, которая сносно работает, если отношение ширины линии к толщине печатной платы лежит между 0,1 и 2,0. Что будет, если это отношение 1,99 или 2,01 - "ну-уэ-э-э, там смотреть надо". Весёлые операции, разумеется, никуда не деваются.
Можно было бы задаться вопросом: и в чём же тогда различие между конечно-элементным решателем и Excel, в который вбили полуэмпирическую формулу, с прикольными ограничениями по входным параметрам и операциями, которые всё равно не будут пересчитывать вручную? Ведь с точки зрения влияния на некое "понимание глубинных процессов" оба подхода практически идентичны. Как представляется, различия всё же есть. И они в следующем: 1. МКЭ при вполне допустимом времени вычислений, по точности уделает аналитику в хлам. 2. Но при этом из МКЭ не получится сделать косплей 1950-х годов - своего рода Dark Academia для инженеров.
Если разность температур постоянна и на одном из концов FT232RL, то при битрейте 9600 бит/с делитель позволяет подкручивать битрейт с шагом приблизительно в 0,1%. Имело бы смысл тогда подстроиться под приёмник.
Но. Если...
Градиент "20 с лишним градусов" и при этом он не фиксирован - постоянно меняется
Скорость хочется сделать в районе мегабитов в секунду, следовательно делителем особо точно битрейт уже не понастраиваешь. Либо он в принципе не настраиваем.
Обе стороны затактированы от внутренних RC и подсунуть кварцы нет никакой возможности
...то да, дело - дрянь ))))
Представляется, что применение в таком случае двойного стоп-бита (который - раз! и поможет) - это заплатка. Это не то что, двойной стоп-бит обладает какими-то супер-ценными фишками. Градиент станет чуть побольше - и эта заплатка также порвётся. Придётся урезать уже количество бит в символе )))
5% на бит? Типа, чтобы на 10 битах получить 50% ? Ммм. На каком оборудовании вы получали такое расхождение длительности бита? Просто даже если взять, скажем MCP2221 и врубить ему нетипичный именно для него битрейт 128000 бит/с, то там расхождение от ошибки деления частоты будет 7,3%. На весь символ. Не на бит. У всех остальных мостов ошибка от деления частоты на весь символ набегает, ну, процента 1,5%. А то и меньше.
Не, если эта ATmega328P, используемая в расширенном температурном диапазоне и затактированная от внутреннего генератор, который будет гулять на предельных температурах на 14%, то да. Но там и двойной стоп-бит не поможет )))) Там, думаю, нужно будет как раз 5-битными символами общаться, чтобы погрешность не набегала )))
Субъективно я не проникся вышеперечисленными доводами. Мне всё ещё кажется, что имитатор EPCS16 был бы здесь несколько уместнее. Не исключаю, однако, что я не прав. Вам на месте было конечно было виднее, возможно были и ещё какие-то доводы в пользу JTAG.
В таком случае не вполне понятно, чего не сделать полное реконфигурирование ПЛИС, которое было бы проще запрограммировать? Да, оно будет длится чуть дольше и на время конфигурирования ПЛИС не сможет взаимодействовать с внешним миром. Ну так и что же?
Готовой инструкции я не нашёл, но завтра постараюсь поиграть с STM32 при помощи TopJTAG Probe. Если всё будет успешно, напишу вам что где качать и что где нажимать.
Ммм. Не очень понимаю, зачем же вы писали именно JTAG, когда для заливки в четвёртый Циклон достаточно было бы сымитировать EPCS16, которая работает банальнейшим образом.
Наличие модуля JTAG в микросхеме позволяет при помощи интерфейса JTAG ввести микросхему в тестовый режим и установить любое логическое состояние на любом выходном пине. Либо прочитать логическое состояние на любом входном пине.
Соответственно, если две микросхемы с JTAG-ом соединены друг с другом какой-нибудь, скажем, параллельной шиной, то при помощи JTAG возможно приказать одной микросхеме установить на шине характерный паттерн, а с другой микросхемы считать его. Затем поменять его и снова считать. Если считывается то, что было установлено, значит непропаев нет.
Вот здесь парни сделали крупный наглядный выставочный стенд, иллюстрирующий работу JTAG. Они как раза рассказывают про то, что "You can find the solder failure..."
Вот здесь небольшое руководство по работе с ПО, осуществляющим в том числе прозвонку межсоединений при помощи JTAG.
В общем виде в JTAG отсутствует понятие пакета. Данный термин можно ввести в рамках некоторой надстройки над JTAG-ом. Но тогда нужно определиться, какого рода действия вы планируете выполнять при помощи типового пакета.
Немного странно, что в статье ни разу не упомянут JTAG, который как раз для подобных нужд и разрабатывался. Если в микроконтроллере есть JTAG, то почему бы не использовать штатный JTAG? Если в микросхеме нет JTAG-а, почему бы не написать программный JTAG и не продолжить работу с ним штатными средствами тестирования?
В профессиональных пакетах JTAG-тестирования (к примеру, JTAG ProVision или XJDeveloper) заложены тестовые последовательности для обширной номенклатуры периферийных микросхем. Такие последовательности позволяют, например, при помощи JTAG-битбандинга писать/читать данные из подключенных к микроконтроллеру микросхем памяти, у которых нет своего JTAG-а. И таким образом не только проверять непропаи, но и работоспособность самих периферийных микросхем, а также банально записывать в них определённые данные. Кроме того, данные пакеты могут автоматически сгенерировать тестовые последовательности из net-листа проекта печатной платы. Писать подобные тесты полностью вручную чревато неоправданными трудозатратами и человеческими ошибками.
В вашей же статье речь идёт, фактически, о анти-стандартном решении, призванном перехватить функционал JTAG-а. Есть сомнения, что данные подход правилен.
корка имеет два варианта интерфейсов X и Y. Среда генерит корку под Х нормальную, а под Y -- с неправильным направлением одного порта.
Формально, путь стандартен: техподдержка -> эррата -> багфикс в одном из следующих релизов. Формально, на этом пути сообщество нигде не фигурирует. В реальности вендоры регулярно заморачиваются налаживанием симбиоза с сообществом, но об этом я бы хотел написать отдельно.
Большое спасибо! Обожаю такие статьи: всё объяснено просто, понятно и наглядно.
Вангую, что сейчас:
...будет упомянут ОГАС...
...но тот, кто его упомянет, ничего не расскажет про просуществовавшую до самого распада Союза АСПР.
По сравнению с предыдущим годом исчезла номинация "Железо и его разработка". Для электронщиков осталась DIY. Эх...
Хм. Да, оказывается, что счётчик Гейгера на основе слюдяного датчика регистрирует даже рентгеновское излучение. Никогда бы не подумал.
Ээээ. А как датчик, регистрирующий потоки заряженных частиц среагировал на кванты электромагнитного излучения?
Ох уж эти тёплые ламповые расчёты на бумажке в качестве альтернативы холодным и бездушным решателям на конечных элементах.
Ведь как сакрализировать умение пользоваться конечно-элементным решателем? Особо никак: "я тут знаю секретную кнопку, ускоряющую всё в 1000 раз, про которую не рассказано в хелпе" - сомнительно и, главное, не архетипично.
Вот с аналитическими формулами - всё совсем по-другому! "Я знаю Секретную Формулу, которую прочёл в Священной Книге" - это прям позволяет почувствовать себя Гендельфом инженерии.
Тут, правда, вот какое дело
- простая аналитика, типа I=U/R, осталась в школе.
- чуть более сложная аналитика для простейших случаев, типа Z0=60/sqrt(e) * ln(Rэк/Rж), требует некоторых операций сверх сложения, вычитания, умножения и деления.
Будем на бумажке извлекать натуральный логарифм?
- чуть более сложная аналитика для практических случаев, представляет из себя полуэмпирическую подгонку под ответ со всякими прикольными ограничениями. Так, для импеданса копланарной линии есть, типа, аналитическая формула, которая сносно работает, если отношение ширины линии к толщине печатной платы лежит между 0,1 и 2,0. Что будет, если это отношение 1,99 или 2,01 - "ну-уэ-э-э, там смотреть надо". Весёлые операции, разумеется, никуда не деваются.
Можно было бы задаться вопросом: и в чём же тогда различие между конечно-элементным решателем и Excel, в который вбили полуэмпирическую формулу, с прикольными ограничениями по входным параметрам и операциями, которые всё равно не будут пересчитывать вручную? Ведь с точки зрения влияния на некое "понимание глубинных процессов" оба подхода практически идентичны. Как представляется, различия всё же есть. И они в следующем:
1. МКЭ при вполне допустимом времени вычислений, по точности уделает аналитику в хлам.
2. Но при этом из МКЭ не получится сделать косплей 1950-х годов - своего рода Dark Academia для инженеров.
Если разность температур постоянна и на одном из концов FT232RL, то при битрейте 9600 бит/с делитель позволяет подкручивать битрейт с шагом приблизительно в 0,1%. Имело бы смысл тогда подстроиться под приёмник.
Но. Если...
Градиент "20 с лишним градусов" и при этом он не фиксирован - постоянно меняется
Скорость хочется сделать в районе мегабитов в секунду, следовательно делителем особо точно битрейт уже не понастраиваешь. Либо он в принципе не настраиваем.
Обе стороны затактированы от внутренних RC и подсунуть кварцы нет никакой возможности
...то да, дело - дрянь ))))
Представляется, что применение в таком случае двойного стоп-бита (который - раз! и поможет) - это заплатка. Это не то что, двойной стоп-бит обладает какими-то супер-ценными фишками. Градиент станет чуть побольше - и эта заплатка также порвётся. Придётся урезать уже количество бит в символе )))
5% на бит? Типа, чтобы на 10 битах получить 50% ? Ммм. На каком оборудовании вы получали такое расхождение длительности бита? Просто даже если взять, скажем MCP2221 и врубить ему нетипичный именно для него битрейт 128000 бит/с, то там расхождение от ошибки деления частоты будет 7,3%. На весь символ. Не на бит. У всех остальных мостов ошибка от деления частоты на весь символ набегает, ну, процента 1,5%. А то и меньше.
Не, если эта ATmega328P, используемая в расширенном температурном диапазоне и затактированная от внутреннего генератор, который будет гулять на предельных температурах на 14%, то да. Но там и двойной стоп-бит не поможет )))) Там, думаю, нужно будет как раз 5-битными символами общаться, чтобы погрешность не набегала )))
Ошибка эффективно обнуляется и после одного стоп-бита.
Поддержка IBIS и Touchstone (импорт/экспорт, как в ADS) имеется?
Субъективно я не проникся вышеперечисленными доводами. Мне всё ещё кажется, что имитатор EPCS16 был бы здесь несколько уместнее. Не исключаю, однако, что я не прав. Вам на месте было конечно было виднее, возможно были и ещё какие-то доводы в пользу JTAG.
В таком случае не вполне понятно, чего не сделать полное реконфигурирование ПЛИС, которое было бы проще запрограммировать? Да, оно будет длится чуть дольше и на время конфигурирования ПЛИС не сможет взаимодействовать с внешним миром. Ну так и что же?
Мне кажется, что JTAG здесь избыточен.
Любопытно, конечно, было бы узнать назначение устройства - так ли уж нужна была в нём динамическая реконфигурация.
Готовой инструкции я не нашёл, но завтра постараюсь поиграть с STM32 при помощи TopJTAG Probe. Если всё будет успешно, напишу вам что где качать и что где нажимать.
Ммм. Не очень понимаю, зачем же вы писали именно JTAG, когда для заливки в четвёртый Циклон достаточно было бы сымитировать EPCS16, которая работает банальнейшим образом.
Наличие модуля JTAG в микросхеме позволяет при помощи интерфейса JTAG ввести микросхему в тестовый режим и установить любое логическое состояние на любом выходном пине. Либо прочитать логическое состояние на любом входном пине.
Соответственно, если две микросхемы с JTAG-ом соединены друг с другом какой-нибудь, скажем, параллельной шиной, то при помощи JTAG возможно приказать одной микросхеме установить на шине характерный паттерн, а с другой микросхемы считать его. Затем поменять его и снова считать. Если считывается то, что было установлено, значит непропаев нет.
Вот здесь парни сделали крупный наглядный выставочный стенд, иллюстрирующий работу JTAG. Они как раза рассказывают про то, что "You can find the solder failure..."
Вот здесь небольшое руководство по работе с ПО, осуществляющим в том числе прозвонку межсоединений при помощи JTAG.
В общем виде в JTAG отсутствует понятие пакета. Данный термин можно ввести в рамках некоторой надстройки над JTAG-ом. Но тогда нужно определиться, какого рода действия вы планируете выполнять при помощи типового пакета.
Немного странно, что в статье ни разу не упомянут JTAG, который как раз для подобных нужд и разрабатывался.
Если в микроконтроллере есть JTAG, то почему бы не использовать штатный JTAG?
Если в микросхеме нет JTAG-а, почему бы не написать программный JTAG и не продолжить работу с ним штатными средствами тестирования?
В профессиональных пакетах JTAG-тестирования (к примеру, JTAG ProVision или XJDeveloper) заложены тестовые последовательности для обширной номенклатуры периферийных микросхем. Такие последовательности позволяют, например, при помощи JTAG-битбандинга писать/читать данные из подключенных к микроконтроллеру микросхем памяти, у которых нет своего JTAG-а. И таким образом не только проверять непропаи, но и работоспособность самих периферийных микросхем, а также банально записывать в них определённые данные. Кроме того, данные пакеты могут автоматически сгенерировать тестовые последовательности из net-листа проекта печатной платы. Писать подобные тесты полностью вручную чревато неоправданными трудозатратами и человеческими ошибками.
В вашей же статье речь идёт, фактически, о анти-стандартном решении, призванном перехватить функционал JTAG-а. Есть сомнения, что данные подход правилен.
В своих статьях я под спойлеры обычно убираю самое интересное :)
Формально, путь стандартен: техподдержка -> эррата -> багфикс в одном из следующих релизов. Формально, на этом пути сообщество нигде не фигурирует. В реальности вендоры регулярно заморачиваются налаживанием симбиоза с сообществом, но об этом я бы хотел написать отдельно.