galjoen 0 6 июня, 2008 Опубликовано 6 июня, 2008 · Жалоба То-же задумывался. А какая дальность прогнозировалась и какая получилась? На скорости 57600 связывались компьютер через USB-HID переходник (самодельный на ATmega64, пишущий трафик во флэш) и 6 блоков ATmega64 (планировалось до 64). Общая длина кабеля 50 м. Сбоев по причине помех не было замечено. Перед передачей контроллеры ждали тишину на линии (контроль тишины происходил постоянно). Передача начиналась с 0xAA как в LIN. Если самопринятый 0xAA был запорчен (коллизия)- опять ждали тишину, время зависящее от N блока. Входы RxD у ATmega64 были соединены с входами захвата таймеров для точного тайминга. За счёт ненужности опроса ведущим (и отсутствия самого ведущего) трафик резко уменьшался, и зависил ТОЛЬКО от частоты событий в сети. Всё хорошо работало, но перешли к CAN (на то-же место стали паять AT90CAN64). В принципе переход на CAN был скорее маркетинговым ходом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nelord 0 8 июня, 2008 Опубликовано 8 июня, 2008 · Жалоба ... Передача начиналась с 0xAA ... Тут начал моделировать все запрограммированное, при соединении UART'ов все передает как и было задумано, при установке трансивера MAX487 с подключенными согласующими резисторами 120 Ом (соединяют А и В в непосредственной близости с самыми "удаленными" абонентами), наблюдаю следующую ситуацию: канал свободен и абоненты считывают его состояние, то есть сигнал DE/!RE=0, согласующие резисторы дают на линиях A, B сигнал "1", модель этой ИМС в Proteus 7.2 при таком уровне выдает на линию RO="0", то есть UART абонента принимает этот "0", но он конечно игнорируется до приема 0хАА (начала кадра). Можно ли как-нибудь разрешить эту ситуацию так, чтобы этот "0" не приходил, когда не нужно? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nelord 0 8 июня, 2008 Опубликовано 8 июня, 2008 · Жалоба Попутно возник еще один вопрос, при детальном анализе ситуации, принимаемый байт "00", когда на линии никто не активен, устанавливает USR.FE. В документации написано: данный флаг устанавливается в "1" при обнаружении ошибки кадрирования, т.е. если стоп-бит принятого слова равен "0"; флаг сбрасывается аппаратно при приеме стоп-бита, равного "1". Флаг действительно установился в "1", однако вернуть его в "0" - не получается ни "clr temp | out USR, temp", ни приемом нормального стоп-бита. Моделирую в упоминавшемся ранее Протеусе 7.2. Сталкивался ли кто-нибудь с похожей ситуацией, если, подскажите, пожалуйста, как сбросить этот флаг. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 8 июня, 2008 Опубликовано 8 июня, 2008 · Жалоба Тут начал моделировать все запрограммированное, при соединении UART'ов все передает как и было задумано, при установке трансивера MAX487 с подключенными согласующими резисторами 120 Ом (соединяют А и В в непосредственной близости с самыми "удаленными" абонентами), наблюдаю следующую ситуацию: канал свободен и абоненты считывают его состояние, то есть сигнал DE/!RE=0, согласующие резисторы дают на линиях A, B сигнал "1", модель этой ИМС в Proteus 7.2 при таком уровне выдает на линию RO="0", то есть UART абонента принимает этот "0", но он конечно игнорируется до приема 0хАА (начала кадра). Можно ли как-нибудь разрешить эту ситуацию так, чтобы этот "0" не приходил, когда не нужно? Подавить нуль в принципе можно растяжками А и Б в направлении земли и единицы, но так не делают настоящие профессионалы по причинам, которые я не хотел бы сейчас обсуждать Правильное решение проблемы таково: - при наличии сигнала break(а это называется именно так) в линии приемник игнорирует принятый байт, сбрасывает все ошибки и продолжает прием. - передатчик начинает передачу так: включает передатчик, передает сигнал RxD пассивного уровня в течение времени не менее длительности байта. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vet 0 9 июня, 2008 Опубликовано 9 июня, 2008 · Жалоба Попутно возник еще один вопрос, при детальном анализе ситуации, принимаемый байт "00", когда на линии никто не активен, устанавливает USR.FE. В документации написано: данный флаг устанавливается в "1" при обнаружении ошибки кадрирования, т.е. если стоп-бит принятого слова равен "0"; флаг сбрасывается аппаратно при приеме стоп-бита, равного "1". Флаг действительно установился в "1", однако вернуть его в "0" - не получается ни "clr temp | out USR, temp", ни приемом нормального стоп-бита. Моделирую в упоминавшемся ранее Протеусе 7.2. Сталкивался ли кто-нибудь с похожей ситуацией, если, подскажите, пожалуйста, как сбросить этот флаг. а зачем его сбрасывать? в даташите он помечен "только для чтения", его значение обновится с приемом следующего символа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
galjoen 0 9 июня, 2008 Опубликовано 9 июня, 2008 · Жалоба Подавить нуль в принципе можно растяжками А и Б в направлении земли и единицы, но так не делают настоящие профессионалы по причинам, которые я не хотел бы сейчас обсуждать Кроме экономии электроэнергии я других причин отказа от растяжки не вижу. Правильное решение проблемы таково: - при наличии сигнала break(а это называется именно так) в линии приемник игнорирует принятый байт, сбрасывает все ошибки и продолжает прием. - передатчик начинает передачу так: включает передатчик, передает сигнал RxD пассивного уровня в течение времени не менее длительности байта. При таком подходе: 1. В случае тишины на линии ПОСТОЯННО будут приходить 0е байты с ошибкой формата (break). Их придётся всё время обрабатывать по прерыванию тратя на это время. И допустимое время работы с запрещёнными прерываниями уменьшится в 2 раза (из-за занятости одного уровня FIFO приёмника). 2. Передача RxD пассивным уровнем (1) (или что тоже самое - передача FF) будет воспринята приёмником как приём байта в одном из вариантов FF, FE, FC, F8, F0, E0, C0, 80 или 00 без ошибки формата. 3. Это задержит начало передачи собственно данных на время 1 байт. Т.е. существенно затормозит сеть. Всё это (в т.ч. растяжка резисторами) не нужно т.к. можно использовать приёмопередатчики RS485 со сдвинутыми уровнями у A и B. Есть такие. Их электрические характеристики ПОЛНОСТЬЮ соответствуют стандарту RS485, но уровни у A и B сдвинуты так, что тишина на линии ВОСПРИНИМАЕТСЯ КАК 1. Вот от использования таких приёмопередатчиков я не вижу причины отказываться. 2 'nelord' 1. За давностью забыл - 1м байтом передавалось не 0xAA, а 0x55. Т.е. в линии 0101010101 (0x55), а не 0010101011 (0xAA). 2. Эта передача (1й 0x55) имеет смысл только при мультимастерной сети (для разрешения коллизий). В случае с 1м ведущим она не нужна т.к. коллизии и так невозможны. 3. Вы какую хотите создавать сеть - с 1м ведущим или мультимастерную? 4. Если вы хотите мультимастерную сеть, то рекомендую использовать CANовские приёмопередатчики. Например PCA82C251. Их кстати можно использовать и просто вместо RS485 приёмопередатчиков, тогда не нужны будут растяжки (у них уровни сдвинуты) и не надо будет переключать приём/передачу (передаётся только 0). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 9 июня, 2008 Опубликовано 9 июня, 2008 · Жалоба Все, что Вы сказали, в общем-то верно, но в решении с растяжками теряется помехоустойчивость, потому что растяжка не может быть идентична включению самого драйвера. Иногда такое решение просто не проходит из-за требований организации, сертифицирующей устройство на соответствие определенному протоколу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nelord 0 9 июня, 2008 Опубликовано 9 июня, 2008 · Жалоба Вы какую хотите создавать сеть - с 1м ведущим или мультимастерную? Сеть получилась мультимастерная, а сигнал "break" вызывал дополнительную обработку прерываний, однако это на производительность не сильно сказалось. Спасибо большое за помощь в решении возникших вопросов, работа была успешно сдана! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
