Napisałem sobie program który po wykrytym przerwaniu zapala diode led.
Kod: C / C++
Zaloguj się, aby zobaczyć kod
Problem w tym że przerwanie wywołuje się podczas zwarcia z vcc oraz po odłączeniu. Przerwanie reaguje na zbocze narastające i opadające. A ja chciał bym tylko na jedno z wyżej wymienionych. Z góry dziękuje za odp.
Program reaguje zapewne wyłącznie na zbocze opadające tak jak chcesz, lecz zwierając przewody dochodzi do drgań, w efekcie masz mieszankę zboczy opadających i narastających.
No ale ja pytam o to co zmienić w kodzie żeby zbocze narastające generowało przerwanie po pisze kod pod obsługę kamery ov7670 i podczas zbocza narastającego będe pobierał dane. Problem przycisku już został mi wyjaśniony i nie stanowi problemu.
Do tej kamery to proponuję wziąć inny kontroler Czytałeś ds do tej kamery? Czytałeś ds i manual do xmegi? Gdybyś czytał, to nie pytałbyś co wpisać, aby układ reagował na zbocze narastające. Nie wiem jak chcesz rozwiązać problem zbyt szybkiego zegara kamery (24MHz) względem możliwości xmegi, (16MHz) ale nawet jeżeli poradzisz sobie z odbiorem danych, to gdzie chcesz je zmieścić mając do dyspozycji 16kB ram i kiedy chcesz to obrabiać, ew. gdzieś dalej wysyłać? Licząc bardzo szybko, xmega będzie zajęta na 160% samym tylko odbiorem danych z kamery.
Swoją drogą, kiedyś pytałeś o sygnały synchronizacji dla wyświetlacza TFT. Wiesz już jak to działa?
Niekoniecznie będzie to 160%, gdyż wg noty zegar wynosi min. 10 MHz, czyli 16 MHz, które można łatwo uzyskać (24 MHz zresztą też), zadziała. Oczywiście o jakimś sensownym przetwarzaniu danych raczej mowy nie ma - ale jeśli kamera będzie podłącozna pod interfejs RGB kontrolera LCD to przesył obrazu kamera LCD procesora nie zajmie. Wszelkie timingi da się wygenerować sprzętowo timerami. Co nie zmienia faktu, że na większym procku (ale solidnie większym) dałoby się nawet obraz z tej kamerki jakoś przetwarzać.
BTW, skoro zbocze opadające to PORT_ISC_FALLING_gc, to zbocze narastające to PORT_ISC_RISING_gc.
Co do wydajności xmegi względem kamery jestem spokojny ponieważ kamera może pracować z mniejszą rozdzielczością i będzie przesyłać dane już gotowe w formacie RGB wystarczy je tylko zapisać w zewnętrznym sram który już obsłużyłem. Chce przechwycić tylko jedną klatkę. Widziałem tą kamere współpracującą z atmegami (16MHz) więc nie mam obaw co do Xmegi (32Mhz). Dzięki tmf za pomoc. "Pomógł" do cb już poleciał. Tak już wiem jak obsłużyć tą matryce TFT, ale zabiorę się za nią gdy zmienie architekturę, zastanawiam się nad fpga/cpld.
Przepraszam, ale co Ty chcesz tutaj generować timerami?
Kamera potrzebuje stabilnego sygnału zegara ( i to możesz jej dać), ale później sama wystawia pixel clock, dane, hsync i vsync. Choćbyś nie wiem jak próbował, to xmega nie jest w stanie odczytywać płynnie danych w każdym takcie zegara (aby nic nie zgubić) i jednocześnie przesyłać to do TFT. EBI na nic się tutaj nie zda. A jeżeli chcesz połączyć kamerę bezpośrednio z kontrolerem wyświetlacza, to żaden format przesyłanych danych SCCB, 565, 555 czy 444 nie jest w tej postaci jadalny. Nie mówiąc już o różnicach w back porch i front porch. Proponuję zrobić analizę w dziedzinie czasu i od razu będzie widać dlaczego w ARMach jest DCMI.
Prędkość wysyłu danych z kamery można regulować ustawiając rejestry kamery po i2c to leci. A po drugie ja tylko pytałem o zbocza a nie o wydajność atxmegi i kamery. Po 2 to mój problem a Pan zbyt się nim przejął. Tematu jeszcze nie zamykam.
Przepraszam, ale co Ty chcesz tutaj generować timerami?
Kamera potrzebuje stabilnego sygnału zegara ( i to możesz jej dać), ale później sama wystawia pixel clock, dane, hsync i vsync. Choćbyś nie wiem jak próbował, to xmega nie jest w stanie odczytywać płynnie danych w każdym takcie zegara (aby nic nie zgubić) i jednocześnie przesyłać to do TFT. EBI na nic się tutaj nie zda. A jeżeli chcesz połączyć kamerę bezpośrednio z kontrolerem wyświetlacza, to żaden format przesyłanych danych SCCB, 565, 555 czy 444 nie jest w tej postaci jadalny. Nie mówiąc już o różnicach w back porch i front porch. Proponuję zrobić analizę w dziedzinie czasu i od razu będzie widać dlaczego w ARMach jest DCMI.
Proponuję dokładniej przeczytać notę do ov i np. do ILI, potem się wypowiadać. Stanie się też jasne po co timery.
BTW, można też wklepać na youtube odpowiednie hasło, aby się przekonać, że ludzie robią to nawet na ATMega, ba, nawet z prostym przetwarzaniem obrazu, typu śledzenie koloru:
http://www.youtube.com/watch?v=Tug7FBZTlnc
Sam kiedyś zrobiłem odczyt z kamery na ATMega8 i to w sposób zupełnie programowy (procek sprzętowo generował tylko Pixel Clock dla kamery (jakieś 8MHz)).
Program musiał ignorować co drugą linię obrazu żeby się wyrobić, ale ogólnie dawał radę.
Konwertował też w locie YCrCb na RGB i puszczał po SPI do LCDka.
Myślę więc że na Xmega będzie tylko łatwiej (ale dla kogoś biegłego w programowaniu, i raczej nie dla autora tematu (sorki )).
Spokojnie kolego ogarniamy powoli dużo czasu mamy. A xmegi to ja dopiero co zaczynam bo książkę pana tmf kupiłem i powoli sobie robie i jak coś to pytam. Kamerkę już mam też, a z tym lcd to nie wiem coś z nim nie gra bo podłączyłem ostatnio do arduino na sprawdzonym sofcie też coś nie działa.