Какое устройство схематически показано на рис 91

ГДЗ по физике за 8 класс Генденштейн, Кирик ФГОС часть 1, 2

Почти все учителя используют в преподавании дополнительные пособия. Одним из таких является задачник по физике. Он помогает детям закрепить материал. Не всегда одного учебника с теорией достаточно, чтобы полностью вникнуть в тему. Пособие с задачами – как раз то, что нужно всем восьмиклассникам. К нему также были разработаны ГДЗ по физике сборник задач 8 класс Генденштейн часть 1, 2. Здесь собраны все правильные ответы к упражнениям основного издания. Пособие также имеет онлайн-версию, которая позволяет открывать готовые ключи в интернете. Все, что нужно иметь при себе – это телефон или компьютер с выходом в сеть. Только представьте, насколько это удобно и практично. Больше не нужно бегать в поисках печатных изданий по всему городу, все решения как на ладони.

Как пригодятся в учебе ГДЗ по физике к сборнику задач для 8 класса Генденштейна (часть 1, 2)

Учебно-методический комплекс призван помочь ученикам в:

• проверке д/з;
• подготовке к контрольным, практическим, лабораторным и тестам;
• разборе новых тем;
• закреплении изученного и т. д.

Даже если по какой-то причине школьником было пропущено занятие – не беда. Решебник поможет восполнить пробелы в знаниях без найма репетиторов. Главное – не просто списать домашку из задачника, а сначала лучше самому проработать материал. После сверки результатов рекомендуется проанализировать свои действия и исправить допущенные ошибки. Так учащийся сможет запомнить свои слабые места и в будущем больше уделить внимания подобным заданиям.

Решебник по физике для сборника задач за 8 класс (авторы: Л. Э. Генденштейн, Л. А. Кирик, И. М. Гельфгат, А. Б. Кайдалов) поможет ученикам чувствовать себя увереннее на уроке, т.к. они всегда будут готовы к нему на все сто. Школьник, чтобы блеснуть своими знаниями с места или у доски, сам будет тянуть руку, когда преподаватель задаст вопрос. Учитель непременно отметит такую тягу к учебе положительными отметками.

Войди через VK, чтобы добавить книгу в избранное

Быстрый поиск

Тема 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

Справочник с верными ответами был составлен в соответствии с дополнительным изданием авторства Гендештейна Л. Э., выпущенным издательством «Мнемозина» в двух частях в 2015-м году. Он предназначен для того, чтобы помочь школьникам справиться со всеми трудностями, которые только могут возникнуть на пути к получению хороших и отличных отметок по физике. Благодаря этому онлайн-сборнику ученики сумеют без проблем освоить рабочую программу по данной науке. Для этого им вовсе не требуется записываться на доп. курсы или обращаться за помощью к репетиторам.

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

Что дает решебник к сборнику задач по физике для 8 класса Генденштейн

На восьмой ступени обучения ребятам предстоит изучить такие темы, как:

1. Внутренняя энергия. Количество теплоты.
2. Температура. Виды теплопередачи.
3. Электризация тел.
4. Электрическое поле.
5. Сопротивление. Закон Ома.
6. Магнитное взаимодействие и др.

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

Чем поможет онлайн-решебник сборника задач по физике за 8 класс Генденштейн, Генденштейн, Кирик, Гельфгат, Кайдалов

Мало кто знал, но данное учебно-методическое пособие помогает не только быстро и качественно выполнять домашние задания, но и блистательно готовиться к:

• контрольному опросу в классе;
• олимпиаде;
• предметным конкурсам;
• обычной самостоятельной работе;
• важным тестам.

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

Неизвестный танк часть 2 — 7

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

Главный фрикцион выключают для разъединения двигателя с ко­робкой передач на время переключения передач коробки; притрогании танка с места и после переключения передачи фрикцион плавно вклю­чают. Кроме того, главный фрикцион может быть выключен для кратко­временной остановки танка при работающем двигателе и включенной пе­редаче. Главный фрикцион предохраняет детали трансмиссии от поло­мок при резком изменении числа оборотов двигателя.

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

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

Рис. 91. Устройство однодискового главного фрикциона

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

Маховик приводит во вращение отжимной и нажимной диски. Вместе с маховиком вращается и ведомый диск, зажатый между махо­виком и нажимным диском.

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

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

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

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

В рассмотренном нами фрикционе имеется один ведомый диск. Та­кой фрикцион называется однодисковым.

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

Рис. 92. Устройство многодискового главного фрикциона

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

Зубчатое соединение дисков с барабаном позволяет им переме­щаться в осевом направлении; вращаются же диски всегда вместе со своим барабаном: ведущие —с ведущим, ведомые —с ведомым.

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

Рис. 93. Общий вид многодискового главного фрикциона

Выключается фрикцион при помощи такого же механизма выклю­чения, как показан на рис. 91.

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

Рис. 94. Однодисковый главный фрикцион

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

Орион-128/Радио 06-91/Организация экранной памяти

Использование материала заявлено как добросовестное, исключительно для образовательных некоммерческих целей.

Автор: В. СУГОНЯКО, В. САФРОНОВ

Одна из важных задач, которую помогают решать самодельные («гаражные») компьютеры — не только приобщение радиолюбителей к конструированию аппаратуры, но и изучение ими основ программирования. Можно спорить о целесообразности промышленного выпуска компьютеров подобного класса (хотя их дешевизна и простота дают основание для такого спора), но трудно отрицать тот факт, что тысячи любителей, пройдя школу «Микро-80» и «Радио-86РК» стали «на ты» с микропроцессорными системами, многие профессиональные программисты выросли из среды бывших самодельщиков.

В этой статье мы постараемся помочь тем, кто хочет глубже вникнуть в устройство ПРК «Ориона-128» и расскажем о некоторых особенностях его построения — вскользь они уже затрагивались в предыдущих публикациях, но продолжают вызывать вопросы со стороны читателей.

Итак, вернемся немного назад и посмотрим, что из себя представляет «память» нашего ПРК. Рассмотрение устройства памяти ПРК «Ориона-128» удобнее начать с экранной области ОЗУ (или, как еще говорят, видеоОЗУ). Отличие видеоОЗУ «Микро-80» и «Радио-86РК» состоит в том, что информация, записанная в ячейки этой области, непосредственно отображается на экране дисплея, минуя дополнительное преобразование в аппаратно исполненном знакогенераторе.

Область видеоОЗУ «Ориона-128» занимает в основной странице памяти адресное пространство размером 12К, начиная с адреса 0C000H (по адрес 0EFFFH включительно). Кроме того, если включен цветной режим, в формировании изображения участвует соответствующая ей область дополнительной страницы, расположенная в тех же адресах, и общий объем используемой под видеоОЗУ памяти становится равным 24К. Каждая ячейка ОЗУ экранной области соответствует восьми расположенным в горизонтальный ряд точкам одной строки растра ЭЛТ. На рис.1 в качестве примера показано увеличенное схематическое изображение левого верхнего угла экрана.

Если компьютер работает в монохромном режиме, ячейки дополнительной страницы в формировании изображения не участвуют и изображение целиком зависит от того, какая информация в данный момент записана в ячейках видео области основной страницы. Бит, установленный в 1, дает на экране одну светящуюся точку. Если бит равен 0 — точка погашена. Так, например, чтобы получить такую картину — полностью погашенный экран и одна светящаяся точка в левом верхнем углу, необходимо заполнить всю область 0C000H- 0EFFFH байтами со значением 00Н, а в ячейку 0С000Н записать значение 80Н (двоичное представление шестнадцатиричного числа 80Н-10000000).

Распределение ячеек по пространству экрана показано на рис.2. Ячейки памяти располагаются последовательно друг за другом вертикальными колонками по 256 (100H) в каждой. Адрес ячейки задается двумя байтами — старший определяет номер колонки, младший — номер ячейки в колонке. Так, для того, чтобы перейти от некоторой ячейки памяти к соседней, расположенной ниже, надо увеличить на единицу значение младшего байта адреса, на ячейку выше — уменьшить на единицу это значение. Аналогично, для того чтобы перейти от некоторой ячейки к соседней, расположенной справа или слева от заданной, надо проделать такие же операции со старшим байтом адреса.

Для программиста, занимающегося разработкой программ, работающих непосредственно с ОЗУ, в том числе и с экранной областью, необходимо иметь представление об общей структуре памяти компьютера. Память компьютера можно представить в виде ленты, на которой друг за другом расположены ячейки, начиная с самой первой, имеющей адрес 0 до последней, с адресом 0FFFFH (в десятичной форме записи это число равно 65535). Однако рассмотренное нами устройство видеоОЗУ показывает, что гораздо удобнее придерживаться несколько другого представления о памяти «Ориона-128», такого, например, какое показано на рис.3.

На этом рисунке вся память схематически представлена так же, как для экранной области (см. рис.2), колонками по 256 ячеек. Основная экранная область при этом является составной частью общего поля памяти. Точно так же, как и основная страница ОЗУ, расположена дополнительная страница. Она показана сзади основной, параллельно ей. Это объясняется тем, что адреса ячеек дополнительной страницы соответствуют адресам ячеек основной, а то, с какой областью в настоящий момент работает процессор, зависит от состояния системного порта переключения страниц. Служебная область, с адреса 0F000H по адрес 0FFFFH, включает в себя служебное ОЗУ (0F000H- 0F3FFH), порты (0F400H-0F7FFH), ПЗУ и системные порты (0F800H-0FFFFH). На рис.3 она выглядит «склеенной». Это значит, что независимо от состояния системного порта страниц при обращении по этим адресам процессор однозначно будет иметь доступ к системной области.

В вопросах читателей встречается просьба более подробно рассказать о переключении экранов. Пространство ОЗУ, начиная с нулевого адреса и по адрес 0BFFFH, на рис.3 показано условно разделенным на три 16-килобайтных области. Отображаться на экране дисплея может информация, содержащаяся в любой из них. Для переключения экранов служит системный порт 2 (то есть область с адресами 0FA00H — 0FAFFH. Записывая в любую ячейку этой области значения 0, 1, 2 или 3, мы включим на отображение область экрана с соответствующим номером). Следует заметить, что возможность такого переключения была заложена еще при теоретической проработке будущего компьютера. На практике пока только одна-две большие программы используют этот режим, да и то манипулируют только двумя экранными областями. В этих программах использование двух экранов необходимо для быстрой смены информации на дисплее — «перекачка» 12К видеоОЗУ и 12К атрибутов цвета занимает достаточно большое (относительно, конечно) время, и, если такую смену надо делать часто, использование переключения экранных областей себя оправдывает. Что касается полного использования режима четырех экранов, то здесь можно сказать следующее: программы, которые будут использовать все четыре экрана в цветном варианте, должны быть достаточно специфическими.

