Как с помощью трех открытых проектов написать диплом

Не секрет, что в у нас в проекте используют обучают студентов. Точнее, студенты на базе проекта осваивают практические аспекты системного программирования: пишут дипломы, курсовые, занимаются исследовательской деятельностью и так далее. Вот об одном дипломе, успешно защищённом прошлым летом, и пойдет речь в данной статье. Автором является Александра Бутрова AleksandraButrova, тема “Разработка графической подсистемы для встроенных операционных систем”. При написании диплома были использованы три открытых проекта: Embox, Nuklear и stb. Последний использовался только для загрузки картинок, а вот Nuklear являлся, по сути, виновником торжества. Можно сказать, что работа свелась к интеграции Nuklear и Embox. Первый предоставлял лёгкую графическую библиотеку, а Embox отвечал за встроенные системы.
Читать дальше →

PVS-Studio 2018: CWE, Java, RPG, macOS, Keil, IAR, MISRA

PVS-Studio 2018: CWE, Java, RPG, macOS, Keil, IAR, MISRA

Приближается 2018 год и пора подумать о новых направлениях развития нашего статического анализатора PVS-Studio. Сейчас наибольший интерес для нас представляет поддержка языка Java. Дополнительно мы рассматриваем возможность поддержки языка IBM RPG. Не менее интересно развить анализ C, C++ C# кода в направлении выявления потенциальных уязвимостей. Ещё нам хочется поддержать анализ C и C++ кода на платформе macOS, и, наконец, доделать поддержку компиляторов от компаний Keil и IAR. Никуда мы не денемся и от поддержки стандарта MISRA. Перечислено много, и на всё одного 2018 года нам не хватит. Поэтому давайте вместе с нами пообсуждаем наши планы и выберем самые приоритетные направления.
Читать дальше →

[Из песочницы] Настройка Sublime Text 3, SW4 и STM32CubeMX для разработки STM32 под Linux

Подобных статей достаточно много на просторах интернета, но хотелось бы написать актуальную вариацию. Лично я долгое время мучался в связке: Ubuntu — основная система, разработка под STM32 в виртуальной машине Windows 7. Но однажды меня это очень утомило и я таки решил потратить несколько дней на поиск решения и вылизывание полноценной среды под Linux Ubuntu. Забегу вперёд и скажу, что идеала я так и не добился, не удалось сделать realtime debug, как в Keil. В остальном всё очень пристойно.


Внимание, очень много текста и картинок!

Читать дальше →

[Из песочницы] Быстрый старт с NRF51822

1. Вступление

Добрый день. В сети гуляет огромное количество уроков программирования под разные простенькие (и не очень) платформы. С каждым годом однотипные туториалы разной степени углубленности по одному и тому же микроконтроллеру штампуются десятками. И это прекрасно, так как обилие статей ведет к снижению порога вхождения в тематику и позволяет уже созревшим программистам не тратить время на поиск прочитанного вдоль и поперек даташита, а просто воспользоваться уже рабочим куском кода инициализации периферии и перейти к проблемам посерьезнее. Однако есть нюанс — шаг вправо, шаг влево от стандартной подборки STM32/8, AVR и иже с ними или углубление в более сложные интерфейсы тех же самых STM32/8, и тишина. Лишь изредка на далеком-далеком форуме кто-то задает вопрос, который в итоге остается без ответа… К чему я, собственно, веду. Не так давно возникла необходимость использования в проекте чипа nRF51822 компании Nordic Semiconductor с популярной ныне тематикой Bluetooth low energy (далее — BLE) на борту. image Чип оказался настолько популярным на информационную составляющую, что Google с горем пополам выдал 2-3 ссылки с описанием самого BLE стека и пару абстрактных статей касательно реализации стека у чипов Nordic и Texas instruments (CC2640). Матерые программисты скажут: «Берите примеры от компании Nordic (а их там к слову с избытком) и разбирайтесь». И это верный подход, если бы не одно но, касающееся, по большей части, начинающих программистов и желающих получить быстрый результат: обилие структур, многоуровневые библиотеки — все это прекрасно и логично, но избыточно для быстрого старта или маленького проекта. Все это увеличивает порог вхождения до неоправданных высот....Далее...

Автоматная разработка, практикум. Пример «Дисплей». Часть 1

Тесты в предыдущей статье убедительно показали высокую эффективность «автоматной» реализации примера «Дисплей» по сравнению с условно названной «неавтоматной» версией. Вкратце итог: обе реализации автоматные, но разница в эффективности многократна и глубинная причина видится в том, что вариант А1 («автоматный») изначально проектировался как автомат, а вариант А2 («неавтоматный») нет. Не столько автоматная реализация, сколько автоматное проектирование является основой высокой эффективности. Для простых алгоритмов автоматные реализации получаются сами собой. Есть смысл говорить о том, что автоматное программирование, это не столько реализация программы в виде конечного автомата, сколько автоматное проектирование, фундаментом которого является конструктивная декомпозиция. Я несколько раз касался темы автоматного проектирования и конструктивной декомпозиции, но чтобы раскрыть эту тему нужны практические примеры. В этой и следующих нескольких статьях я проведу практикум, покажу процесс автоматного проектирования, пытаясь по возможности приводить ход рассуждений присущих автоматному проектированию.
Читать дальше →

