Что такое скелет программы

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

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

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

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

Структура же программы при этом следующая:

• Макросы и макроопредения
• Сегмент ОЗУ
• Точка входа — ORG 0000
• Таблица векторов — и вектора, ведущие в секцию обработчиков прерываний
• Обработчики прерываний — тела обработчиков, возврат отсюда только по RETI
• Инициализация памяти — а вот уже отсюда начинается активная часть программы
• Инициализация стека
• Инициализация внутренней периферии — программирование и запуск в работу всяких таймеров, интерфейсов, выставление портов ввода-вывода в нужные уровни. Разрешение прерываний.
• Инициализация внешней периферии — инициализация дисплеев, внешней памяти, разных аппаратных примочек, что подключены к микроконтроллеру извне.
• Запуск фоновых процессов — процессы работающие непрерывно, вне зависимости от условий. Такие как сканирование клавиатуры, обновление экрана и так далее.
• Главный цикл — тут уже идет вся управляющая логика программы.
• Сегмент ЕЕПРОМ

Костная система — Анатомия человека | Kenhub

Начинается все с макросов, их пока не много, если что по ходу добавим.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

В оперативке пока ничего не размечаем. Нечего.

1 2 3
; RAM =================================================== .DSEG ; END RAM ===============================================

С точкой входа и таблицей векторов все понятно, следуя нашему давнему шаблону, берем его оттуда:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
; FLASH ====================================================== .CSEG .ORG $000 ; (RESET) RJMP Reset .ORG $002 RETI ; (INT0) External Interrupt Request 0 .ORG $004 RETI ; (INT1) External Interrupt Request 1 .ORG $006 RETI ; (TIMER2 COMP) Timer/Counter2 Compare Match .ORG $008 RETI ; (TIMER2 OVF) Timer/Counter2 Overflow .ORG $00A RETI ; (TIMER1 CAPT) Timer/Counter1 Capture Event .ORG $00C RETI ; (TIMER1 COMPA) Timer/Counter1 Compare Match A .ORG $00E RETI ; (TIMER1 COMPB) Timer/Counter1 Compare Match B .ORG $010 RETI ; (TIMER1 OVF) Timer/Counter1 Overflow .ORG $012 RETI ; (TIMER0 OVF) Timer/Counter0 Overflow .ORG $014 RETI ; (SPI,STC) Serial Transfer Complete .ORG $016 RETI ; (USART,RXC) USART, Rx Complete .ORG $018 RETI ; (USART,UDRE) USART Data Register Empty .ORG $01A RETI ; (USART,TXC) USART, Tx Complete .ORG $01C RETI ; (ADC) ADC Conversion Complete .ORG $01E RETI ; (EE_RDY) EEPROM Ready .ORG $020 RETI ; (ANA_COMP) Analog Comparator .ORG $022 RETI ; (TWI) 2-wire Serial Interface .ORG $024 RETI ; (INT2) External Interrupt Request 2 .ORG $026 RETI ; (TIMER0 COMP) Timer/Counter0 Compare Match .ORG $028 RETI ; (SPM_RDY) Store Program Memory Ready .ORG INT_VECTORS_SIZE ; Конец таблицы прерываний

; FLASH ====================================================== .CSEG .ORG $000 ; (RESET) RJMP Reset .ORG $002 RETI ; (INT0) External Interrupt Request 0 .ORG $004 RETI ; (INT1) External Interrupt Request 1 .ORG $006 RETI ; (TIMER2 COMP) Timer/Counter2 Compare Match .ORG $008 RETI ; (TIMER2 OVF) Timer/Counter2 Overflow .ORG $00A RETI ; (TIMER1 CAPT) Timer/Counter1 Capture Event .ORG $00C RETI ; (TIMER1 COMPA) Timer/Counter1 Compare Match A .ORG $00E RETI ; (TIMER1 COMPB) Timer/Counter1 Compare Match B .ORG $010 RETI ; (TIMER1 OVF) Timer/Counter1 Overflow .ORG $012 RETI ; (TIMER0 OVF) Timer/Counter0 Overflow .ORG $014 RETI ; (SPI,STC) Serial Transfer Complete .ORG $016 RETI ; (USART,RXC) USART, Rx Complete .ORG $018 RETI ; (USART,UDRE) USART Data Register Empty .ORG $01A RETI ; (USART,TXC) USART, Tx Complete .ORG $01C RETI ; (ADC) ADC Conversion Complete .ORG $01E RETI ; (EE_RDY) EEPROM Ready .ORG $020 RETI ; (ANA_COMP) Analog Comparator .ORG $022 RETI ; (TWI) 2-wire Serial Interface .ORG $024 RETI ; (INT2) External Interrupt Request 2 .ORG $026 RETI ; (TIMER0 COMP) Timer/Counter0 Compare Match .ORG $028 RETI ; (SPM_RDY) Store Program Memory Ready .ORG INT_VECTORS_SIZE ; Конец таблицы прерываний

