Brauche Unterstützung beim OV7670 (bzw. SCCB)

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> @Michael U. :
>
> Meinst Du mit "Odroid" den hier:
> 
https://www.heise.de/make/meldung/Odroid-Go-Bastel-Game-Boy-mit-ESP32-zum-Odroid-Geburtstag-4088637.html
> ?

Ja, gekauft hier:
https://www.pollin.de/p/odroid-go-mobile-spielekonsole-kit-810887

> Und hast Du die JPG-Decompression selbst programmiert?
> Wenn ja: mit welcher Library?

Nein, wäre wie auch MP3 in der Klasse, wo ich durchaus verstehe, was da 
passiert, mich der Arbeitsaufwand bei meinen C/C++ Kenntnissen aber doch 
etwas abschrecken würde.
https://github.com/Bodmer/JPEGDecoder

Gruß aus Berlin
Michael

[David D. (saturi)]

Hallo zusammen,

ich verabschiede mich für zwei Wochen in den Urlaub. Da aber die erste 
Woche regen angesagt ist... Juhu.... werde ich wohl offline etwas 
weitermachen.
Ich denke, dass ich euch im anschluss einmal einen release von dem 
Programm zur Verfügung stellen werde, sodass ich vielleicht noch den ein 
oder anderen Verbesserungsvorschlag von euch erhalten kann :)

bis dahin!

lg.
David

[Michael U. (amiga)]

Hallo,

schönen Urlaub wünsche ich Dir.

Ich habe inzwischen zumindest die FIFO-Version der OV7670 von meinem 
Bekannten auch hier liegen, kann also durchaus dann mal was testen.

Ansonsten habe ich inzwischen zumindest die Versandbestätigung von 
SeeedStudio für das ESP-Cam Modul bekommen, also auch da abwarten und 
überraschen lassen.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

@Michael U.:
Danke für Deine Ausführungen zum Odroiden und zur JPEG-Lib.

@David D.:
Schönen Urlaub!

@Michael U.:

> Ansonsten habe ich inzwischen zumindest die Versandbestätigung von
> SeeedStudio für das ESP-Cam Modul bekommen, also auch da abwarten und
> überraschen lassen.

Da bist Du schon weiter als ich.
Ich habe ebenfalls 2 Stück bestellt, aber noch keine Versandbestätigung 
erhalten.

Viele Grüße

Igel1

[David D. (saturi)]

Guten Morgen meine lieben Mitstreiter.
Nach einer besinnlichen Weihnachtszeit habe ich mich nun die letzten 
Tage wieder unserem gemeinsamen Kamera Projekt gewitmet.

Ich denke, ich wäre jetzt soweit, das PC-Programm mit euch zu teilen. 
Ich habe es heute tatsächich einmal geschafft, ein Bild (allerdings nur 
schwarz) von dem uC zum PC zu senden und dort darzustellen. Dass der 
Bildstream aber funktioniert habe ich ausprobiert und einfach mal vom uC 
weiß gesendet. Jetzt liegt das Problem also wieder auf uC seite und dem 
auslesen bzw. schreiben des Fifos, was offensichtlich noch nicht 
wirklich funktioniert.

Weiterhin hoffe ich auf euren Rat bei folgendem Problem:
Derzeit übertrage ich das Bild Zeile für Zeile. Nach jeder Zeile sende 
ich noch ein CR+LF mit. Diese beiden Zeichen überprüfe ich dann. Sind 
diese an entsprechender Stelle vorhanden, wird die nächste Zeile vom uC 
abgefragt. stehen dort andere Zeichen, wird nocheinmal die Gleiche Zeile 
abgerufen.
Die Auswertung der Zeile findet erst statt, wenn >= (BytesProPixel * 
xResolution)+2 Zeichen im Buffer auf PC Seite vorhanden sind.
Wird jetzt aber ein Byte "verschluckt", wartet das Programm und sendet 
eben nichts mehr an den uC zurück. Das passiert leider relativ häufig. 
Hier bräuchte ich so eine Art watchdog oder eine andere Art der 
Herangehensweise.

Seid ihr noch im Boot und hättet Lust mit zu spielen? dann würde ich 
euch das Programm schicken und eine kleine Einweisung/Workarounds :D 
zusammenschreiben.

lg.

David

[Michael U. (amiga)]

Hallo,

schön von Dir zu hören. Bei mir liegt zumindest jetzt auch die OV7670 
mit FiFo von meinem Bekannten rum.

David D. schrieb:
> ich noch ein CR+LF mit. Diese beiden Zeichen überprüfe ich dann. Sind
> diese an entsprechender Stelle vorhanden, wird die nächste Zeile vom uC
> abgefragt. stehen dort andere Zeichen, wird nocheinmal die Gleiche Zeile
> abgerufen.

Hast Du Grund zu der Annahme, das da unterwegs was aus der Leitung 
fällt?
Bei meinem LogicAnalyzer übertrage ich 32kB per Loop aus einem externen 
Ram über einen FTDI mit Einstellung 500kBaud an mein (uraltes) 
VB-Programm. Da ist nie auch nur ein Bit abhanden gekommen. Ich hatte 
zwar ein paar Diskussuinen im alten VB6 mit den seriellen Puffergrößen, 
die habe ich aber gewonnen. ;)

Anhsonsten: mitspielen durchaus, der Kram leigt ja ohnehin rum. 
Ernsthaft werde ich die OV7670 sowiso nicht einsetzen. Meine ESP-Cams 
liegen allerdings z.Z. auch nur rum. Inzwischen ist beim ESP32-Arduino 
zumindest ein Demosurce dabei. Das ist zwar ähnlich dem gemacht, was ich 
hier schon hatte, also Arduino-Rahmen und das IDF-Demo darunter, ist für 
mich aber vermutlich etwas lesbarer. Dann muß ich da nicht immer meinen 
Bekannten nerven.

OT: da ich bei Pollin mal wieder was entdeckt hatte:
https://www.pollin.de/p/portabler-designlautsprecher-schwarz-641081
hat nicht 3 Lautsprecher sondern 2+ passiv-Membran und ist auch 
USB-Soundkarte, das hat Pollin garnicht erwähnt. Da kommt in einen jetzt 
erstmal ein ESP32 Wrover + I2S-Decoder rein, als"Klo-Radio" oder so.
Muß nur noch klären, ob die diskrete Einschaltlogik mit der Taste den 
zusätzlichen Strom des ESP32 verkraftet oder ob ich da noch was 
dazulöten muß.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

@David:

ich wäre auch wieder dabei - allerdings nur als interessierter Mitleser 
und "Gelegenheits-Dreinschwätzer" ... aber das kennt Ihr ja schon.

Bitte liste (oder verlinke) nochmals Deine aktuelle 
Hardware-Konstellation, mit der Du experimentierst (nur für den Fall, 
dass der eine oder andere - im äußersten Fall sogar ich selbst - Deinen 
Aufbau einmal nachbaut). Wenn Du ganz viel Motivation hast, vielleicht 
gar mit einem kleinen Schaltplan. Mit einem Programm wie "Fritzing" 
sollte so etwas in wenigen Minuten getan sein.

Was den Code angeht, so würde ich anregen, ihn bei Github oder einem 
ähnlichen Code-Repository einzustellen. Alternativ betreibt 
mikrocontroller.net auch einen eigenen SVN-Server, in dem man ebenfalls 
Code einstellen könnte: 
https://www.mikrocontroller.net/articles/Hilfe:SVN
Allerdings ist Github im OpenSource-Bereich meiner Meinung nach etwas 
weiter verbreitet.

Vorteil: alle können an Deinem Projekt mitproggen.
Nachteil: Du bist nicht mehr Herr "Deines" eigenen Codes - weil es dann 
nämlich nicht mehr so richtig "Dein" Code ist.

Viele Grüße

Igel1

[Dieter F. (Gast)]

Andreas S. schrieb:
> Vorteil: alle können an Deinem Projekt mitproggen.

Gibt es da jemanden? Nur mal so gefragt ...

Ich überlege, mit dem ATXMega mitzuspielen, passt halt nicht so ganz zum 
aktuellen Ansatz.

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Andreas S. schrieb:
>> Vorteil: alle können an Deinem Projekt mitproggen.
>
> Gibt es da jemanden? Nur mal so gefragt ...
Um realistisch zu bleiben: sehr wahrscheinlich nicht wirklich.
Ich würde auch nur seinen Code hier auf den AVR packen und etwas 
Fehlersuche mit betreiben, seine PC-Software würde ich ohnehin nur 
nutzen. zumindest, wenn ich dafür nicht erst meinen PC "umbauen" muß...

Die OV7660 ist nicht unbedingt mehr so sinnvoll, um die wirklich zu 
nutzen. Für Spezialanwendungen (Objekterkennung? Bewegungserkennung? 
Barcode/QR-Code Leser?) vielleicht noch. Selbst die OV7670 ist nicht 
soviel moderner, allerdings macht die etwas höhere Auflösungen und 
JPEG-Ausgabe.

> Ich überlege, mit dem ATXMega mitzuspielen, passt halt nicht so ganz zum
> aktuellen Ansatz.

Ein ATXMEga (Xplain...) liegt hier irgendwo noch rum, nie wirklich 
benutzt.
Inzwischen sind ESP8266/ESP32 meine Freunde, die ESP8266 im realen 
Einsatz hier für diverse Home-Spielereien, die ESP32 mehr im 
Experimetierstaduin, weil die Module für den Preis einfach noch 
ungeahnte Möglichkeiten bieten.
Die OV7670 habe ich am ESP32, da denke ich noch über eine "reale" 
Verwendung nach, Wetter-Cam auf dem Balkon vielleihct, da könnte sie 
alle paar Minuten ein Standdild in voller Auflösung schicken.
BT beim ESP32 bisher nur angetestet, als BT-Speaker.
Rechenleistung reicht bequem für Webstream, Software-MP3-Decoder und I2S 
Ausgabe. läuft hier u.a. auf einem Odroid Go:
https://www.pollin.de/p/odroid-go-mobile-spielekonsole-kit-810887?&gclid=EAIaIQobChMIm76Gy4vz3wIVk-J3Ch2_kAhVEAQYASABEgJuBPD_BwE

Da habe ich bei den Emalatoren letztens entdeckt, daß jemad Frode für 
den ESP32 angepasst hat, irgendwie genial, Frodo stammt ursprünglich vom 
Amiga, Christian Bauer hat ihn dann für alle möglichen OS 
bereitgestellt.
Fehlt nur noch, das jemand das mit Shapeshifter
https://de.wikipedia.org/wiki/ShapeShifter
macht, aber ein 68020 mit 14MHz (als Minimum) auf dem ESP32???

OK genug Geplauder... ;-)

Insofern wird OV7670 und AVR für mich eben nur als Beweis dienen können, 
daß man es irgendwie machen kann.

Gruß aus Berlin
Michael

[David D. (saturi)]

Guten Abend zusammen :)
Das freut mich ja, dass ich direkt Rückmeldung bekommen.

Anbei nochmal der gewünschte Schaltplan.

>Hast Du Grund zu der Annahme, das da unterwegs was aus der Leitung
>fällt?
Leider hatte oder habe ich das tatsächlich. Ich glaube zwar das es nicht 
Aufgrund von EMS ist, sondern lediglich durch schlechte Programmierung. 
Das mit dem abbrechen mitten im Bild-Stream habe ich jetzt tatsächlich 
hinbekommen. (Das Problem lag daran, dass ich nicht gesehen habe, dass 
ich die Write- und Read-Reset Leitungen des Fifos invertieren muss... 
kaum ist das passiert, bekomme ich auch (zuverlässig?!) meine 480 Zeilen 
geliefert. zuverlässig in Klammern, weil es bisher erst in den letzten 
beiden Bildern so war. Derzeit fahre ich aber noch im RGB888 Format bei 
voller Auflösung, einer Baudrate von 19200 und REICHLICH puffer Zeiten 
im ms Bereich, sodass ich aktuell für ein Bild rund 15 min brauche :D. 
Immerhin ist durch das nun offensichtlich funktionierende zurücksetzen 
der Write und Read Pointer im Fifo ein plausibles schwarzes Bild mit 
leichtem Rauschen hinterlegt und nicht wie vorher das komplette 
Farbspektrum willkürlich :D...
Kaum schreibe ich diese Satz stoppt die Übertragung bei 418 Zeilen....

>Gibt es da jemanden? Nur mal so gefragt ...
Nein leider nicht :D
Es gibt auch ein Github-Projekt zu diesem Anliegen hier, dass ein User 
in Leben gerufen hatte, aber nachdem ich der einzige war, der darin 
weiter gearbeitet hat, habe ich das Uploaden eingestellt.Ich stelle euch 
aber gerne den Source Code für den Atmega zur Verfügung. Ich hoffe, dass 
ich es heute Abend schaffen -werde. Dazu packe ich dann noch einen 
Release für mein "OV7670-Terminal" Programm.

@Dieter.F du bist herzlich eingeladen auch mit einem anderen Controller 
mit einzusteigen.

Viele Grüße
David

EDIT: Hier noch der Github Link:
https://github.com/igittigitt/ov7670

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Ich stelle euch
> aber gerne den Source Code für den Atmega zur Verfügung. Ich hoffe, dass
> ich es heute Abend schaffen -werde. Dazu packe ich dann noch einen
> Release für mein "OV7670-Terminal" Programm.

mach das mal, ich werde es auf jeden Fall mal anwerfen und reinschauen.
Im Moment wohl speziell in die Übertragungsgeschichte, RGB888 ist ja 
erstmal gut handhabbar. Vielleicht schicke ich einfach einen passenden 
BMP-Header vorneweg und lese es wie früher per TeraTerm in den Buffer 
und speichere den.
Dann kann es mir ja Irfanview anzeigen.
Ein lauffähiges altes VB6 habe ich hier nicht mehr, sonst hätte ich mir 
da meine Empfangsroutine vom LogicAnalyzer ausgeliehen...

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

@David:

solltest Du noch keinen LogicAnalyzer haben, so wird hier in diesem 
Forum im Marktbereich gerade genau derjenige LA gebraucht angeboten, den 
ich ebenfalls habe.

Ist ein phantastisches Gerät, das ich jedem nur empfehlen kann:
Beitrag "Intronix Logicport 34 Kanal Logic und Bus Analyser"

Einziger Nachteil: er hat nur 2k Puffer, die allerdings dank 
intelligenter Sampling-Methodik optimal ausgenutzt werden. Notfalls muss 
man halt den (sehr flexiblen) Trigger etwas klug wählen - dann kommt man 
in 99% der Fälle auch mit den 2k aus.

Dafür kann das Teil auch 250MHz-Signale noch analysieren (mit internem 
Timer sogar bis 500MHz) - absolut sensationell für diesen Preis.
Und die Logic-Level sind auch in weiten Volt-Bereichen einstellbar.
Die Software ist ebenfalls sehr, sehr gut und mächtig.

Hier die Specs:
http://www.pctestinstruments.com/logicport/specifications.htm

Bei Interesse: schnell zuschlagen - das Teil wird bald weg sein.

Viele Grüße

Igel1

PS: nich ich bin weder mit dem Verkäufer verwandt noch kenne ich ihn.

[Dieter F. (Gast)]

Andreas S. schrieb:
> Die Software ist ebenfalls sehr, sehr gut und mächtig.

Zu gut und mächtig für mich (wahrscheinlich) - ich kam damit nicht klar 
und habe ein solches Teil vor einiger Zeit verkauft. Aber das ist - wie 
alles - relativ :-)

[David D. (saturi)]

Guten Abend,
wie versprochen die Uploads:

Das Terminal Programm (ich vermute, dass das ein .net-Framework o.ä. 
installiert sein muss, falls ihr es nicht ausführen könnt, einfach 
nochmal melden, dann finden wir bestimmt eine Lösung):

https://github.com/igittigitt/ov7670/tree/TWI-Interfac/OV7670-Terminal-Releases

Und der Code fürs AVR Programm:

https://github.com/igittigitt/ov7670/tree/TWI-Interfac/OV7670-AVR

Und hier noch eine Kurzanleitung:
Wie schon erwähnt funktioniert noch nicht sehr viel, aber auf Wunsch 
stelle ich es trotzdem schon einmal zur Verfügung.

1. Alles anstöpseln und dann beim Aufrufen des Terminals unter der 
Register-Karte "Settings" und in der GroupBox Com-Port die 
voreingestellten Werte benutzen (evtl. muss der Com-Port eingestellt 
werden) und auf verbinden klicken. (Falls hier Änderungen vorgenommen 
werden wollen, müssen diese Ebenfalls im AVR Code geändert werden 
(UART.c))


2. nun sollte "connected" in grüner Schrift in gleicher Box stehen. 
Jetzt muss ein paar mal auf den Button get camera status geklickt 
werden, bis bei Version zwei plausible Hex Adressen erscheinen (Bei mir 
0x76 0x73)

Hierbei handelt es sich noch um ein Kommunikations Problem, das ich noch 
nicht identifizieren konnte. Mehrmaliges klicken behebt dieses aber :D

3. nun können unter den Groupboxen Read Register und Write Register 
beliebig die Register geschrieben und gelesen werden. Eine jeweilige 
Bestätigung erscheint unten in der Status leiste. Es ist auch möglich, 
mit "Read Device Settings" alle register auszulesen und ggf. 
abzuspeichern. sollte der Fortschrittsbalken unerwartet stehen bleiben 
ebenfalls nochmal den Button drücken und hoffen, dass er diesmal 
durchläuft. ;-) sollte jemand den Fehler finden, bin ich sehr Dankbar.

4. Das Laden von abgespeicherten Settings funktioniert auch. Allerdings 
nicht, diese auch alle wieder auf den Chip zu schreiben.

5. "take" (wo eigentlich "take picture" stehen sollte, funktioniert 
derzeit nur im VGA und RGB Modus. d.h bevor ein Bild aufgenommen wird 
muss erst das Register 0x12 mit 0x04 beschrieben werden. Das ganze am 
besten mit "get camera status" verifizieren.

6. Ab dann beginnt der Bildaufbau. dauert etwas und in der Statusleiste 
sieht man, wieviele Bildzeilen bereits empfangen sind. (ca 2-3 Sekunden 
pro Zeile

7. unter der Registerkarte _picture kann kann man unter den beiden 
Bildboxen den Haken setzen und bekommt das Bild, dass gerade empfangen 
wird etwas größer dargestellt. Bild speichern funktioniert ebenfalls. 
die anderen Knöpfe noch nicht.


Zum schluss möchte ich noch eins Anmerken, die Zeilen, die Seriell 
ausgelesen werden, geben das Bild wieder, dass bei "take picture" den 
Sensor belichtet hat, also bringt ein belichten der Kamera während der 
Übertragung rein garnichts.

Natürlich habe ich aktuell noch überhaupt kein Bild und bei euch wird 
mit meinem Code ebenfalls nur Rauschen zu erkennen sein. Daher lade ich 
euch hiermit recht herzlich ein, dass ganze zu testen. Gerne gehe ich 
auch noch auf den Code ein, wenn es jemanden interessiert.

viele Grüße

David

PS: Danke für den Link des Logik Analysers... Leider ist mein Budget 
aktuell etwas eng, sodass ich mit 2 Kanal Oszi leben muss. Ich habe auch 
irgendwo noch einen Logikanalyser den ich zusammen mit einem Billig USB 
Oszi gekauft habe rumliegen. Der ist aber ebenso unzuverlässig wie das 
Oszi an sich, was vermutlich noch nichtmal an der Hardware sondern 
vielmehr an der unfertigen zugehörigen Software liegt.

[Andreas S. (igel1)]

@David:

Dein Programm lief auf meinem Computer (Win7 64bit) direkt out of the 
box.
Allerdings habe ich keine Levelshifter, um Deine Schaltung nachzubauen.
Ich konnte also nur das Programm anwerfen und ein paar Knöbbschen 
drücken.

Wenn Du mir sagst, in welchem Format Du die Bilder aus dem AVR 
rausschreibst, kann ich das ja vielleicht mal in meinem ARM nachstricken 
(ohne Gewähr, dass ich jemals dazu komme ...).

Wirst zu den Code vom OV7670-Terminal.exe auch noch veröffentlichen?
Irgendwo hatte ich schon einmal so ein Programm gesehen ... wo war das 
nur ...

Viele Grüße

Igel1

[Andreas S. (igel1)]

Andreas S. schrieb:

> Irgendwo hatte ich schon einmal so ein Programm gesehen ... wo war das
> nur ...

Ha - gefunden: qSerialTerm heißt das Dingen - ich habe es aber niemals 
probiert:

http://embeddedprogrammer.blogspot.com/2012/07/hacking-ov7670-camera-module-sccb-cheat.html 
>  nach qSerialTerm suchen

[Michael U. (amiga)]

Hallo,

Terminalprogramm startet hier auch erstmal ohne Probleme.

Die AVR-Sourcen habe ich erstmal in die ArduinoIDE geworfen und die dort 
nötigen

#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}  // extern C
#endif

auf die .h Dateien verteilt. Gab noch ein paar unkritische Warnings und 
irgendwo fehlte ein #include "UART.h", dann lief er erstmal durch.
Ein aktuelles AVR-Studio habe ich nicht drauf und werde es auch nicht 
installieren. ;)

Mal schauen, heute Nachmittag mal OV2840-FIFO-Modul und Peegelwandler an 
einen Arduino UNO oder so stecken und mal schauen, was überhaupt 
passiert.
Dann werde ich mir das mal genauer anschauen.

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

David D. schrieb:
> @Dieter.F du bist herzlich eingeladen auch mit einem anderen Controller
> mit einzusteigen.

Na ja - ich nehme erstmal den Nano ohne Arduino und spiele damit etwas 
herum.

Mit dem 16MHz-Takt an PB0 schluppt die Kamera schon schön :-). Über ein 
Oszilloskop man man da schon mal prima die Signale (HSync etc.) 
beobachten. Ein Datenbit funkt dann auch schön wild, wenn man die Kappe 
von der Kamera abmacht.

Ich verwende keine Level-Shifter - entweder das Teil (ich habe 4 im 
Sonderangebot gekauft :-) ) hält das aus oder nicht.

Was mir aufgefallen ist - bei einigen IF's hast Du "=" statt "==" 
geschrieben - das ist "nicht optimal".

Ich werde mir jetzt mal die "Kommando-Verbindung" etwas genauer 
anschauen. Bis gerade fragte ich mich, wie Du bei solchen Taktraten ein 
Bild mit dem "lahmen" :-) 328P abholen willst - bis ich Register 0x11 
entdeckte ...

VG

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Ich verwende keine Level-Shifter - entweder das Teil (ich habe 4 im
> Sonderangebot gekauft :-) ) hält das aus oder nicht.

naja... ich sage es jetzt mal so: aus dem Alter bin ich raus...

Meie Sorge ganz allgemein ist da aber weniger, ob sie das aushält, mehr 
der Umstand, daß ich mich da auf das Verhalten der Kamera da nicht 
verlassen wollte. Die Pegel an den Eingängen sind dann doch merklich 
oberhalb der Specs.

Gruß aus Berlin
Michael

[David D. (saturi)]

Hallo Dieter,

ja das Register 0x11 ist erstmal wichtig um die CLK etwas runter zu 
bekommen, damit man das VSync signal auch abtasten kann.


>Was mir aufgefallen ist - bei einigen IF's hast Du "=" statt "=="
>geschrieben - das ist "nicht optimal".


Das wäre natürlich suboptimal, ich werde den Code direkt durchgehen und 
danach suchen. Im falle der if(errorCode=functionXXX()) ist es 
allerdings gewollt, da ich so abfragen kann, ob die funktion 
durchgelaufen ist oder nicht.

Mir ist aber selber noch ein Fehler aufgefallen. In der Funktion

void OV7670_captureNewImage (void)

muss es heißen:

...
OV_WR_PORT &= ~(1<<OV_WR_PinNo);
while(!getValueOfPin(OV_VSync_PIN,OV_VSync_PinNo));
OV_WR_PORT |= (1<<OV_WR_PinNo);

hier hatte ich vorher OV_WR_PIN stehen. Das muss definitiv korrigiert 
werden.
Dann habe ich gerade noch etwas mit den Low Active Signalen gespielt und 
das Timing etwas geändert. Das werde ich jetzt direkt noch ins Github 
Project Pushen.
Anbei noch drei Bilder.
Das eine aufgenommen im "normalen" Modus, das zweite, bunte mit dem test 
pattern 8bar color bar (Register 0x70 [7] und 0x71 [7] auf 10 gestellt) 
Immerhin wird es Bunt. Und das dritte mit dem Testpattern 11 
"FadeToGrayColorBar" Aber etwas scheint entweder mit der Bildaufnahme, 
der Farb zusammenstellung oder der Auflösung nicht zu passen. Aber man 
sieht unterschiede.

vielen Dank fürs Miteifern.
Die nächste Woche bin ich leider auf Dienstreise. Vielleicht kann ich 
die Zeit nutzen, um die Kommunikation zwischen uC und PC zu beschreiben, 
oder zumindest meine Vorstellung davon.

lg.
David

[Dieter F. (Gast)]

Michael U. schrieb:
> naja... ich sage es jetzt mal so: aus dem Alter bin ich raus...

Ich auch - aber ich suche auch keine Dauerlösung, nur einen 
"proof-of-concept" :-)

Michael U. schrieb:
> Meie Sorge ganz allgemein ist da aber weniger, ob sie das aushält, mehr
> der Umstand, daß ich mich da auf das Verhalten der Kamera da nicht
> verlassen wollte. Die Pegel an den Eingängen sind dann doch merklich
> oberhalb der Specs.

Das gilt nur in Richtung der Kamera über die SCCB-Schnittstelle. Hier 
kann man zur Sicherheit die geschriebenen Register-Werte verifizieren.

Von der Kamera kommen "Kamera-verträgliche" Pegel, welche vom 328P 
sicher erkannt werden (bei 3,3V VCC des 328P müssen die > ca. 1,8 V 
sein).

Falls das nicht funktioniert steuere ich halt nach.

David D. schrieb:
> Das werde ich jetzt direkt noch ins Github
> Project Pushen

Damit habe ich keine Erfahrung - würde ggf. dann direkt austauschen.

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Von der Kamera kommen "Kamera-verträgliche" Pegel, welche vom 328P
> sicher erkannt werden (bei 3,3V VCC des 328P müssen die > ca. 1,8 V
> sein).

wenn Du einen 3,3V Nano hast, passen die Pegel doch sowieso und 
Levelshifter sind unnötig. Ich hatte da auf einen 5V vermutet...

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Michael U. schrieb:
> wenn Du einen 3,3V Nano hast

Schrieb ich doch :-) - das ist zwar nicht ganz im Sinn der reinen Lehre, 
wird aber wohl funktionieren.

[Dieter F. (Gast)]

David D. schrieb:
> 5. "take" (wo eigentlich "take picture" stehen sollte, funktioniert
> derzeit nur im VGA und RGB Modus.

Wo genau im Code liest Du eigentlich die Daten vom Bus ein?

Sag nicht da:

char OV7670_getByte (void)

dazu gibt es keinen Aufruf ...

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Wo genau im Code liest Du eigentlich die Daten vom Bus ein?
>
> Sag nicht da:
> char OV7670_getByte (void)
>
> dazu gibt es keinen Aufruf ...

Nein, er benutzt char readByte (void) 2 Zeilen darüber...
Ordnung ist eben nur das halbe Leben. ;)

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Michael U. schrieb:
> Nein, er benutzt char readByte (void) 2 Zeilen darüber...

Danke - muss wohl die Tomaten wegblinzeln ...

Jetzt verstehe ich auch, wieso ich keine PWM für den Takt finde.

[Saturi (Gast)]

Hallo und Grüße aus dem Ausland.
Am Wochenende bin ich wieder zuhause und in der Lage detailierter auf 
die Fragen und die Erklärungen einzugehen.

Grob aus dem Kopf heraus den groben Ablauf:
der Atmega ist nach der Initialisierung der verschiedenen Komponenten in 
einer Art Idle-Mode(Programmstatus = -1). Ansonsten gibt es, wie in 
einem Automaten verschieden Programmstati. In welchen der uC versettz 
wird, hängt von dem per UART vom Terminal empfangenen Kommando ab. Die 
Befehlsverarbeitung findet in der UART.c statt. Hier gibt es (relativ 
weit unten [was für eine Angabe xD]) eine funktion, die die Empfangenen 
Bytes auswertet. Dabei gilt Folgendes Protokoll:
1. Byte = Befehl
je nach Befehl nun wvtl. 1 oder mehrere Datenbytes
2. Byte = Datenbyte
...
n. Byte = n-tes Datenbyte
n+1 Byte = 13   [ASCII CODE = Carrige return]
n+2 Byte = 10   [ASCII CODE = Line Feed]

diese Funktionen ändern den Programmstatus des uC. Die einzelnen zum 
Programmstatus auszuführenden Funktionen werden in der main.c durch eine 
Switch Anweisung angesteuert. Alle OV7670 Funktionen liegen auch im 
entsprechenden OV7670_withFifo.c (oder so ähnlich). Eine Bildübertragung 
funktioniert wie schon erwähnt immer Zeilenweise.


Ich habe letztes Wochenende noch eine zweite Version des Terminals 
"released". Hier ist ein Fehler in der Farbberechnung korrigiert worden 
und die Auflösung wird jetzt entsprechend des eingestellten Registers 
berücksichtigt (sowohl beim uC als auch beim Terminal) dadurch reduziert 
sich die Aufnahme von einem Bild dramatisch. Ich empfehle hier das QCIF 
Format.
Weiterhin sollte jetzt das Farbformat YUV - sofern per Register 
eingestellt - den Y Teil, also den Helligkeitswert abbilden. (UV)vom YUV 
werden aktuell gekonnt ignoriert.

Trotzdem bekomme ich noch kein Bild zusammengebaut.Ich bin für jede Art 
von Ratschläge offen :)

viele Grüße

David

[Dieter F. (Gast)]

Saturi schrieb:
> Trotzdem bekomme ich noch kein Bild zusammengebaut.Ich bin für jede Art
> von Ratschläge offen :)

Hallo David,

kannst Du die Source für die PC-SW offen legen?

Deine Abfrage der Datenbytes mit eigener Taktung funktioniert mit 
Sicherheit nicht (zuverlässig). Die Kamera braucht eine externe Frequenz 
von 10 bis 24 MHz. 8 MHz gehen auch, das habe ich ausprobiert und damit 
will ich (auf dem 328P) arbeiten.

