В современном мире все большее распространение получают системы на основе встраиваемых процессоров, предназначенных для эффективного выполнения узкого класса задач в условиях жестких ограничений на соотношение производительности, энергопотребления и размера. Такие системы можно встретить практически в каждом электронном устройстве, начиная от бытовой техники и кончая самолетами и военными комплексами. При этом большую популярность приобретает подход к построению встраиваемых систем на основе готовых типовых решений, когда для исполнителей и систем управления выбираются существующие на рынке производительные контроллеры и с их помощью как из кирпичиков собираются новые устройства. При таком подходе один и то же контроллер повторно используется в системах различного назначения, существенно сокращая затраты на проектирование. При этом использование в качестве исполнителей специализированных для каждой системы расширений обеспечивает высокую техническую эффективность в смысле баланса указанных выше показател ей.
В процессе создания встраиваемых систем важнейшую роль играет инструментарий кросс-разработки, позволяющий выполнять разработку, отладку и профилирование программ для целевой системы с использованием инструментальной машины с отличной от целевой архитектурой. Основными компонентами такого инструментария являются ассемблер, компоновщик, симулятор, отладчик и профилировщик. В качестве инструментальной машины, как правило, выступает обычная рабочая станция. В отличие от производства реальных микросхем, для построения кросс-инструментария достаточно некоторого высокоуровневого описания целевой системы - прежде всего структуры памяти/регистров и системы команд с временными характеристиками исполнения. Это делает возможным раннее создание инструментария кросс-разработки еще в процессе проектирования аппаратуры. Использование кросс-инструментария на этом этапе играет ключевую роль при решении следующих задач:
Конечно, важно, чтобы после завершения проектирования аппаратуры полученные кросс-инструменты были пригодны для собственно производственного применения при дальнейшей разработке реальных приложений.
Рассмотрим известную обобщенную схему проектирования встраиваемой системы.
(рис 3.1) Обобщенная схема проектирования встраиваемой
На первом этапе происходит определение требований к системе. Определяются необходимые функциональные характеристики системы и задаются ограничения. Типовыми ограничениями являются быстродействие, энергопотребление, размер и стоимость изготовления кристаллов в рамках заданного технологического процесса производства микросхем.
На следующем этапе выполняется декомпозиция системы на аппаратные и программные компоненты (HW/SW partitioning). Принимаются решения об общей структуре системы (в первую очередь, число и характеристики вычислительных блоков) и выполняется отображение требуемой функциональности на программные и аппаратные части.
Далее процесс разделяется на две ветви - для проектирования программных и аппаратных компонентов. Выходом аппаратной ветви являются модели аппаратуры. В этой ветви принимаются решения об архитектуре выделенных в системе аппаратных вычислительных устройств. Для программируемых компонентов определяется состав функциональных блоков (включая внешние модули расширений для специфических вычислений), структура памяти (включая регистры) и система команд. Результатом проектирования программной части являются модели программных компонентов, совместимые с соответствующими аппаратными моделями.
Процесс носит итеративный характер, и точность описания моделей на каждой итерации постепенно повышается от высокоуровневых функциональных описаний до синтезируемых спецификаций аппаратуры и машинных кодов программ, соответствующих этой аппаратуре. Каждая итерация заканчивается интеграцией результатов программной и аппаратных ветвей, моделированием полученной системы, проверкой функциональной корректности и сбором соответствующих оценок ключевых параметров для их анализа с целью дальнейшей оптимизации. На основании полученных таким образом оценок принимаются решения о пересмотре декомпозиции между программными и аппаратными компонентами, о конкретных изменениях программ и аппаратуры, например, добавлении/удалении вычислительных блоков или оптимизации системы команд. Цикл повторяется до получения конкретных спецификаций программ и аппаратуры, которые совместно задают встраиваемую систему, удовлетворяющую всем заданным требованиям. Затем проводится верификация спецификаций, и цикл проектирования заверша ется подготовкой отчуждаемого продукта, пригодного для интеграции в более крупные проекты "систем на чипе" (SoC) или для запуска в отдельное производство. Такой продукт обычно включает в себя:
Существует много различных методов и средств автоматизации проектирования аппаратуры. В случае встраиваемых систем огромное внимание уделяется задаче оптимального разбиения системы на аппаратные и программные компоненты (HW/SW partitioning and codesign). Однако в данной главе ограничимся только рассмотрением создания и использования (кроме собственно основного назначения для разработки реальных программ) кросс-инструментария как средства получения дополнительных данных для поддержки принятия проектных решений в процессе проектирования аппаратуры (см. следующие разделы). Конкретные методы использования таких данных выходят за рамки данной статьи.
Целью использования кросс-инструментов является создание на инструментальной машине файла с двоичным образом (firmware) начального содержимого памяти (как машинные команды, так и данные) для целевой аппаратной системы. Такой файл затем используется для загрузки в конкретные целевые устройства.
В качестве языков программирования встраиваемых систем выступают обычно C (а также его расширенные подмножества типа Embedded C) и ассемблер. Ассемблер используется как в виде вставок в код на языке С, так и в виде отдельных ассемблерных модулей. В случае встраиваемых систем программирование на ассемблере остается важной составляющей создания программ ввиду, как правило, жестких требований к высокой производительности и малому объему программного кода.
На рис представлена типовая схема разработки программ с помощью кросс-инструментария.
Обычно процесс взаимодействия программиста с кросс-инструментами происходит через визуальную интегрированную среду разработки (IDE) со встроенным редактором, механизмами поддержки проектов, различными средствами управления и анализа результатов работы отдельных инструментов.
(рис 3.2)
Реальные программы обычно состоят из нескольких модулей, каждому из которых соответствует файл с исходными текстами программ (на языках высокого уровня или ассемблера). Компилятор транслирует модули на языке высокого уровня в промежуточные ассемблерные модули. Ассемблер отвечает за преобразование ассемблерных модулей (как написанных вручную, так и сгенерированных компилятором) в объектные модули с машинными кодами и данными для целевой аппаратуры. В качестве формата объектных модулей обычно используется ELF, включающий в себя различные секции (например, секции исполняемого кода, секции данных, секции с информацией о символах и секции с отладочной информацией). Компоновщик выполняет сборку нескольких объектных модулей в один абсолютный модуль с объединением соответствующих секций входных объектных файлов. При этом выполняются перемещения символов по абсолютным адресам памяти (автоматически или в соответствии с заданной программистом картой памяти) с соответствующими исправлениями зависящих от них кодов команд и значений данных. На этом заканчивается этап сборки программы. Полученный абсолютный модуль можно преобразовать в образ памяти для непосредственной загрузки в целевую аппаратуру с помощью программатора.
Для программиста взаимодействие с исполняемой моделью аппаратуры осуществляется через отладчик, который позволяет просматривать состояние модели (содержимое памяти, регистров, шин, сигналов) и осуществлять управляемое (в том числе, пошаговое) выполнение целевой программы на уровне отдельных команд или строчек исходного кода. Совместно с отладчиком используются различные виды профилировщиков и средств анализа, визуализирующих необходимые характеристики модели (как статические, так и времени исполнения) и соответствующие статистики. В качестве примеров можно привести:
В качестве модели целевой системы для кросс-отладчика чаще всего выступает симулятор, позволяющий моделировать целевую аппаратуру полностью на инструментальной машине. Существуют симуляторы различного уровня абстракции от функционального симулятора на уровне всей системы до симуляторов на уровне системы команд (в том числе потактово-точных) и симуляторов, эмулирующих точную структуру аппаратуры на уровне функциональных блоков и конкретных вентилей. В качестве симулятора в составе инструментария кросс-разработки обычно используется симулятор уровня системы команд (в том числе, с учетом конвейерных эффектов с потактовой точностью). Также отладчик может поддерживать отладку непосредственно аппаратной модели в виде реального чипа, подключаемой к инструментальной машине, что может иметь место на финальных стадиях проектирования и на стадии эксплуатации. Использование настоящей аппаратуры позволяет запускать программы в режиме реального времени, однако программный симулятор предоставляет гораздо больше воз можностей для отладки и анализа программ.
Разработка приложений для встроенных систем - частный случай так называемой кросс-разработки. В случае кросс-разработки платформа, для которой пишется приложение (целевая платформа, например, Linux ARM в виде смартфона) отличается от платформы, на которой работает программист и создается исполняемый код для целевой платформы (платформа разработчика, например, Linux x86 в виде обычного PC). В случае ОС Android аппаратная часть платформы может быть одинакова - x86, но способ разработки все равно останется кроссплатформенный. Мы рассмотрим четыре составляющих кроссплатформенной разработки - создание исполняемого кода, его запуск, отладка и интегрированные среды разработчика.
Наиболее важной частью кроссплатформенной разработки является набор инструментов для создания исполняемого кода. В него входит компилятор, компоновщик, другие утилиты, набор библиотек для целевой платформы - этого достаточно, чтобы создать исполняемый файл для целевой платформы. Обычно этот набор инструментов является частью или близким родственником GNU Compiler Collection, то есть применяются те же названия, те же ключи командной строки, те же приемы использования. Ниже приведен пример набора инструментов для архитектуры ARM:
[r...@v...]# ls -1 toolchain/arm-eabi-4.4.0/bin/ arm-eabi-ar arm-eabi-as arm-eabi-g++ arm-eabi-gcc arm-eabi-gdb arm-eabi-gprof arm-eabi-ld arm-eabi-objdump arm-eabi-ranlib arm-eabi-strings arm-eabi-strip
Для управления процессом сборки, документирования и т.п. можно использовать те же средства, что и для обычной разработки под Linux.
Запуск объектного кода может быть осуществлен разными способами. Самый естественный - запуск непосредственно на целевом устройстве. Для этого требуется само целевое устройство, подключенное к компьютеру разработчика по USB или Ethernet. Это наиболее надежный способ, но не всегда самый удобный. Финальное тестирование необходимо производить именно на целевом устройстве.
Альтернатива - установить целевую операционную систему на универсальную виртуальную машину на платформе разработчика. В качестве такой машины для Android рекомендуется Android Virtual Device, Virtual Box, также можно использовать VMWare. При этом надо учитывать, что по некоторым параметрам виртуальная машина может отличаться от реального устройства - например, по скорости работы, особенностям периферии и т. п.
Промежуточным вариантом является использование эмулятора, предоставляемого производителем целевой платформы. Фактически это разновидность виртуальной машины, которая, с одной стороны, максимально адаптирована для эмуляции целевой платформы, а с другой стороны, интегрирована со средствами разработки, например, IDE, которые также предоставляются производителем. Примером этого может послужить Intel® HAXM.
В настоящее время для запуска обычно не ограничиваются переносом на целевую платформу одного исполняемого файла, а формируют целый пакет со всеми зависимостями и правилами установки (например, APK для Android или RPM для MeeGo), который затем устанавливается на целевой платформе. С помощью такого же пакета финальная версия приложения попадает на устройства конечных пользователей. Это, с одной стороны, увеличивает переносимость приложения и облегчает запуск сложных приложений, с другой - слегка усложняет и удлиняет процедуру запуска.
При кроссплатформенной разработке процедура отладки приложения изменяется не сильно. Описанный выше gdb можно использовать и для кросс-отладки. Для этого на целевой платформе отлаживаемое приложение запускается из-под gdbserver:
gdbserver host:port exe [args …]
На платформе разработчика запускается gdb и в его консоли устанавливается связь с gdbserver:
target remote host:port
gdb устанавливает соединение с gdbserver согласно указанным host:port и после этого программист может проводить сеанс отладки как в обычном gdb. При использовании интегрированной среды разработки все эти детали взаимодействия gdb скрыты от программиста - зачастую, глядя на экран платформы разработчика, невозможно определить, происходит отладка локально или на целевой платформе.
Еще одним популярным способом отладки при кроссплат-форменной разработке является полный отказ от gdb и интенсивное использование логов.
Современные IDE, такие как QtCreator или Eclipse, поддерживают кросс-платформенную разработку. Эта поддержка может быть встроенной или реализовываться в виде плагинов. В любом случае IDE берут на себя львиную долю организационной работы, освобождая программисту время для творчества. Внешне процесс кросс-разработки с использованием IDE практически не отличается от обычного.
В современном мире все большее распространение получают системы на основе встраиваемых процессоров, предназначенных для эффективного выполнения узкого класса задач в условиях жестких ограничений на соотношение производительности, энергопотребления и размера. Такие системы можно встретить практически в каждом электронном устройстве, начиная от бытовой техники и кончая самолетами и военными комплексами. При этом большую популярность приобретает подход к построению встраиваемых систем на основе готовых типовых решений, когда для исполнителей и систем управления выбираются существующие на рынке производительные контроллеры и с их помощью как из кирпичиков собираются новые устройства. При таком подходе один и то же контроллер повторно используется в системах различного назначения, существенно сокращая затраты на проектирование. При этом использование в качестве исполнителей специализированных для каждой системы расширений обеспечивает высокую техническую эффективность в смысле баланса указанных выше показател ей.
В процессе создания встраиваемых систем важнейшую роль играет инструментарий кросс-разработки, позволяющий выполнять разработку, отладку и профилирование программ для целевой системы с использованием инструментальной машины с отличной от целевой архитектурой. Основными компонентами такого инструментария являются ассемблер, компоновщик, симулятор, отладчик и профилировщик. В качестве инструментальной машины, как правило, выступает обычная рабочая станция. В отличие от производства реальных микросхем, для построения кросс-инструментария достаточно некоторого высокоуровневого описания целевой системы - прежде всего структуры памяти/регистров и системы команд с временными характеристиками исполнения. Это делает возможным раннее создание инструментария кросс-разработки еще в процессе проектирования аппаратуры. Использование кросс-инструментария на этом этапе играет ключевую роль при решении следующих задач:
Конечно, важно, чтобы после завершения проектирования аппаратуры полученные кросс-инструменты были пригодны для собственно производственного применения при дальнейшей разработке реальных приложений.
Рассмотрим известную обобщенную схему проектирования встраиваемой системы.
(рис 3.1) Обобщенная схема проектирования встраиваемой
На первом этапе происходит определение требований к системе. Определяются необходимые функциональные характеристики системы и задаются ограничения. Типовыми ограничениями являются быстродействие, энергопотребление, размер и стоимость изготовления кристаллов в рамках заданного технологического процесса производства микросхем.
На следующем этапе выполняется декомпозиция системы на аппаратные и программные компоненты (HW/SW partitioning). Принимаются решения об общей структуре системы (в первую очередь, число и характеристики вычислительных блоков) и выполняется отображение требуемой функциональности на программные и аппаратные части.
Далее процесс разделяется на две ветви - для проектирования программных и аппаратных компонентов. Выходом аппаратной ветви являются модели аппаратуры. В этой ветви принимаются решения об архитектуре выделенных в системе аппаратных вычислительных устройств. Для программируемых компонентов определяется состав функциональных блоков (включая внешние модули расширений для специфических вычислений), структура памяти (включая регистры) и система команд. Результатом проектирования программной части являются модели программных компонентов, совместимые с соответствующими аппаратными моделями.
Процесс носит итеративный характер, и точность описания моделей на каждой итерации постепенно повышается от высокоуровневых функциональных описаний до синтезируемых спецификаций аппаратуры и машинных кодов программ, соответствующих этой аппаратуре. Каждая итерация заканчивается интеграцией результатов программной и аппаратных ветвей, моделированием полученной системы, проверкой функциональной корректности и сбором соответствующих оценок ключевых параметров для их анализа с целью дальнейшей оптимизации. На основании полученных таким образом оценок принимаются решения о пересмотре декомпозиции между программными и аппаратными компонентами, о конкретных изменениях программ и аппаратуры, например, добавлении/удалении вычислительных блоков или оптимизации системы команд. Цикл повторяется до получения конкретных спецификаций программ и аппаратуры, которые совместно задают встраиваемую систему, удовлетворяющую всем заданным требованиям. Затем проводится верификация спецификаций, и цикл проектирования заверша ется подготовкой отчуждаемого продукта, пригодного для интеграции в более крупные проекты "систем на чипе" (SoC) или для запуска в отдельное производство. Такой продукт обычно включает в себя:
Существует много различных методов и средств автоматизации проектирования аппаратуры. В случае встраиваемых систем огромное внимание уделяется задаче оптимального разбиения системы на аппаратные и программные компоненты (HW/SW partitioning and codesign). Однако в данной главе ограничимся только рассмотрением создания и использования (кроме собственно основного назначения для разработки реальных программ) кросс-инструментария как средства получения дополнительных данных для поддержки принятия проектных решений в процессе проектирования аппаратуры (см. следующие разделы). Конкретные методы использования таких данных выходят за рамки данной статьи.
Целью использования кросс-инструментов является создание на инструментальной машине файла с двоичным образом (firmware) начального содержимого памяти (как машинные команды, так и данные) для целевой аппаратной системы. Такой файл затем используется для загрузки в конкретные целевые устройства.
В качестве языков программирования встраиваемых систем выступают обычно C (а также его расширенные подмножества типа Embedded C) и ассемблер. Ассемблер используется как в виде вставок в код на языке С, так и в виде отдельных ассемблерных модулей. В случае встраиваемых систем программирование на ассемблере остается важной составляющей создания программ ввиду, как правило, жестких требований к высокой производительности и малому объему программного кода.
На рис представлена типовая схема разработки программ с помощью кросс-инструментария.
Обычно процесс взаимодействия программиста с кросс-инструментами происходит через визуальную интегрированную среду разработки (IDE) со встроенным редактором, механизмами поддержки проектов, различными средствами управления и анализа результатов работы отдельных инструментов.
(рис 3.2)
Реальные программы обычно состоят из нескольких модулей, каждому из которых соответствует файл с исходными текстами программ (на языках высокого уровня или ассемблера). Компилятор транслирует модули на языке высокого уровня в промежуточные ассемблерные модули. Ассемблер отвечает за преобразование ассемблерных модулей (как написанных вручную, так и сгенерированных компилятором) в объектные модули с машинными кодами и данными для целевой аппаратуры. В качестве формата объектных модулей обычно используется ELF, включающий в себя различные секции (например, секции исполняемого кода, секции данных, секции с информацией о символах и секции с отладочной информацией). Компоновщик выполняет сборку нескольких объектных модулей в один абсолютный модуль с объединением соответствующих секций входных объектных файлов. При этом выполняются перемещения символов по абсолютным адресам памяти (автоматически или в соответствии с заданной программистом картой памяти) с соответствующими исправлениями зависящих от них кодов команд и значений данных. На этом заканчивается этап сборки программы. Полученный абсолютный модуль можно преобразовать в образ памяти для непосредственной загрузки в целевую аппаратуру с помощью программатора.
Для программиста взаимодействие с исполняемой моделью аппаратуры осуществляется через отладчик, который позволяет просматривать состояние модели (содержимое памяти, регистров, шин, сигналов) и осуществлять управляемое (в том числе, пошаговое) выполнение целевой программы на уровне отдельных команд или строчек исходного кода. Совместно с отладчиком используются различные виды профилировщиков и средств анализа, визуализирующих необходимые характеристики модели (как статические, так и времени исполнения) и соответствующие статистики. В качестве примеров можно привести:
В качестве модели целевой системы для кросс-отладчика чаще всего выступает симулятор, позволяющий моделировать целевую аппаратуру полностью на инструментальной машине. Существуют симуляторы различного уровня абстракции от функционального симулятора на уровне всей системы до симуляторов на уровне системы команд (в том числе потактово-точных) и симуляторов, эмулирующих точную структуру аппаратуры на уровне функциональных блоков и конкретных вентилей. В качестве симулятора в составе инструментария кросс-разработки обычно используется симулятор уровня системы команд (в том числе, с учетом конвейерных эффектов с потактовой точностью). Также отладчик может поддерживать отладку непосредственно аппаратной модели в виде реального чипа, подключаемой к инструментальной машине, что может иметь место на финальных стадиях проектирования и на стадии эксплуатации. Использование настоящей аппаратуры позволяет запускать программы в режиме реального времени, однако программный симулятор предоставляет гораздо больше воз можностей для отладки и анализа программ.
Разработка приложений для встроенных систем - частный случай так называемой кросс-разработки. В случае кросс-разработки платформа, для которой пишется приложение (целевая платформа, например, Linux ARM в виде смартфона) отличается от платформы, на которой работает программист и создается исполняемый код для целевой платформы (платформа разработчика, например, Linux x86 в виде обычного PC). В случае ОС Android аппаратная часть платформы может быть одинакова - x86, но способ разработки все равно останется кроссплатформенный. Мы рассмотрим четыре составляющих кроссплатформенной разработки - создание исполняемого кода, его запуск, отладка и интегрированные среды разработчика.
Наиболее важной частью кроссплатформенной разработки является набор инструментов для создания исполняемого кода. В него входит компилятор, компоновщик, другие утилиты, набор библиотек для целевой платформы - этого достаточно, чтобы создать исполняемый файл для целевой платформы. Обычно этот набор инструментов является частью или близким родственником GNU Compiler Collection, то есть применяются те же названия, те же ключи командной строки, те же приемы использования. Ниже приведен пример набора инструментов для архитектуры ARM:
[r...@v...]# ls -1 toolchain/arm-eabi-4.4.0/bin/ arm-eabi-ar arm-eabi-as arm-eabi-g++ arm-eabi-gcc arm-eabi-gdb arm-eabi-gprof arm-eabi-ld arm-eabi-objdump arm-eabi-ranlib arm-eabi-strings arm-eabi-strip
Для управления процессом сборки, документирования и т.п. можно использовать те же средства, что и для обычной разработки под Linux.
Запуск объектного кода может быть осуществлен разными способами. Самый естественный - запуск непосредственно на целевом устройстве. Для этого требуется само целевое устройство, подключенное к компьютеру разработчика по USB или Ethernet. Это наиболее надежный способ, но не всегда самый удобный. Финальное тестирование необходимо производить именно на целевом устройстве.
Альтернатива - установить целевую операционную систему на универсальную виртуальную машину на платформе разработчика. В качестве такой машины для Android рекомендуется Android Virtual Device, Virtual Box, также можно использовать VMWare. При этом надо учитывать, что по некоторым параметрам виртуальная машина может отличаться от реального устройства - например, по скорости работы, особенностям периферии и т. п.
Промежуточным вариантом является использование эмулятора, предоставляемого производителем целевой платформы. Фактически это разновидность виртуальной машины, которая, с одной стороны, максимально адаптирована для эмуляции целевой платформы, а с другой стороны, интегрирована со средствами разработки, например, IDE, которые также предоставляются производителем. Примером этого может послужить Intel® HAXM.
В настоящее время для запуска обычно не ограничиваются переносом на целевую платформу одного исполняемого файла, а формируют целый пакет со всеми зависимостями и правилами установки (например, APK для Android или RPM для MeeGo), который затем устанавливается на целевой платформе. С помощью такого же пакета финальная версия приложения попадает на устройства конечных пользователей. Это, с одной стороны, увеличивает переносимость приложения и облегчает запуск сложных приложений, с другой - слегка усложняет и удлиняет процедуру запуска.
При кроссплатформенной разработке процедура отладки приложения изменяется не сильно. Описанный выше gdb можно использовать и для кросс-отладки. Для этого на целевой платформе отлаживаемое приложение запускается из-под gdbserver:
gdbserver host:port exe [args …]
На платформе разработчика запускается gdb и в его консоли устанавливается связь с gdbserver:
target remote host:port
gdb устанавливает соединение с gdbserver согласно указанным host:port и после этого программист может проводить сеанс отладки как в обычном gdb. При использовании интегрированной среды разработки все эти детали взаимодействия gdb скрыты от программиста - зачастую, глядя на экран платформы разработчика, невозможно определить, происходит отладка локально или на целевой платформе.
Еще одним популярным способом отладки при кроссплат-форменной разработке является полный отказ от gdb и интенсивное использование логов.
Современные IDE, такие как QtCreator или Eclipse, поддерживают кросс-платформенную разработку. Эта поддержка может быть встроенной или реализовываться в виде плагинов. В любом случае IDE берут на себя львиную долю организационной работы, освобождая программисту время для творчества. Внешне процесс кросс-разработки с использованием IDE практически не отличается от обычного.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.