Witam szanownych użytkowników forum,
Po wielu godzinach pracy poddałem się i postanowiłem zasięgnąć pomocy osób bardziej doświadczonych w Delphi ode mnie. Jestem praktycznie początkujący jeżeli chodzi o aplikacje na Windowsa.
Wszystko na PC zrobione jest na podstawie poradników Mirka natomiast po stronie uC zastosowałem komunikację AT z Greenbooka.

Za pomocą aplikacji na PC wysłam prostą komendę do uC, następnie urządzenie przechodzi w stan badania 2 przycisków i zależnie od wciśnięcia wysyłana jest odpowiedź jako string "TRUE" lub "FALSE" z powrotem do aplikacji. Do tej pory wszystko jest ok. Nastepnie string jest parsowany w programie i label obok przycisku zmienia się na TRUE lub FALSE (zdjęcie poniżej).



Niestety działa to tylko raz po nawiązaniu połączenia. Aby jeszcze raz sprawdzić stan przycisków, muszę zamknąć i otworzyć comport. Dane na 100% są wysyłane poprawnie. Potwierdzają to diody na ATB i terminal. Po prostu DataPacket analizuje je tylko za pierwszym razem.



Obsługa komendy AT ze strony ATmegi:


Z góry dziękuję za odpowiedź.

Pozdrawiam,
Michał

_________________
MMT Technologies

Zastanów się i spróbuj sam wyjaśnić sobie i nam - np co to oznacza wg ciebie ?

_________________
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 ]

Dziękuję za szybką odpowiedź.



Chciałem sprawdzić, czy pierwszy element tablicy (czyli pierwsza część stringu do znaku "+") jest równa "ans_tf". Chodziło o prosty sposób analizowania jaki rodzaj odpowiedzi przysłało urządzenie.



Jak rozumiem tab[0] powinien się równać "ans_tf", natomiast tab[1] - "TRUE".
Chociaż z tego co widzę to chyba nie jest najlepszy sposób.

Pozdrawiam,
Michał

_________________
MMT Technologies

Powiedz mi jak pierwszy (JEDEN ELEMENT) tablicy może być równy jakiemuś całemu stringowi hmmm?

_________________
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 ]

Przecież to jest tablica stringów - tab: TArray<String>; Ja tu błędu nie widzę. Ta procedura działa poprawnie jeśli się jej podstawia pod Str stringi takie jakie są wysyłane z ATmegi. W linii 8 buf.Split dzieli wg "+" i w tab[0] jest np. "ans_tf", nie może być inaczej. Pytanie co Ci się wyświetla w Memo2, bo widzę, że masz podgląd zawartości buf? Jeśli już tu jest błąd to znaczy, że DataPacket złego stringa podstawia.

Ach to przepraszam - mi się coś pomieszało .... sorki

_________________
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 ]

Dziękuję Panowie za cenne wskazówki.
Udało mi się dojść do bardzo dziwnej rzeczy.

Oczyściłem główną pętlę while(1) w ATmedze (jest tam teraz tylko event rs232) i teraz sytuacja wygląda tak:
1. Po zmianie podświetlenia LCD (on/off) działa poprawnie (w polu memo aplikacji ładnie widać odpowiedzi AT)
2. TRUE/FALSE już również działa prawidłowo (dowolną ilość razy - w memo również mamy podgląd)
3. Wysyłanie tekstu do LCD działa, ale po wysłaniu czegokolwiek na wyświetlacz blokuje mi się na amen odbiór danych (tzn. wysyłanie z apki chodzi bez zarzutu, ale nie mogę już nic odebrać - memo milczy chociaż dane są odbierane...)

Wrzucam poniżej kod z ATmegi z funkcjami do obsługi wszystkich komend:


Wstawiam filmik z działania aplikacji. W momencie wysyłania do LCD i zmiany tekstu na ATB wszystko działa (oczywiście poza T/F). Tak jak pisałem nie przychodzą powiadomienia.
Jest dobrze dopiero po "resecie" comportu.

https://youtu.be/TlCtnwmxrjc

Pozdrawiam,
Michał

_________________
MMT Technologies

Ale skąd wiesz, że po wysłaniu czegoś na LCD, dane są prawidłowo odbierane? Musiałbyś może podpiąć się bezpośrednio pod ComPort i podglądać to co do niego dochodzi z pominięciem DataPacket. Spróbuj podzielić aplikację na mniejsze części, wykastruj do testów z obsługi grafiki itp., zostaw tylko samą komunikację i wtedy szukaj przyczyny. Posprawdzaj dokładnie ustawienia ComPort'a, może następuje np. przepełnienie bufora. Przede wszystkim musisz się upewnić czy ATmega po odbiorze danych do LCD odpowiada prawidłowo, a jeśli tak to czy to może w aplikacji coś się blokuje po wysłaniu tych danych.

Testowałem wszystkie funkcjonalności manualnie z terminala. Za każdym razem polecenie jest wykonywane prawidłowo i dostaję odpowiedź od ATmegi w puttym. Problem musi leżeć w aplikacji.

Sprawdzę jeszcze wieczorem ustawienia datapacket i comportu. Bo najprawdopodobniej tam musi leżeć problem.

_________________
MMT Technologies

Podepnę si e pod temat, bo zdaje się, że kolega Makowka ma ten sam problem co ja.
Zacznę od kodu:



Problem jest taki: podczas pierwszego wywołania procedury ComDataPacket1Packet zmienna ( globalna ) FlagaCom1 przyjmuje wartość True, a po drugim wywołaniu ( pomimo, iż nadaję str = 'OK' ) zmienna FlagaCom1 przyjmuje już zawsze wartość False. Dlaczego ?

Sprawdzam w Memo1 i str powinna mieć wartość 'OK' czyli FlagaCom1 powinna być równa True.

Procedurę tą chcę wykorzystać w taki sposób, że co 3 sekundy wywołuje zdarzenie Timer1 z zapytaniem "AT", w odpowiedzi dostaje "OK" lub jeśli urządzenie nie odpowiada to nic i dlatego chce aby FlagaCom1 odpowiednio się ustawiała.

--------
Problem rozwiązałem - błąd w kodzie i to banalny, bo nie zerowałem flagi.
...