Arduino Mega. Контроллер теплицы. Хроники

РЕКЛАМА НА ФОРУМХАУС

DIYMan, можно попросить Вас одним глазком взглянуть на код dachnik-a, на сайте вот тут: Умная теплица, пост #89.
Я решил сравнить с той программой, которую сам нацарапал и был поражён несходством. С моей убогой точки зрения, у него там с фанатическим упорством повторяются одни и те же фрагменты кода, а с другой стороны, в них имеются отличия, поэтому нельзя оформить как вызов одной и той же подпрограммы.
Я знаю, Вам смотреть такие опусы неприятно, всё равно что ковыряться в г..., но полагаю у Вас это займёт всего несколько минут времени, чтобы поставить точный диагноз - чем страдает код, если страдает.
Я интересуюсь потому, что всё равно пока не могу воспользоваться тем, что Вы нам любезно выложили - не дорос, так скать, а код дачника мне, честно говоря, совсем не понравился, хотя и понятен и всё у него чётко разложено по функциям.

 

@Cofessor, код страдает тем же, что и весь быстро писаный код: всё в кучу. Понятное дело, что в микроконтроллерах есть ограничение по памяти и объёму кода, поэтому особо там ООП не применишь. Но! Код dachnik-a - он, так сказать, малосопровождаемый, ошибки в нём будет вылавливать очень трудно даже самому автору через пару месяцев.

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

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

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

1. Вместо многократных вызовов buttonState =, buttonState_0 = и т. п. (у кнопок ещё и малоинформативные имена - это тоже большой грех, к слову) вводим простую структурку:

Код:

Struct InputStates
{
  uint8_t ButtonUp;
  uint8_t ButtonDown;
  uint8_t ButtonLeft;
  uint8_t ButtonRight;

void Update()
{
  ButtonUp = digitalRead(ButtonUpPin);
  ButtonDown = digitalRead(ButtonDownPin);
  ButtonLeft = digitalRead(ButtonLeftPin);
  ButtonRight = digitalRead(ButtonRightPin);
}
};
InputStates ButtonStates; // создаём экземпляр этой структуры где-нибудь

И в нужном месте вызываем:

Код:

ButtonStates.Update();
if(ButtonStates.ButtonUp == HIGH) {/*Кнопка UP нажата*/}

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

Аналогично про вывод на LCD - пишется простенький класс вывода, который внутри себя делает чёрную работу. Захотели поменять экран на другой - рабочий код не трогаем, трогаем только класс вывода на экран.

Вот как-то так. Скажем - я бы сразу писал по другому, но это только моё личное мнение.

 

Тем временем пришёл ко мне модуль реального времени, такая вот тавтология Модуль DS3231 - там тебе и время, и дата, и аж два алерта, сиречь будильника, и - даже температура (впрочем, лучше её не юзать, это для внутреннего потребления модуля, так сказать - хотя он отдаёт её показания исправно).

Понятное дело - такое добро должно быть присобачено к Меге тут же! Что я и сделал, предварительно скачав библиотеку (я положил её в общий архив; надеюсь, кто в теме, знает, как устанавливать библиотеки в среду ArduinoIDE), и запаяв несколько штырьков (выпаянных со старых плат) к одному концу проводков, срезанных со старых плат же (ну не было у меня проводков папа-мама, были только папа-папа, да мама-голый_провод, пришлось колхозить ).

Короче, наколхозил я добра, и стал думать - а куда, собственно, воткнуть этот класс часов? Подумал, и понял, что единственное ему место - в классе контроллера, сиречь ModuleController. А кому надо - тот дёрнет контроллер на предмет опроса времени. Поэтому не стал писать отдельный модуль для часов, т. е. часы, другими словами, в общую сеть не выставлены - не умеют отвечать на запросы типа CTGET. Думаю, если это понадобиться в дальнейшем - модуль легко допишется.

Sure, если кому не надо часов реального времени (или же пока модуля нет) - гоу то Globals. h, и там комментируем строчку USE_DS3231_REALTIME_CLOCK, тогда модуль использоваться не будет, а он тянет около двух килобайт за собой.

Если скомпилировать, как есть, и залить в Мегу, предварительно подключив модуль к питанию и земле, SDA -> пин 20, SCL -> пин 21, потом открыть монитор порта - то там будет видна строка текущего времени, вместе с датой. Всё работает сдато, короче

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

Ну вот мы и перешли к собственно железу, как и обещал

