Witam, Pytanie odnośnie komunikacji modbus RTU po RS232. Z Stm32f103 wysyłam zapytania na MAX485. Do urządzenia dochodzi pytanie bo sygnalizuje to diodą, oraz urządzenie sygnalizuje odpowiedź. Sprawdzałem po stronie TX (przed MAX485) za pomocą SimpleTerm Gold i ramka się zgadza, natomiast na RX...

Cisza w sensie że Slave nie odpowiada czy nic nie odbierasz w armie? W pierwszym przypadku może sie adres slava nie zgadzać, suma crc błędna, nie kompatybilne ustawienia magistrali, w drugim coś mnie widze obsługi odbioru w armie (przerwanie, DMA). Ponadto te opóźnienia nie wyglądają dobrze, szczególnie odczekiwanie 1 sekundy i dopiero potem przestawianie się na odbiór

Do slave napewno pytanie dochodzi bo to sygnalizuje. Sygnalizuje również odpowiedź . Teraz sprawdzam tak: 1) Przed RS485 na MAX485 podglądam co jest na DI i rzeczywiście zgadza się wysłana ramka. 2) Przed RS485 na MAX485 podglądam co jest na RO i tam jest cisza. Narazie w ogsługę w STM nie ma co wnikać bo dane muszą się dopiero pojawić z RS485 na pinie RO układu MAX485. Między masą a RO jest 5.1V ....

Masz opóźnienie zanim się przełączysz na odbiór, może poprostu przegapiasz ramkę?

@kornik280 Tak jak w pierwszym poście opóźnienia. Po GPIO_ResetBits(GPIOA, GPIO_Pin_8); niby ma być odbiór.

Chodzi o to że wysyłasz dajesz opóźnienie przełączasz się na odbiór i podczas tego opóźnienia może przyjść odpowiedź

to tak robie - co wynika z kodu w pierwszym poście...

i robisz źle, co wynika z odpowiedzi i z tego że masz problem. Slave nie będzie czekał aż mu pozwolisz na odpowiedź, tylko odpowiada najszybciej jak to możliwe. A że Ty wtedy nie odbierasz...

@Freddie Chopin po pierwsze odbieranie po rs232 mam zrobione w przerwaniu więc odbieram. A po drugie czy to takie istotne ma moim etapie? Tak jak wcześniej wspomniałem wpinam się i podglądam co pojawia się na linii za pomoca przejściówki usb/rs232 którą wpinam do układu tak jak poniżej:

Niczego nie odbierasz - nieważne czy przez polling czy w przerwaniu czy przez DMA czy jakkolwiek sobie życzysz - układ MAX-485 masz przestawiony na nadawanie. Odpowiedź przychodzi w czasie Twojego delaya. Jeśli wiesz lepiej gdzie jest problem niż kilka osób (mówiących o tym samym problemie), to w sumie po co pytać na forum?

Jak nie dasz strobowania w stan niski to max485 nic nie odbierze , W Twoim przypadku odpowiedź prawdopodobnie przychodzi w czasie twojego opóźnienia

REKLAMA

Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

STM32f103rb - Brak odpowiedzi na RX przy komunikacji Modbus RTU po RS232

ienecode 10 Maj 2016 14:35 8118 150

Najlepsze odpowiedzi

Dlaczego STM32F103RB nie odbiera odpowiedzi Modbus RTU po RS485 przez MAX485 i jak poprawnie przełączyć się z nadawania na odbiór?

MAX485 trzeba przełączać na odbiór natychmiast po zakończeniu nadawania, a nie po stałym opóźnieniu; zamiast czekać na TXE należy czekać na bit TC w USART i dopiero wtedy ściągnąć DE/RE w stan odbioru [#15670454][#15673836] Nie warto też blokować przerwania odbioru ani wykonywać w nim długich operacji — w IRQ najlepiej tylko ustawić flagę, a wysyłanie/analizę zrobić w `main()` albo z timera/SysTick [#15667601][#15677505][#15677603] W Twoim przypadku był jeszcze drugi błąd: `ramkaodbierz` była tylko wskaźnikiem, który nie wskazywał na zaalokowaną pamięć, więc zapis do niej powodował problemy; trzeba zrobić z niej tablicę o odpowiednim rozmiarze [#15676888][#15677014] Po tych poprawkach urządzenie zaczęło poprawnie widzieć ramki odpowiedzi [#15671402]

Wygenerowane przez model językowy.

REKLAMA

Zgłoś naruszenie prawa

Odpowiedz | Nowy temat

#1 15663308 10 Maj 2016 14:35

ienecode ienecode

Poziom 21

Posty: 2097

Ocena: 96
Autor tematu

Post #1
15663308 10 Maj 2016 14:35

Witam,

Pytanie odnośnie komunikacji modbus RTU po RS232.

Z Stm32f103 wysyłam zapytania na MAX485. Do urządzenia dochodzi pytanie bo sygnalizuje to diodą, oraz urządzenie sygnalizuje odpowiedź. Sprawdzałem po stronie TX (przed MAX485) za pomocą "SimpleTerm Gold" i ramka się zgadza, natomiast na RX jest cisza. Co może być przyczyną ?

Tak wygląda mój main:
Kod: C / C++
Zaloguj się, aby zobaczyć kod
Wyzwalacze, powiadomienia i optymalizacja zużycia energii przy wykorzystaniu mierników energii Fox [sponsorowany]
REKLAMA
#2 15663324 10 Maj 2016 14:43

kornik280 kornik280

Poziom 18

Posty: 466

Pomógł: 36

Ocena: 14
Pomocny post? (0)

Post #2
15663324 10 Maj 2016 14:43

Cisza w sensie że Slave nie odpowiada czy nic nie odbierasz w armie?
W pierwszym przypadku może sie adres slava nie zgadzać, suma crc błędna, nie kompatybilne ustawienia magistrali, w drugim coś mnie widze obsługi odbioru w armie (przerwanie, DMA).
Ponadto te opóźnienia nie wyglądają dobrze, szczególnie odczekiwanie 1 sekundy i dopiero potem przestawianie się na odbiór
#3 15663334 10 Maj 2016 14:47

ienecode ienecode

Poziom 21

Posty: 2097

Ocena: 96
Autor tematu Pomocny post? (0)

Post #3
15663334 10 Maj 2016 14:47

Do slave napewno pytanie dochodzi bo to sygnalizuje.
Sygnalizuje również odpowiedź .

Teraz sprawdzam tak:
1) Przed RS485 na MAX485 podglądam co jest na DI i rzeczywiście zgadza się wysłana ramka.
2) Przed RS485 na MAX485 podglądam co jest na RO i tam jest cisza.

Narazie w ogsługę w STM nie ma co wnikać bo dane muszą się dopiero pojawić z RS485 na pinie RO układu MAX485. Między masą a RO jest 5.1V ....
#4 15663343 10 Maj 2016 14:50

kornik280 kornik280

Poziom 18

Posty: 466

Pomógł: 36

Ocena: 14
Pomocny post? (0)

Post #4
15663343 10 Maj 2016 14:50

Masz opóźnienie zanim się przełączysz na odbiór, może poprostu przegapiasz ramkę?
#5 15663515 10 Maj 2016 16:10

ienecode ienecode

Poziom 21

Posty: 2097

Ocena: 96
Autor tematu Pomocny post? (0)

Post #5
15663515 10 Maj 2016 16:10

@kornik280 Tak jak w pierwszym poście opóźnienia.
Po GPIO_ResetBits(GPIOA, GPIO_Pin_8); niby ma być odbiór.
#6 15663631 10 Maj 2016 17:07

kornik280 kornik280

Poziom 18

Posty: 466

Pomógł: 36

Ocena: 14
Pomocny post? (0)

Post #6
15663631 10 Maj 2016 17:07

Chodzi o to że wysyłasz dajesz opóźnienie przełączasz się na odbiór i podczas tego opóźnienia może przyjść odpowiedź
#7 15663716 10 Maj 2016 17:40

ienecode ienecode

Poziom 21

