Witam serdecznie wszystkich użytkowników forum wraz z Administracją

Kieruję się do Waszej społeczności z nastawieniem, iż będziecie w stanie mi pomóc, a nie to co na innym forum, którego pierwsza litera (w cudzysłowie oczywiście) wyraża się taką samą literą jak podstawa logarytmu naturalnego

Przechodzę do problemu, otóż tam, gdzie pracuję mamy kilkanaście sztuk bardzo starych wskaźników (liczników), które mają port komunikacyjny RS485 w standardzie ASCII. Port ten służy do programowania urządzenia dedykowanym programem oraz do odczytu aktualnych wartości, np. przepływu oraz stanu licznika nr 1 i nr 2.
Powiedzmy, że mamy taki wskaźnik o adresie 81, zapytanie o aktualny przepływ wygląda następująco:


Odpowiedź jest następująca:


Na początku odpowiedzi mamy takie dane jak, typ (model) wskaźnika, jego adres, ciąg liczb, które reprezentują datę oraz godzinę, a na końcu mamy aktualny przepływ.
Zapytanie o stan liczników wygląda tak:


Odpowiedź:


Tutaj początek odpowiedzi wygląda podobnie, jednakże nas interesują wartości po "h", tam są wskazania sumatorów nr 1 i nr 2.

Moja prośba jest następująca: czy jest możliwość, aby wykorzystać ATMegę 164a (bo taką akurat znalazłem w naszych zasobach) do odczytu tych danych z w/w wskaźnika poprzez wykorzystanie portu UART0 razem z układem MAX485, obrobienie ich tak, aby wyjściowo mieć same końcowe wartości (tutaj będą to 197.5 oraz 0000130952), konwersja na ModBusa i wyrzucenie ich na porcie UART1 jako RS485 ModBus RTU?

Mam nadzieję, iż opisałem zagadnienie w miarę czytelnie, w razie czego w załączniku podsyłam pomocne (wg mnie) materiały do analizy problemu. Jeśli będzie potrzeba, to jutro po południu będę mógł wrzucić skany z DTR wskaźnika dot. komunikacji poprzez 485.

Nie wiem, czy mogę oficjalnie robić reklamę innego forum, dlatego w załączniku również podam adres do zagranicznego forum, w którym zwróciłem się o pomoc z tym samym problemem, ale z wykorzystaniem RaspberryPi i programu Node-Red, to rozwiązanie akurat wyśmienicie się sprawuje, ale niestety nie wszędzie mam możliwość jego wykorzystania, dlatego wpadłem na pomysł z wykorzystaniem ATmegi. Oczywiście w miarę możliwości chciałbym, aby jedna ATMega mogła obsłużyć do 5 takich wskaźników jednocześnie, ponieważ są miejsca, gdzie akurat tyle ich mamy w bliskiej odległości.

Na koniec zostawiłem najważniejsze: mam dostęp do bibliotek Pana Mirosława "MK MULTI UART 2.0", czekam na dostawę GreenBooka. Co do programu - coś spróbowałem samemu podziałać, jednakże nic nie wychodzi tak jak ma być. W załączniku również podsyłam moje wypociny, ale proszę mnie nie bić za to. Jeśli jest taka możliwość to proszę o nakierowanie, bądź wskazanie co gdzie należy zrobić.

Przy próbach przy podłączonym wskaźniku udało się uzyskać odpowiedzi po zapytaniach ze strony ATMegi, także komunikacja po tej stronie działa. Układ jaki zbudowałem był następujący: Atmega podłączona poprzez układ MAX485 do wskaźnika FP210, a po drodze wpiąłem się konwerterem USB-TTL w nóżki Atmegi i uruchomiłem program "Hercules", aby mieć podgląd na linię.


Z góry dziękuję za poświęcony czas na analizę i odpowiedzi
Pozdrawiam, Robert
____
EDIT
Masz Ci los.... nie wysłałem tego projektu, który chciałem, a ponadto awaria internetu spowodowała, że nie mogę korzystać z komputera tylko z telefonu, w razie jakichkolwiek pytań, jutro będę mógł odpowiadać, bo z telefonu to ciężko będzie.....


