[ashr 0]

Есть плата разработчика на базе Kinetis K70. От производителя платы есть bsp для mqx версий 4.0.0 и 4.0.2.

Какова сложность доработки указанных bsp до версии 4.1.0? Есть тонкие моменты? Что-то порекомендуете?

Сам я только только прикоснулся к mqx. Ничего еще не щупал, только бегло ознакомился с доками.

[AlexandrY 3]

Есть плата разработчика на базе Kinetis K70. От производителя платы есть bsp для mqx версий 4.0.0 и 4.0.2.

Какова сложность доработки указанных bsp до версии 4.1.0? Есть тонкие моменты? Что-то порекомендуете?

Сам я только только прикоснулся к mqx. Ничего еще не щупал, только бегло ознакомился с доками.

 

Почти все файлы придется рефакторить, поменялись имена у типов данных.

Для некоторых драйверов стали использовать DMA (например для SPI), значит надо смотреть в версии производителя не занято ли там у них уже DMA

Добавились фичи, а следовательно и управляющие структуры у драйверов.

 

Вообщем демки производителя с новым MQX BSP скорее всего не заработают.

Это еще не говоря о том, что новый MQX 4.1.0 идет наверняка без BSP вашей оригинальной платы, поэтому всегда нужен этап перепортирования.

[ashr 0]

Еще.

У Freescale есть некий "Processor Expert". В какой степени PE может помочь в разработке своего bsp?

И кроме как ставить CodeWarrior или Eclipse нет вариантов его использовать?

 

У меня модуль SQM4-K70 + EasyBoard (взяли по вашей наводке). Вы видели их bsp, какого оно качества? Насколько быстро ребята реагируют на новые версии MQX?

 

[AlexandrY 3]

Еще.

У Freescale есть некий "Processor Expert". В какой степени PE может помочь в разработке своего bsp?

И кроме как ставить CodeWarrior или Eclipse нет вариантов его использовать?

 

 

У меня модуль SQM4-K70 + EasyBoard (взяли по вашей наводке). Вы видели их bsp, какого оно качества? Насколько быстро ребята реагируют на новые версии MQX?

 

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

 

Он генерит исходники совместимые с GCC, IAR, Keil, CW

Я использовал IAR.

В Processor Expert создал проект, сконфигурировал все как надо согласно моей платформе, потом скопировал то что сгенерировалось в поддиректорию с MQX (чтобы не повредить сам проект Processor Expert и иметь нетронутый оригинальный сгенерированный код)

Определил макрос PE_LDD_VERSION в файле PE_Types.h который входит в состав BSP (этот макрос перенаправляет BSP на объявления в исходниках от Processor Expert). В IAR-е указал пути к файлам сгенерированным Processor Expert. Скомпилировал.

И все заработало, как ни странно.

 

Но потом такой метод не применял.

Напрягают магические числа, которые повсюду в коде от Processor Expert.

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

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

Хотя для новичков это вполне вариант.

 

Я предпочитаю все метаданные с объяснением конфигурации вставлять в исходники.

 

 

Исходники для SQM4-K70 EasyBoard это как я посмотрел просто копия MQX BSP версии 4.0.2, но с поправками на другую распиновку, может быть еще там периферия какая-то добавлена, это надо углубляться,

но очевидно их придется рефакторить для MQX 4.1

[ashr 0]

Добрый день.

 

В bsp к mqx есть файлы для линкера xxx_sramdata/xxx_ddrdata.

 

Правильно ли я понял, что в случае конфигурации sramdata компилятор/линкер будет использовать для размещения объектов только внутренную sram контроллера, а внешнюю ddr память можно использовать только в качестве пула памяти (_mem_create_pool).

 

Для случая конфигурации ddrdata, для размещения объектов, стеков, таблицы векторов прерываний и проч. будет использована внешняя ddr память, а внутренняя sram контроллера будет пущена на т.н. sram_pool, используемый некоторыми драйверами (в частности enet). И здесь вопрос, насколько это снижает производительность контроллера. Нельзя ли при такой конфигурации разместить во внутренней sram хотя бы таблицу векторов и стек прерываний.

 

[AlexandrY 3]

Добрый день.

 

В bsp к mqx есть файлы для линкера xxx_sramdata/xxx_ddrdata.

 

