Analizuję i pojąć nie mogę

Mirku, opisałeś w rozdziale 5.8.2 bufor cykliczny. Idea działania jest zrozumiała, ale nie rozumiem kodu dołączonego, mimo Twoich objaśnień.


Może po kolei. Opiszę to jak taki skończony idiota to chwyta, może wyłapiesz dziury w tym całym "rozumowaniu"

Wszystko działa tak, że mamy zdefiniowane przerwania.
Jeżeli coś się połączy z moim uartem w Atmedze i wyśle jakieś dane to one trafiają do rejestru UDR.
Ten natychmiast zgłasza radośnie że dostał dane. Następuje przerwanie.

W funkcji obsługi przerwania zapisujemy to co się pojawiło w UDR do naszego bufora (przy okazji zwiększając mu "adres głowy")

teraz, wysyłając ciągle po bajcie danych, wszystko trafia do tego bufora, aż on się zapcha.
Jak jest pełny to tracimy nowe dane, bo się do bufora już nie dopisują.



Teraz zdefiniowałeś funkcję :
-której zadaniem jest pobierać bajt danych z bufora cyklicznego.

ale który bajt? bo mamy ich aż 32 w zdefiniowanym buforze.
jeśli wywołamy funkcję tak jak to robisz w przykładzie projektu wielozadaniowego:



to funkcja zwraca (w przypadku projektu wielozadaniowego) kod rc5 z pilota, który się właśnie pojawił, czy który jest ostatni w buforze RX_Buf?

Jeślibym chciał odczytać zawartość całego bufora RX_Buf, to muszę zmodyfikować kod na postać:
pętli w rodzaju:

Żeby zbędnie nie odczytywać niepełnego bufora to w pkt (8) z opisu, czyli w miejscu w funkcji obsługi przerwania, w którym umieściłeś komentarze o tym, żeby sobie zrobić obsługę przepełnienia bufora przydałoby się umieścić coś co by generowało przerwanie i zajmowało się poza moją wiedzą np. przesłaniem bufora danych po uarcie do komputera.(Czyli np Twoja funkcja uart_putc(char);?) Ale to wtedy mamy przerwanie w przerwaniu, to chyba nie jest najszczęśliwsza droga? Da radę tak, czy błądzę?

Pozdrawiam.

No troszkę sporo ale postarałem się całość przeczytać ze zrozumieniem i chyba trafiłem na miejsce w twoim wywodzie, gdzie lekko się potknąłeś a to spowodowało już dalej niestety reakcję lawinową niezrozumienia - o ile dobrze to wszystko zrozumiałem. Ale po kolei:

1. do pytania:



wszystko idzie dobrze ale tu być może lekkie potknięcie bo bufor można zdefiniować sobie dowolny tzn o dowolnej wielkości nie koniecznie 32 bajty a co ważniejsze - mowa o DWÓCH buforach panie kolego NADAWCZY I ODBIORCZY - więc tak w ogóle mowa o dwóch wężach o dwóch głowach i o dwóch ogonach a co ważne o dwóch różnych przerwaniach .... no i teraz się przewracamy na plecy do góry nogami w dalszych zeznaniach - już dalej nic się nie trzyma kupy jak to się mówi.

2. Bo pomieszałeś totalnie odbieranie z nadawaniem. Co ma w tym projekcie wielozadaniowym fragment kodu z udziałem funkcji input = uart_getc(); z nadawaniem tego co odebrał pilot ???? Rozumiesz ? tu już pomyliłeś wszystko sobie i pomieszałeś

linijka input = uart_getc();

służy tylko i wyłącznie do odbierania danych z terminala w postaci prostych komend czyli pojedynczych znaków ASCII '1', '2' oraz '3', które można kliknąć sobie w terminalu i one spowodują jakąś tam niezależną reakcję jak zapalenie diody LED, zgaszenie jej albo zmianę stanu na przeciwny. UWAGA !!!!!!!!!!!!! te dane wpadają do bufora odbiorczego - to co przychodzi z terminala - i nie ma to NIC wspólnego z buforem nadawczym, który wykorzystany będzie dalej na potrzeby przesłania do terminala kodów z pilota..... rozumiesz ? A wszystko działa niezależnie.

3. napisałeś niestety coś takiego ciut wcześniej:



a z jakiej paki coś ma się zapychać ???? eeeej no panie kochanieńki toż policz sobie ile milionów razy na sekundę wywoływana jest linia:

input = uart_getc();

?????? nie zdążyłbyś pan tak szybko pisać w terminalu żeby zapchać nawet ten biedny 32 bajtowy bufor - tak szybko byłby rozładowywany tą linią - i to musisz zrozumieć - że ty jako programista musisz zawsze zadbać żeby w miarę często zaglądać do tego bufora, a jak czasem ci się coś przytrafi w programie że jakiś inny proces troszkę dłużej zajmie i wpadnie kilka znaków to po chwili gdy proces się skończy to i tak zaraz zostanie znowu bufor błyskawicznie zostanie odczytany. Poza tym o jakim ty ZAPCHANIU piszesz ????????? UWAGA! przecież sama nazwa bufor cykliczny mówi o tym że bufor jest cykliczny więc nie może się zapchać - działa cały czas tylko że co najwyżej dane się nadpiszą ale będzie działał i nic się nie zawiesi - najwyżej stracisz dane jeśli zbyt dużo czasu będą zajmowały inne procesy w pętli głównej. I to będzie tylko twoja wina - dlatego wciąż mowa o pisaniu funkcji nieblokujących - rozumiesz ?

Tylko, że ja pokazałem w książce - w tej książce na razie podstawy - jak sobie zorganizować takie dwa bufory i odbiór oraz nadawanie danych na przerwaniach oraz zapis i odczyt do i z tych buforów.... bez żadnych procedur np sprawdzania błędów gdy nastąpi przepełnienie bufora tzn głowa zrówna się z ogonem - tzn w przypadku nadawczego po prostu będzie oczekiwanie aż się wyśle ale w przypadku odbiorczego dane się nadpiszą a programista nie zostanie powiadomiony - i wskazałem zdaje się miejsce w książce gdzie należałoby o to dalej już samemu zadbać

ok - oddziel więc w swojej głowie to co wyżej i to co dotyczy bufora odbiorczego czyli tego co odbieramy do procka z terminala

