IJAR 0 9 июня, 2009 Опубликовано 9 июня, 2009 · Жалоба Необходимо организовать обмен между 2-мя контроллерами. Скорость порядка 1 Мбайта. Расстояние между конт-ми ~10 см на плате. Хотелось бы со стороны каждого контроллера иметь буфер организованный в виде стека на 256 - 1024 байт а уже между буферами что то вроде параллельног канала. Т.е. минимальная нагрузка на ПО контроллеров. Для работы с навеской есть по 11 ног в каждом контроллере. Прямое соединение не катит из-за разности в скоростях контроллеров.USB - не подходит по ряду причин. Естественно эта навеска должна быть в чипе. Цена не особеноо лимитирует. Может кто использовал такой девайс. Заранее спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VladimirYU 0 9 июня, 2009 Опубликовано 9 июня, 2009 · Жалоба Необходимо организовать обмен между 2-мя контроллерами. Скорость порядка 1 Мбайта. Расстояние между конт-ми ~10 см на плате. Хотелось бы со стороны каждого контроллера иметь буфер организованный в виде стека на 256 - 1024 байт а уже между буферами что то вроде параллельног канала. Т.е. минимальная нагрузка на ПО контроллеров. Для работы с навеской есть по 11 ног в каждом контроллере. Прямое соединение не катит из-за разности в скоростях контроллеров.USB - не подходит по ряду причин. Естественно эта навеска должна быть в чипе. Цена не особеноо лимитирует. Может кто использовал такой девайс. Заранее спасибо. Ну про USB для меги128 забудь сразу и навсегда. А вот где проблема порылась? Чем не устраивают стандартные SPI или TWI(I2C) или USART? А с размерами буферов сами разберетесь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mempfis_ 0 9 июня, 2009 Опубликовано 9 июня, 2009 · Жалоба Скорость порядка 1 Мбайта. Большая скорость. А мега сможет обеспечить такой поток данных? Можно попробовать завести SPI с удвоением скорости (на 16МГц вроде скорость должна быть F/2 = 8Мбит), но и времени на аппаратную обработку практически не остаётся. Если выводить через паралельный порт то врятли будет достигнута такая скорость (2 такта получить данные из памяти или порта, 2 такта положить их порт, 2 такта выставить готовность данных, есщё несколько тактов дождаться подтверждения, плюс время на обработку - при грубом подсчёте даже 1 мегабайта не получается) А откуда собственно берётся такой поток данных? может быть там нужна ПЛИС или второй ARM7? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IJAR 0 9 июня, 2009 Опубликовано 9 июня, 2009 · Жалоба Ну про 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SapegoAL 0 9 июня, 2009 Опубликовано 9 июня, 2009 · Жалоба Я делал параллельный обмен м/у контроллерами. Принцип приблизительный как в CENTRONICS. data ----<=====>---- ____ rdy ____/ \____ _____ ask ______/ \___ Здесь 10 ног, но чаще всего требуется типа команды передавать (1 нога) ну и направление (1 нога), либо синхронизацию начальную как-то обеспечивать. 11 ног принципиально достаточно. У меня было столько-же. Работало очень устойчиво. Вот если бы можно было соединять 2 FT245 друг сдругом - все было бы O'K Их можно соединить даже без микроконтроллера. На примитивной логике. Только 1 Мбайт это скорее желаемое чем бействительное значение. Хотя заявлено 2. Надо будет программно обеспечивать чтобы переполнения буферов не происходило. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alvy 0 9 июня, 2009 Опубликовано 9 июня, 2009 (изменено) · Жалоба Как вариант: использовать чтото типа 74АС164, которую к SAM7 подцепить по SPI (1МГц без проблем прокачает), а к Меге подцепить многоразрядную шину с битами управления. Просто, имхо, меге будет намного проще и быстрее работать с параллельным интерфейсом, а САМ7 - с последовательным (в режиме DMA будет минимум ресурсов расходоваться). Изменено 9 июня, 2009 пользователем alvy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IJAR 0 9 июня, 2009 Опубликовано 9 июня, 2009 · Жалоба Я делал параллельный обмен м/у контроллерами. Принцип приблизительный как в 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. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SapegoAL 0 9 июня, 2009 Опубликовано 9 июня, 2009 · Жалоба Замена Mega128(Fosc=7.372800 МГц) на что-либо невозможна из-за разработки большого объема ПО. Всё смешалось, кони-люди. :) А как вы обеспечите "около 1 Мбайта" на микроконтроллере с пиковой производительностью 7Мипсов, если он ещё чем-то занят? Это и так 7 тактов на транзакцию. О каких прерываниях мы ведём речь? И куда этот поток складывать? Да и ARM7 с потоком 1Мбайт тоже будет напряжённо громыхать костылями. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IJAR 0 9 июня, 2009 Опубликовано 9 июня, 2009 · Жалоба Всё смешалось, кони-люди. :) А как вы обеспечите "около 1 Мбайта" на микроконтроллере с пиковой производительностью 7Мипсов, если он ещё чем-то занят? Это и так 7 тактов на транзакцию. О каких прерываниях мы ведём речь? И куда этот поток складывать? Да и ARM7 с потоком 1Мбайт тоже будет напряжённо громыхать костылями. В том то и суть, что порт обмена должен быть "всегда готов", ну кроме начала обмена (возможно) А передача идет блоками по 0.5-1.5КБайт каждые 100 mS. Если кидать блоками не более 0.5 Кбайт, то на это время прерывания, в моем случае, можно "придержать". Собственно всего то и нужен чип "Параллельный порт CENTRONIX с буфером памяти" Как вариант: использовать чтото типа 74АС164, которую к SAM7 подцепить по SPI (1МГц без проблем прокачает), а к Меге подцепить многоразрядную шину с битами управления. Просто, имхо, меге будет намного проще и быстрее работать с параллельным интерфейсом, а САМ7 - с последовательным (в режиме DMA будет минимум ресурсов расходоваться). А вообще то идея не плохая. У ETHERNET чипа можно вместо SPI || порт использовать На "худой конец" можно и так попробовать. Спасибо! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
singlskv 0 9 июня, 2009 Опубликовано 9 июня, 2009 · Жалоба Я не могу обеспечить на 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 на борту. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 9 июня, 2009 Опубликовано 9 июня, 2009 · Жалоба Замена Mega128(Fosc=7.372800 МГц) на что-либо невозможна из-за разработки большого объема ПО. Да, повеселили. Перевод проекта среди MSP430 <> AVR <> STM32 <> LPC, если ресурсов хватает, требует неделю максимум. Чем больше ресурсов - тем быстрее. Так что скажите лучше, что ПО на AVR написано бессистемно, а программист забил и уволился. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xelax 0 9 июня, 2009 Опубликовано 9 июня, 2009 · Жалоба Перевод проекта среди MSP430 <> AVR <> STM32 <> LPC, если ресурсов хватает, требует неделю максимум. Вот только ненадо шапкозакидательства. Есть приличный опыт перевода систематизированного кода(в котором строго соблюдался стиль, кодестайлинг и который постоянно ревьюили) с AVR на ARM. Так вот исключения вроде data и perfetch абортов около полугода выскакивали и время и нервов на вычищения пришлось потратить прилично. Так что не вводите в заблуждение. А если написанно бессистемно и программист уволился, то точно такую авантюру затевать не стоит. Зашьёшься на 2-3 месяца. И ещё столько же свои баги ловить потом будешь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IJAR 0 9 июня, 2009 Опубликовано 9 июня, 2009 · Жалоба Да, повеселили. Перевод проекта среди MSP430 <> AVR <> STM32 <> LPC, если ресурсов хватает, требует неделю максимум. Чем больше ресурсов - тем быстрее. Так что скажите лучше, что ПО на AVR написано бессистемно, а программист забил и уволился. Ну, если Вам стало весело, я не возражаю. Но я не собираюсь дискутировать на тему "как и за сколько перейти с одного контроллера на другой", считайте что в моем случаеб а мне как разработчику известны все нюансы, подобный подход не является целесообраным. Если Вам есть что сказать по теме - рад буду прочитать, в противном случае есть другой раздел форума. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 9 июня, 2009 Опубликовано 9 июня, 2009 · Жалоба 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 абортов около полугода выскакивали и время и нервов на вычищения пришлось потратить прилично. Значит действительно все было совершенно не так, как Вы оптимистично утверждали относительно качества исходного восьмибитового кода :( Всё смешалось, кони-люди. :) Да :(, хотя и Автор пытается строить хорошию "мину" :( и слепить их того, "что было". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 9 июня, 2009 Опубликовано 9 июня, 2009 · Жалоба мне как разработчику известны все нюансы В такой обработке - нет вопросов :) А по теме, если рассуждать логически ... Любой интерфейс на AVR отнимет практически все ресурсы производительности -> Значит, интерфейса не должно быть -> значит, данные должны оказаться в адресном пространстве AVR без передачи по интерфейсу -> значит, двупортовая память (или самопальное аппаратное решение, обеспечивающее доступ к одной и той же памяти, в данном случае достаточно разделенное во времени). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
