- А чего вообще надо делать, если находишься в прерывании по
окончании задания, и требуется еще раз это же задание запустить? Kceния(694 знак., 27.08.2020 20:16, MCU, полностью)fk0
- Интересует работа constexpr. Так вот столкнулся с такой ситуацией,
что в одном классе происходит выход за массив заполнения. Массив
заполнялся на этапе компиляции(проверено отсутствие конструктора в
list). Предупреждений ничего не было. Все компилилось и работало.
Стоило перенести данные из секции .text в секцию .data, пошел
трабл. При upcast адрес присваивался не корректный. Стало
интересно, как внутри устроен constexpr. - Constantin24(11.08.2020 17:37, MCU, полностью)
- Четырехкнопочная клавиатура по горизонтали Up Down Enter Esc. Как
должны быть расположены кнопки? - VLLV(07.08.2020 22:08, MCU, полностью)
- А я бы руки отрывал за такие клавиатуры. За декаду в телекоме
приходилось работать с разными устройствами. В том числе и с
клавиатурой вряд. Привыкаешь к одному интерфейсу, пытаешься
работать на другом, с другой раскладкой. И тупишь. Nikolay_Po(513 знак., 09.08.2020 14:58)
- Индикатор повернуть на 90 градусов?) - VLLV(10.08.2020 05:41)
- Выше я написал как. Если одна строка, то делаем вид, что листаем
влево/вправо. Если несколько строк, то показываем три со стрелками. - Nikolay_Po(10.08.2020 07:16)
- У меня несколько приборов с 4 кнопками, раньше не было по
горизонтали. В этом, новом, расположить по другому не было места, и
еще - нет строчного универсального текстового индикатора, а есть
специально заказанный ЖКИ. Заказчик логику UI не дал, и у меня в
голове она никак не складывается. Это самый худший вариант
проектирования, боюсь, что будет, как в часах 30-летней давности,
когда логика работы не будет интуитивно понятная. VLLV(357 знак., 10.08.2020 08:14)
- А людей изобревших телефонную цифровую клавиатуру, или компьютерную
(на калькуляторах) -- не знаю уж каких, но вообще сжечь хочется! fk0(1 знак., 09.08.2020 16:04, ссылка, ссылка)
- Реальный пример: ESC ENTER DOWN UP. Объясняю: il-2(353 знак., 09.08.2020 14:22)
- Джойстики "в линию" были сделаны Вниз-Вверх-Огонь. Это стандарт со
времен ZX Spectrum. И это работает нормально, ни у кого проблем не
вызывало. Возникает единственный вопрос где наиболее эргономично
сделать ESC/отмену? До? Или после? Мне наиболее логичной выглядит
группировка Да-Отмена. Поэтому я бы расположил ESC в конце. Итого:
Вниз-Вверх-Да-Отмена. RxTx(7 знак., 09.08.2020 01:13, ссылка)
- "Вниз", "вверх", "отмена", "ввод". Я предполагаю, что "отмена" --
редко нажимаемая кнопка. Иначе "отмена", "вниз", "вверх", "ввод". - fk0(08.08.2020 01:40)
- Более употребительные (Up/Down?) - ближе к "руке дающей". Менее
употребительные (ESC/Enter) - дальше. Для правшей - то же самое
слева направо. - ToчкaOпopы(07.08.2020 23:24,
)
- Esc - Up - Enter - Down. Up - Down рядом это очень неудобно для
пальцев, Enter неудобство разбавляет раздвигая пальцы ))) . Esc
привычно слева. - m16(07.08.2020 22:57)
- яб сделал так Esc Down Up Enter - Aleksey_75(07.08.2020 22:54)
- Как перечислены. - teap0t(07.08.2020 22:24)
- Silabs C8051F064: использование старших портов (P5-P7) как GPIO. PiTeK(405 знак., 06.08.2020 11:33 - 11:38, MCU, полностью)MBedder
- Приведи пожалуйста ссылку на C стандарт подтверждающую слова: "про
невыравненный доступ сказано -- поведение неопределено"? Уточню:
речь идет о void* указателе. - RxTx(24.07.2020 14:49 - 26.07.2020 13:02, MCU, полностью)fk0
- Сонму копьеметателей: Пощупал конкретнее: В MDK ARM v4 пофиг всякие
#pragma pack(1), __align(4), __packed и их полное отсутствие.
Похоже компилятор, имея в командной строке " --cpu Cortex-M3",
всегда генерит __aeabi_memcpy() в соответствии со здравым смыслом,
имея указатели (void *)... Тут другое интересно - третий параметр в
"шибко грамотном" MDK ARM v5. Что там вещает стандарт?
Руководствуясь тем же здравым смыcлом, там должно быть количество
БАЙТ и компилятор должен Гyдвин(82 знак., 27.07.2020 12:30)
- Где я говорил про void*? Речь про указатель на int. fk0(281 знак., 24.07.2020 15:23)
- Ты написал в прошлом сообщении (цитирую твои слова): "а с некой
абстрактной моделью вычислительной машины заданной СТАНДАРТОМ
ЯЗЫКА". Ты выражение "стандарт языка" понимаешь как-то не так как
все люди? Какие еще "оптимизаторы", какие "кодогенераторы" в
стандарте языка C? Вот я тебя и прошу подтвердить твою же фразу.
Мне еще в 2-3х сообщениях требовать с тебя цитату из стандарта? Или
не будем валять дурака, и ты уже все понял, что по стандарту языка
C прав именно RxTx(558 знак., 24.07.2020 15:53)
- ISO/IEC 9899:201x, разделе 6.3.2.3 Pointers, параграф 7: fk0(851 знак., 24.07.2020 17:18)
- Баг в GCC, а не в Clang и вообще совершенно про противоположное,
мол нет оптимизации. Остального не понял -- научись выражать мысли
на понятном языке. Гудвин не прав, т.к. при использовании
стандартных же любых конструкций языка (без упакованных структур)
"баг" воспроизвести невозможно. А то, что он воспроизводится при
использовании упакованных структур совершенно естесственно, и
кстати в баге gcc есть на это комментарий (см. ссылку) -- вот так
проблему можно обойти. Какие fk0(1225 знак., 24.07.2020 16:56, ссылка)
- Давай укоротим проблему, насколько это возможно, т.к. нет времени и
я устал. С GCC и багом вряд ли я был прав, несмотря на то что
внутри armcc.exe v4 v5 масса строк "GCC" и отсутствует "CLANG",
armcc это отдельный компилятор. В v6 он называется armclang. Со
стандартом вышло смешно. Формально ты привел действительно ровно
то, что я спросил. И бессмысленно утверждать что разумеется вопрос
был о прямых виновниках разговора: о функции memcpy (она оговорена
в стандарте) и о 6.2 RxTx(1116 знак., 24.07.2020 22:30)
- На счёт memcpy: с одной стороны да, ты можешь подсунуть
невыравненный адрес и всё должно работать. И действительно, если ты
руками там как-то аллоцировал память, посчитал адрес, он оказался
невыравненный -- всё будет работать. Будет вызвана "неоптимальная"
версия memcpy. А в случае с гудвиновским багом компилятор был
обманут: ему сказали, что будеут копировать вот такой-то тип, а
этот тип никак не может лежать на невыравненном адресе,
следовательно, компилятор знает, если fk0(1323 знак., 25.07.2020 02:24, ссылка)
- Извини, но ты загнался. LightElf(632 знак., 26.07.2020 14:26)
- Чего ты привязался к memcpy. Я рассказал выше как получается баг. Вместо memcpy может быть любое обращение по указателю/ссылке. К слову и gcc и clang даже варнинг имеют специальный:
-Waddress-of-packed-member. Его невозможно выполнить в любом коде.
А ты хочешь сказать, мол memcpy на 32-битной машине должен
копировать по байтику вместо 4-х за раз, а на 64-битной по байтику
вместо 8, а на машинах где есть векторные инструкции... вообще
страшно. И да, оптимизатор fk0(728 знак., 26.07.2020 15:24)
- Я привязался к memcpy ровно потому, что ее параметры прямо декларируются как void*. void* означает, что указатель может быть любым. И компилятор обязан этот факт учитывать. Тяготы и лишения
компиляторописателей меня интересуют постольку-поскольку. - LightElf(26.07.2020 15:35)
- И он работает с любым типом корректно. Пока ему голову не
заморочили взятием указателя на выровненный тип в упакованной
структуре. В каком-то смысле, это недоработка компилятора, но
стандарт не нарушается. - Nikolay_Po(26.07.2020 15:39)
- Мы говорим о нестандартном (но весьма распространенном) расширении.
Причем тут ссылки стандарт? - LightElf(26.07.2020 15:42)
- ОК. С точки зрения работы расширения проблема налицо. Но fk0
принялся ругать говнокод и защищать компилятор. За что ему большое
спасибо! Всё подробно разжевал, ссылки привёл. Тема была - супер!!! - Nikolay_Po(26.07.2020 15:47)
- Тогда на что ссылаться? По стандарту всё ок. А по мнению LightElf
не ок? Нужен какой-то формальный документ, который описывает
поведение компилятора. - fk0(26.07.2020 15:44)
- На документацию конкретного компилятора - LightElf(26.07.2020 15:48)
- Где в документации описывается что должно происходить в случаях: fk0(232 знак., 26.07.2020 15:59)
- А знаешь почему не описывается? Сям (компилеру и стандарту) просто
чхать, какая там структура. Осознай это. Упакованная, не
упакованная - именно сишечке по барабану. Осознай: требования по
default data alignment (вообще по типам, не только выравнивание, но
и размер) оно существует только для конкретной CPU платформы, не у
компилятора. И padding (выравнивание) структур делает не компилятор
следующий стандарту C, а бэкенд, именно он отвечает за платформу,
ее выравнивание, RxTx(223 знак., 26.07.2020 17:22)
- Логично, что implementation defined behaviour должен быть описан в
документации конкретного implementation. Разве не так? - LightElf(26.07.2020 17:21)
- Я выше сказал, что проблема возникает не в memcpy, а в выражении
&IH.conag. Что там после -- уже не важно. Результат данного
выражения не валиден. Он содержит корректное числовое значение, но
некорректный тип, из-за чего оптимизатор принимает не верное
решение. - fk0(26.07.2020 15:39)
- Опыт жизни и общефилософское наблюдение показывают: дискуссия
(разговор, беседа) только тогда здрава, заканчивается познавательно
и позитивно, когда ее участники имеют одну и ту же цель и
заинтересованы в одном и том же результате. Моя цель в данном
случае - выяснить четкую практическую истину. Где что сломалось,
почему, кто виноват и что делать. Твоя цель явно в том чтобы либо
образовать меня/нас, либо просто изложить (насколько ты понимаешь и
способен) свои представления о RxTx(484 знак., 25.07.2020 10:11)
- Нет, это не баг. Потому, что это UB. Потому, что изначально взяли
указатель на int и присвоили ему что-то, что не является указателем
на int (об чём есть строчка в стандарте). Далее уже не важно. Более
того, ещё раз повторю, в рамках СТАНДАРТНОГО C/C++, возникновение
такого "не бага" -- в принципе невозможно. Оно появляется из-за
"бажной" реализации упакованных структур. Ты прицепился к memcpy и
считаешь, что мол баг. Но класс проблем же НАМНОГО ШИРЕ, чем только
memcpy. fk0(858 знак., 25.07.2020 16:40)
- Вчера я прочитал что ты написал и планировал самостоятельно
поэкспериментировать. Слова это одно, а когда начинаешь разбираться
сам легко может быть другое. Не вышло, нет времени, поэтому все что
я здесь пишу основано на исходных данных этой темы. Кстати беглое
изучение документации на тему memcpy показывает что существует
большое пространство для маневра не только с тривиальными ключами
компилятора, прагмами и атрибутами но и что важно, с подключаемыми
либами/выбором obj RxTx(5329 знак., 26.07.2020 12:46)
- UB значит, что возможное дальнейшее развитие сценария писателями
компиляторов не рассматривается. Такого мол изначально не может
быть, программист не допустит. Поэтому если при анализе ситуации
возникает UB, то нет смысл думать что если то, или если это -- оно
в принципе невозможно в корректной программе. Выражение
"&IH.conag" само по себе UB. Поэтому заявить, что мол в
компиляторе баг и притягивать дальнейшие преобразования типа и
вызов memcpy не нужно: в корректной fk0(4348 знак., 26.07.2020 13:47)
- Я считаю мы с тобой обменялись мнениями. Дальше пойдет уже
непринципиальное, и смысла обсуждать мелочи не вижу. Ты видимо
по-инерции, все еще не осознав или невнимательно, невдумчиво
прочитав мой пост, прибегнул к обсуждению стандарта C. Напрасно,
так как твои посты я перечитывал несколько раз, обдумывал, и даже
заметил что самое первое что ты написал в эту тему - это именно то,
что memcpy должна работать без всяких проблем! А потом у тебя
что-то сломалось :) Так вот, RxTx(758 знак., 26.07.2020 16:46)
- Опять за рыбу деньги. Расширение в виде #pragma pack в GCC есть?
Есть. memcpy в GCC есть? Есть. Где-нибудь в доке GCC написано, что
к элементам пакованной структуры применять memcpy нельзя? Нигде.
Бага GCC очевидна. Чего спорить-то? Хоть бы warning выдавал, как
тот же IAR делает (Used the address of unaligned structure member). - LightElf(26.07.2020 15:08)
- Именно в gcc бага нет, как и в clang последних версий. Они
применяют атрибут меняющий alignof на 1 автоматически. И там
получаются инструкции ldrb при обращении и медленная версия memcpy.
Но ты _доказать_ что это баг в keil или ранних версиях clang -- не
сможешь. Баг в чём? Я выше привёл доказательство, что это UB, a
следовательно не баг. - fk0(26.07.2020 15:27)
- Если компилятор рассматривает void* как int*, то это его
обязанность убедиться в допустимости такой замены в каждом
конкретном вызове. - LightElf(26.07.2020 15:39)
- Так для типа int -- всё корректно. Некорректно для того типа, что
лежит в упакованной структуре. Это не int, потому, что int не может
лежать на невыравненном адресе. Это другой тип. Но в структуре
записано что int, что и приводит к краху. - fk0(26.07.2020 15:43)
- Компилятор знает, что в общем случае void* нельзя приводить к int*.
Компилятор либо знает, что тип лежит в упакованной структуре и
должен генерировать правильный код. Либо компилятор не знает, где
лежит данный конкретный int и тогда должен исходить из худшего (раз
уж он поддерживает такие конструкции). А вот это "здесь читаем,
здесь не читаем, а здесь - рыбу заворачивали" есть косяк и бага. - LightElf(26.07.2020 16:22)
- SciFi же дал ссылку на кейловскую документацию: Taking the address of a field in a #pragma packed struct does
not yield a __packed pointer. Так что это не баг, а фичер: в структуре лежит __packed int, а
берёшь адрес, и брюки превращаются... превращаются брюки...
Идиотизм конечно, но bug report слать действительно бесполезно. - йцyкeн(26.07.2020 15:58, ссылка)
- Спасибо. Убедительно. - Nikolay_Po(26.07.2020 13:58)
- Вы заблудились в сферических абстрацкиях в ваккуме (возможно вместе
с компиляторописателями). В данном случае мы работаем на процессоре
M3 который УМЕЕТ делать unaligned access. Поэтому если компилятор
знает что генерит код для M3 то никакого undefined behavior при
невыровненном указателе на ЭТОЙ архитектуре нет - корректное
исполнение обеспечит hardware. - 3m(26.07.2020 11:42)
- К сожалению, я не пользуюсь Кейлом, поэтому про Кейл ничего не
скажу, но эксперименты с ИАРом показали следующее: во-первых, в
ИАРе воспроизвести эту ошибку не удалось. ИАР заменяет memcpy на
__aeabi_memcpy4, если адреса выронены, и на __aeabi_memcpy, если не
выровнены. Если для невыровненных адресов написать __aeabi_memcpy4
ручками, хардфолт происходит, и здесь нет никакой мистики:
__aeabi_memcpy4 использует инструкции LDM и STM, для которых CM3
как раз не умеет делать йцyкeн(109 знак., 26.07.2020 14:40)
- Умеет делать unaligned access??? Есло бы он умел, то изначально
исключения (в чём собственно баг) при попытке этого самого access
не возникал бы! Чтоб оно так работало надо сбросить битик
UNALIGN_TRP в CCR, а компилятор ни сном, ни духом про SFR регистры
и их значения. Это программист их правильно поставить должен
вначале. Ну там ещё есть такая мелочь, что невыравненный доступ
доступен не для всех инструкций... что тянет за собой отдельную
реализацию всех библиотек fk0(267 знак., 26.07.2020 13:14, картинка)
- undefined behavior -- это йуридическое понятие, а не техническое,
есличо - SciFi(26.07.2020 11:55)
- Отдыхать вам, батенька, надо... Компилятор должен делать то, что
ему явно указали. Все. Конец пустому пиздежу... - Гyдвин(25.07.2020 08:43)
- Я привожу в пример C++ потому, что зная как он работает начинает
приоткрываться принцип работы и C компилятора тоже (благо внутри
там у GCC и Clang для обоих языков один "движок"). В языке C нет
некоторых вещей (шаблонов, ADL), что не даёт понять, например,
почему тип важен и как тип может управлять компиляцией. Для C
программиста может быть не очевидно, а C++ программист запросто
может написать свой самодельный memcpy ровно с такими же "багами"
пользуясь только средствами fk0(196 знак., 25.07.2020 01:57, ссылка)
- Не подскажет ли кто по USB ? Устройство получило адрес 2. Но иногда
на шине видны пакеты OUT на адрес 3..!!! (точка 2) Всегда
одинаковые, 31 байт: U,S,B,C,0xb0,0x3b,0x99,0x87. Все остальные 0,
кроме 15-го (==6). Что это ? - Юpий_CB(24.07.2020 18:01, MCU, полностью)
- Добрый день господа. Я в теме stm32 пока не опытен, олаживаю, но не
программист. Есть плата с STM32F105RBT6, прошили - не работает.
Поменяли микросхему, прошили - не работает, тут уже меня попросили
разобраться, посмотрел, питание есть, КЗ не назвонилось нигде, но
генератор не работает. Кварц и кондеры на его ножках тоже поменяли.
Куда смотреть? - DRcp(16.07.2020 12:25, MCU, полностью)
- Там кварц тактовая не так просто заводится... Хотя, если кварц не
генерит, то попробуй генератором пошевелить ногу - Звepoящep(22.07.2020 10:21)
- Спасибо всем ответимшим. Большое! Пока вопрос не продвинулся,
программист на удаленке, но готовится к командировке, вообще не
сунуть.) Разберемся. - DRcp(17.07.2020 11:16)
- Если плата самодельная, возьмите какую-нибудь evaluation board с
таким же МК и пусть сначала там программу запустит. - mrfirst(17.07.2020 06:50, )
- +100500 - MBedder(17.07.2020 12:18)
- Залить готовую рабочую программу мигалки светодиодами. Если
работает, а прошивка програмиста-на-удаленке -- нет, то, скорее
всего, программисту-на-удалёнке надо потренироваться ещё. - BlackPrapor(16.07.2020 18:21)
- Номиналы конденсаторов точно как надо? Кварц рабочий из другой
платы можешь выпаять? - Evgeny_CD(16.07.2020 14:27)
- 1. Сброс. Как запрограммировано, что в схеме. 2. Про генератор уже
сказали. Почитай эти две главы в описании контроллера, это не
сложно. - Evgeny_CD(16.07.2020 14:24)
- Что прошили и что не работает? Если сам не программист, зови
программиста. - VLLV(16.07.2020 12:36)
- Microchip тормозит с поставками General(15.07.2020 18:58, MCU, ссылка, полностью)
- Вопрос по часам реального времени. michas(111 знак., 07.06.2020 06:14, MCU, полностью)
- bcd всего лишь можно показывать без дополнительных телодвижений, а
вот операции с ним производить неудобно, имхо. Бинарное -
универсально. - Xитpый Kитaeц(11.06.2020 08:52)
- Они были в 70-80-х годах, когда не было процессоров с аппаратным
делением/умножением и программное было медленное (ибо 8 бит всего).
Тогда распечатать из BCD сильно быстрей, чем программно вычислять
секунды, минуты... Сейчас совершенно без разницы. - fk0(09.06.2020 10:43)
- Медведева на вас нету, если опять порулить дорвется, никакие
таймеры не спасут! - Visitor(07.06.2020 09:04)
- только то, что ты избавлен от постоянных вычислений. Когда надо
визуально предоставлять наружу время и дату. Вот как у меня в моем
пульте. - Лaгyнoв(07.06.2020 09:00)
- Если работа с часами простая (установил и тикают), то часы с
календарем проще - прочел и вывел. Если работа с часами
предполагает сравнение, восстановление и подстройку времени,
переход зима-лето, использование меток времени в логах/архивах, то
секундный счетчик удобнее - все равно все делаешь сам, и не нужно
постоянно конвертировать. - VLLV(07.06.2020 06:24)
- [Архивы]. Сегодня пролистывал сообщения Дениса Ягова (у него сегодня ДР, но
его последний пост был 10 лет назад), и наткнулся на обсуждение
перспектив USB в STM8. Посмотрел сайт STM - за 10 лет так и не
случилось. - Evgeny_CD(14.07.2020 17:34, MCU, ссылка)
- LTC3350 - поможете понять как на выходе будет5В при входном 20В? - POV_(13.07.2020 15:13, , MCU, полностью)
- Подумалось. А в FRAM-памяти ведь тоже разрушающее чтение? Или нет?
А если да, то она же регенерируется значит? А если питание отключат
в момент чтения? - fk0(10.07.2020 12:37, MCU, полностью)
- ща лень искать, но уже обсуждение было - давал инфу. в общем бывает
как минимум два типа топологии - с прибитыми рельсами питания и с
переключающимися. во втором случае опасен только износ. текущее
решение у TI заявляет о 150 пс времени регенерации. даже при
топологии первого типа нереально разрядить байпассную емкость за
это время. - Vit(10.07.2020 15:40)
- У TI есть серия MSP430FRx - там описано, что предпринято для
предотвращения подобной ситуации. Сам по памяти уже не опишу. - Dingo(10.07.2020 13:17)
- Ёмкости конденсатора по питанию должно хватить, чтобы записать
обратно, дальнейшие попытки записи/чтения должны прекратиться, так
как сработает супервизор процессора по питанию. У нас по факту с
FRAM были изредка проблемы, что терялась целостность,
восстанавливали данные из других источников, но редко с
микросхемами FRAM была проблема: после сбоя она ломалась, пишешь
одно - обратно читаешь другое. - FRAM(10.07.2020 13:08, )
- Как страшно жить! - Toчкa oпopы(10.07.2020 12:45)
- MSP430. Что такое _ZEBU_ ? VLLV(74 знак., 07.07.2020 22:48, MCU, полностью)
- Погулял по сайту [Zilog] и испытал странные чувства. Evgeny_CD(565 знак., 08.07.2020 02:45, MCU)
- Какие российские микроконтроллеры гражданского применения
изготавливают полностью (кремний и упаковка) в России? Столкнулся с
тем что отечественные мк пекут на тайване, то есть чуть что - они
ничем не лучше импортных. - General(07.07.2020 10:36, MCU, полностью)
- Белорусов считаем за отечественное? Если да, то собственный MCS-51
:)))) у "Интеграла" есть, AVR клонировали-клонировали, а вот
выклонировали ли, надо смотреть. UPD: залез на сайт, гражданский
MCS помер :(, из гражданских остались одни бескорпусные извращения
с драйвером ЖКИ. - Chum_A(07.07.2020 16:42)
- Стоит присмотреться к контрам, имеющим собственное производство
кристаллов. На вскидку, это Ангстрем, Микрон, ЗНТЦ. У Ангстрема
известные мне гражданские МК старье. Микрон точно делает у себя
гражданские МК, но для смарткарт с криптографией. У ЗНТЦ что-то
есть, крайне самобытное, 16-ти битное. AlexG(364 знак., 07.07.2020 15:54)
- А что раздел "Parts" сайта говорит? Или именно полнота цикла
изготовления под вопросом? - Dingo(07.07.2020 12:38)
Александр Суворов, 1730 год
Пиноккио, 1826 год
Чарльз Дарвин, 1859 год
AKM Asahi Kasei Microdevices выпускает новый чип ЦАП AK4498EXVQ для аудио решений премиум-класса. ...
Представлена технология охлаждения чипов светом - секретная и только по предвари...
Глава Samsung собрался очистить компанию от неповоротливого топ-менеджмента в сфере ...
В России ведется разработка нового 32-разрядного RISC-микроконтроллера К1978ВЕ1У. Новы...
Китай сокращает разрыв с Южной Кореей и Тайванем в полупроводниковой сфере https://ove...
В России создают установку для изготовления кремниевых пластин на замену америка...
Русские вендоры бытовой техники под немецкими именами: как вырос их бизнес после ...
Отдел исследований и разработок АО Оптрон-Ставрополь приступает к сборке раз...
AI Alone Isnt Ready for Chip Design
AI Alone Isnt Ready for Chip Design
