Необходимо организовать обмен между 2-мя контроллерами.

Скорость порядка 1 Мбайта. Расстояние между конт-ми ~10 см на
плате.

Хотелось бы со стороны каждого контроллера иметь буфер организованный в виде стека на 256 - 1024 байт а уже между

буферами что то вроде параллельног канала. Т.е. минимальная

нагрузка на ПО контроллеров. Для работы с навеской есть по 11 ног

в каждом контроллере. Прямое соединение не катит из-за разности

в скоростях контроллеров.USB - не подходит по ряду причин.

Естественно эта навеска должна быть в чипе. Цена не особеноо лимитирует.

Может кто использовал такой девайс.

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

Ну про USB для меги128 забудь сразу и навсегда. А вот где проблема порылась? Чем не устраивают стандартные SPI или TWI(I2C) или USART? А с размерами буферов сами разберетесь.

Большая скорость. А мега сможет обеспечить такой поток данных?
Можно попробовать завести SPI с удвоением скорости (на 16МГц вроде скорость должна быть F/2 = 8Мбит), но и времени на аппаратную обработку практически не остаётся. Если выводить через паралельный порт то врятли будет достигнута такая скорость (2 такта получить данные из памяти или порта, 2 такта положить их порт, 2 такта выставить готовность данных, есщё несколько тактов дождаться подтверждения, плюс время на обработку - при грубом подсчёте даже 1 мегабайта не получается)

А откуда собственно берётся такой поток данных? может быть там нужна ПЛИС или второй ARM7?

1. У меня сейчас в проекте Mega128 + FT245BM от FTDI и далее USB HOST в PC104 под Win5.0 CE и все работает
Но вот вместо PC104 есть желание поставить ARM7. Использование чипа VINCLUM со стороны ARM7 оказалось проблематично
из-за нестабильности времени обмена.
2. Скорость ~ 1Mбайта: UART, I2C, SPI этого не обеспечат+ большие нагрузки ра обслуживание.

Вот если бы можно было соединять 2 FT245 друг сдругом - все было бы O'K

Я делал параллельный обмен м/у контроллерами. Принцип приблизительный как в CENTRONICS.



Здесь 10 ног, но чаще всего требуется типа команды передавать (1 нога) ну и направление (1 нога), либо синхронизацию начальную как-то обеспечивать. 11 ног принципиально достаточно. У меня было столько-же. Работало очень устойчиво.



Их можно соединить даже без микроконтроллера. На примитивной логике. Только 1 Мбайт это скорее желаемое чем бействительное значение. Хотя заявлено 2. Надо будет программно обеспечивать чтобы переполнения буферов не происходило.

Как вариант:

использовать чтото типа 74АС164, которую к SAM7 подцепить по SPI (1МГц без проблем прокачает), а к Меге подцепить многоразрядную шину с битами управления. Просто, имхо, меге будет намного проще и быстрее работать с параллельным интерфейсом, а САМ7 - с последовательным (в режиме DMA будет минимум ресурсов расходоваться).

Я такой вариат и рассматривал, НО!!!
Я не могу обеспечить на Mege непрерывное, из-за прерываний, обслуживание потока.
Стало быть ARM7 войдя в обмен бужет непредсказуемо подвисать, если же использовать на
нем прерывания, то это приплюсует еще большее время на обслуживание. У ARM7 своих задач выше крыши.
Замена Mega128(Fosc=7.372800 МГц) на что-либо невозможна из-за разработки большого объема ПО.


SPI на ARM7 занят под контроллер ETHERNET, кроме того заняты 2 UART-a.

Всё смешалось, кони-люди.

А как вы обеспечите "около 1 Мбайта" на микроконтроллере с пиковой производительностью 7Мипсов, если он ещё чем-то занят? Это и так 7 тактов на транзакцию. О каких прерываниях мы ведём речь? И куда этот поток складывать?

Да и ARM7 с потоком 1Мбайт тоже будет напряжённо громыхать костылями.

В том то и суть, что порт обмена должен быть "всегда готов", ну кроме начала обмена (возможно)
А передача идет блоками по 0.5-1.5КБайт каждые 100 mS. Если кидать блоками не более 0.5 Кбайт,
то на это время прерывания, в моем случае, можно "придержать".

Собственно всего то и нужен чип "Параллельный порт CENTRONIX с буфером памяти"




А вообще то идея не плохая. У ETHERNET чипа можно вместо SPI || порт использовать
На "худой конец" можно и так попробовать.
Спасибо!

1Мбайт/сек на Fosc=7.372800 МГц выглядит как-то малореалистично.
А вот если поднять до Fosc=14.7456 то примерно потянет, ну или урезать осетра(1Мбайт/сек)

Я бы соединял по SPI но не напрямую. В разрыв можно поставить SPI RAM(23K256 от микрочипа) или
SPI FRAM(FM25xx), ну и пару линий квитирования для разграничения доступа к ней,
тогда ARM7 по DMA сможет пару мбайт/сек прокачивать а Mega уже как будет успевать.