od bufora nadawczego - który działa znowu niezależnie i na innym przerwaniu. Tym razem funkcja putc() nie dość że zapisuje pierwszy znak do bufora nadawczego to jeszcze inicjalizuje odpowiednie przerwanie UDRE ... no tu musisz to sobie dokładnie przeanalizować jak to działa

natomiast w przypadku uart_getc() ..... funkcja pobiera jeden znak bufora i zmienia wskaźniki panie kochany głowy i ogona tego bufora - zatem jeśli działa na pełnych obrotach jak tu w pętli głównej - to musiałbyś zostać MATRIXEM żeby tak szybko znaki wpisywać żeby nie zdążyły się odczytać za pomocą tej funkcji. Jeśli nie jesteś matrixem - a podejrzewam że nie jesteś - ja też nie - to jak paluch klepnie jakiś znak - to on od razu jest zeżarty przez uart_getc() i koniec - nie ma po nim śladu w buforze

i tego czego nie ma w tej książce a będzie ale nie w drugiej części niestety tylko w jeszcze następnej to tego co dalej z analizą i parsowaniem nadlatujących stringów panie. Bo tu nie chodzi o to żeby odczytywać jakiś tam cały bufor, tylko żeby grzecznie biblioteki poinformowały programistę - że puk puk - panie programisto, przyleciał jakiś łańcuch tekstowy znaków ASCII zakończony znakiem ENTER - czy zechce go Pan łaskawie odebrać ? czy mam poczekać w tym obiegu pętli.... ok kazałeś poczekać więc w kolejnym obiegu funkcje biblioteczne znowu się przypomną - halo halo panie programisto - chcielibyśmy poinformować że już czekają na pana trzy łańcuchy tekstowe i teraz jeśli ich pan nie odbierze to nie odpowiadam za to, że jeśli nadleci następny to starci pan ten pierwszy nie odczytany .....

no i nie masz wyjścia - natychmiast w TRY MIGA - odczytujesz i analizujesz wszystkie trzy łańcuchy tekstowe - parsujesz dane jakie przyleciały a mogą być przeróżne i liczby, i zmiennoprzecinkowe i teksty i co zechcesz .... po czym gdy widzisz, że już bufor pusty to znowu oddajesz sterowanie do pętli głównej

ALE UWAGA!!!! - biblioteki trzeba tak rozszerzyć żeby broń cię panie BOŻE - żeby pan programista nawet nie wiedział że tam gdzieś w tle jakieś bufory cykliczne działają, że jakieś głowy czy ogony chodzą - pomyśl sobie jak to jest przy RC5 w tej chwili hmmmm????

sprawdzasz cyklicznie czy jest flaga od bibliotek która mówi właśnie : puk puk panie programisto właśnie mamy dla pana nowy kod i adres z pilota który został odebrany - zechce go pan przeanalizować i wykonać stosowne rozkazy ?

I co - czy coś cię interesuje jak to tam w brzuchu bibliotek jest dekodowane ? NIE - i tak samo musi być z obsługą RS232 tylko że hmmm no może nie tak samo - bo w drugiej książce będzie jeszcze większy hardcore przesadzam dla programisty to będzie po prostu miodzio - nie będzie nawet żadnej flagi panie do sprawdzania - nie będzie trzeba jej zerować - nie będzie w końcu żadnych jakichś durnych IF'ów w pętli głównej - za to będą zdarzenia a przykładowy kod wielozadaniowy w pętli głównej uprości się nie do poznania np do takiej postaci:



fajnie będzie co ??? oczywiście to nie wszystko z punktu widzenia programisty będzie jeszcze lepiej - no ale o tym to w drugiej książce i mam nadzieję, że rozumiesz teraz dlaczego nie zabrałem się za tłumaczenie wszystkiego naraz.


OK - wiem że i tu mogłem jeszcze trochę zamotać - więc jak coś to się nie poddawaj i pytaj dalej

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

Ale się rozpisałeś..


oczywiście, piszesz nawet w książce tylko, żeby to były okrągłe liczby (w sensie 2^n), użyłem liczby 32 bo tak było zdefiniowane w przykładzie i już tak poszło.
Natomiast faktycznie chyba pomieszałem te oba bufory ze sobą i wyszedł mi niesmaczny koktajl

Przepraszam, jakoś tak mnie poniosło, jak pisałem o zapchaniu bufora, oczywiście jest cykliczny, czyli się zapętla, czyli nie zapycha, a w najgorszym razie nowe dane nadpisują stare.



Czyli w sumie w całej funkcji obsługi buforu funkcja uart_getc() jest zbędna, bo tak na prawdę funkcja obsługi przerwania sama sobie wszystko porządkuje, organizuje i upycha przychodzące dane do bufora i dopóki nic nie chcemy od bufora to jej nie potrzebujemy. ?
Najwyżej w tej formie w jakiej jest nowe dane zapiszą nam się na starych?

ale dalej piszesz że ta funkcja odświeża, teraz zaglądam do jej definicji i wygląda to tak, że funkcja ta "zdejmuje" ostatnią zapisaną wartość w buforze

no i właśnie tu jest chyba sedno mojego problemu.


no ok, matrixem nie jestem, pisać z prędkością chociażby dźwięku też nie potrafię

ale załóżmy że moja pętla ma opóźnienie. załóżmy że wystarczająco długie, żeby dane ściekające do bufora powodowały jego przyrost. Zresztą po to on jest... no i teraz załóżmy (startowy adres ogona =0, adres głowy 32) że mamy go wypchanego do 24 bajta. Działamy funkcją input=uart_getc();
i co otrzymujemy w wyniku?
input przyjmuje wartość zapisaną w 24tym bajcie naszego bufora? i zmniejsza bufor do 23.

teraz zmniejszamy opóźnienie w naszej pętli głównej i po kolejnym wywołaniu
input = uart_getc();
nasz input ma wartość 23ciego bajtu, a bufor mniejszy do 22... itd, aż do 0.

zmierzam do tego, że chciałbym dane gromadzące się w buforze wysyłać dalej. Nawet nie bardzo mnie interesuje ich stan. Ot w momencie osiągnięcia maxa całość w formie paczki miałaby zostać przesłana uartem do kompa.Stąd moje pytanie o odwołanie się do bufora, a konkretnie do chwili tuż przed jego przepełnienieniem.