Во-первых, тело основной программы придется размещать в «окнах», которые не отображаются на дисплее — З000Н-3FFFH, 7000Н-7FFFH, 0В000Н-0BFFFH. Во-вторых, эта программа скорее всего будет рассчитана на работу не в операционной среде «ORDOS», так как в «ORDOS» дополнительная страница ОЗУ всегда используется как электронный квазидиск, и имеет структуру, которую нельзя нарушать. Тем не менее такая возможность существует, и программисты ПРК «Ориона-128» должны это учитывать.

И, наконец, остановимся более подробно на вопросе, каким образом выводится на дисплей нашего ПРК цветная графическая информация.

ПРК «Ориона-128» имеет 3 режима отображения информации на дисплее — монохромный, четырехцветный и 16-цветный. Будем называть их режим 0, режим 1 и режим 2. Напомним, что для переключения режимов достаточно записать в системный порт с адресами 0F800H-0F8FFH (то есть в любую ячейку этой области) одно из следующих значений, являющихся основными: 0, 4, 6 (могут использоваться так же дополнительные: 1,2,3,5,7- значения 1 и 5 включат те же режимы, что и 0, 4, но в другом цветовом решении — палитре 2 — отключит изображение; значения 2 и 3, а также 6 и 7 равнозначны).

Как уже было сказано выше, в режиме 0 ячейки дополнительной страницы не принимают участие в формировании изображения. Получение 4-цветного изображения иллюстрируется рис.4. В этом режиме цвет каждой точки растра определяется значениями двух битов, один из которых берется из ячейки в основной области, другой из ячейки с тем же адресом дополнительной страницы, получившееся двоичное число (от 0 до 3), и дает цвет, в который окрашена точка: 00 — черный, 01 — красный, 10 — зеленый, 11 — синий.

Можно проделать эксперимент, непосредственно записывая значения в ячейки экранной области, пользуясь, например, программой «М128$». Для этого вызовите программу «М128$» и выполните директиву COLOR 0 (это делается для того, чтобы заполнить экранную область дополнительной страницы значениями 00Н). Изображение при этом пропадет. Теперь нажмите кнопку системного сброса и вновь вызовите «М128$». Директивой MODIFY F8001 запишите в системный порт значение 4 и нажмите «.» (точку), чтобы выйти обратно в меню программы «М128$». Далее директивой MODIFY Е8801 запишите в эту ячейку дополнительной страницы значение из примера на рисунке 4 (1E) и вновь нажмите «.». Наконец, в ячейку с тем же адресом, но в основной странице, запишите значение 93Н (директива MODIFY Е8801).

Если вы правильно проделаете все действия и сведение лучей вашего телевизора достаточно хорошее, вы получите 8 цветных точек, расположенных так, как это показано на рис.4.

В режиме 2 окраска точек происходит совершенно по-другому (рис.5). В этом режиме 8 точек каждой ячейки могут быть окрашены в одно из 256 сочетаний 16 цветов фона и 16 цветов переднего плана. Точками фона считаются точки, значения соответствующих битов которых в байте основной области равны 0 — в наших примерах это (считая слева направо) 2-я, 3-я, 5-я и 6-я точки, а передний план (изображение) — 1-я, 4-я, 7-я и 8-я точки. Ячейка дополнительной области в данном случае определяет, какой цвет имеют те и другие. Старшая тетрада байта этой ячейки задает окраску фона, младшая — изображения. Так, в примере на рис.5 выбрано сине-желтое сочетание.

Проверить все сказанное можно так же, как и в случае с 4-цветным режимом: с помощью программы «М128$». Если вы будете это делать, то вместо директивы COLOR О нужно выполнить директиву COLOR О А и, не пользуясь системным сбросом, перейти к следующему пункту, но в ячейку 0F800H (системный порт цвета) нужно записать не 4, а 6. Все дальнейшие действия повторяются.

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

В режиме 2 каждый бит тетрады отвечает за один из основных цветов, а старший (биты 7 и 3- соответственно для старшей и младшей тетрады) — за яркость цвета (1 — полная яркость, 0 — несколько пониженная): D7 (D3) — яркость, D6 (D2) — красный, D5 (D1) — зеленый, D4 (D0) — синий.

Так, в примере на рис.4 желтый цвет получается сочетанием зеленого и красного (биты D2 и D1), а яркость его определяет установленный в 1 бит D3.

Для записи байта в дополнительную страницу ОЗУ (и соответственно для задания атрибутов цвета любой ячейки экрана) служит специальная подпрограмма «Монитора», адрес входа в которую 0F8З0Н. Для обращения к этой подпрограмме необходимо в регистр С занести значение записываемого байта, а в аккумулятор — значение 1 (признак того, в какую страницу производится запись).

В. СУГОНЯКО, В. САФРОНОВ

Отсканировано с журнала Радио № 6 1991 г.

Отредактировано Лесных Ю. 2001 г.

Виртуальная машина «Etherbox32vm» Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Шевчук Юрий Владимирович, Шевчук Андрей Юрьевич

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Шевчук Юрий Владимирович, Шевчук Андрей Юрьевич

Etherbox: протокол для управления модульной сенсорной сетью

Анализ перспектив интеграции беспроводных сенсорных сетей с сетью Интернет с использованием стандарта 6lоwраn

Стековые микропроцессоры, или новое — это хорошо забытое новое
Виртуальная машина для проекта РуСи

Использование беспроводных сенсорных сетей для сбора, передачи и обработки информации в системах мониторинга состояния объектов

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Etherbox32vm virtual machine

