В чем проще получится плата с внешним контроллером мне не совсем понятно. ИМХО, имея на борту DMA2D и TFT интерфейс (stm32f4xx/f7xx) смысл во внешнем контроллере исчезающе мал (ну разве что он уже есть на борту у TFT модуля).

P.S. Почитал доки на Nuvoton - кое-что понравилось, но очень многое и не понравилось Потом еще обнаружил, что шаг ног у него 0.4мм и совсем "обрадовался". Ну и отсутствие Erratы выглядит очень подозрительно...

Она не отсутствует. У него вся документация - под NDA. Запросите официально. И выложите потом сюда

Кто ищет тот всегда найдет Я нашел почти все - Datasheet, Programming Manual, Technical Reference Manual, и еще немного аппнот, схемы и даже печатку отладочной платы, и еще немного небольших документов типа Hardware Design Manual и т.п.

Посмотрел - мне многое не понравилось, как сделано.

Интересное решение, но места на плате не очень много, хотелось бы использовать минимальное количество корпусов. А как всё обстоит с графическими библиотеками для этого чипа? По ссылке я нашел что-то совсем простое. Хотелось бы интерфейс юзвера сделать на хорошем уровне.



Я работал с готовыми процессорными модулями от Embedded Artists. У вас самостоятельно разведенная плата, или готовые модули. В принципе, можно заморочиться на разводку платы, если это будет единственный вариант.


Необходимо прикрутить TFT дисплей 480 на 320, скорее всего с глубиной 8 или 16 бит к микроконтроллеру, тач пад обязателен, места на плате не очень много., хотелось бы обойтись с минимальным количеством корпусов.


Кругозор расширен! Пока ещё не совсем понятно как добавить качественную графическую библиотеку.

Этот проект - на отладке, так как "для себя". Но на работе есть несколько изделий (своих плат), но на LPC1778. И только в одном внешняя RAM и то - SRAM. Но нигде нет использования встроенного LCD-контроллера.

Корпусов ровно столько же: заменяем SDRAM на графический контроллер.


Тут я не помощник. У меня всё самодельное. Всякие модные виджеты мне не нужны, а нехитрый интерфейс делается с нуля без особого труда. При некоторой сноровке, конечно.
Кстати, мне всегда казалось, что любая приличная библиотека должна иметь кучу драйверов для разных графических контроллеров. А если нужного драйвера не оказалось, можно взять похожий и допилить до нужного. При некоторой сноровке, конечно.

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

Не, чуть меньше - WVGA (800х480), ну и двойная буферизация обязательна.

Например что, кроме шага 0.4?
Для решения этой задачи есть модули содимм на основе этого чипа.
Больше недостатков не заметил, кроме старого и медленного проца.



Смысл? Этот камень уже скоро с производства наверно снимут. Берите уж тогда SOM на imx6s

Например, то, что нет DMA на SPI и UARTах. Таймеры слабоваты. Нет FPU, про ядро Вы уже написали. Три напряжения питания.


Ну он побыстрее будет и без проблем с корпусом.

Да всех их когда-нибудь снимут Его 10лет будут выпускать, выпустили его когда - лет 5 назад наверное, так что 5лет или около того еще есть, вон новые камни i.mx7 обещают только 5лет выпускать.

imx6s рассматривал, но у него часть доков под NDA, весьма важная. Да и он такой не слишком нужен в этом проекте. Если бы переползал на Линукс, то точно остановился бы на нем.

Излазил его наверно больше, чем все здесь на форуме , но кроме видеокорок все доки есть, изменил параметры sdma, чтоб работал, как dma2d, 3D вообще без надобности, остальное все было.
Ну и проц и видеоблок в нем на порядок круче, чем все стм и иже с ними..



FPU - да нет так нет..
С уартом можно использовать фифо "Separate receive / transmit 64/16 bytes entry FIFO for data payloads"

С спи - даже фифо не сделали - неуд!

ЗЫ. Это все-таки считается application processor, поэтому уж что есть Ну и usb типа EHCI - это совсем неплохо...

Почему "медленного"? Там же вроде - до 300МГц. При том что STM32 максимум 180МГц.


