Привет, меня зовут Иван Ларионов. В 2011 году мы вместе с братом основали компанию «Третий пин». Я хочу поделиться своей историей эволюции из инженера-фрилансера в руководителя компании, занимающейся контрактной разработкой электроники. Как и почему удалось не обанкротиться, не закрыться и не выгореть, а нарастить мощности и сохранить кураж.

Не каждый начинающий атлет или даже атлет с опытом могут съедать белка в количестве 2 гр на 1 кг веса тела. Это стандартная рекомендация, которую все мы получаем, приходя тренироваться в фитнес зал. Но сколько в ней правды? У можно ли есть меньше без ущерба результату? Можно ли есть больше, получая дополнительные выгоды? Я решил разобрать эту тему подробно, со всех сторон, затрагивая самые радикальные точки зрения.

В прошлом году мы в АРПЭ проводили исследование рынка контрактной разработки в России. Вот как выглядела оценка рынка на тот момент: рынок маленький, 1,3 млрд ₽, но растёт. Через три года такими темпами объём рынка должен удвоиться. Ситуация резко изменилась, как это повлияет на рынок контрактной разработки?

История о моем опыте использования операционной системы реального времени (ОСРВ) Zephyr для устройства на базе микроконтроллера STM32F7-Discovery.

В статье:

• Что такое Zephyr и при чем тут Linux?
• Запуск проекта на STM32. Интересные моменты по работе с драйверами.
• Фишки этой ОС. Что понравилось, а что нет.

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

Технологичное проектирование

В данной статье я расскажу о следующих моментах:

1. Настройка OpenOCD для работы с FreeRTOS.
2. Не забываем включать хуки.
3. Статическое или динамическое выделение памяти?
4. Сказ, о параметре configMINIMAL_STACK_SIZE.
5. Мониторинг использования ресурсов.

Создание электрических схем и трассировка печатных плат становятся всё более простыми делами. Производители компонентов интегрируют в изделия всё больше функционала, выкладывают готовые модели, условные графические обозначения (УГО) и целые схемы, сайты автоматически генерируют источники питания, фильтры и многое другое. Тем не менее, даже при проектировании простых печатных узлов обнаруживаются ошибки, часто — глупые и очевидные.

Предисловие

На днях мне нужно было реализовать расшифровку базы данных KeePass. Меня поразило то, что нет ни одного документа и ни одной статьи с исчерпывающей информацией об алгоритме расшифровки файлов .kdb и .kdbx с учетом всех нюансов. Это и побудило меня написать данную статью.

На данный момент существует 2 версии KeePass:

• KeePass 1.x (генерирует файлы .kdb);
• KeePass 2.x (генерирует файлы .kdbx).

Структура файла с базой данных KeePass (.kdb, .kdbx) состоит из 3 частей:

• Подпись (не зашифрована);
• Заголовок (не зашифрован);
• Данные (зашифрованы).

Далее я подробно расскажу о том, как дешифровать базу данных KeePass 1.x и KeePass 2.x.

Типичная схема организации выступления

• Принятие решения о выступлении на конференции — примерно за 3 месяца до конференции.
• Подача темы выступления и краткой аннотации (включая формат и длительность), а также резюме — примерно за 2 месяца до мероприятия.
• Предоставление готовой презентации, расширенной аннотации, резюме и фотографии — за месяц и ближе к мероприятию.
• Публикация точной программы — хорошо, если за неделю до мероприятия.
• Собственно выступление.
• Кулуарное общение и организация контактов на мероприятии.
• Фиксация результатов выступления — в течение 3-х дней после мероприятия.