Конструювання програмного забезпечення для вбудованих систем з використанням типових шаблонів



Стаття | Article    

Download

У статті розглянуті особливості побудови архітектури і конструювання програмного забезпечення,призначеного для вбудованих систем на основі малопотужних мікроконтролерів. Приведені результати, що відображають вплив на потрібну оперативну пам'ять і пам'ять програм архітектури програмного забезпечення. Розглянуті архітектури програми у вигляді нескінченного циклу, модіфікованого кінцевого автомату і класичного кінцевого автомату. Надані рекомендації конструювання програмного забезпечення для малопотужних мікроконтролерів і напрямки подальших досліджень.

Ключові слова: малопотужні мікрoконтролери, програмне забезпечення, кінцевий автомат

Design software for embedded systems using standard templates

The article describes the features of the architecture and software designed for embedded systems basedon low-power microcontrollers. The result is reflecting of the depending RAM, program memory and software architecture. The architecture of infinite loop and finite-state machine are described and studied in Article. Recommendations design software for low-power microcontrollers and directions for further research.

Keywords: Low-power mikrkontrolery, Software, finite-state machine

Pavlo Katin

lecturer, Department of Automation and Control in Technical Systems of Facultyof Informatics and Computing Technique of National Technical University ofUkraine “Kiev Polytechnic Institute”

Ukraine Kiev

У статті будуть розглянуті особливості побудови архітектури програм для 8, 16 розрядних мікроконтролерів, призначених для вбудованих систем. Далі будемо називати ці мікроконтролери малопотужними. На сьогоднішній день малопотужні мікроконтролери (ММ) є актуальними для простих і надійних пристроїв. Особливості побудови архітектури, розробка та налагодження програмного забезпечення для вбудованих систем на основі ММ передбачають необхiдність враховувати ряд факторів. У деяких типах мікропроцесорних систем (МПС) дані фактори не мають особливого значення. Прикладом таких МПС є відкриті системи на базі потужних мікропроцесорів. Прикладом архітектури таких мікропроцесорів являється архітектура IA-32, AMD 64 або інша, аналогічна за потужністю і можливістю адресувати пам'ять [1]. В цьому випадку важливим фактором є читабельність програм, можливість їх легкого супроводження, тестування і налагодження та інші питання вдосконалої розробки програмного забезпечення (ПЗ). Для вирішення вищезазначених питань використовується сучасні IDE. Програма будується з використанням типових шаблонів (патернів) [2-5], робиться формалізація ПЗ у вигляді діаграми класів та інших типів діаграм. При цьому збільшується обсяг потрібної оперативної пам'яті і вихідного коду.

На відміну від потужних МПС, в системах на базі ММ, важливим фактором є збереження оперативної пам'яті мікроконтролера ( Random AccessMemory (RAM)). Другим важливим фактором є обмеженість пам'яті програм (Read Only Memory (ROM)). Крім того, для ММ існує багато інших особливостей, які є суттєвими при конструюванні програм. При цьому, з огляду на значні відмінності в широкій номенклатурі сучасних ММ, дані особливості враховуватися не будуть. З урахуванням цього, введемо обмеження на проведення досліджень з питань побудови архітектури програмного забезпечення для МПС на базі ММ:

- в дослідженні розглядаються питання побудови архітектури програмного забезпечення на мові програмування С, С ++;

- архітектурні особливості побудови ПЗ з використанням Ассемблера або машинного коду необхідно виносити в окреме дослідження, у данному розглядатися не будуть;

- до факторів, які ураховуються в дослідженні, відноситься архітектура ПО і її вплив на потрібну ROM та обмеження памяті типу RAM;

- для дослідження були обрані приклади програми, що моделюють 3 стана ММ мікроконтролеру, це не обмежує ефективність результатів, проте потребує подальших досліджень.

Метою дослідження є порівння простої архітектури ПЗ у вигляді нескінченного циклу [3], що звичайно підлягає критиці з боку прихильників класичної архітектури типових паттернів (шаблонів), і архітектури у вигляді кінцевого автомату (КА).

Розглянемо перший варіант реалізації архітектури ПЗ для вбудованих систем на базі ММ. Першим простим варіантом є реалізація програми з використанням нескінченного циклу і спрощеного варіанту КА [3].У такої архітектурі є свої плюси і мінуси. Плюси полягають у простоті архітектурної реалізації. Такий варіант архітектури ПЗ часто зустрічається у академічних (навчальних) рішеннях і простих типах МПС, описаний у [3] і особливих пояснень не вимагає. Приведемо демонстраційних приклад коду, що реалізує дану архітектуру. У данному коді реалізована спрощена модель роботи світлофора, для демонстрації. У коді реалізовано два вкладених кінцевих автомата. Один автомат керує роботою світлофору, інший автомат моделює роботу денного і нічного режиму. Для спрощення коду і зменшення обсягу файлу, що завантажується у мікроконтроллер, стани програмно реалізовані у вигляді констант. Програма реалізована у процедурному стилі. Пояснення надані у коментарях.

Приклад вихідного коду 1

