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

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

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

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

Меня больше интересует минимальная задержка - думаю времени на байт хватит? Т.е. приблизительно 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++;
};
};

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

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

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

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

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

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

Вообщем сбоев нет,несколько раз запускал Все 20000 байт пришли. Может дело в компиляторе.

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

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


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

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

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

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

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

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

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

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

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

добрый день,

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

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

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

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

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

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

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

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