Привет, Хабр!

По моим наблюдениям, всех людей можно разделить на три категории: счастливчиков с нормальным телосложением, худых, кто не знает как бы поправиться, и полных, кто не знает как бы похудеть. Мне угораздило попасть в третью категорию, и всю взрослую жизнь мой вес колебался в районе 95кг при росте 1.74м, что соответствует BMI=31.4 или ожирению. И хотя в принципе, это ничуть не мешало, но все же лишний вес накладывает определенные ограничения, как в перспективе состояния здоровья, так и в плане личной жизни. Наконец, в один прекрасный день я решил что «пора», и занялся этим вопросом более серьезно.



Думаю, среди IT-шников, работающих в офисе, немало людей с похожими проблемами, и надеюсь, мой опыт будет им полезен.

Привет! Сегодня мы познакомимся с такой штукой как M5 UI. Благодаря M5 UI Вы можете с помощью пары строк кода подключать всевозможные поля, кнопки, ползунки и переключатели, создавать условные слоя. Несмотря на то, что процесс подключения элементов UI очень прост, Вы также можете воспользоваться наглядным инструментом M5 UI Designer for Arduino IDE.

Рисунок 1

«Какой толк в книге, — подумала Алиса, — если в ней нет ни картинок, ни разговоров?»
Льюис Кэрролл, «Алиса в Стране чудес»

Всем привет!

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

К визуализации данных в СМИ, интернет-ресурсах, печатных изданиях часто привлекают дизайнеров и художников. Но нередко инфографика нужна в более «скромных» ситуациях — например, для представления информации в отчетах организации или отдела, подведения итогов этапа или проекта, анализа результатов определенного периода. Для этих целей привлечение дизайнеров может быть слишком затратно по финансам и времени. 

Я работаю преподавателем и руководителем группы разработки учебных материалов в учебном центре «Сетевая Академия ЛАНИТ» более 10 лет и, когда провожу разработанный нами курс по инфографике, то обычно начинаю так: «Наш курс не для дизайнеров, а для тех сотрудников, которым нужно научиться правильно применять доступные средства для быстрого и качественного представления данных».

И в статье будет не про космические корабли, бороздящие просторы вселенной, а про кастрюли…

Источник

Доброго здравия всем!

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

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

Данная статья не претендует на истину, а лишь показывает подход к реализации некоторых задач, в данном случае реализацию Uart драйвера на С++.

Зачем и для чего

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

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

(КДПВ – см. аннотацию к диаграмме в конце)

Приветствую. Так получилось, что уже три года подряд в качестве подарка на Новый год определенным людям я делаю игру. В 2018-ом году это был платформер с элементами головоломки, о котором я писал на хабре. В 2019-ом — сетевая RTS для двух игроков, о которой я ничего не писал. И наконец, в 2020-ом — визуальная новелла, о которой далее и пойдет речь, созданная в условиях сильно ограниченного времени.

В этой статье:

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

Интересно? Тогда добро пожаловать под кат.

Осторожно: тут много текста и ~3.5мб изображений

1. Введение

В [1] был дан ответ на вопрос, что считать автоматным программированием (АП), но не была подробно описана модель конечного автомата (КА) в качестве модели управления автоматных программ. При этом понятно, что чистый абстрактный автомат на эту роль не годится, т.к. ограничен числом каналов. Но и структурная модель автомата, как и соответствующая ей теория структурных автоматов, не позволяют пока дать ответ по выбору модели автомата.

Проблема начинается с того, что среди множества работ по теории конечных автоматов (ТКА) мало дающих определение модели структурного конечного автомата (СКА). Правда, можно понять, что структурный автомат — это [структурная] схема из элементарных автоматов (функциональных элементов), реализующая модель абстрактного автомата [2]. Напомним, что в соответствии с теорией все начинается с создания модели устройства в форме абстрактного автомата, а затем ставится задача синтеза цифровой схемы, которая его реализует [3].

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

Правда, тут же закономерен вопрос — зачем еще один и довольно необычный «автоматный инструментарий»? На этот вопрос мы и попробуем ответить, дав определение модели [вложенного] автоматного управления, рассмотрев также ее преимущества по сравнению с обычной моделью программирования.

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

Сразу уточняем: это не 15 самых лучших библиотек, а 15 из лучших. Разумеется, есть и другие, не менее замечательные, о которых я не упомянул или не знаю.
И, нет, это не рейтинг — список маркированный, а не нумерованный.

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

some_stream.set (Direction::to_periph)    SOME_STREAM->CR |= DMA_SxCR_DIR_0
   .inc_memory()                                          |  DMA_SxCR_MINC_Msk
   .size_memory (DataSize::word16)                        |  DMA_SxCR_MSIZE_0
   .size_periph (DataSize::word16)                        |  DMA_SxCR_PSIZE_0
   .enable_transfer_complete_interrupt();                 |  DMA_SxCR_TCIE_Msk;

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