Du musst Dich bei der Auswertung schon an den Pixeltakt (der ausgegeben 
wird und den Du über das Register 11 beeinflussen kannst) halten.

Ich spiele aktuell ein wenig damit herum. Mein Ansatz wird der Versuch 
einer "Interleaved-Verarbeitung" sein. Am Wochenende werde ich 
hoffentlich etwas mehr Zeit dazu finden.

Alternativ zur PC-SW überlege ich ein kleines Display "rudimentär" (ohne 
Farb und Helligkeitsinformationen - stumpf Schwarz/Weiß per Schwellwert) 
per SPI oder I2C mit dem Ergebnis zu versorgen. Mal schauen.

Wenn es nicht so funktioniert, wie ich mir es vorstelle wechsle ich doch 
auf den ATXMega und nutze DMA :-)

VG
Dieter

[Saturi (Gast)]

Guten Abend Dieter,

>Die Kamera braucht eine externe Frequenz
>von 10 bis 24 MHz. 8 MHz gehen auch, das habe ich ausprobiert und damit
>will ich (auf dem 328P) arbeiten.

Auch die Version mit FIFO?

Ich nehme an, dass du dich nicht durch die gesamte Unterhaltung gelesen 
hast :D (was ja auch niemand erwarten kann). Also es gibt von dem OV7670 
zwei Varianten. Eine ohne und einen mit Fifo. Ursprünglich sind wir mit 
der "ohne Fifo" Variante gestartet. Hier hatten wir aber die von dir 
angesprochenen "Timing"-Probleme, die jeweiligen Pixel Werte 
"aufzufangen". Wir haben auch die Clock-Rate reduziert, sind aber zu dem 
Ergebnis gekommen, dass -Aufgrund des für Kamera Leihen eh komplexen 
Themas- zumindest fürs erste die Variante mit FIFO der bessere Einstieg 
ist.

Mein Verständnis bis dato ist, dass ich den Fifo einen ganzen Frame lang 
beschreiben lasse und danach das Schreiben verhinder. Dadurch liegt das 
Bild im FIFO und kann in aller Ruhe ausgelesen werden. Eine 
externe-Clock entfällt glaube ich ebenfalls, weil die intern über einen 
Oszillator auf dem Board getaktet wird. Müsste ich aber Zuhause nochmal 
checken.

Kannst du mir da zustimmen oder habe ich etwas völlig falsch verstanden?

Danke

lg. David

[Saturi (Gast)]

>kannst Du die Source für die PC-SW offen legen?

die würde ich Ungerne auf einer Plattform wie Github veröffentlichen. 
Ich stelle aber gerne jedem, der hier mittüfteln möchte den 
SourceCode/Projektdateien zur freien Verfügung.

Da würde ich vorschlagen einfach die E-Mail Adresse per PN an mich?

[Dieter F. (Gast)]

Saturi schrieb:
> Auch die Version mit FIFO?

Nein - das hätte mir eigentlich auffallen müssen ... :-/

Ich habe nur Kameras ohne FiFo (billig :-) ) und werde versuchen, damit 
klar zu kommen. Blöd - ist aber halt so, andere werde ich mir "just for 
fun" nicht kaufen.

Wenn man den Pixel-Takt weit genug heruntersetzt dürfte das auch ohne 
große Probleme funktionieren. Man muss halt ein wenig optimieren (z. B. 
Deine Bit-Schieberei zur Datenübernahme durch die Übernahme von 2 
Halbbytes ersetzen etc.).

Mal schauen, was so herauskommt ...

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Ich habe nur Kameras ohne FiFo (billig :-) ) und werde versuchen, damit
> klar zu kommen. Blöd - ist aber halt so, andere werde ich mir "just for
> fun" nicht kaufen.

hatte ich eigentlich auch, mein Bekannter hatte aber mal eine mit FiFo 
gekauft und auch nie wirklich genutzt. Die ist nun erstmal bei mir. :)

Es könnte prinzipiell ohne FiFo gehen, aber: soweit ich bisher gefunden 
habe, kann die Kamera keine Snapshot-Modus oder ich habe es bisher 
übersehen.
Wenn es so ist, kann man den Kamera-Speicher nicht in Teilstücken 
auslesen.

Sonst würde der Trick wie bei der (eigentlich genauso) alten DC3840 
gehen: Buffer abholen und Bytes mitzählen, 128 Byte übernehmen, 
rausschicken und dann den Buffer wiedér ab Anfang auslesen und mitzählen 
bis zu den nächsten 128 Byte. Die DC3840 gibt aber JPEG seriell mit 
921kBaud aus, das hat dann letztlich selbst ein Mega32 ohne Verluste 
einlesen und mitzählen können.

Ich schau da aber nochmal genauer ins Datenblatt der OV7670.

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Michael U. schrieb:
> soweit ich bisher gefunden
> habe, kann die Kamera keine Snapshot-Modus oder ich habe es bisher
> übersehen.
> Wenn es so ist, kann man den Kamera-Speicher nicht in Teilstücken
> auslesen.

Muss ja auch nicht. Wenn man den Pixel-Takt mit Prescaler 32 (eigentlich 
31 + 1 Vorgabe) versieht, dann hat man (bei 16 MHz Systemtakt und 8 MHz 
Kamera-Takt) 64 Zyklen Zeit, ein Byte zu "verwursten". Das sollte 
eigentlich ausreichen. Das sind dann halt keine 30 FPS mehr sondern eher 
rund 0,5 FPS :-). Von da an kann man sich "hochtasten" und optimieren - 
mal schauen, wie weit das möglich ist.

[Michael U. (amiga)]

Hallo,

64 Zyklen reichen aber nicht, um das Byte zu "verwursten". Du mußt das 
ja irgendwohin befördern, also z.B. seriell senden. Ram ist ja nicht 
genug da.
Wenn Du es direkt in den UART schickst, bist Du bei mehr als 1MBaud.
Ich laß mich da aber gern überraschen.

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Michael U. schrieb:
> Wenn Du es direkt in den UART schickst, bist Du bei mehr als 1MBaud.

1MBaud habe ich schon mal übertragen, 2MBaud kann der ATMega328 max. - 
schaun mer mal :-)

Ich will eigentlich auch gar nicht an den PC übertragen - das ist für 
mich ziemlich sinnfrei, da es billige USB-Kameras gibt. Aber als poc 
irgendein LCD ansteuern hat für mich "Charme" :-). Da werde ich mir ein 
mit SPI ansteuerbares Teil suchen (aus meinem Fundus) und das Bild als 
s/w-Krüppel oder auch in Farbe ausgeben.

Um das zu erreichen muss man die Register der Kamera verstehen und 
korrekt einstellen können. Ich lese mich noch ein und spiele herum :-). 
Dauert etwas, da ich auch noch "andere Regierungsaufgaben" habe.

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Ich will eigentlich auch gar nicht an den PC übertragen - das ist für
> mich ziemlich sinnfrei, da es billige USB-Kameras gibt. Aber als poc
> irgendein LCD ansteuern hat für mich "Charme" :-). Da werde ich mir ein
> mit SPI ansteuerbares Teil suchen (aus meinem Fundus) und das Bild als
> s/w-Krüppel oder auch in Farbe ausgeben.

ok, als Vorhaben akzeptiert, ich wünsche Dir Erfolg und laß mich etwas 
teilhaben. Display vielleicht das 1,8" 128x160 mit dem ST7735 
Controller, wenn es in Deinen Vorräten ist.

Dieter F. schrieb:
> Um das zu erreichen muss man die Register der Kamera verstehen und
> korrekt einstellen können. Ich lese mich noch ein und spiele herum :-).

Naja, da diskutiere ich auch noch mit der OV2640 am ESP32 rum, 
allerdings basierend auf dem Espresif-Demo. Mir ist da die Umschaltung 
der Auflösung noch nicht sauber gelungen, irgendwelche anderen 
Registereinstellungen müssen da wohl auch noch angepasst werden.

Vielleicht probiere ich auch Deine Idee einfach mal aus...

Gruß aus Berlin
Michael

[David D. (saturi)]

Hallo,
ich bin zurück und wieder voller Tatendrang. Habe den Morgen auch damit 
verbracht, einen Fehler im Timing des Fifos zu suchen und.... siehe 
da... Da habe ich wohl im Eifer meines Code umwerfens vergessen die 
funktion zum "read pointer reset" aufzurufen..... kein Wunder, dass nur 
unreproduzierbarer Müll rauskommt....

Jetzt "reagiert das Bild wenigstens auf Abdunkeln und Belichten der 
Kamera.
Aber irgendetwas scheint trotzdem nicht zu funktionieren...

ich habe jetzt probeweise das Beschreiben des FIFOs deaktiviert. jetzt 
sollte ja nach meinem Verständnis immer das gleiche Bild beim Auslesen 
erscheinen (auch wenn man weniger von Bild als von Muster reden sollte). 
Tut es aber leider nicht. Daher die Frage:
Hat jemand von euch schon Erfahrungen mit dem AL422B gemacht? oder kann 
mir sagen worauf ich achten muss?

> Dauert etwas, da ich auch noch "andere Regierungsaufgaben" habe.
:D schön formuliert... das geht mir leider auch schon so...

[Andreas S. (igel1)]

Hi David, Michael U. und Dieter F.,

ich habe inzwischen eigentlich alles Zeugs zusammen, um David's 
Schaltung nachzubauen (siehe Foto), aber ich bringe es einfach nicht 
über's Herz, meine sauer erkämpften, wenigen freien Bastelstunden in 
AVR-Technik zu investieren - bitte seht's mir nach.

Wer einmal ARM gemacht hat, will nie wieder zurück ...

Also werde ich versuchen, den AL422B am ganz oben abgebildeten STM32F4 
Discovery Board (mit einem STM32F420ZI ARM-Prozessor) ans Laufen zu 
bringen. Ich habe dieses Board mit Absicht gewählt,

a) weil ich es herumliegen hatte,
b) weil ein ARM-Prozessor draufsteckt,
c) weil es auf 3,3V läuft und ich keine Level-Shifter benötige,
d) weil dort schon ein  ILI9346-Display draufklebt.

Mit dem Display kann ich die Ergebnisse etwas einfacher und direkter 
testen und spare weiteres Kabel-Wirrwarr.

Bitte seid trotzdem nicht traurig, denn ich werde ja dieselben 
AL422B/OV7670-Protokollhürden zu nehmen haben, wie Ihr.
Wir können also trotzdem alle voneinander lernen (wenn ich denn 
überhaupt etwas zustande bringe ...).

Mal sehen, wie weit ich komme - tempus fugit.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> ich habe inzwischen eigentlich alles Zeugs zusammen, um David's
> Schaltung nachzubauen (siehe Foto), aber ich bringe es einfach nicht
> über's Herz, meine sauer erkämpften, wenigen freien Bastelstunden in
> AVR-Technik zu investieren - bitte seht's mir nach.

ich kann mir da zwar mehr Zeit für die Geschichte nehmen (obwohl, 
Rentner haben niemals Zeit...), trotzdem wird sich meine Beteiligung ja 
auch auf Nachvollziehen seiner Versuche und Hilfestellung bei 
Fehlersuche u.ä. beschränken. Ich finde für die OV7670 am AVR für mich 
einfach keinerlei praktischen Nutzen, die Teile liegen aber rum, seine 
Software zu flashen und mal reinzuschauen, sehe ich da nicht als Aufwand 
an.
Wie schon mehrfach erwähnt, habe ich ja die OV2640 am ESP32 als 
aureichende Beschäftigung, obwohl die z.Z. wegen anderer "Projekte" auch 
mehr rumliegen.

Ein Display direkt an der Kamera wäre da auch bei mir nur zum 
Experimentieren sinnvoll, mit den kleinen OV2640/ESP32 Modulen kann ich 
die Bilder per WLAN verschicken und den Odroid Go als Monitor. Das läuft 
ja prinzipiell auch schon, nur nicht so, wie ich es mir vorstelle. ;)
Die Links zu dem Kram hatte ich nja im Thread scon mal gepostet.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

> Mal sehen, wie weit ich komme - tempus fugit.

So, der Tag ist mehr als vorbei ...

Zwischenergebnis:

- Mein STM32F429I Discovery-Board ist präpariert (ich musste erst einmal
  den ST-Link in einen J-Link umflashen (ARM-Insider werden verstehen,
  was ich damit meine)

- Sodann habe ich erstmals eine für mich neue IDE - nämlich Embedded
  Studio von SEGGER ausprobiert (wow - unglaublich das Teil!).
  Zum Glück war der Umstieg von meiner alten IDE (emIDE) nicht
  wahnsinnig schwierig, da sich beide ziemlich ähneln.

- Sodann ging's ans Code-Migrieren:
  LCD-Display kann ich ansteuern, d.h. Pixel kann ich einzeln setzen
  Später will ich den FiFo auslesen und auf das Display schreiben -
  erstmal Pixel für Pixel.

- Die Verkabelung hat ewig gedauert:
  OV7670+AL422B-FiFo sind teilweise mit dem Board verbunden.
  VCC, GND, SIOC, SIOD, VSYNC, HREF - mehr noch nicht.

- SCCB scheint zu funktionieren.
  Auslesen von Registerwerten ergibt plausible Ergebnisse.
  Zum Schreiben von Registern hatte ich noch keine Zeit.

Bevor David jetzt ganz blass wird: nein - ich war nur deshalb so 
schnell,
weil ich ja vor >1 Jahre schon einmal die OV7670 Camera an einem
identischen Board so halb am Laufen hatte.

Habe also hauptsächlich Coderecycling betrieben und mich mit dem
Aufsetzen von Dingen beschäftigt, die in meiner alten IDE schon
liefen, in der neuen aber noch nicht.

Das Tolle an ARM und der verwendeten IDE:

- Ich kann nun hardwarmäßig debuggen (und dabei Register und Variablen
  auslesen)
- Ich kann print-Statements verwenden - Ausgabe landet im Debugger
- Flashen geht sehr schnell (<2s)

Jetzt kann ich als nächstes das Auslesen des FIFOs angehen.
Wenn jemand Lust hat, mir die Vorgehensweise dafür zu schildern,
so würde das vermutlich viel Zeit und Recherche ersparen.

Aber jetzt fängt erst einmal die Woche wieder an und das Büro
freut sich auf mich.  Das heißt: Adieu OV7670 ...

Viele Grüße

Igel1


PS: @Michael U. : ja, Du bist offensichtlich in Sachen Kameras ein
ganzes Stückchen weiter als wir - nett, dass Du hier Tipps gibst!

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> - Mein STM32F429I Discovery-Board ist präpariert (ich musste erst einmal
>   den ST-Link in einen J-Link umflashen (ARM-Insider werden verstehen,
>   was ich damit meine)
Das hättest Du nicht schreiben sollen... ;)
Ich habe da als ARM-Outsider bestimmt noch mal eine Frage an Dich.
Ich mußte wiedermal sinnlos Geld ausgeben:
Beitrag "Arduino Custom Firmware für Fitness Armband mit NRF52"

Andreas S. schrieb:
> PS: @Michael U. : ja, Du bist offensichtlich in Sachen Kameras ein
> ganzes Stückchen weiter als wir - nett, dass Du hier Tipps gibst!

Es ist nur Spaß am Experimentieren. Meine erste echte Kamera-Begenung 
war eine TFK500
https://www.google.com/search?q=Kamera+TFK500&tbm=isch&source=univ&client=firefox-b&sa=X&ved=2ahUKEwjovKOz_I_gAhVNYlAKHVgADb0QsAR6BAgGEAE&biw=1484&bih=840
Dazu ein diskreter 4 Bit AD-Wandler mit 2 Komparatoren und Zählerlogik 
am Userport vom C64. Nach rund 3 Minuten hatte ich dann ein Bild 160x200 
mit 4 Graustufen. Gibt es leider nichts mehr davon, muß um 1988 gewesen 
sein.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hi David, hi Leute,

nach Studium des Datenblattes vom AL422B:
(https://www.enrgtech.co.uk/buy/product/ET16818568/AL422B-PBF)
(Achtung: achtet darauf, irgendwo die aktuellste Version aufzutreiben)

... bin ich jetzt doch einigermaßen irritiert.
Dort steht zu lesen:

8.3.1 Irregular Read/Write
It is recommended that the WCK and RCK are kept running at least 1MHz at all times. The faster one of WCK and RCK is used as the DRAM refresh timing clock and has to be kept free running. When irregular FIFO I/O control is needed, keep the clock free running and use /WE or /RE to control the
I/O as follows:    [... dann folgt ein Bild ...]

Außerdem lese ich in Kapitel "7.4 AC Characteristics":

Trc (RCK Cycle Time)   min. 20   max. 1000 ns

Da Trc laut den nachfolgenden Bildern die Periodenlänge von RCK, also 
der Read Clock ist, bedeutet das eindeutig:

Der minimale Takt zum Auslesen der AL422B beträgt 1MHz.

Das würde den gesamten Vorteil, den der FiFo bringen soll: nämlich 
schnelles einlesen der Daten von der Kamera und (beliebig) langsames 
Auslesen der Daten aus dem FiFo durch den Mikrocontroller ad absurdum 
führen.

Wäre wenigstens der "Read Enable" Pin [/RE] auf dem Modul nach draussen 
geführt, so könnte man den Auslesevorgang zumindest ab und an anhalten, 
um kurz Luft zu schnappen (dabei liegt der Lesetakt weiterhin am AL422B 
an, aber dessen Adresszähler wird angehalten). Das ist allerdings nicht 
der Fall - schöne Fehlkonstruktion.

Da Dein ATmega 328p zudem kaum Speicher hat, müsstest Du Daten somit 
mehr oder weniger mit dieser Rate auch über den UART schicken.
Ist das so von Dir geplant?

Hmmm ... bin ratlos bis irritiert, wie Du mit dem AL422B das 
Geschwindigkeits-Bottleneck des Prozessors umschiffen kannst. Das könnte 
schwierig werden - zumindest, wenn Du die Spezifikation einhalten 
möchtest.

Allerdings will ich nicht ausschließen, dass ich mich irgendwo 
dramatisch vertan habe - mir kommt diese  1MHz-Beschränkung im Read 
Clock absolut spanisch vor, denn der Refresh-Zyklus für das DRAM im 
AL422B wird angeblich vom jeweils höheren Takt (also WCK oder RCK) 
abgeleitet.

Da sollte es dem DRAM doch egal sein, wenn der RCK-Takt z.B. nur mit 
1KHz getaktet wird - solange WCK > 1MHz ist. Dumm dabei ist nur, dass 
das Datenblatt etwas anderes sagt, nämlich "It is recommended that the 
WCK and RCK are kept running at least 1MHz at all times." Dort steht 
expliztit NICHT "WCK or RCK are kept > 1MHz" sondern "WCK and RCK are 
kept > 1MHz".

Soweit die schlechten Nachrichten.

Und nun die guten Nachricthen: wenn Du auf die Spec pfeifst, so fand ich 
hier einen Bericht von jemandem, der den AL422B angeblich super langsam 
ausgelesen hat (so jedenfalls seine Worte):
https://www.eevblog.com/forum/microcontrollers/how-to-reduce-the-data-rate(ov7670-al422b(fifo)-camera-module)/msg314703/#msg314703

Und hier sein Projekt:
http://www.rpg.fi/desaster/blog/2012/10/20/ov7670-fifo-msp430-launchpad/

Da ich gerade bin bisschen zu bequem bin, Deinen Code zu lesen, frage 
ich einfach mal: mit welcher Taktrate liest Du den AL422B aus?

Sollte die Rate < 1MHz liegen, so frage ich direkt: hast Du dabei 
Bedenken, oder kennst Du andere Berichte, die ebenfalls mit niedrigerer 
Taktrate erfolgreich ausgelesen haben?

Und noch etwas: ich habe einen 12MHz Quarz auf meinem OV7670+FiFo AL422B 
- Modul entdeckt. Habt Ihr auch einen 12MHz Quarz oder habt Ihr 
tatsächlich einen 24MHz Quarz?  Es scheinen da einige unterschiedliche 
Modul-Versionen im Umlauf zu sein ... mit jeweils unterschiedlichen 
Schaltbildern.

So scheint bei mir z.B. kein Widerstand zwischen SDA (bzw. SIO_D) und 
VCC zu stecken - hab's nachgemessen. Ich vermute daher eher, dass ich 
dieses Modul hier habe:
http://www.haoyuelectronics.com/Attachment/OV7670-Module-A/CMOS_FIFO%20schematic.pdf

Welches Modul habt Ihr?

Fragen über Fragen - wäre supernett, wenn Ihr ein paar meiner Fragen 
beantworten könntet, dann können wir uns etwas besser 
"aufsynchronisieren".

Viele Grüße

Igel1

[Dieter F. (Gast)]

Andreas S. schrieb:
> Und nun die guten Nachricthen: wenn Du auf die Spec pfeifst, so fand ich
> hier einen Bericht von jemandem, der den AL422B angeblich super langsam
> ausgelesen hat (so jedenfalls seine Worte

Ich lese das etwas anders - er hat das Bild super-langsam an den PC bzw. 
das dortige Python-Programm gegeben. Gelesen hat er mit seinem schnellen 
MSP ...

"120mhz with 64KB memory), which was necessary to be able to process the 
signals in time."

[Andreas S. (igel1)]

@Dieter F.:

Bitte den gesamten Absatz lesen, dort steht:

In my previous experiment I used a quite powerful LPC1769 microcontroller (running at

120mhz with 64KB memory), which was necessary to be able to process the signals in time.

This time however, thanks to the FIFO memory, the heavy hardware requirements are gone. For this reason I thought it might be fun to use the least powerful MCU I have around, which happens to be the MSP430.

=> Er hat das Auslesen mit einem MSP430 realisiert - das ist nun 
wahrlich keine Rennmaschine. Und im weiteren Verlauf ist zu lesen, dass 
er die Daten (die er ja kaum im MSP430 wird zwischenspeichern können) 
via UART bei gemütlichen 115200 baud überträgt.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

na toll, ich soll also Datenblatt lesen... ;)
AL422B Revision 1.5 biete ich erstmal als Datenblatt an?
Mindesttakt ist erstmal schon klar, ist ja DRAM drin.
Erfahrungsgemäß halten die die Daten auch, wenn man relativ lange nicht 
refresht. Müßte man mal Testen, einfach mehrfach auslesen und 
vergleichen mit anhalten von RCK/WCK für verschiedene Zeiten.
Beleibt beim C64: Bild laden und anzeigen. C64 aus und wieder ein und 
den VIC-Zeiger wieder auf die Grafik und schauen, wieviel schon kaputt 
ist.
1s klappte eigentlich immer ohne gekippte Bits...

Ich muß mir das aber alles erstmal anschauen.
Als Gedankenansatz: RCK läuft durch. Mit /RRST Lesezeiger auf Anfang, 
128 Byte einlesen und verarbeiten. Dann wieder Lesezeiger auf Anfang, 
RCK mitzählen und die nächsten 128 Byte holen usw.
Das war im Prinzip die Version damals mit der DC3840 um die 921kBaud von 
der Kamera durch den AVR in den Websever zu schaffen und den 
Ethenet-Buffer des ENC rauszuschicken wenn der voll war.
Dauerte eben so seine Zeit, klappte aber zuverlässig.

PS: gestern erstmalig mit ST-Link "gekämpt", war ja bisher bei mir ARM 
dran oder eher ARM ab?

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Andreas S. schrieb:
> => Er hat das Auslesen mit einem MSP430 realisiert - das ist nun
> wahrlich keine Rennmaschine. Und im weiteren Verlauf ist zu lesen, dass
> er die Daten (die er ja kaum im MSP430 wird zwischenspeichern können)
> via UART bei gemütlichen 115200 baud überträgt.

Ja - zu schnell überflogen, sorry - bin "im Dienst" :-)

[Andreas S. (igel1)]

Michael U. schrieb:
> na toll, ich soll also Datenblatt lesen... ;)

Ja, ja - das Leben ist hart und ungerecht ... :-)

> AL422B Revision 1.5 biete ich erstmal als Datenblatt an?

Hui - scheint ziemlich neu - bitte mal hier verlinken.
Ist die Revision neuer als die hier:
https://www.enrgtech.co.uk/buy/product/ET16818568/AL422B-PBF   ?

> 1s klappte eigentlich immer ohne gekippte Bits...

Na ja - ich bin eigentlich ein Freund davon, innerhalb der Specs zu 
bleiben, denn sonst wird's unberechenbar.

> Ich muß mir das aber alles erstmal anschauen.
> Als Gedankenansatz: RCK läuft durch. Mit /RRST Lesezeiger auf Anfang,
> 128 Byte einlesen und verarbeiten. Dann wieder Lesezeiger auf Anfang,
> RCK mitzählen und die nächsten 128 Byte holen usw.

In der Tat: das war auch mein erster Ansatz, wenn man RCK durchlaufen 
lassen muss und keinen Zugriff auf /RE hat.

Unterm Strich vergeudet der Ansatz allerdings wahnsinnig viel Zeit, weil 
man z.B. 479 Zeilen lang warten müsste, um Zeile 480 von einem VGA-Bild 
ausgeben zu können.

Inzwischen kam mir folgender alternativer Ansatz in den Sinn:
Den Adresszähler des FiFo's ständig durch den FiFo "durchlaufen" lassen 
und ab und an (in regelmäßigen Abständen) immer wieder kleine 
Datenpakete herausnehmen und diese per UART übertragen.
Das wäre quasi ein Interleave-Verfahren:

Beispiel dafür:
Man geht wie mit einem Kamm durch einen Bilder-Frame im FiFo und kämmt 
z.B. Zeile 1, 11, 21, 31, ... 461, 471 heraus und überträgt jedesmal die 
besagte Zeile.

Für die Übertragung einer Zeile hat man in diesem Beispiel jeweils 
weitere 9 Zeilen Zeit, was sogar einigermaßen  passen würde, wenn die 
UART Baudrate 115200 beträgt und RCK mit 1MHz läuft.

Beim nächsten Durchlauf würde man dann die Zeilen 2,12,22,32, ...462, 
472 übertragen, u.s.w.

Selbstverständlich muss man nicht unbedingt ganze Zeilen in einem Rutsch 
übertragen, sondern wird die Anzahl der herausgepickten Daten an den 
verfügbaren Puffer des MC anpassen wollen.

Vorteil gegenüber dem ersten Ansatz: man kann die UART quasi dauerhaft 
"unter Feuer" halten und muss nicht 479 Zeilen lang auf Zeile 480 
warten.

> PS: gestern erstmalig mit ST-Link "gekämpt", war ja bisher bei mir ARM
> dran oder eher ARM ab?

Ich muss schon sagen: Du schreckst vor nichts zurück!
Willst Du Dich tatsächlich in ARM einarbeiten?
Wenn ja, so hätte ich vielleicht ein paar Tipps für Dich (wenngleich ich 
auch kein ARM-Profi bin): Einer der Tricks wäre, Dich nicht mit ST-Link 
abzugeben, sondern direkt den ST-Link auf Deinem Board (welches hast 
Du?) in einen J-Link umzuflashen. Übertrage einfach vor dem Flashen ein 
größeres Image in den ARM-Prozessor und nach dem Flashen nochmals, dann 
verstehst Du sofort einen der Gründe, warum J-Link so viel besser ist.

Auf den Seiten von Segger findest Du die passende Anleitung dafür:
https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

Schreibe mal, was Du mit ARM schon gemacht hast und was Du noch vorhast.

Viele Grüße

Igel1

[Andreas S. (igel1)]

Dieter F. schrieb:

> Ja - zu schnell überflogen, sorry - bin "im Dienst" :-)

Kein Problem: Du hast die ersten 3 Zeilen aus dem Artikel gelesen und 
ich die nächsten - das war klassische Arbeitsteilung :-)

[Michael U. (amiga)]

Hallo,

Link zum Datenblatt:
https://datasheetspdf.com/datasheet/AL422B.html
Hmmm scheinen identisch zu sein, nur meins heißt AL422B?

Deine FiFo Überlegungen gefallen mir auch, wenn ich das real teste dann 
schon aus Prinzip auf einem ATMega238. Ich muß mir das aber erst in Ruhe 
anschauen und mal Takte zählen.

Andreas S. schrieb:
>> PS: gestern erstmalig mit ST-Link "gekämpt", war ja bisher bei mir ARM
>> dran oder eher ARM ab?
>
> Ich muss schon sagen: Du schreckst vor nichts zurück!
> Willst Du Dich tatsächlich in ARM einarbeiten?

Siehe meinen Link weiter oben von 28.01.2019 09:05.

Ich will nicht direkt, aber alels, was sich aus der ArduinoIDE 
programmieren läßt, hat für mich erstmal eine sehr geringe 
Einstiegshürde.

Andreas S. schrieb:
> Schreibe mal, was Du mit ARM schon gemacht hast und was Du noch vorhast.

Nichts. Gestern viel mir dann noch ein, daß ich irgendwo mal ein 
Nucleo-Board gakauft hatte, das nach etwas suchen auch wieder 
auftauchte. Hat den Vorteil, daß ich also auch einen Original ST-Link 
verfügbar habe. Das China-Teil hat sich zwar ordentlich gemeldet, ließ 
sich aber nicht updaten. Nach der Fehlermeldung beim Update ist es auch 
nicht mehr erreichbar bis zum Abstecken/Anstecken.
Ist mir im Moment aber erstmal egal, die Uhr ist angekommen und lädt 
gerade Akku, dann kann ich sie in Ruhe kaputt machen. ;)
Das Nucloe-Board speilt zumndest mit der ArduinoIDE, wenn auch erstmal 
nur ein Blink-Sketch für die LED geflasht.
Ob ich da mehr mit den STM oder den nRF mache? Keine Ahnung.Ob ich mir 
da eine sinnvolle IDE für installiere hängt einfach von einem Projekt 
ab, das mir vielleicht noch in den Sinn kommt. Eigentlich bin ich aber 
mit dem ESP32 gut ausgelastet.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

@Michael U.:  Ja, mit dem Datenblatt hast Du den Vogel abgeschossen - 
scheint tatsächlich die neueste Version zu sein.

Was Deine NRF52832-basierende Uhr angeht, so scheint das ebenfalls ein 
interessantes Projekt zu sein - ach hätte der Tag doch nur 32 Stunden 
...