Програма побудована для мікроконтролерів родини MSP430і є робочим прикладом. Під час нескінченного циклу здійснюється перевірка глобальної змінної Semo_State, значення якої змінюються через апаратне переривання. Апаратне преривання зв'язано зі станом двох кнопок, див. функцію void isr_port_1(void).

В одному з варіантів відпрацьовує функція BlinkDAY(), що є функцією-автоматом денного режиму роботи. У іншому відпрацьовує функція BlinkNIGHT(), нічного режиму. Можливий інший варіант реалізації даної архітектури,проте особливого впливу на обсяг ROM і потрібну RAM не відбувається, що не впливає на якість досліджень. Компіляція здійснювалася з використанням середовища IAR system IAR Embeded Workbench for MSP430Version 6.50.4. В результаті компіляції розмір файлу коду для завантаження, потрібної ROM складав 1,214 байт. Тип файлу *.hex. Під час запуску програми ознак переповнення RAM не виявлено.

Аналогічні результати булиотримані для більш простого варіанту програми на основі архітектурінескінченного циклу, приклад якої внаслідок її простоти не наводиться. Прианалогічних умовах дослідження розмір файлу для завантаження дорівнював 755 байт.

Розглянемо інший варіант реалізації архітектури програми з використанням типового паттерну кінцевого автомату [2] з використанням ООП. У вихідному коді, що представлено далі, реалізований модіфікований варіант паттерну кінцевого автомату. Це експериментальний варіант, що поєднує у собі варіант нескінченного циклу і інкапсуляцію функціональності у окремому класі. У наслідок збільшення обсягу вихідного коду, у даній роботі приклад не наводиться.

Приклад вихідного коду 2

Під час запуску програми ознак переповнення RAM не виявлено. Перевагою даної реалізації є можливість збільшувати кількість станів автомату без впливу на інші елементи вихідного коду. Для даного прикладу функціональність КА інкапсульована у класи станів.

Недоліком є збільшення обсягу вихідного коду і певна відмінність від типового шаблону КА. Умови компіляції такі самі як і у прикладі вихідного коду 1. Розмір файлу коду для завантаження, тобто обсяг потрібної ROMскладав 2,334 байт. Тип файлу *.hex. Порівняння першого і другого варіантів програми дає можливість зробити висновок про незначне збільшення обсягів файлу для завантаження. Експертна оцінка даної реалізації викликала сумнівність у доцільності її використання у практичної роботі.

Розглянемо 3 варіант вихідного коду, у якому реалізований типовий варіант паттерну кінцевого автомату [2-5]. У вихідному коді і заголовочних, що представлені далі, реалізований типовий варіант паттерну кінцевого автомату. Це класичний варіант реалізації КА з використанням ООП.

Приклад вихідного коду 3

При налагодженні програми на першому етапі було виявлено утікання пам'яті. Після виявлення помилки ознак переповнення RAM не виявлено.Переваги даної реалізації показані у [2] і особливих пояснень не вимагають. Особливо уважно необхідно підходити до помилок, що пов'язані з звільненням ресурсів. Розмір файлу коду для завантаження, тобто обсяг потрібної ROM складав 3,239 байт. Тип файлу *.hex.

Порівняння першого, другого і третього варіантів програми дає можливість зробити висновок про збільшення майже у 2.5 рази обсягу потрібної ROM при використанні класичного варіанту КА для пристроів на ММ. Таким чином можна зробити наступні висновки:

- використання архітектури ПЗ у вигляді КА із застосуванням ООП дає перевагу у якості налагодження і супроводження ПЗ, що не суперечить теоретичним положенням [2-5],отже архітектура КА може використовуватися для розробки вбудованих систем на основі ММ;

- збільшення обсягу вихідного коду при застосуванні класичної архітектури КА із застосуванням ООП призводить до подвійного збільшення потрібної пам'яті програм ROM, це свідчить про доцільність використання архітектури нескінченного циклу і процедурної моделі КА у деяких випадках реалізації ПО для вбудованих систем на основі ММ;

- під час реалізації класичної архітектури КА із застосуванням ООП можливі небезпечні помилки - “ утікання пам'яті ”;

- потрібно додатково дослідити доцільність комбінованого варіанту реалізації КА (приклад вихідного коду 3);

- доцільно провести дослідження більш складних програм і їх порівняльну реалізацію у різних варіантах КА;

- необхідно провести аналогічне дослідження для операційних систем реального часу для розробки ПЗ вбудованих систем на базі ММ.

Перелік посилань

$1.$ Цилькер Б. Я. Организация ЭВМ и систем / Цилькер Б. Я. – СПб.: Питер, 2006.

$2.$ Приемы объектно-ориентированного проектирования. Паттерны проектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес. – СПб.: Пітер,2016. – 366 с.

$3.$ Фримен Э. Паттерны проектирования / Э. Фримен, Э. Фримен. –СПб: Пітер, 2016. – 656 с.

$4.$ Design Patterns – Elements of Reusable Object-Oriented Software http://www.awprofessional.com/bookstore/product.asp?isbn=0201633612&rl=1 Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides ISBN 0-201-63361-

$5.$ UML Tutorial:Finite State Machines http://rd13doc.cern.ch/Atlas/DaqSoft/sde/uml/UMLFSM.pdf Robert Martin C++ Report, June 1998

Jun 12, 2017