Kilku moich luźnych uwag do prezentowanych fragmentów kodu, i od razu zaznaczam, że nie będą one miały nic wspólnego z tym dlaczego akurat koledze nie działa coś tam ... chociaż ? .... dotyczyć będą dobrego stylu programowania w C na procki i zawsze takie uwagi piszę, gdy ktoś pierwszy raz swój kod wstawia na forum ...



zapisy oznaczone na czerwono kompletnie nie mają sensu a jeśli ktoś twierdzi, że są tylko tak dla porządku, to jest wręcz odwrotnie, wprowadzają TOTALNE zamieszanie i tragicznie trudno analizować kod. Na dodatek NAJCZĘŚCIEJ wpływają też na to że sami strzelamy później totalne babole i dłużej szukamy błędu bo dopiero na końcu gdzieś zauważymy, że nie zmieniliśmy durnego zera na jedynkę albo odwrotnie ... tak się nie robi (ale zakładam oczywiście, że kolega wie, że taki zapis (0<<x) bitowo nic nie robi tzn przede wszystkim NIE ZERUJE bitu - podpowiadam gdyby kolega nie wiedział)


gdy korzystamy z AVR GCC a kolega korzysta tu z AVR GCC to stosujemy typy przewidziane dla tej odmiany języka ... czyli jeśli chodzi o liczby to najmniejszy typ to uint8_t a nie żadne tam "unsigned char". Po pierwsze domyślnie kompilator jest ustawiony, że kompiluje char jako unsigned char, po drugie typ char rezerujemy sobie do miejsc gdzie korzystamy ze znaków alfanumerycznych. W ogóle stosowanie unsigned char - zamiast samego char nawet w przypadku gdy będziemy korzystali ze zmiennych a szczególnie funkcji wbudowanych w avr gcc przyniesie później tylko zdziwienie i kłopoty - dlaczego ? ano właśnie dla tego o czym mówiłem wcześniej - bo będą warningi o niezgodności typów ponieważ avr gcc w wielu takich sytuacjach będzie się spodziewał uint8_t albo przynajmniej char - a nie żadnego unsigned char który wywoła warning. Podsumowując - widać w tym miejscu wciąż duże przyzwyczajenie kolegi do C/C++ na PC.

to samo się tyczy



nie żadne unsigned int tylko : ....



czyli



No a tutaj:

to unsigned char to już w ogóle gryzie po oczach, że aż łzy lecą jak przy krojeniu cebuli Nie piszę tego broń Boże żeby się wyśmiewać czy dogryzać tylko żeby podpowiedzieć z uśmiechem o standardzie avr gcc i specyfice pisania kodu na procki i wcale nie tylko 8-bitowe

proszę spojrzeć jak to może przyjemnie wyglądać:



Dobra tyle tytułem wstępu - na temat szczegółów wizneta się nie wypowiem bo nigdy nie miałem do czynienia z tym modułem - ale tak na zasadzie domyślania się to ... hmmm co to za transmisja SPI jakaś jednokierunkowa? w tych funkcjach




toż transmisja SPI jest DWUKIERUNKOWA czyli gdy nadajemy to jednocześnie ODBIERAMY - oczywiście zależy to też od specyfiki układu docelowego ale może właśnie tutaj jeśli już chodzi o sprawy merytorycznych błędów kolega robi babole ? (ale jak mówię tylko domyślam się jeśli chodzi o pogaduszki akurat z wiznetem) Tak więc te funkcje może są babolem - powinna być jedna która ma i rezultat i argument np

_________________
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 ja cierpliwość mam ogromną i chyba każdy kto mnie zna to o tym wie - za to jak mówiłem zawsze staram się na forum o tym przypominać ponieważ ... tutaj zdecydowana większość jak nie wszyscy posługują się AVR GCC i takie pisanie kodu jest przede wszystkim o wiele bardziej czytelne dla tych, do których się zwracamy z pytaniem .... to również jakby pewien standard na tym forum

Co nie oznacza, żeby dyskryminować CodeVision - tyle że wtedy warto zaznaczyć, że np "Uwaga kod pisany w CodeVision" gdzie nie stosuje się takich typów tylko standardowe podejście z ANSI C w tym zakresie - i takie uwagi już nieraz były na forum" ... wtedy ja z kolei się nie włączam ze swoimi uwagami ... Teraz chyba kolega rozumie w czym rzecz - bo ja chcę pokazać tu raczej że mogło to być powodem nawyków z programowania na PC i że warto się przestawić w tej sytuacji.


Dlatego ja nie mówiłem, że na pewno tylko że być może ... i żeby zwrócić właśnie uwagę na dokumentację ...

np w komunikacji z modułami RFM37 bodajże o ile dobrze pamiętam absolutnie już od pierwszego wysyłanego bajtu - jednocześnie zaczynamy odbierać dane

czasem trzeba zwrócić uwagę w dokumentacji na sekwencję właśnie .... bo być może tak jest że wysyłasz komendę a odbierasz bajt śmieć, a następnie dopiero moduł wysyła kolejne bajty danych

ja tego nie wiem jak to jest z wiznetem i dlatego tylko zwróciłem uwagę - a może być że jest to ok ... to już kwestia zabawy z modułem i sprawdzenia

Chyba że trafi się ktoś na forum kto się bawił z tym modułem przez SPI i coś podpowie

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



Jak znam życie to zwykle więcej przez takie podejście problemów - i nie chodzi tylko o zadanie pytania na forum ale nawet jak się samemu programuje i testuje coś często - ponieważ DUŻO gorzej zauważyć błąd że gdzieś tam w końcu daliśmy albo nie daliśmy jedynki albo zera. Natomiast linia w której widać KONKRETNIE ustawione bity - to od razu daje po oczach i wiadomo co się robi - trudniej samemu o pomyłkę.

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

Znasz tę stronkę?
http://www.ermicro.com/blog/?p=1773
Najlepszy tutorial jaki znalazłem jeśli chodzi o kość Wiznet.