Witam,

Wiele razy spotykam deklaracje tego typu:

Z czego najbardziej interesuje mnie wartosc po prawej stronie znaku równości. Rozumiem to tak: Zmienna o nazwie p_led_reg to stały wskaźnik to zmiennej volatile o wielkosci uint8_t. Jednak nie potrafię sobie wyobrazić jak działa pozostałą część tzn rzutowanie. Przecież, jeżeli dobrze rozumiem, to wskaźnik ma stała długść prawda? Proszę o wyjanienie bo bardzo mnie ta kwestia meczy

Początek się zgadza - p_led_reg to stały wskaźnik na ulotny uint8. Następnie temu wskaźnikowi przypisywany jest konkretny adres pamięci. Ten adres jest rzutowany na "wskaźnik na uint8_t" a nie na "uint8_t". Tak jak piszesz - wskaźnik ma stały rozmiar. Rzutowanie jest użyte z prostego powodu - bez tego rzutowania kompilator będzie krzyczał:

W generowanym kodzie (asm) omawiane rzutowanie nie powoduje żadnej zmiany.

Przepraszam nie miałem kiedy odpisać (wredny operator i jego BTS-y). Dziękuję za odpowiedzi. Jedna kwestia się wyjaśniła Ideę wskaźników znam i nawet wykorzystuje owe w mniej lub bardziej zgrabny sposób. Zastanawia mnie jednak - nadal - skoro rzutujemy na typ uint8_t to zapisanie typu 8-bitowego danych dla adresu np. 0x00080000 oznacza, że rezerwuję 8-bitów czyli cały rejestr uC ? Chyba właśnie przełamałem barierę umysłową dla tej notacji Poprawcie jeżeli się mylę lub jeżeli napisałem niewyraźnie.

Wybieram opcję numer 2. Nie mam pojęcia co miałeś na myśli

Miałem na myśli, że taką notacją jaką podałem w pierwszym poście mogę np. odwoływać się do rejestru procesora ? lub bardziej operować na nim w sposób bardziej przyjazny dla człowieka.

Jeżeli masz na myśli rejestry peryferiów mikrokontrolera to tak. Zresztą jak "rozwiniesz" AVR'ową definicję jakiegoś rejestru (np. PORTx) to zobaczysz, że mniej więcej tak to jest zrealizowane Tylko zamiast "pełnoprawnego-nazwanego wskaźnika" jest definicja z rzutowaniem adresu. Przykład - PORTD mega88 (kolejność definów odrobinę zmieniona - żeby się wygodniej czytało):


Jakby to trochę zwinąć to wyjdzie:
czyli liczba 0x2b jest rzutowana na wskaźnika na volatile uint8_t, druga gwiazdka odpowiada za dereferencję wskaźnika. Zapis PORTD=x powoduje więc zapis x pod adres 0x2b (adresy wszystkich rejestrów są wypisane w DS procka).

Stosując notacją taką jak Ty w pierwszym poście, zapis PORTD = x będzie wyglądał tak:
powyższe jak najbardziej działa

Z drugiej strony - jeżeli pisząc rejestry procesora miałeś na myśli rejestry r0,r1... -> to się nie da

Chciałbym zadać osobom, które odpisały w temacie jedno pytanie:
Skąd wy macie taką wiedzę nt. mikrokontrolerów i ogólnie języka C ? Ja siedzę w tym trochę i nadal trudno mnie rozumieć pewne kwestie tak jak np:
Jeżeli dobrze rozumiem: PORTD to zwyczajnie adres tak? widzę rzutowanie na typ wskaźnikowy ulotny i potem dereferencję tej zmiennej.
Gdzie można dojść do takich informacji ? jest jakiś manual lub cokolwiek takiego ?

W porównaniu z wiedzą i doświadczeniem kolegi mokrowskiego wypadam dosyć mizernie, ale skoro pytanie było skierowane do wszystkich wypowiadających się w wątku to pozwolę sobie odpowiedzieć Mój przepis na rozwój mikrokontrolerowy, uprzedzam - próbowałem to jakoś uporządkować, ale jakbym się nie starał to wychodzi trochę sieczka... cóż ponoć lepszy rydz niż nic