З. Ы. Совсем забыл, голова садовая: модуль, собственно, вот такой: https://www.aliexpress.com/item/Hot-Sale-DS3231-AT24C32-IIC-Precision-RTC-Real-Time-Clock-Memory-Module-For-Arduino-Free-Shipping/32286657514.html

Завёлся сразу, даже какой-то когнитивный диссонанс у меня

 

А точки здесь какую роль играют? Ранее встречал их только в функциях библиотек. Это не разделение объекта с его содержимым?

 

Точка в данному случае - оператор доступа к члену класса, т. е., на примере:

int state = ButtonStates. ButtonUp;

Это значит: получить значение переменной ButtonUp экземпляра класса с именем ButtonStates, и записать его в переменную типа int с идентификатором state. И, наоборот:

ButtonStates. ButtonUp = 1;

Будет значить: записать 1 в переменную с идентификатором ButtonUp, которая находится в экземпляре класса, и этот экземпляр носит гордое имя ButtonStates.

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

Но в конечном итоге всё это добро всё равно сводится к ассемблеру

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

Надеюсь, не запутал.

 

Мы в город Изумрудный
Идем дорогой трудной,
Идем дорогой трудной,
Дорогой непрямой...

Пропели? Прочувствовали? Прослезились? Ото-ж!

Ситуация, прямо как по дороге в Изумрудный город - и трудно, и извилисто. Зато - захватывающе! Думаю вот - система позволяет вертеть модулями как хочешь с помощью директив условной компиляции, поэтому - добра много быть не может! Понятное дело, что не нужон мне Bluetooth, чтобы подключиться к контроллеру теплицы, не-ну-жон! Зато - для какой-нибудь домашней метеостанции, если вдруг руки зачешутся через годик-другой - самое оно! Значит, поступаем так: заказываем у китайцев модуль блютуза, и - дописываем его поддержку в контроллер, правильно? Свршенно врно, т-щ праааапорЩИК! Всё равно модуль только через месяц придёт - значит, мы запланировали себе работу на "через месяц", а пока - будет что почитать в этих ваших интернетах, на тему ознакомления с документацией - на каком вертеле блютуз крутить, какими солью/перцем его посыпать и когда снимать с огня, чтоб не сгорело.

Заодно, в кои то веки - придётся осваивать написание приложений под андроид. Откладывал столько лет, а вот теперь таки дополз. А откладывал-то почему? Да бесит Java, до скрежета зубовного! Уж лучше C# какой-нибудь, чем её, родимую. Но что поделаешь - гугль, меня не спросивши, собака такой, взял - да и вбабахал яву в андроид. Так что теперь уже я, не спросившись гугля, буду эту самую яву мучить. Эээх... Зато, как освою - там и до кошерного вай-фая недалече, а это уже сильно интересней - рулить Мегой с вай-фая, пускай и с помощью постылой Java.

Яву, яву - взял я нахаляву!

З. Ы. Пропели? Вспомнили? Пустили скупую мужскую слезу? Ото-ж!

 

Честно говоря, я пока ещё не оценил прелестей ни ООП, использование которого по моему разумению, может не только не сократить код, но даже увеличить его, ни, тем более, упомянутое Вами заумное функциональное программирование.
Для меня главное чтобы код был минимален, хорошо структурирован, комментирован и алгоритмически оптимизирован. Код дачника мне не понравился в первую очередь тем, что он, с моей точки зрения, именно алгоритмически топорно сделан. Создаётся впечатление что автора нимало не заботило то, что в каждой функции у него повторяются один в один по 7 совершенно одинаковых команд. Почему он не выделил их в отдельную функцию и просто не писал по одной строчке вместо 7?
Далее - да, там уже идут различия, присутствуют уникальные команды, и это наверное то, что Вы называете внутренней реализацией и как-то оформляете через ООП, но я бы просто ещё подработал алгоритм, чтобы такого было поменьше.
Я пока написал всю свою программу в канонической форме и у меня обращения к кнопкам и экрану занимают ничтожное место, я просто поражён как много они занимают у дачника - львиную долю программы, правда я использую всего лишь одну кнопку и у меня совсем другой алгоритм. Вот я и думаю, когда функций станет больше - не станет ли мой код напоминать код дачника? Не хотелось бы, но я считаю что очень много зависит от алгоритма

 

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

Ещё раз повторюсь - подходов масса, какой вам ближе - тот и используйте. Проблемы стоит решать только по мере поступления. И да - вы неправы в таком вот постулате:

ООП бывает разным - это раз. Например, если долго покорячиться и использовать шаблоны, то код будет даже меньше, чем просто самопально написанный - в этом прелесть инстанцирования на этапе компиляции. Потом - даже если код станет и больше - за удобства надо платить, это, так сказать, жирный старт. Если проект большой, то такой жирный старт сначала кажется избыточным, но, по мере разрастания проекта часто оказывается, что весь первоначальный задел мало чем сказывается на итоговом объёме кода.

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

Безусловно. Например, от применяемого алгоритма зависит быстродействие программы. Например, если алгоритм имеет сложность О (n), то он будет выполняться существенно дольше, чем алгоритм с O (log n), хотя и быстрее, чем O (n^2).

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

 

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

Если просто делать в лоб, последовательной переборкой всех элементов массива и сравнением с искомым значением, то нетрудно догадаться, что в самом худшем варианте мы потратим 1000 секунд (когда искомый элемент будет находиться в самом конце массива). То есть алгоритмическая сложность такого подхода - O (n).

Теперь применим другой способ: для начала отсортируем массив по возрастанию, а затем - применим бинарный поиск, т. е. поиск делением пополам. В этом случае, если мы ищем число 1000, то мы сделаем всего 5 итераций, то есть потратим, по условиям задачи, всего 5 секунд. Алгоритмическая сложность такого подхода - O (log n).

Как видите, вторым способом мы сможем выполнить задачу в 200 раз быстрее. И тут, кстати, выплывает моё упоминание про жирный старт. Допустим, что сортировка массива занимает 1000 секунд. Может - ну его нафиг, сортировать? Или лучше - сразу отсортировать, а потому уже просто экономить время?

З. Ы. И да - не ходите на ардуино_ру - там, по моему наблюдению, из адекватных только ЕвгенийП, остальные - с обострённым ЧСВ. Я туда захожу только почитать да поулыбаться, удивлён, как ЕвгенийП там выдерживает постоянное общение. Короче - очень специфический форум. Уж лучше на амперку заглянуть - там адекватных товарищей побольше.

 

В точку! Всё зависит от наших желаний. Скажем, Вы уважаете стандартность и универсальность, а я обожаю минимализм во всём, Вы сразу ставите Mega, а я - Uno с дальнейшей целью заменить её на Nano или Micro. Это разные цели, поэтому и пути оказываются разными. Я рад что Вы предоставляете идентность собеседнику независимо от уровня его подготовки.
Почему я тут на коде дачника заострился - я потому и решил разрабатывать контроллер, что увидел готовый прототип, который можно было использовать в крайнем случае, если не будет получаться у самого. Поначалу его код показался мне архисложным, поэтому я решил написать свой примитивный вариант, а затем сравнить. И вот, вчера я посмотрел код дачника и был шокирован. Функциональность у него ненамного превышает мою, однако объём кода больше в 4 раза. При этом львиную часть кода занимают библиотеки, так что самописный код будет отличаться не в 4, а в 10-20 раз. Можете представить моё разочарование! И заметьте, тут ни слова о причёсывании кода под стандарты структурного, функционального или объектного подхода, только алгоритм и ничего личного.
А я как деловой распечатал 14 страниц кода дачника для изучения... уже выбросил. Хотя в этой истории есть и приятный момент - я, только начав, уже кое-кого обскакал в плане написания экономичного кода, значит тоже чёй-то могу.

Ага, увидел Ваше дополнение про алгоритм. Ну да, я, собственно, именно об этом. - Алгоритм рулит и это может быть важнее всех парадигм программирования.

 

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

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

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

Весь смысл задумки именно в модульности, буде она пригодится при дальнейшем расширении функционала. На ардуинору мою тему обоср@ли, к слову - там вообще нельзя упоминать умные слова, типа OpenHAB и т. п.

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

 

Пока зима и слякотно - продолжаю мучить Мегу. Поддержка модуля опроса температуры есть? Есть. Поддержка получения состояния сторонних коробочек есть? Есть. Алерты есть? Нет!

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

Но что делать, если мне надо отслеживать событие изменения температуры (её выход за пределы значения), и при этом чтобы была возможность что-то сделать ещё? Допустим, изменилась температура на датчике в самом главном контроллере. И по этому изменению надо включить реле номер 1 у коробочки, которая стоит за 100 метров от контроллера. Шо делать, шеф? Фсьо пропало, шеф!

Неа, не всё. Потому как дарю я себе (и вам, конечно же), такую чудную вещь, как модуль алертов. Во-первых, опросить его можно вот так:

CTGET=ALERT|CNT

