roboforum.ru

Собственно надеюсь тема будет очень короткая

Модуль должен будет работать как программатор, так и как адаптер (как вариант - переключатель тупо на нём).

Принимаются пожертвования в виде линков

Основной вопрос - делать на базе FT232 или нет. Пока склоняюсь к мнению, что делать на нём.

Добавлено спустя 50 секунд:
Есть еще бредовая мысль сделать двухстороннюю плату - запаял одну сторону - получил адаптер для USB, запаял другую - для COM

А чего тут думать то? Адаптеры RS-232 и USB - стандартные MAX232 и FT232 (или PL-2303). Программатор - AVR910+AVR911.

=DeaD= писал(а):Есть еще бредовая мысль сделать двухстороннюю плату

Нормальная мысль. Даже больше - запаял обе стороны - и перестановкой джампера переключаешь задействованный интерфейс.

фтопку ft232
у него известный косяк на 115200 - буферизует данные, кидаешь 10 байт - либо они пройдут через несколько секунд, либо по заполнению буфера.
Даешь на CY7Cxxxx
Ну или хотя бы на контроллере, у которого есть юсб девайс, чтобы не ограничивать себя тока последовательным портом.

где описан этот баг FT232?

Хз где официально описан, на зарубежных форумах иногда поднимается эта тема в контексте arduino... мне кажется что даже с ftdi на эту темы пытались связаться разработчики ардуины, но безуспешно...

Ну вот, а у меня FT232 лежат уже вроде

у какой именно ревизии такой баг?
что именно надо сделать что бы он проявился?
у меня на столе штук 30 девайсов с FT232, хочу проверить

An effect that is not immediately obvious is the way the size of the USB total packet request has on
the smoothness of data flow. When a read request is sent to USB, the USB host controller will
continue to read 64 byte packets until one of the following conditions is met:
1. It has read the requested size (default is 4 Kbytes).
2. It has received a packet shorter than 64 bytes from the chip.
3. It has been cancelled.
While the host controller is waiting for one of the above conditions to occur, NO data is received by
our driver and hence the user's application. The data, if there is any, is only finally transferred after
one of the above conditions has occurred. one of the above conditions has occurred.
Normally condition 3 will not occur so we will look at cases 1 and 2. If 64 byte packets are
continually sent back to the host, then it will continue to read the data to match the block size
requested before it sends the block back to the driver. If a small amount of data is sent, or the
data is sent slowly, then the latency timer will take over and send a short packet back to the host
which will terminate the read request. The data that has been read so far is then passed on to the
users application via the FTDI driver. This shows a relationship between the latency timer, the data
rate and when the data will become available to the user. A condition can occur where if data is
passed into the FTDI chip at such a rate as to avoid the latency timer timing out, it can take a long
time between receiving data blocks. This occurs because the host controller will see 64 byte
packets at the point just before the end of the latency period and will therefore continue to read the
data until it reaches the block size before it is passed back to the user's application.
The rate that causes this will be:
62 / Latency Timer bytes/Second
(2 bytes per 64 byte packet are used for status)
For the default values: -
62 / 0.016 ~= 3875 bytes /second ~= 38.75 KBaud
Therefore if data is received at a rate of 3875 bytes per second (38.75 KBaud) or faster, then the
data will be subject to delays based on the requested USB block length. If data is received at a
slower rate, then there will be less than 62 bytes (64 including our 2 status bytes) available after 16
milliseconds. Therefore a short packet will occur, thus terminating the USB request and passing
the data back.
At the limit condition of 38.75 KBaud it will take approximately 1.06 seconds
between data buffers into the users application (assuming a 4Kbyte USB block request buffer size).

Это из какой-то из статей самих ftdi

ты наверно запамятовал... у меня ж 8 классов образования
я по ихнему не понимаю...

Хватит в прицнипе одного предложения
At the limit condition of 38.75 KBaud it will take approximately 1.06 seconds
between data buffers into the users application (assuming a 4Kbyte USB block request buffer size).

В вольном переводе:

В предельном случае - на скорости 38.75кБод будет уходить около 1.06 секунды между сбрасыванием буферов п пользовательское приложение (предполагая размер usb-блока в 4кб).

Че-то вы такое страшное рассказываете...
Юзали фт232 для программирования одного контроллера. Его протокол программирования предусматривает эхо каждого байта назад, то есть размер пакета = 1 байт. Так и гоняет - байт туда, байт обратно. И ничего, программа 30 кбайт заливается десятки секунд, не больше. Но для этого нужно в свойствах порта обязательно! переставить значение таймаута приема с дефолтных 16 мс на минимальные 1 мс. Если не переставить - тогда конечно медленно Вот. Чип - FT232BM, было это года 3-4 назад. Щас они вообще рекомендуют FT232R, ему еще меньше обвязки надо. Насчет него - не знаю, но думаю тоже должен быть регулируемый таймаут.
А то что тут цитируется - может это про старый какой-нить чип, один из первых?
--
Блин, надо было сначала прочитать Речь идет о непрерывном потоке данных. Если поток закончился - после окончания таймаута его передадут приложению. Таймаут дефолтный 16 мс, минимальный 1 мс. Да - размер буфера тоже рулится, дефолтный 4096, минимальный то ли 256, то ли 16 байт - не помню, а девайсов щас под рукой нет.

Так в чем проблема то? Надо драйвер настроить, если наблюдается такое явление. Как настраивать - описано в процитированном апноуте

Да можно не задумываться и делать на ft232... для большинства это явление пройдет незаметно...
Просто по мне так лучше сделать более универсальный модуль, который бы позволил не только usb-serial делать, а все, что поддерживается протоколом usb

Про мега-универсальный модуль не понял - обвешать его всеми разъемами и сбоку еще кодек прикрутить?

Эмуляция последовательного порта - это не единственное что умеет USB..
Есть еще всякие bulk-transfer'ы, есть HID'ы, ну и т.п. радости жизни... с которыми иногда хочется поиграть.. С точки зрения денег - отдать баксов 5 за арм или цайпрес, или at90usb...