Добрый день, уважаемые коллеги. Данная статья будет являться продолжением темы, начатой в посте habrahabr.ru/post/178103.
Продолжим с того момента, когда у нас уже есть значения конструктивных постоянных для двигателя Lego, и можно перейти к конструированию и обсчету робота. В качестве опытного образца остановимся на Segway. Это одна из наиболее показательных задач теории автоматического управления. Привожу конструкцию этого механизма.

Волею судеб мне довелось разбираться с организацией многозадачности, точнее псевдо-многозадачности, поскольку задачи делят время на одном ядре процессора. Я уже несколько раз встречала на хабре статьи по данной теме, и мне показалось, что данная тема сообществу интересна, поэтому я позволю себе внести свою скромную лепту в освещение данного вопроса.
Сначала я попытаюсь рассказать о типах многозадачности (кооперативной и вытесняющей). Затем перейду к принципам планирования для вытесняющей многозадачности. Рассказ рассчитан скорее на начинающего читателя, который хочет разобраться, как работает многозадачность на уровне ядра ОС. Но поскольку все будет сопровождаться примерами, которые можно скомпилировать, запустить, и с которыми при желании можно поиграться, то, возможно, статья заинтересует и тех, кто уже знаком с теорией, но никогда не пробовал планировщик “на вкус”. Кому лень читать, может сразу перейти к изучению кода, поскольку код примеров будет взят из нашего проекта.
Ну, и многопоточные котики для привлечения внимания.

Началась эта история с того, что начитавшись постов с тегом DIY я решил обзавестись набором МК + отладочная плата. Погуглив, узнал что самая дешевая в городе плата это LaunchPad от TI. Не долго думая, отправился за ней в магазин, и понеслась… как и у всех сначала были мигания светодиодами, потом подключение дисплея от Siemens CX75, и т.д.
Вскоре мне надоело делать что-то просто так, без цели, ради того что бы сделать. Так и возникла мысль создать себе гаджет, которым бы я пользовался постоянно.
За подробностями прошу под кат.

Автоматизировать свой дом я начал года 2 назад, в основном используя беспроводную технологию Z-Wave, но и ради фана собрал несколько устройств самостоятельно на микроконтролле ATtiny2313 и Raspberry Pi. Когда я принял решение, что буду делать умный дом, я поставил три задачи, которые умный дом должен был решать, первая — экономия электроэнергии, вторая — обеспечение комфорта, третья — отображение информации о сотоянии дома в реальном времени.

На данный момент удалось реализовать следующее:

• Автоматическое включение и выключение света в коридорах
• Управление телевизором с iPhone при помощи Raspberry Pi и ИК-модуля
• Метеостанция c датчиками температуры и влажности
• Пылесос iRobot, который скоро приобщится к WiFi

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

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

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

Данная статья является первой в планируемом цикле статей по изучению программирования микроконтроллеров. Изучая различные материалы я отметил, что практически все они начинаются с того, что новичку предлагается скачать (или использовать идущую со средой разработки) библиотеку для работы с периферийными устройствами и использовать ее для написания своей первой программы (обычно мигание светодиодом).

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

В этой статье, путь от фразы «Да, я хочу попробовать!» до радостного подмигивания светодиода, будет значительно длиннее чем у других авторов. Я постараюсь раскрыть аспекты программирования микроконтроллеров, которые прячутся за использованием библиотечных функций и готовых примеров.
Если вы намерены серьезно изучать программирование микроконтроллеров данная статья для вас. Возможно, она может заинтересовать и тех, кто вдоволь наигрался с Arduino и хочет получить в свои руки все аппаратные возможности железа.

Здравствуй, Хабр!


Решил написать статью о своем опыте работы с IR на Cubieboard.