The article presents the Etherbox32vm virtual machine architecture. Etherbox32vm is a virtual machine implemented on network nodes in heterogeneous sensor networks to make it possible to change node behaviour remotely. Sensor aquisition and actuator control scenarios, as well as preliminary sensor data processing, can be specified in the form of small programs for the Etherbox32vm virtual machine . Etherbox32vm is light-weight enough to be implementable on microcontrollers with scarce RAM. (In Russian)

Текст научной работы на тему «Виртуальная машина «Etherbox32vm»»

ISSN 2079-3316 ПРОГРАММНЫЕ СИСТЕМЫ: ТЕОРИЯ И ПРИЛОЖЕНИЯ №4(31), 2016, с. 119-143 УДК 004.45

Ю. В. Шевчук, А. Ю. Шевчук

Виртуальная машина «Etherbox32vm»

Аннотация. Описана организация виртуальной машины Etherbox32vm, предназначенной для реализации сценариев функционирования узлов сенсорной сети: дисциплин опроса датчиков, управления исполнительными механизмами, первичной обработки данных, полученных от датчиков. Реализация логики поведения сенсорных узлов в виртуальной машине позволяет удаленно настраивать узлы уже развернутой гетерогенной сенсорной сети на выполнение новых функций. Виртуальная машина Etherbox32vm допускает реализацию на микроконтроллерах с малым объемом оперативной памяти.

Ключевые слова и фразы: сенсорные сети, виртуальная машина, стековая машина.

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

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

© Ю. В. Шевчук, А. Ю. Шевчук, 2016

© Институт ПРОГРАММНЫХ систем имени А. К. Айламазяна РАН, 2016 © Программные системы: теория и приложения, 2016

Решать эту проблему можно разными способами. Например, если сенсорный узел реализован на базе миниатюрного компьютера под управлением ОС семейства UN*X (такой как [1] или [2]), можно было бы задавать сценарии в форме скриптов на shell или другом интерпретируемом языке. Или (диаметрально противоположный подход) можно загружать сценарии в форме программы, скомпилированной в код процессора сенсорного узла. Возможны и другие варианты. При выборе решения необходимо учитывать следующие обстоятельства:

• на данном этапе развития технологии среди сенсорных узлов преобладают устройства с ограниченными ресурсами, например на базе микроконтроллеров с объемом памяти порядка 30КБ, так что выбранное решение должно допускать компактную реализацию;

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

• канал связи с сенсорным узлом может быть низкоскоростным (LoWPAN) или помегабайтно оплачиваемым (GSM). Поэтому как сценарии, так и пересылаемые ими на управляющую станцию данные должны быть компактными;

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

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

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

1. Обзор возможных решений

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

1.1. Удаленное перепрограммирование сенсорных узлов

Суть подхода заключается в полной удаленной замене образа программного обеспечения обновляемого устройства.

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

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

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

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

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

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

1.2. Динамическое подключение исполняемых модулей Contiki

В операционной системе Contiki [4] существует механизм динамической загрузки исполняемых программных модулей. Этот механизм позволяет снизить объем обновлений по сравнению с полной заменой образа, а также снимает необходимость перезагружать устройство после каждого обновления. Однако проблемы с надежностью и гетерогенностью сети остаются.

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

Существуют реализации для маломощных устройств как виртуальных машин общего назначения, например JVM [3,5,6], так и специализированных виртуальных машин, спроектированных для сенсорных сетей, таких как VM* [5], Mate [7], CVM [3].

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

• минимизация размера передаваемых по сети обновлений снижает энергопотребление устройства;

• защищенная среда исполнения повышает устойчивость устройства к ошибкам времени исполнения.

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

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

2. Виртуальная машина Etherbox32vm

2.1. Место Etherbox32vm в программном обеспечении сенсорного узла

Программы в байт-коде Etherbox32vm поступают в сенсорный узел через транспортный интерфейс сенсорного узла. В гетерогенной сенсорной сети сетевой уровень реализован с использованием протокола интернет: IPv4 или IPv6; для доставки байт-кода узлу используется специализированный прикладной протокол, основанный на протоколе UDP [8]. Описание протокола выходит за рамки настоящей статьи; отметим только, что в одном пакете UDP содержится законченная программа для виртуальной машины. Максимальный размер UDP-пакета с учетом фрагментации составляет 64КБ. В имеющихся на сегодняшний день реализациях сенсорных узлов с Etherbox32vm фрагментация IP-пакетов не поддерживается, так что максимальный размер программы вместе с накладными расходами на протокол не может превышать MTU1 сети: 1500 или 1280 байтов в разных реализациях. Благодаря компактности кода виртуальной машины Etherbox32vm, этого оказывается достаточно для возникающих на практике задач, а если размер кода все же превысит максимальный, есть возможность выноса части кода в описанные ниже в разделе 2.7 публичные функции.

1Maximum transmission unit — максимальный размер пакета сети второго уровня, доступный для использования протоколом IP

Минимальная программа для Etherbox32vm может состоять всего из одной команды. За небольшой размер мы будем называть программы для Etherbox32vm словом проглет (англ. proglet2).

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

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

• задание дисциплины (порядка и частоты) опроса датчиков;

• первичная обработка полученных от датчиков данных: агрегирование, фильтрация, принятие решения об отправке данных на управляющую станцию;

• задание дисциплины (порядка, частоты, условий) активации исполнительных механизмов.

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

2Proglet — «очень маленькая программа», по аналогии с Piglet — «очень маленькое существо» [9].

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

2.2. Архитектура Etherbox32vm