бывают ведь и с 2мя SPI на борту.

Да, повеселили.

Перевод проекта среди MSP430 <> AVR <> STM32 <> LPC, если ресурсов хватает, требует неделю максимум. Чем больше ресурсов - тем быстрее.

Так что скажите лучше, что ПО на AVR написано бессистемно, а программист забил и уволился.

Вот только ненадо шапкозакидательства.
Есть приличный опыт перевода систематизированного кода(в котором строго соблюдался стиль, кодестайлинг и который постоянно ревьюили) с AVR на ARM. Так вот исключения вроде data и perfetch абортов около полугода выскакивали и время и нервов на вычищения пришлось потратить прилично.
Так что не вводите в заблуждение.

А если написанно бессистемно и программист уволился, то точно такую авантюру затевать не стоит. Зашьёшься на 2-3 месяца. И ещё столько же свои баги ловить потом будешь.

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

На том "ARM7", который Вы используете свет клином не сошелся (впочем, ка и вообще на ARM7). Возьмите, например, от NXP с вполне приличным USB Host и попробуйте оставить, как есть

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

Что OK- то? Дрыгание ножками кажется панацеей?



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



Да , хотя и Автор пытается строить хорошию "мину" и слепить их того, "что было".

В такой обработке - нет вопросов

А по теме, если рассуждать логически ...
Любой интерфейс на AVR отнимет практически все ресурсы производительности -> Значит, интерфейса не должно быть -> значит, данные должны оказаться в адресном пространстве AVR без передачи по интерфейсу -> значит, двупортовая память (или самопальное аппаратное решение, обеспечивающее доступ к одной и той же памяти, в данном случае достаточно разделенное во времени).

Именно так я и рассуждал, с точностью до запятых.
Скажу больше - была идея вообще поставить вместо Mega128 ARM7, по ногам проходим,
по времени доступа к данным с HardWare тоже пропихнуться получится => данные сразу
лягут в адресное пр-во ARM7. Но.....как всегда есть НО!
Например атестация аппаратуры вместе с ПО - длительный и финансовоемкий процесс.
Пусть на M128 soft писали 33 программиста, пусть там заплатка на заплатке, но оно АТТЕСТОВАНО и работает, т.е. обеспечивает
необходимый функционал аппаратуры.
Не говоря уже о производсте: что делать с заделом печатных плат? и т.п. - Вы же не "1-й год замужем"
все прекрасно понимаете.

Двухпортовка - конечно выход и в эту сторону придется смотреть, но я все же надеялся на решение "малой кровью"
вдруг кто-нить поизводит нужный мне кристальчик не за дорого.

М-да-а-а-а-а.

Можешь организовать синхронизацию от АТмega.

При нормально написанном проекте, изменение тактовой частоты с 7.3728 на 14.7456 = изменению одной константы. У меня, по крайней мере, это так.

На 14МГц, согласно вашего описания проекта, при приостановке остальной деятельности вполне возможна реализация любым из перечисленных способов. Если учитывать, что ARM7 более серьёзно завален работой, а AVR - обслуживание переферии, то лучше применить какую-нибудь логику. Применять ОЗУ двухпортовое, я бы не стал. Уж лучше проект полностью переписать на новых камнях. Баги меньше вылавливать будешь, чем сбои.

Легко. Как только на M128 готовы данные она может пнуть ногой ARM.





Маловато будет.
Надо еще номинал кварца изменить в документации
+это изменение согласовать с производством(комплектация)
+ скорректировать методику проверки платы (там проверяется тактовая частота)
+всю эту байду заложить в архив
+ .... ну я думаю тут все знают что к этому еще вагонетка всякой всячины

если Вам понадобился скорость обмена >100Mbit, советовал бы двухпортовыи FIFO, как SN74ABT7820 , как вариант можете смотреть, хотя imho overkill тотально.
http://focus.ti.com/lit/ds/scas206d/scas206d.pdf
данныи чип 18бит, но выпускают и 8/9 битные. кроме TI и IDT и Cypress выпускают.
FIFO можно соединить к внешнеи шине мк , у мега128 оно имется но подходящии арм можно наити.

Я тоже старр и устал от жизни Но к технике это отношения не имеет.

Ну а если применить какое-нибудь озу двухпортовое или регистр или фифо, то изменений в прогу вносить не придётся? К комплектации это отношения не имеет?

Для этих требований подошла бы двухпортовая память.
Один порт на шину меги, второй на шину ARM'а.
Средняя производительность при работе с внешней памятью блоками по 512 байт со стороны меги порядка 2MByte/s.

В бой идут одни старики?

...Нам бы схемку аль чертеж
Мы б затеяли вертеж
Ну так ищи что хочешь
Черта лысого - найдешь.

Видно ответы в этой ветке навеяли .....



Спасибо, оценил - похоже то что ищу!