Не так давно заказал себе это замечательное устройство (заказывал специально для будущего домашнего сервера, и, следовательно, использовать на ней только серверную ОCь) Выбор пал на Cubian (http://cubian.org/) в виду того, что строить свой велосипед пока не хочется.

Предполагалось развернуть на кубике nginx, php5, samba, mocd и несколько своих сервисов для управления блоком реле.
В ходе изучения кубика решил попробовать настроить IR на прием команд с пульта от старого TV тюнера, решение в виде lirc развернуть не получилось, стал искать другие решения, ничего доброго не нашел.

Написал свое решение, которым теперь делюсь с вами.

Некоторое время назад к нам обратился один потенциальный заказчик со своей идеей проекта «умного дома». Мы заказчикам всегда рады, особенно если у них есть более-менее внятная идея и достаточно денег для ее воплощения (сразу скажу — этот заказчик пока что является идеалом сферического заказчика в вакууме, повезло нам с ним). Так что после пары встреч родилось общее описание проекта, и мы приступили к поиску вариантов технической реализации. Нужен был недорогой контроллер с поддержкой WiFi и USB, небольшим энергопотреблением и, главное, с достаточно открытой архитектурой, чтобы мы могли сделать на его базе собственное кастомизированное решение.

И тут очень удачно попалась нам на глаза статья. Ух ты, какие штуки бывают, оказывается! У меня самого в качестве передвижной точки доступа для поездок по Китаю (где до сих пор RJ-45 розетка в номере при отсутствии WiFi — довольно частое явление) давно уже используется мини-роутер TP-LINK TL-WR702N, купленный рублей за 700, но тот факт, что внутри живет вполне приличный одноплатный компьютер с кучей дополнительных возможностей, стал для меня приятным сюрпризом. А поскольку мы по своему основному бизнесу плотно завязаны с Китаем (и китайскими производителями электроники в частности), стало нам интересно — во сколько же нам обойдется собственная плата на базе SoC AR9331, если целое законченное решение в корпусе, в коробке, с проводами и блоком питания, стоит в России 700р (на то время — $22) в рознице?

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

Теперь хотелось бы воспользоваться им «на полную катушку».

Пока не хватает следующих возможностей по удаленному управлению:

• Изменять временные характеристики работы выключателя.
• Узнать текущее его состояние.
• Управлять его состоянием.

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



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

И тогда пришло понимание, что домашнему роботу на первых порах совсем не обязательно ходить по дому. Вдохновением для нас стал Jarvis (Джарвис) — герой фильма «Железный человек». Это дворецкий, искусственный интеллект, не имеющий тела, но способный управлять различными устройствами в доме главного героя. В результате у нас получился Cubic — домашний робот, который живет дома и может полноценно (более или менее) разговаривать с его обитателями, а также управлять различными системами типа «умный дом».

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

Каждый решает проблему обучения по-своему. Кто-то читает много литературы, кто-то старается поскорее перейти к практике и разбираться по ходу дела, кто-то пытается объяснять друзьям всё, что сам изучает. А мы решили совместить эти подходы. Итак, в этом курсе статей мы будем шаг за шагом демонстрировать, как пишется простая операционная система. Статьи будут носить обзорный характер, то есть в них не будет исчерпывающих теоретических сведений, однако мы будем всегда стараться предоставить ссылки на хорошие теоретические материалы и ответить на все возникающие вопросы. Чёткого плана у нас нет, так что многие важные решения будут приниматься по ходу дела, с учётом ваших отзывов.

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

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

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

Знакомьтесь, это обычный «литровый» пакет молока:

• Проверка на внимательность: там 900 грамм. Рядом несколько по 950. Но пакет может быть воспринят как литровый.
• Проверка на знание физики. Рядом лежит похожий кефир. Объём измеряется в миллилитрах, масса — в граммах. Плотность кефира трагически выше плотности воды. То есть 900 грамм кефира 3,2% жирности — это примерно 874,5 миллилитров.

Второй пациент:



25 лет гарантии. Круто, правда? Есть одна проблема. Надо сохранять чек. Проверка, опять же, на знание физики. Чек у них печатается на обычной кассовой термоленте (я проверил на месте). У меня в офисе лежит много чеков. Мы их ксерокопируем, потому что через год-два они полностью выцветают. Самый старый чек, который видел коллега, держался 3 года в папке в архиве. UPD: смотрите самый низ топика, Икея ответила.

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

Осторожно, трафик: под катом много находок с фотографиями.

После продолжительного обсуждения объявлены победители конкурса Grand C++ Error Explosion Competition. Награды должны были объявить в двух номинациях. Участники первой соревновались по максимальному количеству ошибок на минимальный объём кода. Вторая номинация — творческая, там важно не количество и размер, а качество и красота глюков.

В итоге, абсолютным победителем назван программист Эд Хэнвей (Ed Hanway), приславший такую программу.

#include ".//.//.//.//jeh.cpp"
#include "jeh.cpp"
`

Некий Питер Коттл (Peter Cottle) сделал интерактивную обучалку по основам ветвления в Git. Есть несколько простых обучающих уровней, где нужно сделать пару коммитов, а затем merge или rebase, есть и сложные уровни, над которыми придется подумать. Можно также сохранять уровни и делиться ими с друзьями.

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

Собственно, метеодатчик — это, наверное, второе что все делают после того, как помигают светодиодом на Arduino. А раз уж этой участи не избежать, то надо разобраться с ней как можно быстрее, чтобы уже двигаться дальше.

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

Честно скажу: сначала я хотел делать добро и бросать его в воду отправлять погоду на Openweathermap.org и даже какое-то время делал это. Но потом началось — то сервис внезапно откажет, а я сижу и гадаю, что случилось, то его IP поменяется, и мне надо снова лезть в код центрального контроллера.

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

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

То есть, умный дом — это дом, который может все. А удобный дом — это дом, который все, что может, делает сам.

Давайте сначала я просто похвастаюсь тем, что умеет мой дом сейчас, а вы решите, имеет ли смысл читать про мой местами горький (а местами очень даже ничего) опыт дальше, ок?

История появления на свет центрального домашнего контроллера довольно запутанна. Мне кажется, если на секунду отвлечься и представить его в виде зимнего леса (вид сверху), то можно будет увидеть беспорядочные тропинки, плохо замаскированные ямы и, возможно, бродящего где-то в глуши И. Сусанина.

Функционал наращивался постепенно: сначала подключил беспроводные розетки, потом замахнулся на выключатели света. Аппетиты росли — датчики протечки, задымления, дверей, метеодатчики, радиореле и управление AV-техникой. Мастерство росло не так быстро. Поэтому получилось то, что получилось: вещь, бесконечно далекая от гайдлайнов по программированию и устройству электронных схем, но вполне работоспособная.

И знаете что? Меня это устраивает.

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

Джефф Дин считается кем-то вроде Чака Норриса. Отличие только в том, что он вовсе не герой боевиков, а инженер-программист компании Google.

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