Aber nun back to business:

Habt Ihr schon einen Vorschlag für eine Reihenfolge, in der wir die 
Leitungen des OV7670+FiFo - Moduls ansteuern sollten, um:

1.) einen Frame aus dem OV7670 in den AL422B zu laden?
2.) den Frame aus dem AL422B wieder herauszulesen?
    (erst einmal ganz grundsätzlich N Bytes ab Adresse 0 herauslesen)

Ich würde diese Vorgehensweise gerne zunächst in Pseudocode 
aufschreiben, bevor ich loslege.

Alternativ könnte ich vielleicht auch einmal in David's Code spicken ...
(Wo ist eigentlich David abgeblieben?)

Viele Grüße

Igel1

[David D. (saturi)]

> (Wo ist eigentlich David abgeblieben?)

Der baut gerade schon wieder Überstunden auf... und die Pendellei killt 
den Rest vom Tag... Wenn man dann noch im Sportverein tätig ist schafft 
man es an den heimischen PC erst um 23:30 :D...

Aber auf euch ist ja Verlass und ich bin begeistert über eure Einwände 
und Vorschläge.

Was mir nicht bewusst war, war die sache mit dem DRAM und dass der FIFO 
offenbar den Inhalt verliert.... darüber habe ich mir nie Gedanken 
gemacht und war der Meinung der Reset meines Read Pointers funktioniert 
nicht... -->Anfänger... Hier fehlen mir wohl noch die Grundlagen, die 
ich mir dann wohl die nächsten Tage versuche anzulesen.

Was das Datenblatt angeht hatte ich Version 1.01... somit werde ich dann 
jetzt auch mal auf das neue umsteigen.

Was die Frequenz des Betreiben angeht, habe ich mich an folgenden Satz 
geklammert:
"...The faster one of WCK and RCK is used as the DRAM refresh timing 
clock and has to be kept free running."

Das dann folgende Bild, schildert ja genau, wie man das Schreiben im 
irregular Mode dann händeln soll. Ich habe es dann naiv einfach 
angenommen, dass der auf dem Board verbaute Quarz (bei mir sind es auch 
12MHz) die WCK steuert und die dann automatisch die schnellere ist. Das 
mit dem Write and Read (und nicht Or) ist mir auch schon aufgefallen, 
habe aber gehofft, dass dem einfach keine Beachtung geschenkt wurde.

>Sollte die Rate < 1MHz liegen, so frage ich direkt: hast Du dabei
>Bedenken, oder kennst Du andere Berichte, die ebenfalls mit niedrigerer
>Taktrate erfolgreich ausgelesen haben?
Bedenken habe ich keine :D Dafür fehlen mir einfach sämtliche 
Erfahrungswerte. Die Read rate liegt mit sicherheit unter 1Mhz, weil ich 
jede Zeile zunächst per Uart an den PC übertrage, wenn diese vollständig 
übertragen wurde, vom PC die nächste anfordere und dann erst sende.

Aber da war mir die Sache mit dem flüchtigen Speicher noch nicht ganz 
klar. Dass werde ich mir (hoffentlich morgen) einmal anlesen. Werde auch 
gerne kurz erläutern wie es in meinem Code abläuft, damit ihr in dem 
Wirrwarr nicht lange suchen müsst ;-) aber jetzt bin ich erstmal reif 
fürs Bett.

[David D. (saturi)]

Guten Tag,
eine weitere Sache, die mir grade bei dem Studium des Datenblattes 
auffällt:

Kapitel 8.3.2 Read Enable during Reset Cycles

hier steht, dass der Read Enable während des RRST niemals low sein darf.

Bei mir auf dem board ist der Pin garnicht nach außen geführt und wird 
somit von mir auch nicht gesteuert.

Weiß da jemand was?

Gruß David

[Andreas S. (igel1)]

David D. schrieb:
> eine weitere Sache, die mir grade bei dem Studium des Datenblattes
> auffällt:
>
> Kapitel 8.3.2 Read Enable during Reset Cycles


Das ist Dir vermutlich deshalb nicht eher aufgefallen, weil genau dieses 
Kapitel in  älteren Versionen des Datenblatts fehlte ... (daher hatte 
ich so geflissentlich auf die neueren Versionen verwiesen).

> hier steht, dass der Read Enable während des RRST niemals low sein darf.
>
> Bei mir auf dem board ist der Pin garnicht nach außen geführt und wird
> somit von mir auch nicht gesteuert.
>
> Weiß da jemand was?

Ich kann Deine Beobachtung leider nur bestätigen (scharfes Auge, 
Kollege!):

In der Tat ist der /RE Pin auch auf meinem Modul dauerhaft auf GND 
gezogen (hab's gerade mit dem Multimeter nochmals geprüft). Somit dürfte 
man lt. Datenblatt den /RRST niemals benutzen.

Das bedeutet im Klartext: unser Board hat einen Designfehler.
Da wir diesen ohne riesigen Lötaufwand wohl kaum beheben können,
bleibt uns keine Wahl, als damit zu leben.  Immerhin sind wir
jetzt gewarnt und wissen, dass wir bei der Benutzung von /RRST
evtl. nicht das von uns erwartete Ergebnis erhalten werden.

Viele Grüße

Igel1

[David D. (saturi)]

Das kann ich leider nur Bestätigen. Bei betrieb habe ich noch eine 
Spannung von 0.2 V an dem Pin anliegen. Und auch in der Schematic die 
ich gefunden habe:

https://www.beyondlogic.org/pdf/OV7670_FIFO_SCH_V1.pdf

wird ~RE auf GND gezogen...
Wie gehen wir jetzt weiter vor? :D

Edit: Altes Datenblatt Seite 18 könnte uns retten. Allerdings finde ich 
diese Beschreibung im neuen nicht mehr.... Das ist doch zum Mäuse melken 
:D

"8.3.4 One Field Delay Line (The Old Data Read)
As the design shown in diagram by applying the reset every 1-field cycle 
(with the common signal for
/WRST and /RRST) and a constant read/write operation (with all /WE, /RE 
and /OE are tied to
ground), “1 field delay line” timing is shown in timing chart below"

[Michael U. (amiga)]

Hallo,

ihr seid also fleißig beim Datenblatt lesen.
Ich habe im Moment nur mal recht kurz durch die (Arduino-)Welt geschaut.
a) die OV7660 mit FiFo ist so aufgebaut, weil irgendjemand das mal so 
beschlossen hat.
Ich habe bisher nur diese Modulversion gefunden, wo /RE fest auf GND 
ist.
b) Der FiFo hat offenbar sein Datenblatt nicht gelesen.
Demo-Souzrce, wo ich auf die Schnelle mal reingeschaut habe, ignorieren 
das und setzen den Pointer trotzdem mit

   digitalWrite(RRST, LOW);
   PulsePin(RCLK, 1); 
   PulsePin(RCLK, 1);
   PulsePin(RCLK, 1);

void PulsePin(int PinNumber, int DurationMicroSecs)
{
  digitalWrite(PinNumber, HIGH);           // Sets the pin on
  delayMicroseconds(DurationMicroSecs);    // Pauses for DurationMicroSecs microseconds      
  
  digitalWrite(PinNumber, LOW);            // Sets the pin off
  delayMicroseconds(DurationMicroSecs);    // Pauses for DurationMicroSecs microseconds  
}

auf Anfang.
Auch die Clockverhältnisse von RCLK werden ziemlich ignoriert...
Ich hoffe, auch nicht-Arduino-User können den Ausschnitt so verstehen.
Ich habe mir da mal ein Beispiel rausgepickt und werde mir das wohl 
morgen mal praktisch anschauen, mal schauen, ob mein LA mit 80MHz da 
noch schnell genug ist.

Ich denke, wir sollten da erstmal mit den Gegebenheiten leben, es 
scheint kein wirkliches Problem zu sein.

@Andreas S. (igel1): bisher ist noch ARM dran. Die Uhr lebt noch und der 
Testketch aus dem anderen Thread ist drauf und läuft. Jetzt habe ich das 
Problem: was will ich eigentlich damit??? Mein Handy findet auch beim 
Scan das BT-Device, da muß mich mich auch erst schlau machen, was ich 
damit jetzt anfangen kann...

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hi David, Michael (und eventuell auch ein bisschen Dieter, wenn Du noch 
dabei bist),

habe inzwischen alles vorbereitet, um den Stier bei den Hörnern zu 
packen:

- Das OV7670+FIFO - Modul ist mit meinem STM32F429 Discovery Board 
verkabelt. Das war bislang der zeitaufwändigste Akt von allem, denn fast 
alle Pins des MC's sind bereits mit irgendwelcher Peripherie auf dem 
Testboard verbunden. Das muss man sich erst einmal 17 Pins, die ich für 
Ansteuerung und Auslesen des OV7670+FiFo benötige, aus den Rippen 
schneiden. Hoffe, ich habe keine Fehler gemacht, sonst ist mein schönes 
Board dahin.

- Inzwischen läuft auch Timer1 (von insgesamt 17 verfügbaren Timern!) 
auf dem STM32F429 im PWM-Mode und wirft mir einen schönen 1MHz-Takt 
raus, den ich in FIFO_RCK einspeise.

- SysTick-Timer ist ebenfalls aufgesetzt - damit habe ich auch eine 
schicke Delay(ms)-Funktion.

- Funktionen zum Pixelweisen Beschreiben des LCD's habe ich ebenfalls 
(okay, nicht selbst geschrieben, sondern ausgeliehen - vgl. eines meiner 
letzten Postings).

- Sodann habe ich die folgenden Funktionen implementiert:

void InitControlPins();
uint8_t Read_VSYNC();
uint8_t Read_HREF();
uint8_t Read_FIFO_Data()
void Write_FIFO_WR(BitAction BitVal);   // BitVal: Bit_SET  or  BIT_RESET                               
void Write_FIFO_OE(BitAction BitVal);   // BitVal: Bit_SET  or  BIT_RESET                             
void Write_FIFO_WRST(BitAction BitVal); // BitVal: Bit_SET  or  BIT_RESET                             
void Write_FIFO_RRST(BitAction BitVal); // BitVal: Bit_SET  or  BIT_RESET

Ich hoffe, ich habe nichts vergessen ...

Das Brot- und Buttergeschäft ist also erledigt, jetzt kann der schönere 
Teil beginnen: nämlich die eigentliche Logikimplementierung.

Nur leider ruft jetzt, wo's gerade spannend wird, schon wieder die 
Pflicht  ...
Aber so ist das mit dem Hobby - es kommt irgendwie immer zu kurz - 
jedenfalls gefühlt :-)

Bis denne

Igel1



PS: @Michael: Du hast eine Fitnessuhr erworben und fragst "Jetzt habe 
ich das Problem: was will ich eigentlich damit???" Hmmm, ich würde 
vorschlagen, Du machst ein bisschen Fitness damit ... 
(Programmier-Fitness oder körperliche Fitness - das überlassen wir jetzt 
mal Dir :-)

[Dieter F. (Gast)]

Andreas S. schrieb:
> (und eventuell auch ein bisschen Dieter, wenn Du noch
> dabei bist)

Bin ich - nur langsamer und ohne Fifo :-)

Ich lese auch Datenblätter und überlege, wie ich am Besten vorgehe. Für 
mich ist der Fifo nur ein Hilfsmittel, um langsamer auslesen zu können. 
Alles andere - speziell die Ansteuerung der Kamera - sollte sich nicht 
sehr unterscheiden.

[Andreas S. (igel1)]

Hallo Dieter,

schön, dass Du noch mit dabei bist!

Kameraansteuerung mit SCCB funktioniert schon bei mir.

Aber an den richtigen OV7670-Registerwerten wäre ich wahnsinnig 
interessiert!!

Mit "richtig" meine ich solche Registerwerte, die gute Bilder geben, 
denn da kann man bei der OV7670-Kamera ja problemlos an 200 mehr oder 
weniger undokumentierten Schrauben drehen.

Habt Ihr solche Werte schon irgendwo im Netz abgreifen können?
Selberforschen ist mit diesen OV7670-Datenblättern wie 
Blinde-Kuh-Spielen.

Und der neugierdehalber:

Wie/womit programmierst Du?
Mit Arduino-IDE auf Arduino-Nano (so wie David, unser Eiskalt-Duscher)?
Oder mit Atmel-Studio in Assembler auf dem größten ATmega, den es gibt? 
(das wäre eher die Lauwarm-Duscher Variante).

Ich selber bin mit meinem 180MHz ARM-Prozessor natürlich ein 
Voll-Warmduscher :-)

Viele Grüße

Igel1

[Dieter F. (Gast)]

Andreas S. schrieb:
> Wie/womit programmierst Du?

Um kompatibel zu sein mit C und Atmel Studio auf ATMega328P (Arduino 
Nano Hardware) - das ist zwar eine Krücke, aber auch eine 
Herausforderung :-). Normalerweise würde ich mit ausreichend Ports und 
DMA arbeiten (ATXMega) oder idealerweise einen STM mit entsprechender 
Anschlussmöglichkeit (es gibt welche mit "Kamera-Schnittstelle") nutzen 
- aber STM ist mir nicht geläufig und nur zum Spaß will ich mich da auch 
nicht einarbeiten.

Es haben sich schon viele mit der Ansteuerung beschäftigt und fast alle 
nutzen Vorarbeiten von anderen (Register-Definitionen und -Werte) - da 
ist ein weites Feld.

Noch bin ich nur am "rumspielen" und lesen - aber eine "normale" 
TWI-Anbindung funktioniert gut und mit 8MHz externem Takt läuft die 
Kamera auch ohne Probleme.

Wie geschrieben suche ich nach Möglichkeiten, ohne Fifo mit dem 328P 
"vernünftige" Bilder zu bekommen und vielleicht wenigsten 1 FPS zu 
erreichen (ggf. interleaved, wie geschrieben).

[Michael U. (amiga)]

Hallo,

ich famge mal hier an:
Dieter F. schrieb:
> Wie geschrieben suche ich nach Möglichkeiten, ohne Fifo mit dem 328P
> "vernünftige" Bilder zu bekommen und vielleicht wenigsten 1 FPS zu
> erreichen (ggf. interleaved, wie geschrieben).

Ich hatte gestern meine alten Links mal durchgeschaut, die ich da mal 
gesammelt hatte. Dabei fielen mir zwei wieder auf auf:

https://www.instructables.com/id/OV7670-Arduino-Camera-Sensor-Module-Framecapture-T/

http://privateblog.info/arduino-uno-i-kamera-ov7670-primer-ispolzovaniya/

Beide haben für uns meiner Meinung nach ein paar Vorteile als Anregung: 
es ist alles im Stück, es ist relativ überschaubar gegliedert, sie 
benutzen einen Mega328, sie benutzen OV7660 ohne FiFo. Ich werde wohl 
heute mal testen, was da real geht.

Andreas S. schrieb:
> Und der neugierdehalber:
>
> Wie/womit programmierst Du?
> Mit Arduino-IDE auf Arduino-Nano (so wie David, unser Eiskalt-Duscher)?
> Oder mit Atmel-Studio in Assembler auf dem größten ATmega, den es gibt?
> (das wäre eher die Lauwarm-Duscher Variante).
>
> Ich selber bin mit meinem 180MHz ARM-Prozessor natürlich ein
> Voll-Warmduscher :-)

Ich trenne hier mal etwas anders: Eiskalt-Duscher als Prinzip für 
"siehste, es geht doch!" bei mir. Beim ATMega kpönnte ich auch auf den 
Mega1284 ausweichen, der größte, der hier rumliegt, da lassen sich fast 
alle auch stabil bis 25MHz übertakten (Mega328 meist auch).
Xmega gibt es hier irgendwo einen der ersten (XPlain Demoboard, gekauft, 
kurz angetestet, nie was mit gemacht...).
Nächste mögliche Runde wäre ein ST-Nucleo (habe ich ja 
wiedergefunden...) oder eben meine "geliebten" ESP32.
ArduinoIDE ist eine Entscheidung zur Bequemlichkeit incl. der 
Einschränkungen. Bei AVR spielt es eigentlich keine Rolle, 
Studio-Sourcen lassen sich mit wenig Aufwand in die ArduinoIDE werfen 
und compilieren, Sketchordner "projektname" anlegen, alles wahllos da 
reinkopieren, die main.c in "projektname.ino" umbenennen, bei den .h 
Dateien noch einen Vorrat C++ - extern c Klammerei rumwerfen und dann 
geht es zu 99% schon.
Ist nicht schön, aber selten...
Für den ESP32 und die IDF-Projekte gilt prinzipeill das Gleiche, der 
Anpassungsaufwand ist aber etwas größer.
Mit STM32 habe ich das wegen der kurzen Erfahrung mit Nucloe bzw. der 
nRF5-Uhr noch nicht probiert.
Großer Vorteil für mich: nur eine "IDE" für alles, mit externem 
NotePad++ als Editor auch durchaus praktikabel. Man kann portable 
einfach mehrere auf dem Rechner haben und macht sich den Kram nicht 
gleich kaputt, weil man mal was ausprobiert.
So, genug der Arduino-Werbung...

Der Übergang zu Lauwarm-Duscher und Voll-Warmduscher wäre also eher 
fließend. Beim STM32 wäre es interessant, Du kannst mir ja mal Deinen 
STM-Code schicken und die Pinbelegung, wäre interessant, was  da unter 
Arduino passiertt.

Andreas S. schrieb:
> Aber an den richtigen OV7670-Registerwerten wäre ich wahnsinnig
> interessiert!!

"Richtige" Registerwerte findest Du doch zu Hauf im Netz, schwieruger 
ist es, halbwegs brauchbar kommentierte Init-Sequenzen zu finden, das 
halte ich aber für ein grundsätzliches Problem. Mir sind schon genug 
Applikation-Beispiele für relativ komplexe ICs von den Hersteller 
begegnet, wo 50 Register initialisiert wurden und bei 45 davon keinerkei 
Kommentar stand, so nach der Devise "das muß man eben bei unserem Chip 
so machen".

Ich habe mir bei meinen privaten Basteleien abgewöhnt, alles bis ins 
kleinste Detail zu hinterfragen.

So, Roman zu Ende...

Gruß aus Berlin
Michael

[Michael U. (amiga)]

Hallo,

so, Roman 2.Teil, diesmal zum Thema:
das Programm von
http://privateblog.info/arduino-uno-i-kamera-ov7670-primer-ispolzovaniya/
compiliert bei mir nicht sinnvoll, einige Meckereien, zu groß für den 
Mega328. Ein Versuch, für den Mega2560 zu compilieren endete auch 
tragisch, ich hätte auch keinen hier gehabt.

Also den anderen Link, ist ohnehin ausführlicher für mich.
Sketch compiliert ohne Probleme, auf einen Arduino Nano geflasht.
Nichts... Ein paar Debug-Ausgaben hinzugefügt: arduinounoinut() läuft 
durch, XClock, TWI und UART sind richtig initialisiert, mein eingefügtes 
"Ready" kommt im Ternimal sauber an.
Hänger war bei camInit() und da beim ersten wrReg().
Logisch, wenn ich SDA und SCK vertauscht habe...
Umsortiert und es kommen erstmal Massen an Daten im Ternimal an.
Ich habe in SDA/SCK/XCLK Pegelwandler drin, weil die sowieso noch auf 
dem Steckbrett waren vom letzten Versuch vor Ewigkeiten.

TeraTerm kann zwar prinzipiell 1MBaud und die Daten mitloggen, die 
Anzahl Daten zwischen zwei RDY passten aber nicht zu den erwarteten. 
Entweder ich bringe sein Java-Zeug mal in Gang (hane nichtmal ein 
SunJAVA drauf zur Zeit...) oder ich nehme mein letztens wieder 
installiertes uraltes VN6 und meine LogicAnalyzer-Software von vor x 
Jahren, da kann ich sicher 500kBaud und eigentlich auch 1MBaud einlesen 
und dann eben erstmal in eine Datei schreiben. Wenn die Byteanzahl passt 
kann ich es ja auch mal als RAW in Irfanview laden.

Jetzt muß ich aber erstmal was sinnvolles machen...
Auch als Rentner hat man niemals Zeit. ;)

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Ich habe das (las sich recht "ausgereift") ausprobiert, um zu sehen, ob 
die Kamera überhaupt Bilder liefert.

http://acoptex.com/project/254/basics-project-052a-ov7670-camera-sensor-module-without-fifo-ram-at-acoptexcom/#sthash.IDGNJNcx.P8aXeyqc.dpbs

Das gelbe vom Ei ist es nicht - ich musste das Timing auf 20 (O.K., ich 
habe grobe Schritte gemacht) einstellen, damit 2 von 3 Bildern mit 0,25 
FPS in SW gut erkennbar waren (Beispiel anbei).

Das Timing ist nicht gerade optimal, ein wenig Glückssache :-). Bestärkt 
mich in meinem "Interleaved-Ansatz" ...

Michael U. schrieb:
> http://privateblog.info/arduino-uno-i-kamera-ov7670-primer-ispolzovaniya/
> compiliert bei mir nicht sinnvoll, einige Meckereien, zu groß für den
> Mega328.

Übrigens sollte das Projekt auf der von mir verlinkten Seite mit Deinem 
Link (außer der Sprache :-) ) weitgehend übereinstimmen (zumindest wird 
entsprechend referenziert).

Michael U. schrieb:
> Entweder ich bringe sein Java-Zeug mal in Gang

Muss nicht, in meinem Link ist auch ein Windows-EXE (leider schwächer im 
Vergleich zum Java-Empfänger) zur "Bildgebung" verlinkt.

Die Kamera scheint sich übrigens sehr träge an die Helligkeit anzupassen 
- da ist wohl "Register-Arbeit" angesagt :-/

Fällt mir gerade so ein - ich habe ja in der Arduino-Umgebung gewildert. 
Könnte sein, dass der "Standard-Millis-Interrupt" dazwischen funkt.

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Übrigens sollte das Projekt auf der von mir verlinkten Seite mit Deinem
> Link (außer der Sprache :-) ) weitgehend übereinstimmen (zumindest wird
> entsprechend referenziert).

ja, sind prinzipiell identisch, ich habe mal WinMerge drübergeschickt.

Dieter F. schrieb:
> Muss nicht, in meinem Link ist auch ein Windows-EXE (leider schwächer im
> Vergleich zum Java-Empfänger) zur "Bildgebung" verlinkt.

Wie meinst Du "schwächer"? Macht hier erstmal, was es soll, danke für 
den Hinweis auf die Win-Software.

Ich habe im Moment erstmal das Problem mit senkrechten Kinien im Bild, 
da muß ich wohl nochmal meinen Drahtverhau genauer prüfen...

Dieter F. schrieb:
> Das Timing ist nicht gerade optimal, ein wenig Glückssache :-). Bestärkt
> mich in meinem "Interleaved-Ansatz" ...

Sehe ich eigentlich kein wirkliches Problem, 1MBaud geht, hat man 10 
Bitzeiten bis der UART das rausgeschoben hat und nochmal 1 Byte weil UV 
ignoriert wird. Vielleicht schau ich mir mal das ASM-List an, das der 
Compiler baut, der dürfte aber captureImg() schon sehr brauchbar 
optimieren.
Ich finde den Code selbst eigentlich gut strukturiert und 
nachvollziehbar.

Ich werde das wohl mal mit David's Code "paaren", also z.B. seine 
SCCB-Routinen reinwerfen. Kann man ja schön sehen, was geht oder klemmt.
Auch die FiFo-Version in den Code einzubauen sollte recht problemlos 
gehen.

Naja, kommt Zeit kommt Source. ;-)

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Michael U. schrieb:
> Ich habe im Moment erstmal das Problem mit senkrechten Kinien im Bild,
> da muß ich wohl nochmal meinen Drahtverhau genauer prüfen...

Nö, den Teiler (Register 0x11) z.B. auf 20 (wie ich) hochsetzen (die 
hatte ich auch). Das ist alles ein Timing-Problem ...

Michael U. schrieb:
> Wie meinst Du "schwächer"? Macht hier erstmal, was es soll, danke für
> den Hinweis auf die Win-Software

Die Bilder mit der .EXE sind deutlich schlechter, wie die Bilder mit der 
Java-Komponente.

Michael U. schrieb:
> also z.B. seine
> SCCB-Routinen reinwerfen

Nicht erforderlich - TWI/I2C funktioniert prima.

[Dieter F. (Gast)]

Michael U. schrieb:
> Sehe ich eigentlich kein wirkliches Problem, 1MBaud geht, hat man 10
> Bitzeiten bis der UART das rausgeschoben hat und nochmal 1 Byte weil UV
> ignoriert wird.

Ja, da sind nur die kleine Unsicherheit der Reaktion des 
Schnittstellen-Partners und die harte Abfrage auf high-/low-Pegel beim 
Pixel-Takt. Mein "jedes 3. Bild ist Müll" hat schon eine Ursache - 
möglicherweise einfach nur "millis()".

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Nö, den Teiler (Register 0x11) z.B. auf 20 (wie ich) hochsetzen (die
> hatte ich auch). Das ist alles ein Timing-Problem ...

ok, 20 passt erstmal, da muß ich das Datenblatt mal genauer befragen, es 
geht eigentlich NUR 20 bei mir.
Jedes 3. Bild Schrott bestätige ich auch erstmal.

Bilddarstellung in der .exe ist mir noch ewas unklar. Ich habe nochmal 
mit TeraTerm ein Bild geholt und als RAW in Irfanview angezeigt.
Das Bild aus der .exe ist etwas heller. Mein Fokus stand wohl völlig 
daneben, habe ich gerade mal etwas nachgestellt, muß ich morgen bei 
Vernünftiger Beleuchtung mal machen.

Reicht für heute...

Gruß aus Berlin
Michael

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Michael U. schrieb:
>> Sehe ich eigentlich kein wirkliches Problem, 1MBaud geht, hat man 10
>> Bitzeiten bis der UART das rausgeschoben hat und nochmal 1 Byte weil UV
>> ignoriert wird.
>
> Ja, da sind nur die kleine Unsicherheit der Reaktion des
> Schnittstellen-Partners und die harte Abfrage auf high-/low-Pegel beim
> Pixel-Takt. Mein "jedes 3. Bild ist Müll" hat schon eine Ursache -
> möglicherweise einfach nur "millis()".

doch noch ein Nachtrag: am PC unter Win7 war zumindest die Auswahl an 
Terminalprogrammen nicht groß, die 1MBaud können und die Daten als 
binär-Daten in eine Datei schreiben.
TeraTerm v6.9 macht es zumindest zuverlässig, wenn auch umständlich.
Mit einer eigenen Empfangsroutine auf der COM sehe ich aber da kein 
Problem.
Möglich, daß das Zusammenspiel beim USB-Seriell-Wandler da noch probleme 
machen könnte, sieht hier aber mit dem CH340 nicht danach aus, FTDI 
macht nach meiner Erfahrung da auch keine Probleme.

milis() wird doch garnicht genutzt, Interrupts sind ohnehin komplett 
gesperrt.
_delay_ms() beim AVR-GCC ist meiner Erinnerung nach eine busy-loop 
basierend auf F_CFU.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> Also den anderen Link, ist ohnehin ausführlicher für mich.
> Sketch compiliert ohne Probleme, auf einen Arduino Nano geflasht.

Könntest Du netterweise "den anderen Link" ebenfalls hier einstellen?

Und schön: Dieter hat lauffähigen Code im Internet aufgetrieben - der 
grundsätzliche Beweis, dass ein Atmega eine OV7670 Kamera auslesen kann, 
scheint damit schon einmal erbracht. Jetzt müssen wir es nur selber 
ebenfalls noch hinbekommen.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Könntest Du netterweise "den anderen Link" ebenfalls hier einstellen?
Hatte Dieter oben gepostet:
http://acoptex.com/project/254/basics-project-052a-ov7670-camera-sensor-module-without-fifo-ram-at-acoptexcom/#sthash.IDGNJNcx.P8aXeyqc.dpbs

Mein Link:
https://www.instructables.com/id/OV7670-Arduino-Camera-Sensor-Module-Framecapture-T/
ist vom code für den UNO prinzipiell identisch und läuft genauso, bei 
Dieter war nur netterweise die Windows-exe für den Anzeiger dabei, mußte 
ich den JAVA-Kram nicht erst hier in Gnag bringen.

> Und schön: Dieter hat lauffähigen Code im Internet aufgetrieben - der
> grundsätzliche Beweis, dass ein Atmega eine OV7670 Kamera auslesen kann,
> scheint damit schon einmal erbracht. Jetzt müssen wir es nur selber
> ebenfalls noch hinbekommen.

Prinzipiell sollte sich das auch auf dem STM32 so in Gnag bringen 
lassen, wenn man die Hardwareabhängigkeiten bei XCLK Erzeugung, Seriell 
und TWI anpasst.

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Andreas S. schrieb:
> Und schön: Dieter hat lauffähigen Code im Internet aufgetrieben - der
> grundsätzliche Beweis, dass ein Atmega eine OV7670 Kamera auslesen kann,
> scheint damit schon einmal erbracht. Jetzt müssen wir es nur selber
> ebenfalls noch hinbekommen.

Ja - wobei ich schrieb, das das nicht optimal ist.

Ich wollte lediglich wissen, ob die (meine) Kamera grundsätzlich 
"arbeitswillig" ist. Ist sie.

Nach dem "keep it simple an stupid"-Prinzip werde ich mit QQVGA 
anfangen. 160 x 120 Pixel scheinen beherrschbar zu sein. Blöd ist, dass 
ich kein passendes PC-Programm dazu habe. Wen stört das - es gibt ja 
SPI-fähige-Displays :-)

[David D. (saturi)]

Hallo, wow ...
jetzt habt ihr mich erstmal abgehängt...
Ich überlege, ob ich mir auch mal so ein Zeugs aus dem Internet drauf 
schmeißen soll, um meine Kamera zu testen, obwohl ich mir vorgenommen 
hatte, alles selbst in Gang zu bringen, um wirklich jedes Detail zu 
verstehen und zu lernen.

Andreas S. schrieb:
>Wie/womit programmierst Du?
>Mit Arduino-IDE auf Arduino-Nano (so wie David, unser Eiskalt-Duscher)?
>Oder mit Atmel-Studio in Assembler auf dem größten ATmega, den es gibt?
>(das wäre eher die Lauwarm-Duscher Variante).