To będą jeszcze 2 części? Super. Wiadomo coś bliżej o planach wydawniczych?
I ciekawe kiedy będzie ekranizacja trylogii... a potem Noc w Kinie... 3 części Kardasia




Fajnie! już się nie mogę doczekać!

Hmmm chyba coś spartoliłem, bo mój bufor nie chce być cykliczny..

w sensie, wszystko działa dobrze do momentu
(w funkcji obsługi przerwania)
if (tmp_head == UART_RxTail)
{
//tutaj można wpisać obsługę błędu nadpisywania....
}
else
{
}

No i otóż właśnie, gdy się nic nie wpiszę w obsługę tego błędu, to bufor się już nie zapętla. nie wiem czemu.

do całego Twojego przykładu z książki dołożyłem tylko funkcję:
UART_puts(); jak poniżej:




no i po osiągnięciu /przekazaniu 32 bajtów do bufora, nie następuje jego zapętlenie, tylko uparcie wyświetla napis "Pełny"

nie wiem czemu przy kolejnym przerwaniu nie następuje zwiększenie/przekręcenie
wartości tmp_head.

Do porządku przywraca go dopisanie w tym if'ie od obsługi błędu zapętlenia wartości:
UART_RxHead++;

ale wydaje mi się, ze to nie powinno być potrzebe... do działania

A no to dobrze myślisz o tym warunku IF .... tylko nie mam pojęcia o co chodzi z tym przekręcaniem czy zapychaniem bufora - czym ci się zapycha ? - przecież pisałeś o przykładzie z DVD - a tam nie następuje żadne zapychanie - więc o co chodzi ? bo teraz to nie rozumiem

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

późno było, mogłem już nie jasno pisać.

chodzi mi o to, że jeśli nie pobieramy w pętli głównej nic z bufora.czyli zostawiamy samej obsłudze przerwania zajęcie się zapętleniem -tak jak to rozumiem, powinno się odbywać.

Czyli próbując wymusić sytuację, że jestem matrixem i wpisuję do bufora szybciej niż z niego pobiera funkcja w pętli głównej:
input = uart_getc();

(prosto zrealizowane w postaci nieużywania polecenia input = uart_getc(); )

to po osiągnięciu 32 bajtów, bufor trafia do tego if'a w którym mamy sobie poradzić z nadpisywaniem danych. załóżmy że nam to nie przeszkadza, czyli że nowe dane niech trafiają do bufora i nadpisują stare.

no i nie chce się ten mój wąż przekręcić tak żeby zjadał swój ogon tylko wchodzi do tego if'a i nie chce z niego wyskoczyć bez popchnięcia w postaci dodatkowego sztucznego zwiększenia indexu

aaaaa no teraz to rozumiem - tak masz rację - reakcję na taki błąd czy błędy trzeba sobie zgodnie z tym co pisałem już opracować samemu .... tym się w książce dalej nie zajmowałem niestety - bo trzeba byłoby rozpatrywać zbyt wiele przypadków ale też założeń np czy chcemy realizować transmisję tylko po ASCII którą preferuję tak na marginesie czy np chodzi nam o transmisję binarną - wtedy zaczynają się nieco większe schody ..... no a opisać to wszystko dobrze to temat rzeka. Na początku ważne żeby zrozumieć podstawy działania buforów cyklicznych i obsługi tego w przerwaniach - nie prawda ?

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

ok. ale teraz już wszystko jasne, że tak działa i tak ma być. chociaż wydaje mi się, że powinien sam zwiększyć sobie (w obsłudze kolejnego przerwania) "indeks głowy", tak żeby był różny od indeksu ogona i nie spełniał warunku wejścia do tego zabezpieczenia przed nadpisywaniem.,

ale spoko. Chyba wszystko jasne teraz.
Pewnie, rozumiem ze nie da się wszystkiego opisać w ramach jednej książki.., ale juz nie długą będą 3

No i najważniejsze jest, tak jak mówisz, złapanie głównej idei potem to już można kombinować

PS. a powiesz czemu naciskasz na transmisję po ascii? Trzeba przy tym wykonywać wszystkie te rzutowania intów na chary a później odwrotnie

Powiem tak dawno dawno temu gdy sam początkowałem jeszcze na 8051 i gdy pierwszy raz spotkałem się z transmisją RS232 - to tak jak każdy chyba początkujący (chociaż wtedy programowałem tylko w asm - bo C dla procków nie było jeszcze na świcie) ...... transmisja binarna wydawała mi się łatwiejsza z tych powodów o których ty napisałeś ..... no i zaczynałem - a kłopotów było że szok, nie mówiąc że wciąż pod górkę

Tymczasem jak już się pozna sposób - to okazuje się, że nagle czar transmisji binarnej pryska jak bańka mydlana nie mówię, że jej nie stosuję bo czasem po prostu trzeba i już ....

ale jak mam zrobić coś na szybko to MILION razy wolę zrobić to po ASCII ....

czy uda mi się przekonać ciebie oraz wielu wielu innych podobnie myślących czytelników ? ..... zobaczymy ... choć czuję przez skórę że tak i to bardzo

Sam widzę na kursach C po omówieniu takiego sposobu transmisji - jak kursanci otwierają buzię ze zdziwienia, że wcześniej podchodzili do tego jak do ogromnego KUDŁATEGO JEŻA Z KOSMOSU a tymczasem, po bliższym zapoznaniu się okazało się, że to takie przyjemne i jakże pożyteczne zwierzątko.

Potem z kolei muszę ich czasem hamować bo popadają w drugą skrajność i nagle wydaje im się, że transmisja binarna już jest niepotrzebna i nigdy nie będą sobie zawracać nią głowy .... ale wtedy mam zawsze jedno pytanie:

"a nie chciałbyś mieć możliwości komunikacji po RS485 w standardzie np MODBUS RTU ?"

nooooo pewnie że bym chciał - no to teraz dawaj uczyć się tego co niestety rzeczywiście jest wg mnie może nie ciut trudniejsze ile hmmm bardziej kłopotliwe na co dzień

Dlatego żałuję bardzo, że tego rozdziału nie będzie jeszcze w tej książce - ale może warto poczekać?

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

