Данная статья продолжение серии топиков Элемент задержки на VHDL, Элемент задержки на VHDL. Другой взгляд о элементах задержки на VHDL реализованных в ПЛИС.
Акцент будет сделан на конкретный прикладной пример, который любой желающий может запустить в симуляторе или реальном железе. Пример создан для удобной симуляции в среде Xilinx ISE с использованием Modelsim SE и с минимальными изменениями реализован в полноценное IP Core.
Читать полностью »
Как я уже писал в своей первой статье, не так давно я перешел c С++ на Scala. И вместе с этим я начал изучать модель акторов в исполнении Akka. Наиболее яркое впечатление на меня произвела лекгость реализации и тестирования конечных автоматов (finite-state machines, FSM), которую предоставляет эта библиотека. Уж не знаю, почему именно так получилось, учитывая изобилие остальных прекрасных и полезных вещей в Akka. Но теперь в моем первом проекте на Scala я использую конечные автоматы при каждой выпадающей возможности, подкрепленной целесообразностью (как я искренне надеюсь). И вот я решил, что готов поделиться с сообществом теми знаниями об Akka.FSM, а также некоторыми хитростями и личными наработками, которые я успел накопить. Подобной темы на хабре я не нашел (да и вообще со статьями про Scala и Akka здесь как-то не густо), и решил, не затягивая, исправить положение и выговориться, пока кто-то не сказал всего раньше меня. А чтобы было не скучно — предлагаю вместе реализовать поведение самого настоящего электронного кота. Хотелось бы верить, что какая-то одинокая романтическая душа, вдохновившись моей статьей, доработает предлагаемый в ней функционал до полноценного «Тамакотчи», в качестве домашнего задания. Главное, чтобы такая душа не забыла после поделиться своими результатами с сообществом в комментариях. В идеальном варианте можно было бы создать проект на гитхабе с общим доступом, чтобы каждый желающий смог привнести свой личный вклад в развитие идей трансгуманизма. А теперь — в сторону шутки и фантазии, закатываем рукава. Начинать мы будем с самого нуля, а я для пущего 7D и эффекта присутствия я буду проделывать каждый шаг вместе с вами. TDD прилагается: с неоттестированным робокотом уж точно будет не до шуток.
Информация в статье предназначена для тех, кто уже хотя бы немного заком со Scala, и имеет хотя бы поверхностное представление о модели акторов. Для тех же, кто хотел бы познакомиться, но не знает, с чего начать, в качестве бонуса я написал небольшую стартовую инструкцию и скрыл ее под спойлер, чтоб остальным не мешала. В ней говорится о том, как без лишних усилий создать чистый проект на Scala со всеми нужными библиотеками.
Читать полностью »
При разработке нам понадобился простой конечный автомат, желательно уже реализованный. Из списка реализаций, который предложил гугл, выбрали этот, за простоту и компактность. Используем у себя, в целом FSM неплох. Далее под катом перевод оригинальной статьи автора из Греции Tasos Giannakopoulos. Я не переводчик, поэтому я старался передать смысл, иногда объясняя суть своими словами, за что извиняюсь перед перфекционистами.
Представьте на минутку обычного программиста. Допустим, его зовут Вася и ему нужно сделать анимированную менюшку на сайт/десктоп приложение/мобильный апп. Знаете, которые выезжают сверху вниз, как меню у окна Windows или меню с яблочком у OS X. Вот такое.
Начинает он с одного выпадающего окошка, тестирует анимацию, выставляет ease out 100% и наслаждается полученным результатом. Но вскоре он понимает, что для того, чтобы управлять менюшкой, хорошо бы знать закрыто оно сейчас или нет. Мы-то с вами тут программисты опытные, все понимаем, что нужно добавить флаг. Не вопрос, флаг есть.
var opened = false;Вроде, работает. Но, если быстро кликать по кнопке, меню начинает моргать, открываясь и закрываясь не успев доанимироваться в конечное состояние. Вася добавляет флаг animating. Теперь код у нас такой:
var opened = false;
var animating = false;
function onClick(event) {
if (animating) return;
if (opened) close();
else open();
}
Через какое-то время Васе говорят, что меню может быть полностью выключено и неактивно. Не вопрос! Мы-то с вами тут программисты опытные, все понимаем, что… нужно добавить ЕЩЕ ОДИН ФЛАГ! И, всего-то через пару дней разработки, код меню уже пестрит двустрочными IF-ами типа вот такого:
if (enabled && opened && !animating && !selected && finishedTransition && !endOfTheWorld && ...) { ... }Вася начинает задаваться вопросами: как вообще может быть, что animating == true и enabled == false; почему у него время от времени все глючит; как тут вообще поймешь в каком состоянии находится меню. Ага! Состояния... О них дальше и пойдет речь.
Знакомьтесь, это Вася.
Хорошо, когда твои подчиненные никогда не болеют, не умирают, всегда присутствуют на работе и выполняют твои распоряжения без предварительных приготовлений: «Вызвали — встань». Таковы, например, веб-сервисы, соблюдающие модель REST (которая, если отбросить специальную HTTP-терминологию, сводится к тому, что интерфейс сервиса фактически является интерфейсом контейнера данных).
В реальной жизни у подчиненных бывают насморк и декретный отпуск, у сетевых соединений — таймауты, у авиарейсов — погода, а у автомобильных двигателей в мороз — необходимое время холостого прогрева.
Асинхронный конечный автомат — это удобная абстракция верхнего уровня для управления сущностями с богатым и не всегда предсказуемым внутренним миром. Такой сущностью может быть аппаратное устройство, сессия сетевого протокола или просто параллельно запущенный процесс, код которого вы не контролируете.
Описываемая ниже архитектура асинхронного конечного автомата решает ряд стандартных проблем, возникающих при «лобовой» интеграции подсистем с учетом их внутреннего состояния. Самая заметная из таких проблем — это недостаточная разнесенность (я бы даже сказал — недостаточная «гальваническая развязка») сущностей сигнала и перехода между состояниями, из-за чего автомат становится неустойчивым к DoS-атакам. Есть и другие, менее очевидные — например, «недостаточно атомарная» замена узла подсистемы или используемого ей ресурса.
Модель конечного автомата включает следующие базовые сущности:
