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

[NewWriter]

Ьам вобщем говоря, вот какая проблема то обнаружилась. Просьба автору ВНИМАТЕЛЬНО изучить осциллограмму приема-передачи и ОСОБЕННО поведение управляющих направлением сигналов.
На осциллограмме:
желтый - принимаемая в главный МК (U4) инфа
синий - передаваемая из главного МК (U4) инфа
розовый - управление направлением на подчиненном МК (U1)
зеленый - управление направлением на главном МК (U4)

Видите? У вас они просто неправильно работают. В момент передачи от главного МК сигнал разрешения передачи у главного отсутствует. На RC5 (U4)должен быть высокий уровень, чтобы началась передача через интерфейс, а у вас уровень переключается на низкий слишком рано, не после передачи запроса, а перед его началом. К тому же, U1 начинает переключать управление и передавать, не дождавшись окончания приема всего сообщения. У вас просто не передается команда запроса от главного МК. Потому и ответа нет.

И еще - обратить внимание на длиннющий список предупреждений о неправильной работе со стеком и командами call, return в МК U1.




PS. Кстати. Когда у MAX485 соединены два входа разрешения |RE и DE, работая как бы на переключение, то получаем одну неприятную штуку: при передаче |RE и DE =1, а значит, выход RO находится в Hi-Z состоянии, так же, как и вход RX у МК. И на этом входе очень даже хорошо могут наводиться помехи, которые в определенных обстоятельствах могут привести к ложным срабатываниям приемника в МК и появлению флага ошибки фрейма.
Просто подтяните RX к питанию. Либо запретите прием во время передачи.

[dosikus]

А второе я хотел бы именно Вас попросить разрешить ситуацию с которой столкнулся еще раз. Почему именно Вас? Потому что у Вас есть Протон, потому что у Вас есть Протеус и потому что Вы себя позиционируете профессионалом. Так вот в прилагаемом примере есть две схемы. В одной контроллеры связываются по УАРТ а в другой РС485.

Я вам уже указывал на вашу ошибку , вы проигнорировали . Попытаюсь еще раз :

Prer:
Context Save 
If PIR1.5 = 1 Then                           
HSerIn 1,Main,[Perem, Reg]       
EndIf
Context Restore                
INTCON.7 = 0

Resume

И так, HSerIn нельзя использовать в прерывании. Вызов чего либо (подпрограмм/процедур/функций) в прерывании для новичков вообще противопоказан, а тем более высокоуровневой конструкции использующей таймаут.

Все остальное даже обсуждать не буду, ибо это не код - лапша.
Может будет проще написать подробное ТЗ и выложить здесь?

[vladh]

Два модуля == беспроводной UART + абсолютная гальваноразвязка .

Это замечательно.

И причем здесь китаец? Вы надеетесь что у вас чип сляпанный не в Китае?

Я когда то для себя решил(прочел где то), что вся продукция MAXIM производится в вмерике и в Китай они ничего не перебрасывали.

[vladh]

Просьба автору ВНИМАТЕЛЬНО изучить осциллограмму приема-передачи и ОСОБЕННО поведение управляющих направлением сигналов.

Да, огромное спасибо за подсказку иного подхода к выявлению причины сбоя. Вообще осциллограмма тоже немного привирает. Я, в своем коде, перед командой выдачи данных "открывал ворота", делал паузу, передавал данные, делал паузу и закрывал. Правда экспериментируя, я эти ворота закомментировал. Но даже если их открыть, у меня обмена данными не будет(да и нет я пробовал). Дело скорее всего вот в чем. Я почему то считал, что время выдачи данных около 20 мкс. Я опять же считал что время работы бейсик-команды ответственной за выдачу данных равно времени выдачи данных. Т.е. программа не перейдет к следующей пока МК не выдаст все данные. А реально это похоже не так работает. Т.е. мне нужно следить за и за битом TXIF регистра PIR1. Когда этот бит обнулится только тогда закрывать ворота на выдачу данных.

[OakRidge]

vladh,
Вам упорства не занимать !
Разумеется цепь знания -› опыт -› упорство никто не отменял !
Когда первые две точки граблей кончются последняя тоже вариант
Удачи Вам !

[vladh]

vladh,
Вам упорства не занимать !
Разумеется цепь знания -› опыт -› упорство никто не отменял !

А я считаю это не цепь а цикл.

[NewWriter]

Вообще осциллограмма тоже немного привирает.

Как она может привирать? Она не может настолько соврать, чтобы перепутать черное с белым.
В данном случае осциллограмма честно показывает состояние выходов, изменяющееся в соответствии с исполняемым кодом МК. А код исполняется точно так, как был написан, вернее, скомпилирован протоном (или бейсиком, чем там, я не разбираюсь в нем).
Ну а если вот такой график?
Может быть, станет понятнее, что именно не работает?
Посмотрите на графики - там все подписано - с главного МК уходят запросы, они идут беспрерывно, до тех пор, пока не придет ответ. А он - не приходит. Потому что линия находится в свободном состоянии, передача от главного МК запрещена.




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

[STM32F0]

Время выполнения команд МК нужно считать не на высокоуровневом бейсике, а на низкоуровневом ассемблере.

И в чём разница? Где точнее? Считать такты это верный путь к безнадёге, или от безнадёги. Это, как правило, результат:
1. Неправильного выбора МК.
2. Непонимания происходяшего или неправильно составленного алгоритма.
3. Неправильной расстановки приоритетов.

[NewWriter]

Быть может, стоит более аккуратно перерисовать проект и добавить туда инструментов анализа и графиков, чтобы было понятнее, откуда ноги растут у проблемы? Например, вот так: (во вложении).
Там беда именно в переключениях направлений в полудуплексном интерфейсе.

[vladh]

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