[Programowanie] Terminalowa aplikacja serwisowa do robota. Część 1 - Wstęp

[sosnus]

Witam, w tym kursie opiszę jak stworzyć "terminalową aplikację serwisową" do robota. Dzięki tej aplikacji, będziemy mogli na bieżąco widzieć na ekranie komputera wszystko, co chcemy wiedzieć o naszym robocie, czyli na przykład odczyty z czujników, wartości PWM jakie zostały podane na silniki, ewentualnie napięcie akumulatora i inne jak np. informacje z czujnika przeszkód.

Z pomocą tego poradnika, nauczysz się wyświetlać takie informacje w terminalu Putty na ekranie komputera, w ładny i ciekawy sposób.

Na wstępie omówię po kolei, czym będziemy się zajmować w kolejnych częściach kursu. Opiszę także ogólne zasady, na jakich polega ta metoda komunikacji, oraz wady i zalety tego rozwiązania.

SPIS TREŚCI:

1. Wstęp link

Podstawowe informacje,
Co będzie nam potrzebne?

Zalety i wady "terminalowej aplikacji serwisowej".

2.Bluetooth, program Putty, oraz przygotowanie tego programu do działania jako aplikacji serwisowej. link

Omówienie podstawowych ustawień Putty,
Tworzenie profilu z ustawieniami programu Putty,
Ustawienia okna, kodowania, itp.

przygotowanie modułu BTM-222,
Tworzenie skrótu BEZPOŚREDNIO do naszej "Terminalowej apki serwisowej",
BONUS: Program Putty w załączniku

3. Prosty przepis na transmisję UART w języku C link

Omówienie gotowych bibliotek do obsługi UART Kol Antystatycznego, oraz wykorzystanie ich w praktyce,
Pierwsze testy transmisji uC<=>Putty,
Zakamarki ustawień prędkości transmisji UART,
BONUS : Biblioteki Kol. Antystatycznego do obsługi UART,
BONUS2: Gotowy projekt Eclipse z działającą transmisją UART.

4. Kodowanie CP866, komendy VT100 link

Przygotowanie środowiska programistycznego Eclipse do pracy z kodowaniem CP866,
Omówienie i zaincludowanie bibliotek ułatwiających wysyłanie komend VT100,
Bonus : Tabele znaków ASCII + znaki z kodowania CP866, łatwe w użyciu, w formie pdf'a

BONUS2: Gotowe sosnusowe biblioteki ułatwiające używanie komend VT100

5. Podsumowanie, i wykorzystanie zdobytej wiedzy w praktyce. link

BONUS : Arkusz z programu Exel, przyspieszający włąsnoręczne generowanie tego typu "apek terminalowych"

BONUS2: Projekt Eclipse zawierający:

•Prosty program do robota typu Linefollower z obsługą PWM oraz ADC,
•Obsługę UART

•Wysyłanie po UARCIE odczytów z ADC, oraz wartości rejestrów OCR1A oraz OCR1B,
•Wykorzystanie kodowania CP866 oraz komend VT100, by wysyłanie informacje ukazać w przyjemniej dla oka formie.

Spis treści jest dosyć długi i szczegółowy, więc w kolejnych częściach nie będę się już go przytaczał. Jeżeli szukasz tylko fragmentu kursu, ten spis z pewnością Ci pomoże.

Jak działa "terminalowa apka serwisowa"?

Otwieramy program Putty i wyświetlamy dane, jak przy normalnym użytkowaniu terminala.

Dodatkowo, dzięki komendom VT100 możemy np. przenosić kursor w różne części ekranu.

Do tego dodajemy kodowanie CP866, które umożliwia nam rysowane tabelek, oraz dzięki temu kodowaniu, нам надо писать по-русский .

Całe generowanie aplikacji znajduj się po stronie mikrokontrolera, zadaniem komputera jest tylko odbieranie i wyświetlanie danych (oraz ewentualne wysyłanie pojedynczych znaków).