Сейчас к Mega128 подключен FT245BM - это 8 бит данных (PB0..PB7))+6 управляющих линий (отдельные ноги портов)
11 из них выведены на разъем (технологический). Обращение к FT245BM из проги как к буферу FIFO так что прога скорее всего
не полетит.
Устройство с ARM7 будет разрабатываться вновь отдельной платой (там можно творить многое)
В основной пате есть место для установки этого доп устройства (собственно оно заменит PC104)

Во вложении схемка и описание параллельного интерфейса через параллельный регистр для связи 2х контроллеров на примере blackfin, но думаю, что можно ее адаптировать для АВР и АРМ7, или хотя бы идею почерпнуть.

Спасибо, интересно.

Поставьте ПЛИС и делайте что хотите. Хоть FIFO, Хоть SRAM, Хоть SDRAM. Параллельный или последовательный как душе угодно. И интерфейс взамен FT- ки без проблем организуете и со скоростями проблем не возникнет. 1 Мбайт/с пакетами по 64к без проблем (сам делал на FT245R). И память в этом же кристале. Ресурсов много не займет. Еще останется для какой нибудь попутной задачки.

Ну а теперь, кто из изобретателей интерфейсов скажет в чем их отличие от, например, того-же банального SPI . Двухпортовая RAM/Fifo (дорогие, редкие, умирающие - в серии отакзались уже от них лет пять назад, идущее вразнос при сбоях..), а также они-же, но в FPGA , еще преимущества имееет из-за работы в качестве буфера, но если не махать на ARM ногами для эмуляции шины. Если ARM имеет внешнюю память, он до кучи имеет и всякие вкусности, типа того-же уже используемого USB...
Зачем плодить уродство.

Я чуть ли не первым упомянул двухпортовую RAM, и на уродство отвечу

1) Вообще-то сама попытка подобного проекта - уродство. Постановка задачи в виде наличия AVR, очевидных существенных переделок проекта, и в то же время сохранения проекта по прежнему странна.
2) А термин применил, чтобы всем было понятно, что доступ должен быть с двух сторон, если AVR и проект на нем так ценнен, что даже частоту не изменить.
Кстати, чем ставить двухпортовую память, будет проще заткнуть AVR сбросом, чтобы он замер, пока ARM в память данные не напишет. Двух портовка точно не нужна будет, достаточно будет шинных формирователей и пары регистров. Или все ресурсы заняты SPI, или контроллер вообще вырублен - разницы никакой.

с многоядерных систем 2портовые как были так и остались, но интегрировать стали, например OMAPы и разные дсп кластры ( sharc ) . иногда и видеовходы и тфт драиверы с фифо буферируют если архитектура мк требует. a вообще то ожидал бы от суперадминна больще толерантности, подход типа "мое мнение и неправильное мнение" не особо убедителныи.

Ну может же он высказать своё мнение как просто разработчик?

Я, к слову, разделяю его мнение тоже. Передёргивать то не надо, речь ведь не идёт о "многоядерных OMAPах", разведённых на соответствующих платах и стоимость разработки/отладки соответствующая. А здесь это явно притянуто за уши. Помудохается он с этой памятью + прога то полетит. И я это знаю, и вы и он. Так зачем как страус голову в песок совать? Лучше прямо об этом сказать. И лучше в отрезвляющих выражениях.


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

А не хотите менять - не надо . Реализуйте протокол 245-ой на ARM. Там он по типу того, что я тут рисовал сделан. Если ARM перегружен, введите промежуточную микруху типа той же меги8 за 1$. Ей передавайте по SPI, а на ней формируйте протокол 245. Или сразу с ARMа гоните USB (что конечно же предпочтительнее).

Вольному - воля, Вы совершенно вольны назвать любое мнение не особо убедительным. Равно, как и я, волен высказать свое. А вообше речь идет не только о мнении, но и опыте . SasaVitebsk видно, не спроста не любит двухпортовую память/FIFO - просто он с ней, как и я сталкивался. Мрачная штука - в свое время сталкивался с "изделием" 51 висящий на ISA . Шаг в сторону - расстрел. Программная борьба с аппаратными сбоями по полнй программе. Да разводка оставляла желать лучшего, но и две или три преразводки не помогли существенно.

Чтобы и волки были целы и овцы сыты, я бы вам посоветовал вместо FT245BM поставить самую простую аврку, имеющую 3 порта и память порядка 0.5 КБ и тактовую 20 МГц. Один порт и 2-3 управляющих вывода подключаете к меге128, а второй порт и 2-3 управляющих вывода подключаете к арму. Задача аврки очень проста - вечно стоять в ожидании и принимать на максимальной скорости 256 байт из меги128 по заданному протоколу. А после завершения приёма - передать буфер в арм, возможно по другому протоколу.

По моей оценке максимальная скорость приёма составит 5 МБайт/с, что в 5 раз превосходит требуемую.