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

[Someone]

Ошибаетесь. Докажите.

Ну вы же согласны с тем, что язык программирования (бейсик или С) роли не играет? И что за более чем десяток лет, задача связи двух пиков через rs-485 решалась не раз (я бы сказал не одну тысячу раз)? Вот и остаётся только логика реализации. Выбери вы другую логику решения, например, что мастер каждые полсекунды шлёт запрос и ожидает ответа, а слэйв, соответственно, передаёт только в ответ на запрос к себе, у вас бы всё сразу работало, и через прямое соединение контроллеров, и через 485й, при условии целостности линии связи.

На основании чего Вы так решили?

Дык вот:

Если соединить два МК по UART то все(и модель в Протеусе, и живая схема) работает. Но как только я начинаю переходить на RS485 все начинает работать непонятно.

Я в стартовом сообщении писал, что по обычному UART контроллеры обмениваются без проблем(двухсторонний обмен в моей основной программе). Но мне надо разнести контроллеры на 20 м и я подозреваю, что в этом случае можно будет наловить блох. Поэтому решил добавить RS485. И когда я начал пробовать с эти протоколом пошли чудеса.

Все сказанное должно проявляться и тогда кода связь осуществляется непосредственно по USART. Но в этом случае все ХОРОШО! А ПЛОХО становится, когда начинаю работать чрез МАХ485 или как на схеме МАХ487?

Я уже писал, что состыковал два МК по интерфейсу UART. Они периодически обмениваются данными и все работает вполне себе хорошо. Но вот когда я захотел усложнить задачу и организовать связь по 485 интерфейсу. Тем более, что переход на него должен был быть достаточно простой, а надежность канала значительно выше. Я собрал схему и в живую и в Протеусе. И тут началось.

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

Ещё цитировать, или хватит? А ведь Анатолий ещё во втором посте сей темы сказал "Протокол обмена RS485 не равен RS232 (UART)". Видя, что так и не поняли - попытался разъяснить разницу, пардону прошу за самоцитирование:

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

[Someone]

Удваивать не нужно - в том то и суть, чтобы не передавать от мастера в тот момент, когда может передать слейв.

Ну так ведь оценивается вероятность сбоя в случае, если мастер зафиксирует нажатие кнопки, и сразу попытается передать сообщение слэйву, просто начиная передачу, как было у ТС, и получается, что мастер может начать передачу и закончить её, пока от слэйва придёт очередная посылка, может начать передачу, когда посылка идёт, и может не успеть закончить передачу, когда от слэйва пойдёт посылка. Итог - пока кнопки не трогают - данные от слэйва поступают. как только кнопки начинают жать, в 2х случаях из 3х на линии каша и посылки пропадают, либо путаются данные, о чём ТС и жалуется. А "не передавать от мастера в тот момент, когда может передать слейв" - это уже решение проблемы. Как именно этого не допустить - таймером, контролем линии, либо другим способом - не суть как важно. Любой из методов решения имеет свои достоинства и недостатки.

[STM32F0]

Ну вы же согласны с тем, что язык программирования (бейсик или С) роли не играет?

Играет. Это как читать даташит писаный арабской вязью или китайскими/японскими иероглифами. Типа тоже язык, но не для техники. Да и основные споры, всё более редкие в последнее время, АСМ vs Си, кто там сейчас ещё пачкается об васик?

Любой из методов решения имеет свои достоинства и недостатки.

Если бы ТС знал все достоинства и недостатки, он бы и тему не поднимал. Видать васик не знает напрочь о таком чуде как RS485, так всё запущено.

[Someone]

Играет.

Т.е. по вашему, если программа написана на С, то когда мастер начнёт передачу в линию 485го, в тот момент, когда по этой линии идёт передача от слэйва, не произойдёт ничего страшного, и никакой ошибки не возникнет?

[STM32F0]

Т.е. по вашему

По моему, васик настолько ограничен, что даже RS485 не может работать как положено. А на Си куча примеров, весь инет завален.

[Boba_spb]

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

[Someone]

По моему, васик настолько ограничен, что даже RS485 не может работать как положено. А на Си куча примеров, весь инет завален.

Это таки не ответ на вопрос, а отмазки. Поробуем ещё раз:

если программа написана на С, то когда мастер начнёт передачу в линию 485го, в тот момент, когда по этой линии идёт передача от слэйва, не произойдёт ничего страшного, и никакой ошибки не возникнет?

[Someone]

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

Дык некоторые (не будем показывать пальцем), считают, что это бейсик виноват, и, видимо, если с полудуплексной линией работать как с полнодуплексной, но на С, то всё получится в лучшем виде.

[Boba_spb]

Частенько пользую RS485 - последнее время на С# пишу. И хде там что про RS485 в C# хоть слово. Открыл COM порт и вперед !!! Так что не надо путать алгоритм работы с языками. Если алгоритм кривой, то он кривой хоть на С, хоть на Асме, хоть на каком-то Васике или Барсике

[STM32F0]

некоторые (не будем показывать пальцем), считают, что это бейсик виноват, и, видимо, если с полудуплексной линией работать как с полнодуплексной, но на С, то всё получится в лучшем виде.

Можно и не сомневаться!

последнее время на С# пишу. И хде там что про RS485 в C# хоть слово. Открыл COM порт и вперед !!! Так что не надо путать алгоритм работы с языками. Если алгоритм кривой, то он кривой хоть на С, хоть на Асме, хоть на каком-то Васике

А почему не на васике-шарп? Значит дело не только в алгоритмах.