Правильно ли я понял, что в случае конфигурации sramdata компилятор/линкер будет использовать для размещения объектов только внутренную sram контроллера, а внешнюю ddr память можно использовать только в качестве пула памяти (_mem_create_pool).

 

Для случая конфигурации ddrdata, для размещения объектов, стеков, таблицы векторов прерываний и проч. будет использована внешняя ddr память, а внутренняя sram контроллера будет пущена на т.н. sram_pool, используемый некоторыми драйверами (в частности enet). И здесь вопрос, насколько это снижает производительность контроллера. Нельзя ли при такой конфигурации разместить во внутренней sram хотя бы таблицу векторов и стек прерываний.

 

Да, в случае выбора файла линкера для SRAM область DDRAM оказывается нигде не используемой с исходниках MQX

Но остаются объявления границ этой области и можно там делать свой пул памяти или организовывать секции данных и кода.

 

Если же выбран файл линкера для DDRAM, то где окажутся вектора прерываний зависит от настройки MQX_ROM_VECTORS

Секция .sram_pool организуется во внутренней SRAM.

Но для ENET дескрипторов и буферов память берется либо из пула _BSP_sram_pool либо из некэшируемой области.

Это зависит от пользовательских настроек проекта.

Размещение _BSP_sram_pool тоже зависит от настроек.

Но похоже при любых настройках у MQX для Kinetis некэшированная память всегда приходится на внутреннюю SRAM.

В MQX кэш DDRAM остается всегда включенным.

 

Стек же по умолчанию организуется из системного пула находящегося в DDRAM.

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

 

Не думаю, что размещение буферов ENET в DDRAM что-то сильно замедлило бы, но у Freescale как-то традиционно ENET буфера располагают во внутренней SRAM.

 

Тут надо помнить что доступ к DDRAM идет через кэш, а к внутренней SRAM без кэша. И кэш может оказаться в некоторых случаях быстрее чем SRAM.

Надо тестировать. Пока не тестировал.

[ashr 0]

Спасибо.

[ashr 0]

Еще вот непонятно с буфером для TFT панели.

Смотрю на файл линкера. Там есть строчки:

define exported symbol __EXTERNAL_LCD_BASE      = 0x60000000;
define exported symbol __EXTERNAL_LCD_SIZE      = 0x1FFFF;
define exported symbol __EXTERNAL_LCD_DC_BASE   = 0x60010000;

Предполагаю, что с адреса 0x60000000 как раз и расположен буфер экрана. Правда смущает малый размер буфера.

Смотрю на карту памяти процессора и вижу, что этот адрес - это область Flexbus. На этой шине у меня на плате ничего нет. Хотя TFT панель есть и работает.

По логике, буфер должен располагаться внутри DDRAM. Чего я не понимаю?

[AlexandrY 3]

По логике, буфер должен располагаться внутри DDRAM. Чего я не понимаю?

 

Интересный вопрос. В штатном BSP нет инициализации TFT.

Но адрес хранения буфера экрана TFT может быть произвольный.

Он программируется в контроллере LCDC.

Главное чтобы DMA туда имел доступ. Не все адресное пространство доступно для DMA LCDC.

Надо посмотреть кто и что записывает в регистр LCDC_LSSAR

[ashr 0]

[quote name='AlexandrY' date='Jun 11 2014, 19:05' post='1261584'

Надо посмотреть кто и что записывает в регистр LCDC_LSSAR

Ну да, точно. А строчки в файле линкера видимо к другому относятся.

[ashr 0]

В bsp среди прочего есть конфигурационные макросы:

#define BSPCFG_ENET_HW_TX_IP_CHECKSUM 0
#define BSPCFG_ENET_HW_TX_PROTOCOL_CHECKSUM 0
#define BSPCFG_ENET_HW_RX_IP_CHECKSUM 0
#define BSPCFG_ENET_HW_RX_PROTOCOL_CHECKSUM 0
#define BSPCFG_ENET_HW_RX_MAC_ERR 0

Но они почему то установлены в ноль. Для каких случаев полезно будет установить их в 1.Или по другому. Почему при аппаратной поддержке вычисления контрольных сумм эти опции не в 1 по умолчанию.