Поднимите голову и посмотрите на что-нибудь равномерно окрашенное, на какой-то светлый фон (на снег, на небо без солнца). Если перед глазами вдруг начали медленно проплывать вот такие примерно штуки:



… То знакомьтесь, это «битые пиксели» у вас в глазу, образованные стекловидным телом (на рисунке ниже оно во всей красе). Такие «глюки» у многих появляются ещё в детском возрасте и с годами множатся или постепенно видоизменяются. Для большинства людей их наличие — не повод для беспокойства, но внезапное их появление или резкое увеличение — повод для срочного визита к офтальмологу. Особенно если к этому прибавляются молнии перед глазами, тёмная пелена или мелкая «табачная пыль».

Но давайте для понимания полной ситуации поговорим о том, что это за явление вообще и откуда оно берётся.

Что, опять? Сколько ж можно?

Да, сегодня мы снова поговорим о всеми нами любимом датчике углекислого газа Winsen MH-Z19. Нет, повторов не будет*.



* почти

Как вы могли заметить, на страницах настоящего ресурса регулярно появляются страшилки статьи об опасностях высокой концентрации СО2 в помещении. И хотя утверждения, что концентрации выше 1000 ppm несут ад и погибель, слегка преувеличены (википедия говорит, что хоть какие-то эффекты начинаются с 1%, то бишь 10 000 ppm, тогда как у датчика весь диапазон — 5000 ppm) — СО2 может служить индикатором присутствия других нехороших вещей в силу недостаточности вентиляции. Потому я тоже решил приобщиться к увлекательному миру СО2-метрии и разжился упомянутым датчиком.

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

Но пока я копипастил, в душу закрался червь сомнения — а отчего это датчик выдаёт девять байт, а на СО2 из них приходится всего два байта? Может быть, он хочет сказать мне что-то ещё?

(оригинал — Jasper St. Pierre, разработчик GNOME Shell, взято отсюда)

Это обзорная статья о составных частях графического стека Linux и том, как они уживаются вместе. Изначально я написал её для себя после разговоров об этом стеке с Оуэном Тейлором, Рэем Строудом и Эдэмом Джексоном (Owen Taylor — мэйнтейнер Gnome Shell; Ray Strode — мэйнтейнер большого количества десктопных пакетов сообщества RedHat; Adam Jackson — разработчик графического стека Gnome Shell и интеграции с XOrg; прим. переводчика). 

Я постоянно дёргал их, снова и снова расспрашивал о всяких мелочах, а потом эти мелочи благополучно забывал. В конце концов, я задал им вопрос — а нет ли какого-нибудь обзорного документа, уткнувшись в который я бы избавил ребят от своего назойливого внимания? Не получив утвердительного ответа я решил написать эту статью, которая по завершению была вычитана Эдэмом Джексоном и Дэвидом Эйрли. Они оба работают над этим стеком.

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

В этой статье я расскажу о том, как на базе отладочной платы DE0-nano сделать достаточно простой КВ SDR приёмник.
Пример принимаемых сигналов:

Определившись со своим решением покинуть Nintendo, Square быстро приступила к реализации Final Fantasy 7 на PlayStation. Компания наняла большой коллектив специалистов по 3D и художников, приобрела сотни рабочих станций Silicon Graphics. По мнению многих сотрудников, такая финансовая поддержка позволила обогнать конкурентов, разрабатывавших первые 3D-игры.

Тем временем Square вложила большинство своих ресурсов в создание художественного оформления, музыки и сюжета игры. Она экспериментировала со способами изложения истории через полигональных персонажей и CG-ролики. Кроме того, компания потратилась на открытие западного офиса по продажам и маркетингу в США, чтобы повысить популярность игры в тех странах, где эта серия пока «не взлетела».

Тема элементов защиты банкнот меня заинтересовала после прочтения рекламной статьи на geektimes, в которой описывался карманный приборчик распознающий спец элемент «И» (anti-stokes luminescence).

Мир методов защит документов и банкнот от подделки оказался очень интересным и увлекательным. В чем то, даже теперь понимаю Виктора Ивановича Баранова.

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

Условно, для себя, я разделил методы проверки на две группы:

1. Элементы защиты доступные для проверки без специальных средств (максимум лупа).
2. Исследование с использованием «инструментальных» средств (UV, IR источники и т.п.)

Тема по п1. просто огромна и интересна, но она относительно широко освещена в открытых материалах и в этой статье я ее не затрагиваю.

Вводная

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

Кое-кто из вас может помнить серию примечательных игр для Game Boy Advance, вышедших в течение 2004 года. Светло-серые картриджи с простыми этикетками сильно отличались от обычных, тёмно-серых, с разноцветными этикетками. На них продавались игры, портированные с оригинальной Nintendo Entertainment System. Эти игры, известные в США как Classic NES Series, интересны по нескольким причинам.

Особенно интересны они с точки зрения эмуляции GBA. Обычно игры для Game Boy Advance невероятно проблемны, а сама платформа содержит множество средств для защиты от сбоев. Поэтому для запуска игр эмуляторы должны быть совместимы с ошибками оригинального оборудования. Однако в серии Classic NES Series разработчики пошли дальше и попытались защитить игру от запуска в эмуляторах.

Пару лет назад ко мне в СПб приехал @C0NTEMPLATOR, он был в восторге от стоявшей у меня тогда полумостовой DRSSTC и выразил желание заиметь подобное чудо себе на дачу для развлечения гостей. В общем-то эта просьба успела постепенно забыться, но одним погожим сентябрьским днем мне нечего было делать и хотелось чего-то эпичного.

