FT 232RL проблемы с UART

demiurg301

Meteor писал(а):Погрешность установки медленных скоростей на 8 МГц не превышает 0,2 %. Но я однажды накололся со встроенным генератором - одна плата работала как следует, а вторая слала чушь. Больше на спичках не экономлю - время дороже

Ухты. А чем сбой инициировался? Колво байт, интервалы, скорости? Я на 9600 с интервалами отправки в 3-5мс специально проверял на нескольких макетках (atmega128A) слал данные(байт 0xAA) подряд в течении нескольких часов - сбоя не замечал. Может просто пруха, а может изза того что из новой серии с буквой А ?

Кварц конечно нет проблемы поставить, но просто интересно... Да и жрёт тогда контроллер больше и дольше просыпается.

Реклама

ploop

Я на 9600 с интервалами отправки в 3-5мс специально проверял на нескольких макетках (atmega128A) слал данные(байт 0xAA)

Вот в этом и суть. С интервалами он каждый раз синхронизируется, выплёвывая 1 байт...

Реклама

demiurg301

Тем не менее - это выход.
А уж если нужны выше скорости (что уже редко бывает) - лучше конечно кварц впаять.

Меня больше интересует минимальная задержка - думаю времени на байт хватит? Т.е. приблизительно 1 мс для передачи на 9600 и 4 мс на 2400...

Кстати вот такая конструкция тоже к "срыву" не приводит. Вот я и думаю - вроде бы должна,задержек нет, а не приводит. Может всё дело в "тугодумности" самого С, который задержек добавляет.

void OUT_COM1(unsigned char *PtS,unsigned char L)
{
unsigned char i;
for (i=0;i<L;i++)
{
while ( !( UCSR1A & (1<<UDRE)) );
UDR1=*PtS++;
};
};

ploop

Вот такой код срывался у меня вчера:

Код: Выделить всё

  us_loop:
      sbis UCSRA,UDRE
      rjmp us_loop
    ld r17,X+
    out UDR,r17
    dec r16
    brne us_loop

В X - адрес буфера, в R16 - 100 (100 байт). Для теста загнал в буфер инкрементные данные (1,2,3,4,5....) Где-то на середине начинал проскакивать мусор, при чём сначала редко, потом чаще, к концу (после 80) - вообще один мусор.
Скорость 9600

Скорее всего тактовая частота просто не соответствует действительности...

Реклама

demiurg301

Сейчас проверил специально.
Atmega128A
38400-8N1

for (i=0;i<20000;i++)
{
while ( !( UCSR0A & (1<<UDRE)) );
UDR0=0x81;
};

0x81 специально взял отследить биты крайние.

Вообщем сбоев нет,несколько раз запускал

Все 20000 байт пришли. Может дело в компиляторе.

Вот кстати нашёл в asm файле кусок соответствующий С коду (уродливо, чистый asm конечно красивше). Думаю всё дело именно в этом.

Код: Выделить всё

	
ST   -Y,R17
	ST   -Y,R16
;	i -> R16,R17
	__GETWRN 16,17,0
_0x1F0:
	__CPWRN 16,17,20000
	BRSH _0x1F1
_0x1F2:
	SBIS 0xB,5
	RJMP _0x1F2
	LDI  R30,LOW(129)
	OUT  0xC,R30
	__ADDWRN 16,17,1
	RJMP _0x1F0
_0x1F1:
	LDI  R30,LOW(500)
	LDI  R31,HIGH(500)
	CALL SUBOPT_0x3
_0x3F6:
	LD   R16,Y+
	LD   R17,Y+

Реклама

Meteor

demiurg301 писал(а):Ухты. А чем сбой инициировался? Колво байт, интервалы, скорости?...

Сбой происходил именно из -за тактирования на приемной стороне. Это проверено осциллографом.

Вот такой код срывался у меня вчера:

Сейчас проверил специально.

До этого дня никогда еще не встречал способ оценки времени передачи байта по коду

Поделюсь еще одним секретом отладки.
Зачастую необходимо убедиться в том что все правильно настроено.
Неважно, какая скорость, длина пакета и пр.
Для этого выделяю 1 вывод под сигнал синхронизации.
При старте передачи (1й байт) устанавливаю вывод в логический 0.
После записи последнего байта в регистр передачи, устанавливаю вывод синхронизации в логическую 1.
Сформированный сигнал подаю на вход синхронизации осциллографа. На котором и наблюдаю правильность посылки.
Для длинных посылок, можно применить несколько таких сигналов, или формировать импульс при каждом обращении. Далее уже несложно засинхронизоваться в нужном временном интервале.

Реклама

ploop

Сформированный сигнал подаю на вход синхронизации осциллографа.

Будь он, вопросы сами собой отпали-бы...

Meteor

Что лишний раз подтверждает правило разработчика (едва ли не внесенные в ГОСТ) - должен быть резерв, как по линиям, так и по остальному.

ploop

Дык я про осциллограф

demiurg301