[ usunąłem cały załącznik bo zawierał pełną bibliotekę Mk Multi UART! Proszę mi powiedzieć jaki jest sens pisania czy to książek czy bibliotek i próba ich sprzedawania przeze mnie jeśli później ktoś za darmo wystawia to na forach internetowych? Do czego ta biblioteka w pliku ZIP ? Kolega chciał przedstawić swoją pracę i poddać pod ocenę czy moją ? .... Bardzo proszę uprzejmie na przyszłość o tym pomyśleć zanim się zrobi takie rzeczy ok? Mam nadzieję, że na tym innym forum kolega nie zrobił takiej samej rzeczy? czy może jednak tak? A jeśli tak - to proszę też o usunięcie tej biblioteki z tamtego czy innych forów. Co za problem wstawić w ZIP swój własny kod ? bez moich bibliotek ? - mirekk36]

Taki konwerter możesz zrobić właśnie za pomocą takiej ATmegi.
Poniżej przykład właśnie takiego konwertera, który z kodu w ASCII zamienia na MODBUS RTU:
https://www.e-tronix.eu/8,konwerter-rs2 ... odbus.html

Pozdrawiam

_________________
Rozwój i utrzymywanie Oprogramowania

Przepraszam z całych sił Pana Mirosława, oczywiście wrzucenie tego projektu nie było celowe, może być Pan spokojny, nigdzie - podkreślam - NIGDZIE nie publikowałem tego projektu oraz Pana bibliotek.
Biorąc pod uwagę moją głupotę proszę o usunięcie tematu, postaram się samemu we własnym zakresie znaleźć rozwiązanie, ja tymczasem nie będę już publicznie udzielał na forum.

@0livaw
Widziałem już tą stronę, kontaktowałem się z nimi, czekam na odpowiedź

No przecież jeśli kolega to rozumie - to po co się zaraz obrażać na forum i już z niego nie korzystać. Proszę tylko po prostu o nie udostępnianie publiczne bibliotek. To chyba nic złego.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Nie ma tak dobrze, wracaj tu!

@mirekk36
Panie Mirosławie, nie chodzi o to, że się obrażam na forum, po prostu czuję się jakby spalony już tutaj, oczywiścnie nie powinno mieć miejsca to co się wydarzyło. W pełni się zgadzam, że nie powinno udostępniać się płatnych bibliotek.

@wonsz
Muszę wrócić, aby pokazać co narobiłem.

main.c:


Wiem, że nie jest to kod najwyższych lotów, jego struktura i jako całość boli w oczy, ale jest tak, ponieważ dopiero raczkuję w świecie programowania w C, a muszę przyznać, że trochę mi się spieszy ze znalezieniem rozwiązania. Mam uzyskaną transmisję po ASCII, UART0 służy do komunikacji z tym nieszczęsnym wskaźnikiem, jednakże odpowiedzi wysyłam z mojego PC w zastępstwie - obecnie nie mam fizycznego dostępu do w/w wskaźnika. UART1 służy do wysyłania już obrobionych danych (pobranych z UART0) do PC. Teraz chciałbym w miarę możliwości te dane wysyłać w ModBusie RTU po 485. Jest to do zrobienia? Mogę liczyć na pomoc?
Jedynie co jeszcze zauważyłem, a co mi się teraz nie podoba to to, że wystarczy raz odpowiedzieć na zapytanie, a program ciągle wysyła to co raz odebrał. Nie jest to dobre rozwiązanie, próbowałem czyścić zawartość flow, albo totaliser po każdym wysłaniu znaku \r, ale nie uzyskałem zadowalającego efektu. Widać to na zrzucie w załączniku. W lewym okienku mam podgląd na ruch na UART0, czarną czcionką są znaki wysyłane przez mikrokontroler, różowy/fioletowy (jestem mężczyzną, rozpoznaję tylko RGB) to odpowiedź, którą wysyłam (symulacja wskaźnika). W prawym okienku widać ruch na UART1.
Oczywiście dociera do mnie, że to tylko prosta transmisja ASCII, teraz chciałbym odpowiedzi wysyłać na ModBusa RTU.



Z góry dzięki za poświęcony czas.

Pomijam już fakt, że tak długie delaye jak 5000 nie zadziałają, 2000 pewnie też nie - to już sam fakt że w pętli głównej stosujesz: UART_RX_EVENT(); i do tego delaye, chociażby miały one mieć tylko 100ms ... to jest mniej więcej tak jakbyś chciał jechać szybko autem z zaciągniętym na MAXA hamulcem ręcznym.

Zapamiętaj sobie, że jeśli już zabierasz się za programowanie z użyciem Zdarzeń (Events) to ZAPOMNIJ o delajach na amen. To oznacza wyraźnie, że na razie nie rozumiesz jeszcze kompletnie co to oznacza i co to z kolei znaczy pisanie programów w sposób nieblokujący.

Na tym etapie zachęcam jednak do przestudiowania dokładnie końcówki Bluebooka ale też przede wszystkim całego GREENBOOKA ... tam znajdziesz wyjaśnienia w czym rzecz.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Oczywiście zdaję sobie sprawę z tego, że nie jest ten kod napisany w sposób optymalny, jednakże jak wspominałem wcześniej metodą prób i błędów udało mi się stworzyć tego potwora, który "działa". Czyli po zapytaniu "81D" po trzech sekundach leci zapytanie "81L", po czym po sześciu sekundach znów leci "81D" i tak w kółko. Rozumiem, co Pan miał na myśli pisząc
Da się, ale to męczenie silnika i hamulców.
Z czystej ciekawości zostawiłem na dobę uruchomiony ten program i odczytywałem na bieżąco to co się dzieje na obu uart'ach - ani razu się nic nie wysypało, cały czas mikrokontroler działał w porządku.

Jest jedna sprawa, która mnie nurtuje, mianowicie czy uda się zrobić z tego ModBusa RTU? Wiem, wiem, ględzę o tym jak najęty, ale to jest bardzo ważna sprawa dla mnie....

Oczywiście jestem w trakcie analizy książek, o których Pan wspomniał.

Poszukaj gdzieś na tym forum jest biblioteka ModBudRtu ona na pewno się przyda do tego zadania oprócz tego musisz te delaye zamienić na timer programowy bo inaczej nic z tego nie będzie.

No niestety po dwóch tygodniach walki z tym muszę poddać temat. Są to dla mnie zbyt wysokie progi.
Chyba, że ktoś chce w łatwy sposób - - zarobić, to możemy pomyśleć o jakiejś formie współpracy, ja postaram się odwdzięczyć za poświęcony czas

@tonygryps jedyne biblioteki, które znalazłem to te z freemodbus, ale one są ogólnie dostępne w necie.

Dziękuję wasze odpowiedzi w tym temacie

Czy próbował ktoś może uruchomić programik p. Vadovica ze strony developrog .com ?

Ja niestety dalej próbuję ugryźć temat, ponieważ zaczynają nade mną wisieć coraz ciemniejsze chmurki, no i moja upartość powoduje, że chcę to zakończyć z powodzeniem.... W dodatku brak czasu na zabawy z AVR-ami dają mi się we znaki....
Wydaje mi się, że mógłbym wykorzystać ten kod do moich potrzeb, tylko nie udaje mi się tego uruchomić na moim uC. Prawdopodobnie błąd wisi na początku, tam gdzie wprowadzane są wektory przerwań, ale nie mogę dojść co w końcu robię źle.


Po przestudiowaniu wszelakich źródeł wiedzy, a przede wszystkim BB i GB wydaje mi się, że poprawne wartości wprowadziłem, jedynie co, to w projekcie autor zastosował kwarc 12 MHz, ja zaś działam na 11 059 200. W załączniku podaję odnośnik do strony projektu p. Vadovica

