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

Процессоры, используемые в наших продуктах — это, в основном, 16- и 32-битные микроконтроллеры Microchip, имеющие RAM от 8 до 32 кБ, и ROM от 128 до 512 кБ, без MMU. Иногда, для самых простых устройств, используются еще более скромные 8-битные чипы.

Очевидно, что у нас нет (разумных) шансов использовать ядро Linux. Так что нам нужна какая-нибудь RTOS (Real-Time Operating System). Находятся даже люди, которые не используют никаких ОС в микроконтроллерах, но я не считаю это хорошей практикой: если железо позволяет мне использовать ОС, я ее использую.

Несколько лет назад, когда мы переходили с 8-битников на более мощные 16-битные микроконтроллеры, мои коллеги, которые были гораздо более опытными, чем я, рекомендовали вытесняющюю RTOS TNKernel. Так что это — та ОС, которую я использовал в разных проектах в течение пары лет.

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

Раскрытие уязвимостей Meltdown и Spectre снова привлекло внимание к багам на аппаратном уровне. Многое сделано для улучшения (всё ещё слабой) безопасности нашего программного обеспечения, но всё напрасно, если оборудование даёт сбой. Процессоры в наших системах по-прежнему, в основном, проприетарные и уже преподнесли ряд неприятных сюрпризов (например, в движке Intel Management Engine). Поэтому встаёт естественный вопрос о переходе на железо open-source, как мы сделали с нашим программным обеспечением. Такой переход вполне возможен и даёт ряд преимуществ, хотя и не является панацеей.

Учитывая сложность современных процессоров и свирепый рынок, где они продаются, их разработка по принципам open-source может показаться необычной идеей. Но в этой области уже есть серьёзные инициативы; так что идея свободного дизайна CPU — не просто фантазия. Небольшое исследование темы выявляет несколько проектов; хотя дальнейший список явно не полон.

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

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

Docker, первый выпуск которого был еще в 2013 году, — весьма удобный инструмент для сборки пакетов, поставки и запуска приложений в «контейнерах». Большинство крупных компаний, например, Google, Amazon и VMware рассматривают Docker как зрелую технологию для контейнеров, поэтому сейчас самое время изучить этот инструмент и в результате продвинуться по карьерной лестнице. Хотите? В статье будут приведены вопросы по Docker, ответы на которые нужно знать, если вы идете на собеседование.

Небольшая история от том как я стал разработчиком игр. Постараюсь осветить проблемы, с которыми я столкнулся на своем пути, и поделиться некоторыми цифрами. Программистом работаю давно, с 2001 года, компьютерами занимаюсь с детства, но играми начал заниматься лишь в начале 2014 года. И катализатором этого стала статья на Хабре. Где-то в начале 2014го, читая статейки на Хабре, я нашел статью про то, как один молодой человек сделал простенькую игру для ВК. Простая игра про сражение на самолетиках в 2D. Про саму игру в статье было мало, но меня заинтересовало то, что ему предложили продать игру за 700 баксов. Он отказался и потом пожалел, так как игра принесла ему только убытки. И эта «история успеха» как-то меня вдохновила.

Сегодня речь пойдет о модном — о RISС-V микроконтроллере. Я давно хотел познакомиться с этим ядром и ждал когда появится что-то похожее на STM32 и вот дождался, встречайте — китайский GigaDevice — GD32V.

Инфраструктура для этого микроконтроллера не такая обширная как для STM32, но есть все необходимое для того, чтобы начать с ним работать. Благо отладочные платы можно заказать на аликекспресс, например, вот тут: Longan Nano GD32VF103CBT6 RISC-V MCU

Китайцы продвигают для этого микроконтроллера среду разработку Platform IO, которую можно поставить как расширение под Visual Studio Code. Но мы не будем её использовать, это ведь не по инженерным понятиям, мы же инженеры и хотим разобраться во всем сами. Поэтому давайте попробуем запустить плату на IAR, написав все с нуля.

