Как узнать с какой частотой максимально можно дрыгать ножкой?(asm незнаю).
Хочу подключить авр через FT245BM(FIFO-USB) к усб компьютера. И разогнать его до 8Mbps, сижу вот думаю, успеет ли авр ножками дрыгать или не успеет. dsp не очень хочется ставить из за USB.

Выдавать 8 МБ/С не успеете. Реальна примерно половина при тактовой 16-20.

Ну половина тоже в принципе устроит. надо сделать переходник USB-CAN. если с USB получать ~4Mbps то на CAN задержек не должно быть. но хотелось бы точнее знать, с какой скоростью авр сможет в FIFO данные закатывать.

Тогда это надо делать на камне с CAN и USB.
По другому такой пропускной способности не получить ИМХО.

У AVR команды cbi/sbi (сбросить/установить ногу порта) - 2 такта, in/out (чтение/запись порта) - 1 такт. Остальное прикидывайте сами.

4Мбит/с - это очень много для AVR, если нужна хотя бы малейшая обработка.

ок. решено ставить DSP от TI на 60Mhz. На нем точно получиться сделать нормальный переходник, чтобы в CAN на 1Мбит не было задержек связанных с низкой скоростью USB->микроконтроллер+ будет время над командами подумать.

8Mbps - обычно под этим подразумевается 8 мегаБИТ, а не мегабайт. Так что и АВР успеет.
А вот CAN с такой скоростью трудно себе представить. Обычно скорость CAN выбирается небольшой, тут главное гарантированная доставка сообщения, а не скорость. Да и не смогут CAN трансиверы с такой скоростью работать, там гарантированная скорость 1 мегабит, например у PCA82c250. При этом нормальная работа обеспечивается на очень небольших расстояниях, <20 метров.
Если все же нужна большая скорость, то лучший выбор это АРМ с обоими этими интерфейсами, типа LPC2378.

речь естественно шла о мегабитах. CAN будет работать на 1Mbps, следовательно передача данных от компьютера к микроконтроллеру должна быть намного выше чем 1Mbps, чтобы не было задержек + МК должен успевать по быстрому, принятые по USB пакеты(а принимать он будет по каком нибудь протоколу, что тоже процессорное время на обработку) преобразовывать в годный для отправки по CAN формат. народ говорит, что авр не потянет. пока верю. АРМ незнаю и нехочу, ибо дсп заменят мне почти любой арм.

Я месяц назад как раз делал нечто подобное: Мега8, 16 Мгц, FT245BM.

Максимум на что мне удалсь подняться -- это 360 КБайт/с. Каждый байт мега выбирала из своей памяти и закидывала его в FT245BM за 2.75 us. Потом в работе с 245-ым, естественно, возникала небольшая пауза, связанная с накоплением новой порции инфы и другими прочими делами, типа посмотреть "а не пришло-ли что с юсб" или "не нажал-ли какую-нибудь кнопочку юзер", ну и т.д, и т.п.

Прогу я писал ислючительно на Си (CV 1.25.3), ассемблер не использовал.

Прога высылает и получает инфу в виде коротких пакетов. Передаваемая инфа -- это двоичные данные. Пакеты передается в виде неперерывного потока. Соответственно, на приемном конце возникает проблема: обратно выделять из непрерывного потока эти пакеты, т.е. нужно уметь как-то идентифицировать начало каждого пакета. Я пошел по пути "стаффинга". Исходники приложил (1.45 KB). Они выдернуты из рабочего проекта, работают без нареканий. Юзайте на здоровье!

Если часть кода напишите на асме, то, думаю, сможете поднять скорость передачи раза в два.

Удачи!

Можно использовать контроллеры от Freescale с соответствующей периферией. ИМХО: DSP по периферии далеко не всегда может заменить контроллер.

Спасибо. Но думаю мне с авр в данном проекте не по пути


Наверное год не был на форуме, и думал, что чудо под названием а_в_р123 вымерло. Оказывается нет. живет и процветает.

Сам не понимаю. Те же Cygnal куда богаче и по периферии, и по производительности, да и по цене часто выгоднее..


Конечно, без обработки, причем передача блока - с развернутым раз в 8 циклом для ускорения.

Вы просто не в курсе, тут есть персонаж, из-за которого были забанены некоторые слова (типа avr123). Он похоже опять реинкарнировался под ником Abckur

А если рассмотреть вариант с AT76C713 - МК с системой команд AVR, работает на тактовой 48 МГц, есть встроенный USB, ещё и DMA есть. Ногами обдрыгаетесь.

