Avr e tcm8230md in spycam

Salve a tutti, è da un pò che non scrivo sul forum :-X vorrei realizzare una "semplice" microcamera spia come la keychain808 (occultata dentro un telecomando apricancello) ma con la differenza che si troverà dentro un paio di occhiali. So bene che esistono in commercio prodotti del genere ma voglio sperimentare ;D

Passiamo al progetto :

Cercando online mi sono imbattutto in questo progetto http://www.ikalogic.com/image-processing-as-a-sensor/ in cui ci sono anche i vari collegamenti ed i file (eaglecad) per vederli meglio..il problema è che il file .brd ed il relativo .sch indicano collegamenti completamente diversi!

In base ai due datasheets credo di aver capito chi va connesso a cosa :

Collegamenti Cam -> AVR

  • PVDD -> 2.8V
  • DVDD -> VDD 1.5V
  • DVSS -> GND
  • IOVSS -> GND
  • IOVDD -> VDD 2.8V
  • SCL -> SCL (PC0)
  • SDA -> SDA (PC1)
  • DOUT[0-7] -> PB0-7
  • VD -> PA0 (Sync Pixel verticali)
  • HD -> PA1 (Sync Pixel orizzontali)

Se questi sono giusti mi mancano ancora i pin EXTCLK,RESET,DCLK della cam..

Il post è già diventato lunghissimo e quindi per adesso non aggiungo altra carne sul fuoco :D

PS : se siete deboli di cuore non aprite il file .brd di ikalogic..è un tantino incasinato (ho impiegato diverse ore per sbrogliarmi tra i cavi ed alla fine i collegamenti mi sembrano errati..se volete e può servire posso tentare di farne uno un pò più ordinato)

nessuno?

Forum di Arduino, si parla di molte MCU Atmel, ma la serie ATxMega mica la conoscono in molti. :D Non ti conviene chiedere direttamente al tipo di quel link e fargli presente la cosa ?

Oiram92: Cercando online mi sono imbattutto in questo progetto http://www.ikalogic.com/image-processing-as-a-sensor/ in cui ci sono anche i vari collegamenti ed i file (eaglecad) per vederli meglio..il problema è che il file .brd ed il relativo .sch indicano collegamenti completamente diversi!

Ho seri dubbi che un Xmega sia in grado di gestire una ripresa video con quel sensore CMOS, troppo lento e troppa poca ram, un singolo frame 640x480, anche ipotizzandolo semplicemente a 256 livelli di grigio, richiede ben 307k di ram per l'acquisizione, ci vuole almeno il doppio con codifica a 65k colori. Inoltre impossibile implementare una qualunque compressione video con quel micro, con 600k a frame riempi una SD da 4G in meno di 10 minuti se lavori con solo 15 fps. Il progetto sul blog di Ikalogic è l'utilizzo della camera come sensore per un line follower, molto più semplice da implementare che la registrazione di un video.

Con un XMega da solo vai poco lontano.. non è fattibile

astrobeed:
Ho seri dubbi che un Xmega sia in grado di gestire una ripresa video con quel sensore CMOS, troppo lento e troppa poca ram, un singolo frame 640x480, anche ipotizzandolo semplicemente a 256 livelli di grigio, richiede ben 307k di ram per l’acquisizione, ci vuole almeno il doppio con codifica a 65k colori.
Inoltre impossibile implementare una qualunque compressione video con quel micro, con 600k a frame riempi una SD da 4G in meno di 10 minuti se lavori con solo 15 fps.
Il progetto sul blog di Ikalogic è l’utilizzo della camera come sensore per un line follower, molto più semplice da implementare che la registrazione di un video.

Non ho mai parlato di acquisizione video :slight_smile: il progetto consiste nel collegare il micro, cam ed un bottone. Quando il bottone viene premuto si ha l’acquisizione di un immagine (anche soltanto in bianco/nero va benissimo). Se la camera fosse usata come sensore non dovrebbe in ogni caso inviare l’array al micro per il controllo?

Restando su questa strada, mi sembra di capire che l’unico intoppo sta nel fatto che il micro non ha ram sufficiente per acquisire in memoria un immagine intera. Un escamotage sarebbe quello di creare una routine in modo che vengano acquisiti dal micro 16k per volta (massima ram sul micro), e di volta in volta andare ad aggiungerli al file sulla sd e svuotare nuovamente la ram per acquisire i bytes successivi. Questa procedura mi sembra molto laboriosa (ma spero che non sia sbagliata come teoria) e non so quanto tempo potrebbe richiedere per l’acquisizione di una sola immagine. Qualcuno potrebbe illuminarmi?

Oiram92: Qualcuno potrebbe illuminarmi?

Va bene cosi ? :D

