Proszę o nakierunkowanie mnie jaką drogą podążać. To są moje początki i nie wiem w jakim kierunku pójść przy obliczeniach matematycznych w AVR-kach.

Podaję przykład wzorów na obliczenie wartości z noty aplikacyjnej układu SHT21.

Dla temperatury jest to:
Dla wilgotności względnej:
Uprościłem je sobie do postaci:

DTA - jest to 12-to lub 14-to bitowa wartość odczytana z układu.

Dodam, że jest dostępna biblioteka dla tego układu i tam użyto typów float do obliczeń. Ja jednak kombinuje jak koń pod górę z użyciem int-ów, nie wiem czy tym samym nie wyważam otwartych drzwi. Oczywiście podane wyżej wzory proszę traktować czysto przykładowo.

Będę wdzięczny za wszelkie wskazówki.

_________________
Migracja z punktu B do punktu C
Pozdrawiam

T = (DTA * 175.72 / 65536) - 46.85

załóżmy że np DTA=12000 (tak strzelam)

no to teraz

( (DTA * (175.72*100)) / 65536 ) - (46.85*100) = -1467.47 czyli na końcu mamy: -14,67 jak już podzielimy przez tą liczbę 100

oczywiście trzeba wziąć przy tych obliczeniach pod uwagę promocję do INT http://atnel.pl/domyslna-promocja-do-typu-int.html

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

Dziękuję za odzew.
Cieszę się, że szedłem jednak w kierunku liczb całkowitych.

Teraz po przykładzie Mirka widzę gdzie się gubiłem, robiłem owszem mnożenie x100, x1000x a nawet x10000 ale tylko dla pierwszej części równania, nie mnożąc przy okazji wartości odejmowanej na końcu. Teraz już wiem dlaczego wychodziły mi dziwne wyniki

Dodatkowo z tropu zbijało mnie to, że po dzieleniu przez 65536 wychodziły mi wartości po przecinku (w rozważaniach teoretycznych na papierze). Ale po woli do mnie dociera że skoro mam użyty typ int w kodzie to wynikiem dzielenia będzie w AVR-ku liczba całkowita, później od niej odejmuję także liczbę całkowitą i mam elegancki wynik. Dobrze myślę, tak?

_________________
Migracja z punktu B do punktu C
Pozdrawiam

dobrze tylko nie rób tego na typie int bo będzie za ciasny, co najmniej int32_t

a na końcu - nie "odejmuję liczbę całkowitą" tylko wynik dzielisz przez 100 skoro wcześniej lewą stronę mnożyłeś przez 100

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

Tak, tak to już wiem.

Jasne, dzielenie bądź sformatowanie już do finalnego wyświetlenia to wiem, chodziło mi o odejmowanie liczby która była we wzorcu jako ułamkowa i przez mnożenie doprowadzona do liczby całkowitej, co by bez żadnych ceregieli użyć do tego działania matematycznego.

_________________
Migracja z punktu B do punktu C
Pozdrawiam

no dokładnie - wprawdzie trzeba z tym się pobawić czyli kilka linijek kodu napisać ... ale

.... ale jak się skońpiluje cały kod to okazuje się że w procku zostanie cały hektar miejsca we flashu w porównaniu do sytuacji gdy męczyliśmy floaty ... nie wspominając o dużo szybszej realizacji działań gdyby to się gdzieś tam okazało istotne

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

Witam serdecznie,
Temat stary, ale pasuje do problemu.
Poniżej moja funkcja:


Służy ona do przeliczania wartości z przetwornika ADC na rezystancję PT100. Funkcja zwraca wynik w postaci 10882 gdzie "108" to część całkowita wartości rezystancji, a "82" to ułamkowa. I tak ma działać.
1. Zastanawia mnie dlaczego rzutowanie stałej na typ unsigned long long int (100ULL) pożera 4336 bajtów FLASH i 256 bajtów RAM ?
2. W jaki sposób napisać tę funkcję inaczej, aby uzyskać pożądany rezultat i nie zajmować tyle pamięci i oczywiście nie używać float ?

P.S.
1. Celowo używam długich nazw typów bo tak mi wygodniej.
2. Jako argument funkcji świadomie pobieram tylko 16 bitów wartości z ADC.

pozdrawiam
wjeszak

Czy na poniższym programie testowym też masz takie wyniki?

_________________
Dragonus Cracovus: Biomagia

Hmm. Nie rozumiem. W Twoim kodzie jest tylko wywołanie mojej funkcji. Dlaczego rzutowanie na unsigned long long int zajmuje tak dużo flasha ?

Wydaje mi się, że ta zajętość wynika z tego, że cała operacja (nie jawne rzutowanie?)

wykonywana jest na 64-bitowych liczbach (8 bajtów na każdą zmienną i liczbę i wynik), czyli masz już 40 bajtów. Do tego dochodzi zapotrzebowanie na wyniki pośrednie dla każdego mnożenia, dzielenia i odejmowania. Poza tym same operacje na liczbach 64-bitowych też wymagają odpowiedniego "oprogramowania", gdyż trzeba to zrobić przy pomocy poleceń 8-bitowych (chyba taki masz mikrokontroler). Nic więc dziwnego, że mnożenie 64-bitowe, dzielenie 64-bitowe i odejmowanie 64-bitowe może "pożreć" tyle zasobów. Do tego dochodzi jeszcze ustawienie kompilatora (optymalizacja np. na szybkie działanie, a nie na małą zajętość pamięci). Takie są moje domysły

_________________
40-32:2=4!

W kodzie testowym mam 630 B flash. Żeby cokolwiek porównywać potrzebny jest kod który można skompilować i który operuje na zmiennych wartościach. Dlatego takie coś zaproponowałem.

_________________
Dragonus Cracovus: Biomagia

Witam,
Musiałem chwilowo odłożyć temat. Zużycie flash o którym wcześniej pisałem było spowodowane starą wersją kompilatora (4.3.3). Po przesiadce na 4.9.2 objętość flash zmalała ok. 5 razy, a ilość cykli ok. 6 razy. Kosmos. To tak na przyszłość jakby ktoś rwał włosy z głowy.

wjeszak