Posty: 2097

Ocena: 96
Autor tematu Pomocny post? (0)

Post #7
15663716 10 Maj 2016 17:40

kornik280 napisał:
Chodzi o to że wysyłasz dajesz opóźnienie przełączasz się na odbiór i podczas tego opóźnienia może przyjść odpowiedź

to tak robie - co wynika z kodu w pierwszym poście...
REKLAMA
#8 15663765 10 Maj 2016 18:05

Freddie Chopin Freddie Chopin

Specjalista - Mikrokontrolery

Posty: 13336

Pomógł: 1712

Ocena: 870
Pomocny post? (0)

Post #8
15663765 10 Maj 2016 18:05

i robisz źle, co wynika z odpowiedzi i z tego że masz problem. Slave nie będzie czekał aż mu pozwolisz na odpowiedź, tylko odpowiada najszybciej jak to możliwe. A że Ty wtedy nie odbierasz...

Promuję tematy:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM
#9 15663805 10 Maj 2016 18:24

ienecode ienecode

Poziom 21

Posty: 2097

Ocena: 96
Autor tematu Pomocny post? (0)

Post #9
15663805 10 Maj 2016 18:24

@Freddie Chopin po pierwsze odbieranie po rs232 mam zrobione w przerwaniu więc odbieram.

A po drugie czy to takie istotne ma moim etapie? Tak jak wcześniej wspomniałem wpinam się i podglądam co pojawia się na linii za pomoca przejściówki usb/rs232 którą wpinam do układu tak jak poniżej:
#10 15663823 10 Maj 2016 18:30

Freddie Chopin Freddie Chopin

Specjalista - Mikrokontrolery

Posty: 13336

Pomógł: 1712

Ocena: 870
Pomocny post? (0)

Post #10
15663823 10 Maj 2016 18:30

Niczego nie odbierasz - nieważne czy przez polling czy w przerwaniu czy przez DMA czy jakkolwiek sobie życzysz - układ MAX-485 masz przestawiony na nadawanie. Odpowiedź przychodzi w czasie Twojego delaya. Jeśli wiesz lepiej gdzie jest problem niż kilka osób (mówiących o tym samym problemie), to w sumie po co pytać na forum?

Promuję tematy:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM
#11 15663828 10 Maj 2016 18:33

kornik280 kornik280

Poziom 18

Posty: 466

Pomógł: 36

Ocena: 14
Pomocny post? (0)

Post #11
15663828 10 Maj 2016 18:33

Jak nie dasz strobowania w stan niski to max485 nic nie odbierze , W Twoim przypadku odpowiedź prawdopodobnie przychodzi w czasie twojego opóźnienia
#12 15663842 10 Maj 2016 18:39

ienecode ienecode

Poziom 21

Posty: 2097

Ocena: 96
Autor tematu Pomocny post? (0)

Post #12
15663842 10 Maj 2016 18:39

Freddie Chopin napisał:
Niczego nie odbierasz - nieważne czy przez polling czy w przerwaniu czy przez DMA czy jakkolwiek sobie życzysz - układ MAX-485 masz przestawiony na nadawanie. Odpowiedź przychodzi w czasie Twojego delaya. Jeśli wiesz lepiej gdzie jest problem niż kilka osób (mówiących o tym samym problemie), to w sumie po co pytać na forum?

Nie wiem gdzie jest problem, staram się zrozumieć gdzie leży.
To w takim razie co mogę zrobić z moją pętlą żeby był czas na odebranie informacji ?

Dodano po 1 [minuty]:

W ten sposób:
Kod: C / C++
Zaloguj się, aby zobaczyć kod
REKLAMA
#13 15663857 10 Maj 2016 18:44

kornik280 kornik280

Poziom 18

Posty: 466

Pomógł: 36

Ocena: 14
Pomocny post? (0)

Post #13
15663857 10 Maj 2016 18:44

Teraz masz szanse zobaczyć coś bo max zaraz po wysłaniu ramki przechodzi w tryb odbioru
#14 15663931 10 Maj 2016 19:17

Freddie Chopin Freddie Chopin

