Optimizing CC2530 Z-Stack 3.0.2 Flash and RAM

SWRA635–October 2018

Этот документ призван помочь разработчикам оптимизировать использование флэш-памяти и оперативной памяти Z-Stack 3.0.2 при разработке собственного приложения с использованием платформы CC2530. Также будут описаны некоторые ограничения использования устройства CC2530 в качестве конфигурации устройства Zigbee Coordinator из-за зависимостей RAM. В качестве примера будет использоваться проект SampleSwitch Router из Z-Stack 3.0.2.

Скачать оригинал (eng)

 

 

 

 

 

1. Начальный размер кода Out-of-Box

Z-Stack 3.0.2 можно загрузить со страницы инструмента Texas Instruments ™ Z-STACK, после чего он будет расположен по умолчанию в C: \ Texas Instruments. Первым шагом является загрузка рабочей области проекта CC2530 в IAR EW 8051 v10.20. Это достигается путем выбора File> Open Workspace и поиска нужного файла рабочего пространства, в данном случае SampleSwitch.eww находится здесь:

C: \ Texas Instruments \ Z-Stack 3.0.2 \ Projects \ zstack \ HomeAutomation \ SampleSwitch \ CC2530DB

Затем выберите Project -> Configuration и выберите параметр Router, а затем Project > Make (или F7), чтобы собрать проект маршрутизатора SampleSwitch из Z-Stack 3.0.2 без каких-либо изменений. После сборки кода обратитесь к нижней части файла .map (расположенного в папке вывода), чтобы увидеть начальную точку занимаемой памяти:
 
239 555 bytes of CODE memory
32 bytes of DATA memory (+ 68 absolute )
7 425 bytes of XDATA memory
192 bytes of IDATA memory
8 bits of BIT memory
1 867 bytes of CONST memory
 
Важные числа в этом списке - это память CODE и XDATA, которые соответствуют Flash и RAM соответственно.
 

2. Оптимизация Flash

2.1 Удаление примера пользовательского интерфейса

Пользовательский интерфейс (UI), который предоставляется с примерами приложений Z-Stack 3.0.2, предоставляет средства для простого запуска и запуска сети, просмотра состояния сети на ЖК-дисплее и изменения параметров ввода в эксплуатацию сети во время выполнения. Однако он также занимает много места в коде, и разработчикам нет необходимости хранить их в своих собственных приложениях.
 
Чтобы удалить этот интерфейс, необходимо сделать три вещи:
  • Исключить файлы пользовательского интерфейса из компиляции
  • Удалите вызовы API к функциям пользовательского интерфейса в файлах примеров приложений.
  • Измените флаги компиляции проекта, чтобы исключить драйверы, связанные с ЖК-дисплеем.

2.1.1 Исключить файлы пользовательского интерфейса

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

Рисунок 1. Исключение zcl_sampleapps_ui.c из сборки

2.1.2 Удаление вызовов API к функциям пользовательского интерфейса

В zcl_samplesw.c есть различные вызовы API пользовательского интерфейса, которые мы должны удалить. Найдите в этом файле "UI_" и закомментируйте или полностью удалите этот код. Пример этого:

void zclSampleSw_Init( byte task_id )

{
  ...
  // UI_Init(zclSampleSw_TaskID, SAMPLEAPP_LCD_AUTO_UPDATE_EVT, SAMPLEAPP_KEY_AUTO_REPEAT_EVT,
  // &zclSampleSw_IdentifyTime, APP_TITLE, &zclSampleSw_UiUpdateLcd, zclSampleSw_UiStatesMain);
  // UI_UpdateLcd();
}

Все функции "UI_" должны быть удалены, иначе возникнут ошибки сборки, поскольку они находятся в исключенном файле zcl_sampleapps_ui.c.

2.1.3 Измените флаги компиляции, чтобы исключить драйверы, связанные с ЖК-дисплеем

К флагам компиляции проекта можно получить доступ, перейдя в Project Options, а затем перейдя в C/C++ Compiler > Preprocessor > Defined symbols. Отсюда можно сделать следующие изменения, связанные с ЖК-дисплеем:
  • Удалить LCD_SUPPORTED = DEBUG.
  • Добавить HAL_LCD = FALSE
Рисунок 2. Доступ к символам, определенным препроцессором
 

2.2 Удаление / изменение файлов драйверов

Некоторые драйверы включены по умолчанию в примеры приложений Z-Stack, которые могут не понадобиться для пользовательского приложения. Например, чтобы удалить драйвер ADC, перейдите в Project Options и перейдите в C/C++ Compiler > Preprocessor > Defined symbols, а затем добавьте HAL_ADC = FALSE флаг компиляции.

2.3 Изменение количества доступных виртуальных регистров