До этого дня никогда еще не встречал способ оценки времени передачи байта по коду
Поделюсь еще одним секретом отладки.
Зачастую необходимо убедиться в том что все правильно настроено.
Неважно, какая скорость, длина пакета и пр.
Для этого выделяю 1 вывод под сигнал синхронизации.
При старте передачи (1й байт) устанавливаю вывод в логический 0.
После записи последнего байта в регистр передачи, устанавливаю вывод синхронизации в логическую 1.
Сформированный сигнал подаю на вход синхронизации осциллографа. На котором и наблюдаю правильность посылки.
Для длинных посылок, можно применить несколько таких сигналов, или формировать импульс при каждом обращении. Далее уже несложно засинхронизоваться в нужном временном интервале.

Я имел в виду что сам код вносит задержки, во время которых приёмник синхронизируется, хотя явно мы их не задаём. Может в этом всё дело?
У меня осцил с синхронизацией по несущей. Т.е. поймал фронт - синхронизировался. Выставляешь период синхронизации (для скорости 9600 я выставлял около 1 мс,а для 2400 - 4мс) и никаких синхро импульсов не нужно.

Сейчас отправлял на контроллер с компа пакеты из 250 байт и отсылал их обратно на комп прямо из прерывания - НЕМОГУ добиться срыва

Думаю всё равно послушаю ваш совет и поставлю кварц на 7.3728 МГц

Meteor

У меня иначе построен процесс передачи - все реализую на прерываниях. Там практически нет задержек.
Опустел буфер - прервались для его заполнения.
Записал на передачу последний байт, тут же запретил прерывания передатчика.

Дык я про осциллограф

А я то грешным делом подумал о выводах МК.
Тогда можно "помудрить" с передачей одного байта. А уж потом всего пакета

ploop

Да собственно проблем нет - запаяю сегодня кварц. Это макетка, для отладки алгоритма.
Реально отсылать надо 4 байта, 100-байтовый буфер сделал чтобы вывести отладочную информацию.

igor-x

добрый день,

а поделитесь пож. опытом -как работает такая связка (ATmega16+FT232) на скоростях максимальных для FT232?
если я правильно понял ДШ, FT232 может обеспечить скорость до 300 килобайт в секунду с драйвером VCP со стороны компа.

asteroid7

igor-x писал(а):а поделитесь пож. опытом -как работает такая связка (ATmega16+FT232) на скоростях максимальных для FT232?

FT232 нормально работает на 3 Mbit-ах. Вы только с ATmeg-ой такую скорость не обеспечите.
Например, практически во всех устройствах, всю отладочную информацию гоню на PC терминал со скоростью 1382400, это при кварце 11,0592 МГц. Для максимальной скорости нужен будет кварц на 24 МГц.
ИМХО из опыта, принимать данные на контроллер со скоростью выше 460800 считаю нецелесообразным. Т.к. обработка данных "съест" всю скорость приёма.

igor-x

asteroid7 писал(а):
igor-x писал(а):а поделитесь пож. опытом -как работает такая связка (ATmega16+FT232) на скоростях максимальных для FT232?
FT232 нормально работает на 3 Mbit-ах. Вы только с ATmeg-ой такую скорость не обеспечите.
Например, практически во всех устройствах, всю отладочную информацию гоню на PC терминал со скоростью 1382400, это при кварце 11,0592 МГц. Для максимальной скорости нужен будет кварц на 24 МГц.
ИМХО из опыта, принимать данные на контроллер со скоростью выше 460800 считаю нецелесообразным. Т.к. обработка данных "съест" всю скорость приёма.

a AVR теоретически может работать на скоростях выше 115200? во всех программках расчета скорости UART, независимо от кварца скорость выше 115200 не показывает..
может лучше использовать параллельный FT245 чтобы получить скорости хотя бы до 300 килобайт?

Meteor

Открываем даташит на конкретный МК и читаем там про U(S)ART.
Например для меги 16, с предельной тактовой 16 МГц, можно ожидать максимальную скорость 2Мбит\с.
Ну а вот обработать полученный поток - это уже отчасти искусство

asteroid7

igor-x писал(а):a AVR теоретически может работать на скоростях выше 115200?

igor-x писал(а):может лучше использовать параллельный FT245 чтобы получить скорости хотя бы до 300 килобайт?

У 16-ой меги 1 Кб озу. Минус стеки, получится один буфер на 700-800 байт. Куда 300 Кб гнать-то?

igor-x

asteroid7 писал(а):У 16-ой меги 1 Кб озу. Минус стеки, получится один буфер на 700-800 байт. Куда 300 Кб гнать-то?

гнать будет мега16 на комп... уже стало понятно что 300к невозможно выкачать с меги., но надо будет попробовать сколько удастся.

ploop

Так всё-таки для чего такой поток? Может, на месте обрабатывать?
Или применить подходящие средства, DSP например...

igor-x

ploop писал(а):Так всё-таки для чего такой поток? Может, на месте обрабатывать?
Или применить подходящие средства, DSP например...

да! на месте хотелосьбы обработать, но не владею пока такими средствами обработки сигналов (DSP например)..
с АВРками только еще чуть разобрался. поэтому пусть ПК считает все