В нём UART имеет FIFO глубиной 64 байта - с таким FIFO и DMA не нужно. А вот для SPI оно очень даже нужно.

Вы его помнится без Linuxа запускали, я так понял осилили?


sdma не может заменить полноценно dma2d - фактически получится делать только две функции: заливка и копирование (аналогичный блок есть даже в древних i.mx287). А ведь прелесть DMA2D в растровых операциях, которые позволяют выводить шрифты, делать наложения с прозрачностью и т.п. без участия процессора.

Хотя с другой стороны быстродействие у i.mx6 даже если весь вывод графики делать процессором наверное всеравно будет поболее, чем у stm32f4+dma2d.


Потому, что по тестам (на сахаре тестировали как-то) у него выходило 5MFLOPS, а у stm32f4 32MFLOPS - FPU это сила (если конечно плавающая точка нужна). На целочисленных операциях наверное Nuvoton немного быстрее будет, но stm32f7xx (Cortex-M7) уже будет лучше с любой стороны.

Почему не сделали?:
Configurable bit length of a transaction from 1 to 32-bit and can be configured as burst mode, totally128-bit can be transmitted at one time
128 бит - какое-никакое но FIFO. В STM32 и такого нет


Понятно что программная эмуляция будет гораздо медленнее аппаратного FPU! Что тут тестировать? Странно ещё что такая маленькая разница всего в 6 раз.
А вот насчёт "любой стороны" я бы не был так категоричен.
Какой размер кеша на stm32f7xx? А с какой частотой работает flash программ у него и какова ширина шины выборки команд из flash программ?
А каково время входа в прерывание на stm32f7xx?

Это никак не FIFO - скорее извращенный DMA (на 4ре слова ). stm32 запросто может такое делать даже древние stm32f1xx. Единственно, что хорошо у Нувотоновского SPI это возможность задать произвольную длину "слова". У меня, например, с одним из девайсов обмен ведется 24битными словами и в нынешней реализации у STM это очень неудобно.


4K+4K, но у него еще есть ITCM (16K) и DTCM (64K), а еще есть 256K быстрого ОЗУ. Для большинства решаемых задач требующих максимальной производительности ядра это более выгодная конфигурация.


ITCM RAM работает на частоте ядра , флеш 256битный. В случае "промаха" потребуется 8циклов (на частоте 216МГц), чтобы вычитать данные из флеша, если ART не промахивается, то исполнение идет без задержек.

От меня встречный вопрос - сколько потребуется циклов Нувотону, чтобы вычитать данные с произвольного адреса из DDR2 памяти работающей на 150МГц? А если учесть, что по той же шине данные скармливаются на контроллер LCD и обрабатываются DMA2D, то все станет очень грустно.

В stm32f7xx/f4xx такая архитектура, что можно минимизировать задержки из-за обращения ядра/DMA2D/LTDC к одним и тем же интерфейсам/шинам.


У Cortex-Mx по этой части все будет много лучше ARM9. Фактически линейка Cortex-Mx создавалась с учетом минимизации отклика на прерывания.

Почему это? Вполне себе обычный FIFO.


У Нувотона кроме кеша кода есть кеш данных, который размером 16К, который сгладит проблемы с доступом к коду и данным в одной области RAM.
А вот что будет когда Вы код разместите в "256K быстрого ОЗУ" откуда и данные надо выбирать.
У Nuvoton тоже есть отдельная SRAM, где можно разместить быстрые данные, чтобы они не мешали выборке команд.

Размер кеша в 4 раза больше + частота почти в 1.5 раза выше - я бы в большинстве задач (не связанных с float) поставил на Nuvoton, а не на stm32f7xx.
Да и float часто маловато, нужен double, а тогда преимущество от аппаратного FPU полностью пропадает.


Правда что-ли?
А то что для входа/выхода в прерывание в Cortex-M необходимо как минимум сохранить/восстановить 8 слов на стеке, в то время как ARM9 для входа в прерывание просто переключает режим CPU.
Если нужна очень быстрая реакция на какое-то прерывание, то ARM9 для этого гораздо лучше подходит с его системой прерываний.
Если нужны вложенные прерывания или переключение контекстов, то здесь ARM9 хуже конечно.