Как устроен человек? Как устроен мой скелет. Зачем мне кости?

Обработчики пока тоже пусты, но потом добавим

; Interrupts ============================================== ; End Interrupts ==========================================

Инициализация ядра. Память, стек, регистры:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
Reset: LDI R16,Low(RAMEND) ; Инициализация стека OUT SPL,R16 ; Обязательно. LDI R16,High(RAMEND) OUT SPH,R16 ; Start coreinit.inc RAM_Flush: LDI ZL,Low(SRAM_START) ; Адрес начала ОЗУ в индекс LDI ZH,High(SRAM_START) CLR R16 ; Очищаем R16 Flush: ST Z+,R16 ; Сохраняем 0 в ячейку памяти CPI ZH,High(RAMEND) ; Достигли конца оперативки? BRNE Flush ; Нет? Крутимся дальше!

CPI ZL,Low(RAMEND) ; А младший байт достиг конца? BRNE Flush CLR ZL ; Очищаем индекс CLR ZH CLR R0 CLR R1 CLR R2 CLR R3 CLR R4 CLR R5 CLR R6 CLR R7 CLR R8 CLR R9 CLR R10 CLR R11 CLR R12 CLR R13 CLR R14 CLR R15 CLR R16 CLR R17 CLR R18 CLR R19 CLR R20 CLR R21 CLR R22 CLR R23 CLR R24 CLR R25 CLR R26 CLR R27 CLR R28 CLR R29 ; End coreinit.inc

Reset: LDI R16,Low(RAMEND) ; Инициализация стека OUT SPL,R16 ; Обязательно.

LDI R16,High(RAMEND) OUT SPH,R16 ; Start coreinit.inc RAM_Flush: LDI ZL,Low(SRAM_START) ; Адрес начала ОЗУ в индекс LDI ZH,High(SRAM_START) CLR R16 ; Очищаем R16 Flush: ST Z+,R16 ; Сохраняем 0 в ячейку памяти CPI ZH,High(RAMEND) ; Достигли конца оперативки? BRNE Flush ; Нет? Крутимся дальше! CPI ZL,Low(RAMEND) ; А младший байт достиг конца? BRNE Flush CLR ZL ; Очищаем индекс CLR ZH CLR R0 CLR R1 CLR R2 CLR R3 CLR R4 CLR R5 CLR R6 CLR R7 CLR R8 CLR R9 CLR R10 CLR R11 CLR R12 CLR R13 CLR R14 CLR R15 CLR R16 CLR R17 CLR R18 CLR R19 CLR R20 CLR R21 CLR R22 CLR R23 CLR R24 CLR R25 CLR R26 CLR R27 CLR R28 CLR R29 ; End coreinit.inc

Всю эту портянку можно и нужно спрятать в inc файл и больше не трогать.

Секции внешней и внутренней инициализации переферии пока пусты, но ненадолго. Равно как и запуск фоновых программ. Потом я просто буду говорить, что мол добавьте эту ботву в секцию Internal Hardware Init и все 🙂

1 2 3 4 5 6 7 8 9 10 11
; Internal Hardware Init ====================================== ; End Internal Hardware Init =================================== ; External Hardware Init ====================================== ; End Internal Hardware Init =================================== ; Run ========================================================== ; End Run ======================================================

А теперь, собственно, сам главный цикл.

1 2 3 4 5
; Main ========================================================= Main: JMP Main ; End Main =====================================================

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

Разделим их просто логически.

1 2 3
; Procedure ==================================================== ; End Procedure ================================================

Спасибо. Вы потрясающие! Всего за месяц мы собрали нужную сумму в 500000 на хоккейную коробку для детского дома Аистенок.

Из которых 125000+ было от вас, читателей EasyElectronics. Были даже переводы на 25000+ и просто поток платежей на 251 рубль. Это невероятно круто. Сейчас идет заключение договора и подготовка к строительству!

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

67 thoughts on “AVR. Учебный курс. Скелет программы”

Mazayac :

«Суть в том, чтобы в автоматическом режиме, каждые несколько миллисекунд вызывать прерывание, в котором происходит подсчет импульсов от одометров» Очень сложный, и неудачный подход.
Для подсчета импульсов с энкодеров в разы проще и эффективнее использовать прерывание по изменению состояния входа.
Пришел импульс — сгенерировалось прерывание, посчитали его быстренько и работаем спокойно дальше. Итого: 1 импульс на энкодере — одно прерывние, а не постоянная беготня с проверкой порта и сравнением с предыдущим состоянием 🙂

DI HALT :

Да можно и так. Я подумал об этом в последний момент, но у меня на инты повешан драйвер движка, когда я его туда вешал я даже не думал про энкодеры на редуктор, Точнее у меня на них был собрана макетка, и я решил оставить обратную совместимость и ничего не менять. Так что чистейшая ошибка планирования, когда итоговая конструкция допридумывается походу дела такое сплошь и рядом :))))) Но зато появился кусок извратского кода для изучения. Тоже полезно, заодно показал как логика работает. 🙂

Mazayac :

«на инты повешан драйвер движка»
Пора на Атмегу88 переходить 🙂 У нее все порты (B, C, D) умеют внешние прерывания обслуживать, 24 входа для прерываний — с ума можно сойти.

DI HALT :
Не продают у нас такое. А заказывать больно накладно выходит.
Mazayac :

У нас тоже не продают. Приходится заказывать из Москвы, хорошо еще что удается «прицепляться» к заказам для фирмы и не платить за доставку.

Lomaster :

Не разобрался: прерывание по изменению состояния входа на ATMega8 можно только на 4 и 5 (INT0 и INT1) ноге делать?

Источник: easyelectronics.ru

Лекция 2 Скелет оконной программы Вступление

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

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

Кроме того, программа под ОС должна выполнять ряд стандартных действий, которые позволяют полноценно «включить» ее в состав исполняемого программного обеспечения.

Рассмотрим эти шаги и составные части программ.

Четыре составные части программы под windows

Любое оконное приложение, написанное под Windows должно содержать в себе следующие элементы:

1. Функцию регистрации класса окна.
2. Функцию создания окна.
3. Оконную процедуру.
4. Цикл обработки сообщений.

Источник: studfile.net

MVP и Dagger 2 – скелет Android-приложения – часть 1

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

Так получилось, что я относительно недавно начал программировать под Android – после месяца без проекта в компании, где я работаю, меня определили в команду мобильной разработки в уругвайском офисе Tata Consultancy Services. При беседе с тимлидом команды мне был озвучен стек, с которым мне предстояло сначала ознакомиться, а затем и овладеть. В числе прочего был фреймворк Dagger 2 для DI и MVP в качестве архитектурного паттерна. И Kotlin. Но о нем в другой раз 🙂

Таким образом, я приступил к изучению сначала основы Android SDK, а затем и всего сопутствующего стека. С самим SDK проблем не возникло – исчерпывающей информации по нему в сети более чем достаточно, начиная с официальной документации и заканчивая туториалами (особенно с этим помог проект startandroid), но с Dagger 2 и MVP применительно к Android-разработке возникли некоторые затруднения ввиду довольно куцей документации первого и, на тот момент, недостаточного понимания второго. Дело в том, что до мобильной разработки я делал микросервисы на Java с использованием Spring Boot/MVC и уже имел достаточное представление и о том, что такое Dependency Injection, и о том, что такое MVC. При том, даже само название “Spring MVC” предполагает, что этот паттерн заложен в архитектуру проекта и его использование очевидно. От Dagger 2 я ожидал как такой же как в Spring “магии” и настолько же проработанной документации и туториалов. И обломался 😛

Тем не менее, при достаточном упорстве и усидчивости, нет ничего невозможного, а результатом изысканий стало осуществление моей давней идеи, возникшей еще в те времена, когда об Android-разработке я и не помышлял. Оценить идею вы можете, установив приложение из Google Store

В данной статье я хотел бы представить сухую выжимку результата моих поисков – пошаговое руководство по созданию скелета Android-приложения с использованием MVP и Dagger 2. Итак, начнем.

1.1 Abstracts

Для начала, создадим пакет abstracts в корне проекта, пусть это будет com.caesar84mx.mymvcapp.abstracts. В нем создадим 2 интерфейса: view.BaseView и presenter.BaseMvpPresenter. Следующим образом:

Это базовые архитектурные элементы, которые в дальнейшем будут использоваться в приложении. Далее, открываем BaseView и объявляем в него методы showView() getContext():

interface BaseView < fun showView(view: View, isShown: Boolean) < view.visibility = if (isShown) View.VISIBLE else View.GONE >fun getContext(): Context >

Теперь открываем BaseMvpPresenter и редактируем его следующим образом:

interface BaseMvpPresenter

В пакете view создаем абстрактный класс BaseCompatActivity, наследуем его от AppCompatActivity и имплементируем недавно созданный интерфейс BaseView. Внутри класса объявляем абстрактный метод init(savedInstanceState: Bundle?) и имплементируем метод getContext() из BaseView:

