ATNEL tech-forum

Re: ADC

2011-12-07T17:05:07+01:00

Michal_PB1 napisał(a):

aczkolwiek w obecnej sytuacji nie jest az tak wazne te 2 bajty

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

Statystyki: Napisane przez mirekk36 — 7 gru 2011, o 17:05

Re: ADC

2011-12-07T16:41:43+01:00

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

Statystyki: Napisane przez Michal_PB1 — 7 gru 2011, o 16:41

Re: ADC

2011-12-07T16:20:09+01:00

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:

Code:

wynik = pm * 25 * 13; // wynik = 276250

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

Quote:

W efekcie takiego działania, na wyświetlaczu LCD uzyskamy wartość mierzonego napięcia w postaci: 27.62V.

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ć

Statystyki: Napisane przez mirekk36 — 7 gru 2011, o 16:20

Re: ADC

2011-12-07T15:39:16+01:00

A czy moglbym prosic o odp, dlaczego w takim kodzie jak ponizej po zmienie zmiennej pm na uint32_t program dziala prawidlowo ?
[syntax=c]
#include
#include

#include "LCD/lcd44780.h"

uint16_t pomiar(uint8_t kanal);

int main(void)
{
lcd_init();

ADMUX |= (1<ADCSRA |= (1<
uint32_t wynik;
uint32_t pm;
uint8_t cz_d, cz_u;

while(1)
{
lcd_cls();
lcd_locate(0,0);
lcd_str("Napiecie:");
lcd_locate(0,10);
pm = pomiar(4);
wynik = pm * 25 * 10;
cz_d = wynik/10000;
cz_u = (wynik/100) % 100;
lcd_int(cz_d);
lcd_char('.');
lcd_int(cz_u);
lcd_str("V");
_delay_ms(1000);
}
}
uint16_t pomiar (uint8_t kanal)
{
ADMUX |= (ADMUX & 0xF8) | kanal;
ADCSRA |= (1<while(ADCSRA & (1<return ADCW;
}

[/syntax]

Statystyki: Napisane przez Michal_PB1 — 7 gru 2011, o 15:39

Re: ADC

2011-12-07T15:33:39+01:00

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.

Statystyki: Napisane przez mirekk36 — 7 gru 2011, o 15:33

Re: ADC

2011-12-07T14:32:49+01:00

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

Statystyki: Napisane przez Michal_PB1 — 7 gru 2011, o 14:32

Re: ADC

2011-12-07T12:17:18+01:00

Michal_PB1 napisał(a):

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

....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

[syntax=c]
uint32_t wynik;
uint16_t pm;

pm = pomiar(5);// odczytana wartość ADC np. = 850

wynik = pm * 1 * 2957;// wynik = 2.513.450[/syntax]

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.

Statystyki: Napisane przez mirekk36 — 7 gru 2011, o 12:17

Re: ADC

2011-12-07T09:30:32+01:00

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.

Statystyki: Napisane przez SunRiver — 7 gru 2011, o 09:30

Re: ADC

2011-12-06T16:42:59+01:00

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)
[syntax=c]ADMUX |= (ADMUX & 0xF8) | kanal;
ADCSRA |= (1<while(ADCSRA & (1<return ADCW;[/syntax]

Statystyki: Napisane przez Michal_PB1 — 6 gru 2011, o 16:42

Re: ADC

2011-12-06T00:23:49+01:00

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:

[syntax=cpp]
// biblioteki
#include

// piny uzyte do podłaczenia LCD
LiquidCrystal lcd(7, 8, 9, 10, 11, 12);

// zmienne dzielnika i ustawienie portu
int analogInput = 1;
float vout = 0.0;
float vin = 0.0;
float R1 = 50000.0; // rezystancja R1 w omach
float R2 = 4400.0; // rezystancja R2 w omach

// variable to store the value
int value = 0;

void setup(){
// ustwienie wejścia
pinMode(analogInput, INPUT);

// ustawienie rozmiaru LCD
lcd.begin(16, 2);
lcd.print("Vin=");
}

void loop(){
// odczut ADC
value = analogRead(analogInput);

vout = (value * 5.0) / 1024.0;
vin = vout / (R2/(R1+R2));

// wyswietlanie rezultatu
lcd.setCursor(4, 0);
lcd.print(vin);
lcd.print("V");

// oczekiwanie
delay(500);
}

[/syntax]

działa bez błędnie

dzielnik :

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

Statystyki: Napisane przez SunRiver — 6 gru 2011, o 00:23

Re: ADC

2011-12-05T23:55:43+01:00

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

Statystyki: Napisane przez SunRiver — 5 gru 2011, o 23:55

Re: ADC

2011-12-06T01:20:17+01:00

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. ;/

Statystyki: Napisane przez woow — 5 gru 2011, o 23:48

Re: ADC

2011-12-05T23:44:48+01:00

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

Statystyki: Napisane przez Michal_PB1 — 5 gru 2011, o 23:44

Re: ADC

2011-12-05T23:38:29+01:00

hmm dziwne u mnie poprawiło wskazania i to znacznie

czy uwzgledniłeś niedokładność rezystorów w dzielniku ??

Statystyki: Napisane przez SunRiver — 5 gru 2011, o 23:38

Re: ADC

2011-12-05T23:24:33+01:00

po pierwsze dzieki za propozcyje rozwiazania problemu, lecz to nie to

Statystyki: Napisane przez Michal_PB1 — 5 gru 2011, o 23:24

Re: ADC

2011-12-05T23:15:02+01:00

kufa a może to to :

masz w kodzie :
[syntax=c]#include
#include

[/syntax]

widzisz bład ?? a włąściwie oszczeżenie
tez nie zwróciłem na to uwagi

a powinno być

[syntax=c]#include
#include

[/syntax]

kompilator przepuszca , ale moze sie pluć juz procek

Statystyki: Napisane przez SunRiver — 5 gru 2011, o 23:15

Re: ADC

2011-12-05T23:05:02+01:00

Tak mam dany.Tez dobrze ustawilem

Statystyki: Napisane przez Michal_PB1 — 5 gru 2011, o 23:05

Re: ADC

2011-12-05T23:00:17+01:00

a czy masz wpiety kondensator na AREF ??
ja zwykle dla wewnetrznego źródła daje 100nF miedzy AREF i GND

tak na wszelki wypadek przytaczam ustawienia z noty:

Statystyki: Napisane przez SunRiver — 5 gru 2011, o 23:00

Re: ADC

2011-12-05T19:26:38+01:00

zmiana napiecia odniesienia nic nie dala

Statystyki: Napisane przez Michal_PB1 — 5 gru 2011, o 19:26

Re: ADC

2011-12-05T19:05:51+01:00

moze nie koniecznie odrazu nowy uC , ale moze skozystaj z zewnetrznego napiecia odniesienia na poczatek i staraj sie unikac wbudowanego ... ja jeszce patrze co mozna by było poprawic ew

Statystyki: Napisane przez SunRiver — 5 gru 2011, o 19:05

Re: ADC

2011-12-05T18:46:52+01:00

hmm czyli mozna powiedziec ze to wina uC ? jakies propozycje rozwiazania czy po prostu kupic jakis lepszy uC ?

Statystyki: Napisane przez Michal_PB1 — 5 gru 2011, o 18:46

Re: ADC

2011-12-05T18:34:54+01:00

hmm no ciekawe bo na m88 mam podobne wyniki jak kolega z ta róznicą że :

dla 12V wynik 10.14 dla 8 = 5,22 , dla 9,5V = 7,13 , dla 29V = 28,11
bardzo dziwne

Statystyki: Napisane przez SunRiver — 5 gru 2011, o 18:34

Re: ADC

2011-12-05T18:27:48+01:00

hmmm..m8 piszesz kurcze mam tylko megi 88/168/328 ale zaraz sprawdzę na którejs sa fakt lepsze od m8 , ale tego pokroju

Statystyki: Napisane przez SunRiver — 5 gru 2011, o 18:27

Re: ADC

2011-12-05T18:11:39+01:00

po sprawdzalem polaczenie pomierzylem rozne wartosci i to do czego doszedlem:
wg mnie jezeli napiecie nie przekracza bynajmniej u mnie 5V to pomiary sie zgadzaja (wiadmomo minimalne roznice wzgledem miernika)
natomiast jezeli pomiary wykonywane sa na napieciu powyzej 5V (nie przekraszajace oczywiscie dopuszczalnego napiecia ) to wyniki sie nie zgadzaja i to duzo np: dla 12V wynik 3,5V dla 8V wynik 0,74V dla 19V wynik 3,5V nie wiem co jest tego przyczyna. Kod raczej nie jeżeli kolega SunRiver spr i pomiary sie zgadzaly. Dodam, że używam Atmega8

Statystyki: Napisane przez Michal_PB1 — 5 gru 2011, o 18:11

Re: ADC

2011-12-05T17:35:23+01:00

no ja rozumiem nikt tu inny winien niżeli ja nie jest.

Statystyki: Napisane przez Michal_PB1 — 5 gru 2011, o 17:35