Drobny projekt na ADuC847 - oprogramowanie C++, RS232

Witam!
Zabralem sie za projekt uC (ADuC847), a jako ze dopiero zaczynam `zabawe` z mikrokontrolerami to cel mojego przedsiewziecia jest wylacznie dydaktyczny.
Zalozenie? Chodzi o uniwersalny uklad wykorzystujacy znajdujace sie na pokladzie uC przetworniki A/D do pomiaru napiecia. Mam w posiadaniu takze akcelerometr, z ktorego rowniez chcialbym skorzystac. uC mialby komunikowac sie z PC przez port szeregowy. Generalnie pytanie moje kieruje do wszystkich, ktorzy maja jakies doswiadczenie (niekoniecznie z ADuC) w programowaniu mikrokotrolerow. A pytanie brzmi: jak powinien wygladac porzadnie zaprojektowany i oprogramowany obiektowo (C++) system realizujacy takie konkretne zadanie? Nie chodzi mi absolutnie o gotowe kody, schematy. Nie chodzi mi tez o aspekt techniczny. Najbardziej zalezy mi na ideowym opisie. Mam na mysli zarowno oprogramowanie samego uC jak i program okienkowy (windows API), ktory umozliwialby wyswietlanie wynikow pomiarow, oraz szeroko rozumiane sterowanie praca mikrokontrolera (zmiane zakresow pomiarowych, wybor kanalu A/D, zmiany predkosci transmisji RS232, itp..). Mam bardzo ogolne pojecie o tym, jak to powinno wygladac, przynajmniej w kwestii transmisji, tzn zalezy mi na zamknieciu tego w 'czarnej skrzynce', czyli relizacje funkcji wysylajacych/odbierajacych dane na zasadzie "podaje ci dane, ty je wysylasz, a jak to juz mnie nie obchodzi.. ". Czy w dobra strone zmierzam? Na takiej samej zasadzie mamy podzielona siec na warstwy..

Nie wiem czy dobrze wszystko sprecyzowalem, ale od czegos trzeba zaczac, a cala reszta moze wyjsc w praniu.. Dodam moze jeszcze, ze znam C++ dosc dobrze.

Bylbym wdzieczny za jakiekolwiek sugestie i propozycje. Bardzo wdzieczny bylbym takze za polecenie jakiejs przydatnej literatury.
Wydaje mi sie, ze wiele z tych informacji przydaloby sie nie jednej osobie.
Z gory dziekuje i pozdrawiam!

Wydaje mi się, że próbujesz wskoczyć od razu na głęboką wodę : oprogramowanie przetworników, transmisja a z drugiej strony aplikacja pod Win do obsługi portu szeregowego. Skoro sam na wstępie napisałeś, że zaczynasz "przygodę" oraz że Twoja znajomość "C" jest "nie dość dobra" czyli słaba to zastanów się bo można się łatwo zniechęcić.
Tutaj jak zwykle polecam zacząć od lekcji nr 1 pt. "zapalanie nieśmiertelnej diody LED"
Ale postęp techniki jest dzięki wytrwałym i upartym.