Кстати, IAR раздает отладочный комплект (отладочная плата + отладчик I-Jet + 30 Дней полная лицензия) IAR RISC-V GD32V Evaluation kit. Вот тут можно оставить заявку Request for Development Tools. Не уверен, что они посылают комплект всем желающим, но мы получили в течение 5 дней. Спасибо им за это!

Ну что же, кто заинтересовался, добро пожаловать под кат

Здравствуйте. В данной статье я хочу по возможности максимально просто и понятно рассказать о том, как рассчитываются временные ограничения (timing constraints) на синхронные интерфейсы ПЛИС. Просто — не значит коротко, но зато простыми словами, которые вы сможете легко понять. Если вы новичок и перед вами стоит задача описать свой первый SPI, то данная статья должна вам помочь понять для чего нужны ограничения и как их рассчитать.

Если вы знакомы с объектно-ориентированным программированием, то наверняка слышали и о принципах SOLID. Эти пять правил разработки ПО задают траекторию, по которой нужно следовать, когда пишешь программы, чтобы их проще было масштабировать и поддерживать. Они получили известность благодаря программисту Роберту Мартину.

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

Основная цель этой статьи – лучше усвоить принципы SOLID через отрисовку иллюстраций, а также определить назначение каждого принципа. Дело в том, что некоторые из принципов кажутся похожими, но функции выполняют разные. Может получиться так, что одному принципу следуешь, а другой при этом нарушаешь, хотя с виду особой разницы между ними нет.

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

Ну, приступим.

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

Мы писали о фронтендерах и бэкендерах, о мобильной разработке и о тестировании, но это были частные случаи. Когда человек подходит к первой или очередной профессии, он редко говорит, что станет разработчиком под iOS или проктологом, как правило это звучит «программистом» и «врачом». Специализация приходит позже, с опытом. Но чтобы твёрдо заявить, что ты хочешь стать программистом, врачом, архитектором, геологом и т.д., нужно избавиться от романтизации профессии и подойти к ней здраво и осмысленно. Даже если вы вдруг решили стать программистом, чтобы «войти в айти после 35-ти». Если говорить о программистах с позиций романтики, то это люди, которые превращают наши замыслы в код и делают жизнь лучше, проще, удобнее. Если говорить прямо, то работа программиста — напряжённый, зачастую рутинный труд с множеством плюсов и минусов. Об этом и поговорим.

Процесс создания in-game модели персонажа от эскиза до релиза.



Доброго времени суток. Меня зовут Ivan. Сегодня я поделюсь с вами деталями разработки игр, а именно расскажу о полном цикле создания персонажа. Итак, поехали!

Unreal Engine 4 — это набор инструментов для разработки игр, имеющий широкие возможности: от создания двухмерных игр на мобильные до AAA-проектов для консолей. Этот движок использовался при разработке таких игр, как ARK: Survival Evolved, Tekken 7 и Kingdom Hearts III.

Разработка в Unreal Engine 4 очень проста для начинающих. С помощью системы визуального создания скриптов Blueprints Visual Scripting можно создавать готовые игры, не написав ни строчки кода! В сочетании с удобным интерфейсом это позволяет быстро изготавливать рабочие прототипы.

В этой части туториала по Unreal Engine 4 мы ознакомимся с основными возможностями программы. Вот основные темы, которые будут в нём рассмотрены:

• Установка движка
• Импорт ассетов
• Создание материалов
• Использование Blueprints для создания объектов с простейшими функциями

Привет всем!

Решил написать очередную статью, которая была бы полезна начинающим разработчикам в области ПЛИСоводства. Очень долго откладывал момент публикации, сам материал подготовил еще несколько месяцев назад, а вот сесть и написать всё это в целую статью как-то не доходили руки. Но вот наконец-то появилось свободное время, поэтому всех заинтересовавшихся приглашаю к прочтению.