Etherbox32vm является стековой машиной. Вычислительный и программный стеки объединены в один стек.

По сравнению с регистровой архитектурой, стековая архитектура позволяет уменьшить объем кода, исполняемого виртуальной машиной за счет отсутствия полей выбора операндов в коде инструкций [10, 11]. В момент интерпретации большей части инструкций, операнды находятся уже на стеке и именно в том порядке, в каком их ожидает интерпретатор.

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

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

Рис. 1. Стек до и после команды add

Элементы стека являются целыми значениями длиной 32 бита. Куча (heap) в памяти проглета отсутствует, динамическое выделение памяти не предусмотрено. Адреса возврата из функций хранятся в отдельном стеке вызовов в памяти интрепретатора, вне адресного пространства проглета. Работа со стеком вызовов осуществляется только командами вызова функций и возврата из них; никакие другие манипуляции с содержимым стека вызовов невозможны.

Каждый проглет выполняется в собственном виртуальном адресном пространстве, которое инициализируется содержимым UDP-пакета. Выполнение начинается с первой инструкции проглета (с адреса 0).

2.3. Система команд Etherbox32vm

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

Таким образом работают, например, команды арифметических и логических операций, как схематически показано на рисунке 1.

Существуют также команды, операнды которых передаются в виде непосредственных значений, следующих за байтом кода команды. Такие команды могут быть представлены в памяти несколькими байтами. Порядок байтов в непосредственных значениях — little endian (первый байт содержит младшие биты, последний старшие).

Есть также несколько команд, у которых часть кода команды представляет собой непосредственный операнд или его часть. Например, команда push11 представлена двумя байтами. Эта команда загружает на стек значение, содержащееся в младших 11 битах команды: 8 бит младшего байта и 3 младших бита старшего байта. Пять старших битов кода команды идентифицируют команду как pushll. Подобная ей команда push6 кодируется одним байтом и загружает на стек непосредственное значение длиной до 6 бит. Таким образом, загрузка часто встречающихся в программах малых констант экономично кодируется одним или двумя байтами, в то время как для кодирования команды push32, загружающей любое 32-битное значение, потребуется пять байтов.

Результатом работы некоторых команд является модификация массива байтов, следующих за кодом команды. К таким командам относятся, например, команды работы со внешними интерфейсами, описанные ниже в разделе 2.9.

Etherbox32vm реализует набор инструкций, достаточный для реализации Си-подобного языка. Проглеты, состоящие из нескольких команд, легко выражаются на языке ассемблера. Для более сложных проглетов существует компилятор Си-подобного языка Etherbox2 в байт-код Etherbox32vm [14].

2.4. Работа со стеком и памятью

В машине Etherbox32vm единственный стек выполняет функции вычислительного стека, используемого для аргументов и результатов команд, и программного стека, используемого для локальных переменных, аргументов и результатов функций. Поэтому помимо команд работы с вершиной стека, традиционных для этой структуры данных (добавление, удаление, дублирование элемента на вершине стека — push, pop, dup), предусмотрены дополнительные команды:

dupn N — копирование на верхушку стека значения, находящегося в стеке на глубине N;

pushn VAL N — модификация значения, находящегося в стеке на глубине N;

popn N — удаление N элементов с верхушки стека.

Таблица 1. Структура команды data

Поле opcode length data

Длина в байтах 1 2 length

Дополнительные команды позволяют работать с находящимися на стеке локальными переменными и аргументами функций. Поскольку положение локальных переменных относительно начала стекового фрейма остается неизменным, для чтения и записи локальных данных функции оказывается достаточно двух команд (первая из которых — загрузка константы N), равно как и для удаления стекового фрейма при возврате из функции (см. также раздел 2.6, «Работа с подпрограммами»).

Загрузка значений из памяти на стек осуществляется командами load8, load16, load32. Эти команды получают единственный аргумент на стеке: адрес загружаемого значения. Сохранение значения, находящегося на вершине стека, в память проглета, осуществляется командами store8, store16, store32.

Адресация памяти производится по абсолютному адресу в виртуальном адресном пространстве проглета.

2.5. Сегмент данных

Сегмент данных проглета содержится в теле команды data. Структура команды data описана в таблице 1. Традиционный для языка Си сегмент bss отсутствует, неинициализированные данные помещаются в сегмент данных и инициализируются нулями. Это упрощение плохо согласуется с заявленной целью снижения объема передаваемых по сети данных, но в перспективе планируется реализовать в протоколе сжатие данных, что нейтрализует этот негативный эффект.

Если статические данные присутствуют в программе, команда data записывается в последовательности команд первой. Таким образом, значения адресов статических данных проглета оказываются наименьшими, что увеличивает долю компактных команд push8 среди команд загрузки на стек адресов переменных.

Загрузка значений из сегмента данных на стек и обратно производится командами load и store, соответственно.

stack return frame value

Рис. 2. Стек до и после команды smartret

2.6. Работа с подпрограммами

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

Команда ret производит возврат из текущей функции, совершая переход по адресу, находящемуся на верхушке стека возвратов текущего проглета.

Уровень начала стекового фрейма текущей функции также хранится в стеке возвратов. Стековый фрейм, содержащий аргументы и локальные переменные функции, удаляется командой popn непосредственно перед возвратом из функции.

Однако в случае, если функция возвращает значение, при удалении стекового фрейма требуется сохранить находящееся в момент возврата на вершине стека возвращаемое значение. Для этого была введена специальная команда smartret (см. рис. 2).

2.7. Публичные функции

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

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Рис. 3. Стек до и после команды link

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

