[gte 6]

Я: шеф пали какая железяка у нас терь будет!

Шеф: должно быть маленькое и дешевое!

Я: Ммм, ладно.

L78M05 имеет небольшой выходной ток. Стоит подумать над необходимостью предохранителей F1, F2.

Они сработают при выходе из строя L78M05, но тогда достаточно одного на входе, да еще необходимо чем то ограничить напряжение на выходе стабилизатора, иначе в предохранителях уже не будет смысла. Зачем так поставлен F3? Защиту по входному питанию стоит поставить.

По зависаниям, если не менялась разводка, вряд ли кто поможет. Ищите отличия в платах, деталях.

[aesok 0]

Тоесть, обработчик прерываня сохраняет не все регистры которые в нем изменяються.

 

Попробуйте все функции которые вызываються из прерываний объявить с атрибутом "always_inline"

 

Анатолий.

[smalcom 0]

2aesok, МЕГАСЕНК. как думаете в мейллист команде гцц стоит написать об этом, или это ключами компилятора решается? Попробую совет.

 

Хм... Вы в курсе, что ULN2803 имеют выходы с открытым коллектором, т.е. ток нагрузки втекает в выходы, а то, что у вас нарисовано на выходе 245-х дает вытекающий ток? Странные у вас "замены".

 

управлять же можно разными железками. бывают такие которым нужен ТТЛ, есть такие которым нужен мощный выход ОК. в зависимости от этого используется та или иная ревизия. также ревизию с 245ми проще(почти только программно) перевести на 16входов(ЗЫ. встречалась правка ТЗ прямо на объекте).

 

Вообще же требование на наличие failsafe (самопального или встроенного) является верным признаком того, что или используется дурной самопальный протокол обмена, или же нормальный протокол реализован программистом с грубыми ошибками.

протокол работает хорошо и ошибки отсеиваются без проблем. я просто перестраховываюсь(этим блокам 3года от роду)

 

L78M05 имеет небольшой выходной ток

есть на 1 ампер. Вылетает эта штука не сразу при достижении одного ампера.

 

Зачем так поставлен F3?

при работе с улн он ограничивает ток нагрузки.

 

иначе в предохранителях уже не будет смысла

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

 

Ищите отличия в платах, деталях.

проблема найдена - разный код, сгенерированный разными компиляторами

[aesok 0]

2aesok, МЕГАСЕНК. как думаете в мейллист команде гцц стоит написать об этом

 

нет не нужно, поздно уже писать.

 

Анатолий.

[defunct 0]

нет не нужно, поздно уже писать.

Анатолий,

 

А этот баг присутсвует в версии 4.2.2?

[aesok 0]

А этот баг присутсвует в версии 4.2.2?

 

Нет, только в 4.3.0

 

Анатолий.

[sensor_ua 0]

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

Чтобы при неактивном канале было НЕАКТИВНОЕ логическое состояние - чтобы не только активность в канале определялась без лишних вопросов, но и чтобы неактивный канал не вызывал разнотолков. Тем более если у Вас аппаратный УАРТ с определением состояния линии BREAK, то Вы на коне, а если программный - придётся натрудить не только мозолей на пальцах, но и места в памяти программ, которой не завсегда много, ну а если какой-нить простенький аппаратный УАРТ, то научиться обходить его типа "убогость" может оказаться сложнее, чем реализовать весь программно. Итого - использование определения сигнала линии BREAK избыточно и нецелесообразно в относительно простых программно-аппаратных решениях. Ну и далее - переход из BREAK в режим передачи должен сопровождаться выдерживанием передающим хостом некоего таймаута не менее 1-го байта или вариантов с заполнением канала некими символами (0xFF) перед непосредственно передачей, а последнее налагает некоторые ограничения на реализации протоколов.

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

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

ЗЫ. Программы, у которых "срывает крышу" от всяких несуразиц в канале - на помойку, независимо от того, какой уровень в канале при неактивном состоянии.

[defunct 0]