Это небольшая оптимизация CC2530 для конкретного устройства, которая позволяет сэкономить несколько сотен байтов Flash. Перейдите в Project Options и перейдите в General Options > Target > Number of virtual registers. По умолчанию это значение установлено на 16, но более оптимальное значение, найденное для проектов Z-Stack, было 24. Можно предпринять попытки изменить это значение на различные размеры и посмотреть, какой размер кода будет наименьшим.
Рисунок 3. Изменение количества виртуальных регистров

2.4 Рекомендации по поддержке кластера ZCL

Убедитесь, что в приложении отсутствуют кластеры ZCL, которые не нужны ни для типа устройства, ни для сертификации Zigbee. Например, в проекте SampleSwitch Router кластер ZCL_GROUPS по умолчанию включен во флаги компиляции проекта. Согласно спецификации Zigbee Lighting & Occupancy Device Specification, этот кластер является дополнительным кластером и, таким образом, может быть удален из Компилятора C/C++ Compiler > Preprocessor > Defined symbols из Project Options. Используйте спецификацию Zigbee Cluster Library v6, Zigbee Lighting & Occupancy Device Specification и спецификация Zigbee Home Automation Profile (все они доступны на веб-сайте альянса Zigbee), чтобы определить, какие кластеры должно поддерживать выбранное устройство Zigbee.

2.5 Замечания BDB_Repor​ting 

Функция отправки отчета об атрибутах в спецификации Zigbee 3.0 является обязательной функцией для определенных типов устройств, которые поддерживают определенные кластеры. Например, устройство Zigbee On/Off Light должно поддерживать Client Side кластера On/Off Cluster. Он должен поддерживать атрибут "OnOff", и согласно спецификации ZCL v6 этот атрибут должен быть отчетным. Если приложение будет поддерживать какие-либо атрибуты кластера с отчетным типом доступа (согласно спецификации ZCL v6), флаг компиляции BDB_REPORTING должен быть включен в приложение. В Z-Stack есть 4 отдельных макроса, которые связаны с отчетами ZCL:
  1. BDB_REPORTING: определяет механизм отчетов BDB, который добавляет функцию отправки отчетов.
  2. ZCL_REPORTING_DEVICE: определяет устройство, отправляющее отчеты.
  3. ZCL_REPORT_DESTINATION_DEVICE: включает функцию получения / обработки отчетов в коде вашего приложения.
  4. ZCL_REPORT_CONFIGURING_DEVICE: включает конфигурацию параметров отчетов на удаленных устройствах.
Функция BDB_REPORTING увеличивает размер флэш-памяти примерно на 9 КБ. Этот механизм использует функции, которые определены в zcl.c под флагом компиляции ZCL_REPORTING_DEVICE, поэтому, когда BDB_REPORTING определяется, то ZCL_REPORTING_DEVICE также определяется автоматически. BDB_REPORTING, однако, не определяет автоматически два других флага компиляции, ZCL_REPORT_DESTINATION_DEVICE и ZCL_REPORT_CONFIGURING_DEVICE, которые необходимо добавить отдельно, если требуется их функциональность. Несмотря на то, что это небольшие функции, каждая менее 1 КБ Flash, если устройству не требуется функция отправки отчетов (устройство не поддерживает кластеры, которые имеют обязательные атрибуты, подлежащие отчету согласно спецификации ZCL), нет необходимости тратить 9 КБ. Flash, необходимого для функции отправки отчетов BDB, чтобы поддерживать обработку отчетов и / или конфигурацию отчетов.

3.1 Драйвер UART

Если приложению необходим UART, он добавляется с помощью флага компиляции HAL_UART. По умолчанию драйвер UART использует 256-байтовые буферы TX и RX, которые в совокупности занимают 1 КБ ОЗУ. Использование UART с меньшими размерами буфера возможно путем изменения флага компиляции HAL_UART_DMA_RX_MAX = 128. Добавление этого к определенным символам изменит размер буферов RX и TX с 256 до 128 байтов и приведет к экономии ОЗУ ~ 500 байтов. Но один недостаток, который необходимо учитывать, заключается в том, содержит ли связь большие пакеты данных, например, интерфейс монитора и тестирования (MT), для которого разрешена длина фреймов не более 253 байтов. В этих обстоятельствах размер буфера должен оставаться равным значению по умолчанию.
 

3.2 Размеры списка устройств

На устройствах маршрутизации Zigbee (координаторах и маршрутизаторах) присутствуют два списка устройств, которые занимают статически выделенный объем ОЗУ во время компиляции:
  • • NWK_MAX_DEVICE_LIST
    • Определяет количество поддерживаемых напрямую подключенных дочерних устройств
    • Каждая запись в этой таблице составляет 28 байт ОЗУ.
    • Размер по умолчанию - 20
  • • MAX_NEIGHBOR_ENTRIES
    • Определяет количество "соседних" устройств, которое используется в рамках процедуры маршрутизации сетки Zigbee. Больше соседей <==> лучше ячеистая сеть.
    • Каждая запись в этой таблице составляет 23 байта ОЗУ.
    • Значение по умолчанию - 16