fiber — легковесные процессы для Arduino


А давайте притащим мир большого программирования в Arduino!


Любая программа, а тем более программа близкая к аппаратуре (а какие еще на arduino бывают?) при рассмотрении представляет собой множество параллельно работающих ветвей.


При этом в реальной жизни обработка большинства вещей в реальном времени не требуется. Достаточно иметь нечто похожее на реальное время.


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


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


Если рассмотреть структуру произвольного сложного программно-аппаратного проекта в том числе на Arduino, то увидим, что задач требующих "реального" (с жесткими требованиями) реалтайма — меньшинство, а большинству задач достаточно условного реалтайма.


Программирование реального реалтайма — это как правило прерывания и аппаратные хитрости. В этой статье поговорим о программировании реалтайма условного.

Читать дальше →

Автоматное программирование. Часть 3. Диаграмма состояний и переходов. Продолжение

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

Такое железное и такое безымянное

Привет, Хабр! Настала осень, птицы потянулись на юг, нормальные люди — на диван, а мы, «железное безымянное направление» проектной исследовательской школы GoTo, сердито курлыча и ощетинясь паяльниками, зажатыми в стальных руках-крыльях, сбиваемся в бронированный клин, чтобы лететь 28 октября в Питер на осеннюю школу в ИТМО.

image

Почему железное, почему безымянное, и что будет на школе — обо всем по порядку.
Читать дальше →

Обзор одной российской RTOS, часть 6. Средства синхронизации потоков

К сожалению, при разработке реальных многопоточных приложений, невозможно просто написать код всех задач, подключить их к планировщику и просто запустить на исполнение. Начнём с банальности — если задач много, то они начнут впустую тратить процессорное время на исполнение в холостых циклах. Как уже отмечалось в предыдущих публикациях, все задачи, которым в настоящий момент нечего делать (не пришли данные от аппаратуры или по прочим организационным причинам) должны быть заблокированы. На исполнение следует ставить только те задачи, которым сейчас есть что делать, так как процессорных тактов микроконтроллерам вечно не хватает. Далее, задачи могут конфликтовать друг с другом за те или иные ресурсы (в частности, за оборудование). При рассмотрении типов многозадачности, мы уже рассматривали типовые случаи конфликтов за порт SPI (частично решаемое переходом на кооперативную многозадачность, но на неё перейти можно не всегда). И самый страшный случай — зависимость задач. Часто результат работы одной задачи используется в другой. Из очевидных примеров, можно упомянуть следующие: бесполезно пересчитывать данные для выхода PID регулятора температуры, пока не получено и не усреднено достаточно данных с термодатчика, нет смысла менять воздействие на скорость двигателя, пока не получены сведения о текущем периоде его вращения, незачем обрабатывать строку символов с терминала, пока не получено терминирующего символа (признака конца строки). А кроме очевидных, есть масса неочевидных случаев зависимостей и порождаемых ими гонок. Иногда у начинающего разработчика больше времени уходит именно на борьбу с гонками, чем непосредственно на реализацию алгоритмов работы программы. Во всех этих случаях, на помощь разработчику приходят синхронизирующие объекты. Давайте в текущей публикации рассмотрим, какие синхронизирующие объекты и функции имеются в ОСРВ МАКС. ...Далее...

STM32 без HAL и SPL

В свое время, более 5 лет, при поиске информации о 32-разрядных микроконтроллерах, обратил внимание, что практически все примеры для STM32 подразумевали использование SPL (Standard Peripherals Library). Цитата из Википедии:
STM32F10x Standard Peripherals Library (сокр. STM32F10x SPL) — библиотека, созданная компанией STMicroelectronics на языке Си для своих микроконтроллеров семейства STM32F10x. Содержит функции, структуры и макросы для облегчения работы с периферией микроконтроллера."

В настоящее время, для снижения порога вхождения и ускорения разработки предлагается использовать STM32CUBE. Цитата с сайта STM:
STM32Cube embedded software libraries, including:
The HAL hardware abstraction layer, enabling portability between different STM32 devices via standardized API calls
The Low-Layer (LL) APIs, a light-weight, optimized, expert oriented set of APIs designed for both performance and runtime efficiency
A collection of Middleware components, like RTOS, USB library, file system, TCP/IP stack, Touch sensing library or Graphic Library (depending on the MCU series)

На мой взгляд, для большинства проектов не нужны внешние библиотеки и проще использовать обращение к регистрам микроконтроллера, используя стандартную документацию.
Читать дальше →
  • Новее
  • 1


Последние посты