Leaderboard

ЕС, Румыния, Молдавия, какие могут быть еще ассоциации... Подобная риторика про демократию хорошо заходила лет тридцать назад, с тех пор маски сброшены и вообще не смешно. Извиняюсь за политический оффтоп.

Кем и где наблюдается? Имхо надо быть совсем упоротым чтобы добровольно, имея выбор, пересесть с Кайла или Яра на на эту тормозную шарманку.

Может не тупо усреднять, а, например, брать средний квадрат (по энергии оценивать). Это ослабляет влияние отдельных шумовых "выбросов". Или, скажем, брать 20 отсчётов, сортировать их, отбрасывать 5 самых больших и 5 самых маленьких, остальные 10 усреднять -- это тож эффективно убирает спорадические "выбросы". Понятно, что числа указаны условные . А вообще, для начала, надо посмотреть на характер значений, получающихся при измерениях. Проанализировать и тогда уже выбирать подходящий алгоритм обработки.

Вышла новая книга от небезызвестного здесь персонажа. Что заслуживает уважение – это упорство Виталия. Из другой области. Кому интересно, как вытягивать шумы в ЖИГ-генераторе с помощью КСС: Patent

Добрый день! Не рисуйте схемы в таком стиле: изобилие меток и портов. Такие схемы сложно читаемы. Основная часть времени уходит на визуальный поиск связей. Рисуйте линии. Я в своё время тоже увлекался подобным. Но, коллеги, читая мои схемы быстро направили на путь истинный.

Это основная ошибка. В составе команды должны быть экономисты и менеджеры, которые не увлечены утопической идеей, а умеют считать деньги.