Also das stimmt nicht ganz, ich mache es wie Dieter:
>Um kompatibel zu sein mit C und Atmel Studio auf ATMega328P (Arduino
>Nano Hardware) - das ist zwar eine Krücke, aber auch eine
>Herausforderung :-).

nur auf Arduino Uno Hardware (was aber im Prinzip das gleiche ist, nur 
mit weniger Pins nach außen geführt) aber ist beides der Atmega328


Dieter F. schrieb:
Noch bin ich nur am "rumspielen" und lesen - aber eine "normale"
TWI-Anbindung funktioniert gut und mit 8MHz externem Takt läuft die
Kamera auch ohne Probleme.

kannst du da villeicht deinen Source code zur verfügung stellen? das 
hatten wir hier "früher" auch schon versucht zum laufen zu bekommen 
(vergeblich...) meines erachtens wegen dem ACK, dass bei TWI und SCCB 
unterschiedlich ist. Vielleicht habe ich aber in meinem Code was 
übersehen gehabt.

EDIT:
Da flattert mir doch was ganz spannendes in die Hände (bzw. auf den 
Bildschirm)

https://github.com/dalmirdasilva/ArduinoCamera/blob/master/CameraAL422B/datasheet/OV7670%20Implementation%20Guide%20(V1.0).pdf

Das sieht mir auf den ersten Blick doch nach einer ausführlichen 
Registerbeschreibung aus und erklärt ebenfalls, dass man Auflösungen und 
Farbformate nicht beliebig mischen darf... (daher hatte ich erst recht 
keine Chance :D )

[Dieter F. (Gast)]

David D. schrieb:
> Das sieht mir auf den ersten Blick doch nach einer ausführlichen
> Registerbeschreibung aus und erklärt ebenfalls, dass man Auflösungen und
> Farbformate nicht beliebig mischen darf... (daher hatte ich erst recht
> keine Chance :D )

Jein - das ist auch noch nicht die "Wahrheit". Es gibt noch einen 
Software Implementation Guide - und ein hoch-geheimes etwas, was die 
Soll-Register-Einstellungen beinhaltet.

Ich gehe auch erstmal nach den beiden ersten Beschreibungen vor und 
schaue, was dabei herauskommt.

Bei den OV7670-Programmen haben anscheinend alle von irgendwem 
abgeschrieben - die gleichen sich bei der Register-Beschickung fast 
überall.

David D. schrieb:
> Dieter F. schrieb:
> Noch bin ich nur am "rumspielen" und lesen - aber eine "normale"
> TWI-Anbindung funktioniert gut und mit 8MHz externem Takt läuft die
> Kamera auch ohne Probleme.
>
> kannst du da villeicht deinen Source code zur verfügung stellen?

Da kannst Du Dir irgendeinen beliebigen Sourcecode nehmen - die haben 
sowieso (fast) alle nur kopiert.

Ich werde "meinen" Weg gehen und schauen, ob dabei ein Bild (oder viele) 
herauskommen. Wenn ich erfolgreich bin teile ich - wenn nicht suche ich 
mir ein anderes Projekt :-)

[David D. (saturi)]

Dann werde ich dem ganzen wohl noch eine Chance geben.
Da ich mir nun durch irgendeine Änderung wieder als zerschossen habe, 
habe ich beschlossen jetzt die Dokumentations- und Aufräumarbeiten in 
meinem Code dieses Wochenende zu fokussieren. und werde ihn dann nochmal 
zur Verfügung stellen. Mein Ziel ist es weiterhin ein Bild an den PC zu 
senden und mit meinem eigenen Programm zu erfassen.

Zusätzlich habe ich in meinem Sammelsorium noch ein 1.8 SPI TFT 128*160 
gefunden. (incl SD Kartenaufnahme auf der Rückseite).
Ich überlege grade parallel eure fortschritte damit zu verfolgen. Macht 
das Sinn? (Bislang habe ich das aber noch nicht in Betrieb genommen)

Weiterhin habe ich leider etwas die Übersicht verloren, wer jetzt hier 
was versucht. Ich versuche einmal zusammen zu fassen. Bitte korrigiert 
mich wenn ich falsch liege.

Dieter:
Atmega328P (Arduino Nano) (Atmel Studio) - OV7670 (ohne Fifo)
versucht das Bild direkt auf einem Display darzustellen.

Michael:
Arduino Nano (Arduino IDE) - OV7670 (mit Fifo)
versucht das Bild an den PC zu senden?! und es mit einem COM Terminal 
aufzufangen und abzuspeichern?

Igel:
Durch und durch ARM :D - OV7670 (mit Fifo)
Habe aber bei dir noch nen Nano auf dem Board stecken gesehen was 
treibst du genau mit dem?

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Ich überlege, ob ich mir auch mal so ein Zeugs aus dem Internet drauf
> schmeißen soll, um meine Kamera zu testen, obwohl ich mir vorgenommen
> hatte, alles selbst in Gang zu bringen, um wirklich jedes Detail zu
> verstehen und zu lernen.

Das habe ich ganz ganz fürher noch gemacht, als zu den ICs noch die 
Innenschaltungen veröffentlicht wurde. Ja komplexer die ICs wurde, um so 
mehr habe ich mich auf meine konkrete Anwendung konzentriert. 
Datenblätter lesen hab ich aber damals ganz gut gelernt, auch, daß 
Fußnoten und Anmerkungen oft wichtiger sind als die Registerbeschreibung 
selbst...

David D. schrieb:
> nur auf Arduino Uno Hardware (was aber im Prinzip das gleiche ist, nur
> mit weniger Pins nach außen geführt) aber ist beides der Atmega328

Ob UNO oder Nanao war bei mir ketzt nur eine Größenfrage, die sind 
funktionell in diesem Zusammenhang identisch.
Atmel Studio ist mir für meine Spielereien in zu großer Klotz, ein AVR 
Studio 4 wäre durchaus hier noch griffbereit. Die Sachen auch von Dir 
sind aber in 10 Minuten in der ArduinoIDE und compilieren dort, also 
bleibe ich dabei.
Gerade mal den Spaß gemacht den .ino Inhalt in ein AVR Studio 4 Projekt 
zu packen, hat keine 5 Minuten gedaurt, compiliert. Keine Lust, jetzt 
einen ISP-Programmer zu holen und es zu flashen...

Zu TWI: schau in die verlinkten Arduino-Sketche, ist ohnehin reines C.
Danke noch für den Link zum Applicatio-pdf, hatte ich noch nicht (und 
auch nicht gesucht...).

Ich werde mir morgen mal einen Lochrasterträger mit Buchsenleisten und 
Verdrahtung fertig machen, für den Nano und beide OV7670 Versionen und 
vorverdrahten. Dann fällt nichts gleich auseinander. Werde wohl dann 
auch mal meinen LA ranhängen und mir mal anschauen, wo ein Grund für die 
zyklische auftretenden fehlerhaften Bilder zu erkennne ist.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

David D. schrieb:
> EDIT:
> Da flattert mir doch was ganz spannendes in die Hände (bzw. auf den
> Bildschirm)
>
> 
https://github.com/dalmirdasilva/ArduinoCamera/blob/master/CameraAL422B/datasheet/OV7670%20Implementation%20Guide%20(V1.0).pdf

Und Michael U. schrieb daraufhin:
> Zu TWI: schau in die verlinkten Arduino-Sketche, ist ohnehin reines C.
> Danke noch für den Link zum Applicatio-pdf, hatte ich noch nicht (und
> auch nicht gesucht...).

Hättet Ihr mal schön brav die Postings vom lieben Igel1 gelesen, hättet 
Ihr den Guide schon vor Wochen kennengelernt:

Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)"

Anyway ...

Ihr seid ja ganz schön am Stricken - Respekt, Respekt.

> Ich überlege, ob ich mir auch mal so ein Zeugs aus dem Internet drauf
> schmeißen soll, um meine Kamera zu testen, obwohl ich mir vorgenommen
> hatte, alles selbst in Gang zu bringen, um wirklich jedes Detail zu
> verstehen und zu lernen.

Mach das auf keinen Fall! Abkupfern ist extrem motivationskillend
und dazu bewundere ich Deine Ausdauer und Deine steile Lernkurve.
Wenn Du Fertig-Code kopierst, hast Du einen Fan weniger ...

Außerdem kannst Du unendlich stolz auf Dich sein, wenn Du das 
tatsächlich
alles allein hinkriegst! Und willst Du Dir diesen Stolz selber stehlen?

Viele Grüße

Igel1

[Andreas S. (igel1)]

Au weia - noch so'n Schnitzer (ich hoffe, diesmal nur im Datenblatt):

Schaut Euch mal das Bild "AL422-06 Write Cycle Timing (Write Enable)" 
auf S.11 der AL422B-Spec an:
Lt. diesem Bild wird das Byte n+2 auf dem Bild erst in der 2. steigenden 
Taktflanke von WCK nach einer fallenden /WE-Flanke abgespeichert.

Unser Problem: das "Horizontal Timing" der OV7670 Kamera besagt, dass 
nach einem Ansteigen von HREF bereits die erste Taktflanke von PCLK das 
erste Pixel-Byte überträgt.

Das würde bedeuten: da HREF direkt per NAND-Gatter mit dem /WE vom 
AL422B gekoppelt ist, würde das erste Pixel-Byte einer jeden Zeile nicht 
in das FiFo geschrieben werden - tolle Wurst!

Aber tröstet Euch: als Ausgleich wird am Zeilenende noch ein völlig 
falsches Byte in den Speicher geschrieben, wenn HREF längst schon wieder 
LOW ist.

Seht Ihr das ähnlich, oder liege ich falsch?

Viele Grüße

Igel1

[David D. (saturi)]

>>Mach das auf keinen Fall! Abkupfern ist extrem motivationskillend

okay.... überredet ;-)

was das Datenblatt angeht kann ich dir nicht ganz folgen. Also 
zunächsteinmal ist es bei mir Seite 12 (wir sprechen aber schon von 
v1.5?)

Wo nimmst du das NAND Gitter her?

Aber abgesehen davon verstehe ich das Timing diagram auch nicht 
wirklich... laut dem wird nämlich auch das n+1 Byte in DI geladen obwohl 
/WE auf high ist....

merkwürdig


>>Hättet Ihr mal schön brav die Postings vom lieben Igel1 gelesen, hättet
>>Ihr den Guide schon vor Wochen kennengelernt:


Okay... sorry das ist mir wirklich durchgegangen... zu meiner 
Verteidigung lief da noch nicht mal das SCCB-Protokoll xD ... und es ist 
fast ein Jahr her... Aber danke nochmal für den Hinweis. Jetzt hab ich 
sie mir abgespeichert :D

[Andreas S. (igel1)]

David D. schrieb:
>>>Mach das auf keinen Fall! Abkupfern ist extrem motivationskillend
>
> okay.... überredet ;-)

Tapfer!

> was das Datenblatt angeht kann ich dir nicht ganz folgen. Also
> zunächsteinmal ist es bei mir Seite 12 (wir sprechen aber schon von
> v1.5?)

Ja, hast recht - hatte versehentlich in meiner älteren Version 
nachgeschaut - das Timing ist aber in Version 1.5 unverändert 
problematisch.

> Wo nimmst du das NAND Gitter her?

Wie weiter oben geschrieben:
> Ich vermute daher eher, dass ich dieses Modul hier habe:
> 
http://www.haoyuelectronics.com/Attachment/OV7670-Module-A/CMOS_FIFO%20schematic.pdf

Dort findest Du einen Baustein SN74LVC1G00:
http://www.ti.com/lit/ds/symlink/sn74lvc1g00.pdf
... und das ist ein NAND-Gatter.

Das Gatter invertiert das HREF-Signal (wenn FIFO_WR = HIGH) und so 
werden nur dann Pixel in das AL422B hineingeschrieben, wenn HREF = HIGH, 
weil dann nämlich \WE=LOW ist.

Damit wird sichergestellt, dass nur die Zeilen-Pixel in den FiFo 
geschrieben werden (... wenn da nicht der in meinem letzten Post 
beschriebene Fehler wäre ...).

> Aber abgesehen davon verstehe ich das Timingdiagram auch nicht
> wirklich... laut dem wird nämlich auch das n+1 Byte in DI geladen obwohl
> /WE auf high ist....

Das könnte sich so erklären: evtl. ist das "Write Register" (siehe 
interner Aufbau des AL422B) ein flankengetriggertes Flip-Flop, welches 
die Daten bei steigender Flanke übernimmt. Danach werden sie im nächsten 
Schritt ins DRAM geschrieben.

Einmal im Flip-Flop geht die Sache ihren sozialistischen Gang.

Trotzdem passt das alles nicht so recht ins Bild.

> merkwürdig

Richtig. Einzige Erklärung,die uns retten könnte: Das Diagramm "AL422-06 
Write Cycle Timing (Write Enable)" ist falsch und es ist darin in der 
untersten Zeile DI7~0 nicht das Datenbyte, was außen am FiFo anliegt 
abgebildet, sondern dasjenige, welches intern ins DRAM geschrieben wird.

Aber vielleicht haben Michael oder Dieter noch eine bessere Idee ...

Im Anhang nochmals zum besseren Vergleich die zwei Timing im Vergleich.
Der Frowny zeigt auf, wo eigentlich das erste Datenbyte nach einem Write 
Enable vom AL422B geschnappt werden müsste.

Viele Grüße
Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Unser Problem: das "Horizontal Timing" der OV7670 Kamera besagt, dass
> nach einem Ansteigen von HREF bereits die erste Taktflanke von PCLK das
> erste Pixel-Byte überträgt.

ich habe jetzt nicht in das Datenblatt des AL422B geschaut und auch die 
Schaltung nicht genauer angeschaut.
Wie wird die OV7670 für den FiFo-Betrieb initialisiert?
Wenn z.B. Bit 5 in COM10 gesetzt ist wird kein PCLK während des HSYNC 
ausgegeben.
Ich komme erst heute nachmittag dazu, da mal reinzuschauen.

PS: doch kurz reingechaut: AL422 übernimmt mit der steigenden Flanke von 
WCK die Daten wenn /WE aktiv ist. Die Kamera hat das Byte mit der 
steigenden Flanke von PCLK gültig, die kommt nach Ende HREF. Sieht für 
mich im Moment glaubwürdig aus?

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:

> Wie wird die OV7670 für den FiFo-Betrieb initialisiert?
> Wenn z.B. Bit 5 in COM10 gesetzt ist wird kein PCLK während des HSYNC
> ausgegeben.

Das ist meiner Meinung nach unbedingt zu vermeiden:
Die Clocks sollten auf beiden Seiten durchlaufen, vgl. Datenblatt Absatz 
8.3.1. "It is recommended that the WCK and RCK are kept running at least 
1MHz at all times."

Und wenn wir schon den RCK-Takt brutal unter 1MHz runterdrücken, um das 
Bild in Ruhe auslesen zu können, dann sollte der WCK-Takt zumindest auf 
>1MHz durchlaufen, denn angeblich wird ja (lt. Datenblatt) der 
schnellere der beiden Takte zum DRAM-refresh verwendet (... glauben wir 
das mal ...), siehe Kapitel 8.3.1.: "The faster one of WCK and RCK is 
used as the DRAM refresh timing clock and has to be kept free running."

> Ich komme erst heute nachmittag dazu, da mal reinzuschauen.

Du bist entschuldigt :-)

> PS: doch kurz reingechaut: AL422 übernimmt mit der steigenden Flanke von
> WCK die Daten wenn /WE aktiv ist.

Ja schon, aber laut dem Bild in meinem letzten Posting übernimmt der 
AL422B   nach einem /WE=LOW (also nach einem Aktivieren der 
Schreibfähigkeit) erst mit der 2. steigenden Flanke wieder Daten vom 
Bus! Das ist genau der Knackpunkt. Schaut Euch mein Bild aus dem letzten 
Posting bitte einmal genau an.

> Die Kamera hat das Byte mit der
> steigenden Flanke von PCLK gültig, die kommt nach Ende HREF.

Richtig - die Kamera wirft somit das 1. Byte raus, bevor der AL422B es 
aufschnappen kann, denn der liest seinerseits die Daten erst ab er 2. 
steigenden Flanke ein.

> Sieht für
> mich im Moment glaubwürdig aus?

... für mich nicht - aber ich lasse mich gerne von Euch vom Gegenteil 
überzeugen ...

Ich kann nur hoffen, das das Datenblatt in diesem Punkt falsch ist, denn 
für diese Einlese-Verzögerung um einen WCK-Takt findet sich meiner 
Ansicht nach keine echte Begründung, die sich aus internen Aufbau des 
Chips ableiten ließe (vgl. "AL422-03 Block Diagram" auf S. 14 des 
Datenblatts).

Viele Grüße

Igel1

[Andreas S. (igel1)]

Hi Leute,

so, hier der erste Versuch ein komplettes Bild in den AL422B zu 
schieben.
Wenn Ihr Lust habt, so wäre es super nett, wenn Ihr einmal meinen 
Pseudo-Code sichten und ggf. kommentieren könntet:

Reading an image frame from OV7670 into AL422B fifo:
-----------------------------------------------------

FIFO_WCK = >=1MHz clock // make sure AL422B FiFo is clocked by camera's PCLK with at least 1MHz

delay(1ms)              // see AL422 datasheet: do wait 0.1ms after power up before applying reset

FIFO_WR = HIGH          // enable chips WE (and keep it enabled all time till end of frame-grabbing
FIFO_WRST = HIGH        // disable write reset
                        // at this point, pixels already get shifted into AL422B, but we don't care for it
                        // because we will reset the FiFo's write address pointer later on.

while(!VSYNC) {}        // VSYNC=LOW: wait for end of current frame
while(VSYNC) {}         // VSYNC=HIGH: vsync=high marks end of old frame

// new frame starts here
FIFO_WRST = LOW         // reset AL422B write addr pointer by driving /WRST to LOW for >= 2 cycles (1 cycle = 1 PCLK-cycle)
delay(1ms)              // and < 17x Tline  =>  driving /WRST to LOW for 1ms should be okay
FIFO_WRST = HIGH        // reset write address pointer of AL422B

while(!VSYNC){}         // read data while VSYNC=LOW

// new frame ends here
FIFO_WR = LOW           // disable chips WE when end of frame is reached (VSYNC goes HIGH) 
                        // and keep it disabled since we are done with reading one frame.

Das Schöne am Ganzen: es ist wirklich keine echt zeitkritische Aktion 
enthalten - das ATmega sollte das also genauso locker bewerkstelligen 
können.

Viele Grüße

Igel1

[Andreas S. (igel1)]

... und weil's so schön war, hier direkt der Pseudo-Code für das 
Auslesen des AL422B FiFo:

Reading an image frame out of AL422B fifo:
-------------------------------------------

FIFO_RCK = 10kHz clock  // feed FiFo with clock signal (using TIM1 on STM32F4)
                        // frequency can be adjusted according to UART-baudrate (e.g. 115200 baud) 
                        // and UART-mode (e.g. 8N1 => 1 Start-Bit + 8 Data-Bits + 1 Stop-Bit = 10 Bits)
                        // If you use 115200 baud, you can transfer 115200baud/10bit/Byte = 11520 Bytes/s
                        // So FIFO_RCK can be at most 11.520 KHz in this example
                        // See: http://www.netzmafia.de/skripten/hardware/PC-Schnittstellen/seriell.html

delay(1ms)              // see AL422 datasheet: do wait 0.1ms after power up before applying reset

FIFO_RRST = LOW         // reset AL422B read addr pointer by driving /RRST to LOW
delay(1ms)

// pull /RRST high right after a falling RCK shoulder
while(!FIFO_RCK){}      // wait for a possible high shoulder to end
while(FIFO_RCK){}       // wait for FIFO_RCK to become low
FIFO_RRST = HIGH        // read addr pointer starts upcounting here (at very rising FIFO_RCK-edge)

// read out image from AL422B FiFo
for(noOfPixels x bytes per pixel){    // repeat for "number of bytes in an image frame" times
  while(!FIFO_RCK)      // wait during low FIFO_RCK-shoulder
  get FIFO_DATA         // grab data right after rising edge of  FIFO_RCK
  UARTsend(FIFO_DATA)   // send data
  while(FIFO_RCK)       // wait till end of high shoulder of FIFO_RCK
}

Auch hier würde ich mich sehr freuen, wenn Ihr einen intensiven Blick 
darauf werfen könntet und mir Feedback gebt.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Auch hier würde ich mich sehr freuen, wenn Ihr einen intensiven Blick
> darauf werfen könntet und mir Feedback gebt.

werde ich sicher machen, aber erst irgendwann nachher. Ich löte erstmal 
meinen Lochrasterträger mit Buchsenleisten zusammen, dann kann ich 
stabil zwischen mit und ohne FiFo wechseln und im Zweifel auch einfach 
mal was messen ohne daß der Drahtverhau auseinanderfällt.
Dann kann ich Deinen Ansatz auch einfach mal in den obigen Source 
reintippen, OV7670 Init ist dann dort übersichtlich genug und der TWI- 
und UART-Kram ist ja auch lauffähig vrohanden.

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Hi,

ich bin der Leserei jetzt überdrüssig und habe mich entschieden:

Ich werde erstmal mit QQVGA beginnen. Da kann ich mit 2 MBaud (getestet 
und für gut befunden) im Idealfall (errechnet) 3 - 4 FPS erzielen und 
brauche nicht mal Interleave.

Arbeite gerade an einem kleinen Python-Script. Mal schauen, wie schnell 
PIL's Routinen zum Pixel setzen sind :-)

Übrigens werde ich mit 16 MHz Takt für die Kamera arbeiten. Spielt 
sowieso keine Rolle - warum sollte ich dann außerhalb der Spezifikation 
bleiben ... . So aktiviere ich PINB0 per Fuse und fertig.

VG
Dieter

[Andreas S. (igel1)]

Hi Leute,

habe den Pseudocode inzwischen in "echten" Code verwandelt.

Gerade zum ersten Mal das Programm laufen lassen.

War leider ein Schuss in den Ofen: zeigt nur weisse Mäuse vor weissem 
Hintergrund an.

Jetzt wird's interessant, denn debuggen mit einem Logicanalyzer ohne 
Zugriff auf die Pins der Kamera (es sind ja nur HREF und VSYNC nach 
draussen geführt) wird vermutlich schwierig werden.

Das wird sicherlich langwierig werden (es sei denn, Ihr findet direkt 
vorab einen dicken Bock im Pseudocode).

Viele Grüße

Andreas

[David D. (saturi)]

Guten Morgen/Mahlzeit zusammen.
@Igel ich werde mir deine beiden Pseudocodes nachher, wenn ich zuhause 
bin einmal anschauen und mit meinem bisherigen vorgehen vergleichen. Bis 
nachher :)

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> War leider ein Schuss in den Ofen: zeigt nur weisse Mäuse vor weissem
> Hintergrund an.
naja, besser als garkein Bild... ;)

Ich bin mit meinem Träger löten gestern auch nicht allzuweit gekommen, 
hoffentlich wird es nachher nochwas.
Puh... Hatte ich noch garnicht nachgeschaut, aber die Eingäge des AL422B 
sind ja zum Glück 5V-tolerant...

Gruß aus Berlin
Michael

[David D. (saturi)]

Sooo... meine bessere hälfte hatte doch noch was zu tun, wodurch ich 
wenigstens die Möglichkeit hatte die Write Sequenz schon einmal 
durchzuschauen:

>FIFO_WCK = >=1MHz clock // make sure AL422B FiFo is clocked by camera's >PCLK 
with at least 1MHz
So far so good... Wenn ich bei mir messe, liegen ungefähr die 12 Mhz vom 
verbauen Oszillator an.

>delay(1ms)              // see AL422 datasheet: do wait 0.1ms after power >up 
before applying reset
jep... aber jetzt steht dort: "Apply /WRST and /RRST 0.1ms after power 
on" Für mich hieß apply bei einem low-active signal auf Low ziehen.
Bin ich hier falsch? also ich habe an dieser Stelle dann

//Initialization From Datasheet: "Apply/WRST and //RRST 0.1ms after power on
  OV_WRST_PORT &= ~(1<<OV_WRST_PinNo);
  OV_RRST_PORT &= ~(1<<OV_RRST_PinNo);

womit ich beide Pins auf Low Signal ziehe.

bei mir pulse ich danach nohc zweimal den RCK Pin um den Read Pointer 
wirklich auf 0 zurückzuholen. Keine Ahnung ob das notwendig ist... Na 
gut, weiter im Text:



>FIFO_WR = HIGH          // enable chips WE (and keep it enabled all time >till 
end of frame-grabbing
>FIFO_WRST = HIGH        // disable write reset
>                       // at this point, pixels already get shifted into >AL422B, 
but we don't care for it
>                        // because we will reset the FiFo's write address 
>pointer later on.
Ist WE nicht ebenfalls Low-active? also eigentlich /WE demnach würdest 
du es deaktivieren und dann wird garnichts geschrieben.


>while(!VSYNC) {}        // VSYNC=LOW: wait for end of current frame
>while(VSYNC) {}         // VSYNC=HIGH: vsync=high marks end of old frame
while(VSYNC) {}... sehr gut... das hatte ich bis jetzt noch nicht, macht 
aber durchaus Sinn

>// new frame starts here
>FIFO_WRST = LOW         // reset AL422B write addr pointer by >driving /WRST to 
LOW for >= 2 cycles (1 cycle = 1 PCLK-cycle)
>delay(1ms)              // and < 17x Tline  =>  driving /WRST to LOW for >1ms 
should be okay
was meinst du genau mit diesem Kommentar?: < 17x Tline  =>
Ich habe da nur ein delay von 6 us drin... frage mich grade wie ich 
dadrauf gekommen bin

>FIFO_WRST = HIGH        // reset write address pointer of AL422B
>
>while(!VSYNC){}         // read data while VSYNC=LOW
>
>// new frame ends here
>FIFO_WR = LOW           // disable chips WE when end of frame is reached (VSYNC 
goes HIGH)
>                       // and keep it disabled since we are done with >reading 
one frame.
FIFO_WR = LOW  --> siehe oben, ich meine Low-active

Die Read Sequenz dann später :)


@Michael, wie willst du es schaffen, dass beide Kameras mit dem Board 
kompatibel sind? ich habe auch beide Versionen hier, aber die Pins 
weichen eben schon voneinander ab in den beiden Modellen? Oder willst du 
das aufwändig über jumper lösen?

Bis später,
David

EDIT: irgendwie hats die Zitate verhauen und ich bekomme es auch nicht 
korriegiert... Ich hoffe ihr könnt es dennnoch inhaltlich trennen ;-)

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> @Michael, wie willst du es schaffen, dass beide Kameras mit dem Board
> kompatibel sind? ich habe auch beide Versionen hier, aber die Pins
> weichen eben schon voneinander ab in den beiden Modellen? Oder willst du
> das aufwändig über jumper lösen?

Ich habe 2 passende Buchsenleisten parallel verlötet, es wird natürlich 
nur jeweils eine Kamara gesteckt werden.
Die "identischen" Pins verbinde ich direkt, SDA/SCl/XCLK über 
Levelshifter, D0...D7 kommen auch zusammen, ist ja egal, ob die Daten 
vom OV7670 oder dem AL422B kommen. PCLK und XCLK kommen parallel auf 2 
Pins des AL422B, dann bleiben von dem noch 4 Signale, die ich auf freie 
Pins verteilen muß.
Prinzipiell sind ja D9...D13 (PB1...PB5) noch verfügbar, außer der 
Kamera kommt an des "Spielbrett" nicht ran, bei OB7670 ohne FiFo und 
OV2640 wäre dann selbst SPI ja noch verfügbar.
Der Rest ist ja dann Sache der Definitionen in der jeweiligen Software.
Prinzipiell würde auch mein OV2640 Modul noch auch dem Platz der OV7670 
passen, die PinOuts sind identisch. Dann kann ich zumindest die Hardware 
mal in die Ecke legen, wenn ich keine Zeit dafür habe, ohne das was 
auseinanderfällt...

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

David D. schrieb:
> Sooo... meine bessere hälfte hatte doch noch was zu tun, wodurch ich
> wenigstens die Möglichkeit hatte die Write Sequenz schon einmal
> durchzuschauen:

Dankeschön - sehr nett von Dir.

>FIFO_WCK = >=1MHz clock // make sure AL422B FiFo is clocked by camera's >PCLK
> with at least 1MHz
> So far so good... Wenn ich bei mir messe, liegen ungefähr die 12 Mhz vom
> verbauen Oszillator an.

Dann passt ja alles.

>
>>delay(1ms)              // see AL422 datasheet: do wait 0.1ms after power >up
> before applying reset
> jep... aber jetzt steht dort: "Apply /WRST and /RRST 0.1ms after power
> on" Für mich hieß apply bei einem low-active signal auf Low ziehen.
> Bin ich hier falsch?

JA. Ich glaube, Du hast da einen Denkfehler gemacht:
Schau Dir das Nand Gatter im Schaltplan genau an:
Damit wird \WE nur dann auf LOW gezogen, wenn
FiFo_WR = HIGH AND HREF = HIGH ist.


> also ich habe an dieser Stelle dann
>

//Initialization From Datasheet: "Apply/WRST and //RRST 0.1ms after 
> power on
>   OV_WRST_PORT &= ~(1<<OV_WRST_PinNo);
>   OV_RRST_PORT &= ~(1<<OV_RRST_PinNo);

> womit ich beide Pins auf Low Signal ziehe.

Okay - da könnte etwas dran sein.
Muss ich mir nochmals überlegen, ob ich das genauso machen werde.

>
> bei mir pulse ich danach nohc zweimal den RCK Pin um den Read Pointer
> wirklich auf 0 zurückzuholen. Keine Ahnung ob das notwendig ist... Na
> gut, weiter im Text:
>
>
>
>>FIFO_WR = HIGH          // enable chips WE (and keep it enabled all time >till
> end of frame-grabbing
>>FIFO_WRST = HIGH        // disable write reset
>>                       // at this point, pixels already get shifted into 
>AL422B,
> but we don't care for it
>>                        // because we will reset the FiFo's write address
>>pointer later on.
> Ist WE nicht ebenfalls Low-active? also eigentlich /WE demnach würdest
> du es deaktivieren und dann wird garnichts geschrieben.

Siehe Anmerkungen von mir weiter oben.

