Proszę o wyjaśnienie takiego zapisu:
Powołuję zmienną



Dlaczego to się kompiluje skoro powołana zmienna jest ośmio bitowa?
To jest kawałek programu.

To jest właśnie siła języka C. Tu rządzi programista, ale niestety musi wiedzieć co robi, dlatego też zasady dotyczące wielkości zmiennych są bardzo elastyczne, a jedna z większej elastyczności to domyślna promocja do int.
Inaczej pisząc, to programista musi kontrolować zakres typów, a nie kompilator. Dzięki temu można robić "różne sztuczki"

hmm...
ja nie wiem dlaczego nie krzyczy.

powołujesz zmienną z wartością 0,
inkrementujesz do wartości 1,
oczekujesz na spełnienie 'ifa' który który nigdy się nie spełni, by ustawić wartość na PORTB.
poza ifem: zerujesz zmienną.

hmm. ale dlaczego nie krzyczy?
może dlatego że nie przypisujesz takiej wartości do zmiennej, a sprawdzać w ifie można cokolwiek

A dlaczego miałby krzyczeć? Co szkodzi porównywać zawartość bajtu ze słowem ? Toż w zakresie 0-255 pokrywają się ich wartości ... poza tym to co pisze wyżej kolega Zealota.

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

Wg mnie nie krzyczy, bo w linijce:

właściwie to jest:


oprócz tego tam jest niepotrzebny średnik.
Dodatkowo promocja do int jednak zapewni, że warunek się spełni.
Można rzutować na int8_t i wtedy już nie będzie działać.
Tak z praktyki dopiero ostatnio widzę, co było dla mnie długo mgliste, ten wszędobylski int
Nie potrafię już na to patrzeć, że co chwilę trzeba rzutować, żeby nie przekroczyć zakresu int dla dużych liczb, a to powoduje farfocle, oczopląsy i długaśne linijki
Przy AVR to zwykle, żaden problem, bo tam rządzi uint8_t, ale przy tych stm,ach to już trzeba się strzec

Nie rozumiem dlaczego promocja do int, skoro powołana zmienna jest określona uint8_t

------------------------ [ Dodano po: 2 minutach ]


A gdzie inkremenuję do wartości 1?

W drugiej linii Twojego kodu, nie widzisz tego?;-)

_________________
Pozdrawiam
PP

Tak w drugiej linii inkrementuję zmienną, ale nie do jednego a do 500.

jak dla mnie nie zachodzi tu żadna promocja do int tylko zmienna jedzie sobie do 255 i się przepełnia i nigdy nie osiąga 500. Nikt nie zabroni sprawdzać czy jest równa nawet 10000000 bo dlaczego by nie. Po prostu zawsze będzie fałszywy warunek i już.
Poza tym warunek if ( zmienna == 500 ); jest pusty a reszta jest poza warunkiem, czyli port się togluje cały czas a zmienna zeruje się zawsze po 1.

Lepiej byłoby tak, choć wg mnie i tak się nie wykona warunek



w każdym obiegu pętli. Na początku masz zmienna=0, potem zmienna++ czyli inkrementujesz do 1, potem pusty if, który i tak nigdy się nie wykona, następnie ZA KAŻDYM OBIEGIEM resetujesz zmienna.
 

_________________
IntegraMETEO
WordCLOCK
IntegraTOUCH

Proponuję najpierw sprawdzić, kompilując kod.
Ja oczywiście sprawdziłem pod kompilatorem i dlatego jestem mądrzejszy.
To najlepsza forma nauki.

No to muszę doczytać... DO tej pory żyłem w przekonaniu, że dotyczy to działań typu dodawanie i mnożenie dwóch zmiennych a nie zwykłego inkrementowania. ALe w sumie jakby się tak zastanowić to zmienna++ to też dodawanie dwóch liczb.
Nie zmienia to faktu, że w tym wypadku if się i tak nie wykona bo zmienna nie dojdzie nigdy nawet do 2, a warunek jest pusty

_________________
IntegraMETEO
WordCLOCK
IntegraTOUCH

