Имеется два устройства на мега32 и мега88, связанных по USART. Устройство на мега88 управляет общим питанием и имеет резервное питание от батареи для работы в спящем режиме. При влючении основного питания мега88 сразу передает 0х00 и этим вводит в ступор второе устройство. Никак не могу эту фигню убрать. Может кто сталкивался с таким?


Так все работает хорошо и устойчиво, но вот эта бага всю малину мне х...т

Ниже по тексту я просто высказываю свою догадку исходя из собственного опыта. То есть не претендую на истину.

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

Если моя догадка верна, то необходимо сделать начальную процедуру синхронизации. Я это везде делаю где применяется несколько однокристаллок. В самом примитивном случае необходимо чтобы мастер заканчивал инициализацию последним.

Дело в том что отслеживаю я при помощи третьего устройства, которое тупо передает инфу из лини ТХ мега88 на терминал. Инициализация USARTов действительно отличается по времени, но как это красиво разрулить пока идеи нет. У Мега88 питание никогда не выключается, а просто меняются источники, но она периодически входит в режим Power-down, при этом я выключаю все что можно, а потом когда проц просыпается инициализирую все заново, а второе устройство стартует на холодную...

А почему у слэйвов нет какойнить простяцкой защиты от неправильных данных? хедер какой-ни-какой...

Собственно устройства общаются между собой посредством коротких текстовых команд, типа мнемоники asm, только чуть длиннее, чтобы можно понять было что за команда и несуществующие команды отсеиваются, но вот этот 0х00 почему-то вводит второе устройство в ступор. Механизм пока мне не понятен.

Ну вот. Теперь понятно.

В общем то я поддержу prottoss.

1) Надо обрабатывать ошибки.
2) Либо надо ввести процедуру синхронизации, при которой слэйв дожидается какой-нибудь последовательности принятой без ошибок.

Знаешь как модем работает? Он принимает всё, но анализировать команду начинает начиная с "at". То есть команда
hgklk;lk;lkl;khjati3

будет отработана как ati3

Хорошо, спасибо. Буду пробовать.

Так все, более менее путние системы работают
Вначале ИД пакета, контрольная сумма (опционально), данные

1)После сброса порты находятся в третьем состоянии. Если нет подтяжки на линии Tx, то вполне возможно что этот уровень воспринимается как ноль (стартовый бит).
2) В каком порядке происходит инициализация? Если сначала порты, а потом USART, то какой уровень пишется в PD1? Если ноль - то он будет восприниматься принимающей стороной как стартовый бит.

Так-то оно все так.
Но здесь не тот случай когда надо подтяжки добавлять или порядок инициализации менять.

Принял ненужную лапшу - проигнорируй ее да и все.
А то кто-то - кого-то в ступор в водит. Смех и грех.

Проблема принимающей стороны, раз ее ноликом можно "убить".

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

Да уже поборол... Там просто приемная сторона не успевала обрабатывать все что ей приезжало. У меня USART с FIFO и буфер оказался маловат, потому что пока он ошибку отработал, а буфер уже забили, поэтому все остальное было тоже ошибкой. Чуток увеличил буфер и убрал на приемной стороне лишних несколько телодвижений и все вроде наладилось.

У меня была ситуация что uart повисал когда происходила запись регистра скорости передачи в тот момент когда шли данные. Толком не выяснил причину- поставил подпорку - лечилось выключением и включением uarta.