abstract class BaseCompatActivity: AppCompatActivity(), BaseView < override fun onCreate(savedInstanceState: Bundle?, persistentState: PersistableBundle?) < super.onCreate(savedInstanceState, persistentState) init(savedInstanceState) >protected abstract fun init(savedInstanceState: Bundle?) override fun getContext(): Context = this >

От этого класса в дальнейшем мы будем наследовать все активности.

Теперь перейдем к презентеру – создадим класс BasePresenter, имплементирующий интерфейс BaseMvpPresenter и реализуем методы интерфейса следующим образом:

open class BasePresenter : BaseMvpPresenter < protected var view: V? = null private set override var isAttached = view != null override fun attach(view: V) < this.view = view >override fun detach() < this.view = null >>

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

1.2. Компоненты

Для начала, создадим пакет com.caesar84mx.mymvcapp.components, в нем пакет mainscreen, в котором, в свою очередь, пакеты ui и backstage, и перенесем в пакет ui класс MainScreen:

Теперь удалим из класса MainScreen автоматически сгенерированную при создании проекта имплементацию метода onCreate(), а также, наследование от AppCompatActivity и унаследуем его от BaseCompatActivity. Теперь реализуем метод init(), ранее объявленный в базовом классе. Весь код, который мы раньше поместили бы в метод onCreate(), мы поместим в него (как мы помним, метод init() вызывается в методе onCreate() базового класса):

class MainScreen : BaseCompatActivity() < override fun init(savedInstanceState: Bundle?) < setContentView(R.layout.activity_main_screen) >>

Великолепно, элемент view паттерна MVP создан, теперь перейдем в закулисье нашего компонента – пакет backstage. Создадим интерфейс MainScreenContract – так называемый контракт, через который мы и будем реализовывать наш паттерн. В данном интерфейсе создадим 2 подинтерфейса — Presenter и View:

interface MainScreenContract < interface Presenter: BaseMvpPresenterinterface View: BaseView >

Теперь, перейдем к презетнеру и создадим класс MainScreenPresenter:

class MainScreenPresenter : BasePresenter(), MainScreenContract.Presenter

Скелет приложения почти готов, осталось несколько штрихов. В класс MainScreen добавим имплементацию интерфейса MainScreenContract.View, создадим и проинициализируем переменную presenter: MainScreenPresenter, а в методе init() присоединим вид к презентеру следующим образом:

class MainScreen : BaseCompatActivity(), MainScreenContract.View < val presenter: MainScreenPresenter? = MainScreenPresenter() override fun init(savedInstanceState: Bundle?) < setContentView(R.layout.activity_main_screen) presenter?.attach(this) >>

Таким образом, мы создали презентер и добавили в него наш экземпляр view (не путать с android.view.View), который в презентере будет использоваться для манипуляций с видом.

1.3. Заключение первой части

Итак, мы создали базовые абстрактные элементы паттерна MVP, которые, однако, используются не напрямую, в лоб, а через т.н. контракт – базовый элемент каждого компонента приложения, который сочетает в себе как действия элемента view, так и действия элемента presenter. Контракт – достаточно гибкий элемент, состав которого варьирует от компонента к компоненту, ненавязчиво увязывая компоненты в рамках единой архитектуры.

Следует помнить, что в соответствии с концепцией MVP, элемент view должен быть максимально тупым, в нем мы производим только элементарные действия, такие, как, например, показать/спрятать текст, поменять фон или цвет текста, показать/спрятать значок загрузки и т.д. Методы, соответствующие этому элементу, мы определяем в подинтерфейсе View контракта.

В то время, как логикой мы занимаемся в презентере – бизнес-логика, манипуляции данными (CRUD), запуск фоновых задач и т.д. В нем же мы решаем, когда и показать те или иные элементы на экране. В этом отличие от реализованной в спринге концепции MVC, где между бизнес-логикой и видом находится тупой контроллер, который только получает запросы от вида и вызывает сервис, который возвращает данные или выполняет иные действия, определенные бизнес-логикой. Методы, соответствующие презентеру, мы определяем в подинтерфейсе Presenter контракта.

При реализации презентера, манипуляции видом будут производиться через переменную view суперкласса BasePresenter, в то время, как методы, соответствующие view реализуются в классе активности.

Вы спросите, а где здесь Dagger 2 и зачем он нам сдался, не будет ли реализация DI в Android натягиванием совы на глобус? Ответ на второй вопрос – нет, не будет. А почему и зачем он нужен – во второй части моей статьи 😉

Источник: habr.com