Чтобы переопределить размер одного или обоих этих списков, значения по умолчанию можно изменить в NWK / nwk_globals.h или добавить в Определенные символы (например, NWK_MAX_DEVICE_LIST = 15).
Рисунок 4. Размеры списка устройств по умолчанию
 

3.3 Размер кучи

Размер кучи можно настроить, изменив значение INT_HEAP_LEN, которое по умолчанию составляет 3072 байта ОЗУ для устройств маршрутизации в ZMain/OnBoard.h. Измените значение здесь или добавьте его в Определенные символы (например, INT_HEAP_LEN = 2688).

3.4 Размер стека

Размер стека можно настроить, изменив значение стека XDATA, которое определено в параметрах проекта IAR. Откройте Project Options и перейдите в General Options > Stack/Heap > Stack Sizes > XDATA.
Рисунок 5. Изменение размера стека
По умолчанию это значение составляет 0x400 или 1024 байта ОЗУ, но 0x300 считается подходящим для большинства основных приложений Z-Stack.
 

4. Оптимизация размера кода

В качестве примера экономии места для кода в проект SampleSwitch Router были внесены следующие изменения:
  • Удален пользовательский интерфейс.
  • Удален драйвер АЦП.
  • Удален кластер ZCL_GROUPS.
  • Оптимизированное количество виртуальных регистров
  • Уменьшена куча до 2688 байт.
  • Уменьшен NWK_MAX_DEVICE_LIST до 15 устройств.
  • Уменьшено MAX_NEIGHBOR_ENTRIES до 10 устройств.
Цифры ниже отражают размер сборки нового проекта:
225 182 bytes of CODE memory
40 bytes of DATA memory (+ 59 absolute )
6 435 bytes of XDATA memory
192 bytes of IDATA memory
8 bits of BIT memory
660 bytes of CONST memory
В общей сложности было сэкономлено более 14 КБ флэш-памяти и около 1 КБ ОЗУ по сравнению с его оригинальным аналогом. Это оставляет около 37 КБ флэш-памяти и 1750 байт ОЗУ, доступных для расширения приложений.

5. Ограничения конфигурации координатора CC2530 Zigbee

За счет реализации тех же оптимизаций, что и раньше, конфигурация координатора SampleSwitch использует 6762 байта памяти XDATA на устройстве CC2530, что оставляет 1430 доступных байтов ОЗУ. Это дополнительное увеличение объема памяти по сравнению с устройством-маршрутизатором в первую очередь связано с ZDSECMGR_TC_DEVICE_MAX (по умолчанию 40 из ZDO / ZDSecMgr.h), который выделяет 8 энергонезависимых
(NV) байтов на ключ APS. В качестве Zigbee 3.0 Trust Center (TC) координатор должен хранить эти ключи для управления сетевой безопасностью, и, таким образом, ZDSECMGR_TC_DEVICE_MAX определяет количество устройств, которым разрешено подключаться к сети.
Кроме того, если требуется, чтобы координатор действовал как концентратор данных Many-to-One (MTO), который записывает обнаружение сетевого маршрута (путем установки CONCENTRATOR_ENABLE и CONCENTRATOR_ROUTE_CACHE значения true в NWK / ZGlobals.h), тогда XDATA будет дополнительно заполнен MAX_RTG_SRC_ENTRIES из NWK / nwk_globals.h, значение по умолчанию 12 и требует 6 байтов RAM на запись. Также необходимо учитывать, что размер кучи должен быть увеличен для размещения указателя списка ретрансляторов, который хранится как последний элемент каждой записи исходной таблицы маршрутов.
Для передачи этой информации через интерфейс MT в качестве сетевого процессора Zigbee (ZNP) потребуется дополнительная оперативная память для буфера UART.
Учитывая эти ограничения, а также топологию сети и критерии проектирования для конечного приложения, понятно, что 8 КБ флэш-памяти, находящейся на устройстве CC2530, не смогут поддерживать сети, содержащие большое количество узлов. При таких обстоятельствах рекомендуется рассматривать беспроводные MCU CC2652R или CC1352P SimpleLink ™ в качестве альтернативы. В дополнение к току сна менее мкА и сохранению до 80 КБ ОЗУ эти устройства поддерживают SDK SimpleLink CC26x2 / CC13x2, который сочетает в себе структуру TI-RTOS и Z-Stack 3.x для надежного решения Zigbee, которое тестируется и обслуживается ежеквартально. Посетите страницу обзора Zigbee для получения дополнительных предложений по устройствам и решениям.
 
Ваша оценка: None Средняя: 9.7 (3 голосов)