alexunder

Думать о производстве есть смысл, если Вы собираетесь помимо собственных нужд торговать этими сопротивлениями. Опять же, вам все равно нужна качественная "обмериловка сопротивлений" независимо от того покупаете вы их или производите. Так проще уж купить измерительное оборудование для селекции хороших резисторов, приобретенных на стороне, чем это же оборудование + техпроцесс + человеко-часы для собственного производства. Ar для сварки не такой чистый как для PVD, особенно, когда речь идет о столь особенных сопротивлениях. Аппарат на приведенной Вами картинке очень примитивен. Это игрушка, чтоб в дамскую сумочку положить: нагрева подложки нет, замучаетесь с неоднородностью толщины, пористости и других параметров пленки; дурацкая резинка по кругу, плохой вакуум, плохое воспроизведение результатов. Такие сундучки используют для наипростейших напылений (в основном металлов) для покрытия проводящей пленкой диэлектрических образцов для анализа в СЭМ. Брать следует аппарат, чтоб хотя бы под размер 6"-8" подложек. По-моему, в Новосибирске кто-то делал подобное оборудование. Вдобавок к перечисленному @Pengozoid не забываем про оборудование для анализа тонких пленок: профилометр, фото-рефлектометр и, возможно, ИК-спектрометр (на просвет).

Стоимость установки для нанесения, материалов и газов высокой чистоты, оборудования для распила подложек (и "корпусирования"), метрологического оборудования для анализа тонких пленок (механические и электрические х-ки) и готовых сопротивлений, а также человеко-часов, необходимых, чтобы все это "поднять" (и постоянно поддерживать) перекроет стоимость одного только метрологического оборудования, необходимого для отсева покупных сопротивлений.

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

Это как? Создать свой сигнал GPS? P.S. 80C186 - красота!

Прочёл всю тему, но так и не увидел явных аргументов и предпосылок для применения ООП. А значит что? А значит, автору ООП для данной задачи не нужно.

Уважаемый Александр! Вы зачем-то придрались к (весьма гибкой и удобной) реализации маленькой толики тестовой системы. Мне несложно оперировать двумя языками. Я лишь единожды подготавливаю общий инструментарий для инженеров-тестеров, а тем требуется только знание Питона для написания тестовых скриптов и их адаптации под конкретный чип. С типозащищенностью и "антибажностью" C# все в порядке как всегда :) Но дело даже не в этом, т.к. тема совсем о другом. Тестовая система предназначена для первичных тестов, а далее, рутиной обмерки характеристик аналоговых ИМС (КМОП сенсоры). Система (как правило в виде одной "материнской платы") обладает программируемыми источниками питания, процессором в ПЛИС для генерации сигналов управления испытуемой ИМС а так же системой сбора кадров изображения и "упаковки" оных в CameraLink. Программы для процессора пишутся на простом Си-подобном языке, вот там-то и обеспечивается жесткий тайминг. Компилируются и вызываются эти микропрограммки из Питона, куда возвращаются полученные изображения. Само собой никакого риалтайма на питоне! Но из Питона оператор может управлять чем угодно: запускать программку в ПЛИС, собирать кадры изображений, проводить их обработку, генерировать отчеты и т.п. В данной теме я лишь обсуждаю UI для дерганья отдельными битиками внутри регистров конфигурации большого аналогового зверя (как например, на картинке внизу)!

В чем именно замороченность? По-моему, все очень просто. uCProbe - это какой-то очередной LabView, заточенный под работу с конкретными МК и вообще он для эмбеда. А у нас не эмбед совсем.