1. Nic na siłę, bo wszystko co wymuszone idzie jak... Robiąc PCB do jakiegoś swojego projektu mogę całymi tygodniami gapić się na projekt i przesuwać elementy, żeby było "śliczniej". Kilka razy zdarzyło mi się robić płytkę "dla kogoś" - po 15 minutach wszystko mnie bolało i miałem dosyć Formalnie nigdy nie uczyłem się C/uK, przygoda czysto hobbystyczna. Jedynym wyjątkiem był jeden semestr "Technik Mikroprocesorowych" na studiach (kierunek zupełnie nie informatyczny/elektroniczny) - wykład w bólach na 3 zaliczyłem - nie chciałem się uczyć rejestrów 8051 na pamięć... porażka jakaś to była.

2. Praktyki nie mam żadnej praktycznie. Układy, który zrobiłem i udały się na tyle że do czegoś się przydają mogę policzyć na palcach jednej ręki. Lwia część moich projektów została "rozebrana" zaraz po tym jak zaczęły działać - temat opanowany przestaje być atrakcyjny

3. Czytać, czytać, czytać! A co konkretnie? Wszystko Kiedy trafiam na coś nowego - wpisuję to w googlach/wyszukiwarkach foruff. Najczęściej przy lekturze wypływają nowe zagadnienia - poszukiwania się "rozwidlają". Np. jak zaczynałem zabawę z STM32 to wpisałem w wyszukiwarce na Elektrodzie "stm32" i... tak minął tydzień Jakby nie patrzeć Internet jest moim głównym źródłem wiedzy.

