Teraz gdy trafiłem tu na ten post kolegi @Intre, to znalazłem wiele podobieństw jakie stworzyłem w stosunku do kodu tu zaprezentowanego. Nie mniej jednak kilka moich spostrzeżeń i sugestii napiszę, bo może rozwieją one wszelkie wątpliwości i będą komuś pomocne.
I tak, faktycznie jak słusznie zauważył kolega @jkarczew, jeśli korzystamy z funkcji lcd_int(),to faktycznie mogą się "minusy" pojawić, bo dla tej funkcji my mamy liczbę 16-bitową ze znakiem czyli operujemy za zakresie -32768 - 32767, a w rejestrze tegoż układu dane są w zakresie int bez znaku czyli 0 - 65535. Ja się identycznie jak ty @Intre natknąłem na "minusy" bo w UART'cie wyświetlić chciałem dane, za pomocą funkcji z BB uart_putint(). Wystarczyło użycie funkcji dla long i nie ma już z tym problemu.
Kolejna sprawa, to zauważyłem że jak liczysz wartość lux_light, to wystarczy ci typ uint16_t do tego celu, pozostałe działania robisz poprawnie, mam na myśli "sklejenie" dwóch bajtów: lux_light = (light_buf[0]<<8) + light_buf[1];. Pozostałe przeliczenia które tu podałeś na wartość LUX są także zgodne z tym co podano w nocie. Tu dodam, że jeśli nie potrzebujesz tej wartości LUX gdzieś wyświetlić lub zapisać, to nie ma sensu robić tych przeliczeń, do sterowania np. natężeniem świecenia LED'ów wystarczy jak porównasz lub porobisz sobie przedziały "surowych" wartości z rejestrów układu.
Teraz jeszcze jedno, bo nie mam pewności, ale w DS tego sensora, jeśli dobrze zrozumiałem, to nie potrzeba na samym starcie wydawać polecenia BH1750_POWER_ON, gdyż ten robi to automatycznie po wydaniu któregokolwiek rozkazu pomiaru, także w przypadku tego modułu funkcja BH1750_init(); jest wg. mnie zbędna. W każdym razie mi działa pomiar bez żadnej inicjalizacji. Oczywiście niczemu ona też nie szkodzi (tak mi się wydaje), także zasadność jej używania uznaję jako kwestię dowolną
Ostatnia już sprawa, to czas oczekiwania na wykonanie pomiaru po wydaniu rozkazu. Może on być w zależności od wybranego trybu i rozdzielczości w przedziale od 16-120ms. U Ciebie @Intre nie widzę takiego opóźnienia, czego nie uważam oczywiście za błąd, bo masz przecież to zrealizowane poprzez cykliczne odczyty w timerze programowym, ale zwracam na to uwagę, że pierwszy twój pomiar po podaniu zasilania do układu zwróci 0, a kolejny pomiar da rezultat z poprzedniego rozkazu pomiarowego, także niejako masz rezultat z poprzedniego cyklu pomiaru. Ja u siebie użyłem paskudnego _delay_ms(120) w procedurze BH1750_read(); i oczywiście zamierzam to w docelowych projektach oprzeć także o timer programowy, tak aby nie wprowadzać sobie żadnych dodatkowych opóźnień blokujących.
Mam nadzieję, że moje skromne uwagi do czegoś się przydadzą, a w razie pytań lub wątpliwości chętnie odpowiem w oparciu o swoją wiedzę i nabyte w tym zakresie doświadczenie.
Statystyki: Napisane przez matw — 17 sie 2014, o 20:59
]]>
