Как отлаживают программы микроконтроллеров? Берется JTAG, осциллограф – пара дней/недель и программа отлажена. Таким будет типичный ответ, и в большинстве случаев он будет правильным… Но не всегда. Микроконтроллеры решают очень разные задачи, и в этой статье мы рассмотрим, что делать, если нужно разработать громоздкое ПО низкоуровневого управления каким-либо силовым электрооборудованием, например, преобразователями частоты для электродвигателей, DC/DC преобразователями заряда АКБ для поезда, корректорами мощности, сервоприводами и т.п. Оборудованием, где протекают килоамперы и ШИМят киловольты, где на счету каждая коммутация IGBT ключей инвертора, где время реакции микроконтроллера на нештатную ситуацию измеряется в микросекундах, а само оборудование в герметичных корпусах устанавливается и эксплуатируется где-нибудь на заводах Якутии. Если вы хотите узнать, какие особенности это накладывает на способы отладки – добро пожаловать под кат.

Open Source проекты с каждым днём набирают всё большие обороты, появляются новые, активно развиваются популярные.
Такие проекты как Bootstrap, Angular.js, Elasticsearch, Symfony Framework, Swift и многие другие привлекают новых разработчиков, их сообщество растёт. Всё это даёт огромный рост проектам, а самим разработчикам интересно поучаствовать в разработке чего-то, чем пользуется весь мир.

Я, как и многие другие программисты, не устоял и также время от времени участвую в разработке Open Source проектов, в основном на PHP. Но когда я начинал, я столкнулся с проблемой — я не знал, как правильно организовать процесс «контрибьютинга», с чего начать, как сделать так, чтобы мой Pull Request рассмотрели и т.д.

Всем начинающим «контрибьютерам», которые столкнулись с похожим проблемами, добро пожаловать под кат.

Состояние дел

Это обсуждение относится к ядру операционной системы Linux, и представляет интерес для разработчиков модулей ядра, драйверов под эту операционную систему. Для всех прочих эти заметки вряд ли представляют интерес.

Или как я перестал бояться и полюбил ассемблер

Однажды летом, я устроился в родном университете программистом микроконтроллеров. В процессе общения с нашим главным инженером (здравствуйте, Алексей!), я узнал, что чипы спиливают, проекты воруют, заказчики кидают и появление китайского клона наших программаторов для автомобильной электроники — лишь вопрос времени, задавить их можно только высоким качеством. При всем этом, в паранойю впадать нельзя, пользователи вряд ли захотят работать с нашими железками в ошейниках со взрывчаткой.

Хорошая мера защиты — обновления программного обеспечения. Китайские клоны автоматически отмирают после каждой новой прошивки, а лояльные пользователи получают нашу любовь, заботу и новые возможности. Робин Гуды при таком раскладе, естественно, достанут свои логические анализаторы, HEX-редакторы и начнут ковырять процесс прошивки с целью ублажения русско-китайского сообщества.

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

Публикую перевод статьи «Sidechains: How Many Sides Does a Cryptocurrency Have?» Рэя Паттерсона (Ray Patterson) с сайта Bytecoin.org.

Не существует «самой лучшей» криптовалюты

Bitcoin прекрасен, Bytecoin прекрасен, Doge прекрасен.
Все криптовалюты прекрасны (ну, или давайте на секундочку представим, что это так).

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

Естественно, вы можете просто собрать другую криптовалюту, которая будет сочитать в себе все лучшие «фичи». Что-то вроде стандрата для криптовалют. Погодите… Это мне что-то напоминает.



Конечно, такой подход возможен… теоретически. Но на практике это становится невыполнимым.
Во-первых, идея «самого лучшего» крайне субъективна. Не всем кажется, что функция «demurrage»(плата за простой монетки в кошельке) у Freicoin – довольно полезная функция. Выбор стандарта из всевозможных вариаций Proof of Work также стало было колоссальным испытанием.

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

Преумножая альткойны

Вот вам иная точка зрения. Представьте себя счастливым разработчиком криптовалюты. Вы изобрели новую функцию и теперь хотите её протестировать в реальных условиях. Вы не можете слепить всё на скорую руку и закинуть на рынок (ваш проект крайне важен для вас), но вы не можете протестить новую «фичу» без реальных пользователей. Что делать?

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