>
>
>>while(!VSYNC) {}        // VSYNC=LOW: wait for end of current frame
>>while(VSYNC) {}         // VSYNC=HIGH: vsync=high marks end of old frame
> while(VSYNC) {}... sehr gut... das hatte ich bis jetzt noch nicht, macht
> aber durchaus Sinn
>

>>// new frame starts here
>>FIFO_WRST = LOW         // reset AL422B write addr pointer by >driving /WRST to
> LOW for >= 2 cycles (1 cycle = 1 PCLK-cycle)
>>delay(1ms)              // and < 17x Tline  =>  driving /WRST to LOW for >1ms
> should be okay
> was meinst du genau mit diesem Kommentar?: < 17x Tline  =>

Der Write Reset muss unbedingt disabled werden, bevor HREF auf HIGH 
geht, also bevor die Zeilenübertragung beginnt.

> Ich habe da nur ein delay von 6 us drin... frage mich grade wie ich
> dadrauf gekommen bin
>
>>FIFO_WRST = HIGH        // reset write address pointer of AL422B
>>
>>while(!VSYNC){}         // read data while VSYNC=LOW
>>
>>// new frame ends here
>>FIFO_WR = LOW           // disable chips WE when end of frame is reached (VSYNC
> goes HIGH)
>>                       // and keep it disabled since we are done with >reading
> one frame.
> FIFO_WR = LOW  --> siehe oben, ich meine Low-active
>
> Die Read Sequenz dann später :)
>

Danke!

>
> @Michael, wie willst du es schaffen, dass beide Kameras mit dem Board
> kompatibel sind? ich habe auch beide Versionen hier, aber die Pins
> weichen eben schon voneinander ab in den beiden Modellen? Oder willst du
> das aufwändig über jumper lösen?
>
> Bis später,
> David
>
> EDIT: irgendwie hats die Zitate verhauen und ich bekomme es auch nicht
> korriegiert... Ich hoffe ihr könnt es dennnoch inhaltlich trennen ;-)

Macht nix.

Viele Grüße

Igel1

[David D. (saturi)]

Lieber Igel....
ich bitte vielmals um Verzeiung :D ... Ich sollte mir wohl definitiv 
mehr Zeit für eure Beiträge nehmen. Das fällt mir nur immer sehr schwer, 
weil ich voller Tatendrang stecke und meine Zeit sooo begrenzt ist... 
Aber damit kämpfen wir ja alle...
Da du so hartnäckig an deinem NAND Gatter festgehalten hast und ich es 
zugegebener maßen bis grade immer noch nicht verstanden hatte, habe ich 
jetzt zwei Stunden investiert, um zum ersten meine Verkabelung zu 
überprüfen (seit der nächtlichen Umbauaktion geht leider garnix mehr :D) 
und mich mit meinem Modul auseinander zu setzen.
Ich habe beide Schematics die ich zum Modul hatte überprüft und bin zu 
dem Entschluss gekommen, dass die beide nicht zu meinem Modul gehören. 
Dann habe ich brav in diesem Chatverlauf nach deiner verlinkten 
schematics gesucht und zack... ja passt auch für mich, wie die Faust 
aufs Auge. Aber wo ist die LED?! ... jap einfach nicht aufgelötet. aber 
Die Pads sind da. nach der Schematics scheint es wohl einfach eine 
unregelbare beleuchtungs LED und keine Status LED zu sein.

Durch das NAND-Gatter wird mir jetzt auch klar, warum auf dem Board WR 
und nicht WE steht.
Wir halten also Fest: /WE bleibt weiterhin Low-Active wie im Datenblatt 
angegeben. Dazu ergibt sich folgende Logische Beziehung:

WE = ~(WR^HREF)  --> ~WE = /WE = (WR^HREF)

Damit muss ich mir schonmal keine Gedanken machen, dass während des HREF 
plötzlich was unerwartes in den Fifo geschrieben wird.


Das war aufjedenfall eine sehr Wertvolle Lehrstunde für mich und ich 
werde meinen Code nochmal dementsprechend überarbeiten.


Gruß David.


PS: Read Sequenz schaue ich mir dann jetzt gleich mal an

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Aber wo ist die LED?! ... jap einfach nicht aufgelötet. aber
> Die Pads sind da. nach der Schematics scheint es wohl einfach eine
> unregelbare beleuchtungs LED und keine Status LED zu sein.

LED ist bei mir auch nicht bestückt, mit 1k Vorwiderstand laut 
Schaltplan wohl offenbar nur als Spannungsanzeige gedacht gewesen.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

David D. schrieb:
> Damit muss ich mir schonmal keine Gedanken machen, dass während des HREF
> plötzlich was unerwartes in den Fifo geschrieben wird

Das hast Du messerscharf erkannt!

Ich finde überhaupt, dass Du Dich sehr konsequent und zielgerichtet 
einliest und alles recht fix kapierst.

Du brauchst Dein Licht nur nicht so unter den Scheffel zu stellen.
Bescheidenheit ist eine Zier, doch es besser lebt man ohne ihr.

Habe ich das weiter oben richtig verstanden, dass so ein heller Kopf wie 
Du sich keinen LogicAnalyzer für 100 Mäuse leisten kann? Wenn das 
stimmt, so denke nochmals über Deinen aktuellen Arbeitgeber nach.

Anders ist die Situation natürlich, wenn Du und Dein Liebste gerade 
Drillinge bekommen oder ein Haus gebaut habt ...

Viele Grüße

Igel1

[Dieter F. (Gast)]

Hi,

damit ihr mal ein wenig Lachen könnt :-)

Immerhin bekomme ich meine Daten nach Python übertragen. Es soll eine 
Color-Bar sein (Register 0x12 Wert 0x06) :-). Mit viel Phantasie erkennt 
man das sogar ...

Python kommt offensichtlich nicht mit und "ruckelt Verschieber" rein.

Die Daten kommen sauber an (mit HTERM geprüft) - nur die 
Python-Eingangsverarbeitung hakelt scheinbar etwas.

Meine Register-Einstellungen:

  //Reset Register
  write_register_i2c(0x12, 0x80);
   _delay_ms(100);
  
  //Pixel-Clock = Input-Clock/2  (!! + Register 0x3e und 0x73)
  write_register_i2c(0x11, 0x02);
  
  //Home - Steuerung Belichtung
  write_register_i2c(0x13, 0xe5); //AWB off
  write_register_i2c(0x01, 0x96);
  write_register_i2c(0x02, 0x40);
  
  //Saturation 0
  write_register_i2c(0x4f, 0x80);
  write_register_i2c(0x50, 0x80);
  write_register_i2c(0x51, 0x00);
  write_register_i2c(0x52, 0x22);
  write_register_i2c(0x53, 0x5e);
  write_register_i2c(0x54, 0x80);
  write_register_i2c(0x58, 0x9e);
  
  //Brightness 0
  write_register_i2c(0x55, 0x00);
  
  //QQVGA
//  write_register_i2c(0x12, 0x04);    //"normale" Funktion RGB
  write_register_i2c(0x12, 0x06);    //"normale" Funktion RGB - + Color Bar
  write_register_i2c(0x0C, 0x04);    //DCW enable
  write_register_i2c(0x3E, 0x1A);    //DCW and scaling PCLK / 4
  write_register_i2c(0x70, 0x3A);    //Horizontaler Skalierungs-Faktor
  write_register_i2c(0x71, 0x35);    //Vertikaler Skalierungs-Faktor
  write_register_i2c(0x72, 0x22);    //DCW control parameter
  write_register_i2c(0x73, 0xF2);    //Clock divider für DSP / 4
  write_register_i2c(0xA2, 0x02);    //Histogramm ...
  write_register_i2c(0x56, 0x40);    //Kontrast 0

Das Timing auf Kamera-Seite sieht (aus meiner Sicht) hingegen gut aus:

Gelb    -> VSYNC
Violett -> HREF
Blau    -> TX

(Ich sende den String "Start" bei jedem neuen Bild - daher der "blaue 
Ausreisser")

QQVGA hat den Vorteil, dass nur jeder 4. HREF-Slot (im Vergleich zu VGA) 
Daten enthält/übermittelt. Die "Totzeit" nutze ich für die serielle 
Übertragung.

VG
Dieter

[Michael U. (amiga)]

Hallo,

ok, Löten habe ich noch geschafft, läuft auf dem Arduino UNO, aber nicht 
sinnvoll... Ein halbwegs fehlerfreies Bild bekomme ich nur manchmal.
Morgen hänge ich mal den LA ran und schaue mir das erstmal an, ob 
erkennbar ist, wo es klemmt.
Zumindest kann ich jetzt wahlweise auch mal mit der FiFo-Version 
rumspielen.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hi Leute,

na das sieht bei Dieter doch schon ganz "interessant" aus.
Und Michael hat sich ein Bienchen für sauberes Löten verdient!

Ich selber debugge mich so durch die Gegend.

Bislang gefunden:

- Hatte vergessen die Ports-Initialisierungsfunktion aufzurufen.
  Ergo waren alle Steuerein- und Ausgänge hochohmig und es passierte
  gar nichts.

- Sodann hatte ich vergessen FIFO_OE auf LOW zu setzen: folglich
  waren die Datenausgänge des AL422B ebenfalls hochohmig und nichts
  kam heraus.

Ansteuerung und Timings sehen mir inzwischen ganz passabel aus.
Inzwischen habe ich graue Mäuse auf grauem Hintergrund - supi ...

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Und Michael hat sich ein Bienchen für sauberes Löten verdient!

naja, mal schauen, ob Du bei Deinem Bienchen bleibst... ;-)

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> naja, mal schauen, ob Du bei Deinem Bienchen bleibst... ;-)

Okay - ersetze "Bienchen" bitte durch "dicken Brummer".
Mama mia ...

Viele Grüße

Igel1

[Andreas S. (igel1)]

Verflixte Hacke, wo liegt der Fehler?

Bitte schaut Euch mal die Ansteuerung des Moduls für den Einlesezyklus 
an:
Mit dieser Ansteuerung will ich ein Bild von der Kamera in den FiFo 
schieben.

Seht Ihr irgendwelche Fehler?

Viele Grüße

Igel1

[Andreas S. (igel1)]

Aha - habe soeben einmal die Register mit einer Zahlen-Kombination aus 
dem Internet gefüllt.  Es erscheinen erste, schemenhafte Bilder.

Alles sehr bleich.
Ist scheinbar noch ein längerer Weg bis zum ersten echten, scharfen 
Bild.

Gute Nacht

Igel1

[David D. (saturi)]

Hey!  Na das hört sich doch schonmal gut an! Hast du an deinen read 
weite Funktionen was ändern müssen? Bei mir bleibt es leider dabei, dass 
ich nicht mal zweimal das gleiche auslesen kann -,-

[Andreas S. (igel1)]

David D. schrieb:
> Hey!  Na das hört sich doch schonmal gut an! Hast du an deinen read
> weite Funktionen was ändern müssen? Bei mir bleibt es leider dabei, dass
> ich nicht mal zweimal das gleiche auslesen kann -,-

Bitte in meinem Falle nicht den Tag vor dem Abend loben ...
Es ist noch weit, weit entfernt davon, ein Bild zu ergeben.
Aktuell kann ich nur sagen: es kommt irgendwas vorne rein,
was scheinbar irgendetwas mit dem zu tun hat, was hinten rauskommt.
Nicht mehr und nicht weniger.

Was Dein Problem angeht, so sehe ich zwei mögliche/wahrscheinliche
Ursachen:

1.)  Du hältst das Schreiben des OV7670 in den FiFo nicht an.
     Will sagen: prüfe einmal, ob Du nach dem Schreiben (also
     nach dem Auslesen des Bildes) das Signal FIFO_WE auf LOW
     legst (und dort für die gesamte Zeit des späteren
     FIFO-Auslesens auch auf LOW belässt). Ein LogicAnalyzer
     ist in diesem Zs.hang Gold wert.

2.)  Du machst evtl. keinen Address Pointer Reset, bevor Du
     den FiFo ausliest:
     Prüfe, ob Du wirklich vor jedem Auslesen FIFO_RRST auf
     LOW legst und sofort, nachdem Du FIFO_RRST auf HIGH
     ziehst mit der ersten steigenden RCK-Flanke Deine Daten
     ausliest.

Mehr fällt mir aktuell auch nicht dazu ein.

Viele Grüße

Igel1

[Andreas S. (igel1)]

... man muss nur das richtige "Model" nehmen, schon erkennt man erste, 
zarte Erfolgspflänzchen ...

1. Photo:  Original
2. Photo:  ... na ratet mal ...

Fazit: es muss noch weiter am Code gestrickt werden.

Irgendetwas mit der Horizontal- und der Vertikalauflösung stimmt da noch 
nicht. Auch scheint mir das Bild noch furchtbar blass ...

Schau'n wir mal ...

Viele Grüße

Igel1

[Dieter F. (Gast)]

Andreas S. schrieb:
> Fazit: es muss noch weiter am Code gestrickt werden.

Hi,

nein - das ist  meiner Meinung nach eine reine Parameter-Einstellung der 
Kamera.

Ich bekomme auch herrlich bunte Bilder, welche mit viel Phantasie das 
abbilden, was ich sehe. Da kommen dann bekannte und "magic"-Parameter 
ins Spiel. An dieser Stelle klinke ich mich aus. Es bringt mir überhaupt 
nichts, wenn ich irgendwelche Register-Einstellungen (ohne den 
Hintergrund zu kennen) nachstelle. Ich kenne den "Implementation Guide" 
und den "Software Guide" zur Kamera - aber beides ist unzureichend.

Da arbeite ich lieber mit Liniensensoren, bei denen ich ich die 
Umsetzung (Helligkeit etc.) selbst steuern muss.

Ich habe mal mit dem Gedanken gespielt, die OV7670 als Sensor für eine 
Spektralanalyse einzusetzen - das habe ich hiermit verworfen (also ein 
erfolgreicher POC :-) ).

Der ATMega328x ist schlicht nicht ausreichend, um mit diesem 
Kamera-Modul (egal ob mit oder ohne Fifo) umzugehen. Nur für ein 
Standbild ist der Fifo sinnvoll, da das Kamerabild dann für die weitere 
Verarbeitung  (VGA etc.) zwischengespeichert wird. Aber wozu?

Der ATMega328x ist schlicht unzureichend, um weitere Verarbeitung(en) 
durchzuführen. Auch ein ATXMega (trotz DMA) wird da überfordert sein.

Es war nett, das mal auszuprobieren - aber es macht aus meiner Sicht 
keinen Sinn, weiter zu machen. Irgendwelche Einstellungen nachzumachen 
(oder zu kopieren) macht für mich keinen Sinn. Die Kamera / die 
Einstellungen sind so schlecht dokumentiert, dass ich da nicht 
weitermachen möchte.

Viel Spass noch allen und viele Grüße
Dieter

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Der ATMega328x ist schlicht nicht ausreichend, um mit diesem
> Kamera-Modul (egal ob mit oder ohne Fifo) umzugehen. Nur für ein
> Standbild ist der Fifo sinnvoll, da das Kamerabild dann für die weitere
> Verarbeitung  (VGA etc.) zwischengespeichert wird. Aber wozu?

ein "wozu" gibt es bei der Geschichte für mich ohnehin nicht.
Der Kamera-Sensor ist einer der ersten, die es für Handy-Kameras 
überhaupt gab. von dieser Seite sind also ohnehin keine Wunder zu 
erwarten.
Ich hatte am Anfang schon mal erwaähnt, daß ich die DC3840 auch hier 
habe, die dürfte den gleichen Sensor drin haben. Die gehörte zu 
irgendeinem Siemens-Handy als Aufsteckkamera und wurde um 2007 für 1,-€ 
verramscht.
https://www.ulrichradig.de/home/index.php/projekte/uC-kamera
Unterschied ist, daß der benutzte IC OV528 einen JPEG-Encoder enthält 
und die Daten im Original mit 921kBaud seriell rausschickt.
Sowas als Standbild kann man mit einem Mega328 mit der OV7670 bermitlich 
auch schaffen. Nicht mehr und nicht weniger...
Ich hatte die DC3840 inzwischen mal erfolgreich an einen ESP8266 
gehängt, der mir auf zum Webbrowser auch ein "Foto" in 640x480 schickt.
Dauert, wie auch damals am Mega32 mit ENC28J60 als LAN-Interface, 
etliche Sekunden bis das Bild komplett da ist.
Die OV7670 kommt am Mega328 da schlechter weg, weil sie ohne FiFo keinen 
Snapshot kann und mit FiFo die Pins nicht mehr reichen, um z.B. SPI noch 
nutzen zu können.

Dieter F. schrieb:
> Ich kenne den "Implementation Guide"
> und den "Software Guide" zur Kamera - aber beides ist unzureichend.
Kann ich bis jetzt noch nicht sagen, ich habe mir noch nicht die Zeit 
genommen, da genauer durchzuschauen. Letztlich sind aber wohl die Leute 
damals damit ja auch zurechtgekommen.

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Michael U. schrieb:
> Letztlich sind aber wohl die Leute
> damals damit ja auch zurechtgekommen.

Dann schau mal weiter nach - ich bin gespannt.

[Andreas S. (igel1)]

@Dieter:

Ja, ich bin inzwischen auch mächtig abgenervt von der 
Register-Setting-Lotterie.

Es muss doch irgendwen geben der das optimale Setting herausgefunden hat 
...

Viele Grüße

Igel1

[Dieter F. (Gast)]

Andreas S. schrieb:
> Es muss doch irgendwen geben der das optimale Setting herausgefunden hat

Moin,

ja - dazu habe ich auch etwas gefunden.

Der Hersteller gibt "Geschäftskunden" - nach "non disclosure agreement" 
- weiterführende Unterlagen ...

Also bleibt nur, bestehende (funktionierende) Einstellungen 
"abzukupfern" oder langwierig zu experimentieren. Beides sind für mich 
keine Alternativen.

VG
Dieter

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Der Hersteller gibt "Geschäftskunden" - nach "non disclosure agreement"
> - weiterführende Unterlagen ...
>
> Also bleibt nur, bestehende (funktionierende) Einstellungen
> "abzukupfern" oder langwierig zu experimentieren. Beides sind für mich
> keine Alternativen.

werden diese Module heute wirklich noch irgendwo eingesetzt außer als 
NOS-Restposten für ein paar Hobbybastler? Ich kann es mir eigentlich 
nicht vorstellen. Die Daten passeg zu gut zu den damaligen ersten 
Webcams und da war man froh, wenn der Rechner 320x240 mit 10-15 Fps 
zustande gebracht hat.
Wir haben damals private Videosession mit einem Bekannten in Kanada 
gemacht, mehre als 5-10 Fps kamen da ohnehin nie stabil zustande. 
Lichtempfindlichkeit war sowieso miserabel (für heutige Verhältnisse).

Du hast doch, genau wie ich, schon ein Bild zu sehen bekommen. Die 
Grundsettings für YUV in 320x240 passten also grundsätzlich erstmal.
Sie Einstellungen von Deinem Link und von meinen sind identisch, die 
kompletten Sourcen soweit auch.

Ich kenne mit den OV7670 kaum was fertiges, auch für die OV2760 ist die 
Luft da dünn. Eine QR-Code-Auswertung und einen Roboter, der die Bilder 
mit wenigen Fps schickt, das war es eigentlich auch schon.

Kamera am "Arduino" und die Preise sind meiner Meinung nach die Auslöser 
für den Hype auf die Dinger. Es werden wohl die meisten gekauften 
irgendwo in der Ecke liegen, weil am letztlich keine irgendwie sinnvolle 
Anwendung dafür gefunden hat.
Ein RasPi Zero W mit der RasPi-Cam läßt die Dinger doch sowieso nur alt 
aussehen...

Gruß aus Berlin
Michael

[Michael U. (amiga)]

Hallo,

ich hoffe ja, daß zumindest David noch im Boot ist...
Ich habe mich jetzt mal mit meinem tollen Träger etwas über die 
FiFo-Version hergemacht. Erste Erkenntnis: Der Arduino UNO mit Mega16U2 
bekommen im Gegensatz zum CH340 1MBit nicht auf die Reihe, mehr als 
230400 geht nicht stabil. Macht es etwas umständlich, mir "mal schnell" 
ein Bild anzeigen zu lassen.
Kamera-Init habe ich erstmal grob nach dem Application-pdf auf die 12MHz 
meiner FiFo-version gesetzt. Grob, weil statt der 15 Fps nur 7,5 Fps von 
der Kamera ausgegeben werden, da stimmt also noch was nicht.
FiFo lesen scheint zu passen und einlesen von der Kamera wohl auch, ich 
bekomme zumindest identsche Bilder geliefert, auf denen ein zufällig im 
Bildfeld befindlicher USB-Stecker mit einem Schild mit Barcodes drauf 
zumindest gut zu identifizieren ist...

Jetzt ist aber erstmal andere Beschäftigung dran.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> Kamera-Init habe ich erstmal grob nach dem Application-pdf auf die 12MHz
> meiner FiFo-version gesetzt.

Verstehe nicht ganz, was Du damit meinst.

> Grob, weil statt der 15 Fps nur 7,5 Fps von
> der Kamera ausgegeben werden, da stimmt also noch was nicht.

Du hast beachtet, dass die Schreiber des Implementation Guide von einem 
Szenario mit 24MHz-Quarz ausgehen, wir aber nur einen 12MHz-Quarz auf 
dem Board sitzen haben?

> FiFo lesen scheint zu passen und einlesen von der Kamera wohl auch, ich
> bekomme zumindest identsche Bilder geliefert, auf denen ein zufällig im
> Bildfeld befindlicher USB-Stecker mit einem Schild mit Barcodes drauf
> zumindest gut zu identifizieren ist...

Welchen Code verwendest Du?
Ich bin allerwärmstens daran interessiert.

Ich selber habe irgendetwas in meinem Code verschlimmbessert und nun 
bekomme ich noch nicht einmal mehr die schwachen Bilder aus dem Teil 
herausgefischt.

Und dabei habe ich sogar noch einen kapitalen Fehler in meiner Software 
gefunden, der erklärt, warum das Bild so unglaublich blass war.
Aber aktuell ist leider "rien ne vas plus" angesagt.

Viele Grüße

Igel1

[Dieter F. (Gast)]

Andreas S. schrieb:
> Du hast beachtet, dass die Schreiber des Implementation Guide von einem
> Szenario mit 24MHz-Quarz ausgehen, wir aber nur einen 12MHz-Quarz auf
> dem Board sitzen haben?

Ja - spannend. Da geht dann wieder die "Raterei" los - auf die ich (wen 
wundert es) keine Lust habe.

Im tollen "Software Implementation Guide" kommt auch nicht viel mehr.

Das ist eine "Totgeburt", welche mich "Gott-sei-Dank"  nur ca. 10 € (für 
4 Module - wer will noch welche?) gekostet hat.

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Du hast beachtet, dass die Schreiber des Implementation Guide von einem
> Szenario mit 24MHz-Quarz ausgehen, wir aber nur einen 12MHz-Quarz auf
> dem Board sitzen haben?

ich benutze immernoch die Arduino-Software, läßt sich auch problemlos 
auch im alten AVR-Studio 4.18 compilieren.
Ich habe nur das PinOut an die FiFo-Version angepasst und die 
Initialisierung entsprechend geändert. Dann habe ich captureImg() vom 
Auslesen der OV7670 ohne FiFo und rausschicken auf die FiFo-Geschichte 
umgebaut.
Dabei fiel mir dann auf, das wohl der Uno nicht mit 1MBuad klarkommt.
usw. usw.
Die ursprüngliche Sourve betrieb ja die OV7670 ohne FiFo mit 8MHz XCLK 
vom AVR erzeugt und hatte auch die Teiler noch "seltsam" gesetzt.

Die 12MHz Registerwerte stammen aus der OV7670 Applikation.pdf Punkt 3.1 
zweiter Block: 15fps PCLK = 12Mhz
Da bekam ich aber nur 7,5 fps raus.
Jetzt kommt dann Dieters berechtigte Maulerei zum Zuge... ;)
Register CLKRC (0x11) hat einen default von 0x80. Bit 7 ist aber als 
Reserved angegeben. Mit 0x00 teilt der Kram aber definitv durch 2...
Mit 0x80 (default) teilt es durch 1 (teiler aktiv, Teilerwert 0 000 + 1.
bit 7 ist also wohl nicht so "reserved" wie angegeben, eigentlich müßte 
auch 0x40 (kein Vorteiler) richtig sein, muß ich morgen mal testen.
Problem ist im Moment, daß in der Source für die OV7670 ohne FiFo 
ziemlich an den Werten rumgebogen wurde, um bei einer Baudrate von 
1MBaud, also rund 100kB/pro Sekundedie Kamera auch einen PCLK von 100kHz 
zu bekommen und (manchmal) ein Bild zustande zu bringen. Das muß ich 
erstmal auf sinnvolle Werte bringen.
Ich habe zwar noch eine Source mit FiFo gefunden, was der da aber treibt 
ist mir noch völlig unklar...

Gruß aus Berlin
Michael

[David D. (saturi)]

Hallo zusammen,
huch hier ist jetzt aber schlechte Stimmung aufgekommen :D

Freut euch doch erstmal, dass es bei euch soweit schon geht...

>Aber aktuell ist leider "rien ne vas plus" angesagt.
:D der ist gut... :D

Zum Thema Oszi, nein ich würde mich aktuell nicht über meinen 
Arbeitgeber beschweren, aber nach einem halben Jahr Arbeiten habe ich 
leider das Zinslose Schuldenkonto bei meinen Eltern noch nicht tilgen 
können, sodass ein Invest von über 100€ fürs "Bastel-Hobby" leider noch 
nicht drin sind...


ABER da viel mir meine Fehlinvestition von 100€ während des Studiums ein 
:D ein USB Oszi DDS140 von Sainsmart incl. Signalgenerator und 
Logicanalyzer...Spart euch die Kommentare... Die Software war/ist 
einfach so verbuggt, dass ein vernünftiger Umgang da leider nicht 
möglich ist. Dann habe ich gestern aber im Netz ein Java-Programm 
gefunden, dass mit dem kompatibel ist und siehe da, ich kann den Logic 
analyzer in Betriebnehmen! (mit einigen abstrichen, aber auf den ersten 
Blick siehts ganz gut aus.)


Ich nutze zwar eine leicht andere Sequenz als du für das schreiben, aber 
in der Theorie sollte es passen.
 Morgen komme ich hoffentlich nochmal dazu etwas auszuprobieren und 
werde euch dann meine Sequenz mal offen legen.

Da ich ja leider auch von Fehlern in meinem Terminal Programm ausgehen 
muss, wäre es super, wenn mir mal jemand erklären könnte, wie ich aus 
dem Bytestream im Terminal (zb. H-Term) ein Bild zauber kann, um zu 
überprüfen, ob mein Terminal auch wirklich das Empfangene anzeigt.

Danke und bis Morgen

David

[Andreas S. (Gast)]

... wird laaangsam ...

VG
Igel1

[Dieter F. (Gast)]

David D. schrieb:
> huch hier ist jetzt aber schlechte Stimmung aufgekommen :D

Nö - keine schlechte Stimmung - nur etwas Frust, das es nur mit Raterei 
oder Abkupfern weiter geht :-\

Zur Bilderzeugung kann ich gerne mein Python-Scriptchen (primitiv - aber 
funktionierend und leicht anpassbar) zur Verfügung stellen (heute 
Abend).

VG
Dieter

[David D. (saturi)]

> Zur Bilderzeugung kann ich gerne mein Python-Scriptchen (primitiv - aber
> funktionierend und leicht anpassbar) zur Verfügung stellen (heute
> Abend).
das wäre subba :)

[David D. (saturi)]

Sooo....

1. Möglichkeit:
Ich habe es einfach IMMERNOCHNICHT verstanden...
2. Möglichkeit:
Mein Terminal Programm funktioniert nicht.

Anbei meine Signalverläufe, mit einem mehr oder weniger zuverlässigem 
LogicAnalyzer... Dennoch denke ich, dass die Signalverläufe so sind wie 
dort aufgenommen, weil das auch meiner Programmierlogik entspricht.

Gibt es da irgendetwas falsches dran?
Ich danke euch für jeden Hinweis...

Gruß
David

Edit: OE überigens auf GND

[David D. (saturi)]

Am Terminal scheint es auch nicht zu liegen... wenn ich mit der gleichen 
Funktion ein hochzählendes Byte rausschicke zeigt mir das Terminal im 
yuv format was plausibles an....

Auch wenn der Bildstream dann irgendwann abbricht weil irgendwas nicht 
passt...

wo liegt denn bloß mein Fehler :(

[Michael U. (amiga)]

Hallo,

@David D.: beim flüchtigen Hinsehen sieht es stimmig aus. Ich habe im 
Moment aber auch irgendwo Probleme mit der Übernahme Kamera -> FiFo, 
habe aber auch etwas rumgespielt und komme wohl erst morgen dazu, 
nachzuschauen.

@ Dieter F.. am Python-Script hätte ich auch Interesse, einlesen mit 
TeraTerm v6.9 und speichern geht zwar zuverlässig, ist aber umständlich, 
Anzeige dann als RAW in Irfanview.

@Andreas S.: würdest Du Deine Registerwerte zu obigem Bild hier 
reinstellen/anhängen?

Ich habe zwischendurch mal nach und nach die Registereinstellungen aus 
dem Applikation-pdf mal etwas für mich kommentiert. Oha, oha, 
genaugenommen macht das Teil mehr als gut ist. ;) AGC, AWB, AEC, 
DeNoise, Colormatrix, Linsenkorrektur usw. usw. Sagt mir grundsätzlich 
zwar fast alles was, aber da kann und muß man sich an vielen Stellen auf 
die Herstellerwerte verlassen.
Ich denke auch, daß damals, als die Dinger aktuell ware, Firmen, die 
Stückzahlen für z.B. eine Webcam beteltt haben, einfach sagen konnen, 
das sie passende Initwerte für die Sensor-Charge und Optik xy dazu haben 
wollen und die auch bekamen.

Ich hänge das mal hier an, ist das default-array für die verlinkten 
Arduino-Sourcen.

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

David D. schrieb:
> das wäre subba :)

Auf eigene Gefahr ... :-)

Das Script schreibt halt jede Menge Bilder in den aufrufenden Pfad ...

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Auf eigene Gefahr ... :-)