Jest tam też projekt dla arduino nano, ten również próbowałem dostosować do moich warunków, ale niestety poległem.
Widocznie nie nadaję się do tego, skoro dalej stoję w miejscu

Tak na początek w AVRmodbus.c zmieniłem na:


Koncepcja:
1. utworzenie prostego kodu w MkClipce z dodaną biblioteką modbus
2. dodanie biblioteki do obsługi UART/RS485 (np. Mirka) i wykonanie prostych testów
3. dodanie własnych funkcjonalności związanych z konwersją danych

12MHz dla USART to taki sobie pomysł (lepiej posłuchać porad Mirka ).

Jest też inny przykład, który powinien ładnie się kompilować pod ATMEGA164P:
https://community.atmel.com/projects/mo ... ibrary-avr

@JarekK - Dziękuję za odpowiedź oraz dziękuję za podanie linków i za podanie koncepcji, spróbuję coś sklecić z tego, już udało mi się uruchomić komunikację (po małych przeróbkach w pliku nagłówkowym) poprzez RS485 z wykorzystaniem bibliotek "yaMBSiavr" (w sumie kiedyś mi się one przewinęły przez palce, ale za Chiny Ludowe nie mogłem ich znaleźć ponownie), przy chwili czasu spróbuję zabrać się za ogarnięcie całości. Jeśli coś z tego sklecę to się tutaj pochwalę. Ja korzystam z kwarcu 11,059 MHz, kwarc 12 MHz został wykorzystany przez autora bibliotek, które podałem w moim poprzednim poście, czyli p. Vadovica ze strony developrog .com
Jeszcze raz wielkie dzięki

W międzyczasie bliżej przyjrzałem się opisowi na stronie Dalibora Vadovica.
Chcąc zmienić kwarc w jego implementacji modbusa powinno się trochę zmienić ustawienia dla timerów:
"Im using 12Mhz crystal then im settng prescaler of timer 2 to 256-> 12 000 000/256=0.021ms for one tick
then for 1.5char is value =1.718/0.021=81 in dec or in hex 0x51 and for time 3.5 char =4.01/0.021=190 in dec or in hex 0xBE".
Wtedy dla 11 059 200 odpowiednio dla 1,5 char będzie 74 (decimal), a dla 3,5 char będzie 173 (dec).
Dorzucam próby przeportowania USART i timera na ATmega164 . Jest dużo dłubania bo przy okazji są błędy w datasheet do tego procka i trzeba sprawdzać niektóre opisy rejestrów w toolchainie w nagłówkach iom164.h oraz iomxx4.h
Nie mam ATmegi 164 wiec nie przetestowane.

ATmega 164, main.c

Witam, po kilku wiadomościach wymienionych z kolegą @JarekK zdecydowałem się pokazać moje dotychczasowe prace.
Po analizie i wielokrotnych próbach związanych z ogarnięciem bibliotek z różnych źródeł wykorzystałem bibliotekę "yaMBIavr", ponieważ wydawała mi się w miarę przystępna i najlepiej pasująca do moich potrzeb. Po przeanalizowaniu całości i odkryciu jak uruchamiana jest obsługa UART0, spróbowałem w podobny sposób uruchomić UART1 ale tylko w trybie ASCII. W załączniku wrzucam moje wypociny. Wszystkie moje zmiany zostały skomentowane w odpowiedni sposób. W tym przypadku chciałem, aby co pół sekundy na UART1 była wyrzucana cyfra 8, niestety bez rezultatu, przy czym UART0 działa bez zająknięcia jako ModBus RTU.
Pozdrawiam, Robert

_______
Jeszcze jedna sprawa mnie zastanawia - może spróbować wykorzystać innego AVR-a? Może ta ATMega 164A nie będzie się do tego nadawać?

Jeśli niepotrzebne to proponowałbym wyciąć z main.c
volatile uint8_t instate = 0;
volatile uint8_t outstate = 0;