poczekamy... nie wiem tylko czy czerpiesz inspirację z takich dyskusji na forum, czy to dla Ciebie odskocznia, ale może zamiast się rozpraszać... to pisać i wydawać....?

//PS. broń Boże nie mówię Ci co masz robić

Tak po części inspirację do opisów pewnych zagadnień biorę z różnych forów internetowych jak widzę, że mnóstwo osób ma wciąż podobne problemy z tą samą rzeczą - a jakoś nikt nie udzielił pełnej wyczerpującej odpowiedzi, która by pomogła albo sam jej też nie rozumiem. Zresztą jak widać po tym co i jak opisuję niestety pewne tematy (ale to wg mnie) nie nadają się po prostu do wyjaśnienia na forum gdy dotyczą zbyt rozległych zagadnień....

..... druga rzecz, która mnie inspiruje to moje własne problemy jak np z transcieverami Hoperf - bo od wielu miesięcy nie mogłem sobie z nimi poradzić chociaż kilka razy się za nie zabierałem. Aż w końcu postawiłem sobie cel - KONIEC - teraz muszę je opisać do książki, żeby później samemu mieć zawsze pod ręką taki opis jaki sam bym chciał znaleźć w jakiejś tam książce - a go nie ma nigdzie przecież ..... I akurat z tymi ranscieverami o mało co nie poległem i to przez nie m.in mam takie duże opóźnienie z wydaniem tej książki - już dwa razy rzuciłem modułami o podłogę a raz miałem ochotę je podeptać i zapomnieć - i w zamian opisać coś innego - ale się powstrzymałem przed zdeptaniem - chociaż miałem straszliwego nerwa jak to się mówi i z przekrwionymi oczami jak koci wilkołak jeszcze raz zasiadłem - mówiąc sobie "albo ja albo one" ..... no i w końcu po długiej i nierównej walce wygrałem .... Mam też nadzieję, że dzięki temu uda mi się zaprezentować coś - czego nie znajdzie się jak dotąd nie tylko w żadnej książce ale i nigdzie w internecie - tak troszkę chociaż nieskromnie powiem - no bo też nie ukrywam że teraz jestem w nich zakochany - jak mam takie biblioteki do ich obsługi .... dlatego opis w książce akurat ich to będzie wręcz jak bezpośrednia relacja CNN z obszaru wojny - ostrych walk .... i mam nadzieję, że chociaż z tego powodu warto będzie może poczekać na nią jeszcze trochę

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

Ha ha.. oj jakby mi się przydała ta pozycja teraz.. } właśnie podłączyłem RMF01 i 02 do procków

Ok, a z czystej ciekawości, to jak to zrobić normalnie na liczbach?

W całej tej funkcji z datasheeta:


bez względu co się poda na, czy "unsigned char data " czy "uint8_t data"
i tak wysyła wszystko w postaci znaków ASCII. Jedynie funkcja itoa z parametrem 2 pozwala mi przesyłać binarną postać liczb (jedynki i zera) albo liczby w systemie dziesiętnym.. a nie da się bez tego itoa?

gdzie następuje to przekształcenie z liczby na znak ASCII?

No widzisz to jest KULCZ do zrozumienia wszystkiego - a brak tego zrozumienia powoduje ogromny wyłom w myśleniu, wypacza je i człowiek zawsze kombinuje pod górkę, tymczasem żeby pomóc ci zrozumieć jakie to proste (aż się zdziwisz) .... zadam ci pytania 2 a ty spróbuj na nie odpowiedzieć ok?



co zostanie wysłane tym poleceniem do terminala ? znak ASCII jak piszesz 'A' czy liczba ?



Mogę tak w ogóle napisać? a jeśli tak to co zostanie wysłane do terminala znak ASCII czy liczba 65 ?

zastanów się dobrze zanim odpowiesz

A na deser w razie czego dodatkowe pytania:



co tym razem zostanie wysłane do terminala ?

(proszę, żeby nikt inny na razie na to nie odpowiadał dobrze ?)

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

ok, pisze jak myślę, poprawiaj:



przy założeniu transmisji ramki 8 bit to wg mnie powinna się wysłać ramka składająca się właśnie z liczby odpowiadającej znakowi 'A' w kodzie ASCII w jej binarnie zapisanej formie czyli: 01000001


to samo w pozostałych przypadkach, bo wszystkie podane przez Ciebie wartości =65 (w syst dziesiętnym)

Po wgraniu wszystkich kombinacji na procka, w terminalu dla wszystkich wartości dostaję (widzę) znak 'A'

Odpuść sobie myślenie na razie o ramkach, o ilości bitów w ramkach i takich tam pierdókach

Skup się teraz na tym co powiedziałeś i słusznie, że powinna być przesłana liczba odpowiadająca znakowi 'A' w kodzie ASCII.

No więc właśnie - zobacz sam sobie odpowiedziałeś na poprzednie wątpliwości - bo o jakiej ty tu konwersji z ASCII na liczby mówisz albo odwrotnie ?????

Nie tylko, że nie potrzeba żadnej konwersji robić - ale po prostu nie ma czegoś takiego jak konwersja ASCII na liczbę albo liczby na ASCII w tym rozumieniu o jakie pytasz ....

KAŻDY znak ASCII jest tylko i wyłącznie liczbą i niczym innym. Dlatego po co się zastanawiasz jaki typ dać dla znaku ASCII czy unsigned char? czy char? czy uint8_t?

każdy będzie dobry - tyle że automatycznie i domyślnie masz robioną konwersję char do unsigned char przez kompilator - dlatego wpisywanie unsigned char jest po prostu wg mnie bez sensu przez ludzi. Chyba że się wyłączy tę opcję kompilatora, bo można to wtedy trzeba byłoby wpisywać unsigned char.

A w książce pisałem, że dla znaków, dla stringów dajemy zwykle typ char nie dlatego że TAK MUSI BYĆ I KONIEC !!!! .... tylko dlatego, że panie kochany jak ja w twoim kodzie zobaczę np coś takiego:



to od razu się domyślę na tym etapie że w buf będziesz pewnie przechowywał znaki ASCII (ale też przecież normalne liczby) .... i że będzie on gdzieś wykorzystywany np w funkcjach komunikacji UART, LCD i tym podobnych - rozumiesz ?