и от выведет кол-во сохраненных сработавших событий (сохраняются последние 3, по умолчанию)

А вот так можно посмотреть, какое событие сработало:

CTGET=ALERT|VIEW|0

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

Но это лирика, физика начинается гораздо интересней! Для начала тем, кто хочет поиграться - достаточно просто скачать прикреплённый файл, скомпилировать его в Arduino IDE и закачать в Мегу - кроме этого пока ничего не надо, т. к. изменения температуры я сделал случайными, чтоб чисто поиграться, что называется. Поэтому никаких датчиков подключать не надо - должно заработать и так.

Скачали? Прошили в Мегу? Открываем монитор порта, и вводим одну за одной три команды:

CTSET=0|ADD|M
CTSET=0|PROP|M|RELAY_CNT|2
CTSET=ALERT|RULE|TEMP|TEMP|0|>|38|CTSET=M|RELAY|0|ON

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

CTSET=ALERT|RULE|TEMP|TEMP|0|>|38|CTSET=M|RELAY|0|ON

Вся эта абракадабра значит дословно следующее

CTSET= - установить
ALERT - для модуля с именем "ALERT"
RULE - правило:
TEMP - если у модуля с именем TEMP
TEMP - показания температурного датчика
0 - с индексом 0
> - больше чем
38 - градусов
CTSET=M|RELAY|0|ON - выполнить эту команду, т. е.

CTSET= - установить
M - для модуля с именем M
RELAY - канал реле
0 - с индексом 0
ON - в положение "включено"

Как видите - всё просто. Если команда будет без связи с другим модулем, например, вот такая:

CTSET=ALERT|RULE|TEMP|TEMP|0|<|20

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

Пока поддерживается только слежение за температурой и команды "больше чем" и "меньше чем". Диапазонов нет, и не уверен, нужны ли они в моём случае.

Как видите - система становится чрезвычайно гибкой, и рулить ей можно натурно из любого места простыми текстовыми командами. Единственное "но" - хотелось бы иметь возможность сохранять алерты в EEPROM, и вычитывать их оттуда при старте. Ну и, конечно, добавлять/удалять из EEPROM по запросу извне. Но пока я эту мысль только думаю, потому как необходимости в динамическом добавлении алертов у меня ещё нет - этот инструмент я буду использовать как настроечный, для этапа старта микроконтроллера. Т. е. чисто для того, чтобы не программировать - а просто прописать в строке инициализации нужные команды, и модули сами собой свяжутся друг с другом, как надо. Надеюсь, не запутал такими объяснениями

В общем, играйтесь.

 

Дописал чуть - теперь контроллер выдаёт, есть ли изменения внутреннего состояния зарегистрированных модулей:

CTGET=0|HAS_CHANGES

И, конечно, можно пролистать изменения:

CTGET=0|LIST_CHANGES

Результаты ответа вот в таком формате:

MODULE_NAME|PROP_NAME|IDX|FROM|TO\r\n
MODULE_NAME|PROP_NAME|IDX|FROM|TO\r\n

список заканчивается двойным переводом строки (\r\n\r\n). Пока, понятное дело, поддерживаются только реле и температура, примерный ответ на команду CTGET=0|LIST_CHANGES такой:

OK=TEMP|TEMP|0|25,89|22,97
TEMP|RELAY|1|OFF|ON

Понятное дело, что сие означает: в модуле контроля температуры (модуль называется TEMP) изменились показания датчика с индексом 0 с 25,89 на 22,97. также в модуле TEMP изменилось состояние второго канала реле с "выключено" на "включено".

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

 

Думаю над упитанностью клиентов. Очень думаю. Поясню, что имею в виду: заказал для связи по Wi-Fi модули ESP8266, но, как показало беглое знакомство с его возможностями в интернете - на нём всё равно не поднять полноценный веб-сервер, любой тяжёлый браузер (типа того же файрфокса) нагнёт модуль запросами как нефиг делать - а ведь хочется иметь красивый дизайн веб-морды: чтобы тут тебе и картинки, и AJAX-запросы, и стили, и прочая хренотень. Забивать этим добром несчастный маленький модуль - как-то совсем не очень, мне кажется.

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

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

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

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

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

 

Ура, наконец-то пришли резисторы! А вот датчиков температуры пока на почте нет Не выдирать же из инкубатора - для тестов-то? Пущай уже растёт оттуда, куда пришит - нечего заниматься вивисекцией на ровном месте

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

Заодно надо бы начинать писать документацию - а то, боюсь, уже сам скоро заблужусь. Так что работы - непочатый край.