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

[anatol378]

vladh, не хочу больше тупить мозги. Предлагаю сделать на 485 два непереключаемых канала и запустить через них UART. Если все будет как на проводочках, то чтото не так в протоколе обмена.

[dosikus]

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

[anatol378]

dosikus, Алексей хрень не гони. Кто направления переключает в RS485?

Работа приемника USART в асинхронном режиме (восьмибитный прием):

Главным элементом приемника является регистр RSR. Это сдвиговый регистр, который, собственно, и принимает данные, со скоростью, установленной генератором обмена. Программно этот регистр не доступен, а данные из него автоматически загружаются в регистр RCREG после цикла получения стопового бита, если этот регистр не заполнен. После этого выставляется флаг прерывания RCIF (пятый бит регистра PIR1 (0Ch)). Само прерывание можно запретить сбросом бита RCIE (5-й бит регистра PIE1 (8Ch)), но флаг все равно будет выставляться.

Регистр RGREG представляет сбой двухуровневый FIFO, т.е. в него можно принять два байта. Чтобы считать из него два байта, нужно просто прочитать его два раза.

Если в регистр RSR принят байт (пришел стоповый бит), а в регистре RCREG уже есть два байта, то выставляется флаг переполнения приемника OERR (первый бит регистра RCSTA (18h)), а принятый байт теряется. Сбросить флаг OERR можно только выключив и заново включив приемник.

Таким образом, последовательность действий при приеме следующая:

1) Инициализация: установить скорость, режим генератора скорости обмена, выбрать восьмибитный режим, разрешить/запретить прерывания, включить приемник.

2) Работа: ожидать появления флага RCIF, после этого проверить, нет ли ошибки FERR, затем считать данные из RCREG и, наконец, проверить (и, если надо, то сбросить) ошибку переполнения.

Это к вопросу ТС

Если в программе передатчика в строке 38 уменьшить время задержки менее 5 мс, то результат опять будет похожий

из первого поста.
В ПИКе нет длинного буфера. И покуда принимающий контроллер занимается херней с первыми принятыми байтами остальные летят в жопу.
К тому же АЦП должен "отдыхать" и этом контроллере он 10 битный. ТС отвел ему байт. Ну и т.д.
Мне это не нужно, пытаюсь подсказать направления.

В конце концов http://www.microchip.ru/lit/?mid=1x0

[NewWriter]

Кто направления переключает в RS485?

а если полудуплекс, только по двум проводам, а надо и туда, и сюда. ...в RS485, а не UART

И покуда принимающий контроллер занимается херней с первыми принятыми байтами остальные летят в жопу

А чтобы программа МК могла самостояятельно распознать, что был пропуск байтов, есть такой специальный бит - OERR

[dosikus]

Кто направления переключает в RS485?

И что? ...
Изучи даташит на MAX'ы, и обрати внимание на MAX488/490 .
Изумительно, не правда ли - ничего переключать не надо .
Из Half-duplex получили Full-duplex.
А протокол не меняется . и RS485 так и остался транспортом для UART

[anatol378]

Та ничаго.
Просто аппаратный RS232 с его высокими напругами и защитными интервалами по напряжению (гистерезис), не стоит сравнивать с аппаратно програмным RS485. Да и применение немного разное, несмотря на передачу данных в обоийх случаях.
Кстати RS232 легко защитить от помех при работе через дифференциальные трансформаторы. Проводочкой поболее надобно будет.

Изучи даташит на MAX'ы

Нахрена. MAX'ы не протокол, а средство сопряжения.

Думаю не секрет что RS485 предназначен для работы с "витая пара" с типовым волновым сопротивлением 120 ом (и терминаторами с таким же сопротивлением) противофазными сигналами с целью максимального уменьшения наводок. Идея не новая и применялась в телефонии с 19 века.

[Boba_spb]

И что? ...
Изучи даташит на MAX'ы, и обрати внимание на MAX488/490 .
Изумительно, не правда ли - ничего переключать не надо .
Из Half-duplex получили Full-duplex.
А протокол не меняется . и RS485 так и остался транспортом для UART

Если не считать, что RS485 стал RS422

RS485 - всегда Half-duplex - ну не может он одновременно передавать в обе стороны всего одна линия.
RS422 - Full-duplex - у него две линии .

[dosikus]

Если не считать, что RS485 стал RS422

Все это уже разрыв мозга...

не стоит сравнивать с аппаратно програмным RS485.

Как это не стоит, если в данном случае и в большинстве это и имеем - RS485 как транспорт.

Нахена. MAX'ы не протокол, а средство сопряжения.

А зачем тебе потрошить физику RS485 если он для юзера прозрачен и по сути является мостом.
Интересно как ты будешь работать с ESP12, там уже WiFi - так же разгребать до теории радиоволн?

[Boba_spb]

А зачем тебе потрошить физику RS485 если он для юзера прозрачен?

Вот в этом и весь фокус - в RS485 необходимо управлять направлением передачи. Закончил передачу - освободи линию. Правда иногда делают автоматический выбор направления

[dosikus]

Boba_spb, Я это прекрасно знаю . Посмотри выше - здесь пока не требуется коммутировать линию , один вечно приемник другой вечно передатчик.
Здесь можно закрыть глаза на отличии UART от RSxxx.
Пусть сначала на этих кошках потренируются , а то разрыв мозга обеспечен.