Покупка заводов в Сибири была стратегически правильным решением для компании “Лифт ми Ам”. После того, как лифты стали ездить не только вверх, но и вниз, дела компании пошли… нет полетели, вверх. Лифты начали разбирать, как горячие пирожки со стола. Название уже не соответствовало действительности и было принято решение о ребрендинге. (На самом деле их замучила судебная тяжба с Моби).
Итак, под крыло ЛинкМиАп планируется взять заводы в Новосибирске, Томске и Брно. Самое время подумать о том, как это хозяйство подключить к имеющейся сети.

Итак, сегодня рассматриваем
1) Возможные варианты подключения, их плюсы и минусы
2) Site-to-Site VPN на основе GRE и IPSec
3) Большая тема: динамическая многоточечная виртуальная сеть (DMVPN) в теории и на практике.

В традиционном видео лишь ёмкая выжимка из статьи, посвящённая работе и настройке DMVPN.

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

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

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

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

Чтобы Яндекс показал Ваш сайт в числе первых, нужно чтобы он максимально полно отвечал на запрос пользователя. И это будет уже половина успеха. Оставшаяся половина это удобство, техническая составляющая сайта и его простота. Ниже я привел чек-лист из 68 пунктов, который был разработан специально для системы управления задачами PTYSH, совместно с компанией DFAKTOR. А теперь я делюсь им с Вами. Кропотливое выполнение каждого пункта из данного чек-листа позволит вывести практически любой сайт на самый верх поисковой выдачи. Но придется как следует поработать. Начнем с самого малого.

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

Если вам интересно, чем безопасности прошивки могут помочь STM, SGX и PSP — жду вас под катом.

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

Всем привет. Этот пост о серверном решении для интернета вещей, который я написал на асинхронных сокетах с использованием всем известной Netty. Я расскажу о задаче, которую мы ставили перед собой, о том почему я выбрал Netty, почему у нее нету альтернатив, какие у нетти недостатки и преимущества и как можно выжать максимум. Сейчас наш сервер в среднем обрабатывает 1.5 млрд сообщений в месяц и нагрузка с каждым месяцем растет на 20%. Для привлечения внимания — нагрузка на один продакшн сервер с 4-мя ядрами Xeon® CPU E5-2630L v2 @ 2.40GHz при лоаде в 500 рек-сек.



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

Все началось около 2-х лет назад, когда мне подарили arduino. Я всегда мечтал сделать какое-то интересное устройство своими руками. Но все эти паяльники, резисторы, вольты-амперы меня постоянно отпугивали. Так было, пока не появились arduino. С ардуиной я смог наконец-то управлять электроникой. Сказать, что это было очень круто — не сказать ничего. Я был счастлив. Но, как это часто бывает, после освоения базовых навыков в микроконтроллерах, захотелось большего — управлять устройствами через интернет с телефона. Быстрый гуглинг показал (дело было 2 года назад), что на текущий момент нет ни одного решения, которое бы решало эту задачу. Не считая IoT облака с HTTP API, которые было не очень удобно использовать.

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

После небольшого перерыва продолжаем разговор о безопасности UEFI. В этот раз речь пойдет о технологии SecureBoot, ее преимуществах и недостатках, об атаках на нее и защите от них.

Впервые о SecureBoot речь зашла в стандарте UEFI 2.2 в 2011 году, но окончательно все аспекты были реализованы в версии 2.3.1C в начале 2012 года. Основным разработчиком технологии была Microsoft, которая сразу же заявила, что для получения сертификата Windows 8 Ready для своей еще не выпущенной новой ОС требуется реализация и включение SecureBoot по умолчанию на всех новых ПК. Это заявление вызвало волну резкой критики со стороны сторонников свободного ПО, которая успешно докатилась и до Хабра.
Если вам интересно, чем именно закончилось противостояние MS и сообщества, как SecureBoot выглядит после почти 4 лет взросления, и какие атаки на него все еще возможны — добро пожаловать под кат.

Стоп, чуть не забыл: по доброй традиции, набор ссылок на предыдущие части, для тех, кто умудрился их пропустить.

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

Из этого материала вы узнаете о том, как использовать профиль общих атрибутов (Generic Attribute Profile, GATT) при организации взаимодействия Intel Edison с Texas Instruments SensorTag по протоколу Bluetooth Low Energy.

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

Но если вы проводите за своим инструментом до 80% рабочего времени, то желательно убедиться, что вы не тратите время впустую и что работа доставляет вам удовольствие. В этой статье я бы хотел немного рассказать про те инструменты, которыми я лично пользуюсь каждый день, и про то, как они улучшают user experience (и, часто, продуктивность) при работе с консолью и с удаленными серверами в частности.

