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

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

Суть сводится к тому, что эту команду в виде «make install» или «sudo make install» использовать в современных дистрибутивах нельзя.

Но ведь авторы программ в руководствах по установке пишут, что нужно использовать эту команду, возможно, скажете вы. Да, пишут. Но это лишь означает, что они не знают, какой у вас дистрибутив, и дистрибутив ли это вообще, может, вы вступили в секту и обкурилисьчитались LFS и теперь решили под свою хтоническую систему скомпилять их творение. А make install является универсальным, хоть и зачастую неправильным способом это сделать.

Недавно возникла данная задача — эмуляция носителя FAT32 на stm32f4.

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

В моём случае накопитель был, но правила работы с ним не позволяли разместить файловую систему. В ТЗ, тем не менее, присутствовало требование организовать Mass Storage интерфейс для доступа к данным.

Результатом работы явился модуль, который я озаглавил «emfat», состоящий из одноимённого .h и .c файла.

Модуль независим от платформы. В прилагаемом примере он работает на плате stm32f4discovery.

Функция модуля — отдавать куски файловой системы, которые запросит usb-host, подставляя пользовательские данные, если тот пытается считать некоторый файл.

В этой статье я расскажу о том, как можно захватывать аналоговый черно-белый видеосигнал с помощью платы STM32F4-DISCOVERY, и об особенностях передачи его на компьютер при помощи USB.

Введение

Данную статью я решил написать после прочтения статьи «Массивно-параллельная стабилизация изображения», в которой описывается алгоритм для стабилизации изображения с поворотных камер. Дело в том, что в свое время мной был реализован алгоритм для стабилизации изображения со стационарных камер, который используется в IP-видеосервере MagicBox и некоторых других продуктах компании Синезис, в которой я работаю по настоящее время. Алгоритм получился достаточно удачным по своим скоростным характеристикам. В частности, в нем очень эффективно реализован алгоритм поиска смещения текущего изображения относительно фона. Эта эффективность позволила задействовать основные его элементы (конечно с некоторыми модификациями) для сопровождения объектов, а также для проверки их на неподвижность.

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

Рис. 1 Стабилизация изображения иногда очень полезна.

Сегодня мы рассмотрим алгоритм TILT (Transform Invariant Low-rank Texture) и множество его методов применения в области Computer Vision. Статья будет нести несколько обзорный характер, без плотного углубления в математические дебри.

Всем привет!

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

Итак, конструкция разработана, собрана на макетной плате, проверена в действии. Дальше — печатная плата. Если верить форумам, то многие (в том числе и мои знакомые) используют Sprint-Layout. Но ведь это ручная работа, тот же карандаш и бумажка, только в электронном виде. Зачем все эти ядра процессора и гигабайты памяти, если приходится всё равно работать ручками? Признаюсь, меня это всегда коробило.

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


Красивая картинка для привлечения внимания

Вы правильно поняли из названия, что это не совсем обычное описание алгоритма JPEG (формат файла я подробно описывал в статье «Декодирование JPEG для чайников»). В первую очередь, выбранный способ подачи материала предполагает, что мы ничего не знаем не только о JPEG, но и о преобразовании Фурье, и кодировании Хаффмана. И вообще, мало что помним из лекций. Просто взяли картинку и стали думать как же ее можно сжать. Поэтому я попытался доступно выразить только суть, но при которой у читателя будет выработано достаточно глубокое и, главное, интуитивное понимание алгоритма. Формулы и математические выкладки — по самому минимуму, только те, которые важны для понимания происходящего.

Знание алгоритма JPEG очень полезно не только для сжатия изображений. В нем используется теория из цифровой обработки сигналов, математического анализа, линейной алгебры, теории информации, в частности, преобразование Фурье, кодирование без потерь и др. Поэтому полученные знания могут пригодиться где угодно.

Если есть желание, то предлагаю пройти те же этапы самостоятельно параллельно со статьей. Проверить, насколько приведенные рассуждения подходят для разных изображений, попытаться внести свои модификации в алгоритм. Это очень интересно. В качестве инструмента могу порекомендовать замечательную связку Python + NumPy + Matplotlib + PIL(Pillow). Почти вся моя работа (в т. ч. графики и анимация), была произведена с помощью них.

Внимание, трафик! Много иллюстраций, графиков и анимаций (~ 10Мб). По иронии судьбы, в статье про JPEG всего 2 изображения с этим форматом из полусотни.

[FF D8]

Вам когда-нибудь хотелось узнать как устроен jpg-файл? Сейчас разберемся! Прогревайте ваш любимый компилятор и hex-редактор, будем декодировать это:

Специально взял рисунок поменьше. Это знакомый, но сильно пережатый favicon Гугла:

Последующее описание упрощено, и приведенная информация не полная, но зато потом будет легко понять спецификацию.

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

[FF D8] — маркер начала. Он всегда находится в начале всех jpg-файлов.

Следом идут байты [FF FE]. Это маркер, означающий начало секции с комментарием. Следующие 2 байта [00 04] — длина секции (включая эти 2 байта). Значит в следующих двух [3A 29] — сам комментарий. Это коды символов ":" и ")", т.е. обычного смайлика. Вы можете увидеть его в первой строке правой части hex-редактора.

Недавно я разработал одно простое устройство. Пришлось решать вопрос, как изготовить пробную партию в 50 плат. Думаю, этот опыт будет полезен всем DIY энтузиастам, кто уже думает о том, что делать дальше после того, как девайс готов.

Замечу, что настоящая заметка — это не маркетинговое исследование или что-то подобное, претендующее на объективное освещение вопроса. Это исключительно один частный личный опыт.