La camera ti butta fuori i pixel ad una certa frequenza, devi leggerli subito tutti altrimenti li perdi. Ti serve quindi una memoria FIFO esterna con una mcu lenta e con poca memoria. Per questo ti dicevo che non si può fare senza altre cose.

In passato ho fatto proprio con una FIFO l'acquisizione di immagini QVGA a colori e la loro trasmissione via wireless con un XMega, ci volevano 3-4s per immagine (complice anche la banda disponibile col modulo wireless utilizzato)

astrobeed: Va bene cosi ? :D

:roll_eyes: ahaha così va meglio ;) però potevi prendere una foto in cui la lampada non fosse affetta dall'effetto flicker :P

flz47655: La camera ti butta fuori i pixel ad una certa frequenza, devi leggerli subito tutti altrimenti li perdi. Ti serve quindi una memoria FIFO esterna con una mcu lenta e con poca memoria. Per questo ti dicevo che non si può fare senza altre cose.

In passato ho fatto proprio con una FIFO l'acquisizione di immagini QVGA a colori e la loro trasmissione via wireless con un XMega, ci volevano 3-4s per immagine (complice anche la banda disponibile col modulo wireless utilizzato)

Beh innanzitutto 3-4s per immagine vanno benissimo! Adesso mi documento meglio sulle memorie FIFO :) per quello che ricordo dal corso di informatica base le FIFO sono delle code del tipo First In First Output quindi in base a questa logica si deve una catena del tipo :

il micro invia il comando di scattare la foto, la cam prende l'array di bytes e lo passa (tramite le porte Dout) al micro che reindirizza tutto sulla memoria FIFO esterna per salvarli. In seguito preleva l'array dalla memoria e lo salva su sd.

Vado subito a leggermi qualcosa in più sulle FIFO :D ovviamente suppongo che la memoria disponibile deve essere superiore ai 600k che diceva astrobeed giusto?

Hai sbagliato tutto.

La FIFO va collegata direttamente alla camera, il micro non fa in tempo a stare dietro ai bit che butta fuori la camera.

La FIFO deve essere veloce in scrittura (almeno quanto il pixel rate impostato nella camera) e deve poter essere letta lentamente dalla MCU che poi potrà scrivere i dati sulla SD.

La dimensione dipende dal formato (es RGB656 sono 2 byte / pixel) e dalla dimensione dell'immagine che vuoi acquisire.

Ti do un modello di FIFO, AL422B. Trovi modulini con camera + FIFO (cerca "OV7670 FIFO") ma a posteriori direi che non ne vale la pena, con i soldi che spendi ti compri una raspberry e ci colleghi una vecchia webcam di recupero che avrà qualità quasi sicuramente migliore ed eviterai tanti problemi.

Grazie mille per la risposta, mi sono documentato sulle memorie FIFO ed ho cercato anche l'implementazione "OV7670 + fifo". Credo di essermi chiarito un pò do più le idee e (leggendo i datasheets) sono giunto ad alcune conclusioni (ancora incomplete).

Utilizzo dell'I2C sulla camera Il collegamento tra le porte SDA/SCL va fatto tra la cam ed il micro (con le relative resistenze di pull-up dato che la cam lavora a 2.8V)

1) Il protocollo di comunicazione viene utilizzato per scrivere sul registro della cam in modo da settare soltanto i parametri per inizializzarla o (sempre attraverso questa linea) si deve dare il comando di acquisizione del frame?

Linee di input e output dei dati Le linee di output della cam vanno collegate agli input della fifo in modo da scrivere direttamente in memoria i dati inviati dalla cam. L'invio delle informazioni dalla cam avviene ad una certa velocità determinata dal clock della cam stessa. Per questo motivo va messo un cristallo sulla porta EXTCLK in modo da stabilire la frequenza a cui lavora la cam. Inoltre va definito anche il clock di output dei dati (porta DCLK della cam) che, per ovvi motivi, deve essere sincronizzato con il clock di scrittura sulla fifo. Questo significa che la porta DCLK della cam va collegata con la porta WCK (write clock) della fifo.

2) Il ragionamento è corretto?

Acquisizione del frame Inizio questo "paragrafo" con una domanda :

3) La cam ha due porte di output (VD e HD) che servono per la sincronizzazione verticale ed orizzontale dai pixel. Dal datasheet non mi è chiaro se vanno collegati entrambi i pin oppure se sono solo due modalità differenti di acquisizione del frame. In altre parole, supponiamo che siano due modalità indipendenti, se scelgo di usare il pin VD, avrò in output un array di valori in cui i primi due bytes sono l'ultimo pixel della prima colonna, i successivi sono il penultimo pixel, e così via..mentre se usassi la modalità HD avrei una sincronizzazione per righe (invece delle colonne). E' giusto così, cioè che è sufficiente utilizzare uno solo dei due pin oppure in un qualche modo (che al momento non comprendo) vanno usati entrambi per sincronizzare righe e colonne in una matrice?