4. Do wszystkiego staram się podchodzić krytycznie. Nie przyjmować nic na wiarę tylko drążyć temat aż zrozumiem. Nie trawię stwierdzeń w stylu "to się robi tak bo... działa i już" - nie nie nie - nie zasnę póki nie zaszufladkuję sobie czemu tak Unikam też używania gotowych kodów, bibliotek. A jeśli już to przynajmniej staram się je dokładnie przejrzeć, zmienić coś "po swojemu" - a najlepiej napisać od zera i porównać z czyimś kodem (oczywiście są wyjątki - do analizowania FatFS'a mi się nie pali).

5. Jeśli chodzi o książki to za wiele w sumie nie przeczytałem - tylko te "główne" polskie pozycje o uK i to nie w całości. Kiedyś dorwałem jakąś książkę na temat "embedded programming" ale była tak nudna że nie dałem rady przebrnąć.

6. Wydaje mi się, że najważniejszym "krokiem milowym" jest przerzucenie się z kursów i poradników na samodzielne docieranie do źródeł wiedzy i rozwiązywanie problemów. Problem z większością poradników jest taki, że kiedyś się kończą pozostawiając Czytelnika z jakimś kawałkiem wiedzy - mało który pokazuje jak samemu zdobywać/pogłębiać wiedzę - skąd ją czerpać. Przecież Autorzy poradników nie urodzili się z tą wiedzą, nie dostali jej gdzieś z pod lady Gdy zaczynałem zabawę z AVR'ami zawsze mnie to zastanawiało - skąd Autor poradnika to wie? Odpowiedź teraz wydaje się oczywista - datasheet, dokumentacja avr-gcc, avr-libc itp... tam na prawdę jest wszystko! Chociaż nie zawsze "wprost".

7. Niech sobie każdy mówi co chce, ale według mnie asemblera trzeba kumać! Tzn. nie na tyle żeby po obudzeniu o 3 w nocy napisać z biegu funkcję dzielącą przez siebie liczby zmiennoprzecinkowe - to przesada. Według mnie niezbędne jest jednak rozumienie "o co chodzi" w kodzie w asm, wiedza o tym jakie (z grubsza) są rozkazy i co umożliwiają. Ktoś kto napisał cokolwiek sam w asm zastanowi się dwa razy zanim użyje floatów w C, łatwiej mu będzie pojąć zagadnienia związane z atomowością itp... Poza tym - mając kilka możliwości zapisania czegoś w C - będzie mógł porównać kod asm co (być może) pozwoli wybrać rozwiązanie lepsze.

8. Mistrz Przedmówca wspomniał o czytaniu kodów innych. Podpisuję się pod tym wszystkimi wyprowadzeniami. Taka anegdotka: kiedyś w hipermarkecie usłyszałem jak młoda kobieta, wskazując na jakiś towar, pyta towarzyszącego jej mężczyznę "a co to jest?", odpowiedź brzmiała mniej więcej "jeśli nie wiesz co to jest, to nie jest Ci to potrzebne". To stwierdzenie jest bardzo prawdziwe, ale podejście idiotyczne Czemu prawdziwe - bo faktycznie - dopóki czegoś nie znamy to nie wiemy, że jest nam to potrzebne, radzimy sobie bez tego, czasem na około , ale jednak. Czemu idiotyczne? - bo gdyby ludzkość kierowała się takim podejściem to dalej tłuklibyśmy się maczugami w jaskiniach.
Wracając na grunt programowania - czytanie kodów innych (i wcale nie muszą to być kody lepszych programistów) - pokazuje inne podejście, inne mechanizmy, metody itd.. Osobiście uważam, że bardzo dużo nauczyłem się próbując pomagać innym na forach - broń Boże nie chcę nikogo wyśmiewać, ale ludzie mają czasem naprawdę dziwaczne pomysły, popełniają kuriozalne błędy, których "ja" bym nie zrobił - efekt tego jest taki, że człowiek cały czas uczy się czegoś nowego, poddaje w wątpliwość niby oczywiste sprawy "wiem, że to nie zadziała, ale właściwie dlaczego?". Jak to powiedział kolega mokrowski w temacie o kostce do gry na tiny13 -> to jest "pouczające"
Ponadto jest sporo prawdy w powiedzeniu, że próba wytłumaczenia czegoś komuś jest świetnym sprawdzianem własnej wiedzy.
Prosty przykład z życia - a propos kodów innych - wielokrotnie czytałem, że należy unikać używania zmiennych globalnych bez potrzeby. Pisząc swoje programiki nie bardzo się tym przejmowałem - przecież dokładnie wiedziałem co jest co i nic mi się nie myliło - po co więc miałem sobie życie utrudniać dziwacznymi radami... Pewnego dnia postanowiłem jednak, z lenistwa, wykorzystać czyjś kod (stacja lutownicza z reg. PID). Wymagał on jednak drobnych zmian - w projekcie był LCD, ja miałem LED; potencjometr zamiast przycisków itp... 90% zmiennych w tamtym programie to były zmienne globalne - próba uporządkowania tego bardzo wyraźnie pokazała czemu zmienne globalne są złe i jak trudno ogarnąć taki program

9. Nie można się bać próbowania. Bardzo często odpalam sobie jakiś kod czy to w kompilatorze C online (jest szybciej), czy w pająku na płytce stykowej - żeby coś sprawdzić. To czasem bywa o wiele szybsza metoda, niż szukanie w dokumentacji.

10. Uważam, że bardzo dużo dało mi rozszerzenie mojego menu mikrokontrolerowego o STM32 (wcześniej tylko AVR8). Czemu? Bo nagle okazało się, że część rzeczy oczywistych w AVR, w STM działa inaczej. Nie mam na myśli oczywiście innych peryferiów To zrodziło kolejne pytania - a czemu tak jest? Jak pojawiły się pytania, to zaczęło się buszowanie w googlach... w trakcie lektury pojawiły się kolejne pytania itd itd... Dodatkowo przygotowanie środowiska dla STM'ów spowodowało, że zetknąłem się z elementami, które dotychczas były ukryte w toolchainie AVR i nigdy się nimi nie interesowałem - np. skryptem linkera, kodem "rozruchowym" uP itd.. Nagle te pliki "jawnie" pojawiły się w projekcie... a więc wrodzona dociekliwość nie pozwoliła mi zasnąć zanim nie ogarnąłem ich zawartości.

11. Nie da się ukryć, że piszę z punktu widzenia hobbysty z kilkuletnim stażem (czasem z przerwami na inne hobby, ale jednak). Druga strona medalu jest taka, że osoba, która dopiero zaczyna nie może się rzucić na zbyt głęboką wodę. Ktoś kto po opanowaniu "blink-led'a" postanowi zbudować zdalnie sterowanego drona najprawdopodobniej polegnie. Wszystko musi przyjść z czasem. Tu stanę trochę w opozycji do tego co pisałem wcześniej - początkujący musi część rzeczy przyjmować na wiarę i drążyć temat stopniowo w miarę postępów w nauce. Trzeba samemu wyczuć czy nie zapuszczamy się za daleko. Nagrodą w wytrwałości jest to, że potem przychodzi taki okres, gdy nowe "odkrycia" więcej porządkują niż mącą Wszystko zaczyna do siebie pasować.

12. Czytać, czytać, czytać - wiem wiem było... ale nigdy nie jest za dużo

Ech. Jak Boga kocham chciałem podrzucić link z embedded-gurus, ale mnie kolega mokrowski ubiegł
W takim razie podrzucam link to małego sprawdzianu z emb-C: klik. Miłej zabawy.

Jestem pod wrażeniem Myślę że te słowa pomogą niejednemu zapaleńcowi jak mi. Dziękuję za dopowiedzi