A niepotrzebnie wmieszałeś w tę konwersję funkcję ITOA - bo wynika z tego że właśnie - nie wiesz co to znaczy konwersja liczb ale na format ASCII..... co to oznacza?

ano że jak np chcesz wysłać liczbę 13 do terminala - i teraz zastanów się jaki chcesz uzyskać efekt w terminalu ? taki że na ekranie pojawią ci się dwa znaki 1 i 3 czy chcesz żeby zadziałało to jak kliknięcie entera czyli przejście do kolejnej linii ????

jeśli ma zadziałać jako znak ENTER czyli CR to po prostu wysyłam:



ale jeśli chcę żeby pojawiła się liczba w postaci dwóch znaków to mogę to np wysłać tak:



widzisz różnicę tego co będzie się działo w terminalu ....

i dlatego żeby nie trzeba było np liczby 233 wysyłać wpisując siedem takich linii można wtedy zastosować konwersję tej liczby do stringa ITOA() albo LTOA()

Pisałeś tak:



Ale o czym ty mówisz ? - co to znaczy wg ciebie że przesyła w postaci znaków ASCII ? dziwisz się, że wysyłając liczbę UDR=65 - widzisz w terminalu znak A ????? No coś ty - to normalne - terminal odebrał liczbę 65 - a jest to panie kochany terminal czyli coś co działa w trybie znakowym - to co miał wg ciebie pokazać ???? 65 ? przecież "65" to są dwa znaki ASCII o różnych kodach a ty wysłałeś tylko liczbę 65 która jest znakiem ASCII A





Pewnie, że można bez itoa() - napisz sobie własną funkcję do konwersji liczb na postać/format ASCII - masz przykład takiej własnej funkcji w rozdziale o ADC gdzie chodzi tam o wyświetlanie wyników




Przede wszystkim musisz rozróżnić LICZBĘ od CYFRY bo tu się kręcisz troszeczkę....

popatrz np napiszę sobie taką pętlę, która wyśle do terminala w postaci znaków ASCII cyfry 0d 0 do 9



spróbuj przeanalizować sobie jak to działa - a to jest właśnie super prosta konwersja liczb a w zasadzie cyfr!!!!! na znaki ASCII bo przecież tą metodą nie wyślę liczby 10 czy 129, czy 1202323223 - dlaczego ? no pomyśl

Ale za to wiedząc to co wyżej się dzieje w tej pętli to spokojnie zrozumiesz jak działa ta funkcja opisana w rozdziale o ADC OK?

Mam nadzieję, że chociaż troszkę rozjaśniłem sytuację - czy nie za bardzo?

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

Ok, po kolei i od początku.

zdaję sobie sprawę że tabela znaków ASCII to taki klucz do szyfru. Nie bardzo sobie wyobrażam w technice cyfrowej, gdzie dysponujemy tylko zerami i jedynkami, przesłać coś co nie jest liczbą. Po to cała ta tabela powstała, żeby przypisać znakowi 'A' jakąś liczbę, padło na '65'.
Program dostaje liczbę zapisaną binarnie w postaci 01000001, porównuje z tabelą ASCII i wyświetla znak A.

z tymi typami, to własnie mi się z jakichś pradawnych czasów nałożyło, jak próbowałem coś w C pisać, że typ char jest tylko typem znakowym.
zresztą tam chyba nawet jak się wrzuciło w char'a wartość liczbową to kompilator zgłaszał warning albo i error.
do przekazywania liczb służyły inty floaty, etc.

no i chodzi mi o to, żeby ominąć tą konwersję na znaki ASCII, jak terminal dostanie liczbę 01000001, to niech mi ją napisze w takiej postaci (binarnej), albo przeliczy to na postać dziesiętną, ale niech nie przelicza na system ASCII.

Oczywiście, można składać liczby i kazać mu wyświetlić:
liczbę '13' w postaci wysłania dwóch liczb odpowiadających cyfrze 1 i później cyfrze 3

ale załóżmy, że chcę wysłać właśnie '13'
czyli 00001101 i w oknie terminala (czy innego programu na kompie zczytującego z portu COM) chcę mieć postać taką właśnie, czyli binarną. Sam sobie później przeliczę to na system 10tny, 16tkowy czy jaki inny zapragnę niech mnie w tym nikt nie wyręcza

no i rozumiem, że problem stoi po stronie oprogramowania zewnętrznego, bo jak wpiszę:
UART_putchar(65); to mój mikroklocek wyśle radośnie po linii TX zakodowaną binarnie liczbę 65. a że terminal to zinterpretuje jako A, to już jest problem terminala...?


Edit:
Ok pójdźmy dalej, bo i char i int8_t ważą 1 bajt, tyle co rejestr nadawczy UDR.
czyli dopóki przesyłam wartości z zakresu 0-254 jest git.

jakbym chciał władować teraz pełnego inta, zajmującego 2 bajty to muszę podzielić go na młodszą i starszą część i najpierw władować jedną, potem drugą a w urządzeniu odbiorczym to sobie skleić z powrotem?
i w tym momencie wysyłanie liczby 2 bajtowej w postaci znaków ASCII zaczyna być zrozumiałe i prostsze, bo się nie bawię w systemy big endian czy small endian tylko "wyłuskuje" z mojej dużej liczby kolejne cyferki i je wysyłam, a potem tylko odtwarzam po stronie odbiorcy i do tego celu mi właśnie funkcja itoa.

No tylko znowu... itoa mi to przelicza na liczbę binarną, a potem to jest transmitowane po kolei... czyli tak, mamy liczbę przykładowo:
300 (dziesiętnie), po działaniu funkcją itoa przy podstawie 2 robi nam się z tego: 100101100, a następnie wszystko jest wysyłane funkcją UART_putchar(), ale po kolei, czyli rozpisując:

UART_putchar('0')
UART_putchar('0')
UART_putchar('1')
UART_putchar('1')
UART_putchar('0')
itd...

a każde wysłanie takiego '0' czy '1' wiąże się z wysłaniem 8 bitów... które terminal odczyta, porówna ze swoją tabelą ASCII i wyświetli to co sobie dopasuje..

PS. tak wiem, ze to idiotyczne lepiej przesłać '300' czyli '3' , '0', '0' ,a potem to sobie przeliczyć na binarny jeśli się uprę że chcę binarnie. ale chodzi mi bardziej o idee i zrozumienie wszystkiego a nie o ergonomiczne działanie. więc nie bij za to




