Узнайте, как характеристики сгенерированного кода и данных RAM/ROM влияют на метрику RAM/ROM.
Для получения информации о модели примера и других примерах в этой серии, смотрите Подготовьте модель алгоритма управления для генерации кода C.
Можно оценить сгенерированный код на основе двух основных метрик: скорости выполнения и использования памяти. В некоторых случаях улучшение одной метрики подразумевает жертву в другой метрике. Например, вы часто можете получить более быстрое выполнение, потребляя больше памяти.
Можно также классифицировать использование памяти как ПЗУ (память только для чтения) и ОЗУ (память с произвольным доступом).
Доступ к данным из ОЗУ происходит быстрее, чем доступ к данным из ПЗУ.
Исполняемые файлы и данные должны храниться в ПЗУ, поскольку ОЗУ не поддерживает данные между циклами степени.
Этот пример оценивает требования к памяти и разделяет использование памяти на компоненты функций и данных. Пример не оценивает скорость выполнения.
В этой оценке используется компилятор Freescale™ CodeWarrior ®.
Компилятор: Freescale™ CodeWarrior ®
Версия: 5.5.1.1430
Целевой процессор: Power PC 565
Как описано в Build Integrated Code Outside the Окружение Simulink и Test Generated Code, сгенерированный код может потребовать использования служебных функций. На служебные функции ложится разовая фиксированная стоимость памяти. Из-за этих фиксированных накладных расходов данные в этом примере показывают использование памяти для:
Алгоритмы: Код C, сгенерированный из блоков Simulink ® плюс функции определения данных
Утилиты: Функции, которые являются частью источника библиотеки Coder™ Simulink ®
Полный: Сумма как алгоритма, так и утилит
В трех аналитических отчетах в этом примере используется одно и то же строение сборки. Freescale™ CodeWarrior ® был настроен, чтобы минимизировать использование памяти и применить все применимые оптимизации.
Исходные файлы: PCG_Eval_File_1.zip
Тип данных: Все двойной точности
Включенные данные: Проект включает все данные, которые требуются сборке (включая данные, объявленные как extern: pos_rqst, fbk_1, и fbk_2)
Главная функция: Измененная версия example_main от сборки интегрированного кода за пределами окружения Simulink
Метод вызова функции: переиспользуемые функции для ПИ-контроллеров
Использование памяти
Function Data Algorithms 1172 bytes 549 bytes Utilities 592 bytes 40 bytes Full 1764 bytes 589 bytes
В этом строении данные модели используют тип данных с одной точностью с плавающей точностью вместо двойной точности.
Моделирование Строения
Исходные файлы: PCG_Eval_File_2.zip
Тип данных: Все синглы
Включенные данные: Проект включает все данные, которые требуются сборке (включая данные, объявленные как extern: pos_rqst, fbk_1, и fbk_2)
Главная функция: Измененная версия example_main от сборки интегрированного кода за пределами окружения Simulink
Метод вызова функции: переиспользуемые функции для ПИ-контроллеров
Использование памяти
Function Data Algorithms 800 bytes 308 bytes Utilities 592 bytes 40 bytes Full 1392 bytes 348 bytes
В этом строении используется только 56% памяти данных из первого строения: 308 байт вместо 549 байт. Это строение также использует 68% памяти функции: 800 байт вместо 1172 байт. Для этой системы использование одинарной точности вместо двойной точности не влияет на точность алгоритма управления, поэтому можно использовать это строение для достижения более эффективного кода.
Исходные файлы: PCG_Eval_File_3.zip
Тип данных: Все синглы
Включенные данные: Проект включает все данные, которые требуются сборке (включая данные, объявленные как extern: pos_rqst, fbk_1, и fbk_2)
Главная функция: Измененная версия example_main от сборки интегрированного кода за пределами окружения Simulink
Метод вызова функции: Интерфейс функции void void таким образом, обмен данными происходит через глобальные переменные
Использование памяти
Function Data Algorithms 948 bytes 348 bytes Utilities 592 bytes 40 bytes Full 1540 bytes 388 bytes
Это строение потребляет больше данных и памяти функций, чем предыдущее строение.