Specjalista - Mikrokontrolery

Posty: 13336

Pomógł: 1712

Ocena: 870
Pomocny post? (0)

Post #14
15663931 10 Maj 2016 19:17

Dalej jest źle, bo na początku pętli znów przestawiasz MAXa w tryb nadawania (natychmiast po tym jak przestawiłeś go w tryb odbioru).

Promuję tematy:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM
#15 15663947 10 Maj 2016 19:31

ienecode ienecode

Poziom 21

Posty: 2097

Ocena: 96
Autor tematu Pomocny post? (0)

Post #15
15663947 10 Maj 2016 19:31

Freddie Chopin napisał:
Dalej jest źle, bo na początku pętli znów przestawiasz MAXa w tryb nadawania (natychmiast po tym jak przestawiłeś go w tryb odbioru).

To jak to zrealizować, Żeby dać czas procesorowi na odebranie danych z MAX485? Bo ja nie mam pomysłu...

Dodano po 8 [minuty]:

Bez Delay'ów tylko w obsłudze przerwania od odebrania napisać ifa który czeka aż przyjdzie cała ramka ?
#16 15663988 10 Maj 2016 19:36

Freddie Chopin Freddie Chopin

Specjalista - Mikrokontrolery

Posty: 13336

Pomógł: 1712

Ocena: 870
Pomocny post? (0)

Post #16
15663988 10 Maj 2016 19:36

Ależ możesz dać delaye, tylko w odpowiednim miejscu... Niemniej jednak te delaye nadają się tylko do testowania czy transmisja działa, bo w "normalnym" programie to będzie już musiało być zrobione inaczej.

Promuję tematy:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM
#17 15663996 10 Maj 2016 21:18

ienecode ienecode

Poziom 21

Posty: 2097

Ocena: 96
Autor tematu Pomocny post? (0)

Post #17
15663996 10 Maj 2016 21:18

Freddie Chopin napisał:
bo w "normalnym" programie to będzie już musiało być zrobione inaczej.

Tz jak ?
Narazie przychodzi mi do głowy tylko takie rozwiązanie:
Załóżmy że bez Delay'ów w mainie. W pętli jest tylko wysyłana ramka i zmiana pinu sterującego.
Natomiast w przerwaniu sprawdzam: jeśli odebrano pierwszy bajt (tj. adres urządzenia ) to odbieram kolejne aż do otrzymania sumy CRC ?
Wtedy by to miało sens ?

Dodano po 1 [godziny] 38 [minuty]:

To tak,
Wyskrobałem obsługę przerwania odebrania z RS która na razie wygląda następująco:
Kod: C / C++
Zaloguj się, aby zobaczyć kod

Póki co to mam problem bo nie wiem kiedy stwierdzić że to koniec ramki, zaraz pod komentarzem "//warunek konca ramki??????????????????"

Jaki tam warunek powinien być ?
#18 15664957 11 Maj 2016 07:48

kornik280 kornik280

Poziom 18

Posty: 466

Pomógł: 36

Ocena: 14
Pomocny post? (0)

Post #18
15664957 11 Maj 2016 07:48

To jest bardziej skomplikowane, poczytaj to: https://www.elektroda.pl/rtvforum/topic409812.html
#19 15664994 11 Maj 2016 08:15

ienecode ienecode

Poziom 21

Posty: 2097

Ocena: 96
Autor tematu Pomocny post? (0)

Post #19
15664994 11 Maj 2016 08:15

To wychodzi na to że w warunku muszę dodać odliczanie czasu 3,5 znaku ? jeśli przekroczy ten czas to wchodzi mi do tego ifa , tak ?
Tylko w jaki sposób to zrealizować ?
REKLAMA
#20 15665005 11 Maj 2016 08:20

stracho stracho

Poziom 13

Posty: 71

Pomógł: 5

Ocena: 5
Pomocny post? (0)

Post #20
15665005 11 Maj 2016 08:20

Link
#21 15665017 11 Maj 2016 08:27

ienecode ienecode

Poziom 21

Posty: 2097