Философский вопрос: а можно ли считать продвинутый программерский редактор + система сборки за IDE? Ведь функционально-то оно ведь ровно то же самое. Если вникать в суть процесса, то вся тема базируется на трёх "китах" (аспектах): сборка проекта; редактирование кода; визуальная отладка. За п.1 отвечает система сборки. Что это конкретно -- дело третье. п.2 решается использованием специализированного (программерского) редактора. Можно, конечно, и в блокноте код редактировать, но мало кому в здравом уме это приходит в голову. п.3 -- тут речь про GUI Front-end для отладчика в случае вариантов типа gdb или какие-то встроенные визуальные отладчики. В итоге, что понимать под IDE? Вот, скажем, есть продвинутый программерский редактор, способный запускать тулы, перехватывать их вывод, парсить его и переходить в исходные файлы к месту ошибки. Т.е. пишем код, запускаем сборку (хоть по горячей клавише), если есть ошибки/варнинги, тыкаем в них, попадаем в код. Редактор умеет подсветку синтаксиса и навигацию для выбранного языка. Чем это не IDE? Только тем, что там эти фичи прикрутили сами, а не какие-то другие люди? Ну, так сам-то себе сделаешь лучше и удобнее. И это делается один раз -- разобрался, и дальше оно плывёт из проекта в проект. Если что-то подправить, улучшить, сделать более удобным -- это куда проще и управляемее, чем ковырять чьи-то поделия, где каждый раз ещё надо разобраться, как оно там сделано. Либо терпеть неудобства. Про сборку Тут два варианта: либо делаем сами, либо используем то, что дают. Общего рецепта быть не может -- все люди разные, у всех свои предпочтения. Объективно основные плюсы и минусы: своя система сборки + полная управляемость; - необходимость делать это самому, править, сопровождать. Для кого-то и это плюс -- более качественный контроль за сборкой; готовая (из IDE) + можно пользоваться "из коробки"; - нужно каждый раз разбираться, как сделать то или иное -- например, добавить файлы в проект, указать фичи сборки (ключи компилятора, линкера), пути для левых заголовочных файлов и т.п. Как правило, это не сложно, и типовые вещи делаются без проблем, если GUI сделан по-человечески, когда, глядя на него, интуитивно понятно, что к чему. Но при смене IDE опять проходить по-новой, а если их в работе больше одной, то каждый раз помнить и соображать, как что делать в конкретной. Это упирается в особенности психики идивида -- одним это без проблем (даже нравится), другим это разнообразие как шило в печень; - если нужно сделать что-то такое, что не предусмотрено системой сборки, то это, как правло, неразрешнимая проблема, и в ход идут костыли; - привязка к конкретной сборочной системе (утилите) -- обычно это make. Тут тоже сделать ничего нельзя. Про новизну Я поддерживаю тезис, что прыгать и скакать от новизны к новизне может быть годным по молодости, когда ещё опыта нет -- как раз в целях набора этого самого опыта, без него ведь и не понять, что к чему. В этом деле пока не попробуешь сам, не потрогаешь, не поковыряешь, то и не поймёшь. Через какое-то время этот опыт приходит, и на основе его выбирается предпочтительный вариант. Это нормально. Но именно исходя из этого тезиса - "хочется стабильности и продуктивности" - как раз и начинает рулить вариант "собственная (выбранная) сборочная система + выбранный редактор". Когда у меня один и тот же редактор уже 25 лет (если не дольше, только версии меняются), в котором я пишу абсолютно всё, начиная от C/C++ и Python и заканчивая скриптами Tcl и шелла, то это ли не стабильность? При переходе к новому проекту не нужно изучать новую IDE с её особенностями и борьбой с ними. Например, лично меня очень раздражает, когда в редакторе при перемещении курсора по вертикали (кнопки Up/Down на клавиатуре) он начинает метаться влево-вправо, когда попадаются пустые строки. В приличных редакторах есть настройка типа "виртуальных пробелов", при которой курсор предсказуемо двигается по вертикали в одной и той же позиции. Готовые IDE типа IAR EW вообще тут не позволяют ничего сделать, широкораспростнанённые на базе Eclipse или VSCode тоже просто так не позволяют это решить -- там начинается квест по поиску и установке соответствующих расширений, в одной из них мне удалось решить, в другой нет. И таких примеров можно привести дофига. И лично для меня это очень негативный фактор -- я люблю, чтобы инструмент был идеально заточен и максимально готов к работе, чтобы я в процессе концентрировался только на предмете работы, а не отвлекался на раздражающие факторы инструментария. Если вам это пофиг -- многим людям всё это до лампочки, они неприхотливы в этом аспекте и даже не замечают тут неудобств, то данный аргумент мимо. Но таким людям и вся эта тема должна быть пофиг. А когда у меня один и тот же редактор, то этой проблемы нет вообще -- всё на месте, всё привычно. Единственное, что нужно иногда сделать -- настроить регулярные выражения для парсинга выхлопа тулов, но это редкая операция, а если используется тот же тулчейн (например, GCC, то и делать ничего не надо) Про отладку Этот аспект, имхо, существенно менее важен, чем первые два. Не считаю, что GUI отладка должна вестись в том же редакторе. Во-первых, у отладчика свои требования и возможности, они часто не пересекаются с возможностями редактора. Во-вторых, такой инструмент бывает нужен весьма не часто. Обычно он нужен для интроспекции, а многие отладочные операции успешно и удобнее (и быстрее) решаются с помощью отладочной печати в терминал (лог). Для GUI отладки IDE вендоров подходят обычно лучше всего -- там меньше всего проблем. Главное, чтобы они позволяли загружать уже собранный исполняемый (сегодня это, как правило, elf), который собрать, конечно, с отладочной инфой (тогда отладка по удобству ничем не уступает отладке проекта, собранно в IDE). Как итог Каждый выбирает инструмент сам, осуждать и удивляться не нужно. Кому-то пофиг негибкость и какие-то неудобные моменты готовых IDE, а кому-то важно иметь полную управляемость. Сам лично предпочитаю иметь независимые "координаты" по всем "трём осям" -- сборка, редактор, отладчик: система сборки должна позволять собрать проект откуда угодно, начиная от командной строки и заканчивая CI/CD, включая, конечно, редакторы/IDE; редактор может быть любым, какой нравится, никаких привязок к сборке и отладке; отладчик -- обычно какой удобнее и доступнее, без привязок к сборке и редактору. Именно такой подход и отвечает наилучшим образом стремлению к стабильности, удобству, гибкости и, в конечном итоге, продуктивности. Что касается make (сам его не люблю), то необходимость его использовать в "раздельном" подходе сильно ослабляется. Уже была тема (слегка холиварная) про сборочные инструменты. В случае IDE, кстати, если там она генерит Makefile, иногда приходится туда заглядывать, когда что-то идёт не так. Т.ч. если сами мейкфайлы писать и не надо, то уметь читать их очень не лишне. Например, вот нужно передать параметр программе в виде макроса, которой представляет собой строку. С ходу такое обычно не взлетает, нужна какая-то отладка. Вот тут приходится обращаться на этот "низкий" уровень. Кстати, как в IDE передать компилятору строку (то, что в командной строке передаётся через ключ -D)? Типа аналог: #define SOURCE_IP "192.168.10.10"

