связь Mega128 <=>ARM7 Опции

[IJAR]

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

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

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

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

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

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

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

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

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

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

[VladimirYU]

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

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

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

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

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

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

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

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

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

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

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

[mempfis_]

Скорость порядка 1 Мбайта.

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

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

[IJAR]

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

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

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

[SasaVitebsk]

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

Код

data ----<=====>----
           ____
rdy  ____/     \____
            _____
ask ______/      \___

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

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

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

[alvy]

Как вариант:

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

Сообщение отредактировал alvy - Jun 9 2009, 07:56

[IJAR]

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

Код

data ----<=====>----
           ____
rdy  ____/     \____
            _____
ask ______/      \___

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

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

Как вариант:

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

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

[SasaVitebsk]

Замена Mega128(Fosc=7.372800 МГц) на что-либо невозможна из-за разработки большого объема ПО.

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

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

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

[IJAR]

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

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

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

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

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

Как вариант:

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

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

[singlskv]

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

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

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

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

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

[Dog Pawlowa]

Замена Mega128(Fosc=7.372800 МГц) на что-либо невозможна из-за разработки большого объема ПО.

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

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

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

[xelax]

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

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

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

[IJAR]

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

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

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

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

[zltigo]

1. У меня сейчас в проекте Mega128 + FT245BM от FTDI и далее USB HOST в PC104 под Win5.0 CE и все работает
Но вот вместо PC104 есть желание поставить ARM7. Использование чипа VINCLUM со стороны ARM7 оказалось проблематично
из-за нестабильности времени обмена.

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

2. Скорость ~ 1Mбайта: UART, I2C, SPI этого не обеспечат+ большие нагрузки ра обслуживание.

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

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

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

Так вот исключения вроде data и perfetch абортов около полугода выскакивали и время и нервов на вычищения пришлось потратить прилично.

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

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

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

[Dog Pawlowa]

мне как разработчику известны все нюансы

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

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

[IJAR]

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

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

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

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

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

[Sanya_kv]

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

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

[SasaVitebsk]

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

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

[IJAR]

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

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

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

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

[proba]

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

Сообщение отредактировал proba - Jun 9 2009, 14:20

[Dog Pawlowa]

+ .... ну я думаю тут все знают что к этому еще вагонетка всякой всячины

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

[SasaVitebsk]

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

[defunct]

Скорость порядка 1 Мбайта. Расстояние между конт-ми ~10 см на
плате.
Хотелось бы со стороны каждого контроллера иметь буфер организованный в виде стека на 256 - 1024 байт а уже между
буферами что то вроде параллельног канала. Т.е. минимальная

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

[IJAR]

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

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

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

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

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

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

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

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

[GDI]

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

Прикрепленные файлы

 EE213v02.pdf ( 129.37 килобайт ) Кол-во скачиваний: 47

 

[IJAR]

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

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

[artem79]

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

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

[zltigo]

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

[Dog Pawlowa]

Зачем плодить уродство.

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

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

[proba]

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

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

Сообщение отредактировал proba - Jun 12 2009, 07:45

[SasaVitebsk]

a вообще то ожидал бы от суперадминна больще толерантности, подход типа "мое мнение и неправильное мнение" не особо убедителныи.

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

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


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

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

[zltigo]

a вообще то ожидал бы от суперадминна больще толерантности, подход типа "мое мнение и неправильное мнение" не особо убедителныи.

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

[=GM=]

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

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

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