Continuando con l'acquisizione del frame, dal datasheet della fifo si legge che affinchè sia abilitata la scrittura sulla memoria, il pin WE (write enable) deve essere messo "low". Questo significa che il WE va collegato ad una porta (di output) del micro e quando questa viene settata a "low", il pin WE (di input) viene attivato ed abilita la scrittura in memoria dei dati che riceve dai pin DI[07].

4) Ma la cam come viene "avvisata" del fatto che deve restituire in output i dati del frame?

Dal circuito "OV7670 + fifo" sembra che colleghino il pin VSYNC (che corrisponde al VD della cam) direttamente al micro, mentre la porta HREF (che "dovrebbe" corrispondere alla porta HD della cam) viene collegata ad un circuito logico NAND che da in output un valore 0 o 1 al write enable della fifo. Quindi, quando entrambi gli input al circuito NAND sono 1 (gli input provengono (1) dal micro e (2) dalla porta HREF), allora il circuito NAND restituisce sul pin WE della fifo il valore 0 (cioè "low") in modo da abilitare la scrittura sulla memoria stessa. Quest'ultimo fatto mi confonde un bel pò le idee perchè in base al tipo di porte abbiamo che :

5) Il VSYNC (cioè il VD della cam) è un output e quindi, se collegato direttamente al micro, dovrebbe essere messo su una porta di input del micro, ma a cosa serve allora? 6) L'HREF (cioè il pin HD della cam) è anch'esso un output e viene utilizzato per abilitare la scrittura della fifo tramite il circuito NAND. Per abilitare la scrittura è necessario che esso sia sempre "HIGH" in modo tale che il circuito NAND restituisca "LOW" alla fifo.

7) Quindi, in sostanza, a che cosa servono HD e VD?

Scusate se il post è molto lungo però piuttosto che scrivere soltanto le domande ho preferito argomentare un pò quello che credo di aver capito in modo da vedere insieme se sono sulla strada di pensiero giusta oppure sono completamente fuori strada.

Parliamo dei modulini OV7670 con FIFO (non della tcm8230 che se vuoi te la studi per conto tuo :smiling_imp: )

La camera lavora a diverse tensione, per l'I/O non puoi superare i 3v quando devi scrivere verso la camera. Per semplificarti la vita usa 2.8v per il micro così hai la solita tensione e non devi fare magheggi.

1) Non è I2C ma SCCB, seppur molto simile non è compatibile. Imposti i registri per dire la dimensione dell'immagine, la frequenza dei pixel, etc.. è un pò il punto debole in quanto non sono documentati molti registri e non potrai mai tararla alla perfezione senza contattare Omnivision (=$$$) che se non devi produrre almeno 1 milione di pezzi non ti richiama neanche.

2) Col modulino hai tutto già collegato. L'oscillatore non serve è già sul modulino e serve per dare il pixel clock.

3) La OV7670 ha una porta ad 8 bit per i dati (=pixel) e altre porte (HREF, VSYNC) che sono collegate con la fifo per sincronizzare la scrittura con l'inizio di un nuovo frame. Se studi lo schema c'è tutto, attenzione che le prime rev del modulino non funzionavano e dovevi proprio fixarle il modulino con dei cavetti jumper, cerca la rev. 3 altrimenti hai altre magagne e basta.

4) La camera la configuri con SCCB (NON semplice ne documentato, nel 99% dei casi ti vengono immagini da schifo) e lei in continuazione butta fuori i dati

5) Il VSync ti dice quando inizia / finisce un frame

6) HRef serve per abilitare la scrittura ed evitare di scrivere dati invalidi, il sensore manda i dati di una riga, dei dati invalidi, altra riga, e così via. Guardati le timing specification del DS di 0v7670

7) Secondo me sei completamente fuori strada, fai tutta questa fatica per cosa? Cosa te ne fai alla fine di immagini in bassissima qualità, piccolisssimo angolo di visuale (hai visto la focale delle lenti? E' 2.8mm con un CMOS da 1/6'', fai i tuoi calcoli...), fps bassisimo che praticamente non puoi elaborare ulteriormente.. Comprati un temporizzatore per una macchina digitale fotografica, fai prima e viene molto meglio!

In alternativa ti prendi una raspberry col suo modulo camera da 5MP, qualità molto buona, puoi comprimere su SD al volo in JPEG o fare video compressi ad alti fps, etc.. ti diverti poi a fare videosorveglianza o robe del genere coi tanti pacchetti già pronti che trovi. Spendi ma almeno ottieni qualcosa.

Ti abbiamo steso subito?