Создание профессиональной ассоциации по микроэлектронике

[aleksandr-zh 0]

блин, это был сарказъм ...

[byRAM 1]

49 минут назад, aleksandr-zh сказал:

блин, это был сарказъм ...

Понятно. Да вот только родственники разные бывают. Бывают трудовые династии, у которых есть способности и тяга к какому-то делу. Бывают пары, образовавшиеся на предприятии. А бывают и блатные, не спорю, их много.

[Sverlo1 0]

09.05.2022 в 21:17, Sverlo1 сказал:

>> Интересно, но как это натянуть на современность?

Уже натянули...   https://habr.com/ru/company/selectel/blog/653749/

На 28-нм технологию власти планируют перейти к 2030 году. 
Стоит отметить, что зарубежные производители освоили 4-нм техпроцесс и понемногу реализуют планы по разработке чипов по 3-нм и 2-нм техпроцессу.

 

 

[baumanets 0]

Как я понимаю, это опять лысенковщина.

Они хотят МЭМСами управлять пучком 13,5 нм излучения.

У меня собственно 2 вопроса. О возможности на циклотроне получить монохроматический (или близкий к нему), одномодовый пучок излучения.

В Западных компаниях, это решили обстрелом оловяных капель Co2 лазером.

		EUV ArF immersion Wavelength 2% FWHM bandwidth about 13.5 nm 193 nm Photon energy 91...93 eV 6.4 eV Light source CO2 laser + Sn plasma ArF excimer laser Wavelength bandwidth 5.9%[26] <0.16%[27] Secondary electrons produced by absorption Yes No Optics Reflective multilayers (~40% absorbing per mirror) Transmissive lenses Numerical aperture (NA) 0.25: NXE:3100 0.33: NXE:33x0 and NXE:3400B High NA (0.55): in development 1.20, 1.35 Resolution spec k1 = resolution / (wavelength / numerical aperture) NXE:3100: 27 nm (k1=0.50) NXE:3300B: 22 nm (k1=0.54), 18 nm (k1=0.44) with off-axis illumination NXE:3350B: 16 nm (k1=0.39) NXE:3400B/C, NXE:3600D: 13 nm (k1=0.32) 38 nm (k1=0.27) Flare 4%[28] <1%[29] Illumination Central angle 6° off axis onto reticle On axis Field size 0.25 and 0.33 NA: 26 mm × 33 mm High NA: 26 mm × 16.5 mm[30] 26 mm × 33 mm Magnification 0.25 and 0.33 NA: 4X isomorphic High NA: 4X/8X anamorphic 4X Ambient Vacuum hydrogen Air (exposed wafer area underwater) Aberration control (including thermal) None Yes, e.g., FlexWave[31] Illumination slit Arc-shaped[32] Rectangular[33] Reticle Pattern on reflective multilayer Pattern on transmissive substrate Wafer pattern shift with reticle vertical position Yes (due to reflection); ~1:40[34] No Pellicle Available, but has issues Yes Wafers per day (depends on tool and dose) 1500 6000 # tools in field > 90 (all 0.33 NA tool models) > 400
		Т.е. у наших освоителей бюджетов не готов ни источник излучения, ни система передачи на шаблон, ни система экспонирования. Я так понял, они хотят повторить вот это: https://ru.wikipedia.org/wiki/Европейский_рентгеновский_лазер_на_свободных_электронах Вместо того, чтоб делать 40 нм на иммерсии мультипаттернинге (несколько шаблонов) честных 193 нм эксимера, прокачивать изготовление оптики, что нашло бы применение не только в микроэлектронике, но и в телескопах и спутниках, они хотят попытаться нарастить Брэгговские слои на подвижное зеркало МЭМС и впридачу этого построить циклопическое сооружение.

[Sverlo1 0]

>> Т.е. у наших освоителей бюджетов не готов ни источник излучения, ни система передачи на шаблон, ни система экспонирования.

 

Я не зря проговорил натягивание совы на глобус.

Ты упускаешь что-то важное в этой цепочке.

Да и сама цепочка не такая будет, как мы думаем.

Достаточно статью на хабре повнимательней прочитать.

[Sverlo1 0]

https://habr.com/ru/post/668368/

Остаётся над этим только похихикать...   :(

[byRAM 1]

19 минут назад, Sverlo1 сказал:

https://habr.com/ru/post/668368/

Остаётся над этим только похихикать...   :(

А есть ли нужда в чтении статей долбодятлов с хабра?

Какое отношение имеет эта статья к этой теме?

[makc 6]

16 часов назад, byRAM сказал:

А есть ли нужда в чтении статей долбодятлов с хабра?

Читать стоит не только статьи, но и комментарии. Зачастую там намного больше информации, чем в статье. А вообще читать нужно, иначе будет информационный вакуум и если вам не нравятся такие статьи - напишите лучше, опубликуйте на том же Хабре и мы все почитаем, просветимся и поблагодарим вас за науку, ну или покритикуем... Уж как получится...

16 часов назад, byRAM сказал:

Какое отношение имеет эта статья к этой теме?

К сожалению показывает отношение к отрасли и уровень разработчиков.

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

[byRAM 1]

16 минут назад, makc сказал:

К сожалению показывает отношение с отрасли и уровень разработчиков.

Это мнение одного человека, при чём тут остальные разработчики?

Я бы понял, если бы эта статья была построена на соцопросе и голосованиях.

Зачем тащить в тему чьё-то мнение и его сразу выдавть за истину?

Ну и программист МК - это как колорадский жук на картошке (микроэлектронике). Она никоим образом от жука не зависит, он паразитирует на ней.

Edited May 29 by byRAM

[Sverlo1 0]

1 час назад, byRAM сказал:

А есть ли нужда в чтении статей долбодятлов с хабра?

Какое отношение имеет эта статья к этой теме?

Судя по кометам, народ там очень даже грамотный.

Даже если не согласен со статьёй, вполне ожидаема народная толковая разборка, и/или капитальный разгром!!!

 

А по второму вопросу Макс уже ответил...

Могу только добавить из тех комментов:

Я по молодости думал, что это наша отечественная специфика, но нет - говнокод в embedded - явление, увы, интернациональное.

И если там где Embedded Linux там еще обычно все не так плохо, то чем ниже уровнем (особенно под bare metal или под крохотные rtos), тем страшнее. Об этом
не раз уже говорили здесь на хабре (в первой половине одной нашумевшей статьи, например, да и еще много где в комментариях).
Объяснения этому можно найти разные. Долгое время специфика embedded состояла в том, что сам по себе функционал у железок был весьма ограничен и прямолинеен (несколько основных функций), время не жизни, а точнее развития продукта не слишком большое (сделали изделие и клепаем много лет, ну или спустя N лет выйдет новая железка), а ресурсы очень ограничены (нужно экономить каждый байт и каждый такт, иначе трындец). В подобных условиях о читаемости и архитектуре никто, понятное дело, думать не будет.

И не всё так плохо:

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

Edited May 29 by Sverlo1

[makc 6]

4 часа назад, byRAM сказал:

Это мнение одного человека, при чём тут остальные разработчики?

Сформулированное и оформленное мнение как минимум заслуживает внимания и как максимум обсуждения.

4 часа назад, byRAM сказал:

Зачем тащить в тему чьё-то мнение и его сразу выдавть за истину?

Простите, но я не вижу, чтобы кто-то его выдавал за истину.

4 часа назад, byRAM сказал:

Ну и программист МК - это как колорадский жук на картошке (микроэлектронике). Она никоим образом от жука не зависит, он паразитирует на ней.

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

PS: как ни странно, архитекторы МК и SoCов пытаются учитывать нужды программистов, как прямых "потребителей", которые безусловно влияют на выбор решений. Поэтому нивелировать роль программистов в развитии архитектур и микроэлектроники никак нельзя. Правда не всегда это доводит до добра, но это уже совсем другая история. 

[byRAM 1]

9 часов назад, makc сказал:

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

PS: как ни странно, архитекторы МК и SoCов пытаются учитывать нужды программистов, как прямых "потребителей", которые безусловно влияют на выбор решений. Поэтому нивелировать роль программистов в развитии архитектур и микроэлектроники никак нельзя. Правда не всегда это доводит до добра, но это уже совсем другая история. 

Так я и сам тоже являюсь программистом, в т.ч. и микроконтроллеров, и примерно понимаю какое место они имеют в плане влияния на микроэлектронику. После микросхемотехников, технологов и схемотехников их влияние весьма отдаленное, т.к. многие из узкоспециализированных программистов МК ни ассемблера, ни схемотехники не знают.

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

Попадались такие персонажи, которые даже Си с мусором смешивали, кодили исключительно на C++, потому как не знают ни ассемблера, ни схемотехники, а произошли от программистов компьютеров и IT, но там не задалось.

Edited May 30 by byRAM

[Electrobit 0]

15 часов назад, makc сказал:

показывает отношение с отрасли и уровень 

А вы что думаете, в других отраслях какое-то другое отношение или какой-то другой уровень?

[makc 6]

1 час назад, byRAM сказал:

Так я и сам тоже являюсь программистом, в т.ч. и микроконтроллеров, и примерно понимаю какое место они имеют в плане влияния на микроэлектронику. После микросхемотехников, технологов и схемотехников их влияние весьма отдаленное, т.к. многие из узкоспециализированных программистов МК ни ассемблера, ни схемотехники не знают.

Вы меня похоже не поняли. Для программистов МК контроллер является инструментом решения их задач, которые они решают на том или ином языке (от Форта до Раста и Java с Python). Но именно они своими задачами определенно задают тренд для разработки новых МК в глобальном масштабе, хотя и не пишут ТЗ на них и не всегда понимают, как там что внутри работает. 

Статья, кстати, показывает этот разрыв в понимании и даёт понять, что есть специалисты, понимающие не только абстрактные понятия верхнего уровня, но их мало. 

1 час назад, byRAM сказал:

Попадались такие персонажи, которые даже Си с мусором смешивали, кодили исключительно на C++, потому как не знают ни ассемблера, ни схемотехники, а произошли от программистов компьютеров и IT, но там не задалось.

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

49 минут назад, Electrobit сказал:

А вы что думаете, в других отраслях какое-то другое отношение или какой-то другой уровень?

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

[dxp 0]

22 часа назад, makc сказал:

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

С интересом посмотрел бы на юнит тест для таймера или UART'а.