IDE отталкивают сложной подковерной возней и завязкой всего на себя. Хочется контроля, такого инструмента работа которого прозрачна, где не бывает непонятных проблем. Отдельная система сборки и отдельный отладчик выглядят проще, и это не конфликтует с редактором текста который умеет в анализ язака и рефакторинг. К чему привыкли то и проще, я в IDE этих без пояснительной бригады немогу понять где/как самые простые операции выполнить.

Дело не в лени. По работе приходится сталкиваться с подобными халокодом, в котором нужно исправить ошибку или добавить функционал и, как обычно, здесь и сейчас. В своей работе я ХАЛ не использую. В этом случае как раз и помогает ИИ, позволяющий сузить круг поиска и часто предлагающий варианты решения, глядя на которые решать задачу становиться намного проще. Понимаете, мне в своё время говорили, что у инженера на полке должны стоять таблицы Брадиса , а сам он должен уметь пользоваться логарифмической линейкой, потому что в калькуляторе могут сесть батарейки и я не смогу ничего рассчитать. Нынешние разговоры про ИИ мне часто напоминают те разговоры про калькулятор и логарифмическую линейку. В институте мы все учились брать интегралы. Многие смогут сейчас сходу это сделать? Я даже вспоминать не хочу, а просто загоню его в Maple и получу результат, не тратя на решение кучу времени. Вот и к решению задач с помощью ИИ у меня отношение такое же как к взятию интегралов.

Фильм скорее художественный и несёт популяризаторскую ценность. Для прикладников на один раз посмотреть. Что-то на уровне разговоров в курилке. Реверс-инженеринг физических решений и изделий упомянут только исторически в общих чертах, а потом всё скатывается в айти-рассказы, суть которых "мы посмотрели код, мы сделали".

тогда это не ТС а ТСО А "болванка" здесь для выравнивания температуры по времени и по обьему. И термостатируемый обьект, помещенный в болванку будет иметь температуру более стабильную и равномерную. Это как конденсатор в выпрямителе. Чем больше емкость (масса)- тем ниже пульсации (выше стабильность температуры)

Я делал Блоки управления инкубаторами на 16 000 яиц с поддержанием температуры 36..39 град с точностью 0.1 град и поддержанием влажности 40..80%, поэтому представляю сложности. Там перемешивание воздуха было обязательным. Требования надежности и контроля жесткие.. Представляете себе 16000 выброшенных оплодотворенных яиц? PS. это было в 2000 году. Выпустили около 300шт. Несколько птицефабрик. Потом были биореакторы для заквасок йгуртов.. А потом пришли эффективные менеджеры.. Но это отдельная история.

0,1 градуса - это очень непросто, избежать такого градиента внутри камеры - уже задача. Я видел термостаты похожего объёма, которые это могут. Они были облеплены теми самыми элементами Пельтьё с пяти граней из шести.

