никто
Это первая статья из цикла о том, как создать свой собственный ООП язык программирования с использованием LLVM.
В данной статье мы начнем с введения в серию и начнем реализацию с написания лексического и синтаксического анализаторов для подмножества языка, который будет полностью реализован в заключительных частях серии.
Часть 3. Косвенная адресация и управление потоком исполнения →
Как и планировалось, в этой части рассмотрим более подробно особенности программирования с использованием библиотеки NanoRTOS. Те, кто начал чтение с этого поста, могут ознакомиться с общим описанием и возможностями библиотеки в предыдущей статье. В силу ограниченности планируемого объема публикации предполагается, что уважаемый читатель хотя бы в минимальном объеме знаком с программированием на C#, а так же имеет представление об архитектуре и программировании на языке ассемблер для контроллеров AVR серии Mega.
Известно, что семейство микроконтроллеров STM32F4xx, имея на борту достаточно производительные ядра, вполне подходящие для «не мясорубочных» задач ЦОС не имеют полноценного интерфейса ввода данных с простейшей параллельной шины в режиме «pipe-line» (clk-data). «Покурив» «dm00037051.pdf», нашел не специфичный, но на первый взгляд подходящий вариант – интерфейс DCMI (Digital camera interface).
Конечно, использование для нагруженной классической ЦОС (КИХ, БИХ, FFT) микроконтроллеров STM32, не совсем является оптимальным вариантом, но если вдруг так легли карты и все-таки возможностей данного микроконтроллера вполне достаточно, плюс нужно достаточное количество низкоскоростных интерфейсов. Об этом под катом.
Понадобилось при изучении и ремонте компьютеров, которые старше меня, прошивать ПЗУшки. Тесты оперативной памяти и периферии проводить. Нормального программатора у меня на тот момент не было.
Добрый день!
Изучать ООП (объектно-ориентированное программирование) можно двумя способами: или прочитать сотню книжек, в которых дается голая теория об устройстве классов и принципах наследования, полиморфизма, инкапсуляции, но так ничему и не научиться, или перестать беспокоиться и попытаться на практике освоить новые приемы, переработав, к примеру, готовые коды, а лучше с нуля изготовив что-то простое, но красивое.
Во всех книгах, посвященных паскалю, delphi и lazarus (я нашел аж целых две о последнем), очень схожая часть, посвященная ООП. По этим книгам можно много узнать о том, насколько круче ООП устаревшего структурного подхода, но так и не получить достаточных навыков применения этого на практике. Конечно, любой программист, использующий визуальные IDE, уже по умолчанию использует ООП, так как все компоненты и структурные элементы визуального приложения представляют собой объекты, однако свои собственные структуры и абстракции перенести в парадигму ООП бывает очень сложно. Чтобы понять всю прелесть и оценить открывающиеся перспективы, я решил сделать небольшое приложение, которое в конечном итоге превратилось в простенький screensaver. Заодно вспомнил о существовании тригонометрии.
Приложение будет рисовать на экране в случайных местах пятьдесят полярных роз с разными характеристиками: размер, цвет, количество лепестков. Потом их же затирать и рисовать новые, и т.д. Используя принципы структурного программирования, можно, конечно, сделать обычный многомерный массив объемом на 50 и в нем сохранять все уникальные характеристики. Однако стоит вспомнить, что паскаль подразумевает строгую типизацию данных, а, следовательно, массив не может состоять их элементов с разными типами. Можно сделать массив из записей (record), но чего уж мелочиться, от записи до класса — один шаг. Вот его мы и сделаем.
