[firstvald 13]

Все как надо подтянуто. Дело не в фронтах. На скоростях 115200 работает. Ессно скорость 19200 правильно генерируется. В серии у нас на многих сотнях метров через кабель бегает. Наиболее вероятно - отклонение генератора в микросхеме, но это только догадка.

Статистикой только и надо заниматься. Если нет вопросов на макете - могут быть в серии, а если что-то иногда на макете проскакивает - серия будет полностью неработоспособной. Насмотрелся на серийные буржуйские изделия которые на поверку не работают когда с ними не на столе и не терминалом играешься и они продаюся! Пока придется карту минных полей составлять - где не работает

[Гость @Ark]

Наиболее вероятно - отклонение генератора в микросхеме, но это только догадка.

Статистикой только и надо заниматься.

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

Удачи!

[firstvald 13]

Удалось обмен отладить - в структуре тайм-аутов тайм-ауты, начиная со скорости 19200 (хотя не понятно: для 38400 57600 115200 можно оставить то, что есть), пришлось увеличить в два раза по сравнению с теми значениями, при которых обмен работает нормально через обычный RS (замечу еще раз , что нормально обмен работает не при вычисленных значениях, а при подобранных, винда тайм-ауты считает практически никак, а менее 10 мс вообще никак).

 

Теоретически, на символьных посылках с большими тайм-аутами этой проблемы не заметно вообще. Поэтому у кого-то работало и он уверял , что проблемы нет. На самом деле, если предполагается, что железяка должна работать и через RS и через мост или сразу только через мост, нужно потренировать обмен и посмотреть как там дела.

 

В старых разработках, которые работали через RS, а теперь возможно будут работать через мост или в устройство вделывается мост и устройство становится как-бы USB, возможно, во внешнем софте придется подкорректировать константы в структурах тайм-аутов.

 

Чудеса с паритетом запишем пока в загадки, возможно немного времени не хватало, но это надо обдумать.

[vetal 0]

Сдается мне, что вы наотрез не хотите смириться с тем, что вы работаете с контроллером шины USB, имеющем интерфейс UART, а не наоборот.

Замирания 20-1000мс(и хуже) - совершенно нормальная ситуация при работе под управлением ОС семейства Windows :)

Битовая скорость внешнего физического интерфейса(uart) и скорость обмена(что применимо и для задержек) информацией по шине USB имеют очень слабую связь, которая больше влияет на трафик, чем на задержки в отличие от наличия встроенного контроллера!

 

Равно как и при работе с удаленным(сетевым) последовательным портом задержки могут доходить до нескольких секунд.

[firstvald 13]

Сдается мне, что вы наотрез не хотите смириться с тем, что вы работаете с контроллером шины USB, имеющем интерфейс UART, а не наоборот.

Замирания 20-1000мс(и хуже) - совершенно нормальная ситуация при работе под управлением ОС семейства Windows :)

Битовая скорость внешнего физического интерфейса(uart) и скорость обмена(что применимо и для задержек) информацией по шине USB имеют очень слабую связь, которая больше влияет на трафик, чем на задержки в отличие от наличия встроенного контроллера!

 

Равно как и при работе с удаленным(сетевым) последовательным портом задержки могут доходить до нескольких секунд.

 

 

Конечно не хочу мириться! Был RS232, можно было общаться с устройствами. А сейчас получается такая ситуация, что надежно общаться с устройством просто не через чего! Нету такой дырки в компьюторе! Одну засопливили, а новой не просверлили! Вернее просверлили, но не ту и не там.

 

Спонтанные провалы на несколько секунд , полнейшее искажение временных соотношений между посылками при вставлении в последовательный канал сегмента локальной сети у нас коллеги видели, вернее, нарвались. Второй или даже третий год не знают чего делать. Поигрались (вдоволь ) тайм -аутами и, похоже, банально переспросами проблему закрыли.

[jorikdima 0]

Если вам нужна более жесткая времянка при работе с ЮСБ - пишите свой драйвер к вашему девайсу, FTDI вам тут не грозился этого обеспечить.

[Vasily_ 45]

Вот интересно - окуда FTDI берет тактовые импульсы? ВМ их из кварца брала. А у этой?

Так и на RL можно кварц повесить, что мешает?

[galjoen 0]

Спонтанные провалы на несколько секунд , полнейшее искажение временных соотношений между посылками...

Не понял, вы не в курсе, что FTDI и прочие переходники USB -> COM данные через bulk передают? А если знаете, то почему считаете, что может быть по другому?

 

Сделайте своё USB устройство и будет вам счастье. До 500 кбод вполне HID для этого подойдёт - драйверов не нужно будет.

[firstvald 13]

Да нет. Так нельзя. В мире уже сложилось что общение с приборами происходит по последовательным протоколам. Ряд из них требует довольно жестких временных соотношений при обмене. Попытки отказаться в компьюторах от обычного послеледовательного порта приводят к тому, что такой компьютор тут же превращается в Dendy, годное только на MP и Word. Спасать лицо компам пытаются через оставшиеся дырки : локльную сеть и USB. Не работает ни то ни то.

 