Я не хочу в личку... есть гитхаб с исходниками открытый... Всего-то хотел от вас названия двух пинов компорта. https://github.com/ua1arn/hftrx/tree/develop

С Али что угодно можно купить и доказывать что всё пропало. Могу даже видео снять специально для вас, проводки от ВАЗ 2114 и там будут провода из чистой меди. Почитайте про правильный обжим, ибо тут всякого бреда нагнали. 1308072-2._AMP_SUPERSEAL_Connectors.pdf.

Да, звонятся, потому что они просто закрыты маской но не заполнены, а это у всех отдельный заказ.

Динозавр 555 и 91 кОм это приговор, рабочий ток надо увеличивать на порядки, например: Здесь МК на своём выходе таймера создаёт данный сигнал ШИМ и далее просто измеряет своим АЦП выходное напряжение схемы, микросекунды по горизонтали равны пикофарадам, в качестве компаратора используется логический элемент.

Абсолютно согласен, от такого вида схемы через минуту начинают глаза слезиться. Порты -- это вообще не для этого, тогда уж метки. Но и ими увлекаться не надо. Когда много сигналов (в шину), то, конечно, лучше метками, иначе там будет клубок проводов. Но аналоговые (цифро-аналоговые) схемы надо рисовать так, чтобы проглядывалась структура замысла и связи, которые выполнять непосредственно -- проводами. Поэтому в первую очередь надо правильно размещать компоненты на схеме -- от правильного размещения и зависит в первую очередь читабельность (почти как с платами -- плохое размещение на ней препятствует хорошей разводке).

Пытаться однозначно стоит, у нас выбора нет, это вопрос выживания России как страны в существующих границах. Иран успешно противостоит США и Израилю только потому, что он много лет готовился к войне, находясь под санкциями, строил множественные подземные сооружения, развивал свою военную и гражданскую промышленность, науку, общественный строй, с опорой на собственные силы. И достиг неплохих успехов в этом. Иранские дешевые дроны Шахиды скопировали мы, и даже сами американцы (срочно разворачивающие производство), признав их эффективность при затяжной войне. Ну и как выглядят сейчас атакуемые арабские страны залива, которые отдали на аутсорсинг вопросы собственной безопасности? Поставившие на принцип, что все можно купить за деньги. А выясняется, что в критические моменты за деньги ВСЕ купить нельзя. И надо просто посмотреть на карту и на плотность населения, чтобы понять, что удержать территорию нашей страны от посягательств непростая задача. И необходимость сильной вертикали власти в таких условиях это следствие. Ту два варианта либо сдаться, либо победить, и все равно при любом исходе война в глобальном смысле будет продолжаться, и санкции никуда не денутся

Если ты не олигарх, по сути да, потому как твои конкретно силы ничто по сравнению с силами государства. Впрочем, обычно(не всегда) требуется уточнение в чем конкретно не выполняет, потому как обычно государство нейтрально и имеет кучу механизмов выполнения своих обязательств, а подобные формулировки являются просто частью пропагандистской компании какой-то олигархической группы желающей захватить часть или всю власть над государством используя толпу в качестве послушного стада. Демократия это лишь способ избрания публичной власти управляющей государством. Причем тут демократия деньгам государства? А государство в праве на любого гражданина за это натравить силовиков и сгноить в тюрьме или лишить жизни. Чего Тэтчер неоднократно и демонстрировала. Автократия подразумевает неограниченную власть кого либо. В России нет никого кто бы обладал такой властью ни формально ни реально. Т.е. демократия это оказывается не обман при котором избраться можно только с помощью олигархата об участии которого в выборах не принято говорить? А пацаны-то и не знают...