Прошел год и многие вечера коротались написанием очередного, куда более крупного и на этот раз полезного проекта. В прошлый раз везде приходилось ужиматься, как только возможно. Ресурсов того многострадального камня мне стало не хватать и в какой-то момент пришло интересное решение. Отдать часть задач другому контроллеру. (Как и в прошлый раз, под катом много воды и изображений.)

Привет! Это стало уже традицией и в этому году мы не только снова на FOSDEM, но ещё и на самом «проходном» месте рядом с информационной стойкой.


О наших прошлогодних приключениях на этом мероприятии можно почитать в предыдущих постах нашего блога.

Мы всё-таки смогли дойти до третьей части и добрались до самого интересного — организации асинхронных вычислений.

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

Теперь посмотрим, как можно управлять потоком исполнения (control flow) в случае обработки асинхронных задач.

• Параллелизм (часть 1)
  
  
  • Потоки: scheduling, сон
  • Синхронизация: Spinlock, семафоры, барьеры памяти
  • Атомарность: TAS, CAS
  
  
• Кооперативность (часть 2)
  
  
  • Корутины (coroutines)
  • Акторы
  
  
• Асинхронность (часть 3, текущая)
  
  
  • Event loop
    • select
  • Callbacks
  • Async Monad
  • Промисы (promises, обещания)
  • async/await — промисы + корутины
  
  

В условиях входа космических аппаратов в атмосферу при гиперзвуковых скоростях выделяется огромное количество тепла, которое не только предъявляет высокие требования по тепловым нагрузкам к материалам спускаемого аппарата, но и приводит к образованию плазмы вокруг СКА.

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

Не менее актуальна задача и в военном аспекте: РГСН гиперзвуковых ракет и боевых блоков МБР.На пример для:

3М-22 («Циркон»)/на фото дем.макет BrahMos-II, но вряд ли 3М-22 будет оличаться:



Объект 4202 (Ю-71):



Радиолокация и радиосвязь через «такую» плазму не работают: суммарная мощность потерь электромагнитной энергии и радиошумовое излучение практически полностью определяющие уменьшение энергетического потенциала радиоканала связи в целом, существенно возрастают и предопределяют потерю радиосвязи на траектории спуска.

Феномен обрыва связи при входе в атмосферу был открыт во время проекта «Меркурий», а затем программ «Джемини» и «Аполлон». Он проявляется на высоте снижения около 90 километров и до отметки в 40 километров — в результате быстрого нагрева поверхности падающей в атмосфере капсулы на ее поверхности образуется облако- плёнка плазмы, выступающая своего рода электромагнитным экраном.

Эффект назван (не официально) Radio Silence During Fiery Re-Entry.

с подкидным дураком и пьяными соседками

«Вот пока вы тут сидите, там, на Аляске,
ионы атомов сливаются и образуют плазмоиды!» (С) Неизвестный

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

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

Всем привет! Эта статья будет посвящена верификации дизайна конечного автомата управления торговым устройством vending machine, описанного на языке Verilog (дизайн) и System Verilog (верификация).

Вообще в основе публикации лежит мой курсовой проект, который был оценен моим преподавателем по достоинству с предложением сделать публикацию на Хабре.

Основное на чем я хочу акцентировать внимание — это описания типичных блоков multilayer testbench и применение некоторых базовых конструкции языка SystemVerilog и верификации. В основе подхода, который я использовал лежит так называемая Open Verification Methodology (OVM) с изменениями, которые упрощали разработку проекта и были удобны персонально мне.

Итак, поехали!

Всем привет! Надеюсь, все хорошо провели праздники и готовы с новыми силами покорять высоты FPGA разработки.

Сегодня я хочу написать небольшой гайд по запуску тестбенчей на Verilog/SystemVerilog в ModelSim без использования GUI.

План будет такой:

1. Добавление пути к ModelSim в PATH.
2. Написание скрипта с объяснением команд.
3. Запуск ModelSim с исполнением написанного скрипта.

Поехали!

Добрый день, коллеги. Со времени написания первой статьи прошло достаточно много времени. За это время моя библиотечка для доступа к диску научилась работать со встроенными SMART-тестами и их логами а также механизмами безопасности современных накопителей.

На этот раз я расскажу о создании приложения для тестирования жестких дисков на базе этой библиотеки.

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

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

Поняв, что простого решения не предвидится я решил попробовать написать подобную программу самостоятельно. Понимая, что подобный проект на C я не осилю я начал изучать возможность прямой работы с дисками из python, которым я частенько пользуюсь для решения простых задач и люблю за простоту и понятность. Информации по этому вопросу в сети кот наплакал, но все же я выяснил, что существует модуль fcntl который в том числе позволяет отправлять устройству ioctl запросы. Теперь у меня появилась возможность отправлять команды диску. Но в линуксе все диски считаются scsi дисками, а для тестирования нужно передавать диску непосредственно ata команды. Оказалось существует механизм ATA Command Pass-Through, позволяющий обернуть ata команду в scsi запрос. Основную информацию о том, как это использовать удалось почерпнуть из исходных текстов проекта sg3_utils. Осталось попробовать реализовать это все на питоне.

Занимаясь программированием рендеринга графики, мы живём в мире, в котором обязательны низкоуровневые оптимизации, чтобы добиться GPU-фреймов длиной 30 мс. Для этого мы используем различные методики и разработанные с нуля новые проходы рендеринга с повышенной производительностью (атрибуты геометрии, текстурный кеш, экспорт и так далее), GPR-сжатие, скрывание задержки (latency hiding), ROP…

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


Быстрый обратный квадратный корень в Quake

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

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

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