Привет, Хабр! Так получилось, что одним из моих увлечений являются интеллектуальные игры. Это «Что? Где? Когда?», «Своя игра», «Эрудит-квартет», «Брейн-ринг» и прочие. И вот, однажды мне захотелось сделать своими руками систему для этой игры. Если вам интересен процесс создания с нуля такого устройства — приглашаю под кат.

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

Хотя на самом-то деле, если вспомнить историю Си, всё достаточно очевидно и, главное, логично. А все жалобы людей, «обжёгшихся» на неопределённом поведении для людей не забывших что такое Си и зачем он вообще существует звучат примерно как: «я тут гвозди бензопилой забивал… забивал и забивал, всё было хорошо, а потом я дёрнул за ручку и у неё коготки как забегают, задёргаются, мне руку оттяпало и полноги… ну кто так строит?».

Люди, которые знают что такое бензопила пытаются, конечно, объяснить, что за если за эту рукоятку дёрнуть, то так, в общем-то, и должно быть, но люди, считающие, что у них у руках такой себе молоток говорят «мимо» них, и, в результате, все остаются при своих.

Введение

Из всех наслаждений, отпущенных человеку в жизни,
самое изысканное — шевелить мозгами.
(Борис Акунин)

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

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

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

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

И если с Nvidia Physix (привет Unity3D) ничего не поделаешь кроме пары параметров, то Bullet Physics и Box2D доступны в исходных кодах, и от безысходности начинаешь разбираться с тем как что устроено и работает.

Разобраться с тем, как все работает очень полезно. Все игровые физические движки очень похожи. Они все impulse base, что означает то, что в каждый фрейм симуляции все (силы) переводяться в импульсы, импульсы складываются, делятся на массу и прибавляются к скоростям (линейной и вращaтельной) объекта, скорость же определяет насколько объект сдвинется в текущем фрейме симуляции.

И тут встает вопрос, если все так просто, как получается, что можно выложить в столбик кубики и они себе спокойно стоят и не разлетаются?

Я покажу, что за всю эту магию отвечает маленький кусочек кода!

Всем привет!

Многим известно, что во всех современных процессорах есть вычислительный конвейер. Бытует заблуждение, что конвейер — это какая-то фишка процессоров, а в чипах для других приложений (к примеру, сетевых) этого нет. На самом деле конвейеризация (или pipelining) — это ключ к созданию высокопроизводительных приложений на базе ASIC/FPGA.

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

Ты ждал знак? Вот он!

Много лет я не решался начать программировать ПЛИС, потому что это сложно, дорого и больно (как мне казалось). Но хорошо, когда есть друзья, которые помогают сделать первый шаг. И теперь я не понимаю одного — ПОЧЕМУ Я ЖДАЛ ТАК ДОЛГО?

Сейчас я помогу сделать первый шаг и тебе!

Всем привет! Мы — небольшая команда разработчиков сервисного робота Tod Bot. В своей практике мы широко используем фреймворк ROS, постоянно решая с его помощью насущные для нашего робота задачи: от управления передвижением и обработки данных с сенсоров до автономной навигации в помещении, распознавания речи и образов, высокоуровневого поведения робота.
Сегодня в рамках конкурса на образовательной платформе Stepic мы анонсируем онлайн-курс «Программирование робота вместе с ROS». Наш курс будет интересен людям, неравнодушным к программированию и робототехнике, и готовым приобрести новые знания и навыки по разработке ПО для роботов, конечно же, приложив при этом необходимые усилия. Получить представление о содержимом курса вы можете из небольшого интро-видео.

Многие мои друзья и знакомые крутят пальцем у виска или задаются вопросом: не жмёт ли мне череп, когда узнают, что я пишу драйвера под Linux. Слово “драйвер” окутано каким-то почти мистическим смыслом, и постичь Дао его написания способны лишь избранные гуру.
К счастью это не так. Не знаю, как обстоят дела с написанием драйверов под другие операционные системы, в т.ч. и наиболее популярные, но под linux, вне зависимости от аппаратной архитектуры драйвера пишутся очень просто. Для написания драйвера необходимы базовые знания языка си, представление о работе ОС линукс (базовые), понимание того, что мы хотим получить, желание чтения документации и исходных кодов, ну и усидчивость. Всё.
Вы хотите посмотреть как написать драйвер для своего устройства? Тогда ныряйте под кат!

Иллюстрированная проекция модели сетевого взаимодействия OSI на универсальную последовательную шину.

Три «замечательных» уровня стека USB

Меня не устроил вид стека USB, который можно встретить чаще всего на просторах сети:


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

Если у читателя бывали сходные ощущения, предлагаю альтернативное, явившееся мне неожиданно ясно в перегретом мозгу видение стека USB, по мотивам любимой 7-уровневой модели OSI. Я ограничился пятью уровнями:



Я не хочу сказать, что весь софт и библиотеки уже сделаны или должны проектироваться, исходя из этой модели. Из инженерных соображений код c уровнями будет сильно перемешан. Но я хочу помочь тем, кто начинает своё знакомство с шиной USB, кто хочет понять протоколы обмена устройств и терминологию предметной области, подобраться поближе к готовым примерам, библиотекам и лучше ориентироваться в них. Эта модель не для загрузки в МК, но в ваши блестящие умы, дорогие друзья. А ваши золотые руки потом всё сами сделают, я не сомневаюсь:)

Прочитав статью «Переезд электронщика в Шэньчжэнь», в которой автор в красках рассказал о преимуществах дизайна электронных устройств в Китае, решил тоже расчехлить клавиатуру. Хочу рассказать об уникальном для России месте, где я вот уже более пяти лет занимаюсь фрилансом в этой же области, которое в отдельных случаях может составить серьёзную конкуренцию Поднебесной.

Это город Зеленоград