logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Realizacji transmisji sygnału z sensora S9132 - mikrokontr.

cezary1986 16 Lip 2009 21:41 3096 9
  • #1 6787354
    cezary1986
    Poziom 10  
    witam,
    Potrzebuje pomocy przy realizacji transmisji sygnału z sensora S9132 (http://sales.hamamatsu.com/assets/pdf/parts_S/S9132.pdf) do komputera za pośrednictwem rs232. Układ generuje 2 sygnały, po 256B każdy. Czy możliwe jest przesłanie tych sygnałów do PC bezpośrednio przez rs232, czy potrzebne jest zastosowanie mikrokontrolera, który "połączy" te sygnały i dopiero wtedy z jego wyjścia będzie możliwa transmisja przez rs232?
    Czarek
  • #2 6804079
    Father
    Poziom 26  
    Bezpośrednio się nie da... potrzebny jest mikrokontroler, żeby wysłać dane z sensora przez UART do PC...
  • #3 6805436
    Genos182
    Poziom 13  
    Oprócz tego przydałoby się wyjście UART mikrokontrolera podłączyć do układu MAX232, a z tego układu do PC-ta ze względu na różne poziomy napięć.
  • #4 6807891
    cezary1986
    Poziom 10  
    moglibyście polecić mi mikrokontroler za pomocą którego mógłbym "połączyć" ten sensor z PC?
    Jeżeli chodzi o sygnał z sensora do miktokontrolera, to jak już pisałem wyżej, są to 2 sygnały, każdy po ok. 256B.
    Realizacji transmisji sygnału z sensora S9132 - mikrokontr.
    Natomiast sygnał z mikrokontrolera do PC chciałbym ograniczyć jedynie do współrzędnych z matrycy (tylko maksymalne wartości), to z racji niewielkich prędkości jakie oferuje UART.
    Realizacji transmisji sygnału z sensora S9132 - mikrokontr.
    Kluczową sprawą jest jak najmniejszy rozmiar mikrokontrolera i jak najmniejsza (zerowa?) liczba innych elementów.
  • Pomocny post
    #5 6808351
    Genos182
    Poziom 13  
    Wiesz, wszystko zależy od tego jaką częstotliwość będzie miał sygnał CLK oraz ST z datasheeta. CLK może się wahać z tego co widzę od 500 Hz do nawet 10 MHz. Jeżeli byś taktował detektor odpowiednio wolnym sygnałem to wyślesz do procesora wszystkie próbki, ale jeżeli CLK ma być większe, wtedy rzeczywiście trzeba coś kombinować. Generalnie w datasheecie jest przykładowy układ, który zbiera próbki oparty o procesor i rejestry przesuwające. Jeżeli byś chciał uprościć układ to możesz zrezygnować z rejestrów przesuwających ale to trochę obciąży procesor, ze względu na większą liczbę przerwań. Tak naprawdę do tego zadania może się nadać każdy mikrokontroler jeżeli wymagania nie będą wysublimowane, najlepiej ten który już znasz, ale może to być np 8-bitowa Atmega8 (28 wyprowadzeń). Pewnie da się znaleźć jeszcze mniejszy. Ja bym pewnie wybrał ARMa Atmela, bo akurat go znam i ma JTAG, tyle że on ma już 64 nóżki.
    Tak naprawde ciężko coś powiedzieć nie znając f dla CLK i ST:)
  • #6 6825800
    cezary1986
    Poziom 10  
    Aby osiągnąć wymagane skanowanie 200Hz muszę taktować sensor sygnałem o częstotliwości 650-700kHz, sygnał ten, a właściwie dwa takie identyczne wyprowadzę z atmegi8L (w obudowie TQFP, 32 wyprowadzenia, z racji małych rozmiarów). Będę się starał zrezygnować z rejestrów przesuwających z przykładowej aplikacji (74HC164), nie chodzi mi szczególnie o wartości które będą niosły poszczególne Bajty a o ich kolejny numer (detekcja punktu). Mam tylko nadzieje, że 8kB pamięci atmegi pomieści algorytm, który jednocześnie będzie sterował sensorem, odbierał i obrabiał dane, a potem przekazywał je dalej po UART
  • #7 6825979
    Genos182
    Poziom 13  
    Witam,

    Jeżeli chcesz aby CLK było koło 700 kHz, to ja bym te rejestry przesuwające dodał :) Bez tych rejestrów to by oznaczało, że musisz zgłaszać przerwania bardzo często. Przy częstotliwości max dla przykladowego atmela8 wynoszacej 16 MHz, to byś miał około 22 cykli na obsłużenie przerwania. To troche mało. Dla świętego spokoju ja bym dołożył te dwa rejestry.
  • #8 7415426
    jhusak
    Poziom 13  
    Kolega cezary1986 myślał o rozwiązaniu bardziej hakerskim, tzn. atmegą wystawiam clk a następnie czytam bit, a nie generator clocków i wykorzystanie przerwań - bo to nie zadziała. W podejściu tym (hakerskim) można w pełni wykorzystać moc procesora, oraz taktowanie ze zmienną prędkością. Ja bym to zrobił tak: wystawiam odp. clk, czytam bit np na PIND0, przesuwam w lewo i tak 8 razy. Teraz testuję wartość - wyliczam max, bądź max funkcji interpolowanej z 3 najmocniej oświetlanych punktów (to jest ciekawsze i dokładniejsze, pozwala osiągać podpixelową rozdzielczość;) i mam pozycję spota. Czasu na 1 bit jest duużo. Spokojnie można przetworzyć 1 milion bitów na sekundę, czyli 1000000/12/512 ramek czyli te ok. 200 ramek na sekundę. Nawet w C, acz przy zegarze procka 20 MHz, czyli 20 cykli na bit (wystarczy: ust. linii clk, odczyt bitu, ustawienie go w rejestrze danych,zerowanie linii clk, przesunięcie rejestru, i tak 8 razy. Razem 5 cykli na bit, i to jest chyba minimum. Jeśli się pomyliłem to o 1-2 cykle. czyli można się pokusić o 500 Hz detekcję)
  • #9 7831642
    jhusak
    Poziom 13  
    cezary1986 napisał:
    Aby osiągnąć wymagane skanowanie 200Hz muszę taktować sensor sygnałem o częstotliwości 650-700kHz, sygnał ten, a właściwie dwa takie identyczne wyprowadzę z atmegi8L (w obudowie TQFP, 32 wyprowadzenia, z racji małych rozmiarów). Będę się starał zrezygnować z rejestrów przesuwających z przykładowej aplikacji (74HC164), nie chodzi mi szczególnie o wartości które będą niosły poszczególne Bajty a o ich kolejny numer (detekcja punktu). Mam tylko nadzieje, że 8kB pamięci atmegi pomieści algorytm, który jednocześnie będzie sterował sensorem, odbierał i obrabiał dane, a potem przekazywał je dalej po UART


    Pomieścił:)
    Podłączyłem atmegę do tego S9132. Wraz z obsługą wyświetlacza s65 i wyświetlaniem na nim tego, co widać w detektorze, przy częstotliwości kwarcu 20 MHz, kod w avrgcc, mam ok. 100 HZ odświeżanie, kod 3 kB. Podłączenie BEZPOŚREDNIE do atmegi, bez żadnych rejestrów przesuwających, niczego.

    Procesor generuje takt i w trakcie bada odpowiedź układu. Żadnych przerwań, cudów (przykładowa aplikacja z datasheetu jest w tym przypadku bez sensu rozbudowana)

    Nadmieniam też, że można czytać obie współrzędne na raz - a właściwie nie da się ich odczytać oddzielnie - bo to będzie już następna próbka.

    Układ S9132 jest trochę dziwny - wymaga DOKŁADNEGO taktowania - trzeba dokładnie czytać dokumentację, która jest nieco lakoniczna. Nie jestem przyzwyczajony do takich rozwiązań - mimo, że wszystko działało jak trzeba od strony hardware, to software musiał być bardzo dokładnie staktowany - pomylisz się o 1 cykl, i już nic nie działa.

    Poza tym jedna ze współrzędnych ma minimalnie niższą czułość. Ponadto tryb 10 bitów nie za bardzo mi chciał dokładnie działać. Może go jeszcze stestuję, jak już na 8 bitach wszystko hula.

    No i przylutować to draństwo - niczym się nie da ładnie, chyba że hotairem i pastą cynową. Ja lutowałem lutownicą o średnicy grota 1 milimetr z hakiem, i się trochę namęczyłem.

    Generalnie jestem zadowolony. Aktualna cena układu w Elfa to 115 zł; trzeba zamówić, a następnie po kilku dniach przyjechać i odebrać.
    Nie jest to reklama, a wskazówka, gdzie można nabyć ten układ.
  • #10 7996660
    jhusak
    Poziom 13  
    Po wielu testach wychodzi, że z błędem poniżej jednego bitu można zrobić oversampling odczytu 16x, otrzymując rozdzielczość 2048x2048.

    Trochę zabawy z tym było, ale się dało nawet 64x, ale szumi to już właśnie gdzieś na bicie - dwóch. No i jakość takiego oversamplingu zależna od siły sygnału, wielkości plamki (optymalna to ok. 10-20 um). Używam obiektywu do kamerek video. 106 stopni dla 1/4" przetwornika daje w tym przypadku ok. 45 stopni.

    Ważny jest też filtr podczerwony.
REKLAMA