Z racji tego, iż to mój pierwszy post na forum, pragnę w pierwszej kolejności wszystkich serdecznie powitać . Przechodząc do meritum sprawy: od dłuższego czasu pracuję nad projektem testera diagnostycznego opartego na scalaku STN1110 - odpowiednik ELM327 se strony software'owej (te same komendy AT, OBD etc.). Układ współpracuje z uC ATMega32, która komunikuje się z STNem poprzez UART. Całość sterowana jest czterema przyciskami microswitch a dane odebrane z pojazdu wyswietlane na wyświetlaczu LCD 4x16. Środowisko programistyczne to Eclipse - język C. W programie wykorzystuję biblioteki zarówno z Bluebooka (LCD, Superdebounce) jak i z greenbooka (UART oraz zmodyfikowane przezemnie funkcje parsujące). Cały program opiera się na wysyłaniu odpowiednich zapytań do STNa, który to komunikuje się z ECU samochodu i zwraca odpowiednie dane, które następnie podlegają parsowaniu i wyswietlaniu na LCD. Problem pojawia się kiedy wysyłam zapytania o więcej niż jedną wartość. Np. chcę wyświetlać na LCD 4 wartości: temp. cieczy chłodzącej, obroty silnika, prędkość pojazdu oraz obciążenie odświeżając każdą wartość cyklicznie (narazie w pętli głównej while). Niżej kod:

Na diodach sygnalizujących komunikację pomiędzy Atmegą a STNem oraz STNem a ECU samochodu widać komunikację pomiędzy poszczególnymi układami. Niestety nie widać żadnej wartości wyświetlanej na LCD. Natomiast jeśli wysyłam każde zapytanie poprzez przyciśnięcie innego przycisku (4 przyciski na 4 wartości) z funkcji superdebounce to wszystko ładnie się wyświetla (oczywiście jednorazowo bez odświeżania wartości). Moje pytanie brzmi, czy problemem w tej sytuacji są linie programu oczekujące na znak gotowości: , które to prowadzą do zatrzymania programu? Jeśli tak to jak można by było obejść owy problem??
Za wszelkie porady serdecznie dziękuję

Może spróbuj dla testu dodać pewne opóźnienia między odczytami...


Być może po odebraniu znaku '>' układ nie jest gotowy na natychmiastowy odbiór danych i potrzebny jest pewien odstęp czasowy. Podane przeze mnie czasy są oczywiście przykładowe i mają na celu jedynie zlokalizowanie przyczyny potencjalnych problemów.

Podstawy debugowania problemow opisywal mirekk w ktoryms poradniku. Podpowiem, poswiec jeden pin megi i podlacz do niego diode (z rezystorem) i zapal sobie ta diode w odpowiednim miejscu. I patrz kiedy ci sie przestanie zapalac. A jak juz masz LCD to w ogole wypas.

I juz dzis komus dawalem porade. Skoro cos chodzace z komunikacja z UART nie dziala jak nalezy, to pierwsza rzecz to podlaczyc do PC i udawac, raz jedna strone raz druga i sprawdzic co sie dzieje.

Może to niewiele wniesie do kodu ale możesz włożyć każdą pętlę while w poprzednią żeby uzyskać zawsze zbieranie informacji w tej samej kolejności

I oczywiście te delaye też są warte sprawdzenia...

A jak wygląda symulacja w terminu?

Panowie problem rozwiązany, żadna opcja z wysyłaniem komend w pętli głównej oraz blokowaniem pętli w oczekiwaniu na znak ">" nie działała. Po prostu program się blokował w chwili oczekiwania i nie obsługiwał poszczególnych funkcji wyświetlających dane na LCD. W końcu postanowiłem zmienić koncepcję. W pętli while znajduje się tylko obsługa zdarzenia UART_RX_STR_EVENT(bufor). Przed pętlą wysyłam jednokrotnie zapytanie o obciążenie uart_puts("010r\r), a następne zapytanie wysyłam dopiero w programie obsługującym zdarzenie od komendy 0104 (odbieram dane na temat obciążenia, wyświetlam je na LCD a pod koniec funkcji wysyłam zapytanie o kolejną wartość(temperaturę) uart_puts("0105/r), i tak robię jeszcze w trzech kolejnych funkcjach a w ostatniej znów pytam o pierwszy parametr (0104). I dopiero takie rozwiązanie daje zadawalające rezultaty.

Tak to jest kiedy na forum przedstawiany jest tylko pewien fragment kodu, a pozostały może oddziaływać na całą resztę.
To świetnie że udało się rozwiązać problem, ale na przyszłość, mimo iż wydaje się to niepotrzebne, warto dodać również te elementy które są również pośrednio powiązane, a bardziej celowo uda się pomóc.

Racja Następnym razem postaram się lepiej przedstawić problem.

Moglbys podpowiedziec jak interpretowales sygnal np. obciazenia ktory wychodzi juz elma do avr. Tzn. wysegregowales dane do przetworzenia, bo elm wysyla to chyba w czwartym bicie.

ups.odkopalem temat z przed roku, ale moze ktos cos pomoze.