То, как FTDI обменивается с компьютором должно быть абсолюно фиолетово, если смотреть на обмен со стороны API. А получается, что FTDI показывает в API свои заморочки. Это недоработка или небоежность FTDашного писателя. Если знаешь , что READFILE может вывалится потому что у тебя там что то не успело, но при этом сам обмен нормальный, нафига так писать?

[galjoen 0]

Да нет. Так нельзя. В мире уже сложилось что общение с приборами происходит по последовательным протоколам. Ряд из них требует довольно жестких временных соотношений при обмене. Попытки отказаться в компьюторах от обычного послеледовательного порта приводят к тому, что такой компьютор тут же превращается в Dendy, годное только на MP и Word. Спасать лицо компам пытаются через оставшиеся дырки : локльную сеть и USB. Не работает ни то ни то.

1. USB - это последовательный протокол.

2. Жёсткие времянки д.б. возложены на контроллер.

3. Появление USB в компе - наоборот прорыв на новый уровень. USB-шные флешки тому пример. Другое дело, что люди в силу своей костности этого не замечают или не хотят замечать. Или скрывают т.о. своё незнание/неумение.

 

Я делаю свои девайсы подключающимися в USB как составное устройство HID+MassStorage. Это позволяет челу, который никогда не видел мой девайс и не знал о его существовании сразу начать с ним работать - воткнуть в USB и всё.

При этом появится окошечко с файлами (MassStorage), среди которых будет pdf-ка с описанием, исполняемый файл (exe-шник) для работы с моим девайсом и лог-файл, в который мой девайс складывает данные при работе без компа. Запустив exe-шник можно просмотреть лог, настроить мой девайс (через HID), а при подключении к объекту поуправлять и пополучать данные в реалтайме. Всякие модбасы, CAN и т.п., где нужны времянки, естественно формируются в моём девайсе.

При этом чела не заставили устанавливать никакие драйверы, не задали ему ни одного вопроса, не заставили выходить в инет, вводить коды активации и т.д. и т.п. И вообще у него не возникло никаких вопросов. Точнее возник только один - а почему другие так не делают?

То, как FTDI обменивается с компьютором должно быть абсолюно фиолетово, если смотреть на обмен со стороны API. А получается, что FTDI показывает в API свои заморочки. Это недоработка или небоежность FTDашного писателя. Если знаешь , что READFILE может вывалится потому что у тебя там что то не успело, но при этом сам обмен нормальный, нафига так писать?

FTDI и т.п. переходники, на мой взгляд вообще не имеют права на жизнь. Ни одного преимущества у них нет. Та же FTDI вначале позиционировалась как временное решение. Но нет ничего более постоянного, чем временное...

[jorikdima 0]

FTDI и т.п. переходники, на мой взгляд вообще не имеют права на жизнь. Ни одного преимущества у них нет. Та же FTDI вначале позиционировалась как временное решение. Но нет ничего более постоянного, чем временное...

Когда на МК нет ЮСБ или же обмен данными через ЮСБ настолько прост (малые объемы данных), что не хочется тратить время на реализацию ЮСБ в МК, а пользоваться UART, почему бы и нет???

Эти переходники довольно активно используютсявразличных приборах.

[galjoen 0]

Когда на МК нет ЮСБ или же обмен данными через ЮСБ настолько прост (малые объемы данных), что не хочется тратить время на реализацию ЮСБ в МК, а пользоваться UART, почему бы и нет???

Эти переходники довольно активно используютсявразличных приборах.

МК с USB уже $3 стоят. Причём это АРМ от STM.

При цене FTDI $2 (?) на МК $1 остаётся. Причём в этом случае будет 2 корпуса. Поэтому никакого смысла из-за экономии денег использовать МК без USB, при подключении к USB нет. Если уж так нравится, то можно эмулировать COM на МК с USB. Один раз сделал - и пусть кочует из проекта в проект...

 

А то, что они активно используются, это не есть хорошо...

[Nuts_ 0]

у меня работает связка на 1 мбит

делиттель на FTDI принудительно на 3

 

ftStatus=FT_SetDivisor(ftHandle,3);
FT_SetTimeouts(ftHandle,1000,500);
FT_SetDataCharacteristics(ftHandle,FT_BITS_8,FT_STOP_BITS_1,FT_PARITY_NONE);

 

ATMEGA8 _кварц _ 8MGZ обязательно от RC не рабоатла

пакет аж 32768 байт

;ИНИЦИАЛИЗАЦИЯ UART
    ldi temp,0
    out UBRRL,temp;СКОРОСТЬ
    clr temp
    out UBRRH,temp;СКОРОСТЬ
    ldi temp, (0<<U2X)
    out UCSRA,temp
;Enable receiver and transmitter
    ldi temp, (1<<RXEN)|(1<<TXEN)
    out UCSRB,temp
;Set frame format: 8 data, 1 stop bit
    ldi temp, (1<<URSEL)|(3<<UCSZ0)
    out UCSRC,temp