Co będzie nam potrzebne?

•Komputer z zainstalowanym środowiskiem Eclipse przygotowanym do programowania AVR (może być AVR studio lub WinAVR, lecz ja będę pokazywał wszystko na przykładzie Eclipse),
•Program PuTTy (do pobrania w 2 części artykułu),
•Moduł bluetooth współpracujący z AVR, oraz moduł BT do komputera,
•Robot z mikroporcesorem z serii AVR posiadający sprzętowy UART,
•Przejściówka PC«»UART (niezbędna do konfiguracji modułu BT).

Teraz czas na wady i zalety tej metody. Jest to bardzo ważne, bo to uwidoczni Ci, że naprawdę warto spróbować stworzyć aplikację serwisową właśnie w ten sposób

PLUSY:

Nie musisz dodatkowo uczyć się języka C# lub C++, co byłoby konieczne, jeżeli chciałbyś zrobić podobną apkę w MS Visual Studio lub podobnym programie,
Nie musisz instalować żadnych frameworków, dodatkowych środowisk rogramistycznych, itp., wystarczy tylko środowisko Eclipse przystosowane do C dla AVR, oraz program Putty,
Program Putty prawdopodobnie mniej obciąża procesor komputera, niż podobna apka napisana za pomocą MS Visual Studio,
Niewiarygodna przenośność (przenosisz między kompami tylko program Putty, zajmujący poniżej 500kB pamięci dysku twardego, nie musisz na innym kompie instalować od nowa frameworków, itp.). Nic nie stoi na przeszkodzie, aby korzystać z tego rozwiązania także na linuxie, lub dowolnym innym systemie posiadającym możliwość instalacji konsoli portu szeregowego (niezbędna jest tylko obsługa komend VT100 i kodowania CP866 przez terminal).

MINUSY:

Przy obsłudze tego typu "terminalowych aplikacjach" nie da się korzystać z myszki,
Wizualnie taka aplikacja wygląda gorzej niż okienkowa, jaką można by napisać w Visualu,
Rysowanie tych ramek oraz wysyłąnie komend dodatkowo obciąża pamięć flash uC, lecz to od Ciebie zależy, jak bardzo, bo wiele rzeczy można ładnie zoptymalizować, nie pogarszając czytelności kodu. Szacuję, że przy optymalizacji rysowania ramek, zajmą one ok. 1 do 1,5 kB.

Na zakończenie tego przydługiego wstępu, zaprezentuję efekt końcowy, do którego będziemy sukcesywnie dążyć:

[KCPR]

Z niecierpliwością czekam na kolejną część, bo aplikacja wygląda bardzo fajnie

[Deucalion]

•Wykorzystanie kodowania CP866 oraz komend VT100, by wysyłanie informacje ukazać w przyjemniej dla oka formie.

Przecież mamy własną stronę kodową CP790 - Mazovia. W putty występuje jako CP620 (Mazovia)

Czym jest spowodowana promocja ruskiej?

[Naelektryzowany]

•Wykorzystanie kodowania CP866 oraz komend VT100, by wysyłanie informacje ukazać w przyjemniej dla oka formie.

Przecież mamy własną stronę kodową CP790 - Mazovia. W putty występuje jako CP620 (Mazovia)

Czym jest spowodowana promocja ruskiej?

Pozwolę sobie zacytować sosnusa:

Do tego dodajemy kodowanie CP866, które umożliwia nam rysowane tabelek, oraz dzięki temu kodowaniu, нам надо писать по-русский .

Konkretnie drugą część zdania.

[Deucalion]

Pozwolę sobie zacytować sosnusa:

sosnus napisał/a:

Do tego dodajemy kodowanie CP866, które umożliwia nam rysowane tabelek, oraz dzięki temu kodowaniu, нам надо писать по-русский .

Konkretnie drugą część zdania.