Да и вообще - у ARM9 есть огромный плюс перед Cortex-M - это полноценный MMU. Позволяющий делать гибкую защиту памяти. Мне этого очень не хватает в Cortex-M.

FIFO это когда Вы пишите в один и тот же регистр, а данные уходят в порядке записи. А здесь четыре отдельных регистра, так что на FIFO никак не тянет.



Я же написал 4К+4К - у stm32f7xx тоже есть кэш данных. Кроме того код у Cortex-M7 скорее всего будет компактнее.


А Вы что не в курсе, что Cortex-Mx как правило быстрее работают из флеша и никто в обычном ОЗУ код не размещает. Для этого есть ITCM на отдельной шине.


Размер кэша больше в 4 раза, а SRAM меньше почти в шесть раз, плюс у stm32f7xx есть ITCM/DTCM (это может быть часто даже лучше кэша). Частота в 1.5 раза выше, но Cortex-M7 выдает 2.14DMIPS/MHz, а ARM9 только 1.1MIPS/MHz.


А то, что ARM9 не умеет прерывать load/stor multiple и подобные инструкции (в принципе этого уже достаточно, чтобы максимальное время было у ARM9 больше), не умеет делать tail-chaining, не умеет обрабатывать late-arriving? Да и регистры обычно нужны в прерывании. Сейчас начнете про FIQ рассказывать, но как правило его можно либо к какому-то одному источнику подключить, либо придется анализировать флаги от кого прерывание - думаете быстрее выйдет? В общем случае нет.


Ой ли...


Вот объясните, если сторонний код (который может убить систему) у меня не запускается, а все ПО написано мною зачем мне ММУ?

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


Да ну?! Неужто Cortex-M уже каждый такт умеет 2 с лишним команды выполнять?
Меньше читайте рекламных буклетов и больше смотрите систему команд. Что ARM9 что Cortex-M в части наиболее употребительных команд - все однотактовые и примерно одинаковые.
Вот в части всяких сложных а-ля DSP-расширений - там есть разница. Только сколько такого кода в реальных проектах?


Быстрее конечно. Так как не надо ни сохранять регистры, ни грузить рабочие переменные/указатели. Огромный выигрыш.
И очень часто у меня бывает, что в изделии есть один источник высокочастотных прерываний, которые надо обрабатывать как можно быстрее. Не много, а всего один. И ARM7/9 здесь выигрывает значительно.


Ну если Вы только Hello world пишете, то определённо не нужно. А у меня бывают проекты по нескольку десятков тысяч строк. Да ещё как правило несколько человек пишут.

https://mohammadthalif.wordpress.com/2011/1...mips-and-dmips/

FIFO это не либой буфер, а это буфер организованный особенным образом (не думал, что нужно объяснять), и 4ре отдельных регистра с произвольным доступом это может быть что угодно но не FIFO.


Качаем http://infocenter.arm.com/help/topic/com.a...rtex_m7_trm.pdf
Читаем:


Также читаем:
http://infocenter.arm.com/help/index.jsp?t....faqs/4160.html


Аналогичную цифру для stm32f7xx я уже приводил выше - 2.14DMIPS/MHz можете посмотреть сами у STM в доках.


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


Ну в том проекте который собирается переезжать на сегодняшний день около 20тыс. строк, правда это не только код для обсуждаемого ARMа (там еще есть двухядерный DSP ) - чуть больше Hello word

Вам если и нужно, то MPU, а не MMU. MMU нужно если Вы собрались виртуальные адресные пространства организовывать и подобные вещи. Обычно это нужно когда будут запускаться сторонние программы - т.е. речь о совсем других системах. Кстати Cortex-M7 может быть с MPU

Вот типичный код для M4:

За сколько тактов выполнится на M7 и на ARM9? Считая что нет ожиданий памяти и т.п. Правильно - примерно одинаково.
Всё эти DMIPS-ы достигаются на сложных а-ля DSP командах, выполняющих несколько операций за команду. В обычном коде (не процедуры сигнальной обработки) такхи команд встречается оч. мало.
А такой код будет выполняться быстрее на CPU с большей тактовой.
Или M7 сможет автоматически запараллелить выполнение каких-то команд из этого кода?


