[kovigor 6]

Нужно, например, иметь возможность генерировать на GPIO импульсы с частотой порядка 10 МГц, и читать состояния ножек с такой же примерно частотой. Как я понимаю, ARM7/9 здесь не годятся, нужен как минимум CORTEX, и то не факт, что он подойдет. Кто что посоветует ?

[aaarrr 69]

Вам просто нужен процессор с GPIO на быстрой шине. Такое есть у NXP (как ARM7, так и M3) и у новых STM32, если ничего не путаю.

[kovigor 6]

Вам просто нужен процессор с GPIO на быстрой шине. Такое есть у NXP (как ARM7, так и M3) и у новых STM32, если ничего не путаю.

 

Спасибо. Особенно интересны достижения в данной области других специалистов. Наверняка многие решали подобную задачу. Хотелось бы услышать о достигнутых результатах, это поможет сориентироваться. Я понимаю, что подобных "таблиц производительности" я не найду, но все же ...

[ChipKiller 0]

Особенно интересны достижения в данной области других специалистов.

... сомнительно, что специалисты используют CORTEX ради "ногодрыганья". Конечно можно выдать "трель" с помощью bit-banding_а, но зачем тогда 32 разряда?

[scifi 1]

Вот реальный пример. В микроконтроллерах STM32F2xx и STM32F4xx GPIO сидит на шине AHB, и доступ туда на частоте ядра, без задержек.

[topkin 0]

Вот реальный пример. В микроконтроллерах STM32F2xx и STM32F4xx GPIO сидит на шине AHB, и доступ туда на частоте ядра, без задержек.

Но на установление ножки в определенное состояние необходимо 2 такта, т.е. при тактировании AHB 120 МГц, максимальная частота программного ногодрыганья будет 60 МГц, это что касаемо F2/F4. С STM32F1x ситуация хуже

[scifi 1]

Но на установление ножки в определенное состояние необходимо 2 такта, т.е. при тактировании AHB 120 МГц, максимальная частота программного ногодрыганья будет 60 МГц, это что касаемо F2/F4. С STM32F1x ситуация хуже

Вообще-то 1 такт.

1 такт - "0", 1 такт - "1" и т.д. Вот и получается 2 такта на период, то есть 60 МГц.

[Petka 0]

Нужен ARM7 или Cortex с максимально быстрым GPIO, Задача: как можно быстрее "дергать" ножками и считывать их состояние

В чипах lpc17xx есть возможность подключать DMA к GPIO. При этом время доступа к пину 1 такт. Если учесть тактовую частоту до 100 Мгц. то.....

[YuraFCZ 0]

Автор топика написал, что требуется не только выдать на пин частоту порядка 10 МГц, но еще и мониторить состояние некоторых ног с входными частотами такого же порядка... Если работа с GPIO на таких частотах принципиально возможна (как уже написали выше авторитетные люди), то времени на какую либо обработку получаемых с входных ног данных по моему просто нет - что можно успеть за несколько единиц тактов? Сохранить состояние ноги где то в RAM, переключить какой нибудь выход?

[kovigor 6]

Автор топика написал, что требуется ...

 

Нужно вот что. Внешнее устройство (им я управлять не могу) выставляет на некоторые линии GPIO 32-разрядный адрес (получается своеобразная шина адреса, реализованная в виде набора линий GPIO) и стробирует его коротким (~100 нС или даже короче) импульсом (тоже по одной из линий GPIO). Я должен при получении этого строба прочитать упомянутый адрес и как можно быстрее выдать соответствующее ему 32-разрядное слово данных на отдельную шину данных, реализованную, опять же, в виде набора линий GPIO. Т.е., надо сэмулировать микроконтроллером работу микросхемы ПЗУ (или статического ОЗУ, если хотите, но только в режиме чтения). Читаю описание LPC17xx и все больше убеждаюсь в том, что это, похоже, нереализуемо на таких скоростях ...

[Flexz 0]

Главная проблема тут имхо - 32 разряда, на LPC17xx порты хоть и 32битные, но целых нету. Если б 16, еще можно попробовать успеть, но только на STM32F4 (168МГц), либо новые LPC43xx (204МГц), у этих порты 16битные.

Вообще, конечно, для ПЛИСки задача.

[kovigor 6]

Главная проблема тут имхо - 32 разряда, на LPC17xx порты хоть и 32битные, но целых нету. Если б 16, еще можно попробовать успеть, но только на STM32F4 (168МГц), либо новые LPC43xx (204МГц), у этих порты 16битные.

Вообще, конечно, для ПЛИСки задача.

 

Да, очень похоже на утопию. Просто заотелось на микросхемке памяти сэкономить и реализовать ее функции на МК ...

[scifi 1]

Нужно вот что. Внешнее устройство (им я управлять не могу) выставляет на некоторые линии GPIO 32-разрядный адрес (получается своеобразная шина адреса, реализованная в виде набора линий GPIO) и стробирует его коротким (~100 нС или даже короче) импульсом (тоже по одной из линий GPIO). Я должен при получении этого строба прочитать упомянутый адрес и как можно быстрее выдать соответствующее ему 32-разрядное слово данных на отдельную шину данных, реализованную, опять же, в виде набора линий GPIO. Т.е., надо сэмулировать микроконтроллером работу микросхемы ПЗУ (или статического ОЗУ, если хотите, но только в режиме чтения). Читаю описание LPC17xx и все больше убеждаюсь в том, что это, похоже, нереализуемо на таких скоростях ...

Я бы сделал так (STM32F2xx): строб на триггер таймера, таймер генерит триггер для DMA и запускает обработчик, DMA читает из GPIO (пусть даже двумя кусками по 16 бит), обработчик ждёт окончания пересылки DMA, формирует данные и выдаёт в порт. Может получиться весьма шустро.

Только если МК должен при этом делать что-то ещё, то надо смотреть подробнее: возможны задержки на Bus Matrix.

[ChipKiller 0]

Просто заотелось на микросхемке памяти сэкономить и реализовать ее функции на МК ...

... такая экономия ИМХО обернется "головной болью". В прежние времена всевозможные эмуляторы ПЗУ делали на связке CPLD+RAM.

[kovigor 6]

... такая экономия ИМХО обернется "головной болью". В прежние времена всевозможные эмуляторы ПЗУ делали на связке CPLD+RAM.

 

Да, похоже, вы правы. Идея неудачная, мягко говоря. Если бы адреса увеличивались последовательно, думаю, DMA решил бы проблему. Но доступ к памяти возможен как раз по произвольным адресам ...