Нет, только в 4.3.0

Спасибо, успокоили. :beer:

[=AK= 12]

Чтобы при неактивном канале было НЕАКТИВНОЕ логическое состояние - чтобы не только активность в канале определялась без лишних вопросов, но и чтобы неактивный канал не вызывал разнотолков.

В неактивном канале нужное вам состояние на входе UART-а обеспечивается подтягивающими резисторами. Предположим, вы поставили резисторы по 1к, т.е. один резистор тянет на +5, другой - на землю. Какой мощности должна быть наведенная помеха для того, чтобы на входе UART-а появился ложный "старт"? В первом приближении, помеха должна иметь можность 5В^2/2k=12.5 мВт (у автора топика с его 47к подтяжками будет еще меньше, но это не суть важно). После этого ваша софтинка примет помеховый сигнал за истинный, поскольку вы надеетесь на резисторы и на то, что такой помехи не будет. Начнется ложный прием, а пришедший вслед за этим настоящий пакет данных будет испорчен.

 

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

 

Предположим, наведенная помеха в паузах запускает ложный прием. Однако ложный пакет будет отвергнут, поскольку очень маловероятно, что она выдает помеховые импульсы в нужном темпе (чтобы выполнялось требование о малой паузе между байтами) и что CRC помехового пакета будет правильным.

 

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

 

Теперь оценим, какой мощности должна быть помеха, чтобы испортить настоящий пакет данных в таком протоколе. Работающий передатчик RS485 обязан уметь выдавать на линию не менее 60 мА тока (реально выдает раза в два больше). Мощность помехи, необходимая для того, чтобы пересилить выход передатчика, должна быть 5В*60мА=300мВт. Почти в 20 раз больше, чем с резисторами.

 

Вот настолько и будет лучше помехоустойчивость правильного протокола по сравнению с дешевыми самопалами, которым нужно, "чтобы при неактивном канале было НЕАКТИВНОЕ логическое состояние" (с). Разница в десятки-сотни раз. :)

 

ЗЫ. Программы, у которых "срывает крышу" от всяких несуразиц в канале - на помойку, независимо от того, какой уровень в канале при неактивном состоянии.

 

Добавьте к программам протоколы, у которых "срывает крышу" от всяких несуразиц в канале.

[smalcom 0]

47k недают покоя)) вы же учитывайте что на линии не одно устройство, а до 32. в даташите на st485 указаны 22k. а увеличил я их чтобы немного снизить потребление тока. для линий я использую экранированую витую пару пятой категории.

[=AK= 12]

чтобы немного снизить потребление тока.

У вас каждый оптрон жрет по 10 мА ни за понюх табаку, а вы на спичках пытаетесь экономить. Замените хотя бы ISO2 на обычный транзисторный оптрон (заодно Q1 можно будет выбросить, если грамотно включить), потребление уменьшится на 10 мА при прочих равных. Вы же, надеюсь, не дергаете сигнал прием/передача с частотой 1 МГц? :(

для линий я использую экранированую витую пару пятой категории.

С двойным экраном? Один из фольги, второй из медной плетенки? Тогда ладно... :)

 

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

[GrayCat 0]

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

 

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

 

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

 

 

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

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

 

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

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

[smalcom 0]

Замените хотя бы ISO2 на обычный транзисторный оптрон

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

 

Вы же, надеюсь, не дергаете сигнал прием/передача с частотой 1 МГц?

нет, конечно)) максимум вроде около 100-150Гц

 

по протоколу. протокол у меня простой:

Заголовок

Адресат

Команда

Данные постоянной длины

CRC16

 

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

[=AK= 12]

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

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

 

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

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

 

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

Я писал, что нужно два элемента:

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

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

 

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

[defunct 0]

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

Есть более простой способ решающий эту проблему - байт стаффинг.

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

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

 

по протоколу. протокол у меня простой:

Заголовок

Адресат

Команда

Данные постоянной длины

CRC16

Что такое "Заголовок"?

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