И что? Ну пускай не может прервать. Только это всего одна команда.
А Cortex-M на вход/выход потратит одну такую операцию на вход (8 сохранений контекста),
потом в ISR надо загрузить как минимум один указатель да рабочую область ОЗУ с переменными, загрузить все переменные, перед завершением все переменные выгрузить (если нужно), восстановить контекст (8 чтений). Разницу ощущаете?


MPU у меня везде используется, но он слишком слаб: всего 8 регионов, минимальная гранулярность 32 байта (вроде) и регионы должны быть выровнены на границы кратные размеру. Это очень сильно сокращает возможности защиты. MMU не только для виртуализации, он и по защите гораздо более гибок. И кешем данных можно управлять удобнее с помощью него.

Пример еще более искусственный, чем тесты.


Да нет, на обычных тоже работает. Достаточно переставить у Вас команды и, если вычитываемые и записываемые данные окажутся в памяти на разных шинах (что довольно типично, например, загрузка констант из флеша в ОЗУ) каждая загрузка/сохранение будет выполнена одновременно.


Та одна команда может столько тактов утянуть... В ARM9 переменные в регистры загружать не надо? Вы о чем? После входа в ISR можно сразу работать. А вот с ARM9, если Вы собираетесь на С обработчик писать, будет засада, ибо рабочие регистры R0..R3 не переключаются при смене контекста.


Мне сложно представить задачу где нужно такое. Либо притянуто за уши, либо проблема с архитектурой ПО.

P.S. Что-то от темы мы сильно удалились... Я бы с удовольствием послушал mantech про standalone i.MX6. Интересно плата была своя или какой-то SoM использовался? Может это решение (в том числе и "на вырост" , а если четырехядерный поставить , то можно даже от DSP процессора избавиться, хотя это и не актуально, но все же...).

Да, уже с год, как в контроллерах у пользователей работает. Самое сложное для меня было, это , как ни странно, Hello world запустить Просто есть там нюансы с подготовкой имиджа для заливки в камень, после того, как тест заработал, было уже гораздо легче, т.к. был pltform sdk.



Да, использовал готовый модуль, ибо по цене даже дешевле, чам самому ваять.
Думал 2х ядерный запилить, но ценник кусачий А в принципе - ничего такого пугающе сложного там нет. Этап 1 - запустить камень, подрыгать пинами. 2) инит уарта, вывод в printf. 3) запуск MMU и кешей(к сожалению, без MMU кэши не работают). 4) запуск контроллера прерываний(он там как у нувотона, с программным выбором вектора из таблицы). 5) делал собственный переключатель контента для многозадачности.
6) инициализация дисплейного контроллера (кстати, он многие функции DMA2D может делать, включая альфа-наложение и ресайзинг), портировал свой гуй... И пожалуй все!

Впечатления от видеоконтроллера - на четверочку, так и не смог запустить 2х канальный LVDS, причем по отдельности каналы работают "на ура", 2х канальный режим хотел для "мониторных" матриц использовать с большим разрешением, но пришлось довольствоваться HDMI.
По скорости - нет вопросов, ничего не моргает, и при ДМА и просто так(как ни как память DDR3 на 400МГц 32 бита)

Когда-то игрался с LPCшкой и сдрам на 100МГц, так при одновременной работе с ДМА и экраном начиналась рябь, что совсем не айс...

ЗЫ. Сейчас пока времени нет, хочу поднять аллвиннер А20 в стандалон, думаю, как в нем имидж создавать, чтоб хелловорд запустить. Ядро там почти такое-же, уарты стандартный 16550, мму, кэши, прерывания, усб все такое-же, как в мх6. Может кто пробовал? Просто платок с таким процом полно и цена демократичная...

А что там пробовать, если есть u-boot? А так A20 - процессор просто замечательный, с загрузкой только есть некоторые "приколы".

Почему искусственный? Это кусок реального листинга. Взятый наугад.