Ocena: 96
Autor tematu Pomocny post? (0)

Post #21
15665017 11 Maj 2016 08:27

Nie będzie to takie łatwe :/
#22 15665048 11 Maj 2016 08:43

kornik280 kornik280

Poziom 18

Posty: 466

Pomógł: 36

Ocena: 14
Pomocny post? (0)

Post #22
15665048 11 Maj 2016 08:43

Na początek możesz mieć ramke na sztywno wiesz co posyłasz do slava i wiesz jak długa będzie odpowiedź,w przerwaniu inkrementujesz tablice.
Gdy doliczysz się całej ramki wtedy ją sprawdzasz.
Nie jest to rozwiązanie idealne. Preferowane jest z mierzeniem 3,5T
#23 15665655 11 Maj 2016 13:36

ienecode ienecode

Poziom 21

Posty: 2097

Ocena: 96
Autor tematu Pomocny post? (0)

Post #23
15665655 11 Maj 2016 13:36

To zrobiłem tak jak mówisz:

Kod: C / C++
Zaloguj się, aby zobaczyć kod

Jeśli mam tyle bytów o ile pytam to ramkę uważam za całą i sprawdzam czy suma CRC się zgadza. Myślę że to mi spokojnie wystarczy na funkcjonalność jaką potrzebuje.

Teraz pytanie odnośnie przerobienia maina.
Bo rozumie że w mainie w pętli głównej nie mogę mieć ciągle wysyłania ramki bo nie będzie czasu na to żeby mikroporcesor przechwycił przerwanie z RXNE ?
W takim razie mam zrobić jakieś przerwanie zegarowe które będzie wywoływać co jakiś czas wysłanie rami ? To rozwiąże problem ciągłego wysyłania ?
#24 15665760 11 Maj 2016 14:44

kornik280 kornik280

Poziom 18

Posty: 466

Pomógł: 36

Ocena: 14
Pomocny post? (0)

Post #24
15665760 11 Maj 2016 14:44

Najprościej użyć przerwanie od SystTick i tam wysyłać zapytanie
#25 15665989 11 Maj 2016 17:31

ienecode ienecode

Poziom 21

Posty: 2097

Ocena: 96
Autor tematu Pomocny post? (0)

Post #25
15665989 11 Maj 2016 17:31

Nie wiem czy dobrze jeszcze zrozumiałem przerwanie od licznika zliczającego w dół SysTick.
Procesor skonfigurowałem na zewnętrznym oscylatorze 8MHz i przez PLL ostatecznie jest teraz 72MHz.

Główna funkcja ma teraz taką postać:
Kod: C / C++
Zaloguj się, aby zobaczyć kod

czyli teraz co 1ms jest wywoływana funkcja SystTick_Handler ?
Kod: C / C++
Zaloguj się, aby zobaczyć kod

Tak to zrozumiałem z jakiegoś tutoriala...
gdybym w funkcji SysTick_Config(CLK_FREQ/1000); nie dzielił przez 1000 tylko zostawił moją częstotliwośc 72MHz to przerwanie było by co 1s ? dlaczego tak niby ?
#26 15666012 11 Maj 2016 17:39

Konto nie istnieje Konto nie istnieje

Konto nie istnieje

Post #26
15666012 11 Maj 2016 17:39

Damian7546 napisał:
gdybym w funkcji SysTick_Config(CLK_FREQ/1000); nie dzielił przez 1000 tylko zostawił moją częstotliwośc 72MHz to przerwanie było by co 1s ? dlaczego tak niby ?

72e6 razy sie zmieni to wywoła UEV co spowoduje wywołanie (w tym przypadku) tego handlera. poniewaz 1 zmiana licznika to 1 takt zegara to 72e6 / 72e6 = 1s

Jak wartość bedze 72e3 to 72e3/ 72e6 = 1e-3s

Takie pytanko: czy wiesz w ogóle jak działa licznik?
#27 15666040 11 Maj 2016 17:46

ienecode ienecode

Poziom 21

Posty: 2097

Ocena: 96
Autor tematu Pomocny post? (0)

Post #27
15666040 11 Maj 2016 17:46

No wiem że to układ który zlicza impulsy z zegara z którego jest taktowany mikroprocesor.

http://echiny.pl/piotr/arm/konfiguracja-rcc-i-nvic-obsluga-systick-oraz-timera-tim2

Tutaj gośc pisze że jak częstotliwość taktowania podzieli przez 1000 to wywołanie będzie miał co 1ms ....
@Piotrus_999 Ty napisałeś odwrotnie :
Piotrus_999 napisał:
72e3/ 72e6 = 1e-3s
#28 15666053 11 Maj 2016 17:50

Konto nie istnieje Konto nie istnieje

Konto nie istnieje

Post #28
15666053 11 Maj 2016 17:50

Damian7546 napisał:
impulsy z zegara z którego jest taktowany mikroprocesor.

Niekoniecznie - poczytaj zanim cos napiszesz.

Damian7546 napisał:
@Piotrus_999 Ty napisałeś odwrotnie :
Piotrus_999 napisał:
72e3/ 72e6 = 1e-3s

Naprawde?
Matematycy kurcze blade - takie rzeczy to chyba pod koniec podstawówki

wiesz co znaczy 1e-3s 0.001s?

a jeszcze chcą żeby matematyka na maturze była nieobowiązkowa
#29 15666066 11 Maj 2016 17:55

ienecode ienecode

Poziom 21

Posty: 2097

Ocena: 96
Autor tematu Pomocny post? (0)

Post #29
15666066 11 Maj 2016 17:55

Piotrus_999 napisał:
Naprawde?

wiesz co znaczy 1e-3s 0.001s?

a jeszcze chcą żeby matematyka na maturze była nieobowiązkowa

nie o zapis mi chodziło tylko myślałem że w argumencie funkcji SysTim_Config chciałeś wstawić 72e3/ 72e6.
Ale już rozumie:
1/72e6 = czas jednego taktu
więc:
czas jednego taktu *72000 = 0.001s.
#30 15666071 11 Maj 2016 17:57

grko grko

Poziom 33

Posty: 1386

Pomógł: 247

Ocena: 141
Pomocny post? (0)

Post #30
15666071 11 Maj 2016 17:57

Cytat:

72e6 razy sie zmieni to wywoła UEV co spowoduje wywołanie (w tym przypadku) tego handlera. poniewaz 1 zmiana licznika to 1 takt zegara to 72e6 / 72e6 = 1s

Jak wartość bedze 72e3 to 72e3/ 72e6 = 1e-3s

Takie pytanko: czy wiesz w ogóle jak działa licznik?

Tyle że systick jest 24 bitowym timerem. Wypadałoby zajrzeć do implementacji zanim zaczniesz wprowadzać w błąd autora.
Zarejestruj konto, Zaloguj się i bądź aktywny na forum, a wtedy reklamy nie będą się pojawiać. Dołącz do dyskusji i otrzymaj punkty za rejestrację oraz odpowiedzi.

Zainstaluj aplikację Elektroda

Odpowiedz | Nowy temat

Zgłoś naruszenie prawa

Podsumowanie tematu

✨ Użytkownik zadał pytanie dotyczące problemu z komunikacją Modbus RTU po RS232 z użyciem mikrokontrolera STM32F103RB i układu MAX485. Mimo że zapytania są wysyłane poprawnie, odpowiedzi nie są odbierane. W dyskusji poruszono kwestie związane z opóźnieniami w przełączaniu trybów nadawania i odbioru, co może prowadzić do utraty odpowiedzi. Użytkownicy sugerowali poprawki w kodzie, takie jak zmiana kolejności operacji oraz użycie przerwań do obsługi odbioru. Wskazano również na konieczność poprawnej konfiguracji zegara oraz na problemy sprzętowe, takie jak niewłaściwe połączenia w układzie. Ostatecznie, po wprowadzeniu poprawek, użytkownik uzyskał poprawną komunikację, jednak nadal występowały sporadyczne problemy z odbiorem danych.
Wygenerowane przez model językowy.

REKLAMA