STM32F103 и захват потока данных, Справится ли? Опции

[KKV2003]

Добрый день, народ.

Подскажите, пожалуйста кто знает. Планируем сделать устройство, которое должно хватать поток данных со скоростью хотя бы 10 МБайт в секунду по байту. Можно ли будет притормозить поток - пока не известно. В общем на это рассчитывать не хочется, как крайний вариант разве что.

Хватать, конечно, не постоянно - информация дозируется. Объем файла данных порядка мегабайта-двух. Сваливать ее предварительно планировалось в SDRAM - у нее есть burst-режим. Но иногда нужно будет подготавливать новые строки и банки для приема данных.

Причем придется еще производить достаточно сложные вычисления, поэтому ее 72 МГц и 32 разряда вполне пригодятся. Поэтому брать что-либо простое ( типа АТМеги или АТхМеги ) трудно.

Так вот вопрос в том, сможет ли STM32F103 ( или что-то подобное ) управлять хотя бы записью во внешнюю память со скоростью порядка 10 МГерц или выше? Причем модели в 100-выводном корпусе имеют блок работы со внешней памятью, но разве что статической или флешь-памятью. Можно ли будет использовать их времянку ( циклы чтения/записи ) для управления записью в SDRAM?

У АТхМеги есть поддержка SDRAM, но там разве что 4-хбитная шина данных... Что не радует...

С АРМами пока мало связывался, но ( по косвенным данным ) с портами они работают медленно и эмулировать протокол быстро не получится...

Заранее спасибо.

[kovigor]

А поток что из себя представляет ? Просто восьмиразрядная шина со строб-сигналом ?

[zksystem]

Так вот вопрос в том, сможет ли STM32F103 ( или что-то подобное ) управлять хотя бы записью во внешнюю память со скоростью порядка 10 МГерц или выше? Причем модели в 100-выводном корпусе имеют блок работы со внешней памятью, но разве что статической или флешь-памятью. Можно ли будет использовать их времянку ( циклы чтения/записи ) для управления записью в SDRAM?

У АТхМеги есть поддержка SDRAM, но там разве что 4-хбитная шина данных... Что не радует...

С АРМами пока мало связывался, но ( по косвенным данным ) с портами они работают медленно и эмулировать протокол быстро не получится...

Заранее спасибо.

Возьмите контроллер с SDRAM контроллером, например Luminary Micro LM39B96 или какой другой. STM32F103 рулит только статикой.

[KKV2003]

Поток - просто байты по клоку. Причем клок еще нужно сделать ( но тормозить выдачу не желательно ).

Нашел еще AT91SAM7SE серию с SDRAM-контроллером, хотя у нее порядка 50 МГц тактовая частота... Но SDRAM контроллер вполне адекватный ( до 32 разрядов, куда их приладить? ).

LM39B96 сейчас погляжу.

[kovigor]

Поток - просто байты по клоку. Причем клок еще нужно сделать ( но тормозить выдачу не желательно ).

Нашел еще AT91SAM7SE серию с SDRAM-контроллером, хотя у нее порядка 50 МГц тактовая частота... Но SDRAM контроллер вполне адекватный ( до 32 разрядов, куда их приладить? ).

LM39B96 сейчас погляжу.

Так это простое сэмплирование 8-разрядной шины 10млн. раз в секунду ? И клока в этой шине нет, а вы просто должны брать отсчеты через равные промежутки времени ? Думаю, что на ARM такое не сделать - слишком быстро. Наверное, придется FPGA ставить. Хотя я могу и ошибаться ...

[Aner]

По смотрите в сторону 9-х армов таких как этот S3C2440.
Там точно получиться.

[KKV2003]

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

Texas порадовал контроллерами, может будем заказывать образцы и отладку.

Про Самсунга тоже гляну, но ( по-моему ) там потребуется внешняя память ( чего сильно не хотелось бы добавлять )...

[zksystem]

Texas порадовал контроллерами, может будем заказывать образцы и отладку.

Про Самсунга тоже гляну, но ( по-моему ) там потребуется внешняя память ( чего сильно не хотелось бы добавлять )...

C Texas'ами (Luminary) осторожнее, там в errata скрыта "камасутра".

[rezident]

По смотрите в сторону 9-х армов таких как этот S3C2440.
Там точно получиться.

Угу. Или LPC32x0, если BGA не пугает.
KKV2003, у нас сделали платку на LPC3250 + питание и память, для устройства с мезонинной конструкцией, например. Портировали на нее Linux. Пишите в личку, если интересует такой модуль.