Ну если это действительно так и последовательность
STR R2,[R0]
LDR R3,[R1]
если R0 и R1 указывают в регионы памяти на разных шинах, будет выполнена за 1 такт, то тогда да - это большой плюс.
Хотя утверждать это по вышеприведённой цитате из TRM я бы не стал. Хотелось бы увидеть более конкретное доказательство.


Я о FIQ. И о том, что можно написать ISR, который будет уже хранить все рабочие переменные/указатели в регистрах R8-R14 без необходимости их загрузки при входе в ISR.
Таким образом можно получить наибольшую скорость реакции на прерывание.
Мне такие ISR как раз и приходилось писать. Конечно на асм.


Хмм... очень похоже на ARM9. Там тоже кеш данных без MMU не работает. Хотя кеш кода работает и без MMU.
Контроллер прерываний там как у ARM9 (IRQ, FIQ, банковые регистры состояний CPU, etc.)?

Да, все очень похоже, поправил несколько инструкций CP15 и все заработало. Сравнивал с АРМ11, но и 9й примерно такой-же. Добавлен кэш L2, но он тоже стандартный АРМовский.



Убут мне не подходил, от слова "совсем". Иначе не мучался бы со своим бутлодырем. Просто тот убут, который был с мх6 грузил только с одной сд карты и по сети. Сеть меня вообще не интересовала, а вот нужна была поддержка обеих сд контроллеров, усб-флешек и фат16 и 32. Ну а делать так, что убут грузит мой бут, тот программу и все остальное - это изврат...

А сам он тоже только с карты стартовал? Не обязательно использовать u-boot, но механизм создания образа и первоначальной загрузки можно посмотреть.


Сеть с u-boot'ом - крайне полезная связка как раз для отладки своего stand-alone приложения: компилируем, тут же по TFTP затягиваем новую прошивку и стартуем. Минимум телодвижений.

Мне больше нравится вариант компилируем, заливаем в SPI-флеш и стартуем

Да, с карты, а что в этом такого особенного? На плате был разъем под сд карту, вторую карту подключил к внешнему разъему, но с него убут не грузился, равно, как и все остальное, т.к. чип нужно конигурировать под конкретную карту. Разбираться в дебрях маленького линукса убута небыло никакого интереса, просто взял из него настройки DCD.

Гораздо удобней всяких сетей и пр. программа mfgtolls. Все, что нужно - подключаем плату по усб к компу, запускаем mfgtools, жмем "старт" и ... светодиод уже моргает по моей программе.

ЗЫ. Что-то мне подсказывает что у китайского А20 такой лафы не будет.



Там даже флеш шить не надо, как - уже написал выше.

Подключаем, запускаем, жмем - сколько действий? А с TFTP один раз нажимаем сброс (или в консольке пишем rst). Так что насчет удобства не соглашусь.

На вкус и цвет... Вообщем мне так удобнее показалось, плюс на плате не установлен сетевой разъем, усб есть и подключать его не сложнее, чем сетевой кабель
И да, с mfgtools-ом достаточно тоже нажать ресет и прога загрузится и запустится автоматом, и нет необходимости в поднятии тфтп и пр..

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


USB загрузчик у него есть. Но инструментарий придется свой строить.

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

Вот пример как прошивается CubieTruck через USB

Нашел еще одного кандидата - SoM на S5P6818, доки есть, платы подходящие есть вроде недорого, пора наверное Embedded Linux осваивать, ну или в bare metal его запустить

Что подразумеваете под доками? Где можно глянуть?

Кое что нашел на 1700стр. Сравнивая с докой на мх6 которая 5500стр - это ничто. К тому же такой фишки, как platform sdk, на подобие мх6 - нет вообще, поэтому про bare metal забудте. Это я говорю, как тот, кто поднял в этом виде мх6.

Хотя камень интересный.

Да вроде бы почти все важное там расписано. Периферия я бы сказал у него попроще, чем у i.MX6, а многого просто нет, оттого и доки поменьше.


А что там за откровения в этом Platform SDK, что без него прям никак?

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

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

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

Это точно! Особенно поражает стремление разработчиков данных плат, упрятать все путевые интерфейсы, как уарт, jtag, или lvds, причем почти на всех подобных платах.



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

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