Проблемы ssh

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

1. При высоком round-trip latency (>100 ms) пользовательский ввод появляется с ощутимой задержкой, а при использовании мобильного интернета с edge (latency 1000 ms) работа становится подобна пытке
2. При временных проблемах (несколько минут) с доставкой пакетов, соединение может порваться с write failed: broken pipe, причем узнаете вы об этом только при попытке ввода или при использовании настроек вроде keepaliveinterval

Первая проблема неразрешима потому, что ssh by-design является просто транспортом для байтов, и существующие приложения на это поведение расчитывают. Поскольку ssh не пытается интерпретировать этот поток байтов, он не может осуществлять предиктивный ввод. Лично для меня именно эта проблема наиболее актуальна, поскольку мне приходится работать с серверами в европе и США, и во втором случае задержка составляет около 200 мс и является принципиально неустранимой, по крайней мере до изобретения квантовой коммуникации или чего-нибудь подобного. Вторая же проблема проявляется в наших условиях относительно редко, но всё же неприятно переустанавливать все соединения при сбоях сети (и перезапускать упавшие приложения, если они почему-то не были запущены в screen).

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

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

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

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

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

Некоторое время назад ко мне в руки попал набор разработчика DE0-Nano-SoC, построенный на базе чипа Altera Cyclone V. Данный набор используется мной не с какой-то одной целью — с его помощью решаются разные задачи. Для каждой из этих задач создаётся схема для FPGA и пишется программа для HPS. Схема для FPGA создаётся в среде Quartus II и в процессе разработки загружается в FPGA через JTAG-интерфейс посредством USB-бластера. Когда же схема окончательно отлажена, она записывается на SD-карточку в виде файла прошивки. Затем, когда нужно использовать плату с той или иной целью, берётся нужная прошивка, загружается в FPGA командой вида

cat hardware.rbf > /dev/fpga0

и затем запускается нужная программа.

Всё шло своим чередом, но однажды я обновил в плате ядро Linux — о чём рассказывал в этой статье. И вот спустя некоторое время обнаружилось, что из списка драйверов исчез FPGA-менеджер, позволявший загружать прошивку в FPGA подобным способом. Первой мыслью было то, что я забыл включить драйвер в конфигурацию при сборке ядра. Однако, к моему удивлению, скоро обнаружилось, что среди исходников ядра этого драйвера нет в принципе! Конечно, можно было бы грузить прошивку в FPGA другими способами, коих есть ещё как минимум три. Но этот способ был для меня наиболее оперативным и удобным, вот почему было принято решение восстановить утраченный функционал. Если Вам интересно, как это было сделано — добро пожаловать под кат.

Сейчас очень много статей, рапортующих об успехах нейронных сетей, в частности, в интересующей нас области понимания естественного языка. Но для практической работы важно еще и понимание того, при каких условиях эти алгоритмы не работают, или работают плохо. Отрицательные результаты по понятным причинам часто остаются за рамками публикаций. Часто пишут так — мы использовали метод А вместе с Б и В, и получили результат. А нужен ли был Б и В остается под вопросом. Для разработчика, внедряющего известные методы в практику эти вопросы очень даже важны, поэтому сегодня поговорим об отрицательных результатах и их значении на примерах. Примеры возьмем, как известные, так и из своей практики.

До недавнего времени в Одноклассниках в качестве основного Linux-дистрибутива использовался частично обновлённый OpenSuSE 10.2. Однако, поддерживать его становилось всё труднее, поэтому с прошлого года мы перешли к активной миграции на CentOS 7. На подготовительном этапе перехода для CentOS были отработаны все внутренние процедуры, подготовлены конфиги и политики настройки (мы используем CFEngine). Поэтому сейчас во многих случаях миграция с одного дистрибутива на другой заключается в установке ОС через kickstart и развёртывании приложения с помощью системы деплоя нашей разработки — всё остальное осуществляется без участия человека. Так происходит во многих случаях, хотя и не во всех.

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

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

Речь пойдет не о чудесных Граалях, продаваемых в интернете, не о высокочастотной торговле и не о «безрисковых» вложениях в мифические ТОП-20 лучших трейдеров. Только хардкор: мы проводим многочисленные торговые операции, кто-то вручную, кто-то ― автоматически, и получаем в результате этих операций положительный прирост счета при статистически значимом количестве сделок.

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