Popraw mnie jak znowu gdzieś błądzę...

Nie zrozum mnie źle za nic nie pobiję - żartuję sobie

ale wracając do twoich pytań - to pomyśl sobie - ty chcesz traktować terminal jak coś super inteligentnego co na dodatek odgadnie twoje myśli chyba no bo jak inaczej ? skoro piszesz czy terminal wyświetli znak A po otrzymaniu liczby 65. No pewnie że wyświetli bo to teminal panie - terminal znakowy i skąd pomysł żeby on ci to wyświetlał np w postaci ŁAŃCUCHA ASCII np tak: 1000001 ???? To już jest C-String a nie żadna reprezentacja binarna liczby rozumiesz ???? To musiałbyś:

1. albo napisać sobie własny program na PC który odebraną liczbę zamieni na postać binarną czyli tak na prawdę mówimy na postać łańcucha tekstowego składającego się z wielu znaków ASCII 0 i 1

2. albo właśnie - albo - dokonać tej konwersji już w mikrokontrolerze za pomocą ITOA() z parametrem radix=2

funkcja ITOA() panie - zamieni twoją liczbę na ŁAŃCUCH TEKSTOWY - czyli C-String a następnie wyślesz bajt po bajcie te zera i jedynki jak oddzielne bajty o kodach znaków ASCII = 0 lub = 1

nie ma że CZARY - MARY - i terminal zrobi to jakie ty będziesz miał pobożne życzenie niestety ale już twój program własny może to zrobić - nie ma problemu