Proponuję poczytać np. to (dość przystępny opis):
https://opensourceforu.com/2016/06/quic ... omotion-c/

Ewentualnie wpisać w Google "c promotion rules" i pojawi się sporo artykułów na ten temat.

Jeszcze hola hola.
Być może wczoraj trochę jednak niepotrzebnie zamieszałem, przepraszam
Zrobiłem kolejne testy i na razie mojej tezy o tym, że dojdzie do warunku zmienna == 500, z powodu promocji do int, nie mogę wykazać niestety, pomimo pracy z kompilacją.
Zgodnie z sugestią Kolegi andrews również mnie się należy dokształcenie...

Inkrementacja zmiennej jest umieszczona w przerwaniu, więc w każdym przerwaniu wzrasta o wartość jeden.
Skąd się wzięło u was inkrementacja do 1.
Zmienna zerowana jest po warunku if nie po każdym obiegu. Tak ja to widzę.

Chodził mi oto, że powołałem zmienną ośmio bitową a w przerwaniu w warunku if wpisałem wartość 500 i kompilator
nie wyświetlił mi błędu a skompilował. Ja myślałem, iż największą wartość jaką można wpisać to 255,
Jeden z kolegów wyjaśnił, iż to programista ma pilnować wartości wpisywanych do warunku if.
To co podałem w pierwszym poście to tylko wybrany fragment kodu.

Dzięki wszystkim za wypowiedzi.

Przeanalizuj co robi Twój warunek...

Albo zapisz go inaczej - będziesz widział co się dzieje"



A teraz zobacz taki zapis:


Widzisz teraz skąd ta jedynka a nie 255 czy 500?

_________________
IntegraMETEO
WordCLOCK
IntegraTOUCH

Wygląda na to, że w porównaniu kompilator nie sprawdza typu.

Gdyby zapisać tak:


To dostaniemy ostrzeżenie. Porównanie to oczywiście nie to samo co przypisanie wartości do zmiennej.

Dokładnie. I to jest chyba podsumowanie tematu.
Bo kto programiście zabroni porównania np tak abstrakcyjnego i pozbawionego sensu jak if (zmienna== "elephant"){};

Można sprawdzić czy kolor_samochodu == kombi ;p
Oczywiście nie ma to sensu, typy niezgodne i nie mają prawa nigdy się zgodzić ale kompilator grzecznie to zaakceptuje a program ochoczo będzie sprawdzał warunek za każdym obiegiem... hehe

_________________
IntegraMETEO
WordCLOCK
IntegraTOUCH

Zawsze można dodać do linii poleceń kompilatora opcję -Wtype-limits, która powinna w takim przypadku spowodować wyświetlenie ostrzeżenia w stylu:
"comparison is always false due to limited range of data type". Opcja ta jest też zawarta w zestawie opcji -Wextra.

EDIT:
Jeszcze tylko małe sprostowanie:

W tym przypadku nie będzie. Kod dokonujący porównania zostanie zoptymalizowany nawet przy wyłączonej optymalizacji. Tak samo nie zostanie w ogóle wygenerowany kod instrukcji wykonywanych w przypadku spełnienia warunku. Kompilator po prostu uzna, że sprawdzenie warunku zawsze zwróci fałsz.

Warunek będzie za to sprawdzany mimo bezsensownego porównania w przypadku porównania dwóch zmiennych o różnych typach, przykładowo:

Nastąpi tutaj promocja zmiennej zmienna do int, więc porównywane będą wartości 16-bitowe. W tej sytuacji wiadomo, że nie istnieje taka wartość zmiennej zmienna_int dla której porównanie mogłoby zwrócić prawdę (chyba, że wynik dodawania przekroczy zakres zmiennej 16-bitowej bez znaku), jednak w tym przypadku sprawdzanie warunku będzie się odbywać za każdym razem (praktycznie za każdym razem zwracając fałsz) i w dodatku żadne ostrzeżenie nie zostanie wygenerowane.

Innymi słowami i tak trzeba się pilnować