Чувак явно продвигает кремлевскую пропаганду, а также пытает выдать нынешний российский режим за демократический. Так вот, во первых, в демократиях нет никаких денег государства, а есть деньги налогоплательщиков (М. Тэтчер). Любой гражданин вправе возмущаться и протестовать, когда его деньги тратятся государством на дурные цели. Во-вторых, в научном плане наш режим является не демократией, а персоналистской автократией. С. Гуриев и Д. Трейсман называют подобные режимы также диктатурами обмана. Основной обман заключается в том, что власть определяется не на выборах, выборы подменяются декоративным голосованием за тех, кто надежен. В этих условиях нет никаких договоров с государством, и нет никакого делегирования прав (включая право на насилие) от граждан государственным структурам. Государство само забирает те права, которые ему нужны, и никак не подотчетно гражданам.

Почти медианный фильтр получается. А разница с медианным что дает? Наверно это отбросит только зеленое примет в расчет

Какие студенты, куда поступают? Какой-то математики? Чего нет? Циферок нет, только буковки? Блин, праздники уже прошли, вы только щас протрезвели? Нехило. Философия обычно начинается после второй бутылки.

Дык видимо да здарвствует мир ВПН... Сам никогда не пользовался, но сволочугам все не имется, уже все .сом сайты почти не работают, нужно прогу для разлочки телефона скачать - так фсе уже хренушки без впн-ов, сволочи одним словом(( С таким остервенением лучше б с дронами боролись, но там ведь думать надо, а они с момента получения своей должности отключают мозги.

Make-файлы тоже можно не трогать и не переписывать каждый раз снова, зачем вы это делаете? А IDE новой версии может начать создавать какие-то новые файлы, надо будет разбираться куда их девать, под контроль VCS или можно удалять и они перегенерятся. А может чего-то сломается от их удаления и надо будет искать как исправить. Вот подобные проблемы мне нужны. Работать со сторонними проектами в чужой незнакомой IDE тоже тоже странное занятие, когда можно разделять сборку и работу с текстом и делать большую часть как привык. Добавка: Даже без новых версий IDE, слияние веток в VSC обычно ломает файлы проектов IDE если в обоих ветках были правки в составе исходных файлов (или настройках компиляции), вручную их не объединить, только откатывать и последовательно применять все испраавления.

Обычно бывает достаточно просто переименовать файл в *.cpp и соотв. *.hpp.

Эти спецы из ИАР давно забили на свой же штатный IDE и написали человеческий плагин для VS Code для ARM. Поэтому RabbitRabbit отчасти прав говоря, что штатная IDE от IAR мрак, но, видимо, не в теме, потому что плагин для VS Code, а раньше для Eclipse, показывают наличие у IAR полноценной современной IDE. Я сейчас пришёл в компанию, где всё ПО за последние 15 лет было написано под IAR, да ещё под древней 7.50. Поставил плагин от IAR для VS Code и получил вполне не плохую среду для программирования. Не всегда есть возможность пересесть на новую среду разработки в силу наличия огромной базы существующего ПО, кучи методик и инструкций, привязанных к используемой для среде разработки, поэтому в таких случаях лучше искать способ своего обустройства в устоявшейся инфраструктуре компании, чем обзывать сотрудников дидами и идти на работу к малолеткам-ардуинщиками, меняющих IDE чаще, чем носки.

все деньги каазенные, не так опасно для бюджета когда пилят но деньги вкладывают внутри страны, а вот всякие самозанятые любители китавйских плат пилят бюджет и выводят деньги для закупки за рубежем. А потом когда товар ввозит контробандой еще раз обворовывает бюджет и всех граждан не уплачивая налоги.

и правильно делает ))

вот такой рубец регулятор . датчик можно медный . лучше 100 М. о обязательно чугунная или стальная чушка. питание отдельная песня.

messenger, в вашем ТЗ не указано несколько очень важных моментов, меняющих объём и сложность работы принципиально, что наводит на мысль, что ТЗ просто "спущено сверху", и никем особо не продумывалось. Например, вот это "±0,1оС" - это в точке измерения температуры, или максимально-допустимый градиент по всему объёму? Циркуляция воздуха автоматом такого не обеспечивает... Или, например, совершенно не указано, какое у содержимого камеры собственное тепловыделение и масса (это мощность нагревателя и охладителя, чтобы уложиться в те 2 часа установления температуры)... Или можно двое суток? Если это для биологии, то что насчёт стабилизации влажности и допустимого количества остаточных паров масел (от того же вентилятора), испарений от нагревающихся материалов... Вы б ТЗ более подробное выложили, а то так - как-то несерьёзно. Пока ваше предложение не кажется интересным, большая вероятность, что в процессе работы вылезут новые вводные, реализация которых не уложится в контракт, контракт будет не выполнен, исполнитель будет назначен крайним... Ну, в общем, как это сейчас слишком часто бывает...

В симуляторе http://schmidt-walter-schaltnetzteile.de/smps_e/spw_smps_e.html набрал Fly 300/5V с галочками "proposal". Записал соотношение витков N1/N2, индуктивность первички L1, высчитал AL сердечника. "Перевернул" трансформатор, поменял входное с выходным, подставил обратное значение N2/N1, поиграл "proposal" и током нагрузки при 300 на выходе. Получилось. Резюмирую, работоспособность будет зависеть от частоты, нагрузки и снаббера.

Абсолютно всё. Упругость металлов не оценивается по двухбалльной шкале: упругий/неупругий; причём модули упругости большинства металлов примерно одного порядка: Усилие прижима не зависит от времени - даже для свинца оно не станет со временем равно нулю. Обжимные клеммы никогда не делаются из меди, только из латуни. Усилие прижима обеспечивается не сплющиванием медного провода, а напряженным состоянием прижимных частей клеммы. Про "холодную сварку" - смешные выдумки. Не окисляются места прижима. Использую провода от автомобилей 80-х 90-х годов - состояние в идеале.

Да, с обратным напряжением я погорячился. Но начальная фаза сети (V1) и микросекундные помехи (V2) - прибьют это на раз. Может было бы целесообразнее перенести стабилитроны на вход, сразу в виде двунаправленного TVS.

А разве он не должен обрабатывать транзакцию? Вот проц метнул со своей стороны транзакцию записи, она долетела до моста, от него пришло подтверждение (BRESP), но транзакция болтается в очереди моста и ждёт, когда её PL сторона обработает -- прочитает. А там никто не шевелится. А проц всё мечет и мечет. Когда эта небольшая очередь заполняется, проц при очередной попытке получает отлуп и аппаратное исключение. Я не ведаю деталей, как сделано в MPSoC, но, например, про 7000 сказано про его AXI GP мост: Т.е. там есть небольшая аппаратная очередь, чтобы можно было слать транзакции, не дожидаясь обработки текущей. Но чтобы эта очередь не встала колом, приёмная сторона должна своевременно отрабатывать свою роль. Подозреваю, что у MPSoC тоже сделано похожим образом, отличия количественные. А может и тоже такие же. А 12 получается вместо 8 потому, что там на интерконнектах тоже есть буферизация -- путь длинный, с переходами через несколько тактовых доменов, без локальных буферов не обойтись. Вот и получается 8 в мосте и 4 по дороге до него. Сделайте чтение из моста на стороне PL, если этого там нет.

вот здесь - Выбор цифрового оcциллографа, но тема давно не обновлялась, сейчас по озвученной цене китайских множество и для большинства ремонтных задач вполне хватит. Предпочел бы Rigol, Siglent как более серьезные бренды, а Owon и т.п. не знаю, может уже тоже нормальные. Из портативных "радиолюбительских" - DREAM SOURCE lab неплохо выглядят и показались поудобнее чем Fnirsi.

Изменить как положение вывода в Part так и сам Part для выводы можно прямо на схеме. Но это не хорошая практика. не советую

Ставите к AVR в помощь BT815, BT817 и подобные, и всё летает.

