Введение

Мотивом для этой публикации послужил доклад «Using the R Software for Log File Analysis» на конференции USENIX, который был обнаружен в интернете при поиске ответов на очередные вопросы. Поскольку была написана целая печатная статья, логично предположить, что тема обладает актуальность. Поэтому решил поделиться примерами решения подобного рода задач, решению которых не придавалось такого значения. Фактически, «заметки на полях».
R, действительно, очень хорошо подходит для подобных задач.

Является продолжением предыдущих публикаций.

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

Впервые я задумался о том, как разрабатывают игры под приставки где-то через 20 минут после того, как в самый первый раз увидел Turbo Pascal. На глаза иногда попадался Subor с клавиатурой, и появилась мысль: "Наверное можно набрать какую-то программу, а потом в нее поиграть". Но интерес быстро затух, потому что абсолютно никакой информации по этой теме тогда не было доступно. Следующий раз эта же идея всплыла, когда увидел вполне играбельные эмуляторы старых консолей. Тогда стало ясно, что вбивать листинг в саму консоль и необязательно. Где-то очень потом появился Хабр с благожелательной аудиторией для таких вещей. В какой-то момент даже начал собирать разрозненную инфу чтобы написать мануал самому, и вот сегодня наткнулся на готовый учебник, который явно надо перевести.

Разработка под старые консоли документирована вдоль и поперек, но именно по NES 99% информации относятся к разработке на Ассемблере. Меня почему-то зарубило, что надо освоить именно работу с С.

следующая >>>

Приоритетная структура кода

В разработке электронных устройств грань между разработчиком-схемотехником и разработчиком-программистом очень размыта. Что уж говорит о том, кто должен писать RTL под FPGA.

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

Производители микросхем тоже не отстают, стали паковать ПЛИС в один корпус с процессором, даже Intel выпустил процессор для PC с FPGA внутри, купив для этого известного производителя ПЛИС Altera.

Думаю всем истинным программистам Вселенная шлет сигналы, что им просто необходимо изучить RTL и начать писать “код” для FPGA не хуже, чем под их привычные процессоры.
Когда-то давно, я проходил этот путь и позволю себе дать несколько советов для ускорения.

SDR, или программно-определяемая радиосистема – это устройство для работы с радио, в котором работает мини-компьютер со специальным программным обеспечением. Он заменяет традиционные аппаратные компоненты: фильтры, усилители, модуляторы и демоуляторы. Это позволяет создать радиоприемник, работающий с самыми разными протоколами. Вообразите себе радиолу, которая кроме «ХитFM» может принимать аналоговое и цифровое телевидение, связываться по Wi-Fi, Bluetooth и GPS, а также засекать излучение пульсаров.

А теперь представьте себе американского девятиклассника, который решил сделать такую радиолу, заказал через интернет ПЛИС, радиомодуль, развёл шестислойную плату, а потом своими руками смонтировал на неё почти 300 компонентов. И через три ревизии это всё у него заработало!

Предисловие

• список тем, которые должен освоить начинающий разработчик под FPGA
• рекомендуемую литературу по каждой из тем
• набор тестовых вопросов и лабораторных работ
• классические ошибки новичков (и советы по исправлению)

Дипольная антенна

• Пока ещё явно недостаточно компетентен.
• Есть много более объективные ресурсы рассказывающие об этих темах.

An urban myth has circulated for years that Linux did a better job avoiding swapouts than FreeBSD, but this in fact is not true. What was actually occurring was that FreeBSD was proactively paging out unused pages in order to make room for more disk cache while Linux was keeping unused pages in core and leaving less memory available for cache and process pages.