Зависание микроконтроллера, ATMega 128 Опции

[smalcom]

Наблюдается следующая картина: казалось бы без всяких причин виснет контроллер, если дотронуться металическим предметом до ножек кварца, то или пускается дальше или уходит в перезагрузку, или сделает еще пару шагов и опять виснет. Выводит его из такого состояния только кнопка резет или сброс питания.
контроллер - ATMega128-16AU. Программа раньше работала, проблеиы появились только в текущем месяце на новых устройствах. Не знаю на кого грешить((

PS. менял кварц - непомогло
PPS. частота - 14.7456МГц

Сообщение отредактировал smalcom - Apr 14 2008, 13:30

[GrayCat]

Насчет "устойчивости" протокола...

Вот вы когда дорогу переходите на светофоре. Тоже, в принципе, придерживаетесь определенного протокола: "Красный - стоять, зеленый - идти". Вполне нормальный, достаточно помехоустойчивый протокол. НО. Когда загорается зеленый и вы собираетесь пойти - вы смотрите на дорогу? Вы убеждаетесь в отсутствии "лихачей", стареньких подслеповатых дедушек на "Москвичах", блондинок?

Во-от, так что как бы ни был хорош "протокол" - но если есть возможность улучшить его работу элементарными средствами (в данном случае "растяжки" на RS-485), надо ими воспользоваться. =AK= все правильно написал про "грамотно реализованный" протокол, при наличии помех он, конечно, "битые" пакеты не пропустит... Но для уменьшения количества этих самых битых пакетов вдобавок к протоколу меры защиты аппаратного уровня не помешают.

Имейте ввиду, что оптрон инвертирует сигнал.

Внимательно изучите схему. В этом включении - не инвертирует!

Однако, даже если бы он не инвертировал. Объясните, почему, собственно, на входе UARTа вам хочется в паузах между пакетами видеть высокий уровень, а не низкий. Зачем?

Потому что "исторически так сложилось" © М.С.Горбачев. В "неактивном" состоянии на линии UART предполагается уровень "MARK" (равный -12В в RS-232 или лог. "1" в ТТЛ). Стартовый бит начинается с перехода "MARK -> SPACE".

[=AK=]

Во-от, так что как бы ни был хорош "протокол" - но если есть возможность улучшить его работу элементарными средствами (в данном случае "растяжки" на RS-485), надо ими воспользоваться.

Наличие или отсутствие растяжек никак не влияет на работу правильного протокола, поэтому "улучшить его работу" растяжками невозможно. "Чувствительность" к наличию растяжек есть полная гарантия того, что протокол плохой.

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

Растяжки не уменьшают количество битых пакетов, если протокол правильно реализован. Чтобы получился битый пакет, в плохом протоколе помеха должна пересилить растяжки, а в хорошем - пересилить работающий выход передатчика.

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

Я писал, что нужно два элемента:
- "Задержка перед отправкой пакета", когда передатчик включен, но данных не передает. Длительность паузы - порядка 2-3 байт-интервалов.
- Гарантия малых пауз между соседними байтами в пакете. Если приемник видит большую паузу между байтами, текущий пакет немедленно выбрасывается как ложный, а приемник мгновенно приводится в состояние готовности к приему нового пакета.

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

[defunct]

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

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

по протоколу. протокол у меня простой:
Заголовок
Адресат
Команда
Данные постоянной длины
CRC16

Что такое "Заголовок"?
Если его выбросить то формат у вас совпадает с modbus rtu. Когда "Адресат" идет первым, то по первому же байту можно определить предназначен ли этот пакет конкретному устройству или нет и вести предварительную отбраковку еще в прерывании.

[=AK=]

Есть более простой способ решающий эту проблему - байт стаффинг.
Никаких задержек и никаких лишних включений "перед отправкой пакета" не потребуется. Не потребуется также отмерять точные интервалы.

Нет, не работает. В ситуации, когда помеха запускает UART ложным старт-битом незадолго до байта заголовка (soh), ваш пакет бyдет испорчен, поскольку заголовочный байт не будет принят. Значит, при определенном уровне помех, когда ложный запуск происходит часто, связи вообще не будет, все пакеты бyдут испорчены. Правильный протокол в этой ситуации будет работать как ни в чем не бывало.

[defunct]

В ситуации, когда помеха запускает UART ложным старт-битом незадолго до байта заголовка (soh), ваш пакет бyдет испорчен, поскольку заголовочный байт не будет принят.

Не будет ничего испорчено. Последовательность такая:
Передатчик посылает 1-2 байта преамбулы 0xFF, открывающую стаффинг последовательность, RTU пакет, закрывающую стаффинг последовательность, и байт преамбулы. Использую этот подход в радио каналах и серьезно задумываюсь над переносом этого протокола в 485 сети потому что жесткие времянки модбаса слегка достают уже (при том что против формата RTU пакетов я ничего не имею - формат грамотный).
Плюсы:
1. Передатчик волен вставлять любые паузы между символами (актуально когда хост - компьютер с не реал-тайм драйвером UART'a),
2. Четко выделяется начало и конец пакета, к обработке можно переходить немедленно после приема закрывающего флага, не нужно считать CRC в прерывании на слейве.
3. Опять же хост - тот же компьютер с не риалтайм приемником вместо непрогнозируемого таймаута четко распознает конец пакета - что уменьшает время реакции.

Минусы
Избыточность. (в худшем случае 2х кратное увеличение количества передаваемых данных на 1 пакет).

[=AK=]

Передатчик посылает 1-2 байта преамбулы 0xFF, открывающую стаффинг последовательность

Если передатчик посылает всего 1 байт преамбулы 0xFF:
- Помеха, которая создаст ложный старт-бит незадолго до этого, запустит UART
- В момент прихода байтa преамбулы 0xFF, UART, находящийся где-то в середине приема байта, "не увидит" 0xFF, а увидит некий ложный байт. Пакет будет испорчен.

Если передатчик посылает 2 байтa преамбулы 0xFF, то ситуация лучше: первый байт может быть испорчен, но второй "прочистит" приемник, так что пакет будет принят правильно. Однако по затратам времени два байта преамбулы ничем не лучше паузы в 2 байт-интервала. Что же касается накладных расходов, то ваши затраты на парсенье эскэйп-последовательностей выглядят не меньшими, чем затраты на проверку тайм-аутов между байтами. Разница в основном в том, что вы парсите софтом, а тайм-ауты проверяются в основном железом (таймером). Поэтому вам нужно меньше таймеров, но более производительный проц. В принципе шило на мыло, примерно тож на тож получится.