Регистрация публичной функции осуществляется посредством команды link. Команда link получает два аргумента на стеке: адрес, по которому в текущем проглете находится функция, и числовой дескриптор, который требуется ей присвоить (рис. 3).

После того, как публичная функция зарегистрирована, она может быть вызвана из другого проглета, работающего на этом же устройстве, командой xcall. Команда xcall получает единственный аргумент: дескприптор вызываемой публичной функции.

Код вызываемой публичной функции выполняется в контексте текущего проглета (а значит, и с текущим стеком), но в адресном пространстве того проглета, в котором находится код публичной функции.

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

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

ТТЛ 1 элементы стека 1 1 1 1 dst pack size

Рис. 4. Стек до и после команд copyret и copyargs

copyargs и copyret, предназначенных для копирования данных из памяти одного проглета в память другого. Обе команды получают свои аргументы на стеке.

Команда copyargs копирует данные из вызывающего проглета в текущий. В публичную функцию передается значение pack, содержащее в упакованном виде адрес и длину буфера, содержащего данные, а уже сама функция вызывает copyargs, копируя данные из вызывающего проглета в буфер в вызываемом проглете.

Команда copyret копирует данные из последнего вызывавшегося проглета в текущий. Чтобы возвратить массив, публичная функция возвращает значение pack, после чего вызывающая функция копирует данные из вызываемого проглета в буфер в вызывающем проглете командой copyret.

Действие команд copyargs и copyret на стек показано на рисунке 4), где dst и size — адрес и размер локального буфера; pack — адрес и длина удаленного буфера, содержащего копируемые данные, в упакованном виде: pack = ien

2.7.1. Публичные функции и выполнение проглета

Вызов публичной функции никак не влияет на выполнение проглета, которому принадлежит функция. Возможно, такая функциональность будет добавлена позже, например в форме команды wakeup, которая при вызове внутри публичной функции возвращает проглет в очередь готовых к исполнению, если проглет исполнял команду задержки (например, mdelay). Это позволит приблизить семантику вызова публичной функции к семантике обмена сообщениями, в которой присутствует как передача инфрмациии, так и синхронизация.

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

2.8. Ветвление и базовые блоки

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

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

Для более эффективного решения проблемы согласования уровня стека в систему команд Etherbox32vm была введена команда adjust. Команда adjust получает один аргумент на стеке: число элементов стека относительно начала текущего стекового фрейма, которое должно остаться на стеке после выполнения этой команды. Если в текущий момент на стеке находятся избыточные элементы, они удаляются. Если элементов недостаточно, добавляются нулевые элементы в нужном количестве.

Команда adjust добавляется компилятором языка Etherbox2 перед началом каждого базового блока.

3Базовый блок — последовательность инструкций, содержащая единственную точку входа (начало блока), единственную точку выхода (конец блока) и не содержащая инструкций передачи управления за границы блока.

Таблица 2. Структура команды i2c

Поле opcode len count data

Длина в байтах 1 12 len

2.9. Работа со внешними интерфейсами

В рассматриваемой сенсорной сети узлы имеют модульную конструкцию. Все датчики и исполнительные механизмы подключены к модулю, где работает Etherbox32vm, посредством шины I2C [15]. Доступ к устройствам на шине осуществляется одноименной командой i2c. Структура команды i2c показана в таблице 2.

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

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

Подобным же образом, с сохранением результаов операций чтения в теле проглета, устроены команды работы с интерфейсами UART и CAN Bus.

2.10. Групповой опрос сенсорных узлов

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

4от слов watchdog timer (англ.)

Для опроса узлов со стороны управляющей станции отправляется пакет с групповой (multicast) адресацией, содержащий команды считывания состояния узла и команду wdt. Но конфигурация узлов в сенсорной сети может различаться, соответственно различается и набор данных, составляющих статус каждого сенсорного узла, а значит должен различаться и набор действий, выполняемых сенсорным узлом для составления статуса. То есть в общем случае составить проглет, подходящий для всех узлов при групповом опросе, невозможно.

Для решения этой проблемы в системе команд Etherbox32vm присутствует полиморфная команда poll, по которой каждый узел отрабатывает установленную во время конфигурации индивидуальную последовательность команд. Последовательность команд, выполняемая по команде poll, сохраняется командой savepoll.

2.11. Сохранение проглетов

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

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

2.12. Обработка ошибок

По умолчанию, ошибки времени исполнения (например, доступ к несуществующему адресу памяти, переполнение стека, вызов несуществующей публичной функции) приводят к аварийному прекращению исполнения проглета с последующей отправкой ответа на управляющую станцию (см. раздел 2.13).

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

Выбор возврата из функции в качестве реакции на возникновение ошибки обусловлен простотой реализации: восстановление от ошибки в любой точке функции, при любом состоянии стека сводится к удалению со стека всех переменных и временных значений, добавленных текущей функцией. Необходимый для этого уровень начала стекового фрейма текущей функции уже присутствует в стеке возвратов. А попытка поддержать конструкцию try..catch в духе языка СиН—+ потребовала бы специального сохранения состояния стека и адреса catch-блока.

2.13. Завершение проглета и отправка ответа

Завершение работы проглета происходит в следующих случаях:

(1) исполнение достигает конца программы;

(2) в результате исполнения команды end;

(3) в результате ошибки времени исполнения.

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

Есть также возможность отправить сообщение на управляющую станцию и не завершая работу проглета. Команда send передает текущий проглет на управляющую станцию, а затем продолжает его исполнение.

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

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