Tylko musisz sobie w głowie rozgraniczyć to wszystko - samo nic się nie zrobi. Zatem przesłanie liczby 233 w postaci łańcucha C-String da nam w terminalu trzy znaki ASCII '233' (zrobisz to za pomocą IDOA()

ale jak wyślesz:



no to wtedy poleci tylko jeden bajt do terminala - tyle że na jego ekranie zobaczysz tylko jeden znak - jakiś ptaszek/krzaczek jak ja to mówię - taki, który odpowiada w ASCII temu kodowi - i to się nazywa transmisja binarna

a jak liczbę 233 zamienisz np funkcją ITOA() na ŁAŃCUCH TEKSTOWY - i wyślesz string na UART (czyli 3 bajty) to otrzymasz prezentację ASCII dziesiętnej formy tej liczby 233 jeśli parametrem radix itoa będzie 10, albo prezentację ASCII binarnej formy tej liczby 11101001 tylko teraz przez UART już poleci 8 znaków ASCII

możesz też użyć radix=16 w ITOA() to wtedy polecą dwa bajty hexadecymalnej formy liczby czyli E9

REASUMUJĄC - nie licz na to, że terminal ma obowiązek coś ci tam przeliczać co ci się żywnie podoba - terminal został stworzony do transmisji i komunikacji znakowej. Dlatego gdy mu puścisz binarne dane to nie dziw się że w oknie terminala pojawi się po prostu sieczka

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

no ok, czyli cały "problem" leży po stronie terminala, który tak został zaprogramowany, aby ze wszystkiego co się da robić znaki literowe

nikt nie mówi o czarach-marach, to nie nauka religii tylko programowania tutaj są same konkrety (z wyjatkiem stanów nieustalonych na pinach mikroklocka )

ok, czaję już chyba wszystko. terminal mi tu namieszał, bo liczyłem na to że uda sie go zmusic do pokazania liczby 233 (dla ścisłości -liczyłem właśnie na nieprzetworzoną postać czyli 11111110), po wysłaniu z mikroklocka
UART_putchar(233); a on po prostu musi mi to zamienić na krzaczek ASCII bo tak ma

dzięki. sorry, że tak dużo czasu to zajęło.

O to właśnie chodzi



Nie ma za co i bardzo dobrze że taka dyskusja się wywiązała tu na forum - bo nie myśl, że tylko ty się na tym zaciąłeś - takie a nawet jeszcze gorsze problemy przez to - ze zrozumieniem tego ma mnóstwo osób na starcie - dlatego fajnie, że będą mogli to poczytać poza wyjaśnieniami w książce.

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

Witam,
Wlasnie znalazlem ta rozmowe, wiec nie bede zakladal nic nowego tylko sie podlacze. W sumie na mysli mam kolejne cwiczenie gdzie tym razem polacze wczesniej przewalkowane bloczki a mianowicie komunikacje rs232 i SPI. Na celu mam zbudowanie prostego programu na PC, w ktorym wybieram dane diody, ustalam ich jasnosc a nastepnie po nacisnieciu klawisza 'Start' uruchamiam je.

Ponizej wstawiam graficzna interpretacje


A teraz powiem gdzie zaczynaja sie schody i moje watpliwosci. Do wyslania mam 252 bajty opisujace wartosc PWM sterujacy wybrane PINy sterownikow. W blue book-u znalazlem informacje ze bufer musi byc kolejna potega 2. Oczywiscie to zrozumiale, ale chcialbym sie dowiedziec czemy w naszym przypadku wartosc ta nie moze byc wieksza od 256 ?
Skoro do wyslania mam 252 bajty, a po zamianie na hex wychodza mi 504 bajty plus znak CR jak podejsc do tego problemu ?

Nie mam zadnego doswiadczenia dlatego tez przepraszam za uplyw mojej fantazji i dziwne pomysly, ale chcialbym was prosic o jakies podpowiedzi i najciekawsze rozwiazanie, ktore powinno sie sprawdzic. Wiem, ze pomyslow jest tyle co osob podchodzacych do tego problemu, ale ponizej wypisze to co mi przyszlo do glowy.

Zastanawiam sie nad najlatwiejszym i dosc optymalnym rozwiazaniem dla wyslania ''paczki'' i uzyskania tablicy [252 elementowej z decymalnymi wartosciami].

Biorac pod uwage, ze wyslane beda nie tylko dane odnosnie wartosci PWM, ale tez polecenie START, STOP, oraz np. czas po ktorym diody maja zostac zgaszone i itd. myslalem nad zliczaniem odebranych znakow CR i po odebraniu wielokrotnosci 2 zwiekszac licznik a tym samym Index tabeli, ktora po zapelnieniu 252 bajtow zostanie wyslana po wyslaniu komendy Start. Oczywiscie przed kazda wartoscia PWM bedzie komenda np. 'PWM='. Problem jaki tu widze to dodatkowe bajty dla kazdej wartosci PWM ( np. PWM=' hex (0-255) ') a do wyslania mam ich 252, wiec dodatkowo 252* 4 bajty do wyslania.

Moze zamiast myslec o wysyalaniu kazdej wartosci PWM pojedynczo lepszym rozwiazaniem bedzie polaczenie 252 stanow PWM w jeden string, gdzie kazde 2 bajty oddzielone beda np. przecikiem ',':


W tym wypadku komenda 'PWM=' i sklejony string dla wszystkich 252 wartosci PWM np.-> 'AE,FE,D9,EA.....' da nam dodatkowe 4 bajty dla komendy i 252 dodatkowe bajty dla przecinka i koncowego CR, co w porownaniu do wczesniejszego przykladu oszczedzi mi sporo bajtow i oszczedzi problemow przy kodowaniu. Nastepnie wydzielenie pojedynczych 2 bajtowych tokenow i ulokowaniu ich do odpowiednich indexow w tabeli czekajacej na wysylke do sterownika. No tak, ale przy takim podejsciu powinienem miec bufer nie mniejszy niz 4+504+252, wiec (2^10 = 1024) ?
Czy ide w dobrym kierunku a moze juz dawno zabladzilem ?

Z gory dzieki za wszelkie podpowiedzi !

panie, powiedz mi po co ty chcesz wysyłać 255 bajtów z kolejnymi stanami PWM ... co to ma być ? jak to ma działać .... ?

co ci da przesłanie 255 bajtów od 0 do 255 ?

kompletnie nie rozumiem ? ... czy nie lepiej wysłać stan PWM jako nawet zwykłą liczbę ASCII np 128, i wtedy masz połowę PWM ?

chcesz minimum to wysyłasz np 5, chcesz maksimum to wysyłasz 250 .... a procek te same liczby odebrane po RS232 przesyła natychmiast po SPI do innego układu/procka ?

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

widze ze znowu namotalem Juz szybko tłumacze jak ja rozumiem swój projekcik i bardzo proszę o naprowadzenie na poprawny tok myślenia.

Spory czas temu bawiłem się scalakami dostępnymi na atnel sklep a dokładnie driverami ledów. Topic poniżej:
http://forum.atnel.pl/post72380.html?hilit=ws2803#p72380

Z tego co rozumiem to nie moge wysyłać od razu po SPI odebranych bajtów do scalaka, a mam ich dokładnie 14 . A planem jest uzyskanie matrycy LED-ow do wyswietlania np. napisow.

Zgodnie ze schematem, w celu wysterowania np. 1 scalaka -> jego 18 pinów , musze przeslac po kolei 18 bajtow (144 bitow).
http://www.noodlehed.com/ebay/pics/ws2803data.gif
Analogicznie, jeśli połączyłem kaskadowo więcej driver-ów to do wysterowania wszystkich naraz potrzebuję wysłać większą paczkę danych ze wszystkimi wartości PWM, nawet dla nieaktywnych diod.

Dodatkowo planuję np. załadować kilka wzorów do mojego ledowego ekraniku np. litery: "A","T","N","E',"L" i wyswietlic je w sekwencji np. co 2 sekundy. Do tego chciałbym, aby wyświetlanie rozpoczęło się po wciśnięciu klawisza START, a zatrzmało się po naciśnięciu STOP.

Po wcześniejszych zmaganiach udało mi się wysterować scalak w następujący sposób:


Czyki z palca ustawiałem wartości w bufferze a następnie wysyłałem po kolei bajty poprzez funckję SendSPI.

Tym razem rzucając się na głęboką w moim przypadku wodę postanowiłem stworzyć na PC program, ktory z łatwościa generuje mi wzór (ta część juz zrobiona), ustawić jego poziom jasności, następnie załadować go do bufera i po wciśnięciu START wysłać do kontrolera, który wysteruje mi 252 wyjścia, a dokładniej wpierw załąduje wzór do kontrolera a zacznie sekwencję po wciśnięciu START.



Mam nadzieję, że w jakiś sposób wytłumaczyłem co mam na myśli i wyjaśniłem jak chcę podejść do tego projektu
Z góry dzięki za pomoc !

a no teraz to jaśniej jak dla mnie

tyle że podpowiem ci jedną rzecz ....

jak ładujesz przez RS232 do procka dane to ŁADUJ TO PAN do pamięci RAM najpierw - a nie przesyłaj tego od razu do scalaków WS....

z drugiej strony tu rozumiem że jest więcej danych do przesłania i wtedy warto rozważyć już transmisję BINARNĄ panie kochany a nie transmisję ASCII ... więc caaaałkiem inne podejście ... bo to może rzeczywiście przyśpieszyć operacje

to co robisz to się nazywa (tak można to określić) sterownik wyświetlacza RGB - nawiasem mówiąc fajny cel

_________________
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 miłe słowa, zabieram sie do tego jak przysłowiowy pies do jeża, ale postaram się to jakoś ruszyć i potem pokazać efekt końcowy



Tak właśnię planuję, jedynym problemem teraz jest fakt, iż tych danych w moim przypadku jest znacznie, więcej. Jak bawiłem się w zapalanie kilkunastu LED-ów poprzez komendy po UART-cie przekształcając kody z Green Booka to wszystko obyło ładnie cacy. Teraz "niestety" trzeba użyć już więcej własnej inicjatywy no i zaczynają się schody



Z tego co wyczytałem to szykuje się Pan na omówienie tego zagadnienia w kolejnej, trzeciej biblii , zapewne nudzą już Pana pytania o planowaną datę wydania ?

Reasumując, chciałbym wpierw zrobić to na ASCII, a jak już się uda to troszkę przysiąść i postaraj się coś wyłuskać dla transmisji binarnej, bo to już znacznie trudniejsze i chyba mniej opisane zagadnienie ?

Jeśli chodzi o binarna transmisję to zapewne rozdział o transmisji RC5 w Green Booku powinien mi w tym pomóc ?


O tak jeszcze w celu przypomnienia:


Nie próbowałem jeszcze, ale czy nie mogę tu ustawić większego bufora ? W sumie program ma byc prosty bez dodatkowych wyświetlaczy, czy innych zewnętrznych urządzeń, czy jeśli maksymalna wartość to 256 to nie wystarczyłoby to na moje potrzeby gdzie planuje wysłać stringa z przecinkami w celu wyłuskania 0-255 i ulokowaniu w odpowiednim miejscu w buforze ?


Coś czuję, że daleka droga przede mną

może być większy niż 256 hehehe no przecież to ograniczenie wynika z jednej strony TYLKO i wyłącznie z licznika jednobajtowego .... jak chcesz zmieścić w jednym bajcie więcej ?

więc musiałbyś przerobić sobie ten licznik na zmienną 16-bitową ale .... oj ale to pociągnie za sobą wiele konsekwencji, nie tylko proste przeróbki kodu ale jeszcze konieczność dodawania atomowego podejścia przy zmianach pozycji w buforze no i ....

no i nie wiem czy jest sens, skoro można spokojnie sobie poradzić z małym buforem a przesyłać większe dane kawałkami - co za problem ?

jak masz np 860 bajtów do przesłania to możesz je nawet przesłać przy buforze 32 bajty !! albo i 16 bajtów a nawet 8 bajtów itp itd

tyle że na większą ilość paczek będzie trzeba podzielić to przesłanie 860 bajtów - ale co za problem ?

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

Jak zwykle podpowiedz ekspresowa dzięki za znalezienie chwilki...

W sumie chciałem zapytać się o to wcześniej. W tym wypadku przykładowo mając do wysłania 255 bajty i używając bufora 64 bajtowego podzielę np. w programie na PC cały string na 5 paczek, gdzie ze znakiem końcowym CR wysyłane będzie maksymalnie 64 bajty. Następnie w programie na podstawie green booka będzie rozpoznanie komendy, czy to nadlatująca paczka PWM, bądź klawisz startu czy prędkości zmiany ekranu. Jeśli jest to komenda PWM to następuję wyłuskiwanie kolejnych stanów PWM np. oddzielonych przecinkiem "," gdzie z każdym napotkanym 'separatorem' wzrasta index w tablicy w pamieci kontrolera. Po uzyskaniu wartości indexu 255 licznik sie zeruję a dane są gotowe do wysłania. Czy już nie przekombinowałem ?

A tak dodatkowo widzę, że już kilka osób walczyło z binarną transmisją na naszym forum:
http://forum.atnel.pl/topic2050.html

Niestety po przeleceniu postów, nic mi się nie wyjasniło a jedynie pokazuje mi to że jest to znacznie trudniejsze zagadnienie i wiele osób czeka na Pana pomoc w postaci kolejnej książeczki

Nawiązując ponownie do znaku " , " i sposobu umieszczenia 2 znaków ASCII jako Bajt w jednej komórce tablicy postanowiłem zrobić mały pseudokod w celu upewnienia się czy dobrze to rozumiem.

Dane nadchodzące z PC wyglądają następująco:

(Numer Paczki=1)
,E9,00,00,00,00,00,E9,00,00,00,00,00,00,00,00,00,E9,E9,00,00,00,00,E9,00,00,00,00,00,00,00,00,E9,00,00,00,00,00,00,00,00,00,00
od razu po niej wyslana
(Numer Paczki=2)
,E9,00,00,00,00,00,E9,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,E9,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

Dane to stringi, które są podzielone na kilka ‘paczek’ po około 130 znakow. W tym przykładzie dla kilku pinów ustalam PWM na poziomie 233, gdzie E9= 1110 1001.


Pseudokod:



Czy takie wyłapywanie znaków ' , ' i wsadzenie dwóch znaków ASCII jako jeden bajt się sprawdzi ? A może jest jakiś inny magiczny chwyt ?

Po sprawdzeniu wczesniej podanego pseudo kodu i wyprobowaniu terminala i wysylu i odbior znakow ASCII moge smialo powiedziec ze tego typu domysly nie zadzialaja. A czemu ? Bo jej autor nie mial zielonego pojecia o wartosciach odebranych znakow ASCII ani o zasadzie dzialania funkcji atoi czy uart putin
Moze troszke sie rozpisze, ale w sumie chcialbym znalezc taka odpowiedz oraz graficzna interpretacje, wiec ponizej wstawie kilka linkow do filmikow Mirka i podstawowych stronek, tak aby od zera dotrzec do ponizszych zdjec.

Na samym poczatku podstawa to:
http://www.ascii-code.com/
oraz filmik o terminalu i uart-cie:
http://www.youtube.com/watch?v=qDDCU3udirA#t=2061
http://www.youtube.com/watch?v=JbLHXkFZwsE&list=PLtXXWLsA5QNi_R9uDXpHRpo5hRnig_f23#t=2265

Tyle wystarczy do latwej reprezentacji wynikow na terminalu co znacznie ulatwi zrozumienie pewnych spraw.

W moim przypadku staram sie znalezc szybka i latwa metode konwertowania odebranych znakow ASCII, ktore reprezentuja wartosci w HEX -ie (od 0 do 255) na wartosci binarne badz decymalne.

Na samym poczatku zdjecie przedstawiajace co odbieramy i kilka sposobow wyswietlenia tej samej wartosci. Dodatkowo jak dziala przesuwanie bitowe i dodawanie bitow.




Jak widac, odzyskanie wartosci zapisanej w HEX nie polega na przesuwaniu czy dodawaniu bitow tak jak kombinowalem wczesniej

Nastepnie kilka pomocniczych filmikow:
http://www.youtube.com/watch?v=1tAXqCt5vVQ#t=878
http://www.youtube.com/watch?v=zVjjbQiEXxs#t=645

oraz male wyliczenia:



Teraz juz wiadomo jak mozna odzyskac wartosc zapisana w HEX z ASCII



A wynik wyglada tak:

Wydaje mi sie, ze dzialac to bedzie poprawnie, ale pewien nie jestem czy nie ma innego lepszego sposobu na odzyskanie wartosci z ASCII.

Wiem, ze to blache i podstawowe rzeczy, ale mam nadzieje ze komus sie to przyda a jak nie komus to zapewne po kilku tygodniach wszystko wyleci mi z glowy a te obrazki szybko przywroca mi pamiec