Откуда есть пошла идея

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

Итак, основная идея RR — запустить гоночные КП на шарах в воздух, на некоторой случайной высоте высоте шары будут лопаться, а КП — падать на парашютах. КП будут отдавать свои GPS координаты на сервер гонки, а участники будут их потом искать. В принципе, правила соревнований составлены так, чтобы КП-зонды возвращались организаторам силами участников. Естественно, кроме тех зондов, которые отличились повышенным рандомом и улетели куда-то в за.. далеко. Такие КП приходится искать организаторам собственными силами. Так получилось, что в результате я занялся техническим решением задачи «последних 100 метров», когда организаторы приехали на место, найти КП очень хочется, а координаты неточные. С этой целью было задумано использовать радиопеленгацию — каждый зонд несет радиопередатчик, а организаторы несут приемник-пеленгатор.

Предисловие

Прочитав много увлекательных статей об интересных разработках под FPGA, таких как тетрис, радиопередатчик и другие, я тоже загорелся идеей сделать что-нибудь для души. Для этой цели мной была приобретена камера OV7670 и отладочная плата DE-1 фирмы Terasic с чипом Cyclone II фирмы Altera. Задачу поставил следующую: вывести изображение с камеры на VGA монитор. Для того, чтобы оправдать использование FPGA, я собираюсь сделать это на максимальной для камеры скорости. Должен отметить, что легче понять эту работу помогут знания в области электроники: знания интерфейсов VGA и I2C, представление о SDRAM памяти и т.п.

В этой серии из двух статей о производительности и памяти описываются базовые принципы и приводятся советы для разработчиков по повышению производительности программного обеспечения. Эти статьи затрагивают, в частности, работу памяти и компоновку. В первой части было рассказано об использовании регистров и о применении алгоритмов блокирования для повышения многократного использования данных. В этой части статьи сначала описывается компоновка данных для обычного распараллеливания — программирования для общей памяти с потоками, а затем распределенные вычисления по сетям MPI. В статье описываются понятия, связанные с распараллеливанием: векторизация (инструкции SIMD) и работа с общей памятью (многопоточная архитектура), а также вычисления с распределенной памятью. И наконец, в этой статье сравниваются компоновки данных «массив структур» (AOS) и «структура массивов» (SOA).

В этой серии из двух статей говорится о том, как структура данных и памяти влияет на производительность. Предлагаются определенные действия для повышения производительности программного обеспечения. Даже простейшие действия, показанные в этих статьях, позволят добиться существенного прироста производительности. Многие статьи, посвященные оптимизации производительности программ, рассматривают распараллеливание нагрузки в следующих областях: распределенная память (например, MPI), общая память или набор команд SIMD (векторизация), но на самом деле распараллеливание необходимо применять во всех трех областях. Эти элементы очень важны, но память также важна, а про нее часто забывают. Изменения архитектуры программ и применение параллельной обработки влияют на память и на производительность.

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

Но что если попробовать применить подобные матрицы в своих устройствах на микроконтроллерах? Какой интерфейс обмена и логика вывода у этих матриц?
Попробуем с этим всем разобраться.

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

Краткое предисловие:

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

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

В прошлой части статьи о разработке PowerBank для ноутбука мы остановились на изготовленном макете, измеренном КПД и пониманием того, что делать дальше. А дальше нужно было оживлять железку. Поэтому представляю вашему вниманию часть вторую: ПО макета.

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

В этой работе рассматриваются вопросы, связанные с прямым и обратным преобразованием “программная переменная – сигнал”: особенности построения каналов передачи данных, подключения периферии к шинам процессора, вопросы адресной приёма-передачи данных и работа гипотетического процессора при обмене данными с внешним устройством.

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

Рис. 1. Схема с неопределенным напряжением в линии передачи. В реальной схеме функцию ключа может выполнять транзистор.

В схеме Рис. 1 при замыкании ключа приёмнику передается 5В источника, однако, когда ключ разомкнут на входе приемника находится неопределенное напряжение.
Этой неопределенности нет в схеме Рис. 2, которая имеет два устойчивых состояния 5В или 0В. Сопротивление R добавлено в схему передатчика для ограничения тока через замкнутый ключ. Переходный процесс в линии пропорционален произведению ёмкости линии на выходное сопротивление передатчика, которое отличается при установлении и сбросе напряжения в линии. При установке напряжения в линии происходит заряд ёмкости через сопротивление R. Во время сброса напряжения ёмкость разряжается через сопротивление замкнутого ключа.


Рис. 2. Передача двух состояний 5В и 0В. Тождественные схемы. Постоянная времени (R*C) перехода из 0В в 5В (заряда емкости) больше постоянной разряда линии через идеальный ключ с нулевым сопротивлением.

Так как мой предыдущий мод на ардуине имел много ограничений, а также в плане самообразования — я решил сделать новую версию на STM32F373C8T6. Это мой первый проект на STM32, в нем довольно много недоработок. Надеюсь, кого-нибудь еще заинтересует, и мы сможем сделать его лучше!

Проект на github-е

Привет Хабр. Изучение FPGA я начал совсем недавно. Одним из моих проектов, который был направлен на изучения интерфейсов PS/2 и VGA, была игра в Пин-Понг на одного человека. Одна из реализаций которой работает на плате DE0-CV, которую мне любезно предоставил замечательный проект Silicon Russia в рамках конкурса (http://www.silicon-russia.com/2015/12/11/board-giveaway-for-mipsfpga/).

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

Введение

Я занимаюсь разработкой приложений и драйверов для различных устройств авиационного применения. В Авиации используются ОС с более жесткими требованиями к надежности(ARINC 653), такие как VxWorks653, PikeOS или LynkOS. Разрабатывая приложения для авионики возникла проблема медленного доступа к данным на твердотельных накопителях подключенным по интерфейсу ATA. Это происходило из-за использования медленного программного интерфейса ATA. Я решил эту проблему реализацией драйвера AHCI.

В этой статье Я хочу кратко описать работу AHCI.


Архитектура устройства с AHCI контроллером.

Надеюсь, что долгожданное продолжение цикла заметок об операционной системе реального времени QNX. В этот раз я бы хотел рассказать о Qnet — собственном сетевом протоколе QNX. Сразу уточню, что помимо родной сети Qnet, в QNX поддерживается стек протоколов TCP/IP, работа с которым в общем-то должна быть знакома администраторам Unix-подобных систем. Поэтому в заметке сначала немного расскажу о сетевом администраторе io-pkt, а потом более подробно о протоколе Qnet. По ходу повествования нас также ждут четыре лирических и одно техническое отступления.

Что такое Qnet?

Сеть QNX представляет собой группу соединённых между собой целевых систем, каждая из которых работает под управлением ОСРВ QNX Neutrino. В такой сети любая программа имеет доступ к любому ресурсу на любом узле (node, именно так называются отдельные компьютеры в сети). В качестве ресурса может выступать файл, устройство или процесс (в том числе обеспечивается и запуск процессов на другом узле). При этом целевые системы (те самые узлы) могут представлять собой компьютеры различных архитектур — x86, ARM, MIPS и PowerPC (текущая реализация Qnet работает в том числе и в cross-endian среде). Но словно этого мало, любое POSIX-приложение, портированное в QNX (для переноса зачастую требуется только пересборка) без всякой доработки будет обладать перечисленными выше способностями работы в сети Qnet. Заинтригованы, как это получается?

Сейчас я расскажу вам о том, как можно сэкономить немалое количество времени и денег на вашей IT-инфраструктуре.
Как централизованно админить большое количество linux рабочих станций не разводя при этом хаос в вашей экосистеме.
И так, что же такое LTSP?

LTSP — Это терминальное решение на Linux.
Говоря "терминальное", я в первую очередь имею в виду не подключение к удаленному рабочему столу как в Windows. Я подразумеваю гораздо более гибкую и продвинутую систему доставки ПО, конфигов, домашенего каталога, да и самой операционной системы на клиентские рабочие станции с вашего терминального сервера.

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

У LTSP есть несколько режимов работы:

• тонкий клиент
• толстый клиент

К юбилею выхода шутера от первого лица Serious Sam, который состоялся в марте 2016 года, разработчики игры из хорватской компании Croteam решили открыть исходный код игрового движка Serious Engine 1 v.1.10. Он заинтересовал много разработчиков, которые захотели изучить и улучшить движок. Я тоже решил поучаствовать в улучшении кода и подготовил статью с обзором ошибок, найденных с помощью статического анализатора PVS-Studio.

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

В данной статье мы будем разрабатывать (программную) модель суперскалярного процессора с OOO и фронтендом стековой машины.

Последняя статья про классические примитивы синхронизации.

(Наверное, потом напишу ещё одну про совсем уже нетипичную задачу, но это потом.)

Сегодня мы немножко заглянем в процессор. Чуть-чуть.

По сути, мы будем говорить про единственный примитив, который принципиально отличается от остальных: спинлок. Spinlock.

В комментариях к предыдущим заметкам возникла дискуссия — насколько справедливо вообще выделять спинлок как примитив, ведь по сути он — просто мьютекс, верно? Он выполняет ту же функцию — запрещает одновременное исполнение фрагмента кода несколькими параллельными нитями.

На уровне процесса всё так и есть — различия между спинлоком и мьютексом — чисто технические, вопрос реализации и производительности.

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

Дело в том, что внутри ядра мьютекс реализован с помощью спинлоков, а вот спинлоки реализованы сами по себе, автономно. Они — действительно базовый примитив. Ниже — только сам процессор.

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

Итак, иерархия реализации такова: mutex/cond/sema сделаны на базе спинлоков, спинлоки — на базе атомарных операций, предоставляемых процессором. Мы в них немного заглянем сегодня.

Как устроен спинлок?

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

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

Напомню фрагмент кода:

while(total_free_mem <= 0)
    {
    wait_cond(&got_free_mem, &allocator_mutex);
    }

Здесь цикл вокруг wait_cond гарантирует нам, что даже если мы вернёмся из ожидания события случайно или по ошибке, ничего страшного не случится — проверка в while обеспечит нам уверенность, что нужное состояние проверяемого объекта достигнуто. Если нет — поспим ещё в ожидании.

Отметим ещё раз, что проверяем мы состояние объекта (total_free_mem <= 0) при запертом мьютексе, то есть никто не может его менять в то же самое время.

Почему, зачем и как Солнечная система приняла свою форму.