i odpowiednio
SetOuts()
ReadIns()
io_conf()

i wyciąć odpowiednio w modbusGet() wszystko co dotyczy "coils" i "discrete inputs"

Może PD3 się haczy z Tx a jest w "Inputs: PC0, PC1, PC2, PC3, PC4, PC6, PD4, PD3"
Może lepiej też pobrać wersje biblioteki modbus z 2017r. z github'a (w tej z 2016 były drobne poprawki np. było Baut 64).
I najlepiej zapomnieć o stosowaniu _delay_ms w modbus_RTU gdyż ten może się przez to wysypać (na przerwaniu nieustannie szukana jest przerwa w transmisji 3,5 - 4 znaku)

Może być interesujące, że w bibliotece w pliku yaMBSiavr.h są zdefiniowanie:

#define modbusInterFrameDelayReceiveStart 16
#define modbusInterFrameDelayReceiveEnd 18
#define modbusInterCharTimeout 7

Wartości te są odpowiednie dla 20MHz/38400 Bps i timera jak w przykładzie: 20MHz/8/256 w wyniku ("ISR is called 9765.625 times per second").
Autor przyjął tu zgodnie z dokumentacją modbus.org (Modbus_over_serial_line_V1.pdf str. 14) : "For baud rates greater than 19200 Bps, fixed values for the 2 timers should be used: it is recommended to use a value of 750µs for the inter-character time-out (t1.5) and a value of 1.750ms for inter-frame delay (t3.5)."

Przykładowo dla kwarcu 16 MHz, oraz takiej samej wartości 38400 i timera 16MHz/8/256 powyższe ustawienia powinno się zmienić odpowiednio z (16,18,7) na (14,15,6)
Gdy jednak mamy niższe prędkości transmisji to przykładowo dla 9600 Bps wartości te powinny wynosić:
18.452 MHz/9600Bps i timera 18.452MHz/8/256 (32,37,14)
11.592MHz/9600Bps i timera 11.592/8/256 (20,23,8 )

Powyższe wszystkie obliczenia dotyczą ramki UART 8-N-1 (tzn. długość 10 bitów).

