Witam wszystkich serdecznie:)

Od dłuższego czasu pracuję nad prototypem elektronicznego stetoskopu, który dokonuje akwizycję danych pomiariwych na karcie SD.
W związku z tym, że interesujące mnie pasmo dochodzi do 500Hz, częstotliwość próbkowania jaką muszę uzyska to minimum 1kHz.Wykorzystuję Atmegę 328p.Prcuję zatem nad biblioteką FatFS i odpowiednim systemem buforowania próbek pochodzących z ADC. Póki co staram się zaimplementować1 bufor lecz w domyśle, ostatecznie planuję zastosować 2 bufory. Bardzo proszę o zweryfikowanie mojej koncepcji. Zdefiniowałem sobie funkcję, która zwraca ilość cyfr podanych jako argumet i zastosowałem ją w obsłudze przerwania, aby przesunąć wskaźnik o odpowiednią ilość miejsc w moim buforze.Doszedłem bowiem do wniosku, że biblioteczna funkcja itoa (wykorzystywana w celu skonwertowania danych z ADC do stringa) nie zwraca wskaźnika do ostatniego miejsca w tablicy, do której wpisuje pomiary. Wydaje mi się jednak, że stosowanie funkcji operującej na stringach w przerwaniu może nie być dobrym pomysłem.W obsłudze przerwania zewnętrznego dokonuję prymitywnego multipleksowania kanału ADC, ponieważ projekt zakłada podawanie na analogowy filtr przestrajany częstotliwością fali prostokątnej generowanej w trybie CTC. Wartość podawana z potencjometrudeterminuje zatem cutoff filtra dolnoprzepustowego. Nie wiem również jakiej wielkości bufor zastosować, żeby nie zaśmiecić zbytnio pamięci RAM. W trybie podawania częstotliwości odcięcia przetwornik działa poprawnie. Natomiast w trybie zapisu danych na SD na wyświetlaczu LCD widoczne są zmienne wartości. Natomiast na karcie w tym czasie zapisuje się w zasadzie stała wartość, ok 380. Przetwornik jest skonfigurowany w trybie free running mode. Dane chcę zapisywać w postaci kolumny, żeby móc sobie wygenerować od razu plik .csv. Mam też wątpliwości co do samego działania zapisu w momencie wywołania przerwania od ADC. Wydaje mi się, że czas obsługi tego przerwania powinien być krótszy niż sama procedura zapisu na SD. Zatem czy takie wywołanie się przerwania w trakcie zapisu nie powoduje, że zapis jest w pewien sposób zaburzony? Kolejne pytanie dotyczy możliwości tracenia próbekz ADC. Czy zastosowanie 2 buforów rozwiązuje ten problem? Jeśli tak, to jak mniej więcej zabrać się za ich implementację? Przepraszam za dużą ilość zakomentowanych linii i ewentualną nieczytelność ale to jest bardzo robocza wersja kodu. Jeśli coś wymaga dokładniejszego wyjaśnienia to oczywiście postaram się sprecyzować o co chodzi. Będę bardzo wdzięczy za wszelkie sugestie i pomoc.

Pozdrawiam:)





Kody źródłowe umieszczamy w znacznikach synax=c, bez odbioru! //kila

dobrze, poprawiłem znaczniki kodu, mam nadzieję, że teraz ktoś się odezwie:)

Nie wiem jak pewne rzeczy są w libsie Elm-Chana zrealizowane, ale operując na niższej warstwie (tzn. bezpośrednio na sektorach karty) zrealizowałbym zapis tworząc w RAMie AVRa bufor FIFO z którego dane są ściągane (zapisywane na kartę) po przekroczeniu rozmiaru sektora.

Pewnie nie masz takich możliwości, więc zrób sobie bufor FIFO do przechowywania wartości dwójkowo, a konwersji na stringa i zapisu dokonuj dopiero po przekroczeniu jakiegoś poziomu zajętości bufora.

Swoją drogą, to jeżeli zaimplementujesz obsługę karty w odpowiedni sposób, to możesz sobie wysyłać bit po bicie z dowolnie długimi przerwami między nimi

_________________
Nie pisz komentarzy - dobry kod komentuje się sam.

Dzięki za odpowiedź

czyli sugerujesz, żeby jednak dane z bufora konwertować na string w pętli głównej po przekroczeniu jakiegoś poziomu zajętości? konwersja pojedynczej wartości za pomocą funkcji itoa jest stosunkowo prosta. ale jakie podejście przyjąć przy całej tablicy liczb? zastosować do tego pętlę for? czy wtedy konwersja tak dużej ilości danych nie spowolni samej procedury zapisu? jak zatem wyznaczyć poziom zajętości bufora? czekać do jego całkowitego wypełnienia? jakiej wielkości bufor pozwoli na uzyskanie jak największej częstotliwości próbkowania. czytałem, że zapis do karty SD odbywa się całymi sektorami po 512 Mbajtów. czy z tego wynika, taką wielkość powinno się stosować?

Tak czy siak musisz tą konwersję wykonać, a nie widzę powodu dla którego musiałaby się odbywać w przerwaniu (przechowywanie wartości w stringu zwiększa jedynie zajętość pamięci; konwersja w przerwaniu wydłuża je, mogąc powodować przerwanie jakiejś ważnej operacji w głównej pętli na zbyt długo - konwertując poza przerwaniem masz możliwość kontroli tego).
Temat przecież powstał między innymi dlatego, że nowe dane nadlatują Ci zanim zwolnisz dla nich miejsce... bufor musi mieć więc rozmiar (co najmniej) zapisywanej paczki + rozmiar danych które nadlecą podczas zapisywania tejże paczki.
Na AVRach jest to bez znaczenia. Znaczenie za to ma sposób w jaki go oprogramujesz.
Nie Mbajtów, a bajtów. I nie 512, a co najmniej 512. Warto to stosować, o ile jesteś w stanie zapewnić, że zapisywane dane o wielkości sektora nie będą rozłożone pomiędzy 2 sektorami.

_________________
Nie pisz komentarzy - dobry kod komentuje się sam.