[zksystem]

Лично я бы такой проект на FPGA делал

[KKV2003]

FPGA и ARM9 - это весьма тяжелая артиллерия. Не хотелось бы ее применять для наших "воробьев". Тяжело будет ( и по деньгам, и по времени, и по потреблению ).

Народ захватывает поток в 8 МГц на какой-то АТМеге16-й и ничего...

[zksystem]

Народ захватывает поток в 8 МГц на какой-то АТМеге16-й и ничего...

Вы бы подробнее описали что нужно сделать и какой поток, иначе не вижу смысла что-то тут обсуждать

[ukpyr]

Народ захватывает поток в 8 МГц на какой-то АТМеге16-й и ничего...

никакой "поток" с такой скоростью мега не захватит, придется писать во внутреннюю память (всего 1К), и никакую обработку сделать не получится - проц будет занят на 100%.

Так вот вопрос в том, сможет ли STM32F103 ( или что-то подобное ) управлять хотя бы записью во внешнюю память со скоростью порядка 10 МГерц или выше?

у STM32 есть модуль FSMC с DMA, но без поддержки SDRAM. Но получить одновременно чтение/запись 10МБ/сек вряд ли получится.

Сообщение отредактировал ukpyr - Oct 8 2010, 05:54

[kovigor]

Народ захватывает поток в 8 МГц на какой-то АТМеге16-й и ничего...

Верится с огромным трудом. Точнее, не верю. Проект тов. Чешко на 8-й меге, тот самый, который реализует USB LOW SPEED device, написан целиком на асме, и там все на пределе возможного, по сути. И всего-то 1.5 МБит. А тут 8 МГц. Не поверю, пока не увижу лично ...

[KKV2003]

Согласен, поверить трудно. Но сделано.
Смотрим, удивляемся: http://electronix.ru/forum/lofiversion/index.php/t49195.html
Причем из Меги выжаты все соки, но она справляется. Проект весьма удивительный. За 2 такта выдается новый 17-значный адрес...

Отсюда и пошло желание реально использовать возможности контроллеров. А их явно больше чем используется в большинстве задач...

Входной поток данных валится из выходного буфера микросхемы ( аналогично стеку ) по синхросигналу, который надо давать. Но задерживать синхросигналы не желательно - по ним идет не только выдача байт, но и другие задачи работают...

Необходимо использовать минимум корпусов и денег. Плата - предположительно мезанинного типа в небольшом корпусе...

C Texas'ами (Luminary) осторожнее, там в errata скрыта "камасутра".

Да, камасутра у них богатая... Даже не знаю. Искать С3-кристаллы придется...

[AlexandrY]

Согласен, поверить трудно. Но сделано.
Смотрим, удивляемся: http://electronix.ru/forum/lofiversion/index.php/t49195.html
Причем из Меги выжаты все соки, но она справляется. Проект весьма удивительный. За 2 такта выдается новый 17-значный адрес...

Отсюда и пошло желание реально использовать возможности контроллеров. А их явно больше чем используется в большинстве задач...

Тема избитая и не новая конечно. Нынче актуально не как взять данные с камеры, а как удобно их доставить потребителю.
Тогда посоветовал бы такой проект посмотреть: http://www.alylab.eu/OpenProjects/ARMDomin...bCam/WebCam.htm
За STR912 не агитирую, но в ST сделала такой же проект и на STM32.

[Lmx2315]

Вопрос как у автора темы только по проще:
Нужно на 10 МГц принять 128 байт (побайтно с сопровождением сигнала WR) на порт STM32f103 и после этого на такой же скорости выдать в формате 16 бит на другой порт.
Больше ничего мк делать не должен, справится ли?

з.ы.
Планирую заводить входные данные на порт, а сигнал WR на внешнее прерывание - по его срабатыванию считывать байт с порта и писать его в массив.
Как массив заполняется - читать из массива в порт + формировать сигнал WR2 - для сопровождения данных.

[scifi]

Планирую заводить входные данные на порт, а сигнал WR на внешнее прерывание - по его срабатыванию считывать байт с порта и писать его в массив.

Не успеет. Надо, чтобы сигнал WR вызывал запрос DMA (например, через таймер), и уже DMA прочитает порт. И всё равно нет гарантии, что успеет, потому что у STM32F1 порты относительно медленные. В этом плане STM32F2 и STM32F4 гораздо лучше.
Кстати, что мешает взять МК с внешней параллельной шиной? Или же DCMI у STM32 умеет быстро захватывать параллельные данные.

