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

[Someone]

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

Вот, сами ведь понимаете, что программист виноват. . Задумайтесь о такой простой вещи - и сей компилятор, и пики существуют более десятка лет. За это время миллионы программистов решили свои задачи. Если исходить из вашей логики "у меня всё хорошо, это компилятор или пик чудит", получается что у вас настолько уникальная задача, что ни разу, никем, за эти грубо говоря 10 лет, не решалась, и никто ранее не сталкивался с ошибкой в компиляторе или в пике. Или, иными словами, никто из миллионов программистов, за более чем 10 лет, не связывал два пика по RS-485. Как, по вашему так и было, или ваше "у меня всё нормально" не соответствует истине?

ЗЫ: Что касается работы усарт и не работы 485 - так это разные вещи с разными принципам работы. Усарт в соединении 2х контроллеров (TX1-›RX2, RX1-›TX2) является полнодуплексной линией, и по нему можно одновременно вести передачу обоим контроллерам. 485й же является полудуплексной линией, и в ней двум контроллерам нельзя вести одновременно передачу - будет не распознаваемая каша. И логика работы с 485, и, соответственно, программа, будет совершенно другая. Так что ничего удивительного в "неработе" нет. Привыкайте, что ни компилятор, ни контроллер собственного разума не имеют, и делают только то, что им сказал делать программист. И если девайс работает как-то не так, особенно в тепличных условиях, на столе - значит программист так написал программу.

[Someone]

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

Естественно. Как и в паскале, да и в любом ЯВУ. Что бы там Досикус не распевал про бейсик и С - проблема не в языке, а в программисте. Да, в С программа вероятно будет быстрее работать, скомпилированный код, очень вероятно, займёт меньше места. Но логику работы, и, соответственно, правильность работы программы, определяет программист. А не правильную логику прописать на С так же легко, как и на бейсике.

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

Вопрос: А что произойдёт, если ведущий решил что-то изменить, и посылает посылку с кодом изменения, когда ведомый всё ещё ведёт свою регулярную передачу?

[makakus]

Йаплакаль...

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

Мастер передаёт пакет. Слейв принимает байт заголовка, запускает счётчик таймаута и зарекается передавать что-нибудь до конца приёма пакета или таймаута.
По окончании приёма пакета передаёт подтверждение приёма (должна быть пауза на переключение линии). Если мастер не получил подтверждение, он повторяет команду. Пакет может содержать счётчик повторов/номер пакета.

В общем, бросить изобретать велосипедов, прочитать про уровни системы osi, почитать про модбус и прочие шины-протоколы. Поверьте, всё уже давно придумано до нас.

[akegor]

В общем, бросить изобретать велосипедов, прочитать про уровни системы osi, почитать про модбус и прочие шины-протоколы. Поверьте, всё уже давно придумано до нас.

Не забывайте о разумной достаточности.
Лепить монстроидальный модбас на один датчик только из-зя того, что кто-то его давным давно придумал? Гы! Ну, ежели есть такие продвинутые желающие... Утрирую, конечно же, но математика оперирует крайностями для понятия направления действий.
Да, не надо забывать и о том, что многое в придуманном делается для совместимости, стандартности, что нужно далеко не всегда.

[NewWriter]

485й же является полудуплексной линией

Строго говоря, нет. Это трансивер MAX487 - полудуплексный. А RS485 может быть и полу- и полнодуплексной линией.
Точно так же и модуль USART в ПИКе может работать в полудуплексном синхронном режиме.

(CRC, а не "всех просуммируем",

Недавно мы тут разбирали протокол связи метеостанции с дистанционным датчиком по радиоканалу, и там - простая сумма.

Вопрос: А что произойдёт, если ведущий решил что-то изменить, и посылает посылку с кодом изменения, когда ведомый всё ещё ведёт свою регулярную передачу?

У топикстартера там между посылками ведомого пауза в полсекунды. Ну уж можно как-то исхитриться и выловить момент, чтобы на пару-тройку миллисекунд занять линию
Не нравится? MAX489/MAX490 - и не ждите освобождения линии.

[vladh]

Естественно. Как и в паскале, да и в любом ЯВУ.

Ну наконец я получил ответ ны поставленный выше вопрос. Действительно, Dosikus зря с пренебрежением относится к другим языкам.

Вопрос: А что произойдёт, если ведущий решил что-то изменить, и посылает посылку с кодом изменения, когда ведомый всё ещё ведёт свою регулярную передачу?

Что произойдет? А ничего. Потеряется эта посылка. А действительно я не предусмотрел такой вариант. Спасибо.

[NewWriter]

Вероятность попадания отправки именно в момент приема - около 1/250 для конкретно этого проекта.
Тут как выходит - когда идут регулярные посылки со слейва, и нужно что-то отправить с мастер-устройства, перед тем, как отправить, вычисляем, сколько времени назад была предыдущая посылка (обычный таймер, запускаемый сразу после предыдущего приема). И если по времени таймера ожидается приход посылки со слейва и есть вероятность не успеть отправить, тогда чутка подождем и начнем отправку сразу после приема со слейва. Конечно, интервалы посылок со слейва должны быть достаточно одинаковыми. Небольшой плюс-минус допустим, но чтобы не сильно.
Как-то так.

[akegor]

Период посылок, наверняка, известен. Это же не неизвестное устройство? Поэтому достаточно сделать паузу после приема со слейва и не наворачивать излишние усложнения (это не способствует надежности).

[jump]

Dosikus зря с пренебрежением относится к другим языкам

ему можно - хвост в виде милицейского жезла
за это время (с 10.09) и протокол можно изучить/создать, и программу на асме сваять (коль в ЯВУ плаваете), и ошибки при наличии железного осцилла, лог. анализатора и исд2 найти - не факт, что все устранили и новых не наделали.
если сделать очень низкой скорость USARTов и повесить на RX/TX/направление светодиоды, то можно по их свечению уже кое-что предположить/оценить, в ряде случаев звуковая карта в режиме записи/редактирования подойдет

[vladh]

Период посылок, наверняка, известен. Это же не неизвестное устройство? Поэтому достаточно сделать паузу после приема со слейва и не наворачивать излишние усложнения (это не способствует надежности).

Я уже так и сделал.