О разработке целевого процессора

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

Чтобы реализовать цель на основе ARM® Cortex®-A или процессора ARM Cortex-M, установите соответствующий пакет поддержки и смотрите Целевой SDK: Embedded Coder® Support Package для процессоров ARM Cortex-A, Разработайте Цель (Пакет Поддержки Embedded Coder для процессоров ARM Cortex-A) или Пакет Поддержки Embedded Coder для процессоров ARM Cortex-M, Разработайте Цель (Пакет Поддержки Embedded Coder для процессоров ARM Cortex-M). В противном случае используйте эти функции и темы.

Пользовательские цели

Вы можете хотеть реализовать пользовательскую цель по одной из следующих причин:

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

  • Поддерживать устройства ввода-вывода на целевом компьютере путем слияния блоков драйверов отдельного устройства в модели.

  • Сконфигурировать процесс сборки для специального компилятора (такого как кросс-компилятор для встроенного микроконтроллера или Платы DSP) или разработка/среда отладки.

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

Типы целей

Следующие разделы описывают несколько типов целей, предназначенных для различных вариантов использования

О целевых типах

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

Обсуждение целевых типов сопровождается Рекомендуемыми Функциями Целевых процессоров, который содержит предложенный список функций и общие руководящие принципы для разработки целевого процессора.

Цели быстрого прототипирования

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

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

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

Производственные платформы

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

Желательные функции производственной платформы включают:

  • Значительная поддержка драйвера ввода-вывода, оказанная из поля

  • Легкая загрузка сгенерированных программ независимого исполняемого файла со сторонними отладчиками

  • Управляемое пользователями размещение исполняемого файла во Флэш-памяти или Оперативной памяти

  • Поддержка видимости кода и настраивающийся на целевом компьютере

Проверка целей с SIL и PIL симуляцией

Можно использовать программное обеспечение в цикле (SIL) или процессоре в цикле (PIL) симуляция, чтобы проверить сгенерированный код и подтвердить целевую среду компилятора/процессора.

Можно использовать SIL и режимы PIL симуляции, чтобы проверить автоматически сгенерированный код путем сравнения результатов с симуляцией режима normal mode. С SIL можно легко проверить поведение поглощенного производством исходного кода на хосте - компьютере; однако, обычно не возможно проверить точно тот же код, который будет впоследствии скомпилирован для вашего целевого компьютера, потому что код должен быть скомпилирован для вашей серверной платформы (т.е. различный компилятор и различная архитектура процессора, чем цель). С PIL симуляцией можно проверить точно тот же код, который вы намереваетесь развернуть в производстве, и можно запустить код или на действительном целевом компьютере или на симуляторе процессора.

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

Для получения дополнительной информации о SIL и PIL симуляции, см. SIL и PIL симуляции.

Программно-аппаратная симуляция

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

Рекомендуемые функции целевых процессоров

Основные целевые функции

  • Можно основывать цели на цели типового в реальном времени (GRT) или цели Встроенного в реальном времени (ERT), которая включена в продукт Embedded Coder.

    Если ваша цель основана на цели ERT, она должна использовать 'Embedded-C' значение для CodeFormat Переменная TLC, и это должно наследовать опции, заданные в системном конечном файле цели ERT со следующими линиями в файле TLC:

    %% Assign code format
    %assign CodeFormat = "Embedded-C"
    %%----------------------------
    /%
      BEGIN_RTW_OPTIONS
      rtwgensettings.DerivedFrom = 'ert.tlc';
      END_RTW_OPTIONS
    %/
    %%----------------------------
    

    Следующим эти рекомендации ваша цель имеет возможности генерации производственного кода цели ERT.

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

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

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

    Для получения информации об основанном на прерывании по таймеру выполнении смотрите Расчет Абсолютного и Прошедшего времени (Simulink Coder) и Асинхронные События (Simulink Coder).

  • Необходимо сгенерировать основной программный модуль целевого исполняемого файла, вместо того, чтобы использовать статический основной модуль (такой как статический rt_main.c или rt_cppclass_main.cpp модуль, которому предоставляют программное обеспечение). Сгенерированный main.c или .cpp может быть сделан намного более читаемым и более эффективным, поскольку это не использует проверки препроцессора и другой дополнительный код.

    Для получения информации о сгенерированных и статических основных программных модулях смотрите, Развертывают Сгенерированные Программы Независимого исполняемого файла В Целевой компьютер.

  • Следуйте инструкциям в Соглашениях о присвоении имен Папки и Файла.

Интеграция с целевыми средами разработки

  • Большинство систем кросс-разработки запущено под хостом Microsoft® Windows® PC. Ваша цель должна поддержать операционную систему Windows как серверную среду.

    Некоторые системы кросс-разработки поддерживают одну или несколько версий платформ Open Group UNIX®, допуская поддержку хоста UNIX также.

  • Ваш целевой процессор должен поддержать по крайней мере одну встроенную среду разработки. Интерфейс к среде разработки может принять одну из нескольких форм. Подход набора инструментальных средств и подход make-файла шаблона генерируют стандартные make-файлы, чтобы работать с вашей средой разработки. Для получения общей информации об этих подходах сборки, смотрите, Выбирают Build Approach и Configure Build Process (Simulink Coder). Для получения дальнейшей информации о структуре make-файлов шаблона, смотрите, Настраивают Make-файлы Шаблона.

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

Наблюдение подписания целевого кода

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

    Можно использовать rtiostream API, чтобы реализовать канал связи, чтобы включить обмен данными между различными процессами. Для примера создания канала связи для целевой возможности соединения смотрите, Создают Целевой Канал связи для Процессора В Цикле (PIL) Симуляция. Этот rtiostream канал связи требуется, чтобы включать процессор в цикле (PIL) на новой цели. Смотрите Коммуникации rtiostream API.

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

    Другая опция должна поддержать симуляцию режима external mode Simulink®. Для получения дополнительной информации смотрите Симуляции Режима external mode для Настройки Параметра и Контроля сигналов (Simulink Coder).

Проблемы развертывания и аппаратные проблемы

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

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

    См. драйверы устройств (Simulink Coder).

  • Автоматическая загрузка сгенерированного кода к целевому компьютеру делает цель легче использовать. Обычно утилита отладчика используется; если выбранный отладчик поддерживает файлы командного сценария, это может быть прямо, чтобы реализовать. STF_make_rtw_hook.m описывает механизм, чтобы выполнить код от процесса сборки. Можно использовать этот механизм, чтобы сделать system() вызовы, чтобы вызвать утилиты, такие как отладчик. Можно вызвать другие простые утилиты загрузки подобным способом.

  • Исполняемые файлы, которые сопоставлены с Оперативной памятью, типичны. Можно оказать дополнительную поддержку для Flash или размещения RAM исполняемого файла при помощи опций генерации кода цели. Чтобы поддержать эту возможность, вам могут быть нужны несколько командных файлов компоновщика, несколько скриптов отладчика, и возможно несколько make-файлов или файлов проекта. Также включайте способность автоматически переключиться между этими файлами, в зависимости от значения опции RAM/FLASH.

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

Похожие темы

Для просмотра документации необходимо авторизоваться на сайте