Rzeczywiście, bardzo przydatne opcja kosztem polskich ogonków. Lepiej kaleczyć polski bo cyliryca zawsze się przyda.

Już dotarłem do żródła

[sosnus]

Przeglądając ustawienia, znalazłem coś takiego:

(obrazek pochodzi z 2 części kursu, którą piszę właśnie)

Sprawdziłem co to jest, a że sam czasami używam j. Rosyjskiego, pomyślałem, że może i mi się to w przyszłości przyda (aktualnie piszę właśnie z klawiatury z naniesioną Cyrylicą za pomocą naklejek).

[BTL00]

Muszę przyznać, że wygląda to naprawdę super. Niedawno obejrzałem filmik pana Mirka, i zastanowiło mnie czy do terminala można wysłać dane w postaci wykresu bezpośrednio z urządzenia. Osobiście myślałem nad jakimś ASCII Art'em. Próbował ktoś czegoś takiego?

Kiedyś zrobiłem w VB aplikację z wykresem temperatury, ale miała dziwne problemy z synchronizacją i wykresy były trochę krzaczaste (np. 3 dobre odczyty z EEPROM'u - 1 pusty - 1 błędny - 3 dobre).

[Treker (Damian Szymański)]

Muszę przyznać, że wygląda to naprawdę super. Niedawno obejrzałem filmik pana Mirka, i zastanowiło mnie czy do terminala można wysłać dane w postaci wykresu bezpośrednio z urządzenia. Osobiście myślałem nad jakimś ASCII Art'em. Próbował ktoś czegoś takiego?

Łatwiej i lepiej zapisywać dane liczbowe w jakimś pliku. Nawet w formie txt, później można go wczytać np.: do Excela i wyrysować dowolny wykres.

Kiedyś zrobiłem w VB aplikację z wykresem temperatury, ale miała dziwne problemy z synchronizacją i wykresy były trochę krzaczaste (np. 3 dobre odczyty z EEPROM'u - 1 pusty - 1 błędny - 3 dobre).

Nie byłoby tego problemu, gdyby dane przesyłane były w ramkach z jakąś sumą kontrolną. Masz wtedy pewność, że odebrane dane są poprawne. Jeśli ważny jest każdy odczyt możesz przesyłać też numer danej paczki z danymi. Następna byłaby wysyłana dopiero, gdy komputer potwierdzi odebranie poprzedniej.

[sosnus]

Spójrz na kodowanie CP866, na znak kryjący się pod hexadecymalną liczbą: 0xDF

Z jego pomocą (i innych mu podobnych) można by rysować fajne wykresy słupkowe, lecz poziome (wysyłanie pionowych wykresów znacznie by zwiększyło transfer danych przez UART, oraz ilość zajętej pamięci Flash uC, więc raczej nie warto).

W kursie nie przewidziałem omówienia jak rysować wykresy, szkoła się zaczęła, plan napięty, więc nie będzie czasu by to opisać :\

PS. 3 część prawdopodobnie ukaże się w ten weekend

[BTL00]

Dzięki za odpowiedź. O ile z elektroniki jestem laikiem to z programowania nie aż tak bardzo. Tamten problem z VB miałem kilka miesięcy temu i poradziłem z nim sobie w ogóle inną metodą wykluczającą robienie wykresów VB'kiem. Przedstawiam taki krótki schemat mojego rozwiązania:

komputer -> komenda wysłania pliku -> uC -> generowanie pliku .PGM ->wysłanie do pliku komputera -> zapis na dysku (VB) -> wczytanie z poziomu VB

Udało mi się wtedy zrobić ładny monochromatyczny plik o rozdzielczości 240x240 z wykresem. Co prawda posiadał nieregulowaną skalę (1px - 1 st. Celsjusza i 1 pomiar), ale przynajmniej działał. ASCII Art w terminalu dałoby się pewnie zrobić, ale byłoby to dużo bardziej pracochłonne, dlatego odpuściłem.