[Lmx2315]

Кстати, что мешает взять МК с внешней параллельной шиной? Или же DCMI у STM32 умеет быстро захватывать параллельные данные.

..такое дело - надо быстро решить одну задачу с помощью костылей которыми владею.
Вроде на вышеупомянутый STM32 написано что его порты могут работать на частоте до 18 МГц.
Если не успеет на 10 МГц , то примерно можно оценить теоретически на какой максимально частоте заработает?

[scifi]

Вроде на вышеупомянутый STM32 написано что его порты могут работать на частоте до 18 МГц.

Ну, если 18 МГц, то шансы есть, наверное. Кстати, а захват ограничен во времени? Если да, то я бы сделал так: заводим 8 бит и WR на 16-разрядный порт и читаем его в память непрерывно как можно быстрее. Когда посылка закончилась (надо это как-то определять, таймером что ли), разбираем содержимое памяти, выделяем там фронты WR и соответствующие данные.

[Lmx2315]

Ну, если 18 МГц, то шансы есть, наверное. Кстати, а захват ограничен во времени? Если да, то я бы сделал так: заводим 8 бит и WR на 16-разрядный порт и читаем его в память непрерывно как можно быстрее. Когда посылка закончилась (надо это как-то определять, таймером что ли), разбираем содержимое памяти, выделяем там фронты WR и соответствующие данные.

..как-то сложно это, сделать то можно конечно, только всё не пойму - почему по EXTI нельзя ловить WR и считывать порт в массив?
Я вообще думал что все проблемы будут по трате тактов на вход - выход в прерывание.

[gerber]

На STM32F103 (при FCPU=72 MHz) время между фронтом на пине и входом в EXTI-обработчик чуть меньше микросекунды (смотрел лично логическим анализатором), поэтому прокачать 10 МГц через прерывания по WR не получится.
А вот поллингом попробовать можно (как советовали выше), при запрещённых прерываниях, но вылизывать придётся каждую инструкцию цикла.

[jcxz]

А вот поллингом попробовать можно (как советовали выше), при запрещённых прерываниях, но вылизывать придётся каждую инструкцию цикла.

Даже поллингом и то сомнительно. Если, как писали, макс. частота GPIO у него 18МГц, то учтите что для ввода одного байта, нужно сделать минимум три чтения GPIO:
одно обнаруживает активное состояние WR, второе - читает данные, третье - обнаруживает неактивное состояние WR. И того - как минимум 3 чтения GPIO на один байт данных, а значит шина должна позволять читать GPIO с частотой >=30МГц - уже не пролазим. А ещё надо учесть все комады переходов и сохранений и пр. А данный МК (STM32F103) вроде как Cortex-M0? Так в M0 ещё и инструкции перехода очень многотактовые.
Можно конечно завести сигнал WR на один порт вместе с данными - так будет немного меньше чтений. Но всё равно не хватит, имхо.
Если же ещё можно изменить протокол передачи - стробировать данные не каким-то уровнем сигнала WR, а фактом его изменения, тогда можно обойтись только одним чтением порта на один байт данных.
Т.е. читаем 9-битный порт состоящий из данных+WR, если WR изменился - сохраняем мл.байт содержащий байт данных.
В этом случае есть шанс уложиться по скорости.
Особенно если ещё объединять каждые 4 чтения порта в одно выходное 32-битное значение и его уже писать в память. Очень аккуратно надо отнестись к команде условного перехода в конце цикла, может даже вообще отказаться от цикла - 128 байт - это немного - развернуть в линейный код да ещё расположить в ОЗУ. Да писать в память по 32 бита - вот тогда есть все шансы уложиться даже на STM32F103.

Ещё вариант - групповое стробирование. Т.е. выдаётся только один пульс WR в начале всего пакета, по нему делается синхронизация и дальше весь пакет читается просто чтениями порта данных с соответствующими задержками между чтениями. Делал когда-то такое для интерфейса между LPC1768 с CY7C68013A - работало стабильно - так удалось добиться максимальной скорости передачи по USB.

А с прерываниями - никаких шансов. 100МГц Cortex-M3 захлёбывается при частотах прерываний уже около 1МГц.

[ViKo]

А задать запись через DMA с порта в память по внешнему событию - WR?

[Aleksandr Barano...]

А данный МК (STM32F103) вроде как Cortex-M0?

Cortex-M3