Применение МК без кварца.

[SlovachevskyDV]

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

Смотрел осциллом. Данные похожи на адекватные, но длительность импульсов передачи слегка отличается от приема. Буквально на несколько процентов. Точно не измерял, но не на порядок.

[akegor]

Буквально на несколько процентов

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

[SlovachevskyDV]

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

В ваших словах конечно есть доля истины. Но зачем грубить и оскорблять?
Если не будете пытаться вырвать слова из контекста, а почитаете предыдущие мои сообщения, то увидите, что я (сейчас уже) прекрасно понимаю, свою первоначальную ошибку. Поэтому не нужно снова тыкать меня в это носом, как неразумного котёнка.
Про "несколько процентов" я написал в ответ на предположение о полном обрыве передачи, а не потому, что считаю это несущественным.
Проблему попытаюсь решить калибровкой. Если не получится, изменю схему, чтобы добавить кварц.

[parovoZZ]

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

[SlovachevskyDV]

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

Да. Планирую сделать следующее:
Устройство на STM или комповая программа, если будет часто принимать от меги мусор, пошлет ей команду "старт калибровки". В ответ мега начнет перебирать значения регистра OSCCAL от 0 до 0xFF и отправлять их. Приемник посчитает все правильно принятые, вычислит среднеарифметическое и отправит обратно в команде "калибровка завершена".

[akegor]

Но зачем грубить и оскорблять?

Просто констатация.
Уже не один десяток лет занимаюсь скважинной аппаратурой, которая должна работать на улице до -20 и в скважине до +150. Потому и кой-чо знаю... Приходят в нашу среду Кулибины и Васи-рацинализаторы, но либо уходят, либо меняют свои наклонности.

[Someone]

А отправляет бред, если температура воздуха падает ниже 20. Ткнешь паяльником в проц, работает какое-то время нормально. Через 15-20 мин опять сыплет мусор.

При отсутствии конкретики, скажем температура 18. Кажется ли вам странным заявление

"Нестабильно работает передача данных по УСАРТ в нормальных условиях. При уменьшении температуры на 2 градуса от нормальной, частота внутреннего генератора откланяется от номинальной настолько, что контроллер начинает передавать мусор, при том, что приём работает нормально".

Это первый момент. А второй момент - про паяльник. Вы всерьёз полагаете, что касание паяльником вывода контроллера разогревает внутренний генератор до такой температуры, что чтобы остыть до температуры среды - 20 градусов и менее, требуется 15 минут?

Так что в очередной раз повторюсь - температурный дрейф внутреннего тактового генератора - на 90% не имеет к проблеме никакого отношения (ну по описанным признакам). Проблема либо в коде, либо в реализации железа. За второе говорит влияние паяльника, ну а первое просто чаще всего бывает.

Исключите влияние кода. Это делается минут за 5. Просто создайте, скомпилируйте и прошейте тестовый проект, в котором ничего нет кроме посылки по УСАРТ одного байта, скажем 1 раз в секунду:

#define F_CPU 8000000UL

#define baud  2400

#include ‹avr/io.h›
#include ‹avr/interrupt.h›
#include ‹util/delay.h›


int main(void)
{
  cli();                                      // запрещаем прерывания

  // инициализируем порты
  PORTB = 0b11111111;                         // подтяжки везде
  DDRB =  0b00000000;                         // все пины - входы

  PORTC = 0b11111111;                         // подтяжки везде
  DDRC =  0b00000000;                         // все пины - входы

  PORTD = 0b11111111;                         // подтяжки везде
  DDRD =  0b00000010;                         // все пины - входы, кроме ТХ

  // инициализируем USART
  UBRRH = (unsigned char)(F_CPU/16/baud-1)››8;
  UBRRL = (unsigned char)(F_CPU/16/baud-1);

  UCSRB = (1‹‹TXEN);
  UCSRC = (1‹‹URSEL)|(0‹‹USBS)|               /* 1 stop */ 
          (1‹‹UCSZ1)|(1‹‹UCSZ0);              /* data 8 bit */

  // инициализируем регистр управления
  MCUCR = 0;

  sei();                                      // рзрешаем прерывания

  do
  {
    UDR = 0x55;
    _delay_ms(1000);                          // пауза
  }while(1);//do

}//main 

Исключите влияние трещины в дорожке на плате - продублируйте цепь от выхода ТХ тонким проводом, паяя его прямо к выводам компонентов. Тщательно отмойте флюс, даже если он считается безотмывным. Рекомендую растворитель В-646.

[SlovachevskyDV]

Вы всерьёз полагаете, что касание паяльником вывода контроллера разогревает внутренний генератор

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

Исключите влияние кода

Исключил. Ваш тестовый код в протеусе работает нормально, в моем проце иногда дает 0x55 иногда 0xD5. И так же подвержен влиянию паяльника и зажигалки.

Исключите влияние трещины

Трещин нет. Проводок кидать не стал но хорошенько пролудил дорожки по всей длинне

Тщательно отмойте флюс

отмыл.
Спасибо за советы. Но ничего не помогло. Возвращаюсь к предыдущим планам.

[alex_t2]

Чисто для информации.
Некоторое время назад у меня серийно выпускались блоки на базе меги48, без кварца, на внутреннем генераторе на 8 МГц. Выпущено было где-то около 500 штук.
Так вот, для тестовых целей там был вытащен UART. Для работы он не требовался, чисто тестовые цели, для доводки ПО, и упрощения тестов при изготовлении. Скорость была выбрана 9600, т.к. на ней при 8 МГц минимальная погрешность. За все время только пару раз сталкивался с ситуацией, когда в ответ на команду шел частичный мусор.
Сейчас делается другой блок, тоже без кварцевания, там есть формирование различных попискиваний в канал звука, замечаю, что в основном тон примерно одинаковый, но из сотни бывает попадается заметно отличающийся на слух.

[Someone]

иногда дает 0x55 иногда 0xD5

Т.е. "искажается" только один бит, 7й, который следует сразу после старта... А остальные идут условно нормально... Интересно, если 7й бит будет 1 (посылать 0хАА вместо 0х55) будет ли он искажаться... Впрочем проблему это не решит...

Кстати, а какое напряжение питания контроллера?