Перейти к содержанию
    

Нужен ARM7 или Cortex с максимально быстрым GPIO

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...