Danke, ich liebe die Gefahr. ;-)

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hui - hier hat sich wieder viel getan.

Fangen wir mit David an:

Schön, dass Dein LA nun funktioniert!  Und sehr löblich,
den Kredit an Deine Eltern zurückzuzahlen und dafür auf
Hobby-Equipment zu verzichten - scheinst ein feiner Kerl zu sein.

Was Deine Signale angeht, so sehen die gut aus (wenn man es
riskieren möchte, entgegen dem AL422B-Datenblatt den RCK-Takt
nicht durchlaufen zu lassen).


Und nun zu Michael:

> würdest Du Deine Registerwerte zu obigem Bild hier reinstellen/anhängen?

Aber gerne:

static unsigned char OV7670_QVGA[][2]=
{
  0x12, 0x80,

  0x11, 0x01,         // see Implementation Guide "30 fps QVGA YUV mode"
  0x12, 0x10,         // original: YUV422 = 0x00;
  0x40, 0xD0,         // original: not set
  0x0C, 0x04,
  0x3E, 0x19,
  0x70, 0x3A,
  0x71, 0x35,
  0x72, 0x11,
  0x73, 0xF1,
  0xA2, 0x02,

  0x13, 0x8B,
  REG_COM9 , 0x6A,    // 128x gain ceiling; 0x8 is reserved bit

    0x4f , 0x80 ,  // "matrix coefficient 1"
    0x50 , 0x80 ,  // "matrix coefficient 2"
    0x51 , 0  ,    // vb
    0x52 , 0x22 ,  // "matrix coefficient 4"
    0x53 , 0x5e ,  // "matrix coefficient 5"
    0x54 , 0x80   // "matrix coefficient 6"
};

Achtung, grosse Erkenntnis:

Eigentlich würde man bei diesen Werten ein 320x240 QVGA-Bild
im RGB-Modus erwarten. Aber: April, April.

Heraus kommt ein 315x240 Bild !!

Wäre ich nicht vor 1,5 Jahren schon darauf gestoßen, hätte es
mich sicherlich Tage gekostet, das zu bemerken.

Mein Tipp des Tages lautet daher:

Prüft mit dem Oszi oder mit dem LA genau die Länge der HREF-
Pulse und rechnet zurück, ob die von Euch erwartete Zeilenbreite
bei der von Euch gesetzten Taktrate auch tatsächlich zu der
Länge des HREF-Pulses passt.

In meinem Fall konnte ich so exakt auf die 315 Pixelbreite
einer Zeile schließen. Schon bei geringen Abweichungen in der
Darstellung - ich habe zunächst mit 320 Pixel/Zeile dargestellt -
kann man kein Bild mehr erkennen/erahnen.

Und zum Schluss zu Dieter:

Saubere Leistung: Blitzeblanker Code - kein Kommentar trübt
die Ästhetik - daran erkennt man den Hardcore-Programmierer :-)
Aber einem geschenkten Gaul guckt man ja bekanntlich nicht ins
Maul, also: Danke für den Code! Sobald ich mit meinem LCD-Display
nicht mehr zufrieden bin, kommt Dein Code zum Einsatz.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

erstmal Danke für Deine Registerwerte, ich hoffe mal, ich komme morgen 
dazu, was damit zu machen.

Andreas S. schrieb:
> Und zum Schluss zu Dieter:
>
> Saubere Leistung: Blitzeblanker Code - kein Kommentar trübt
> die Ästhetik - daran erkennt man den Hardcore-Programmierer :-)
> Aber einem geschenkten Gaul guckt man ja bekanntlich nicht ins
> Maul, also: Danke für den Code! Sobald ich mit meinem LCD-Display
> nicht mehr zufrieden bin, kommt Dein Code zum Einsatz.

naja, ich habe von Python keine Ahnung, aber den Ablauf kann ich auch 
ohne Kommentare verstehen. Die Python-spezifischen Sachen müßte ich 
ohnehin googeln... :-)

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> naja, ich habe von Python keine Ahnung, aber den Ablauf kann ich auch
> ohne Kommentare verstehen. Die Python-spezifischen Sachen müßte ich
> ohnehin googeln... :-)

Nu fall Du mir nicht auch noch in den Rücken, wenn ich hier gerade
versuche, Dieter auf den Pfad der Tugend zu bringen!

Viele Grüße

Igel1

[David D. (saturi)]

mein Problem ist, dass ich die Baudrate nicht hochsetzten kann... dann 
kommt nur noch mist am PC an... und ich weiß nicht warum... ich bin mit 
leppigen 19200 im rennen -.-

okay habe es jetzt mal geschafft meinen RCK auf 500Hz anzuheben... vlt. 
geht noch mehr... aber wie macht ihr das denn, wenn ihr RCK 
"durchlaufen" lasst? mit welcher taktrate lest ihr aus?

[Andreas S. (igel1)]

David D. schrieb:
> mein Problem ist, dass ich die Baudrate nicht hochsetzten kann... dann
> kommt nur noch mist am PC an... und ich weiß nicht warum... ich bin mit
> leppigen 19200 im rennen -.-
>
> okay habe es jetzt mal geschafft meinen RCK auf 500Hz anzuheben... vlt.
> geht noch mehr... aber wie macht ihr das denn, wenn ihr RCK
> "durchlaufen" lasst? mit welcher taktrate lest ihr aus?

Ich lasse RCK mit 10kHz durchlaufen und schreibe die Pixel dann Pixel 
für Pixel auf das LCD-Display auf meinem Board. Ich nutze also gar kein 
UART.

Viele Grüße

Igel1

[Andreas S. (igel1)]

Hi,

anbei das Foto des Tages
(links Original, rechts OV7670-Aufnahme dargestellt auf 2.4 Zoll ILI9341 
TFT LCD Billig-Display )

Register-Settings:

static unsigned char OV7670_QVGA[][2]=
{
  0x12, 0x80,

  0x11, 0x00,
  0x12, 0x14,         // original: YUV422 = 0x00;      
  0x40, 0xD0,         // original: not set
  0x0C, 0x04,
  0x3E, 0x19,
  0x70, 0x3A,
  0x71, 0x35,
  0x72, 0x11,
  0x73, 0xF1,
  0xA2, 0x02,

  0x13, 0x8B,
  REG_COM9 , 0x6A,    // 128x gain ceiling; 0x8 is reserved bit

    0x4f , 0x80 ,  // "matrix coefficient 1"
    0x50 , 0x80 ,  // "matrix coefficient 2"
    0x51 , 0  ,    // vb
    0x52 , 0x22 ,  // "matrix coefficient 4"
    0x53 , 0x5e ,  // "matrix coefficient 5"
    0x54 , 0x80   // "matrix coefficient 6"
};

So weit, so gut, aber jetzt kommen die Überraschungen:

Zeilenlänge:  313 Pixel a 2 Bytes pro Pixel

Farbfolge:    [Byte1][Byte2] : [GGGGGRRR][RRRBBBBB]

... wer hätte das gedacht ...

Viele Grüße

Igel1


PS: das OV7670-Bild ist in Wirklichkeit noch etwas besser als hier im 
Anhang abgebildet - beim Abfotografieren und Hochladen geht etwas 
Qualität futsch.

[Michael U. (amiga)]

Hallo,

sicher? Entweder 555 oder 565, 6 Bit ist aber immer Grün weil der Mensch 
bei grün das bessere Detailauflösungsvermögen hat. Rot und Blau sieht 
man schlechter, da reichen dann weniger Bits.
Die Kamera ist noch stark an TV angelehnt, auch das interleave YU/YV 
über 2 Zeilen ist dafür typisch, kann man gut TV-Signale draus basteln 
R-Y und B-Y werden da übertragen, G-Y wird daraus dann per Matrix 
gewonnen. Rührt auch von TV hier, mal konnte bei PAL/SECAM/NTSC sinnvoll 
nur ein Farbsignal zusätzlich in die Zeile packen (Kompatibilität zu s/w 
war damals noch sehr wichtig). Für Display braucht man sowas nicht mehr.

Grrr, ungewöhnlich für mich, mitten in der Nacht, ich werde wach und bin 
putzmunter...

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Andreas S. schrieb:
> Nu fall Du mir nicht auch noch in den Rücken, wenn ich hier gerade
> versuche, Dieter auf den Pfad der Tugend zu bringen!

Moin,

das habe ich einfach nur mal auf die Schnelle gemacht - soll auch nicht 
bleibend sein. Einfach nur ein Script-Arbeitsstand.

Meine Programme sehen besser aus :-) und für den Pfad der Tugend bin ich 
zu alt.

Ansonsten: Schönes Bild, gratuliere ...

VG
Dieter

[Michael U. (amiga)]

Hallo,

@Andreas S.: ich nehme erstmal alles zurück und behaupte das Gegentum.
Ich habe mal den Farbbalken angemacht, das sieht aber mehr als komisch 
aus...
Ich muß aber bei meinen Registerwerten erstmal wieder Ordnung machen.

RGB565 scheint aber hier schon zu passen. Bei mir sind unten die letzten 
Zeilen nicht mehr sinnvoll gefüllt.

Aber erstmal wieder anderen Dingen widmen...

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Dieter F. schrieb:

> Meine Programme sehen besser aus :-) und für den Pfad der Tugend bin ich
> zu alt.

Oh, dann ist also Hopfen und Malz bei Dir schon verloren.
Na dann müssen wir Dich (und Deine Programme) halt so nehmen,
wie Du bist ;-)   ;-)  :-)

> Ansonsten: Schönes Bild, gratuliere ...

Oh dankeschön! So ein bisschen Anerkennung tut ja jedem Hobby-Bastler 
gut ...

Viele Grüße

Igel1

[Andreas S. (igel1)]

Michael U. schrieb:

> @Andreas S.: ich nehme erstmal alles zurück und behaupte das Gegentum.

Probate Vorgehensweise - mache ich auch immer so :-)

> Ich habe mal den Farbbalken angemacht, das sieht aber mehr als komisch
> aus...

Mit welchen Register-Settings hast Du welchen Farbbalken aufgenommen?
Evtl. möchtest Du beides noch nachlegen.

> Ich muß aber bei meinen Registerwerten erstmal wieder Ordnung machen.

Ordnung wird total überschätzt - versuche ich seit Jahren meiner 
Besseren Hälfte klar zu machen ...

> RGB565 scheint aber hier schon zu passen.

Das ist das größte Mysterium, mit dem ich aktuell kämpfe - bei mir passt 
es so gar nicht. Wie kann das nur sein?

> Bei mir sind unten die letzten
> Zeilen nicht mehr sinnvoll gefüllt.

Hmmm - scheint aus dem Takt zu kommen ...

> Aber erstmal wieder anderen Dingen widmen...

Ja, ja - die Rentner ;-)

> Gruß aus Berlin
> Michael

Grüße aus Aachen

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Mit welchen Register-Settings hast Du welchen Farbbalken aufgenommen?
> Evtl. möchtest Du beides noch nachlegen.

das sind die von der Kamera erzeugten Color Bars.
  { 0x12, 0x16 },  // COM7  - Selects QVGA [4] und RGB [2][0]  [1] color bar on
  { 0x42, 0x08 },  // COM17 - AEC Window [7:6] Bit 1 und 0 wie COM4 [5:4], DSP Color Bar on/off[3]

Andreas S. schrieb:
>> Bei mir sind unten die letzten
>> Zeilen nicht mehr sinnvoll gefüllt.
>
> Hmmm - scheint aus dem Takt zu kommen ...

bisher keine Ahnung, wo, vermutlich schon falsch von der Kamera in den 
FiFo, das Muster bleibt immer identisch.

Andreas S. schrieb:
> Ja, ja - die Rentner ;-)

bekanntermaßen haben die niemals Zeit... :-))

ok, gerade mal am Timing beim FiFo lesen etwas rumgespielt, sieht jetzt 
schon mehr nach Farbbalken aus.
Vielleicht hätte ich einfach mal oben schauen sollen, wie Du das machst?

Gruß aus Berlin
Michael

[Michael U. (amiga)]

Hallo,

so, mühsam ernährt sich das Eichhörnchen...

Ich habe das ino mal angehängt, am Ende den Arduino-Block 
auskommentieren und den AVR-Studio Block aktivieren, dann geht es auch 
als Studio Projekt zu compilieren.

Änderungen: Gamma-Werte auf die defaults aus dem Datenblatt gesetzt, 
passt erstmal ganz gut.
ov7670_default_regs sind die Settings aus Applikation, nur Gamma 
verändert.
Rest in regval_list yuv422_ov7670 und rgb565_ov7670 ist zusammengesucht, 
aber nur noch mit den rgb565 Settings getestet.

Chaos damit Andres S. auch seine Freude hat. :-)

PS: Baudrate steht auf 230400, mehr macht mein UNO mit dem Mega16U2 als 
USB-Wandler nicht stabil...

PPS: Format ist definitiv RGB565, BigEndian.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

@Michael: danke für die Tipps - die Colorbalken wollte ich mir auch 
schon immer einmal anschauen, war bislang nur zu faul, die Register 
zusammenzusuchen.

Meine Ausgabe findest Du im Anhang.
Jetzt können wir rätseln, welche Ausgabe nun richtig ist ...
Ich finde meine auch ganz hübsch :-)
Aber korrekt wird vermutlich nur eine von beiden sein (wobei mein 4€ 
China-TFT-LCD Display sicherlich auch einiges an Fehlern in die Sache 
reinbringt.

Ich bin aktuell noch zu faul, mir Code für die Ausgabe in Richtung PC zu 
stricken. Mit so einem ARM-Prozessor braucht's da doch immer etwas mehr 
Überwindung als mit einem Arduino, wo alles schon parat liegt.

Viele Grüße

Igel1

[David D. (saturi)]

Vielen Dank für eure Dateien, die werde ich mir dann am Wochenende 
anschauen.


Bei mir ging oberhalb von 38400 dann garnix mehr... jetzt habe ich es 
spaßeshalber auf 2 000 000 Baudrate gestellt... ja! 2MBaud... und es 
scheint zu laufen! mit dem Atmega238P :D... ich bin total fasziniert... 
mal schauen ob ich morgen mal vom RAW auf das RGB format umschalten 
kann... ist aber einiges an implementierungsaufwand im Terminal... aber 
vielleicht lohnt es sich ja. So scheine ich nicht auf einen grünen Zweig 
zu kommen.

@Igel aus Aachen? das ist ja lustig! ich komme ursprünglich aus Stolberg

[Andreas S. (igel1)]

Ich kapier die Welt nicht mehr:

Wenn ich die Werte noch RGB565-Manier einlese, und an das LCD-Display 
sende, so bekomme ich exakt Michaels Testbild.

Wenn ich dann das Testbild abschalte und meinen Balli fotographiere,
so hat er auf dem Bild eine knallgrüne Nase (statt einer roten Nase).

Ich gucke langsam schon fast so wie mein Ball ...

Grüße

Igel1

[Dieter F. (Gast)]

David D. schrieb:
> 2MBaud... und es
> scheint zu laufen! mit dem Atmega238P

Auf Sender-Seite ja - Python schafft den Empfang aber nicht richtig 
(max. 1 MBaud) - daher hatte ich auch "Verzerrungen" im Bild.

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Ich kapier die Welt nicht mehr:

Wie sprach das grüne Tentacle in Maniac Mansion? Ich bin ja soooo 
deprimiert... ;-)

Im Anhang mal ein Original Farbbalkenbild (Ausleihe aus der 
Burosch-Test-Beschreibung).
Von weiß nach schwarz:
Blau:  Ein-Aus-Ein-Aus-Ein-Aus-Ein-Aus.
Rot:   Ein-Ein-Aus-Aus-Ein-Ein-Aus-Aus
Grün:  Ein-Ein-Ein-Ein-Aus-Aus-Aus-Aus
Konnte man auch ganz früher schon gut mit einfacher Frequenzteilung 
eines Rechtecksignals erzeugen.

Andreas S. schrieb:
> Ich bin aktuell noch zu faul, mir Code für die Ausgabe in Richtung PC zu
> stricken. Mit so einem ARM-Prozessor braucht's da doch immer etwas mehr
> Überwindung als mit einem Arduino, wo alles schon parat liegt.

hmmm... Arduino ist an meinem Kram ein Name für das AVR328 Modul und die 
IDE.
Das ist plain C für einen AVR, die die Bytes nimmt und in den 
Hardware-UART tütet. Kann auf einem STM außer der anderen UART-Init ja 
kaum anders sein.
Auf PC-Seite lesen ich ja immernoch mit TeraTerm als binär-Log ein 
(dehalb ja die 30s Pause, weil ich da immer im Menü rumklicken muß) und 
lasse IrfanView als RAW anzeigen (dehalb nur die reinen Bilddaten, sonst 
müßte ich überflüssige Daten erst om Hex-Editor wieder abschneiden.

Die Display habe ich auch hier, allerdings müßte ich da ziemlich mit der 
Pinbelegung der IOs tricksen, ein AVR328 hat soviele nicht...

Da ich mit dem UART nur sende, könnte ich mal schnell einen Webserver 
auf einen ESP8266 werfen, die Daten vom AVR zum ESP schicken und mir das 
Bild im Browser anschauen. Wäre zwar von hinten durch die Brust ins 
Auge, macht aber eigentlich keinen Aufwand...

Eine Erklärung für Deine grüne Nase habe ich nicht, die Einstellungen 
für den Analogteil (AGC/AEC/Colormatrix usw.) sind bei mir orignal die 
Init aus der Applikation, die geben mit auch noch ein paar Rätsel auf. 
Die Nase kann ja nur da zwischen Bildensor und ADC-Ausgabe versaut 
werden, beim Farbbalken greifen die ja nicht, den erzeugt der DSP ja 
erst dahinter.

Gruß aus Berlin
Michael

[Michael U. (amiga)]

Hallo,

so, mal versucht, einen Blick Richtung Hof zu bekommen.
Leider reicht der FiFo ja nicht für 640x480, gedacht ist der ja nur für 
Interlace-Halbbilder bis 720x480, also 2x 720x240. Würde praktisch aber 
auch keinen Sinn machen, weil bei unserer Auslesegeschwindigkeit die 
geraden/ungeraden Zeilen aus zeitlich weit auseinanderliegenden Bildern 
kämen. Bei Bewegung im Bild also nur Schrott...
Bleibt also in der Geschichte bei 320x240.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hi Leute,

Michael hatte ja 7 Beiträge weiter oben Code mit Register-Settings 
eingestellt und dann geschrieben:
> so, mühsam ernährt sich das Eichhörnchen...

[...]

> Chaos damit Andres S. auch seine Freude hat. :-)

... und Andreas hatte seine Freude ...

Zum Glück ist ihm aufgefallen, dass er zuerst ov7670_default_regs und 
dann erst rgb565_ov7670 einladen musste, weil sich die Werte 
überschreiben.
Im Nachhinein eigentlich logisch, aber beim ersten Kopieren nicht sofort
klar.

Sodann nochmals ein paar Minuten wildes Probieren wg. Zeilenlänge 
(irgendwann war ich's dann leid und habe es wieder aus der Länge des 
HREF-Signals berechnet: 311 Pixel !!) und voila: im Anhang findet Ihr 
das Ergebnis: definitiv das bislang farblich beste Bilder.

Interessanterweise passt mit Michaels Register Settings nun auch das 
RGB565-Format sauber, so wie ich es erwartet hätte.

Einzig die Vertikalstreifen links stören noch etwas (siehe Bild)
Ihr scheint dieses Problem nicht zu haben?

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

na wird doch langsam. :-)

Andreas S. schrieb:
> Einzig die Vertikalstreifen links stören noch etwas (siehe Bild)
> Ihr scheint dieses Problem nicht zu haben?

doch, sieht man auch auf meinen Bildern. Im Moment ist die 
Windowsposition auf "automatisch" was das auch immer heißt. Ich werden 
das mal auf manuell setzen. Register 0x3A (TSLB) Bit [0] muß ich mir 
auch noch anschauen.
Ansonsten eben Register 0x17...0x1a [HSTART/HSTOP/VSTRT/VSTOP].
Dummy-Zeilen und Pixel kann man auch noch einfügen, wo und wozu? Noch 
keine Ahnung.
Der Sensor selbst hat ja 656x488 Pixel, da darf man wohl das Window erst 
auf den aktiven Bereich anpassen...

Den kompletten Code habe ich für mich sowieso jetzt erstmal 
zusammengestrichen, ist nach wie vor Bastelstelle. YUV werde ich noch 
testen, als s/w Bild spart es übertragene Bytes. Die Aufrufe werde ich 
morgan mal in #defins und #ifdef verpacken für RGB, YUV und auch für 
Color Bar on/off. Spielt sich besser mit rum.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> na wird doch langsam. :-)

Na ja - aber leider bei den Falschen ...

Eigentlich wollten wir doch David helfen und nun müssen wir es erst 
einmal selber auf Kette bekommen.

Ich hoffe, David wird nicht davon frustiert, dass es bei uns inzwischen 
halbwegs läuft und bei ihm noch nicht so ganz.

Aber immerhin haben wir ihm nun etwas Grundlagenforschung abgenommen.
Wenn man wenigstens eine funktionierende Register-Kombination kennt, 
tappt man nicht ganz so im Dunkeln - man weiß dann wenigstens, dass 
etwas Vernünftiges aus der Kamera herauskommt und kann sich auf die 
Fehlersuche im eigenen Code konzentrieren.

@David: bitte lade doch einmal Deinen aktuellen Code hier hoch - dann 
können wir etwas stöbern.  Deine Steuersignale sahen ja schon mal gut 
aus - kann eigentlich nur noch an der AL422B Ausleseroutine liegen.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Eigentlich wollten wir doch David helfen und nun müssen wir es erst
> einmal selber auf Kette bekommen.
habe ich auch immer wieder mal drüber nachgedacht, deshalb auch mein 
kurzer TEst im alten AVR-Studio, dans sollte auch im aktuellen gehen. 
Deshalb auch der Kampf mir dem Mega328. ;)

> Ich hoffe, David wird nicht davon frustiert, dass es bei uns inzwischen
> halbwegs läuft und bei ihm noch nicht so ganz.
er wollte ja im Ursprung jedes Fahrad selbst erfinden, an sich sehr 
löblich und sinnvoll. Allerdings bin ich immernoch der Meinung, daß so 
eine Kamera zusammen mit einem Mega328 kein sinnvoller Ansatz ist. 
OV2640/ESP32 liegt ja hier mehrfach rum und läuft auch prinzipiell, aber 
nicht nach meinen Vorstellungen, da werde ich weitermachen.
Sein Ansatz mit seinem PC-Programm ist meiner Meinung nach auch ziemlich 
komplex. Ich bin jetzt mehr denn je der Meinung, daß man mit einzelnem 
Register ändern dabei nur den Heldentod stirbt...
Ich hatte ja kurz überlegt, auch ein VB6-Programm für den schreiben, 
damit Übertragung und Bilddarstellung schell zu prüfen sind. Ich bin bei 
bewährtem TeraTerm und Irfanwiev) geblieben, weil ich wußte, daß beide 
das gewünschte zuverlässig leisten, nur die Bedienung ist eben 
fragwürdig, ich scahffe es aber inzwischen in unter 10s bis ich das Bild 
sehe. ;)
Irfanwiev kann als RAW so ziemlich alles laden, was man in Bytes packen 
kann. Das selber zu machen wäre zwar machbar, nur hätte ich dann ein 
tolles Programm, das ich ohne größere Umbauten wohl nie wieder 
brauche...

Bei meinen Gedanken, die Routinen von David in meinen Source zu packen 
und zu testen, habe ich dagegen fast keine Arbeit. Übertagen und 
Kam-Init habe ich da dann im Zweifel immer sicher, um den Bereich 
einzugrenzen, wo es bei ihm klemmt. Baudrate usw. ist dabei ja auch 
egal, ist ein Byte im UART-Init und eine Auswahl in TeraTerm. Den UNO 
flashen dauert keine 15s.

Ich hoffe also schon, daß David nicht verschreckt abspringt.

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Michael U. schrieb:
> YUV werde ich noch
> testen, als s/w Bild spart es übertragene Bytes.

YUV, RGBxxx sind alles errechnete Formate. Die originäre Auflösung (640 
x 480) bekommt ihr im RAW Bayer Format. Da werden die einzelnen 
Pixel-Helligkeiten als Byte übergeben. Das bekommt man auch in den Fifo. 
Das ist auch alles, was die Sensoren können. Leider liegt eine 
Linsen-Maske über dem Sensor-Array, was (durch Lichtbrechung? - das kann 
ich nicht deuten) die Helligkeiten wie ein Farbfilter beschränkt.

Die Umrechnunng macht der DSP in der Kamera oder man selbst, wenn man 
denn will.

VG
Dieter

[Michael U. (amiga)]

Hallo,

@ Dieter F.: alles zutreffend. Für mich ist die Kamera und der Sensor 
ein Produkt für damals preiswerte Überwachungs-Cams und Webcam gewesen, 
kein Meßgerät. Ziel, auch der Möglichkeiten des Kamera-DSP, sehe ich 
darin, ein subjektiv stimmiges Bild zu erzeugen, kein identisches Abbild 
der Wirklichkeit in diesem Bereich.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Dieter F. schrieb:
> Die originäre Auflösung (640
> x 480) bekommt ihr im RAW Bayer Format.

Heisst das: wenn cih RAW Bayer Format einstelle, wird der DSP komplett 
umgangen?

Viele Grüße

Igel1

[Dieter F. (Gast)]

Andreas S. schrieb:
> Heisst das: wenn cih RAW Bayer Format einstelle, wird der DSP komplett
> umgangen?

Jein - es findet halt keine Umrechnung in ein "Farbformat" statt. Ob 
White-Balancing etc. noch ausgeführt werden weiß ich nicht.

VG
Dieter

[David D. (saturi)]

Hallo zusammen,

>Eigentlich wollten wir doch David helfen und nun müssen wir es erst
>einmal selber auf Kette bekommen.
>
>Ich hoffe, David wird nicht davon frustiert, dass es bei uns inzwischen
>halbwegs läuft und bei ihm noch nicht so ganz.


doch solangsam wird er es :D ... aber nach einem Tief kommt auch immer 
wieder ein Hoch... Habe jetzt wieder 2 Std. damit verbracht einen 
urplötzlich auftretenden Fehler zu suchen mit dem plötzich garnichts 
mehr ging... sogar den Code von gestern Nacht habe ich wieder zurück 
genommen. Nichts.... Lösung: den billigen Logic Analyzer nicht 
unbestromt an den Pins hängen lassen, weil er sonst die einzelnen 
Potentiale so runter zieht, dass Sie zwar auf dem Oszi noch genauso zu 
erkennen sind wie vorher (wenn man nicht auf die Spannung schaut) aber 
vom Atmega nicht mehr erkannt wird. Sprich meine while schleife vom 
VSync bleibt einfach hängen...
 Als hätte ich keine anderen Probleme...


Die Ursprüngliche Idee des Terminals war ja dafür gedacht um bequem 
register ändern zu können, ohne jedes mal neu flashen zu müssen. Um den 
"Re-Use" des Programms möglichst groß zu halten habe ich mir 
vorgenommen, das uC-Programm so einfach wie möglich zu halten um es 
später ggf. auch für andere Controller möglichst anwendbar zu machen.

Ich danke euch für all die Informationen und Register Werte die ihr in 
der Woche zusammen getragen habt... Diesmal nehme ich mir vor sie jetzt 
erstmal alle zu sammeln und für mich zu Bewerten damit ich nicht wieder 
die Lösung vor den Augen habe und sie übergehe...

Zum Imager:
jeder Pixel liefert nur einen Helligkeitswert (Ich denke so war es 
damals im Schwarzweiß Fernsehen-war aber vor meiner Zeit).
Um Farbe in das ganze zu bringen gibt es das Bayer-Pattern, Hier werden 
über die verschiedenen Pixel farbfilter gelegt in meistens folgendem 
Muster: RGGB
RGRGRGRGRG
GBGBGBGBGB
RGRGRGRGRG
GBGBGBGBGB

Jeder Buchstabe steht für einen Pixel und den jeweiligen Farbfilter: R= 
Rot G= Grün B= Blau. Grün kommt in einem Quadrat aus vier Pixeln immer 
zwei mal vor. Das ist vom menschlichen Auge abgeschaut, dass auf Grün 
wesentlich empfindlicher reagiert.

Im RAW format schiebt der DSP also einfach die Helligkeitswerte auf den 
Ausgang ohne die Farbfilter zu beachten, sprich es kommt ein Schwarzweiß 
bild raus (wobei die Helligkeit der einzelnen Pixel schon von den 
Farbfiltern abhängt)
 Beim processed BAYER RAW wird über nen Algo für jeden Pixel durch die 
umliegenden Pixel eine Farbinformation RGB berechnet, sodass ich für 
jeden Pixel 3 Byte bekomme (RGB) mit letzterm Format habe ich es bisher 
versucht, weil es für mich am einfachsten zu händeln war (aber 
vergeblich) ich werde heute einmal schauen auf euer RGB565 zu kommen.
So zumindest ist mein Verständnis, sollte ich hier was falsch verstanden 
haben?

kurz zu den Auflösungen:
VGA: 640*480
QCIF: 176*144
QVGA: 320*240
CIF: 352*288
Das sind die mit denen ich hier ins Rennen gehe.

Wo kommen bei euch die Uminösen 311 Pixel bei HREF her?
Anbei ein aktuelles Bild von mir -.-

Schaue mir dann jetzt mal eure Register werte an...
Aber ein Bild sollte ich doch, wenn auch in schlechter Qualität ohne 
einstellungen bekommen? (also 0x12 und 0x42 Colorbar jeweils an)


Sowohl den Code vom AtmelStudio als auch den Sourcecode vom aktuellen 
terminal stelle ich euch nachher noch rein.

[Andreas S. (igel1)]

Hallo David,

mein Tipp: fange erst einmal mit einer OV7670-Register-Kombination an, 
die 100% funktioniert und die Dir ein Colorbar-Testbild rauswirft.

Dies ist solch eine Kombination:

static unsigned char OV7670_QVGA[][2]=
{
   0x12, 0x80,  

   0x11, 0x00  ,  // CLKRC - Teiler XCLK In -> intern 1:1 -> also 12MHz bei meinem Modul
   0x12, 0x16 ,  // COM7  - Selects QVGA [4] und RGB [2][0]  [1] color bar, on 0x16 off 0x14
   0x40, 0x14 ,  // COM15 - Selects RGB 565 [5:4] und Full Range [7:6]
   0x3a, 0x05 ,  // TSLB  - Window auto, YUYV [00] Ausgabe - TSLB [3], COM13[0]
   0x42, 0x08 ,  // COM17 - AEC Window [7:6] Bit 1 und 0 wie COM4 [5:4], DSP Color Bar on/off[3], on 0x08 off 0x00

   0x15, 0x00 ,  // COM10 - PCLK auch bei HREF
};

Das Ergebnis ist ein Testbild mit 313 Pixel/Zeile und 240 Zeilen. Jedes 
Pixel besteht aus 2 Bytes, die nach RGB565 kodiert sind, also:
[RRRRRGGG][GGGBBBBB].
Dabei wird das hier links dargestellte Byte als erstes Übertragen.

Wenn das funktioniert, so ändere die Werte von Register 0x12 auf 0x14 
und Register 0x42 auf 0x00 und Du bekommst Dein erstes "echtes" Bild - 
ziemlich schwache Farben, aber immerhin - ein Bild.

Danach kannst Du weiterforschen.
Das wäre meine Rat an Dich bzgl. Vorgehensweise.

Viele Grüße

Igel1

[David D. (saturi)]

Hallo Igel,

vielen Dank. Damit habe ich schonmal einen Fehler "enttarnt" was COM 15 
angeht. 16 ist eben nicht 0x16...
trotzdem schreibt ihr mit
0x14 doch in einem reserved Register rum oder nicht? Müsste es also 
nicht heißen
0x14: 0xD0 ?


Leider bringt mich das umstellen der xResolution auf 313 auch nicht 
weiter. Ich scheine immernoch ein Problem mit dem FIFO zu haben.


anbei ein Bild das aktuell rauskommt (QVGA (313px/Zeile)) RGB565


Immerhin habe ich diese "Zeilenstruktur" jetzt bei jedem Bild, allerding 
ändert sich die "Verzerrung" von der vermeitlichen ColorBar mal nach 
rechts und mal nach links...

[Andreas S. (igel1)]

Bitte stell mal Deinen Code hier ein.

[David D. (saturi)]

@Dieter kannst du mir vielleicht sagen, wie du in den Pausen sendest?

Dieter F. schrieb:
>
> QQVGA hat den Vorteil, dass nur jeder 4. HREF-Slot (im Vergleich zu VGA)
> Daten enthält/übermittelt. Die "Totzeit" nutze ich für die serielle
> Übertragung.
>
> VG
> Dieter


Ich denke eines meiner "Probleme ist wahrscheinlich, dass ich zwischen 
den einzelnen Zeilen pausiere um Rückmeldung vom Terminal zu geben, dass 
die Zeile angekommen ist. damit unterbreche ich RCK für 10,3ms... 
vielleicht rührt es daher und ich sollte mein Konzept nochmal überdenken 
und vlt. doch den ganzen Frame übertragen...

[David D. (saturi)]

Unter folgendem Link sind zu finden:

https://github.com/igittigitt/ov7670/tree/TWI-Interfac

- Das Terminal Programm als release (zum Direkt ausführen: 
OV7670-Terminal_V0.3.zip)

- Das Terminal als Solution zur Sourcecode einsicht in VS

-Das Atmel Studio projekt mit allen C-Datein für den Arduino.



Bitte HELFT mir :D ....

@Igel kannst du vielleicht nochmal deine aktuelle Write und Read sequenz 
einstellen? Ich würde die gerne abgleichen.

[Dieter F. (Gast)]

David D. schrieb:
> @Dieter kannst du mir vielleicht sagen, wie du in den Pausen sendest?

Hallo David,

da ich keinen Fifo nutze bringt Dir das wahrscheinlich nichts. Ich 
antworte aber gerne.

Das Auslesen basiert auf den VGA-HREF-Frames. Schau Dir dazu bitte das 
Datenblatt (Version 1.01) Seite 8 an. Also grundsätzlich 640 HREF-Frames 
pro Zeile (HREF-Intervall).

Ich nutze aktuell das QQVGA-Format (160 x 120). In Figure 8 siehst Du, 
dass in in 4 VGA-HREF-Frames nur 1 QQVGA-HREF-Frame prozessiert wird - 
QVGA entsprechend 2, CIF und QCIF - orientiert an VGA und QVGA - 
entsprechend weniger.

Der HREF-Takt orientiert sich also immer an VGA mit 640 Pixel pro Zeile 
- was nicht (vom Pixel-Takt) gebraucht wird, wird ausgeblendet.

Bei dem von mir genutzten QQVGA habe ich 3 HREF-Takte Zeit, die im 
ersten HREF-Takt gelesenen Daten seriell an den PC (oder per SPI an ein 
Display) zu übertragen.

Das ist nicht viel. Ich kann (das hast Du auch probiert) mit 2 MBaud vom 
ATMega328P (Arduino Nano-Basis) senden - (relativ) sicher empfangen kann 
ich mit Python aber nur ca. 1 MBaud. Bei 8 Daten-, 1 Start- und ein 
Stop-Bit sind das bei RGB (2 Bytes) ca. 20 µS pro Pixel (+ die 
UART-Verarbeitung für 320 Byte pro Zeile). Damit komme ich aktuell bei 1 
MBaud auf ca. 0,6 Sekunden pro Bild (QQVGA).

Erreichen kann ich das nur, wenn ich die Pixel-Clock (bei 16 MHz Takt am 
Eingang) entsprechend verlangsame (Register 0x11 etc.).

Genau da fangen die Probleme an. Viele der Einstellungen für andere 
Register sind direkt oder indirekt von der Pixel-Clock abhängig - welche 
das sind ist nicht auf den ersten Blick ersichtlich. Genau da hört der 
Spaß für mich auf.

Mit dem Fifo kannst Du mit der "vollen" Pixel-Clock die Pixel in den 
Fifo übertragen (hast also eine Art Referenz) und von dort "gemütlich" 
auslesen, da diese ja bis zum vollständigen Auslesen gehalten werden.

Wenn ich keine Umrechnungen (RAW Bayer ...) machen wollte und eine 
Kamera mit Fifo hätte würde ich auch QVGA (im Kamera-DSP umgerechnet) 
nutzen, um das Bild auf einem Display oder am PC darzustellen. Die 
passenden Register-Einstellungen sind schon x-Mal veröffentlicht worden 
- wenn Du ein Bild haben willst - einfach kopieren. Der 
"Implementation-" oder "Programming-" Guide sind nur rudimentär und (aus 
meiner Sicht) nicht vollständig.

Genug "gelabert" - schönes Wochenende
Dieter

[Dieter F. (Gast)]

David D. schrieb:
> Ich denke eines meiner "Probleme ist wahrscheinlich, dass ich zwischen
> den einzelnen Zeilen pausiere um Rückmeldung vom Terminal zu geben, dass
> die Zeile angekommen ist. damit unterbreche ich RCK für 10,3ms...
> vielleicht rührt es daher und ich sollte mein Konzept nochmal überdenken
> und vlt. doch den ganzen Frame übertragen...

Du hast "alle Zeit der Welt" den Fifo auszulesen (nach meinem 
Verständnis).

Nur musst Du die Kamera so konfigurieren, dass diese den Fifo 
zuverlässig füllt (und das VSYNC-Signal auswerten, damit Du nicht 
voreilig ausliest).

[David D. (saturi)]

So hatte ich mir das auch vorgestellt... Aber laut Datenblatt des Fifos 
muss man RCK ebenfalls mit 1MHZ betreiben. Und da ich keinen Zugriff auf 
das ReadEnable habe, macht das die ganze Sache kompliziert.

Habe jetzt mal ein neues Feautre zum Terminal hinzugefügt, dass den 
ganzen Frame auf einmal empfängt und siehe da: zumindest die "toten" 
Bereiche sind verschwunden.


Das Bild hat 313x240 Pixel.

Ist es ein Problem mit der AUflösung oder mit dem Speicher auslesen?


EDIT: RCK habe ich jetzt auf 48kHZ und somit immernoch weit unter der 
Spec... Aber ich weiß nicht wo ich das noch rauskitzeln soll

[Dieter F. (Gast)]

David D. schrieb:
> Das Bild hat 313x240 Pixel.
>
> Ist es ein Problem mit der AUflösung oder mit dem Speicher auslesen?

Zeig doch bitte Dein aktuelles Programm. Die PC-Seite "ist geheim" - 
aber dann können wir (Michael und Andreas - ich nur theoretisch) 
zumindest an der AVR-Seite mal schauen ...

[David D. (saturi)]

Siehe den Post von kurz nach 17 Uhr, im Link findest  du sowohl das 
"geheime" ;-) Programm (auch den Sourcecode und ebenfalls den Sourcecode 
vom uC. Hast du Probleme mom Link? Dann Versuch ich's nochmal

[Andreas S. (igel1)]

Hi Leutis,

habe dummerweise aktuell nicht viel Zeit, daher hier nur ganz kurz:

- Habe meinen Pseudocode von weiter oben mehr oder weniger 1:1 auch
  in Code umgesetzt (der Dich aktuell aber mehr verwirren als beflügeln
  würde - ich muss ihn erst aufräumen, bevor ich ihn hier einstellen
  kann).

- Den AL422B lese ich mit 10kHz aus (also weit unter der Spec).
  Der PCLK-Takt aus der Kamera läuft die ganze Zeit durch - ich hoffe
  mal, der reicht für das DRAM-Refresh.

- Ich sammle jeweils 2 Bytes aus dem FiFo und sende die als
  RGB565-Doppelbyte zu meinem LCD-Display (die entsprechende
  Funktion des LCD's spricht nämlich ebenfalls RGB565.)
  Ich warte also explizit nicht auf das Zeilenende, bevor ich die
  Daten in Richtung LCD versende.

Mehr "Magic" ist nicht dabei.

Viele Grüße

Andreas

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> EDIT: RCK habe ich jetzt auf 48kHZ und somit immernoch weit unter der
> Spec... Aber ich weiß nicht wo ich das noch rauskitzeln soll

ich habe mal testweise 50ms delay nach jeder Zeile bei mir eingefügt, 
stört in keiner Weise, Bild wird sauber aus dem FiFo gelesen.

Ich habe mal versucht, durch Dein Programm durchzuschauen, aber bis 
jetzt nur kurz.
Verwirrung: warum finde ich Registerdefinitonen wie

  #define OV_SCCB_COM14    0x3E

in der SCCB_old.h, bei mir würden die zur OV7670_with_Fifo.h gehören.
SCCB wäre bei mir init(), readByte(adr,wert) und writeByte(adr,Wert).
Wenn ich z.B. die OV7670_with_Fifo.h durch eine OV2740.h ersetzen 
wollte, will ich nicht in zig Dateien nach zu Ändernden Registernamen 
suchen müssen.
SCCB bliebe ja SCCB.
Mir ist auch etwas unklar, warum man die Datenpins der Kamera auf 2x 
4Bit von 2 Ports durchuas sinnvoll aufteilet und das dann mit 
Funktionen, die Funktionen aufrufen, einzeln zusammenbastelt.

Das ginge in einer Zeile mit

      UDR0 = (PIN_LOW & MASK_LOW) | (PIN_HIGH & MASK_HIGH);          // Byte (Y) einlesen und rausschicken

Dazu denn eben

#define PIN_HREF  PB0     // (D8)  IN   H-aktiv OV7670 Zeilenstart mit H-Impuls
#define PIN_VSYNC PD3     // (D3)  IN   H-aktiv OV7670 Bildstart mit H-Impuls
#define PIN_WRST  PD2     // (D2)  OUT  L-aktiv AL422B Write-Counterreset mit L-Impuls

#define PIN_STR   PB1     // (D9)  IN   H-aktiv OV7670 Blitzlichtsteuerung
#define PIN_RCK   PB2     // (D10) OUT  H-aktiv AL422B default L
#define PIN_RRST  PB3     // (D11) OUT  L-aktiv AL422B Read-Counterreset mit L-Impuls
#define PIN_WR    PB4     // (D12) OUT  H-aktiv AL422B verknüpft mit HREF OV7670 zu /WR AL422B
#define PIN_OE    PB5     // (D13) OUT  L-aktiv AL422B Output tristate/aktiv, kann hier wohl auf L bleiben

#define PIN_LOW   PINC
#define MASK_LOW  0x0F    // (A0...A3) PC0...PC3 IN

#define PIN_HIGH  PIND
#define MASK_HIGH 0xF0    // (D4...D7) PD4...PD7 IN

Das komplette Init der Kamera-IO dann

  DDRB &= ~((1 << PIN_HREF) | (1 << PIN_STR));                                               // IN

  PORTB &= ~((1 << PIN_WR) | (1 << PIN_OE) | (1 << PIN_RCK));                                // Low  
  PORTB |= (1 << PIN_RRST);                                                                  // HIGH
  DDRB |= (1 << PIN_RCK) | (1 << PIN_RRST) | (1 << PIN_WR) | (1 << PIN_OE);                  // OUT 
  
  DDRD &= ~(1 << PIN_VSYNC);                                                                  // IN
  PORTD |= (1 << PIN_WRST);                                                                   // HIGH
  DDRD |= (1 << PIN_WRST);                                                                    // OUT
  
  DDRC &= ~MASK_LOW;                                                                          // D0-D3 camera  IN
  DDRD &= ~MASK_HIGH;                                                                         // D7-D4 camera  IN

Ich weiß, daß das Herangehen da ewige Diskussionen auslösen kann, es 
stellt also nur meine Vorstellung und Meinung dar.

Wenn die Pin-Zuordnungen (für mich) schnell auffindbar gewesen wären, 
hätte ich den Kram vermutlich noch schnell an mein PinOut des AVR 
angepasst und mal geflasht. So werde ich mich erstmal durchkramen müssen 
um mehr zu verstehen.

So, genug gemault... ;-)

@Andres S. schrieb:
>  Ich warte also explizit nicht auf das Zeilenende, bevor ich die
>  Daten in Richtung LCD versende.
Ich warte auch auf nichts, die Geschwindigkeit wird nur von der 
UART-Rate bestimmt, sind hier RCLK im Moment 22,4kHz, eben 230400 Baud, 
passt ja auch ganz gut. Mit 115200 ist es aber genauso stabil, dann eben 
bei gut 11kHz RCLK.

Gruß aus Berlin
Michael

[David D. (saturi)]

Danke, dass du dir das antust. Da ist Maulen dann auch erlaubt :D
Den case 0 brauchst du dir erst gar nicht anschauen. Der wird eh nie 
aufgerufen :D.... ansonsten sind in der main() die möglichen Befehle in 
dem Switch case Statement. Die Befehle selbst sind in der ov7670 With 
Fifo. Die sccb_old verwirrt zwar wegen dem Namen, aber ist die richtige 
und funktioniert auch recht zuverlässig. Bin grade leider nur mobil 
drin, kannst könnte ich dir schon mehr Infos geben

[Dieter F. (Gast)]

David D. schrieb:
> Siehe den Post von kurz nach 17 Uhr, im Link findest  du

Ja - bin ein Blindfisch :-(

Was mir auffällt:

volatile int height = 480;
volatile int width  = 640;
volatile int BytesPerPixel = 3;

Passt das zu dem, was Du einlesen willst? Würde bedeuten, dass Du RAW 
Bayer (height / width) einlesen möchtest. Da kommt aber nur 1 Byte pro 
Pixel und nicht 3 (ob die Register-Werte dazu passen habe ich nicht 
geprüft).

3 Byte pro Pixel kann die Kamera gar nicht - die passen auch nicht in 
den Fifo bei der gewählten Auflösung, so weit mir bekannt. Damit wird 
nichts vernünftiges herauskommen.

Das

   //Reset the Write Pointer, (not sure, if that will work)
   OV7670_ResetFifoWritePointer();

gehört nicht ans Ende von "OV7670_captureNewImage" - keine Ahnung, ob es 
stört.

VG
Dieter

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Danke, dass du dir das antust. Da ist Maulen dann auch erlaubt :D

ok, wenn Du es so siehst machen wir mal weiter. :-)
Den Kram zuzuodnen ist nicht so das Problem, ich hatte erst gestern Aben 
nur schnell das PinOut der Cam prüfen wollen und an meins anpassen. Die 
steckt ja jetzt so schon auf dem Adapterboard, von dem Andreas so 
"begeistert" war. ;)

SCCB passt, da bist Du ja auch an den I2C-Pins.
D7...D4 passen,
D3...D0 hast Du an PortB, ich an PortA, muß ich anpassen.
VSYNC Du auf C4, ich auf D3,
HREF Du auf C0, ich auf B0,
RST Du auf B5, habe ich fest auf H, muß ich auf einen unbenutzten Pin 
mappen.
PDWN haben wir beide nicht beschaltet, ok.
STR Du nicht beschaltet, ich dummerweise ja, hatte erst später geschaur, 
wofür der ist, muß ich also in Deinem Source noch auf L schalten, kein 
Problem.
RCK Du auf D2, ich auf B2,
WR Du auf B4, ich auf B4,
OE Du nicht beschaltet, ich auf B5, also auch noch auf L setzen
WRST Du auf C3, ich auf D2,
RRST Du auf C2, ich auf B3.

Werde ich nachher in Deinem Source mal anpassen, der LA hängt sowieso 
noch dran, sehe ich ja zur Not, wenn ich wo falsch bin.

Compiler lief ja schon durch, ein paar Warnungen, denen ich aber nur 
nachgehe, wenn es da klemmt bzw. der Rest passt:
SCCB_Old.c:330:40: warning: passing argument 2 of 'OV7670_read' discards 
'volatile' qualifier from pointer target type [-Wdiscarded-qualifiers]
 if(ErrorCode=OV7670_read(OV_SCCB_COM14,&temp))

SCCB_Old.c:161:7: note: expected 'char *' but argument is of type 
'volatile char *'
  char OV7670_read (char regID, char* regData)

SCCB_Old.c:339:39: warning: passing argument 2 of 'OV7670_read' discards 
'volatile' qualifier from pointer target type [-Wdiscarded-qualifiers]
 if(ErrorCode=OV7670_read(OV_SCCB_COM7,&temp))

Ich werde nachher mal anpassen und mich überraschen lassen. ;-)

Gruß aus Berlin
Michael

[David D. (saturi)]

Dieter F. schrieb:
>

> volatile int height = 480;
> volatile int width  = 640;
> volatile int BytesPerPixel = 3;
>

Die werden vom Terminal mit einem Klick auf  get Camera Status auf die 
aktuellen Einstellungen angepasst.
> Passt das zu dem, was Du einlesen willst? Würde bedeuten, dass Du RAW
> Bayer (height / width) einlesen möchtest. Da kommt aber nur 1 Byte pro
> Pixel und nicht 3 (ob die Register-Werte dazu passen habe ich nicht
> geprüft).
Im Processed BayerRaw kommt nur eins an? Da hätte ich drei gedacht.

> 3 Byte pro Pixel kann die Kamera gar nicht - die passen auch nicht in
> den Fifo bei der gewählten Auflösung, so weit mir bekannt. Damit wird
> nichts vernünftiges herauskommen.
Im QCiF auch nicht?

> Das
>
>

>    //Reset the Write Pointer, (not sure, if that will work)
>    OV7670_ResetFifoWritePointer();
>

>
> gehört nicht ans Ende von "OV7670_captureNewImage" - keine Ahnung, ob es
> stört.
Richtig, ich hatte nur irgendwo gelesen, dass der write pointer immer x 
Positionen vor dem read Pointer sein muss und dass ein reset das umgehen 
würde... Kann mich aber auch irren. Werde ich nochmal prüfen

[Dieter F. (Gast)]

David D. schrieb:
> Im QCiF auch nicht?

Nein:

Application Note Punkt 2 - Tabelle (achte auf die "or")

Dann 2.1 erster Absatz:

RAW Bayer nur bei VGA, Processed Bayer für VGA und QVGA. Alle anderen 
Ausgabe-Formate gelten für VGA und alle Auflösungen kleiner CIF. Kein 
Ausgabe-Format hat 3 Byte für die Farb-Information.

Hier ist es schön dargestellt:

http://joe-c.de/pages/optik/kamerasensor.php

[Andreas S. (igel1)]

Hallo David,

David D. schrieb am 09.02.2019 17:19:
> @Igel kannst du vielleicht nochmal deine aktuelle Write und
> Read sequenz einstellen? Ich würde die gerne abgleichen.

Ich habe den wichtigen Part aus meinen Code, nämlich das Auslesen des
OV7670->FiFo und das Auslesen FiFo->LCD-Display, hier angehängt.

Das ganze habe ich mit vielen Kommentaren gespickt.
Der für Dich relevante Teil startet ab:
"// The interesting part starts here"

Als Register-Settings benutze ich die Colorbar-Einstellungen aus meinem
letzten Posting hier:
Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)"

Eine Zeile hat - wie oben geschrieben - 313 Pixel.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

so, ich habe mal alles für David passend gemacht, meinen 
High-End-Adapter etwas umgebaut:
RST zum AVR verdrahtet, ein Pegelwandler war ja noch frei
OE direkt auf GND
STB offen, ist ja sowieso nur ein OUT der Cam, der jetzt nicht gebraucht 
wird.

Compiliert, geflasht, soweit ok. Terminalprogramm geht auch, Baudrate 
bin ich auf meine 230400 gegangen.
Init geht, Status holen geht, Register lesen geht.
Register schreiben ändert den Registerwert nicht, da muß ich noch 
nachschauen, Blid holen bleibt so natürlich auch hängen.
Ich habe mal die Startsequenzen imLA verglichen, bei mir startet ja 
Einlesen automatisch, ist das kurze L bei WRST nach der Mitte.
Ab da wird auch gelesen, der H-Impuls bei WR,
und übertragen, die H-Impulse bei RCK.

Ich habe die Auflösung extra so gelassen, weil ich den kompletten Ablauf 
nach Reset sehen wollte.

PS: bediene ich Dein Terminal falsch oder stellt Du wirklich im Read 
Settings die Werte als HEX und im Write Settings als DEZ dar?
Falls ja: geht's noch? Soll ich mir zum Vergleichen da einen 
Taschenrechner daneben legen?
Falls mein Fehler bitte ein Hinweis.

ok, Register schreiben scheint jetzt zu gehen.

Hast Du die volatile im Lotto gewonnen?
//Initial Variables
volatile int Programstatus = -1;
volatile int height = 480;
volatile int width = 640;
volatile int BytesPerPixel = 3;
volatile char Byte=0;

warning: invalid conversion from 'volatile int*' to 'int*' 
[-fpermissive]
      UART0_rx_work(&Programstatus);

ich habe die volatile da erstmal alle rausgeworfen, ich habe auf Anhieb 
keinen Sinn dafür gefunden?

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

@David:

Oh ha - jetzt gibt's kein Entrinnen mehr: Michael hat Deinen Code in der 
Mangel ...


@Michael:

Nachdem Dieter bei David das Missverständnis "Ein Pixel hat 3 Byte" 
aufgeklärt hat, sollte David jetzt eigentlich das Ziel aus eigener
Kraft erreichen können.

Auch wenn es Dir in den Fingern juckt - ich würde David die Chance
geben, sein Programm selbst ans Laufen zu bringen.

Viele Grüße

Igel1

[David D. (saturi)]

Hallo zusammen,

@Dieter
>Kein Ausgabe-Format hat 3 Byte für die Farb-Information.
Siehe Tabelle 2-1 im application guide: Processed Bayer RGB sehe ich da 
schon als 3Byte pro Pixel nämlich jeweils eins für R eins für G und eins 
für B. Vielleicht vertue ich mich aber auch und es ist stattdessen nur 1 
pro pixel und ich bekomme trotzdem wieder nur die jeweilige 
Farbinformation wie beim normalen RAW Bayer. Die Auflösung zum 
"Processed Bayer RGB" hat dein Link ja leider nicht entschlüsseln 
können.

@Igel
>Ich habe den wichtigen Part aus meinen Code, nämlich das Auslesen des
>OV7670->FiFo und das Auslesen FiFo->LCD-Display, hier angehängt.
Danke! werde ich mir nachher direkt anschauen

@Michael
>PS: bediene ich Dein Terminal falsch oder stellt Du wirklich im Read
>Settings die Werte als HEX und im Write Settings als DEZ dar?
nein alles HEX, nur das 0x fehlt noch beim Read.(das mit dem Write habe 
ich gestern erst implementiert und das mit eingebaut).
mehrere Register können übrigens geschrieben werden indem eine Textdatei 
geladen wird. Format in der Textdatei: Pro Zeile ein Register:
Adresse;Value;ggf Kommentar
Beispiel:

0x12;0x0D
0x13;0xC1;Hier könnte jetzt ein Kommentar stehen
...

dann steht es in der rechten Box. dann auf write Device Settings gehen 
und hoffen, dass alle Register ohne Fehler geschrieben wird. (mit Read 
All Register kann gesehen werden, was die einzelnen Register im 
uController enthalten.(Auch hier hoffen, dass alles durchläuft. Den 
Fehler warum es manchmal-scheinbar zufällig- abbricht habe ich leider 
noch nicht gefunden.)

mit get Camera status dann die Auflösung (die ganzen volatile values) 
anpassen. Volatile deshalb, weil ich mir gedacht habe, dass der compiler 
sie evtl. wegoptimiert, weil sie ja evtl. aus seiner Sicht nicht 
gebraucht werden.

@Igel
>Nachdem Dieter bei David das Missverständnis "Ein Pixel hat 3 Byte"
>aufgeklärt hat, sollte David jetzt eigentlich das Ziel aus eigener
>Kraft erreichen können.
Leider nein... Weil sich dieses "Missverständnis" auf das RAW Format 
bezieht wir aber ja im QVGA und RGB565 unterwegs sind. Und ich da die 
gleichen "Probleme" habe.

>Auch wenn es Dir in den Fingern juckt - ich würde David die Chance
>geben, sein Programm selbst ans Laufen zu bringen.
Ich möchte kein fertiges Programm vor die Füße gesetzt bekommen, sondern 
wissen was ich falsch mache. Daher möchte ich Michael nur ermutigen 
weiterhin meinen Code unter die Mangel zu nehmen und berechtigte Kritik 
zu äußern oder das Vorgehen zu hinterfragen. Nur so weiß ich, was ich 
ggf. auch falsch mache in meinem "Programmierstil" :D...

Aktuell komme ich ohne fremde Hilfe leider nicht weiter, weil ich nicht 
weiß wo ich ansetzen soll. Also Michael: Zerfetz meinen Code :D. Zum 
Terminal kann ich gerne auch noch weitere Fragen beantworten oder 
Vorschläge in die Bedienung mit einfließen lassen.
Ich gebe zu es ist nicht ganz Intuitiv... sondern ebenfalls Historisch 
gewachsen.

ABER ein beliebiges Farbbild zu übertragen (auch im RGB565) 
funktioniert. Es liegt also mehr auf uController Seite und nicht am 
Terminal.

Ich danke euch für euren hoffentlich weiterhin konstruktiven (oder von 
Michael destruktiven :D) input.

Danke

Gruß David

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Auch wenn es Dir in den Fingern juckt - ich würde David die Chance
> geben, sein Programm selbst ans Laufen zu bringen.

das Jucken beschränkt sich so ziemlich nur darauf, seinen Code hier zum 
Laufen zu bekommen.
Zur Kamera selbst habe ich eigentlich garnichts vor, schon deshalb 
nicht, weil ich sie nicht nutzen will. Sie war halt nur da und der 
Mega328 auch und den, das behaupte ich einfach mal, ganz gut kenne.

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

David D. schrieb:
> Processed Bayer RGB sehe ich da
> schon als 3Byte pro Pixel nämlich jeweils eins für R eins für G und eins
> für B. Vielleicht vertue ich mich aber auch und es ist stattdessen nur 1
> pro pixel

Ja, Du vertust Dich - hast Du Dir mal den Link angeschaut? Processed 
Bayer wird sich lediglich auf die Optionen (Schärfe, etc.) auswirken. 
Muss man halt prüfen. Aber auch da gibt es nur ein Byte 
Farbinformationen pro Pixel (Verteilung höchstwahrscheinlich analog RAW 
Bayer, nur "nachgeschärft etc.) - aus meiner Sicht SICHER.

Die Kamera gibt NIEMALS 3 Byte pro Pixel aus. Nochmal - beachte die 
"or"-Angabe.

[David D. (saturi)]

Dieter F. schrieb:

> Ja, Du vertust Dich - hast Du Dir mal den Link angeschaut? Processed
> Bayer wird sich lediglich auf die Optionen (Schärfe, etc.) auswirken.
Habe ich, aber da finde ich jetzt nichts, was auf das Schärfen eingeht.

> Die Kamera gibt NIEMALS 3 Byte pro Pixel aus. Nochmal - beachte die
> "or"-Angabe.
Ja ok, überzeugt ;-) hatte das "or" falsch interpretiert. Aber stimme 
jetzt mit dir überein. ein "or" steht dann also für das nächste Pixel 
steht dann auch im Einklang mit den übrigen Farbformaten. Thumb Up


@Michael
>das Jucken beschränkt sich so ziemlich nur darauf, seinen Code hier zum
>Laufen zu bekommen.

Das wäre klasse... Es ist meiner erstes "wirkliches" Projekt mit dem 
Ding...

[Dieter F. (Gast)]

David D. schrieb:
> Habe ich, aber da finde ich jetzt nichts, was auf das Schärfen eingeht.

AEC, AGC, ABLC, white balance control, gamma control, SHARPNESS CONTROL 
(5.4) - keine Ahnung, was auch immer da berücksichtigt wird.

Deswegen weigere ich mich ja, irgendwelche Einstellungen blind 
abzutippen.

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> @Michael
>>PS: bediene ich Dein Terminal falsch oder stellt Du wirklich im Read
>>Settings die Werte als HEX und im Write Settings als DEZ dar?
> nein alles HEX, nur das 0x fehlt noch beim Read.(das mit dem Write habe
> ich gestern erst implementiert und das mit eingebaut).

ich habe hier Deine v0.3 von github am Laufen und da sieht die 
geschriebene u.ä. Datei so aus:
112;58
113;53
und das ist kein HEX. Falls das überholt ist, leg mal die aktuelle hin.

David D. schrieb:
> Ich danke euch für euren hoffentlich weiterhin konstruktiven (oder von
> Michael destruktiven :D) input.

ich habe mir jetzt mal meinen freien Pin als Debug-Output gesetzt.
Dein _delay_ms(5); in der while81) auskommentiert, am Anfang von while 
das Pin auf H und am Ende auf L geetzt.
Weiß jetzt auch nicht, warum er da warten sollte.
Die zykluszeit der while81) ist 2,55µs, ok, Dein switch() wird also 
sauber durchlaufen.
Dein Fifo-Konstrukt muß ich mir erst ansehen, mir gefallen 
Funktionsaufrufe in einer ISR ohnehin nicht sonderlich.
Speziell weil Du da UART0_rx_in(UDR0); für das Fifo-Handling aufrufst, 
Deinen Rückgabewert von int UART0_rx_in (char input) aber völlig 
ignorierst.
Wer behandelt dann wie return 0; bei Fifo voll?

Ich vermute mal, da bleibt er auch irgendwo hängen.

PS: ich stochere ja öfter in fremden Code rum, schon um Anleihen zu 
tätigen. ;-)
Alles, was Du da Richtung IO hast, ist ja AVR-spezifisch, für mich gibt 
es da keinen Grund, Portzugriffe usw. um 3 Ecken zu machen.
Wenn es einen HAL gäbe wie z.B. auch in der AdrduinoIDE, wo eben ein 
pinMode(6,OUTPUT); den von den Erstellern als Pin 6 bezeichneten Pin auf 
OUT setzt, egal, ob AVR, SAM, STM, ESP usw., dann macht das wieder Sinn, 
dann kann ich komplett ignorieren, wie das erreicht wird, ob da ein 
DDR-Register beim AVR, ein halbes Dutzend bei anderen µC oder noch eine 
IO-Matrix bedient werden muß.
Hat eben den Preis, daß ein pinMode(6,OUTPUT); wesentlich länger braucht 
als ein DDRB |= (1 << PB6);

Gruß aus Berlin
Michael

Gruß aus Berlin
Michael

[David D. (saturi)]

Michael U. schrieb:
> ich habe hier Deine v0.3 von github am Laufen und da sieht die
> geschriebene u.ä. Datei so aus:
> 112;58
> 113;53
> und das ist kein HEX. Falls das überholt ist, leg mal die aktuelle hin.
richtig... in die Datei wurden Dezimal zahlen geschrieben... war ein 
Fehler, anbei die 0.4 Version in der der Fehler behoben wurde (und auch 
noch andere Sachen verbessert und Altlasten entfernt:
https://github.com/igittigitt/ov7670/tree/TWI-Interfac/OV7670-Terminal-Releases


> Speziell weil Du da UART0_rx_in(UDR0); für das Fifo-Handling aufrufst,
> Deinen Rückgabewert von int UART0_rx_in (char input) aber völlig
> ignorierst.
> Wer behandelt dann wie return 0; bei Fifo voll?
niemand... dann läuft es einfach ins Leere... ich weiß aber leider nicht 
wie ich es besser machen soll :/

Ich gebe zu, dass es, wenn die Datenpins auf einem Address Byte liegen 
es sicher einfach wäre die auszulesen, aber so habe ich mir die 
Flexibilität beibehalten, die Kamera auf einen beliebig anderen AVR 
anzuschließen, indem ich vlt. nicht noch zusammenhängende Ports frei 
habe. Auch wenn ich das im aktuellen Fall nicht brauche.

Gute Nacht und bis Morgen

Gruß
David

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> richtig... in die Datei wurden Dezimal zahlen geschrieben... war ein
> Fehler, anbei die 0.4 Version in der der Fehler behoben wurde (und auch
> noch andere Sachen verbessert und Altlasten entfernt:

Danke, gefällt mir so viel besser. :-)
Wenn Du jetzt noch unterschiedliche Registerwerte ind den beiden Fenster 
farblich makieren würdest... ;-)
Und wenn Du die Datei im Format einer Struktur, also z.B.
  { 0x7a, 0x24 },
  { 0x7b, 0x04 },
  { 0x7c, 0x07 },
dann könnte ich das soger direkt aus der Datei in meinen AVR_Source 
kopieren...
Duck und schnell ganz weit weg.... ;-)

David D. schrieb:
> Ich gebe zu, dass es, wenn die Datenpins auf einem Address Byte liegen
> es sicher einfach wäre die auszulesen, aber so habe ich mir die
> Flexibilität beibehalten, die Kamera auf einen beliebig anderen AVR
> anzuschließen, indem ich vlt. nicht noch zusammenhängende Ports frei
> habe. Auch wenn ich das im aktuellen Fall nicht brauche.

Deine Intension ist mir schon klar. Meine Meinung hatte ich ja schon am 
Anfang geschreiben: eine OV7670 an einem AVR (egal welchen) ist eine 
Spielerei und für mich nur der Spaß daran, ob es geht.
Ich könnte an mein Konstrukt durchaus noch einen ENC28J60 ranstricken 
und den alten Webserver da reinknoten. Ein BMP-Header voran und das Bild 
im Browser anzeigen.
Macht für mich aber keinen Sinn.
Auf einem ESP32 kann ich die Daten per I2S-DMA parallel "nebenbei" holen 
und die IOs auf fast alle IOs mappen ohne irgendwelche Nachteile. Auch 
ohne Fifo.
Da diskutiere ich aber lieber mit der OV2640 rum, etwas bessere 
Auflösung und wahlweise gleich JPEG.

David D. schrieb:
>> Wer behandelt dann wie return 0; bei Fifo voll?
> niemand... dann läuft es einfach ins Leere... ich weiß aber leider nicht
> wie ich es besser machen soll :/

Wenn der FiFo voll ist, findet Dein UART0_rx_complete nie die gesuchten 
zeichen am Ende und niemand räumt den Fifio je wieder auf.
Ein fifo_full-Flag aus der ISR oder UART0_rx_in durchreichen und in der 
while(1) in main rigiros den Buffer aufräumen um wieder einen 
definierten Status zu bekommen?

Schönen Tag noch.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hi Leute,

Uli S. hatte offenbar unseren Thread übersehen (oder für nicht passend 
erachtet) und eine Frage zum SCCB-Protokoll auf einem STM32F429 hier im 
Forum eingestellt:
Beitrag "OV7670 blockiert Bus nach senden des Registers"

Michael U. hat ihn auf mich verwiesen und ich habe Uli gerade meinen 
SCCB-Code spendiert:
Beitrag "Re: OV7670 blockiert Bus nach senden des Registers"

Dies nur für den Fall, dass unser Stolberger Hardcore-AVR-Kämpfer 
irgendwann auf den Weg der Tugend findet und sich doch zum ARM Prozessor 
bekehren lässt ...

Viele Grüße

Igel1

[David D. (saturi)]

Hey Mitstreiter,

diese Woche ist leider ganz besonders schlimm bei mir.

@Michael:
>Und wenn Du die Datei im Format einer Struktur, also z.B.
>  { 0x7a, 0x24 },
>  { 0x7b, 0x04 },
>  { 0x7c, 0x07 },


mach ich dir, wenn das der Preis dafür ist, dass du dich weiter mit 
meinem Code auseinander setzt :) bekommst du spätestens morgen Abend.


Hat jemand schonmal mein Programm auf seiner Hardware ausprobiert? 
nicht, dass einfach meine HW kaputt ist …
 (nein ich habe es noch nicht geschafft eure auf meiner 
auszuprobieren... schäm)


Gruß
David

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> diese Woche ist leider ganz besonders schlimm bei mir.
kein Problem. Ich grabe das ja ohnehin nur bei Bedarf aus, ist dank 
meiner Adapterplatine jetzt auch kein Problem, das schnell 
zusammenzustecken.
Ein "Spezialkabel  für meinen LA werde ich mir noch löten, ist aber auch 
kein Aufwand.

David D. schrieb:
> mach ich dir, wenn das der Preis dafür ist, dass du dich weiter mit
> meinem Code auseinander setzt :) bekommst du spätestens morgen Abend.
Danke, keine Eile, dann kann ich Init-Sequenzen einfach mal im "meine" 
Software kopieren und testen.

David D. schrieb:
> Hat jemand schonmal mein Programm auf seiner Hardware ausprobiert?
> nicht, dass einfach meine HW kaputt ist …
Naja, zumindest hat Dein Terminalprogramm mit Deiner Software auf meinem 
AVR geredet, Registerkram ging inzwischen offenbar auch.
Mit Deiner v0.4 habe ich aber noch nicht wirklich weitergetestet, mal 
schauen, ob ich Bilddaten bekomme ohne hängen zu bleiben.
Kann aber sein, daß ich da auch erst am Wochenende wirklich zu komme.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hi Leute,

habe gestern Nacht mein UART endlich auf meinem STM32F429 in die Gänge 
gebracht (ein echter Kraftakt ...). Nun könnte ich Davids 
PC-Bilddarstellungsprogramm einmal ausprobieren.

Allerdings habe ich dazu noch zwei Fragen. Und da ich nicht unseren 
gesamten Thread hier nochmals durchflöhen wollte, stelle ich sie hier 
einfach:

- In welchem (Protokoll)format sendet David die Bilddaten an sein
  PC-Programm?   RGB565, Big-Endian?  Oder läßt er gar unterschiedliche
  Formate zu?

- In welchem (Protokoll)format sendet David Befehle von seinem
  PC-Programm an seinen MC? Und insbesondere: welche Bytefolge sendet
  David, um ein Register im OV7670 zu setzen?

Bitte seht's mir nach, wenn ich mir die Fragen bei aufmerksamer Lektüre 
des Threads hätte selbst beantworten können.

Viele Grüße

Igel1

[David D. (saturi)]

Guten Abend,

>kein Problem. Ich grabe das ja ohnehin nur bei Bedarf aus, ist dank
>meiner Adapterplatine jetzt auch kein Problem, das schnell
>zusammenzustecken.
Davon habe ich mich inspirieren lassen, weil ich eben auch nur sehr 
eingeschränkten Platz habe und schon immer rumgenörgelt wird, dass mein 
"Scheiß" den ganzen Schreibtisch blockiert :D...
Das einzige was mir noch fehlt ist der 2x11 Pin header für die Kamera, 
dann fange ich auch das Löten an.

@Igel:
>- In welchem (Protokoll)format sendet David die Bilddaten an sein
>  PC-Programm?   RGB565, Big-Endian?  Oder läßt er gar unterschiedliche
>  Formate zu?

Ja tut es, und zwar (sollte) es das automatisch tuen. Bisher 
implementiert sind das RGB565 format 1.Byte RRRRRGGG 2. Byte GGGBBBBB, 
und das YUV (wobei hier nur das Y interpretiert wird (hier sind dann 
auch noch abhängigkeit von der eingestellten Byte Order noch nicht 
implementiert, also würde ich raten auf RGB565 zu bleiben)


Sowohl das Farbformat als auch die Auflösung werden über Register 0x12 
erkannt und mit dem klick auf "get Camera Status" zuerst vom controller 
gelesen, ausgewertet und dann die Informationen xRes, yRes und 
BytesPerPixel an den Controller gesendet. Hier werden sie für die 
Ausleseroutine des FiFos benutzt.

Bei einem klick auf take picture complete, wird der ganze Frame direkt 
gesendet (ohne abschluss zeichen) bei take picture RbyR, Zeilenweise mit 
jeweils einem CR+LF am ende.


> In welchem (Protokoll)format sendet David Befehle von seinem
>  PC-Programm an seinen MC? Und insbesondere: welche Bytefolge sendet
>  David, um ein Register im OV7670 zu setzen?


folgende Kommandos kann der uC empfangen:
CommandAuswirkung  Byte1  Byte2  expected Return Value
0x01  Read Register  Register Address  -  1 Byte register Value
0x02  Write Register  Register Address  newRegisterValue  1 Byte 
Errorcode
0x03  Take Picture      1 Row  with CR+LF
0x04  set xResolution  Resolution x MSB  Resolution x LSB  1 Byte 
xresolution Value
0x05  set yResolution  Resolution y MSB  Resolution y LSB  1 Byte 
yresolution Value
0x06  set BytesPerPixel  BytesPerPixel    1 Byte bytesperpixel Value
0x08  initialisiere Kamera      Error Code
0x0A  request new Line      1 Row with CR+LF
0x0B  request Line repeat      1 Row with CR + LF
0x0C  take complete Picture      complete frame in px

Ich hoffe, dass ist lesbar
Edit: hmm wohl kaum. Ich schaue mal, dass ich vlt. noch ne Tabelle 
herbekommen, anbei aber schonmal ein Screenshot von der Excel Tabelle:

[Andreas S. (igel1)]

Hallo David,

Danke für die Mühen.
Leider lese ich aus Deinen Ausführungen, dass Du Dein PC-Programm und
Dein MC-Programm ziemlich eng miteinander verknüpft hast.

Wollte ich also Dein PC-Programm nutzen, so müsste ich auch die
entsprechenden Register-Leseroutinen uns sonstigen Routinen auf
meinem ARM einbauen. Machbar wäre das, aber wiederum Aufwand.

Gibt es in Deinem Programm auch eine Möglichkeit, statt die Parameter
vom MC auszulesen und dann das Format automatisch zu setzen, das
ganze manuell im PC-Programm einzustellen?

Das wäre ideal für mich (... tssss - Wünsche haben die Leute ...)

Viele Grüße

Igel1

[Andreas S. (igel1)]

Hi,

anbei mein erstes per USART übertragenes Bild.
Angezeigt bei http://rawpixels.net/

Auf diese Website kann man Bilddateien unterschiedlichsten Formats 
hochladen und bekommt die Inhalte dann angezeigt.

Echt praktisch in meinem Fall (natürlich hätte ich lieber David's 
Programm dafür genutzt, aber ... siehe voriger Beitrag ...)

Viele Grüße

Igel1

[Andreas S. (igel1)]

... und weil's gerade so gut läuft, hier noch ein "richtiges Bild" - 
ebenfalls per USART übertragen.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> ... und weil's gerade so gut läuft, hier noch ein "richtiges Bild" -
> ebenfalls per USART übertragen.

na geht doch. :-)
Falls Du unter Windows unterwegs bist, nimm Irfanview, brauchst Du kdas 
Internet nicht. Soll angeblich auch unter Linux mit Wine laufen.
Dann einfach laden RAW.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hi David,

Du hast geschrieben:
> Sowohl das Farbformat als auch die Auflösung werden über Register 0x12
> erkannt und mit dem klick auf "get Camera Status" zuerst vom controller
> gelesen, ausgewertet und dann die Informationen xRes, yRes und
> BytesPerPixel an den Controller gesendet. Hier werden sie für die
> Ausleseroutine des FiFos benutzt.

Habe eine Nacht darüber geschlafen, verstehe die Zs.hänge aber leider 
nicht richtig:

Frage 1:

Warum liest Du Register 0x12 aus, um daraus die Dimensionen des Bildes 
abzuleiten und diese dann wiederum zurück an den MC zu senden?

Frage 2:

Wie wir festgestellt haben, haben die Bilder, trotz ausgewähltem QVGA, 
teilweise nur Zeilenlängen von 311 oder 313 Pixeln. Wie berechnest Du 
dann aus Register 0x12 die richtige Zeilenlänge?

Frage 3:

Und dann verstehe ich das CR+LF am Ende der Übertragung einer Zeile 
nicht. Was ist Sinn und Zweck der beiden Zeichen?

Frage 4:

Was genau macht der Befehl 0x03 ?

Frage 5:

Was ist der Unterschied zwischen Befehl 0x03 und 0x0B ?

Ich gebe zu: ich könnte sicherlich auch alles mit Fleiß und Ausdauer aus 
Deinem Code ableiten, aber dazu bin ich ein bisschen zu bequem ...

Viele Grüße

Igel1

[Andreas S. (igel1)]

Hi David,

habe soeben Dein "OV7670-Terminal_V0.4.zip" heruntergeladen und 
ausprobiert.

Ich muss gestehen, dass ich einiges darin nicht verstehe.
Bitte sei trotzdem nicht frustriert: ich hatte auch kein 100%ig 
selbsterklärendes Programm erwartet - ist ja noch alles im Fluss ...

Zwei Dinge stachen mir sofort ins Auge:

Issue 1:

Der Rechte Rand Deines Fensters wird abgeschnitten. Intuitiv versucht 
man dann, das Fenster in Richtung X-Achse größer zu ziehen, aber das 
geht leider nicht - scheint fix zu sein.

Issue 2:

Ich habe versucht, in Deinem Reiter "Load Image" mein RGB565-file in 
Dein Programm einzuladen, um es dort anzeigen zu lassen. Leider wurde 
nur ein schwarzes Bild angezeigt. Dabei bin ich mir sicher, dass die 
Daten in dem Bild korrekt sind und formatmässig passen. Immerhin konnte 
ich ja dieselbe Datei auf http://rawpixels.net/ sauber als Bild anzeigen 
lassen.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Der Rechte Rand Deines Fensters wird abgeschnitten. Intuitiv versucht
> man dann, das Fenster in Richtung X-Achse größer zu ziehen, aber das
> geht leider nicht - scheint fix zu sein.

kann ich hier mit der v0.4 nicht nachvollziehen unter Win7-64. 
Fenstergröße passt beim Start und beide Richtungen lassen sich 
größer/kleiner ziehen.

Gruß aus Berlin
Michael

[David D. (saturi)]

>Frage 1:
>Warum liest Du Register 0x12 aus, um daraus die Dimensionen des Bildes
>abzuleiten und diese dann wiederum zurück an den MC zu senden?

Weil über 0x12 ja die vordefinierten Auflösung oder das Farbformat 
definiert werden. Dann macht das Terminal eine fall unterscheidung.
Wenn QVGA dann Auflösung xxx yyy 2Bytes pro pixel. Die Werte für x y und 
Bytes per Pixel sind hardgecoded und werden je nach Fall Unterscheidung 
dann an den Controller gesendet


>Frage 2:
>Wie wir festgestellt haben, haben die Bilder, trotz ausgewähltem QVGA,
>teilweise nur Zeilenlängen von 311 oder 313 Pixeln. Wie berechnest Du
>dann aus Register 0x12 die richtige Zeilenlänge?
>eben genau durch diese "Hardgecodete
Eben genau über das Hardgecodete... nicht schön aber für den Anfang 
akzeptabel

>Frage 3:
>Und dann verstehe ich das CR+LF am Ende der Übertragung einer Zeile
>nicht. Was ist Sinn und Zweck der beiden Zeichen?
hiermit überprüfe ich, ob die Zeile vollständig angekommen ist, stimmen 
die beiden Zeichen nicht mit den beiden erwarteten überin wird ein Line 
Repeat gesendet und die gleiche Zeile wird nocheinmal übertragen. Komme 
zu wenig zeichen an, bricht der Bildaufbau einfach ab.

>Frage 4:
>Was genau macht der Befehl 0x03 ?
Bildaufnehmen und die erste Zeile senden.
>Frage 5:
>Was ist der Unterschied zwischen Befehl 0x03 und 0x0B ?
0x0B sendet nur die zuletzt gesendete Zeile nocheinmal. (Wenn vorher 
Zeilenweise ausgelesen wurde)
0x0C hingegen nimmt ein Bild auf und sendet den kompleeten Frame, vom 
ersten bis zum letzten Pixel im Bild ohne irgendwelche Steuerzeichen (CR 
LF etc.) also einfach pixel für pixel.

>Ich gebe zu: ich könnte sicherlich auch alles mit Fleiß und Ausdauer aus
>Deinem Code ableiten, aber dazu bin ich ein bisschen zu bequem ...
ein Problem

Andreas S. schrieb:

> Ich muss gestehen, dass ich einiges darin nicht verstehe.
> Bitte sei trotzdem nicht frustriert: ich hatte auch kein 100%ig
> selbsterklärendes Programm erwartet - ist ja noch alles im Fluss ...
Kein Problem... Ich auch nicht :D

> Issue 1:
>
> Der Rechte Rand Deines Fensters wird abgeschnitten. Intuitiv versucht
> man dann, das Fenster in Richtung X-Achse größer zu ziehen, aber das
> geht leider nicht - scheint fix zu sein.

Kann ich leider genau wie Michael nicht nachvollziehen bzw. 
reproduzieren. Welche auflösung benutzt du regulär auf deinem 
Bildschirm? das schaue ich mir heute Abend mal an.

> Issue 2:
>
> Ich habe versucht, in Deinem Reiter "Load Image" mein RGB565-file in
> Dein Programm einzuladen, um es dort anzeigen zu lassen. Leider wurde
> nur ein schwarzes Bild angezeigt. Dabei bin ich mir sicher, dass die
> Daten in dem Bild korrekt sind und formatmässig passen. Immerhin konnte
> ich ja dieselbe Datei auf http://rawpixels.net/ sauber als Bild anzeigen
> lassen.
Da hast du dir auch genau das rasugesucht, was noch nicht 
funktioniert... Auch das werde ich versuchen heute Abend zu 
implementieren ;-)

[Andreas S. (igel1)]

Hi David,

Danke für die Erläuterungen - jetzt blicke ich etwas besser durch die 
Funktionsweise Deines Programms durch.

Könntest Du netterweise zu meinem vor-vorigen Posting auch noch etwas 
schreiben? 
(Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)").

Viele Grüße

Igel1

[Andreas S. (igel1)]

David D. schrieb:
> Kann ich leider genau wie Michael nicht nachvollziehen bzw.
> reproduzieren. Welche auflösung benutzt du regulär auf deinem
> Bildschirm? das schaue ich mir heute Abend mal an.

Hab's gerade nochmals auf einem anderen Rechner ausprobiert (Win7 x64) - 
lief dort ohne Probleme und auch ohne das Fenster-Clipping Problem. 
Fenstervergrößerung funktionierte ebenfalls.

Kann Dir erst morgen die Eckdaten zu dem ersten Rechner zusenden.

Viele Grüße

Igel1

[David D. (saturi)]

Hallo zusammen,

anbei der neue Release mit:
- der Möglichkeit ein Struct zu speichern / zu öffnen
- ein Bild im RGB565 Format ohne jegliche Kommandos zu empfangen: 
Erwartet werden die RGB565 Bytes direct nacheinander ohne jegliches HREF 
oder VSYNC signal. (Falls man das auch so bei der Bildübertragung nennt)

https://github.com/igittigitt/ov7670/tree/TWI-Interfac/OV7670-Terminal-Releases

@Igel
Bild öffnen geht leider noch nicht. Dafür müsste ich von dir noch 
wissen, in welchem Format du die Bilder ablegst. auch einfach eine datei 
mit Byte nach Byte? oder siehts dadrin was anders aus?


Auch wenn ich noch nicht weiß, wie jetzt diese Änderungen des Terminals 
konkret bei der Lösungsfindung meines Codes hilft... :D

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Auch wenn ich noch nicht weiß, wie jetzt diese Änderungen des Terminals
> konkret bei der Lösungsfindung meines Codes hilft... :D

fühle ich mich jetzt mal angesprochen. ;-)
Ich will Deinen Code hier möglichst Original testen.
Mit der struct-Geschichte kann ich jetzt die Registersettings einfach im 
meinen spielenden Code werfen und schauen, ob das passt bzw. 
vergleichen, was nicht passt. Oder meine settmgs in Dein Terminal und 
testen.

Zum Bild bei mir: ich schicke den FiFo mit 320x240 Pixel, die 
fehlerhaften usw. sind mir erstmal eagl, gibt es am Rand eben einen 
fehlerhaften Streifen.

Es kommt entweder RGB565 in 2 Byte so wie sie aus dem FiFo kommen, ob 
das big- oder little Endian ist, spielt keine Rolle. Variante 2 ist YUV 
nur das Y-Byte. Die akommenden Daten schreibe ich bei mir auf dem PC mit 
TeraTerm direkt in eine Datei test.raw. Name und Endung sind eigentlich 
egal, zur Anzeige nutze ich Irfanview, dem kann ich alles wichtige zum 
RAW-Format einstellen. Es gibt keinerlei Kennung oder Header, nur die 
RAW-Daten aus dem FiFo.
Bei Deinem Terminal ist es gut, das ich mit den Registerwerten direkt 
rumspielen kann. Ob jetzt gespeichert werden kann oder es eine direkte 
Anzeige gibt, isr mir da eigentlich hier völlig egal.
Außer 320x240 in RGB565 oder YUV als 8Bit Graustufen (Y-Byte) macht für 
mich eigtlich im Moment nichts Sinn. Höhere Auflösung passt nicht in den 
FiFo und weniger finde ich quatsch.
Andere Formate als diese beiden würden ja nur Sinn machen, wenn man die 
Bilddaten im Zielprogramm selber weiter verarbeiten wollte oder.

Alle Einstellungen zum Analogteil wie Weißabgleich, Belichtung usw. usw. 
bzw. zum DSP kann ich auch so durchspielen.
Eine echte Verwendungsabsicht habe ich ohnehin nicht in der Kombi 
Mega328/OV7670.
Also bleibt es letztlich nur als Test für Deine Programmierung auf dem 
AVR.

230400 läuft hier mit dem Ardiono UNO und em 32U4 als USB-Wandler 
stabil, wenn es da Übertragungsfehler geben würde, müßten die eine 
Ursache haben, der ich nachgehen würde. Warum der Nano mit dem CH340 
auch 1MBit usw. stabil macht und der 32U4 nicht, habe ich keine Lust zu 
ergründen...

Gruß aus Berlin
Michael

[Michael U. (amiga)]

Hallo,

Völlig OT: mit diesem 64x32 RGB-Display habe ich mir im Moment die Zeit 
vertrieben... Hatte mein BEkannter gekauft und nach eiern Woche das 
Handtuch geworfen (das will was heißen!) und es mir in die Hand 
gedrückt.
Nach einer knappen Woche war ich am gleichen Punkt: nichts geht, 
wentweder ein paar sinnlos leuchtende Striche oder Flächen oder 
schwarzes Display.
Der Zufall hat mich vorgestern einen Thread dazu finden laasen. Das 
Display spielt bei keinem wirklich, Stromquellen-Schieberegister für die 
Zeilen und Decoer/MosFET-IC für die Spalten. Beides China, chinesiche 
Datenblätter in denen alles wichtige nicht drinsteht...
Da es in dem Forenthread zumindest Erkenntnisse und Ansätze gabe (einer 
oder beide IC-tyoen sind nicht asymcron-statisch wie es die Datenblätter 
suggereiren, sondern das Schiebereigster möchte irgendwie syncron 
zwischen SPI/Latch-Enable und /OE bedient werden.
jetzt muß ich mir erstmal in Ruhe anschauen, was ich da genau treibe, es 
ist jetzt stabil, der Ablauf aber reines ändern-flashen-wundern gewesen.
Die Ali-Händler bieten diese Displays mit diesem Chipset seit rund 3 
Wochen auch nicht mehr an wegen dieser Probleme.

So, wollte ich einfach mal loswerden. :-)

PS: das Display hat 64x32 Pixel mit 3mm LED-Abstabd. Sehr schönes Teil 
für den Preis.

Gruß aus Berlin
Michael

[David D. (saturi)]

Aber schick aussehen tut es! :D

wo bekommt ihr eigentlich eure Elektrobauteile her? Bin auf der suche 
nach 2x11 Buchsenleisten, aber >5€ bei Reichelt nur für den Versand ist 
mir zu blöd...

[Andreas S. (igel1)]

David D. schrieb:
> Hallo zusammen,
>
> anbei der neue Release mit:
> - der Möglichkeit ein Struct zu speichern / zu öffnen
> - ein Bild im RGB565 Format ohne jegliche Kommandos zu empfangen:

Juhuuuu - Weihnachten ...

> Erwartet werden die RGB565 Bytes direct nacheinander ohne jegliches HREF
> oder VSYNC signal. (Falls man das auch so bei der Bildübertragung nennt)

Supi ...


> https://github.com/igittigitt/ov7670/tree/TWI-Interfac/OV7670-Terminal-Releases

... schon gezogen ...

> @Igel
> Bild öffnen geht leider noch nicht. Dafür müsste ich von dir noch
> wissen, in welchem Format du die Bilder ablegst. auch einfach eine datei
> mit Byte nach Byte?

Genau.

> oder siehts dadrin was anders aus?

Nö.

> Auch wenn ich noch nicht weiß, wie jetzt diese Änderungen des Terminals
> konkret bei der Lösungsfindung meines Codes hilft... :D

Hmmm - ich würde das eher eine selbstlose Spende nennen, für die ich 
mich recht herzlich bedanken möchte!

Leider stürzt Dein Programm im "Manuellem Modus" beim Versuch "Bild 
empfangen" sang und klanglos bereits nach ein paar Zeilen Übertragung 
(115200 baud, 8N1) ab - siehe Bild im Anhang.

Fehlercodes waren:

Problemsignatur:
  Problemereignisname:  CLR20r3
  Problemsignatur 01:  OV7670-Terminal.exe
  Problemsignatur 02:  1.0.0.0
  Problemsignatur 03:  5c67f336
  Problemsignatur 04:  OV7670-Terminal
  Problemsignatur 05:  1.0.0.0
  Problemsignatur 06:  5c67f336
  Problemsignatur 07:  6c
  Problemsignatur 08:  1c
  Problemsignatur 09:  System.NullReferenceException
  Betriebsystemversion:  6.1.7601.2.1.0.256.4
  Gebietsschema-ID:  1031
  Zusatzinformation 1:  0a9e
  Zusatzinformation 2:  0a9e372d3b4ad19135b953a78882e789
  Zusatzinformation 3:  0a9e
  Zusatzinformation 4:  0a9e372d3b4ad19135b953a78882e789

Lesen Sie unsere Datenschutzbestimmungen online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline:
  C:\Windows\system32\de-DE\erofflps.txt

Das Clipping-Problem existiert leider ebenfalls noch:
Der rechte Rand des Programm-Windows wird abgeschnitten und das gesamte 
Window läßt sich nicht über die existierende Breite hinaus aufziehen - 
wohl aber verkleinern.

Meine Auflösung: 1920 x 1200 TrueColor (32bit), Windows 7 x64. Wenn ich 
das Programm starte, so nimmt es von Anfang an die gesamte 
Bildschirmbreite ein und wird am rechten Rand abgeschnitten - wie weiter 
oben in einem meiner vorigen Postings gezeigt.

Viele Grüße

Igel1