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

[IJAR]

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

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

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

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

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

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

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

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

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

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

[SasaVitebsk]

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

Код

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

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

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

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

[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.

[Dog Pawlowa]

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

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

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

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

[IJAR]

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

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

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

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

[Dog Pawlowa]

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

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

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

[IJAR]

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

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

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

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

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