Проект называется «глупые часы», поскольку он ничего не умеет, кроме как считать время и дату и выводить их на дисплей. В первую очередь проект рассчитан на студентов старших курсов и новичков. В нём нет никаких необычных блоков, не используются вендорные IP-ядра, и уж тем более нет сложных интерфейсов обмена (типа PCIe, Ethernet, USB и т.д.).
В этот раз проект на программируемых логических интегральных схемах (ПЛИС) будет примитивен и предельно прост, а я постараюсь рассказать обо всех трудностях, с которыми пришлось столкнуться при выполнении поставленной задачи.

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

Следующий большой шаг в обеспечении радиационной стойкости наступил с переходом на суб-100 нм, где практически каждое следующее поколение технологии приносит новые вопросы: меняются материалы, меняются требования к топологии, растет статическая мощность (утечки безо всякой радиации, которые под дозой становятся еще хуже), продолжает расти значимость одиночных эффектов, которые превращаются во множественные. Эти задачи потребовали разработки новых подходов и, что удивительно, частичного возврата к старым, потому что часть вещей, отлично себя зарекомендовавших на нормах 1-0.18 мкм, на более тонких нормах не работает. Например, в таких технологиях для повышения выхода годных запрещено делать любимые дизайнерами радстойких чипов кольцевые транзисторы. О том, как дизайнеры справляются с новыми вызовами, я расскажу на примере России – и заодно сравню достижения наших соотечественников с успехами иностранных коллег и покажу, чего стоит ожидать в обозримом будущем.

Десятого июля 1962 года с космодрома на мысе Канаверал стартовала ракета “Тор” с первым коммерческим телекоммуникационным спутником на борту. Telstar-1 стал зарей новой эры космонавтики, показавшей, что космос может приносить людям реальную пользу. Этот аппарат ждало большое будущее, но днем раньше в небе над атоллом Джонсон, расположенном в пустынной части Тихого океана, взорвалась атомная бомба Starfish Prime. Взрыв уничтожил три сотни уличных фонарей на расположенных в полутора тысячах километров Гавайях, а также создал огромное количество свободных электронов, подхваченных магнитным полем Земли в рукотворный радиационный пояс. Каждый раз, когда Telsat-1 проходил через этот пояс, продвинутая транзисторная начинка набирала дозу радиации, и уже к ноябрю 1962 года он перестал работать. С изучения последствий этого инцидента началась история защиты космической электроники от радиации.

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

Говорят, что если человек приобрел телескоп и использует его для наблюдений, то через некоторое время он обязательно захочет другой, получше. Так случилось и со мной. У меня есть телескоп PowerSeeker 127мм, но захотелось лучшего. По этой причине я даже было дело собрался точить свое зеркало, но позже обнаружил, что на AliExpress можно за недорого приобрести 200мм зеркало. Главное зеркало вместе с диагональным выходили где-то 6000 рублей с доставкой. Это очень дешево. На снимке выше, как раз такое зеркало, только что прибывшее по почте из Китая.

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

Если поискать в интернете, то, конечно, «телескопы уже печатали». Вот примеры проектов:

1. Gaze Across the Solar System with a 3D-Printed, Raspberry Pi Telescope
2. Open Source DIY Telescope Prime Features Raspberry Pi and 3D Printed Parts

По разным причинам мне эти проекты не очень понравились. Я решил, что буду проектировать части телескопа сам. Чтобы жизнь медом не казалась я отчего-то решил, что буду делать проект во FreeCAD. До этого момента я уже делал кое-что в Компас 3D (я делал Marble-Machine). И теперь я подумал, что FreeCAD должен быть не сложнее…

Привет, Хабр! Представляю вашему вниманию перевод статьи «10 Signs You Will Suck at Programming» автора Jonathan Bluks.



Очень часто на Reddit или Quora я вижу вопросы вида «Как понять, смогу ли я стать успешным программистом?» (На самом деле, эта статья является расширенным продолжением моего недавнего ответа на Quora.) Когда кто-то задумывается о смене карьеры или интересуется разработкой и хочет знать, что для этого требуется, неизбежно возникает этот самый вопрос.

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