Команда send3 позволяет отправить на управляющую станцию произвольный фрагмент текущего проглета. Адрес начала и длина передаваемого фрагмента являются аргументами команды send3.

В разделе 2.3 сказано, что Etherbox32vm реализует набор инструкций, достаточный для реализации Си-подобного языка. Это действительно так, но язык будет иметь несколько существенных ограничений по сравнению с языком Си:

• общий объем задействованных аргументов функций и автоматических переменных в любой момент выполнения программы ограничен глубиной стека виртуальной машины, которая на малых микроконтроллерах совсем небольшая (64 слова). Поэтому рекурсивные приемы программирования практически неприменимы, и при создании автоматических переменных приходится соблюдать осторожность, чтобы не столкнуться с переполнением стека во время выполнения;

• поскольку стек находится вне адресного пространства проглета, невозможно получить указатель на автоматическую переменную. Это особенно заметно для автоматических массивов: доступ по индексу реализуем, доступ по указателю принципиально нет;

• беззнаковые (unsigned) типы не поддерживаются. Это не принципиальное ограничение, при необходимости их можно поддержать ценой добавления команд беззнакового сравнения;

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

2.15. Примеры программ

Ниже приведены три проглета, написанные на языке ассемблера Etherbox32vm. Стоит отметить, что в эксплуатации для кодирования проглетов обычно используется язык более высокого уровня, Си-подобный язык Etherbox2, компилируемый в байт-код Ethrebox32vm.

ТТЛ 1 элементы стека 1 1 1 1 value target delta

Рис. 5. Стек до и после команды near

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

сегмент данных проглета загрузка значения 33 на стек

сохранение результата (34) обратно в data

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

Проглет, опрашивающий в цикле с периодом в 0.5 секунды периферийное устройство через интерфейс I2C. В ответе устройства находятся, среди прочего, показания датчика температуры. В сегменте данных находятся переданные управляющей станцией номинальное значение температуры и допустимое отклонение измеренной температуры от номинального в единицах АЦП. Проглет завершается, если измеренная температура отличается от номинальной на величину, превышающую допустимое отклонение.

data 132 15 232 15

mspause 500 load16 read+3+2 load16 data+3+0 load16 data+3+2 near

0 градусов (16 бит: 15*256+132=3972), 1 градус (16 bit: 15*256+232=4072) в единицах АЦП датчика температуры

чтение показаний периферийного устройства

задержка 0.5 секунды полученная от датчика температура целевое значение температуры допустимая величина ошибки

Команда near получает три аргумента на стеке: value, target и delta, и возвращает 1 в случае, если value отличается от target на величину меньшую, чем delta (рис. 5).

Команда i2c в этом примере осуществляет чтение 12 байт с устройства с адресом 37 на шине I2C. Завершившая чтение команда i2c выглядит в байткоде так:

^1Еу ^ ^12^ 37 0 107 28 50 2 0 0 0 61 134 124 250

opcode len count addr, data

Показания датчика температуры указаны в единицах АЦП температурного датчика и представлены 16-битным значением на смещении 1 от начала ответа в порядке little endian. Здесь это байты со значениями 107 и 28.

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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

единственной команды, и декодируется на управляющей станции по общим правилам.

send3 12+1+3 read 0

dspause 100 push read br

чтение показаний периферийного устройства

отправка на управляющую станцию участка проглета длиной 16, начинающегося с метки read задержка 10 секунд

Представленная в статье архитектура виртуальной машины явла-ется результатом эволюции Etherbox32vm под влиянием опыта практического использования в сенсорных сетях. Использование виртуальной машины позволяет достичь поставленной цели — безопасного удаленного изменения поведения узлов сенсорной сети. В форме команд виртуальной машины действительно удается с достаточной эффективностью выразить встречающиеся на практике сценарии функционирования сенсорных узлов.

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

URL: https://raspberrypi.org/ f 120 URL: https://www.olimex.com/Products/OLinuXino/open-source-

A. Dunkels, et al. “Run-Time Dynamic Linking for Reprogramming Wireless Sensor Networks”, Proceedings of the 4th International Conference on Embedded Networked Sensor Systems, SenSys’06 (October 31-November 03, 2006, Boulder, Colorado, USA), ACM, New York, USA, 2006, pp. 15-28. f 122,123

Contiki: The Open Source OS for the Internet of Things, URL: http://www.contiki-os.org/f122

J. Koshy, R. Pandey. “VMSTAR: Synthesizing Scalable Runtime Environments for Sensor Networks”, Proceedings of the 3rd International Conference on Embedded Networked Sensor Systems, SenSys’05 (November 02-04, 2005, San Diego, California, USA), ACM, New York, USA, 2005, pp. 243-254. f 122

T. Lindholm, F. Yellin. The Java Virtual Machine Specification, Addison-Wesley, 1999. f 122

P. Levis, D. Culler. “Mate: A Tiny Virtual Machine for Sensor Networks”, Proceedings of Tenth International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS’02 (October 05-09, 2002, San Jose, CA, USA), ACM, New York, USA, 2002, pp. 85-95. f 122

J. Postel. User Datagram Protocol, RFC768, RFC Editor, August 28, 1980, URL: http://www.rfc-editor.org/rfc/rfc768.txt f 123 A. A. Milne. Winnie-the-Pooh, Methuen & Co. Ltd., London, 1926. f 124 Y. Shi, et al. “Virtual Machine Showdown: Stack Versus Registers”, ACM Trans. Archit. Code Optim. 4:4 (January 2008), Article No. 2. f 125 P. Koopman, Stack Computers, Ellis Horwood Series in Computers and Their Applications, Ellis Horwood/Halstead Press, 1989, 236 p. f 125 P. J. Koopman, Jr. “A Preliminary Exploration of Optimized Stack Code Generation”, Journal of Forth Application and Research, 6:3 (1994), pp. 241-251. f 125

