Неправильная работа Proton с RS485

[Boba_spb]

Ну если столько проблем при передачи в одну сторону, и заявками что RS232 на большие расстояния лучше RS485/RS422, то лучше ТС бросить все это на ... и заняться более простыми вещами.

[Boba_spb]

Кстати RS232 легко защитить от помех при работе через дифференциальные трансформаторы. Проводочкой поболее надобно будет.

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

[vladh]

anatol378, Да уж , тупить не стоит . Может вам обоим просто взять примеры из мануала Hserin и Hserout . Запустить Hserin на одном и Hserout на другом пЫк ?
Сначала без контроллеров RS485, по UART. Затем тупо добавить контроллеры RS 485.
Блин ну не смешите форум.
anatol378, UART от RS485 отличается только физикой , в вашем случае добавлением MAx'ов...

Алексей, я Вам с самого начала пишу об этом. В Протеусе и на "проводочках" Без МАХ485 все работает как надо! Но как только начинаю применять эти м/схемы передача данных становится проблематичной. И у меня возникли два вопроса: "Кто(что) виноват?" и "Что делать?".

[NewWriter]

Во-первых, сделать линию короткой, буквально по 20 см. И можно без терминаторов (резисторов параллельно). И запитать передатчик и приемник от одного источника.
Во-вторых, на приемнике убрать сигнал управления направлением - отсоединить от RC5 МК, а |RE и DE на приемнике MAX487 прицепить к GND, RC6/TX МК отсоединить за ненадобностью. На передатчике то же самое, только наоборот, разрешая только передачу без переключения.

В-третьих. Как я понял, то, что выложено было в самом первом сообщении, работает через RS485 в железе без проблем? Судя по проекту в протеусе - да. Если проблем нет - вот и забейте.

[vladh]

В-третьих. Как я понял, то, что выложено было в самом первом сообщении, работает через RS485 в железе без проблем?

Нет. без проблем работало, когда не было RS485. После того как я их запаял обмен данными прекратился. Я стал выяснять причину. Уменьшил схему до минимума. Код тоже. Но проблемы стали появляться уже и в случае когда был только канал UART. Усиленно пообщавшись вчера здесь на сайте я выяснил, где собака зарылась. Сегодня, с утра, я поставил эксперимент и убедился, что возникшее прерывание выводит программу из выполняемой Бейсиком команды. Раньше я думал, что это невозможно. Это видимо было моё главное заблуждение. И после того как я это начал учитывать, "больной начал выздоравливать". Поэтому большое всем спасибо за участие и даже тем кто был подчас невежлив ко мне.

[dosikus]

Алексей, я Вам с самого начала пишу об этом. В Протеусе и на "проводочках" Без МАХ485 все работает как надо! Но как только начинаю применять эти м/схемы передача данных становится проблематичной. И у меня возникли два вопроса: "Кто(что) виноват?" и "Что делать?".

Виноваты только вы сами:
Из-за посредственного знания языка неверно используете ресурсы пЫк и компилятора.
Пытаетесь готовые высокоуровневые "кубики" барсика задействовать в низкоуровневой работе .
Ошибочный перевод описания софтового прерывания вы приняли за описание железного.
И здесь уже ваше право обижаться или нет.
Попытаюсь еще раз - займитесь изучением как языка так и С ...

[vladh]

И здесь уже ваше право обижаться или нет.

А я и не обижаюсь ни на кого. И даже на себя. Мне, кстати, так никто и не ответил на заданный мной ранее вопрос: "В СИ также возможны ситуации при которых команды языка СИ могут прерываться возникшим прерыванием?" Это раз. А второе я хотел бы именно Вас попросить разрешить ситуацию с которой столкнулся еще раз. Почему именно Вас? Потому что у Вас есть Протон, потому что у Вас есть Протеус и потому что Вы себя позиционируете профессионалом. Так вот в прилагаемом примере есть две схемы. В одной контроллеры связываются по УАРТ а в другой РС485. Алгоритм работы этих должен быть такой. Нажав на вирт. клавиатуре кнопку "1" перейдем в следующее окно. Здесь необходимо нажать кнопку "5". Остальные функции здесь везде убраны. После нажатия этих кнопок загорается светодиод и левый по схеме МК начинает передавать данные(положение движка переменника) правому МК. При повторном нажатии на "5", передача данных прекращается, светодиод гаснет, дисплей возвращается в предыдущее окно. Для варианта прост УАРТ все работает, а 485 нет.
Вот и помогите найти мне бяку.

[anatol378]

vladh, специально поставил протеус - схемку посмотреть.
Здесь я уже писал про арбитраж шины.
Как вы определяете что канал не занят и можно начинать передачу? Я увидел что тупо переключили направление канала и вперед...
В 232 просто скрестили линии и все. А здесь надо или захватить шину и получить подтверждение о приеме, или послать запрос о передаче, получить готовность к приему, передать инфу и послать сигнал конца сообщения, получить подтверждение приема. Исходное полошение 485 прием в оба конца.
Иначе туда дуй -оттуда х...й

[NewWriter]

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

Если же у вас связь идет в обе стороны, и только между двумя устройствами, то можно применить четырехпроводную схему с полным дуплексом на MAX490 (или сдвоенные MAX485, включенные одна только на передачу, одна только на прием) или ее аналогах, не переключая направления передачи и не заботясь о занятости линии. Моделировать в протеусе этот вид RS485 не обязательно, он работает аналогично простому UART.

которых команды языка СИ могут прерываться возникшим прерыванием?"

Имеете ввиду аппаратное прерывание МК по какому-то событию? Или как?

[vladh]

Как вы определяете что канал не занят и можно начинать передачу? Я увидел что тупо переключили направление канала и вперед...

Да все верно.

В 232 просто скрестили линии и все. А здесь надо или захватить шину и получить подтверждение о приеме, или послать запрос о передаче, получить готовность к приему, передать инфу и послать сигнал конца сообщения, получить подтверждение приема.

Наверное так надо делать, когда на шине больше двух абонентов. А если только два, то обмен можно упростить. Логика работы моей схемы такая. Один абонент главный, второй ведомый. Естественно общение начинает главный. Он посылает посылку и ждет ответа. После получения ответа, он видит что посылка прошла и понята правильно дальше он только регулярно принимает данные о состоянии ведомого абонента. Если ведущий решил что то изменить он опять посылает посылку с кодом изменения. Естественно он тут же должен получить ответ, что посылка принята и понята. Мне видится этого достаточно.

Иначе туда дуй -оттуда х...й

Как видите в случае с 485 так и получается - оттуда ни ответа ни привета.
И, кстати, спасибо за участие в моей проблеме.