Конечно же Windows, просто Windows 7 :) Форма сделана на C# с использованием (стыдно признаться) WinForms, собрана в DLL (SpiRegistersTable.dll). У формы есть несколько делегатов, которые будут вызываться на события по обновлению поля регистра, запросу на чтение всех регистров и т.п. public event EventHandler<RegFieldEventArgs> FieldChangedEvent = delegate { }; public event EventHandler<SeqcRestartArgs> SeqStartEvent = delegate { }; public event EventHandler ReadAllRegs = delegate { }; Затем эта DLL подцепляется к Питону: # импортируем сборку, используя CLR import clr clr.AddReferenceToFileAndPath("SpiRegistersTable.dll")); from SpiRegistersTable import RegsControlForm; # из пространства имен библиотеки SpiRegistersTable вытаскиваем нужный класс regs_ctrl = RegsControlForm(default_spi_cfg, 'notdef', False); # создаем экземпляр формы RegsControlForm # подписываемся на делегаты формы regs_ctrl.FieldChangedEvent += field_change_handler; regs_ctrl.SeqStartEvent += start_sequence; regs_ctrl.ReadAllRegs += synchronize_registers; # обработчики событий def field_change_handler(*args): pass; # обработка изменения поля регистра def synchronize_registers(*args): pass; # вызов чтения всех регистров из DUT Мы используем Питон, реализованный на C#, именуемый IronPython. К такому питону посредством CLR легко подцепляется всё что написано на .NET. В свое время это сделало его очень популярным, но Microsoft забросили его в последние годы (как и многие другие замечательные вещи) и теперь проект не развивается. Мы постепенно переходим на обычный Питон (именуемый также CPython), но и в него можно "протащить" дотнетовские сборки. В общем же Питон используется для быстрого написания тестовых скриптов инженерами-тестерами. Как показывает практика, это намного эффективнее использования компилируемых языков. А уж из Питона "видна" вся тестовая система, включая шину SPI, на которой сидит тестируемый DUT, на которую "выплёвываются" посылки, сформированные обработчиками событий от формы.

В идеале так и должно быть. Но функционал регистров меняется от проекта к проекту, а сочинять функционально-ориентированный интерфейс как у AD из сообщения @Arlleex для каждого чипа лень да ни не всегда требуется. Например, на картинке в первом сообщении в середине есть несколько 9-битовых полей - это ЦАПы для установки внутренних смещений. Их можно было бы обернуть в источники напряжения с установкой напряжения, а не кода. Но в другом проекте их может не быть вообще. На моей картинке есть так же регистр адреса столбца (чип - КМОП сенсор изображения) - rowaddress, а в других проектах адрес может выбираться не через регистр, а внешними синхр. импульсами. В общем, карта битовых полей - наиболее универсальное средство в моем случае. Спасибо. Да, отображения в недесятичных форматах давно нужны. Софта нет как такового. Эта форма общается с программой на Питоне, а последняя по интерфейсу CameraLink с платой, на которой находится тестируемый чип.

Приветствую! Для конфигурации ИМС используем набор регистров, доступных по интерфейсу SPI. Регистры бывают разной длины (как правило, не больше 14 бит), отдельные поля внутри регистров так же могут быть разной длины. Для первичного тестирования поведения чипа в статическом режиме я сделал форму, в которой содержимое отдельных полей каждого регистра может меняться на лету. Пример такой формы с картой регистров представлен на картинке ниже. Регистры расположены по вертикали, содержимое регистров (отдельных битовых полей) - по горизонтали. Внутри каждой ячейки отображено имя поля и его текущее значение. Принцип работы прост: оператор нажимает на ячейку, меняет значение, форма отсылает команду по SPI, оператор наблюдает, что происходит с ИМС и т.д. Для каждого проекта своя карта регистров, которая "подцепляется" к форме из JSON файла. Форма создавалась по-быстрому и, как это обычно бывает, так и осталась в первозданном виде. Хотелось бы сделать что-то более удобное или компактное, даже не знаю, что конкретно в этой не устраивает, но хочется, чтобы содержимое отображалось покомпактнее. Наверняка многие сталкивались с задачами удобного отображения конфигурации регистров. Буду рад, если кто-нибудь поделится своими или чужими визуальным решениями.

Насколько я помню, это не является жестким требованием для магистров. Не встречал такого в Европе от слова "совсем". Научная новизна необходима для кандидатских (PhD).

Так и знал, что Вы C8051 порекомендуете. Очень хорошее впечатление эти мк оставили в своё время. А вот распространённость у EMF8/51 и в самом деле невысокая не только в РФ :(

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

А вот не в курсе был, поискал, вроде как все тоже самое: используются электронные переходы энергия между которыми будет соответствовать энергии фотона (в случае ТГц излучения - десятки мэВ). Это получается на переходах разных матералов или даже квантовых ямах. Прикладываю обзорную статью на русском. thz.pdf

В целом примерно так, да, но все зависит от среды и устройства излучателя. Есть структуры, где детектирование MID-IR излучения тоже за счет переходов электронных уровней (детекторы на основе примесных уровней в кремнии).