Будучи преподавателем на курсе «Full-stack Web-development», я работал со многими программистами-новичками. Хорошая новость в том, что мне редко встречались студенты, которые вообще не могли научиться программировать. Я считаю, что умение программировать — такой же базовый навык, как умение читать, писать и считать. Это под силу любому, так как это одна из способностей человека, но этому действительно надо учиться.

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

Этот список поможет вам понять, сможете ли вы стать хорошим программистом, а также что делать, если вы решите это изменить.

Я постараюсь в общем рассказать о верификации цифровых схем.

Верификация в данной области — это важный процесс, требующий привлечения опытных инженеров. Например, специалист по верификации, работающий над системами с ЦПУ, как правило должен владеть скриптовыми языками и языками командных оболочек (Tcl, bash, Makefile и т.п.), языками программирования (С, С++, ассемблер), HDL/HDVL (SystemVerilog [10, Appendix C — история языка][11], Verilog, VHDL), современными методологиями и framework’ами (UVM).

Доля времени, затраченного на верификацию, доходит до 70-80% от всего времени проекта. Одна из основных причин такого внимания в том, что к микросхеме нельзя выпустить “патч” после того, как ее отдали в производство, можно только выпустить “silicon errata” (это не касается проектов ПЛИС/FPGA).

Под цифровыми схемами я подразумеваю:

• сложно-функциональные блоки/intellectual properties (СФБ/IP);
• специализированные заказные микросхемы/application-specific integrated circuit (ASIC);
• проекты программируемых логических интегральных схем/field-programmable gate array (ПЛИС/FPGA);
• системы на кристалле/system-on-crystal (СнК/SoC);
• и т.п.

На данный момент LLVM стала уже очень популярной системой, которую многие активно используют для создания различных компиляторов, анализаторов и т.п. Уже написано большое количество полезных материалов по данной тематике, в том числе и на русском языке, что не может не радовать. Однако в большинстве случаев основной уклон в статьях сделан на frontend и middleend LLVM. Конечно, при описании полной схемы работы LLVM генерация машинного кода не обходится стороной, но в основном данной темы касаются вскользь, особенно в публикациях на русском языке. А при этом у LLVM достаточно гибкий и интересный механизм описания архитектур процессоров. Поэтому данный материал будет посвящен несколько обделенной вниманием утилите TableGen, входящей в состав LLVM.

Причина, по которой компилятору необходимо иметь информацию об архитектуре каждой из целевых платформ вполне очевидна. Естественно, у каждой модели процессора свой набор регистров, свои машинные инструкции и т.д. И компилятору нужно иметь всю необходимую информацию о них, чтобы быть в состоянии генерировать валидный и эффективный машинный код. Компилятор решает различные платформенно-зависимые задачи: производит распределение регистров и т.д. К тому же в бэкендах LLVM также проводятся оптимизации уже на машинном IR, который больше приближен к реальным инструкциям, или же на самих ассемблерных командах. В подобных оптимизациях нужно заменять и преобразовывать инструкции, соответственно вся информация о них должна быть доступна.

Аннотация

В статье рассмотрен режим работы Vivado, позволяющий вносить изменения в проект на уровне редактирования списка соединений (в дальнейшем – нетлиста). Описаны как сам режим ECO, так и некоторые нюансы, которые появляются во время работы в нём. Приведён демонстрационный пример и описана полная последовательность действий для получения результата, в работоспособности которой может убедиться каждый желающий. Статья будет полезна для «общего развития» FPGA-разработчикам, а особенно — тем, кто часто отлаживает проекты в Logic Analyzer. Надеюсь, работа в этом режиме вызовет интерес у разработчиков, работающих с большими кристаллами, время компиляции в которых может достигать часов (а то и десятков часов), поскольку в этом режиме время, затрачиваемое на имплементацию, при внесении изменений в нетлист может сократиться до буквально пары минут.

Оглавление

В статье очень много картинок не в спойлерах (140 штук). Пожалуйста, будьте внимательны, если заходите с телефона