Описание концепций PPU

Super PPU

Super "Picture Processing Unit" — чип видеоконтроллера, обрабатывающий тайловую графику, плоскости скроллинга и спрайты SNES. По функциям схож с PPU консоли NES.

VRAM

VideoRAM — ОЗУ, используемое Super PPU. Содержит тайлы. В каждом режиме экрана используется собственный размер тайлов. Обычно это 8x8 или 16x16 пикселей на тайл. VRAM имеет объём 64 КБ.

OAM

«Object Attribute Memory» — содержит данные определений спрайтов. Может содержать данные не более чем 128 спрайтов. Схожа с OAM в NES, но более совершенная.

Привет, Хабр!

На днях возникла типовая задача — помочь знакомой превратить гору фотографий в упорядоченную иерархию. Всё бы ничего, но гор фотографий не одна, а две — на Mac и на ноуте под Win10. В поисках решения, наткнулся на несколько сценариев для linux, а вот чего-то такого кроссплатформенного найти не удалось. Будем писать сами — прошу под кат.

Сегодня коротко расскажу о том, как я реализовывал семафор на основании объекта синхронизации «Событие».

Сначала пройдусь по определениям.

1. Что такое синхронизация и зачем она нужна?

Очевидно, что набор действий мы можем выполнять несколькими способами. Самые простые — последовательно и параллельно. Параллельности выполнения определенных действий можно достигнуть за счет запуска различных потоков (threads). Идея простая: назначаем каждому потоку какое-то элементарное (или не очень) действие и запускаем их в определенном порядке. Вообще говоря, запустить мы их можем и все одновременно — выигрыш по времени мы, конечно, получим. Это понятно: одно дело вывести 10 000 слов одно за другим, а другое дело одновременно выводить, например, 100 слов. 100-кратный выигрыш по времени (плюс-минус, без учета задержек и проч.). Но исходная задача может предполагать строгую последовательность действий.

Например:

• Открыть файл
• Записать текст в файл
• Закрыть файл

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

• Сгенерировать три последовательности случайных чисел
• Последовательно вывести их на экран

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

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

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

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

Понятно, что от ошибок не застрахован никто, особенно не-носители языка. Но если мы учим язык, чтобы использовать его, например, в работе, то очень важно научиться писать с минимумом ошибок. Иначе текст может быть неправильно истолкован, что приведет к реальным трудностям.

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

После нескольких лет плодотворной работы, было принято решение вынести на суд общественности наш первый продукт для управления климатом в умном доме — умный термостат для управления теплым полом.

1. Форма кредитной карты

Клёвая форма кредитной карты с гладкими и приятными микровзаимодействиями. Включает форматирование чисел, проверку и автоматическое определение типа карты. Она построена на Vue.js, а также полностью адаптивная. (Посмотреть можно здесь.)



credit-card-form

Чему научитесь:

• Обрабатывать и валидировать формы
• Обрабатывать события (например, при изменении полей)
• Разберетесь как отображать и размещать элементы на странице, особенно данные кредитной карты, которая поверх формы

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

На Хабре достаточно давно не освещался проект FLProg. Это связанно с отсутствием времени на написание статей, да и моими собственными личными проблемами. Но проект не умер, он живёт и развивается. В среднем раз в месяц выходит очередная версия программы. Со времени последней публикации была полностью переделана отрисовка схемы (благодаря этому были устранены фризы при отрисовке), появилась система Cross Reference для проекта, и система анализа проекта на ошибки. Непосредственно сам код программы, был перенесён на более свежую версию языка программирования. Благодаря этому в положительную (с моей точки зрения конечно, ну и пользователи меня поддерживают) сторону изменился интерфейс программы. Добавились многие интересные блоки. Реализовано масштабирование схемы и поиск блоков.

Введение

(Ссылки на исходный код и проект KiCAD приведены в конце статьи.)

Хотя мы родились в 8-битную эпоху, нашим первым компьютером был Amiga 500. Это великолепная 16-битная машина, обладавшая потрясающими графикой и звуком, благодаря чему она отлично подходила для игр. Очень популярным игровым жанром на этом компьютере стали платформеры. Многие из них были очень цветастыми и обладали очень плавным параллаксным скроллингом. Это стало возможно благодаря талантливым программистам, гениально использовавшим сопроцессоры Amiga для увеличения количества экранных цветов. Взгляните, например на LionHeart!


Lionheart на Amiga. Это статичное изображение не передаёт всю красоту графики.

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

Мы всегда любили платформенные игры, а сегодня всего за несколько долларов можно купить Raspberry Zero, установить Linux и «довольно легко» написать красочный платформер.

Но это задача не по нам — мы не хотим палить из пушки по воробьям!

Мы хотим использовать микроконтроллеры с ограниченной памятью, а не мощную систему на чипе со встроенным GPU! Другими словами, мы хотим трудностей!