zombi

Спасибо, я так и думал. Кстати думаю поставить мс 4-2И и сигнал TXD проца тоже через нее пропустить. Т.о. появится дополнительный буфер между разъёмом и ногами проца. Всетаки не напрямую ноги будут наружу выходить!

Контактов на разъёме свободных нет. Добавлять дополнительный джампер тоже не хочется. К томуже мультиплексор тоже хочется выкинуть. Я вот думаю на 2И организовать автовыбор. На первый вход 2И подключаем выход TXD от макса. На второй вход 2И TXD с разъёма (надо только к +5V резистором подтянуть). Ну а выход 2И на вход RXD атмела. Как думаете будет нормально работать?

В изделии исп. авр атмел с одним ком портом и max232. Подключать к изделию нужно различные внешние устройства. У этих устройств порт RS232 может быть как Тrue (размах сигнала -12V +12V) так и TTL ( 0V - 5V). Сейчас процессор управляет мультиплексором для выбора подключаемого на свой вход RXD одного из сигналов TXD от max232 или TXD с разъёма. Как бы сделать так чтобы процессор вообще не занимался мультиплексированием TXD? Предполагается что может быть подключено только одно устройство с одним типом интерфейса.

У атмела вроде как разрядность OSCCAL зависит от версии внутреннего RC. У ATmega162 версия RC 4.0 и разрядность 7 бит 00H - 7FH.

Т.е. как правило заводская калибровка по центру? А какая всетаки обычно девиация калибровочной константы относительно середины?

А как же тогда понять вот эту таблицу: где видно что при OSCCAL=0 Frc чуть больше 4MHz, а при OSCCAL=127 Frc > 14MHz ???????

Пытаюсь понять вот эту табличку из DS на atmega. Если я правильно понял то записав в рег.OSCCAL 0x00 частота понижается до 50% от калибровочной, а если пишем 0x7F то повышаем вдвое? И это граничные величины частоты которые можно достичь если заводская калибровочная константа гдето рядом с 0x3F-0x40. Т.е. если заводкая калибровка равна 0x00 то вообще понизить частоту невозможно, равно как если 0x7F то невозможно частоту повысить. Или я опять чегото не догоняю?

По прежнему ниче не понятно! Конкретизируйте свой вопрос. А то получается что форумчане должны иметь непреодолимое желание помочь Вам и для этого задавать наводящие вопросы :laugh:

Никогда не думал что наличие на плате разъёма RG-45 является необходимым и достаточным условием для передачи информации. Извините, неудержался

Нет. Вот цитата из DS: Т.е. после сброса его нужно прочитать из OSCCAL и запомнить? Или всетаки процессор може гдето прочитать значение заводской калибровки?

Вот и я чисто интуитивно к генераторам склоняюсь, но почему обьяснить не могу. Лет пять назад было одно изделие в котором было предусмотрено (в разводке) использование резонатора с кондерами или генератора. Естественно исходя из цены в первые изделия (~50шт) поставили резонаторы. В эксплуатации наблюдались странные зависания или улеты процессора неисвестно куда. В следуююшей партии поставили генераторы (ни программа ни периферия не менялись) и проблемы исчезли. Позже и в первых изделиях резонаторы на генераторы поменяли. Вот такие чудеса. А сейчас захотелось отказаться от внешних часов и RTC AVRа использовать с внешним генератором это проблематично, возвращаться с резонатору стремно, внутренний RC не стабильный. Засада полная :crying:

У меня мега 162 питание 5V. Куря DS вроде понял так что внутренний RC откалиброван на 8MHz для 3V. А сколько ж будет при 5V??? Вроде с помощью OSCCAL частоту можно поднять аж в два раза. И 14.7456 мне бы очень кстати было. FLASH мне вообще писать не нужно а EEPROM к счастью не часто и я вот думаю попробывать таким образом: Перед записью запретить все нафиг. Записать в OSCCAL default. Дождаться окончания записи в EEPROM. Восстановить OSCCAL. Как думаете прокатит? З.Ы. Кстати а где процессор может прочитать этот самый default байт калибровки?

Под "выходом за пределы спецификации RC-генератора" вы имеете ввиду допустимую 10% калибровку? Кстати хочу уточнить в случае изменения OSCCAL более чем на 10% от номинала атмел не гарантирует только запись в EEPROM и FLASH или чтото еще может глючить?

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

Можно ли предположить что изделие с ATmegа на борту будет : а. Более надежно работать если мега тактируется внешним генератором. б. Менее надежно работать если мега тактируется внешним резонатором. Предполагаемое время непрерывной работы 30-365 суток. Предполагаемые помехи: гроза гдето рядом, сварочный аппарат за стенкой или просто юзверь в шерстяном свитере решил к корпусу дотронуться.

Все дело в том что USART работает на скорости 115.2K, и при Fosc=16MHz и U2x=1 уже погрешность 2.1%. Страшно представить какая будет погрешность при Fosc ~8MHz +/- пол вареника

А какое это может быть время хоть примерно? Можно ли им пренебречь при обязательной 1ms задержке? В принципе может хватило бы и 8-ми но только требутся еще и работа USART.

Вот это и хотелось бы у Вас уточнить. А как узнать это время? Внешний генератор не подходит из-за большого потребления. А встроеннвй RC из-за малой частоты.

Bот к примеру если мне нужно проц тактировать внешним кавцевым резонатором 16MHz то чтобы я в SUT и CKSEL0 не писал все равно "Start-up Time from Power-save" будет 16K CK т.е. 1/16.000.000+16*1024=0.001024 cек (~1ms). Или я чето напутал?

А как процессор должен узнать с какой добротностью железяку ему на вход подцепили?

В документе AVR134 на стр.3 figure 2-2/2-3 показаны графики потребления проца во времени. И сразу видно что чем больше "Startup Time" тем больше жрет проц итого! Кто может объяснить почему с "Crystal Oscillator" Startup Time = 35 ms, a c "Ceramic Resonator" Startup Time = 1 ms. AVR134

10 K это в HEX формате. Грубо бин= 230строк * 16байт= 3.5 К.

Для номерации 24-х тетрад 4-х бит не хватит. Но если сдалать анализ чет/нечет и мастер будет посылать по два байта с одинаковым номером но разными тетрадами тогда должно прокатить. И вариант предложенный Stepan_L (анализировать временной интервал между пришедшими байтами) мне нравится.

Так какой протокол? Просто последовательность 12-ти байт? - это отсутствие всякого протокола. Это как? Оч. интересно.

А что "мастер" об этом думает? Мастер должен позаботиться о том чтобы небыло такого! Если передается более 1-го байта тогда используется протокол для синхронизации и проверки целостности пакета.