Четыре сигнала вместо двух.

С чего это он закрыт? Оба открыты

Продолжение Марлезонского балета? Вас же вроде уже "слили заболтав глупостями"? Или вы уже следующий, кого этим озадачили? Кроме ёмкости, в системе с вашим датчиком есть ещё банальная токовая утечка и диэлектрическая постоянная измеряемой субстанции. Обе ненормируемые и "плавающие". Разве ваша же фраза не заставила вас хотя бы чуть задуматься?

Для бултыхающейся жидкости без пены сейчас неплохо работаю СВЧ датчики миллиметрового диапазона. Это конечно если можно отверстие в бак для датчика сделать. По сравнению с ультразвуковыми- меньше ошибки от изменения температуры. Даже у китайцев на али уже доступны, но не корпусированны для условий топливного бака и метрологию конечно надо будет самому переделывать. С другой стороны у тех же китайцев есть УЗ датчики для измерения уровня жидкого пропана в баллоне сквозь стенку, т.е датчик крепиться снаружи баллона на дне и УЗ при измерении пробивает и стенку баллона и столб жидкости. Но при изменении температуры требует перекалибровки. Ну и как то был случай трубку- коаксиальный конденсатор емкостного датчика в которой что то застряло и мешало измерениям, а поменять было нельзя использовали с дешевой nanoVNA в режиме рефлектометра. Рефлектометр ведел и застрявшее что то и уровень жидкости.

Я бы трансформатор тока применил. Что-то вроде горизонтальных Е10-Е13, 1:50, где первичная обмотка - П-образная полоска медной ленты поверх вторичной обмотки, концами распаянная в плату. Прочитав всю тему, скажу - пустое это дело. Если бы это было нужно - производители самокатов давно бы так уже делали.

Я в прошлом году офигел от суммы налогов, которые пришлось платить, так что не надо ля-ля, и мои денежки там тоже есть, и всех, кто в России налоги платил и плакал... Походу этой буквой маркируется все вот такое "отечественное"... Разумеется скажется, все их "мегакорпорации" по мегараспилу все на наших налогах пойдет, не сомневайтесь, а вот чего они разовьют на них - скорей всего такой же "гибкий экран чубайса"... Есть такое выражение "не можешь с..ть - не мучай жопу" - вот это как раз про наши процессора, ну нет ни технологий, ни идей, ни людей путевых, так отстаньте, ну скажите что-нить умное, там нет рынка сбыта, никогда не выйти на окупаемость и пр. и тупо покупайте у тех, кто смог, у того же Китая, только делайте это честно, но о чем это я , чет забыл походу, где живу... Вот в соседней теме "НИИЭТ выпустил миллионный микроконтроллер на новой линии корпусирования" Не в России Т.е. переводим с номенклатурного на русский - Это Китай сделал нам миллионный чип, вот тяк))

Да, задержки в элементах он не учитывает: Быстродействие сейчас проверяют с помощью Static timing analysis. Altera уже давно не поддерживает Gate-level timing simulation.

n017 n018 что за обозначения ?....точки какие-то ?....искал на схеме, не нашел

Этой козе, такой баян точно не нужен.

Иллюзия по части "необходимой" точности основана по большей части "здоровыми" амбициями потенциальных потребителей. Внимательно почитайте инструкцию ко всем особо "точным" средствам измерения - там указаны не менее "жесткие" условия, при которых названная точность будет иметь место. Зайдите в свой отдел стандартизации и проконсультируйтесь о возможности поверки вашего прибора. Вам просто выдадут список средств измерений, поверку которых они выполняют, - список приборов будет на удивление коротким. Это означает, что все остальные приборы будут обеспечивать заявленную "точность" только в течение срока, который будет указан в паспорте на прибор. В большинстве случаев этот период не более года после его приобретения в магазине.

Нормальный элемент. По-другому никак, все течет и все меняется. Калибруют все по нормальному элементу.