Atmel на него забила - NRND. По этой причине он изначально не может подлежать рассмотрению.

Ну это как идея. Можно взять что-то типа at90usb1286.

Кстати, вот ещё вариант: взять at90usb1286 с usb на борту и добавить at90can128 с can на борту. И голову ломать не надо, чем дрыгать: принял - передал, и забыл.

Неужели будет проще и дешевле чем LPC2378 за 10$ с обоими интерфейсами в одном корпусе? Там и скорости хватит и цена невеликая. Одна at90can128 стоит дороже....

Это будет дороже. Я арм незнаю, а его изучение займет время=деньги.+ примеров под CAN для LPC2378 нет,с нуля я не хочу поднимать его. самый простой и дешевый вариант TMS320F28016, стоит
7$.задрыгает любого до смерти.

Ну не знаю. У меня живет один проект с 2002 года. Сделан на АТ89S8252 и FT232BM, плюс три восьмиразрядных регистра. С небольшой обработкой пуляет в компьютер на скорости 460кб/с. Сделано около 50-ти устройств. Ни одного нарекания не было.

Уважаемый Igor26, у меня нет никакого желания мериться с Вами пиписками. При разработке проекта у меня не было задачи "передать данные на максимальной скорости". Ширина потока моих данных составляет всего 10-20 килобайт в секунду, поэтому, мощьности получившегося канала (360 килобайт в секунду) мне хватило за глаза. РАзумеется, еще повышать скорость, не было совершенно никакой необходимости. Я указал "честную" скорость 360 кБ/с, которую я получил в реальном изделии. Получил, не прибегая к каким-либо ухищрениям.

А то, что Вы смогли получить скорость 460 килобайт (кстати, килобайт пишется не "кб", а -- "кБ" или "кБайт".) в секунду -- это тоже хорошая цифра. "Хорошая" в том плане, что дает ориентацию разработчикам, которые подошли к вопросам передачи данных через USB. Когда я начинал свой USB-проект, я ведь тоже не знал, на какую скорость я могу рассчитывать. Одно дело синтетические тесты и заявления производителей, и другое -- реальная жизнь.

Я вот сейчас смотрю на сохраненые осциллограммы и вижу, что после получения очередного байта FT245BM снимет готовность к приему (TXE) на 460..600 ns. Импульс записи (WR) -- уменя 125 ns, отсюда предельно возможная скорость передачи из меги в FT будет = 1 / (600 + 125) = 1.4 МБ/с или (11.2 Мб/с). Но в реальных устройствах процессорное время расходуется не только на передачу данных. Поэтому появляются накладные расходы, которые неизбежно приводят к снижению скорости передачи. Смысл поднятого в топике вопроса состоит не в том -- с какой максимальной скоростью данные можно передать, а в том -- с какая максимальная скорость реально получается.

Мы же здесь не спортсмены, а разработчики. Почувствуйте разницу.

Игорь, как я понимаю, использовал внешнюю шину памяти 52-го. Для 2-х MIPSового процессора 460Kbyte/s вполне реальная скорость.
В случае 16-ти MIPSового AVR если использовать шину памяти (m162 / m128), то 4 MByte/s вполне достижимая скорость и даже останется время для маломальской обработки.


В реальных условиях подключаете FTшку к шине m162 через буфер и будет щастье. Расхода на передачу практически 0 - как массив перегнать из одного участка памяти в другой.

Точно так.

+1 Да, да да!!!

А я о чем говорил? Zhevak, не понятно, что Вы обиделись:-(

Подскажите а есть готовые проекты реализации CAN на мега8, 16 либо 32?

почему бы сразу не заложить в схему контроллер с аппаратным CAN, тот же AT90CAN32 ?

Как то в сети видел драйвер для SJA1000, под авр. если не найдете, могу у себя поискать.
А вообще было бы разумней, как тут уже посоветовали, воспользоваться камнем с аппаратным CAN. at90can128. can32/64 - очень сложно купить

уже не сложно! мы как раз перешли на CAN64 они заметно дешевле CAN128, а вот CAN32 мало по цене от 64 отличается.

Неа.
Для FTDI заявленная скорость - 1Мбайт в сек. Думаю и уту цифру со стороны FTDI получить будет затруднительно.

Это ограничение USB full speed (FTDI тут ни при чём). 16 пакетов по 64 байта за кадр (1 мС) максимум. Контрольный канал не используется (ещё 1 пакет).

извиняюсь за офф. но где вы покупаете at90can64??