Видео

55:58 -- конечно же вообще все что угодно -- никаких требований по таких случаев от стандарта. (ISO/IEC 9899:TC2 Committee Draft - May 6, 2005 WG14/N1124) "3.4.3 undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements. NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). EXAMPLE An example of undefined behavior is the behavior on integer overflow."

54:26 -- мне кажется там указано совершенно иначе -- что в некоторых случаях при использовании POSIX API необходимо вызывать именно posix-функции (макросы) вместо libc -- это не означает несовместимость POSIX и C стандартов.

Просто надо деплоить в opensource. Чего тут непонятного то? Ну ребят. Если что вам чел с модуляцией голоса в первом ряду подскажет.

Что даёт линукс на микроеонтроллере по сравнению с FreeRTOS или scmRTOS ?

Понятно что они очень любят STM32, но непонятно почему полностью игнорируют RP2040, RP2350, ESP32?

Хорошо ,что в Embox есть UART CLI. Молодцы.

Попробуйте портировать embox на микроконтроллер Элиот от Элвиса.

Чем Еmbox Rtos лучше Zephyr Rtos?

Embox интересный проект, слышал про него, но еще не пробовал. Я правильно понимаю, что в Embox приложения интегрируются и статически линкуются на стадии компиляции всего проекта ? Эдакий busybox+ядро слинкованное в один бинарный блоб который кладется во Flash/EEPROM и оттуда исполняется ? Или же всё таки это традиционная ОС с возможность подгружать задачи из произвольных бинарных файлов ? Также интересно мнения Антона на RIOT-OS. Рассматриваю эту ОС как серьезную альтернативу раздутому монстру Zephyr для собственной синтезируемой СнК на базе ядра VexRiscv.

Это же Глебушка!!!🎆🎆🎆 Лет 20 почти пролетело........ Последний раз встречал лет 13-14 назад....

от Make до Mise и обратно)

Прекрасный докладчик не стал(а) упоминать контрапункт (полифонию). Действительно, это было бы перебором для популярной лекции. :) Я с юных лет мучился вопросом, почему какая-то музыка заходит, какая-то нет. Пытался вникнуть в теорию, но убедился, что мои мозги не имеют свойств, необходимых музыканту. На верхнем уровне абстракции вижу дело так: Прослушивание музыки - это игра в угадалку. Слушатель должен уловить закономерность чередования громкости и высоты звуков и спрогнозировать, что должно прозвучать дальше. Хуже, когда уверенность в прогнозе минимальна по причине нечёткости закономерностей или их чрезмерной сложности. Уверенность в прогнозе - это одна характеристика процесса. Другая сторона - это подтверждаемость прогноза. Хуже, если она полная. И третья сторона - это оправданность того, что звучит, то есть, соответствие предложенным ранее закономерностям. Теперь самое главное: когда слушатели, подобные мне, получают главное удовольствие от прослушивания? Это происходит тогда, когда при высокой уверенности в прогнозе он оказывается неверным, но то, что звучит на самом деле, полностью оправданно. Немного хуже, если закономерности чётко ощущаются, прогноз труден из-за сложности предъявляемой задачи, и вдруг звучит то, что сознанием признаётся вполне оправданным. Композитор должен коварно увлечь слушателя в шулерскую игру и привести его к выводу, что композитор - голова, а слушатель - лох. Давайте использовать для описанного принципа аббревиатуру ГЛ (гений-лох). По чисто техническим причинам музыкальное произведение не может быть насыщено моментами торжества принципа ГЛ. Зерно появляется благодаря тому, что есть корни и листья. Естественно, что я описал тот процесс, который лично мне нравится. А вообще-то музыка - это нечто гораздо более широкое, не всегда имеющее явные признаки ГЛ. Итак, люди получают удовольствие от сознания, что их интеллектуально надули? В искусстве - обычное дело. Жанр анекдота полностью построен на этом принципе.

