ATNEL tech-forum https://forum.atnel.pl/ |
|
Wykorzystanie ATmega 164a do konwersji danych https://forum.atnel.pl/topic23421.html |
Strona 1 z 1 |
Autor: | robek29 [ 8 lis 2020, o 21:55 ] |
Tytuł: | Wykorzystanie ATmega 164a do konwersji danych |
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: Cytuj: <ESC>81D<CR> Odpowiedź jest następująca: Cytuj: FP210v20 81 200513215324 197.8 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: Cytuj: <ESC>81L<CR> Odpowiedź: Cytuj: FP210v20 81 68502h3100001309520000130952 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] |
Autor: | 0livaw [ 9 lis 2020, o 00:29 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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 |
Autor: | robek29 [ 9 lis 2020, o 16:02 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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ź |
Autor: | mirekk36 [ 10 lis 2020, o 00:56 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
robek29 napisał(a): 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. 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. |
Autor: | wonsz [ 10 lis 2020, o 06:38 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
robek29 napisał(a): 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. Nie ma tak dobrze, wracaj tu! |
Autor: | mirekk36 [ 15 lis 2020, o 23:55 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
robek29 napisał(a): while(1) { UART_RX_EVENT(); uart_puts( 0, "\e81D\r" ); //wysyłam komendę <ESC>81D<CR> poprzez port uart0 - dotyczy przepływu _delay_ms(1000); uart_get_str( 0, flow1 ); //odbieram odpowiedź ze wskaźnika z portu uart0 strncpy(flow, flow1 + 26, 31); //wywalam niepotrzebny mi początek odpowiedzi uart_puts( 1, flow ); //wysyłam to co zostało poprzez port uart1 send_cr( 1 ); _delay_ms(2000); uart_puts( 0, "\e81L\r" ); //wysyłam komendę <ESC>81L<CR> poprzez port uart0 - dotyczy sumatora _delay_ms(1000); uart_get_str( 0, totaliser1 ); //odbieram odpowiedź ze wskaźnika z portu uart0 strncpy(totaliser, totaliser1 + 31, 40); //wywalam niepotrzebny mi początek odpowiedzi uart_puts( 1, totaliser ); //wysyłam to co zostało poprzez port uart1 send_cr( 1 ); _delay_ms(5000); } 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. |
Autor: | robek29 [ 16 lis 2020, o 16:59 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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 Cytuj: to jest mniej więcej tak jakbyś chciał jechać szybko autem z zaciągniętym na MAXA hamulcem ręcznym 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ł. |
Autor: | tonygryps [ 16 lis 2020, o 19:00 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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. |
Autor: | robek29 [ 2 gru 2020, o 18:01 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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 - Cytuj: o ironio - 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 |
Autor: | robek29 [ 20 gru 2020, o 21:34 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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. język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
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 |
Autor: | JarekK [ 21 gru 2020, o 21:43 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
Tak na początek w AVRmodbus.c zmieniłem na: język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. 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 ). |
Autor: | JarekK [ 21 gru 2020, o 22:59 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
Jest też inny przykład, który powinien ładnie się kompilować pod ATMEGA164P: https://community.atmel.com/projects/mo ... ibrary-avr |
Autor: | robek29 [ 22 gru 2020, o 21:06 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
@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 |
Autor: | JarekK [ 23 gru 2020, o 10:43 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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 |
Autor: | robek29 [ 17 sty 2021, o 16:00 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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ć? |
Autor: | JarekK [ 17 sty 2021, o 19:33 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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) |
Autor: | JarekK [ 20 sty 2021, o 20:07 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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). |
Autor: | robek29 [ 22 sty 2021, o 20:50 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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 |
Autor: | JarekK [ 23 sty 2021, o 11:23 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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. |
Autor: | robek29 [ 24 sty 2021, o 15:05 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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. |
Autor: | robek29 [ 25 sty 2021, o 20:21 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
Szukając informacji w internecie znalazłem jeszcze takie coś, może ktoś coś wyłuska... Pozdrawiam, Robert |
Autor: | robek29 [ 14 lut 2021, o 18:29 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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 |
Autor: | JarekK [ 14 lut 2021, o 22:22 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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 ? |
Autor: | robek29 [ 15 lut 2021, o 22:46 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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ć? |
Autor: | JarekK [ 16 lut 2021, o 09:42 ] |
Tytuł: | Re: Wykorzystanie ATmega 164a do konwersji danych |
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? |
Strona 1 z 1 | Strefa czasowa: UTC + 1 |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |