no wiadomo ze jest tam pewna niedokładnosc ale nie kilka V. Jutro jeszcze raz na spokojnie przejze uklad i dam znac co i jak

ADMUX &= ~(ADLAR); proponuję wstawić przed ustawianiem kanału przy pomiarze.
Jeżeli działasz na ATMEDZE 8.
Miałem podobny problem i to go rozwiązało.


-----------------------
edit: jak widać zapis ADMUX &= ~(ADLAR); jest "specyficzny", i po przejrzeniu swojego projektu ADC na atmega8 muszę przyznać, że mój problem dotyczył innej kwestii, a zapis ten "przypadkowo" pomógł w jej realizacji.
Zatem nie proponuję stosowania w swoim przypadku.
Gdzieś dzwoniło, niestety nie wiadomo w którym kościele. ;/

ot właśnie .. tu moze byc problem - woow dobrze prawisz

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

w koncu zgłupiałem o co chodzi , ewidentnie cos mi w kodzie nie pasuje

zeby wyjsc z załozenia postanowiłem na szybko postawic duino na m168 i skrobnac mały sofcik:



działa bez błędnie

dzielnik :

Vin ---
|
R1
|
----- duino AnalogIN 1
|
R2
|
Gnd -------- GND

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

ja nie moge wgrac tego kodu - bo chyba napisany w C++ ?? nawet z podpowiedzia kolegi woow dalej jest taki sam obiaw, moze to jednak wina procka ?
edit://

PROBLEM ROZWIAZAŁEM
pewnie ciekaw kolega SunRiver jest co bylo przyczyna ?
a otóż nie wlasciwy typ zmiennej 'pw' (i chyba mi sie zdaje ze w ksiazce tez jest blad bo jest uint16_t a wychodzi liczba duzo wieksza, nie chce podważac umiejetnosci autora !!) zmienilem z 16 na 32 bo tak sobie mysle po sprawdzeniu juz all i spr z nota cos musi byc, ze nie chce mierzyc powyzej 5V czyli musi byc coz z liczba no i tak zmienilem all typy na 32 i patrze DZIAŁA

Ale dziekuje wszystkim za pomoc

mam jeszcze jedna prosbe o wyjsnienie tego kawalku kodu (glownie to pierwsza linijke i ostatnia dlaczego jest ADCW)

Widzisz nie zwróciłem uwagi na zmienną - uznałem , ze to pewnie masz dobre
ciekawostka w sumie

co co programu C++ jak chcesz mogę ci zrobić bootloader arduino do m8 i albo podesłać hexa napisałem to tylko w celu sprawdzenia
na szybko więc rozumiesz.

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

....oj, oj .... panie kolego ... ja bardzo uprzejmie proszę o jasne i rzeczowe odniesienie się do tego błędu w kontekście zwrócenie uwagi o błędzie w książce. Nie chodzi tu o moją urażoną dumę, bo każdy może popełnić błąd, ja także - jestem tylko człowiekiem jak każdy.

Jednak bardzo przepraszam, ale nie chciałbym na tym forum, takich stwierdzeń o błędach w książce i to bez żadnego poparcia. Nie żebym się czepiał ale proszę zwrócić przede wszystkim uwagę na to, że:

1. po pierwsze w książce nie ma żadnej zmiennej pw tylko pm (ale rozumiem, że to może być literówka po prostu) dlatego przyjmuję, że kolega ma problemy właśnie z tą zmienną w kodach z książki.

2. zmienna pm w książce jest typu uint16_t i jak najbardziej jest to prawidłowo dobrany typ dla tejże zmiennej



w kodzie w książce występuje ona w takim użyciu i w takich linijkach kodu. Zwracając więc uwagę na błąd w książce, bardzo uprzejmie proszę się odnosić do faktów a nie do własnego kodu, który może być źle napisany. Szczególnie na tym forum. To nie forum elektroda i dlatego chciałbym aby tu każdy mógł znaleźć rzetelne informacje a nie domysły. Bo na elektrodzie to nie jeden temat rozpoczyna się o tym, że ktoś ma problem z kodami z naszej książki, gdyż tam są błędy albo dlatego pisze o swoim problemie bo "słyszał", właśnie skąd słyszał? z takich właśnie postów o rzekomych problemach. Tylko proszę je poczytać dalej. To że na końcu zwykle się wszystko wyjaśnia i autor gdzieś na samym końcu nieraz (bo nie zawsze) odwołuje swoje słowa z początku tematu uznając, że to jego ewidentny błąd, to i tak później tego nikt nie czyta. Każdy widzi tylko nagłówek tematu:

"I znowu są problemy z kodami z książki z Atnela"

Po to powstało to forum. Proszę zatem na podstawie tego co jest pokazane (zaznaczam) jako przykład w książce - patrz linijki powyżej gdzie jest błąd z typem zmiennej pm ? i proszę spróbować, hmm pokusić się o precyzyjne uzasadnienie tego błędu.

Bo to, że w trzeciej linijce kodu, który widać powyżej zakres obliczeń znacznie przekracza pojemność uint16_t to chyba oczywiste dla każdego, tyle że co ma tu do rzeczy typ zmiennej pm ?

Wynik obliczeń trafia do zmiennej wynik, a ta już jest typu uint32_t !

skąd więc pomysł o przekroczeniu pojemności typu dla pm, skoro ta zmienna na podstawie działania funkcji pomiar może w swoim całym życiu w programie przyjąć tylko i wyłącznie wartości od 0 do 1024 (bo taka jest maksymalna możliwa wartość do odczytania właśnie z pary rejestrów ADCH i ADCL - czyli jednym słowem z ADCW (to od razu jest odpowiedzią na kolejne pytanie szanownego kolegi. AVR GCC przygotował specjalne makro ADCW na tę okoliczność, żeby od razu prosto odczytać wartość tych dwóch rejestrów, stąd wzięło się w kodzie ADCW)

wracając do rzekomego błędu w książce - sorry że do tego wracam, ale jednak wielu ludzi czyta wątki które są tutaj, po przeczytaniu sugestii kolegi i bez mojego odniesienia się do rzeczy, będzie nosiło to w swojej głowie i podświadomości, a potem jak tylko zdarzy im się jakiś problem z ćwiczeniami ADC, to podświadomość od razu podpowie, że " aaaaa gdzieś już czytałem, że w tej książce są błędy z ADC" .... Tymczasem kolega pewnie sobie kod zaczął rozwijać po swojemu i użył zmiennej pm w inny sposób niż trzeba - popełniając błąd. Tego jednak nie wiem na pewno, więc nie zarzucam koledze też od razu błędu - tylko proszę w takich przypadkach o pokazanie kodu dokładnego miejsca gdzie wystąpił problem czy gdzie udało się go odnaleźć. Wtedy wszystkim będzie łatwiej OK ?

dlatego tak się nie robi ok ???

Jest odpowiedni dział na forum do zgłaszania błędów i prosiłbym jak już to w ten sposób to rozwiązywać albo najpierw podzielić się taką rewelacją ze mną na PRIV.

Mam nadzieję, że kolega się nie obrazi za moje uwagi bo nie to było moim celem a po prostu wyjaśnienie.

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

Nie obrazam sie bo jak widac ewidentnie wina znowu lezy po mojej strony. Zwracam honor !!
Jako, ze jestem poczatkujacy to napisalem "chyba mi sie zdaje" - wiec to nie bylo stwierdzenie ze jest blad tylko informacja dla kogos kto sie zna o sprawdzenie tego. Sam teraz sie zastanawiam z czego wyciaglem takie stwierdzenie chyba z tego ze policzylem sobie wartosc zmiennej wynik
Przepraszam Panie Mirku ze znowu sa problemy przez moje nie dopatrzenie

Nie nie, spokojnie żadne problemy, po prostu liczę na takie właśnie uczciwe i kulturalne dyskusje jak tutaj A przypadku zauważenia błędu (bo nie mówię, że być może kolega gdzieś takiego nie znajdzie), poproszę o kontakt najpierw na PRIV, to potem oczywiście opiszę sam ten błąd wyraźnie albo podam aktualizację do kodów programów tak jak miało to miejsce z dwoma czy trzema projektami do których są przecież patche na naszym forum.

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

A czy moglbym prosic o odp, dlaczego w takim kodzie jak ponizej po zmienie zmiennej pm na uint32_t program dziala prawidlowo ?

Już tłumaczę, bo hmm rzeczywiście jest pewna nieścisłość - albo hmm nawet jednak błąd w książce, ale teraz już go widzę wyraźnie i mogę podpowiedzieć co i jak. Otóż jest w książce dokładnie taka linijka kodu:



na stronie 243. I niestety pod spodem jest zdanie, cytuję:


tymczasem przy tak zapisanym kodzie nigdy nie ukaże się nam taka wartość i będzie dokładnie taki problem jaki pojawiał się u ciebie. Z tym, że nie jest on bezpośrednio związany z zakresem (typem) zmiennej pm. Chodzi o to, że AVR GCC standardowo robi promocję wyników obliczeń tego typu do zakresu 16 bitów. (Automatycznie nie zostanie ten zakres zmieniony) Stąd obliczenie wyrażenia: pm * 25 * 13 będzie domyślnie zawężone do 16 bitów. I jak widać będziemy mieli problem.

Jak to można rozwiązać ? na kilka sposobów. Jednym z nich (ale wg mnie nie najlepszym) jest właśnie zmiana typu zmiennej pm do 32 bitów jak to zrobiłeś. No ale tracimy niepotrzebnie (teoretycznie bo może to nie mieć żadnego znaczenia) dodatkowe dwa bajty cennej pamięci RAM (czy to w obszarze zmiennych globalnych czy też na stosie) prawda ?

Dlatego w takim przypadku wystarczyłoby gdybyś tę linijkę napisał tak:

wynik = pm * 25UL * 13UL;

albo nawet tylko tak:

wynik = pm * 25 * 13UL;

albo także tak:

wynik = (uint32_t)pm * 25 * 13;

wtedy w sposób jawny za pomocą UL sugerujesz kompilatorowi aby domyślną promocję wyniku tego działania wykonał do typu jaki reprezentuje największy typ stałej lub zmiennej biorącej udział w obliczeniach. A jak wiesz UL oznacza unsigned long, a zatem dokładnie typ 32bitowy bez znaku. A w ostatniej linijce nie ma UL, ale robimy jawne rzutowanie zmiennej (uint32_t)pm na czas obliczania tego wyrażenia do typu 32-bitowego. Jednak nie musimy tracić 2 dodatkowych bajtów pamięci na zmienną - co też nieraz też bywa bardzo istotne gdy poszukujemy oszczędności co do bajtu i optymalizujemy swój program.

Dlatego w efekcie końcowym to ja przyznaję się do błędu - ale tera gdy podałeś jasny przykład - łatwiej było mi go dostrzec i mam nadzieję, że mnie rozumiesz. A przy okazji mam nadzieję, że w tym miejscu udało mi się w miarę dobrze wyjaśnić co i skąd się bierze oraz jak sobie radzić w takich sytuacjach a jednocześnie jak lepiej gospodarować typami a co za tym idzie cenną pamięcią RAM

Reasumując nieścisłość ta pozostaje tylko w książce a nie w kodach na DVD ponieważ tam przykłady są całkowicie inaczej skonstruowane.

I w takim razie dziękuję że dzięki tobie udało się takiego babola wyłapać

_________________
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. dziekuje za obszerne opisanie tej sytuacji.juz rozumiem, aczkolwiek w obecnej sytuacji nie jest az tak wazne te 2 bajty (bo to byla lekcja spr dzialanie tego przetwornka ADC), lecz nie wiem co moze byc kiedys, ale juz wiem jak sobie z tym poradzic

Ciesze sie, ze moglem sie do czegos przydac

No dokładnie to też pisałem wyżej, nie mniej jednak jak się pisze programy dla procków to od dzieciństwa powinien się wyrabiać nawyk oszczędnej gospodarki każdym bajtem pamięci RAM. O to tutaj chodzi. Bo sam widzisz, jak będzie później większy projekt i w 100 funkcjach pozwolisz sobie na taką nonszalancję to może być kiepsko - sam przyznasz chyba. A o wiele gorzej jest szukać później błędu czy optymalizować program. Niż od początku zwracać uwagę na tak istotną rzecz. I to jest właśnie ta jedna z istotnych różnic pomiędzy językiem C dla PC a językiem c dla mikrokontrolerów i to wcale nie tylko AVR

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