Материал конечно, очень хороший... НО! и их два. Очень похоже на то что вы просто сами создали проблему. А потом героически ее решаете. Когда коту делать нечего... Студентов можно действительно чем то полезным загрузить, тем более на таком СнК. А тут проект чисто ради проекта, трата времени и сил. НО! N1. Это ж Zynq Ultrascale. Там и так есть 6 ядер. Для каких целей туда еще калечный Microblaze пихать? Сила этой системы как раз в том что бы на ядрах крутиться обычный софт. А всякую вычислительную специфику, и всякие хитрые штуки, которые зачастую невозможно сделать на процах - пишешь ручками на ПЛИС. Постучаться в свой ПЛИС-овый код через AXI очень просто(и намного быстрее чем через DDR гонять) хоть из Linux на ядрах, хоть из bare-metal. Что бы прям по IT-шному было - драйвер свой напиши и API к нему, которое в ПЛИСовый модуль обращается....Весить это будет копейки, а скорость работы будет огромная.... Если у тебя большие потоки данных из/в ПЛИС (гигабайты/с), ну тогда напрямую в DDR стучись и всё. По времени распредели работу DDR что б всем хватило. А Microblaze просто так отжирает драгоценные луты… И по сути просто повторяет то что уже есть, но не эффективно. Если бы вы например хотя бы свою DDR для него поставили, ну тогда может быть иногда в узких извращениях для этого есть смысл... НО! N2. UART?...не вы серьезно UART? У вас есть AXI которая напрямую в Microblaze заводится, у вас есть общая DDR, где можно расшарить(даже тут готовых программных решений полно) часть памяти для доступа и обмена обоих процессоров. А вы AXI переводите в UART и потом обратно в AXI? Просто так тратите луты и теряете в скорости... Такое можно делать во время отладки/разработки проекта что б какую то небольшую фичу проверить, ну чисто что б просто время сэкономить. Я б про такое в рекламной презентации точно бы не говорил. Драйвер такого уровня, что б такой костыль не показывать и студент сможет написать. Ребят, сори не удержался. Про Linux вы хорошо понимаете, по СнК(ПЛИСу), что то как то не очень...

Хитро (про эмуляторы) 👍

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

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

Спасибо!

Да, помнится, около 2000 года писал БПФ и при разных реализациях при простом переупорядочивании вычислений скорость отличалась в разы из-за попадания и не попадания в кэш.

Так вот кто пилит Huawei-евский ArkTS с компилятором.

50:53 Байка конечно интересная, но Алькатрас был закрыт в 1963 году. Скорее всего там не Алькатрас был, а какая-то другая тюрьма. Но конечно для красивого рассказа Алькатрас больше подходит. :))

О, Юрий Панчул. Очень хороший человек и отличный инженер.

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

Кто там дергает микрофон все дидео, постоянный бубнеж в колонках?

Лайк за zx-spectrum :)

Спасибо огромное, что спрашивайте тех кто ещё жив.

Спасибо

Тяжело слушать непосвящённому.

Спасибо

1:35:22 неужели в настоящее время есть еще необходимость в переводе такого рода литературу с английского? Ведь человек, готовящийся проектировать чипы, все равно будет на 95% окружен англоязычной литературой и должен и обязан читать по-английски.

о5 люди с других языков тащат что не нужно в гошку...

эйч-ди-эм-ай - не должно быть сложно правильно произносить

ОГОНЬ

канал просто топ. Почему я не смотрел его раньше... Эй там, наверху! Пора разлочить ютуб обратно...

обречено

А в РФ сейчас кто-нибудь вообще начинает дизайнить PIC/QPIC ( photonic, quantum photonic IC) ?

Отличное интервью. Особенно для тeх кто в России. Первый раз слышу на RUclips русскоговорящего Principal ASIC Architect /Engineer говорящиго языком уровня Silicon Valley. Позовите в следующий раз Principal RFIC Engineer если, конечно, найдете - в РФ таких специлистов уровня Silicon Valley вообще, наверное, нет

19:05 "Можно сделать вопрос на собеседовании: "когда override final имеют смысл вместе?"" Да никогда они не имеют смысла вместе, достаточно final написать. Гуру облажался.

Отличный подарок под новый год ))) Чувствуется огромная работа по подготовке этого выпуска (подбор тем, запись, редактура, монтаж), вы все молодцы, спасибо вам и с наступающим!

Ю. Панчул также дизайнил графические чипы для Айфонов в Imagination Production (пионером в области мобильной графики). В ретроспективе типичный советский инженер, попавший в США на волне развала в 90-ых. Уезжал он в команде Cognitive, которая перепродавала советские наработки по OCR.

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

Неинтересно. Никакой конкретики

Спасибо.

что-то со звуком, некоторый рассинхрон.

я текучий инженер

киборг! машина!

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