Nie jest ze mna tak zle, brak mi tylko doswiadczenia. Zalozmy wiec, ze mam wszelka potrzebna do zrealizowania tego projektu wiedze, bo ja osobiscie czuje sie na silach. W elektronice siedze juz od paru lat, tylko `cyfrowka` zajalem sie dopiero jakis czas temu. Poza tym, to glownie o to chodzi, zeby rzucac sie na gleboka wode, bo tylko w ten sposob mozna do czegos dojsc. A jesli chodzi zapalanie LED`ow to ten etap juz dawno mam za soba.. Takze mimo wszystko, czekam na jakies propozycje...

Powiem tak, ostatnio zachciało mi się zbudować w ten sposób system, tak żeby siebie sprawdzić i przy okazji się troszke nauczyć. Miał być to system w postaci czarnej skrzynki do wielu zastosowań. Zaprojektowałem system w postaci urządzenia i biblioiteki API (czytnik kart chipowych na USB, projekt jest na elektrodzie). Czas włożony w zaprojektowanie jakiegoś rozsądnego interfejsu (API) do programów użytkownika (to co zbudowałem nadal mi się nie podoba), był niewspółmiernie większy niż przy napisaniu tego w normalnej postaci (czyli wszystko w jednym programie). Jeśli zamierzasz korzystać tylko Ty z tego urządzenia, a ilość będzie w pojedynczych sztukach, to odradzam sposób projektowania w postaci hermetycznego elementu. Jeśli przewidujesz że będzie więcej urządzeń wykorzystujących ten sam interfejs, ale to będą różne urządzenia, to musisz przewidzieć dodatkowy czas na rozwój swojego API. Czarna skrzynka jest dość wygodna i ideologicznie przyjazna (programowanie obiektowe), ale do prostych i często zmienianych projektów dużo lepiej sprawdza się raz a dobrze napisany program, w którym potem się wprowadza drobne zmiany. Przykładowe problemy na jakie napotkałem to np przechwytywanie błędów (i ich rozróżnianie).

Jeżeli chodzi o transmisje danych to radze poczytać dokumentację techniczną procka na rdzeniu '52 (taki ma aduc847) z np. 89s52.
Najprościej wygląda to tak musisz wybrać rodzaj transmisji (synchroniczna czy asynchroniczna) a później jej szybkość oczywiście w windowsie musisz mieć tak samo, no i oczywiście procedury odczytu na przez procka najlepiej wykonac na przerwaniu...
Spory projekt ale już mi się podoba bardzo chętnie pomogę ale c się dopiero uczę (piszę w asemblerze) chociaż budowę '51 '52 dość dobrze znam i wiem jak to hula:). Niech zgadnę studiujesz we wrocławiu??

Same szczegoly techniczne dotyczace transmisji w sumie znam, chodzi tu oczywiscie o transmisje asynchroniczna. 8051\8052 mam mniej wiecej opanowane. Jestem w stanie zrealizowac poszczegolne 'cegielki' takiego projektu, brakuje mi doswiadczenia w zaplanowaniu wszystkiego jako calosci i w tej kwestii prosze o pomoc.
Nie jest problemem zaprogramowac te kostke, z konkretnie ustawionymi rejestrami, a wiec na sztywno ustawionym zakresem pomiarowym i wybranym kanalem, oraz tak by uC wysylal przez port szeregowy dane jak tylko otrzyma wynik pracy przetwornika A/D. Po drugiej stronie (PC)uruchomiony program odbiera i wyswietla wszystko co z portu szeregowego odbierze. To chyba najprostsze rozwiazanie, ktore mozna powiedziec pozwala na zmierzenie jakiegos napiecia.
Konkretniejszy projekt z uwzglednieniem komunikacji w obie strony, mozliwoscia sterowania pracy uC z poziomu programu wymaga juz przemyslenia i zaplanowania. I tu, jak juz wczesniej wspominalem, nie mam doswiadczenia i pytam jak to wszystko powinno wygladac, od strony programowej oczywiscie. Przed realizacja wiekszego programu kazdy dobry programista 'na kartce' planuje algorytm jego dzialania. Mi wlasnie brakuje czegos takiego jak ten algorytm w odniesieniu do calego projektu.

Cytat:

Niech zgadnę studiujesz we wrocławiu??

Zgadza sie, studiuje we Wroclawiu

Jesli wiesz jak to rozwiązac problem transmisji to skupił bym sie na protokole a potem wokół niego dorobic cała reszte.
Ja to widze tak ze odbierasz np 1 bajt danych który jest rozkazem, drugi to długośc pakietu a reszta to juz dane.
Mozna by taki sposób transmisji zadaptować po oby stronach. Dzięki takiemu podejściu jeśli zmienisz cos w projekcie albo wymyślisz coś co do tej pory nie zrobiłeś dopiszesz część odpowiedzialną za reakcje na odpwiedni rozkaz.
Nie wiem czy dość jasno to opisałem ale ja to tak widze.
Jeśli zrealizaujesz transmisje to potem zostanie Ci jak to nazwałes poukładanie dodatkowych cegiełek.
W ten sposób mozna by zrealizowac zmiane stanów odpowiednich pinów procesora, zmiane ustawień przetwornika AC, zmiane ustawień dotyczących prętkości transmisji itp.
A w drugą strone odczytywać dane z Timerów, napięcie na AC i tak dalej.
Takie podejście do zagadnienie uniezależni Ciebie do reagowania na wszystkie przesyłane dane oraz sam będziesz mógł decydowac do "czarna skrzynka" ma wysyłać.

Wlasnie o to mi chodzi i nad tym teraz pracuje. Dzieki za pierwsze propozycje

Kolega Samuraj jak najbardziej ma racje. Protokół jest tu najważniejszy. Ja chciałbym tylko dodać ze swojego doświadczenia tyle, że jeśli chodzi o RS232 i transmisję asynchroniczną, to warto stracić trochę cennego czasu (jeśli oczywiście nie jest krytyczny) ale informacje po RS wysyłać w sposób znakowy. Oznacza to że dane (1 bajt) są wysyłane w postaci dwóch znaków heksalnych (młodszy i starszy półbajt). To podejście da możliwość wyróżnienia w protokole rozkazów, znaczników itp. Jeśli chcesz mieć niezawodny protokół to musisz mieć komunikację obustronną (potwierdzenia itp). Jednak też z doświadczenia wiem że lepsze są protokoły bazujące na timeout-ach, bo to zabezpiecza Cię przed np. zerwaniem transmisji. To podejście także ułatwi np. "dogadywanie" parametrów transmisji, jeśli będziesz chciał żeby urządzenia komunikowały się na np. najwyższej dostępnej prędkości transmisji.

Cytat:

Jednak też z doświadczenia wiem że lepsze są protokoły bazujące na timeout-ach, bo to zabezpiecza Cię przed np. zerwaniem transmisji. To podejście także ułatwi np. "dogadywanie" parametrów transmisji, jeśli będziesz chciał żeby urządzenia komunikowały się na np. najwyższej dostępnej prędkości transmisji.

Czy moglbys dokladniej opisac taki rodzaj protokolu? Wiem na czym polega zasada dzialania, ale nie mam pomyslu jak to zaimplementowac. Bylbym wdzieczny! Pozdrawiam.

Być może wykonałem zbyt duży skrót myślowy w tym temacie za co przepraszam. Oczywiście bazowanie na timeout-ach oznacza że timeout-y mają wyższy priorytet w ustalaniu poprawnej transmisji.
Co to oznacza:
- nadajnik wysyła daną i włącza timer ustawiony np. na 10ms. oczekuje na potwierdzenie wysłania, jeśli otrzyma to ok. (potwierdzenie może zawierać część danej wysłanej itp.) jeśli nie to decyduje, że dana nie doszła do celu (timeout ma wyższy priorytet) i ponawia transmisje. Po zadanej ilości powtórzeń zapada decyzja zerwania transmisji (koniec nadawania). W tym przypadku można stworzyć automat który co jakiś czas będzie "budził" nadajnik w celu nawiązania transmisji.
- odbiornik po otrzymaniu pakietu danych wysyła potwierdzenie. Jeśli stwierdzi odbiór kolejnego identycznego pakietu przed ustalonym czasem (timeout większy niż timeout nadajnika ale mniejszy niż odstęp pomiędzy pakietami) oznacza to że transmisja jest zerwana tylko w jednym kierunku i trzeba to zasygnalizować.
Oczywiście jest to skrajny przypadek. Czyli zerwanie tylko jednej linii transmisji (odbiornik -> nadajnik). Ale na tej zasadzie można detektować każde uszkodzenie linii transmisyjnych rs232.
Temat ustalania parametrów transmisji jest nieco bardziej skomplikowany. Cała sztuka polega na zsynchronizowaniu transmisji a potem za pomocą timeout-ów można ustalić każdą prędkość transmisji. Nadajnik (master) powinien nadawać na najniższej możliwej transmisji. Odbiornik zawsze powinien być domyślnie ustawiony na prędkość transmisji o dwa/trzy "kroki" wyższą (można przyjąć prędkości standardowe dla rs232 UART-a PC). Nadajnik oczywiście zwiększa prędkość transmisji z zadanym krokiem i timeout-em. Odbiornik po zsynchronizowaniu również zwiększa prędkość transmisji aż do momentu gdy nie odbiera po zadanym czasie (timeout) prawidłowego znaku synchronizacji. Nadajnik jeśli nie odbierze potwierdzenia zmniejsza prędkość, odbiornik robi to samo i następuje synchronizacja na największej możliwej prędkości. Jeśli propagacja w przewodzie dokładnie w tym momencie się zmienia (nie wnikam z jakich powodów) to nadajnik i odbiornik powinien przy pomocy timeout-ow zmniejszać prędkość transmisji aż do czasu zsynchronizowania. Trzeba sobie jednak jasno powiedzieć, że zmiana propagacji jest raczej niemożliwa w tak krótkim czasie (synchronizacja powinna nastąpić w czasie 1-2 sek.) ale to jest tylko zabezpieczenie przed wszelką ewentualnością.
Mam nadzieję że w miarę jasno to przedstawiłem. Być może znowu poczyniłem jakieś duże skróty myślowe, ale w miarę możliwości je wyjaśnię.