Po kolei odpowiem, też myślałem o tym, aby uporządkować to co jest w tym pliku main.c, lecz jedynie co to zmieniłem odniesienia z portu D na porty A, B i C, także piny na porcie D mam zarezerwowane tylko dla potrzeb komunikacji. Dlatego tak to zostawiłem, ponieważ mam też w głowie (o ile ten projekt wypali) kontrolę napięcia poprzez ADC, kontrola otwarcia szafy (coś a'la kontaktron), pomiar temperatury wnętrza itp. Oczywiście do samych testów mogę wywalić te niepotrzebne elementy. Co do aktualnej wersji bibliotek - nie ma znaczenia to chyba dla mnie na razie, bo i tak stoję w miejscu

Co do drugiej odpowiedzi - czy są to pomiary które mają wpływ na działanie całości? Spróbuję dzisiaj kopnąć do tego, gdyby coś się ruszyło to dam znać. Tak sobie jeszcze pomyślałem - może zmienić prędkość jednego z UARTów - może to oddziaływać na zachowanie tej ATMegi?
Dzięki za odpowiedzi
Robert

Po zmianie ustawień na PD3 ja bym wrócił do wykorzystania biblioteki Mirka MK2.
Jeśli nie, to nie wnikając zbytnio w twoich ustawieniach przyjrzałbym się czy poprawne jest UART_CONTROL (coś mi się zdawało że z dwóch UARTÓW wlatywało do jednego koszyka). No i do testów nadawania ASCII na próbę przed UDR1 = 0x38 ustawiłbym PD7 na 1.
Wydaje się, że warto przejść na kwarc 18.452 MHz.

Okey, mam coś działającego. Wiem wiem - nie powinienem robić programu z wykorzystaniem delay-ów, ale jakoś nie potrafię tego zrobić na przerwaniach, dlatego jest jak jest. Teraz pozostało to wrzucić na rejestry modbusowe. Co do zmiany kwarca - myślałem nad tym, ale nie potrafię znaleźć takowego - już złożyłem zamówienie i czekam na dostawę.
Uruchomiłem dodatkowo bibliotekę pana Mirka, wyłączyłem obsługę UART0 i działa ona jedynie na UART1. Obecnie zapytania po ASCII wychodzą tak jak chciałem.
Pozdrawiam, Robert.

Szukając informacji w internecie znalazłem jeszcze takie coś, może ktoś coś wyłuska...
Pozdrawiam, Robert

Podjąłem jeszcze jedną próbę ogarnięcia tego, udało mi się całkowicie usunąć delaye, opierając się tylko na przerwaniach. W załączniku wrzucam kod. Mam jednak problem z jednoczesnym odpytaniem 81D i 81L, może to być związane z tym, że w przerwaniu może być tylko jedno polecenie realizowane? Czy tutaj musiałbym wykorzystać Timer 1? Drugi problem to odczyt wartości większej niż uint16_t. Wychodzi na to, że biblioteka więcej nie przepuści jak właśnie 65 535, chyba że się mylę, w takim razie prosiłbym o wskazówkę czy da się to gdzieś poprawić. Jak widać z kodu pozamieniałem wszystkie uint16_t na uint32_t, w nadziei, że to coś pomoże, ale niestety nie działa to tak, jak bym chciał....

Pozdrawiam, Robert

Jak często wg dokumentacji można odpytywać wskaźniki przepływu (liczniki)?
W tej chwili chyba masz ustawione wysyłanie zapytań 44 razy na sekundę.
Poza tym w pętli while (1) nie masz żadnego warunku ograniczającą ilość wykonywanych działań np. na long vOut.
Po co tysiące razy na sekundę obliczać np. long vOut ?

1) Niby nie ma ograniczenia, jednakże zauważyłem, że przy odczycie co kilka milisekund wskaźnik się przywiesza. Widzę, że w moim przypadku zapytanie leci co kilka sekund, czyli tragedii nie ma.
2) Niczego takiego nie zauważyłem.
3) Czy ma to wpływ na działanie całości? Jak dla mnie bez różnicy, skoro działa - tym bardziej, że nie będę co sekundę odpytywał, tylko raz-dwa razy na minutę
4) Przyczepię się do czegoś: w wiadomościach prywatnych, które wymieniliśmy (w dniu 30 sty 2021, o 21:14) padło stwierdzenie "Poza tym niewiele się dzieje w pętli while (a powinno)" - to co? Jednak mniej ma się dziać?

OK. zagalopowałem się.
Dzięki count==255 masz wykonywanie instrukcji w przerwaniu co około 4-5 sekund (256/44).
Może lepiej roboczo zrobić:
if (count==50) ... ;//instrukcje dla 81D

if (count==100) ...; //instrukcje dla 81L

wówczas przykładowo wysyłasz co ok. 1 s kolejne komendy do wskaźników i czekasz na przepełnienie licznika count.
Jak już masz count jako volatile to może przy obecnej twojej koncepcji warto wykorzystać count jako flagę i zastosować w pętli głównej while (1)
do wykonania działań np. na vout i vout1 gdy nastąpi przepełnienie licznika count czyli np.
if (!count){
...
vout ..;
vout1..;
...
}

Docelowo jednak chyba lepiej kierować się radami Mirka z Bluebooka i jego poradnikami na youtube.
Jeśli chcesz wykonywać zapytanie co kilka minut to może warto podejrzeć na forum kody np. nakręcany minutnik.
Warto też przejrzeć kody z książek Mirka z timerami (wystarczy wpisać szukanie w plikach *.c ciągu znaków "Timer1" czy też "OCR".

Co do zmiennych long, long long czy float to może warto też zobaczyć czy nie trzeba coś poustawiać w Eclipse.
http://mirekk36.blogspot.com/2013/04/ec ... float.html

PS. a przy okazji ile ten program zajmuje obecnie flash i RAM?