Ostatnio zacząłem usilnie pracować z przyjemnym PetitFS'em w celu osiągnięcia możliwości stworzenia datalogera. Chodziło o urządzenie do pomirau temperatury z czujników typu DS18B20 lub innych i zapis na kartę pamięci SD. Wziąłem więc w ręce procesorek ATmega32, podłączyłem kartę pamięci, dwa czujniki DS18B20 (do dowolnego pinu procka) no i napisałem kawałek programu. Generalnie, do procesora podłączony jest jeszcze przez standardową i sprzętową magistralę I2C układ RTC typu PCF8583, który odmierza czas pomiarów ale też właśnie ten czas zapisywany jest na karcie. Co ciekawe układ radzi sobie z zapisem do sporych plików całkiem nieźle. Jest pewna wada tego rozwiązania, otóż nie mogę dokonywać zapisu częściej niż co kilka sekund. A jeśli plik jest bardzo duży (wiele megabajtów) i następują zapisy pod koniec pliku to czas ten wydłuża się nawet do np 8 sekund. Ale to zależy jeszcze od samej karty pamięci. Oczywiście obsługiwane są wszystkie rodzaje kart od zwykłych aż po najnowsze i najszybsze SDHC itp
poniżej schemat poglądowy bez czujników temperatury i RTC
całość odpalam na zestawie uruchomieniowym ATB, który pracuje sobie nocami i dniami pięknie - dokonując zapisów na karcie. Zapis przygotowuję sobie jak w pliku CSV, czyli dane rozdzielone średnikami:
Dzięki czemu taki plik można sobie od razu w Excelu ładnie otworzyć i jeszcze z automatu wykresy generować ;) Poniżej przykład badań temperatury z całej doby. Pomiary co ok 4 sekundy.
Przy założeniu że akurat tutaj generuję sobie pojedynczy rekord (jedną linię) o maksymalnej długości 25 znaków - wliczając znaki CRLF, i przy założeniu, że pomiar będzie robiony przez 31 dni (miesiąc) z rozdzielczością co 30 sekund !!!! to wychodzi, że będzie mi potrzebny plik o wielkości zaledwie 2,13MB !!!! czyli mały pikuś ;)
A gdybym chciał np taki sam rekord zapisywać przez 366 dni w roku co 1 minutę to pliczek wyjdzie mi jedynie 12,57MB - co za problem ? ;)
Cały program napisany jest w języku C dla AVR. Źródeł nie będę przynajmniej na razie udostępniał bo mam w nich jeszcze niezły bałagan - no ale urządzenie już w pełni działa jak widać. Czyli jak widać można ładnie zapisywać do plików i to dużych i dużo danych za pomocą małego Petit'ka .... fakt są pewne ograniczenia ale czy każdy loger potrzebuje zapisywać dane co sekundę albo i częściej ? pewnie tak - jednak jest sporo logerów, które działają o wiele wiele wolniej ;)
Użyta tutaj przeze mnie karta pamięci ma pojemność 8GB.
A ja od dawna myślę o takim loggerze. Zastanawiałem się nawet nad zapisem w postaci RAW, a nie z wykorzystaniem systemu plików. Tylko wtedy tak prosto nie da się wyciągnąć karty i przeczytać na PC
OdpowiedzUsuńMirek
No a właśnie mi przyświecał główny cel jakim jest możliwość wyciągnięcia w dowolnym momencie karty i wsadzenia do komputera i odczytu pliku *.CSV od razu nawet w Excelu ;) .... w końcu jak się będzie robić takie urządzonko dla jakiegoś klienta to ciężko mu byłoby tłumaczyć, że inaczej się nie da, że musi mieć jeszcze jakąś dodatkową aplikację, że musi jeszcze wykonać szereg czynności i nauczyć się ich aby na końcu dopiero odzyskać mierzone dane.... Tyle że jak mówię, zrobić to najspokojniej w świecie bez żadnych ograniczeń można z uzyciem FatFS .... ale mnie interesowało, żeby pomęczyć się i wyciągnąć także takie możliwości z małego i poograniczanego mocno Petit'ka. Wkrótce każdy będzie mógł przeczytać dokładnie jak to zrobiłem i wypróbować sam taki kod źródłowy ;)
OdpowiedzUsuńWkrótce?
OdpowiedzUsuńCzy udostępni Pan kod źródłowy obsługi modułu RFM70?
Skoro jest nieuporządkowany to pomogę go uporządkować.
Mnie nawet nieuporządkowany pasuje, byle działający.
Pozdrawiam
Witam
OdpowiedzUsuńCzy byłaby możliwość pokazania kawałka kodu albo przynajmniej opisania jak wykrywasz ostatnia linie w pliku, czyli mam otwarty plik, sformatowany string do zapisu w nim i chcę dopisac do końca pliku np. po utracie zasilania.
Chce to wykonać na fatfs co prawda ale to wg. mnie bez różnicy chodzi mi tylko o naprowadzenie.
Przygotowuję spory materiał na ten temat z którym każdy będzie się mógł wkrótce zapoznać. Zagadnienie związane z wykrywaniem jak piszesz ostatniej linii w pliku jest hmm dosyć złożone i ciężko byłoby mi to teraz tutaj opisać w dwóch zdaniach a tym bardziej poprzeć to jakimś kawałkiem kodu. Za to mogę z pełną odpowiedzialnością powiedzieć, że wbrew temu co przypuszczasz istnieje nawet nie ogromna ale gigantyczna różnica w zależności od zastosowania do tego celu PetiFS lub FatFS. W tym drugim przypadku można powiedzieć, że nie ma żadnego problemu i jeśli próbujesz to robić w oparciu o FatFS to nawet nie wiem czego dotyczy twoje pytanie, ponieważ stosując FatFS w ogóle nie obchodzi nas jakieś wykrywanie ostatniej linii - po co? Tu zadanie jest uproszczone do maksimum ponieważ mamy możliwość dopisania danych do pliku i powiększenia jego rozmiaru a w PetitFS nawet pomarzyć o tym nie można - więc skąd takie porównanie i przypuszczenie że to bez różnicy czy próbujesz dokonać zapisu w oparciu o jedną albo drugą bibliotekę ?
UsuńMuszę przyznać że to dość toporna przypadłość jeśli plik jest coraz większy to wtedy zapis do niego się wydłuża. I chciałem dodać jeszcze że to nie wina wolnej karty czy komunikacji z nią, najprawdopodobniej ten petit był napisany pod potrzebę jednego projektu i tym sposobem teraz powielane są błędy. Mogę się mylić, ale trochę programowałem i mniej więcej wiem jak operować po prostej tablicy FAT16 czy 32... W przyszłości jak zbuduje swój komputerek na Atmega128 to zmierzę się na żywca z SD i pewnie uzupełnię swoją wiedzę na ten temat. Tak swoją drogą to podziwiam Cię za Twoją wytrwałość w dzieleniu się informacją, mi zawsze brakło na to czasu oraz talentu do przekazu sensownej wiedzy.
OdpowiedzUsuńPewnie, że PetitFS nie był do tego przeznaczony i pisany z takim nastawieniem aby zapisywać duże ilości danych do pliku. To jest oczywiste ;) Wystarczy spojrzeć na funckję zapisu do jednego tylko sektora, którą tak normalnie on umożliwia. Trzeba by to napisać całkiem inaczej ... ale autorowi Petit'a nie zależało z założenia na zapisie TYLKO ODCZYCIE i niewielkiej ilości kodu po kompilacji co udało się z dużym powodzeniem osiągnąć. Jak ktoś chce sobie używać zapisu w wygodny, pewny i nie taki sztuczny sposób to po prostu może wziąć inną bibliotekę tego samego autora czyli FatFS. Nie będzie żadnych takich problemów o któryc ja tutaj piszę.
OdpowiedzUsuńO co więc tak na prawdę chodzi - otóż postanowiłem wymyślić taką powiedzmy PROTEZĘ do tego Petit'ka ..... która pomimo nawet sporych ograniczeń pozwoliłaby jednak na zapis większej ilości danych - czyli coś czego chyba (jak mi się wydaje) nikt się nie podjął bo uważał to za bezcelowe i szybko przesiadał się na FatFS. Tymczasem ja uważam, że pomimo takich ograniczeń, które wynikają z korzystania z tej PROTEZY i tak z ogromnym powodzeniem można użyć tego sposobu do wielu różnych projektów nadal korzystając z olbrzymiej ZALETY Petit'ka czyli niewielkiej zajętości kodu.
Jeszcze raz podkreślę - jeśli robię dataloger, który ma jakiś czy jakieś parametry zapisywać nawet nie co kilka minut a co kilka godzin - to po jasny gwincik mi jakiś szybki zapis do pliku - no po co ? ;) .... Jak potrzebny to sięgam po FatFS'a i już. A jak nie - i zależy mi na maleńkim procku to po Petitk'a z tą właśnie dorobioną przeze mnie funkcjonalnością w postaci protezy.
Dlaczego tak wolno to działa i ma takie ograniczenia ? tu za mało mam możliwości żeby to opisać ale w drugiej części mojej książki poświęcę temu pewien rozdział i każdy zobaczy w szczegółach o co chodzi.
Reasumując - można być dobrym programistą jak piszesz, i można napisać drugi FatFS po swojemu - no można - więc napisz - tylko czy zawsze warto wyważać głową mur ? gdy obok są drzwi ? i to otwarte ? Wystarczy nacisnąć klamkę albo znaleźć jeszcze inne wejście (wyjście - co ja poczyniłem)
Aha i dodam, że ta przypadłość o której piszesz wcale nie wynika z Petit'ka tylko ze sposobu jaki ja obrałem do nietypowego wykorzystania go do takich celów. A dodam że jest jeszcze inny i można byłoby to znacznie przyśpieszyć ale wymagane byłoby tworzenie dodatkowego maleńkiego pliku za każdym razem gdy rozpoczynam zapis do jakiegoś wybranego pliku. To inna mała wada ... jak widać ja wybrałem ten pierwszy sposób - opisując jednak jak można podejść jeszcze inaczej.
OdpowiedzUsuńPanie Mirku, udostępni Pan źródłowy. Piszę projekt z Atmegą, i mam problem z obsługą karty SD. Po prostu nie wiem jak się za to zabrać. Z góry dziękuje, i pozdrawiam
OdpowiedzUsuńAleż WSZYSTKO jest udostępnione, pełne kody źródłowe i nie tylko - do tego bogate komentarze, kilka różnych przykładów no i obszerny opis w oddzielnych rozdziałach w tej książce, polecam:
Usuńhttp://atnel.pl/jezyk-c-pasja-programowania.html
proszę rzucić okiem na spis treści na tej stronie oraz wybrane fragmenty w PDF
Odkupię program do zapisu na SD. Sprawa naprawdę bardzo pilna!
UsuńPozdrawiam
Ależ nie trzeba nic odkupować - wystarczy zakupić książkę
Usuńhttp://atnel.pl/jezyk-c-pasja-programowania.html
przecież w niej wszystko masz
Na płycie też są już gotowe kody źródłowe?
UsuńWitam,
OdpowiedzUsuńpanie Mirku czy kod źródłowy do tego jest gdzieś dostępny ????
Ba nie tylko udostępnione ale jeszcze opisane w detalach, wyjaśnione - no sporo tego jest - wszystko tutaj: http://atnel.pl/jezyk-c-pasja-programowania.html
UsuńPanie Mirku, czy w tym przypadku połączenie między Atmega a kartą wyglądało tak jak na schemacie? Jaką prędkością była taktowana Atmega?
OdpowiedzUsuńA jakie to ma znaczenie ? ŻADNE - może być taktowana DOWOLNĄ częstotliwością
Usuń