M. Shannon, C. Bailey. “Global Stack Allocation (Register Allocation for Stack Machines)”, Procedings of 22nd EuroForth Conference, EuroForth 2006 (September 15-17, 2006, Cambridge, England), 2006, 8 p., URL: http://www.complang.tuwien.ac.at/anton/euroforth2006/ papers/shannon.pdf f 125

А. Шевчук. «Компилятор языка Etherbox2», Наукоемкие информационные технологии (Переславль-Залесский, 2010), 9с., URL: http://site.u. pereslavl.ru/Studentu/Kohkursy/konferenciya/2010/091-10.pdff127

[15] UM10204. I2 C-bus specification and user manual, NXP Semicondictor, 2014, 64 p., URL: http://www.nxp.com/documents/user_manual/UM10204.

Рекомендовал к публикации к.ф.-м.н. А. В. Климов

Пример ссылки на эту публикацию:

Ю. В. Шевчук, А. Ю. Шевчук. «Виртуальная машина «Etherbox32vm»», Программные системы: теория и приложения, 2016, 7:4(31), с. 119-143. URL: http://psta.psiras.ru/read/psta2016_4_119-143.pdf

Юрий Владимирович ^Шевчук

Зав. лабораторией телекоммуникаций, к.т.н. Область интересов: системное программирование, цифровая электроника, сети компьютеров, сенсорные сети.

©Андрей Юрьевич ^Шевчук

Инженер-исследователь. Область интересов: программирование встроенных систем, Web-программирование

Yury Shevchuk, Andrey Shevchuk. Etherbox32vm virtual machine.

Abstract. The article presents the Etherbox32vm virtual machine architecture. Etherbox32vm is a virtual machine implemented on network nodes in heterogeneous sensor networks to make it possible to change node behaviour remotely. Sensor aquisition and actuator control scenarios, as well as preliminary sensor data processing, can be specified in the form of small programs for the Etherbox32vm virtual machine. Etherbox32vm is light-weight enough to be implementable on microcontrollers with scarce RAM. (In Russian).

Key words and phrases: sensor networks, virtual machine, stack machine.

[1] URL: https://raspberrypi.org/

[2] URL: https://www.olimex.com/Products/OLinuXino/open-source-hardware

[3] A. Dunkels, et al. “Run-Time Dynamic Linking for Reprogramming Wireless Sensor Networks”, Proceedings of the 4th International Conference on Embedded Networked Sensor Systems, SenSys’06 (October 31—November 03, 2006, Boulder, Colorado, USA), ACM, New York, USA, 2006, pp. 15—28.

[4] Contiki: The Open Source OS for the Internet of Things, URL:

[5] J. Koshy, R. Pandey. “VMSTAR: Synthesizing Scalable Runtime Environments for Sensor Networks”, Proceedings of the 3rd International Conference on Embedded Networked Sensor Systems, SenSys’05 (November 02-04, 2005, San Diego, California, USA), ACM, New York, USA, 2005, pp. 243-254.

[6] T. Lindholm, F. Yellin. The Java Virtual Machine Specification, Addison-Wesley, 1999.

[7] P. Levis, D. Culler. “Mate: A Tiny Virtual Machine for Sensor Networks”, Proceedings of Tenth International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS’02 (October 05-09, 2002, San Jose, CA, USA), ACM, New York, USA, 2002, pp. 85-95.

[8] J. Postel. User Datagram Protocol, RFC768, RFC Editor, August 28, 1980, URL: http://www.rfc-editor.org/rfc/rfc768.txt

[9] A.A. Milne. Winnie-the-Pooh, Methuen & Co. Ltd., London, 1926.

[10] Y. Shi, et al. “Virtual Machine Showdown: Stack Versus Registers”, ACM Trans. Archit. Code Optim., 4:4 (January 2008), Article No. 2.

[11] P. Koopman, Stack Computers, Ellis Horwood Series in Computers and Their Applications, Ellis Horwood/Halstead Press, 1989, 236 p.

[12] P. J. Koopman, Jr. “A Preliminary Exploration of Optimized Stack Code Generation”, Journal of Forth Application and Research, 6:3 (1994), pp. 241-251.

[13] M. Shannon, C. Bailey. “Global Stack Allocation (Register Allocation for

Stack Machines)”, Procedings of 22nd EuroForth Conference, EuroForth 2006 (September 15-17, 2006, Cambridge, England), 2006, 8 p., URL:

© Y. V. Shevchuk, a. Y. Shevchuk, 2016 © Ailamazyan Program Systems Institute of RAS, 2016 © Program systems: Theory and Applications, 2016

[14] A. Shevchuk. “Etherbox2 language compiler”, Proceedings of Junior research and development conference of Ailamazyan Pereslavl University (Pereslavl-Zalessky, 2010), pp. 91—99 (in Russian), URL: http://site.u.pereslavl.ru/Studentu/ Konkursy/konf erenciya/2010/091-10.pdf

[15] UM10204. I2 C-bus specification and user manual, NXP Semicondictor, 2014, 64 p., URL: http://www.nxp.com/documents/user_manual/UM10204.pdf

Sample citation of this publication: