Оглавление

1. Введение (vim_lib)
2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
3. Уровень проекта и файловая система (vim_prj, nerdtree)
4. Snippets и шаблоны файлов (UltiSnips, vim_template)
5. Компиляция и выполнение чего угодно (vim-quickrun)
6. Работа с Git (vim_git)
7. Деплой (vim_deploy)
8. Тестирование с помощью xUnit (vim_unittest)
9. Библиотека, на которой все держится (vim_lib)
10. Другие полезные плагины

Часто ли вам приходится использовать Git? В смысле, вы коммитите изменения каждый час или каждые несколько минут? Я делаю это очень часто и не слежу за чистотой репозитория, так как считаю его не более чем журналом изменений, а не произведением искусства. Такой подход требует от редактора хорошей интеграцией с Git, позволяющей в пару нажатий клавиш создать новый коммит, вернуться в прежнее состояние, перейти на другую ветку и так далее. Если вы используете современную среду разработки, в которой реализована интеграция с Git, вам очень повезло, но что делать пользователям редактора Vim? Есть ли плагин, который не просто реализует Vim-команды по тиму GitCommit, GitCheckout и GitBranch, а предоставляет удобный интерфейс в лучших традициях редактора?

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

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

День добрый! В прошлой статье я описывал, как «поднять» с нуля SoC от Altera.
Мы остановились на том, что измерили пропускную способность между CPU и FPGA, когда копирование выполняется процессором.

В этом раз мы пойдем немного дальше и реализуем примитивный DMA в FPGA.
Кому интересно — добро пожаловать под кат.

На днях ко мне в руки попала EBV SoCrates Evaluation Board. В двух словах — это плата с SoC от фирмы Altera, на борту которой есть двухъядерный ARM и FPGA Cyclone V.

ARM и FPGA на одном чипе — это должно быть очень интересно! Но для начала всё это добро нужно «поднять».
Об этом процессе я и поведаю в данной статье.

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

А в качестве маленького бонуса измерим пропускную способность между CPU и FPGA.

Данная статья касается современных линуксов. Например, RHEL6 с ядрами 2.6.3х — подойдёт, а вот RHEL5 с ядрами 2.6.18 (кстати, наиболее популярный в продакшне) — увы, нет. И ещё — здесь не будет описания ядерных отладчиков или скриптов SytemTap; только старые-добрые простые команды вида «cat /proc/PID/xyz» в отношении некоторых полезных узлов файловой системы /proc.

Диагностика «тормозящего» процесса

Вот хороший пример часто возникающей проблемы, которую я воспроизвёл на своём лаптопе: пользователь жалуется, что команда find работает «значительно медленнее», при этом не возвращая никаких результатов. Зная, в чём дело, мы решили проблему. Однако меня попросили изложить систематический подход к решению подобных задач.

К счастью, система работает под управлением OEL6, т.е. на достаточно свежем ядре (а именно — 2.6.39 UEK2)

Итак, приступим к диагностике.

Часть первая, про потоки

В реальной жизни часто случается так, что некоторые события происходят с разной переодичностью (а могут и вообще не происходить). Скажем, заказ сока в «Макдональдсе», нажатие кнопки пользователем или заказ лыж в прокате. А наш могучий микроконтроллер должен все это обрабатывать. Но как это сделать наиболее удобно?

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

Немного лирики

По роду своей деятельности постоянно общаюсь с профессиональной аудио аппаратурой, поэтому целью этой разработки было получить устройство, обладающее высокой верностью воспроизведения. Поэтому схемотехнические решения без ООС сразу были отброшены и за основу была взята композитная схема, обладающая большим потенциалом. Приходилось встречать несколько устройств с такой топологией, однако в большинстве конструкций были использованы приборы LT1795 или AD815. Однако как упоминал в одной из своих статей Дмитрий Андронников (aka Lynx):

даже весьма мощные ОУ с ТОС при подключении к их выходу наушников сопротивлением ниже 50...60 Ом работают в достаточно напряженном режиме как по выходному току (что приводит к росту искажений), так и по тепловыделению.

Было решено привлечь «тяжелую артиллерию», но об этом ниже.

Купил простенькие уши, чтоб по ночам можно было гаматься и иногда слушать музыку, взял недорогие, но большие KOSS UR20. Подключив к ресиверу был несколько ошарашен, звук очень и очень приятный, джаз и классика просто на ура идут. По НЧ конечно сильно проигрывают затычкам Koss the plug, и ощутимо KOSS Porta Pro, которые уже какой год таскаю как портативные. Был очень удивлен после когда решил послушать Koss Porta Pro после прослушивания композиций на KOSS UR20 — с порта про как будто в уши ваты натолкали. А я ведь считал их очень «приличными» в плане звука. Хотя может это время и атмосфера их могла так попортить? Все это к чему? Да так, решил собрать усилок для ушей, Усилок будет домашний, не портативный ни разу.
Решил для начала собрать клон Lehmann Audio Black Cube Linear doctorhead.ru/catalogue/?i=523
Вот результат:

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

Списки книг

• 25 бесплатных книг по информатике
• Шпаргалки
• CodePlex: Список бесплатных книг
• Бесплатные технические книги
• Galileo Computing (Немецкий)
• How to Design Programs: An Introduction to Computing and Programming
• Microsoft Press: Бесплатные книги
• MindView Inc
• Проект O'Reilly's Open Books
• TechBooksForFree.com
• Theassayer.org
• Wikibooks: Программирование
• Неплохая подборка, редактируемая сообществом (JIghtuse)
• Книги на Русском (telteron)

Программирование графики

(Статья доступна для оффлайн чтения: Markdown | PDF | PDF (print) | HTML)

Зачем?

Все вокруг постоянно говорят: «Хочешь научиться писать профессиональные программы? Посмотри, как это делают другие!». Вот и я решил последовать этому совету, тем более что моё обучение в университете как раз подходит к концу. Особенно интересно сравнить то как учили делать и то как делается в реальном мире. В качестве примера для подражания был выбран пакет GNU Coreutils. В нём есть всё:

1. Жёсткие требования к переносимости.
2. Большой жизненный цикл.
3. Огромная команда разработчиков.
4. Код различной сложности: от тривиального echo до супер-изощерённого sed, от чисто прикладного wc до более близкого к ОС mkdir.

Предыстория

Мой частный дом отапливается при помощи электрических конвекторов. Всё в них хорошо: и лёгкость монтажа и автоматическое управление температурой и режим день/ночь и режим 50% мощности. Но есть и минус — датчик температуры воздуха закреплён прямо на корпусе конвектора, поэтому нагревается и остывает вместе с ним. Из-за этого конвектор включается/выключается гораздо чаще, чем хотелось бы, невозможно установить желаемую температуру воздуха в комнате, т.к. реальная будет ниже градусов на 5, да и на надёжности постоянные переключения реле сказываются негативно. Можно было, конечно, удлинить датчик температуры и отнести его подальше, но это не наш метод. Т.к. я давно занимаюсь беспроводными технологиями и есть наработки, то решил оснастить конвектор беспроводным датчиком температуры. Это позволит разместить его в любом месте комнаты, не тянуть провода, а если нужно, использовать не один, а несколько датчиков и рассчитывать среднюю по комнате температуру. (Под катом картинки)