marcing pisze:Pozostałbym jednak przy "okrągłej" wartości 10MHz - będzie można w miarę łatwo wyliczyć czas wykonywania poszczególnych elementów programu, oraz potrzebny dla działania ADC...
Racja. Cenna uwaga
[ Dodano: 2007-05-23, 11:34 ]
marcing pisze:Czas konwersji przy dziesięciobitowej dokładności może zająć do 260us (czas maksymalny), taktowanie przetwornika przy takiej dokładności nie powinno być wyższe niż 200kHz.
Pierwsza konwersja po przełączeniu źródła zajmuje 25 cykli zegara ADC (125us przy 200kHz).
Piszesz, że potrzeba kilkuset próbek z kilku kanałów... Przy ośmiu kanałach potrzeba ok. 2,5ms na odebranie danych ze wszystkich wejść, dodać należy oczywiście czas na obsłużenie każdego z nich oraz przełączenie kanału. Przyjmując, że procesor taktowany jest z zegarem 10MHz, pojedyńcza instrukcja trwa 100ns - można więc przyjąć, że potrzebne będzie ok. 2,5us na kanał...
Czyli mamy 3ms - czyli można spokojnie sprawdzać stan wejść kilkusetkrotnie w ciągu sekundy...
Oczywiście - mogłem się pomylić w obliczeniach, ale i tak przyjąłem pewien zapas...
Ostateczny wniosek wydał się rewelacyjny, okazało się jednak, że wąskim gardłem okazała się sama transmisja po RS232. Ale problem i tak jest co najmniej dziwny.
System uruchomiłem na Atmega16 taktowanym zewnętrznym kwarcem 16MHz. Szybkość transmisji ustawiłem na 38400 baud, z względu na minimalny błąd BAUD error w listingu pokompilacyjnym programu Bascom AVR.
Tak na oko 19200 baud to w przybliżeniu 1500 znaków na sekundę. Ponieważ za jednym razem przesyłane są 32 znaki, więc taki ciąg dałoby się przesłać spokojnie nawet 50 razy w ciągu sekundy. A ja mam prędkość nawet 38400 baud!
Tymczasem w praktyce maksymalny osiąg to... 5 razy w ciągu sekundy.
Aplikacja PC wysyła rozkaz TX do urządzenia, urządzenie odsyła zmierzone wartości w postaci ciągu:
dana1:dana2:dana3:dana4:dana5:dana6:dana7:dana8
za pomocą Bascomowej instrukcji Print.
Maksymalna szybkość jaką udaje mi się osiągnąć przy Atega16 i kwarcu 16MHz to około 5Hz. Aplikacja posiada suwak, którą mogę ustawić szybkość pobierania danych z urządzenia. Urządzenie wysyła komendę TX w interwale jaki ustawiam za pomocą suwaka, a następnie szybko odczytuje bufor RS232 i przekazuje dane do zmiennych.
W aplikacji zrobiłem okienko logowania dzięki któremu mogę obserwować cały odbierany string (dana1:dana2:dana3:dana4:dana5:dana6:dana7:dana8)
I widzę, że przy zwiększaniu szybkości powyżej 5Hz string urywa się po 4 czy piątej danej.
Można to
zobaczyć na filmie (ostatnie sekundy - w okienku logowania)
Film można pobrać spod adresu: http://rapidshare.com/files/32895888/clip0010.avi.html
Widać - urządzenie nie zdążyło jeszcze wysłać wszystkich danych.
To jest przykładowy string wysłany od urządzenia do PC:
łącznie 32 znaki, wysłane za pomocą komendy
print
a dokładniej kodu:
Kod: Zaznacz cały
Print Zmienna1 ;
Print ":" ;
Print Zmienna2 ;
Print ":" ;
Print Zmienna3 ;
Print ":" ;
Print Zmienna4 ;
Print ":" ;
Print Zmienna5 ;
Print ":" ;
Print Zmienna6 ;
Print ":" ;
Print Zmienna7 ;
Print ":" ;
Print Zmienna8 ;
Ot cały skomplikowany algorytm.
Najpierw urządzenie czeka na komendę (Input Komenda) a po odebraniu właściwej komendy (słowa
TX wysyła printami 8 danych.
Dlaczego maksymalny osiąg do 5Hz, skoro z moich wstępnych obliczeń wynika, że powinno być z 10 razy tyle?
