Ксения (17.09.2012 19:11, просмотров: 168) ответил Evgeny_CD на LPC43xx, но FLASH вариант пока еще не выпущен.-
- Ну вот. Мадам подкинула провакационный вопрос и пошла демагогия,. xD saifullin(43 знак., 17.09.2012 21:35)
- Насчет "самый" не знаю, но у STM32F4xx максимальная рабочая частота 168МГц. У LPC4333/37/53/57 - 204МГц. B NXP и STM утверждают, что акселератор флеша сводит ее задержки на нет. - Dir(17.09.2012 19:48 - 19:53)
- у STM32F4xx максимальная рабочая частота 168МГц. У LPC4333/37/53/57 - 204МГц! А кто подскажет какая технолония (сколько нм) для данных процов у NXP и STM. Думаю реальная скорость FLASH зависит от технологии. если считаем, что конвеер не испольчуем alex-el(16 знак., 20.09.2012 09:31)
- Эка невидаль, даже у атмеловского AT91SAM9XE рабочая частота 180 МГц. А разница в интервале 180-205 скорее уже из области гарантируемой стабильности. - Ксения(17.09.2012 20:02)
- Ну, производительность ARM9 и Cortex-M4 все-таки очень разные ;) А для управления - так и вообще небо и земля. ARM9 - практически исключительно числомолотилка, а Cortex-M4 - МК с хорошей латентностью прерываний. - Dir(17.09.2012 20:16 - 20:19)
- блекфин да C674+ - это числомолотилки. а арм - так, умную периферию подёргать )) - Mahagam(17.09.2012 20:20)
- ARM9 тоже в своей области. Как управляющий и подергать ножками он никакой. Кэши мешают, контроллер прерываний, доступ к GPIO... - Dir(17.09.2012 20:27)
- АРМы тоже разные бывают. Атмел традиционно выпускает контроллеры, а не числомолотилки. И с периферией там дела обстоят много лучше, даже если архитектура АРМа сама по себе не совсем удачная. - Ксения(17.09.2012 20:36)
- Конечно разные. Cortex-M4 тоже ведь ARM ;) - Dir(17.09.2012 20:50)
- подёргать ножками они все никакие. кэши - вообще радость. а прерывания с умной периферией и большим количеством памяти особо и не требуются - Mahagam(17.09.2012 20:34)
- Ну почему. Кортексы-М вполне прилично дергают ножками, а в реалтайме (т.е. в управляющих системах) без хорошей системы прерываний вообще никуда. Dir(135 знак., 17.09.2012 20:57)
- для ультрабыстрой реакции на событие лучше в проект добавить плисину. всё остальное по времянкам вытянет даже самый тормозной ARM. - Mahagam(17.09.2012 22:46)
- Сомневаюсь, что добавление чего либо в проект лучше, чем не добавление ;) Это уже крайний вариант, если не удалось подобрать МК, устраивающий по характеристикам. - Dir(17.09.2012 23:18)
- по-любому время реакции на прерывание - микросекунды. я не вижу событий реального мира требующих такую реакцию. если под реалтаймом понимаем миллисекунды, тогда потянет любой проц, если нужно скатываться к наносекундам - добро пожаловать в мир Mahagam(6 знак., 17.09.2012 23:23)
- Почему это микросекунды? Доли. Вот как раз в данный момент делаю проект на LPC1766, где период SysTick = 10мкс, а три прерывания обрабатываются меньше, чем за 1мкс (вход, выход, обработка). Обработчик в ОЗУ. Update Dir(163 знак., 17.09.2012 23:32 - 23:36)
- А что даёт расположение обработчика в ОЗУ? Разве флэш не с той же скоростью работает? - Apтём(18.09.2012 00:18)
- В LPC17 время доступа к флэш 50нс (устанавливается при инициализации). Dir(412 знак., 18.09.2012 00:44)
- Спасибо, понятно. На десятке-другом мегагерц рзницы наверняка не будет. - Apтём(18.09.2012 01:04)
- Естественно. До 20МГц число циклов ожидания при выборке из флэши = 0. - Dir(18.09.2012 01:08)
- Спасибо, понятно. На десятке-другом мегагерц рзницы наверняка не будет. - Apтём(18.09.2012 01:04)
- В LPC17 время доступа к флэш 50нс (устанавливается при инициализации). Dir(412 знак., 18.09.2012 00:44)
- А был заказ, который требовал реакции на событие 0,2мкс. Я со своей PLD-кой + АРМ проиграл заказ конкуренту, который использовал ваш любимый 592 Blackfin, работающий в чисто программной петле ;) Dir(148 знак., 17.09.2012 23:46)
- Ахренеть, неужели заказчик анализировал такие нюансы реализации? ;-) - Shura(17.09.2012 23:48)
- Ну так всякие же заказчики бывают ;) - Dir(17.09.2012 23:50, ссылка)
- Ахренеть, неужели заказчик анализировал такие нюансы реализации? ;-) - Shura(17.09.2012 23:48)
- А что даёт расположение обработчика в ОЗУ? Разве флэш не с той же скоростью работает? - Apтём(18.09.2012 00:18)
- Почему это микросекунды? Доли. Вот как раз в данный момент делаю проект на LPC1766, где период SysTick = 10мкс, а три прерывания обрабатываются меньше, чем за 1мкс (вход, выход, обработка). Обработчик в ОЗУ. Update Dir(163 знак., 17.09.2012 23:32 - 23:36)
- по-любому время реакции на прерывание - микросекунды. я не вижу событий реального мира требующих такую реакцию. если под реалтаймом понимаем миллисекунды, тогда потянет любой проц, если нужно скатываться к наносекундам - добро пожаловать в мир Mahagam(6 знак., 17.09.2012 23:23)
- Сомневаюсь, что добавление чего либо в проект лучше, чем не добавление ;) Это уже крайний вариант, если не удалось подобрать МК, устраивающий по характеристикам. - Dir(17.09.2012 23:18)
- для ультрабыстрой реакции на событие лучше в проект добавить плисину. всё остальное по времянкам вытянет даже самый тормозной ARM. - Mahagam(17.09.2012 22:46)
- А я это называю - "дергать пипками" :) от английского слова pipe/pipeline. - Ксения(17.09.2012 20:38)
- моя валяться )))))))))) - Mahagam(17.09.2012 20:44)
- Ну почему. Кортексы-М вполне прилично дергают ножками, а в реалтайме (т.е. в управляющих системах) без хорошей системы прерываний вообще никуда. Dir(135 знак., 17.09.2012 20:57)
- АРМы тоже разные бывают. Атмел традиционно выпускает контроллеры, а не числомолотилки. И с периферией там дела обстоят много лучше, даже если архитектура АРМа сама по себе не совсем удачная. - Ксения(17.09.2012 20:36)
- ARM9 тоже в своей области. Как управляющий и подергать ножками он никакой. Кэши мешают, контроллер прерываний, доступ к GPIO... - Dir(17.09.2012 20:27)
- и чо быстрее? - Mahagam(17.09.2012 20:18)
- блекфин да C674+ - это числомолотилки. а арм - так, умную периферию подёргать )) - Mahagam(17.09.2012 20:20)
- Ну, производительность ARM9 и Cortex-M4 все-таки очень разные ;) А для управления - так и вообще небо и земля. ARM9 - практически исключительно числомолотилка, а Cortex-M4 - МК с хорошей латентностью прерываний. - Dir(17.09.2012 20:16 - 20:19)