Brauche Unterstützung beim OV7670 (bzw. SCCB)

[Andreas S. (igel1)]

@Michael:  Schickes Display - versuche doch mal mit der OV7670-Kamera 
die Uhrzeit abzulesen - das wäre vermutlich genau die richtige 
Herausforderung für einen Hobbyisten Deines Kalibers   :-)

Viele Grüße

Igel1


PS:  Juhu, gewonnen: erster Beitrag in der dritten MC-Threadseite.

[David D. (saturi)]

Glückwunsch:D

> 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.


Das sollte nicht so sein :D ... Hmm hab eine Vermutung ab2r kannst du 
mir genau sagen was du machst? Du hast aber schon die x y und Bytes per 
Pixel Felder mit integren gefüllt?

Ich geh der Sache nachher auf den Grund, wenn ich wieder zuhause bin

[David D. (saturi)]

Problem gefunden!

Da sieht man, dass ich kein gelernter Programmierer bin ... ich sollte 
doch öfter mit exceptions arbeiten...

Naja, hier fürs erste die neuste Version, mit der du jetzt aber ein Bild 
empfangen können solltest.

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

Bei Problemen einfach wieder den report und das Vorgehen schreiben :D 
dann finde ich die Fehler schon.. hoffentlich

[Andreas S. (igel1)]

David D. schrieb:
> Problem gefunden!

Na wenn das mal keine Weltklasse-Supportzeiten sind, dann weiß ich auch 
nicht mehr :-)

Also: der Durchbruch ist fast geschafft (wie Du im Anhang sehen kannst).
Aber: Der Bildaufbau geht nur die ersten Zeilen flott und kommt dann 
seltsam ins Stocken. Erst wenn mein Bild zu ende übertragen ist, 
flutscht Dein Bildaufbau wieder weiter, bricht dann aber bei Zeile 90 
ab.

Offensichtlich wurden aber alle Pixel eingeladen - denn wenn ich ein 
(oder manchmal gar mehrere) weiteres, neues Bild übertrage, so wird das 
alte, abgebrochene Bild zuende aufgebaut - erst bis Zeile 183, dann beim 
nächsten Bildsenden bis Zeile 239 - fertig.

Ich sende mit 115200 baud, 8N1.

Das Verhalten ist nicht ganz deterministisch - manchmals werden mehr 
Zeilen übertragen und dann bricht's ab, manchmal weniger.

Viele Grüße

Igel1


PS:  ... bin jetzt mal ein Weilchen weg ...

[Michael U. (amiga)]

Hallo,

ich habe jetzt noch nicht wirklich was mit dem terminal weitergemacht, 
aber das Window-Problem ist hier noch nie aufgetrreten.
Einen Absturz hat es zumindest auch noch nie gegeben, allerdings bekomme 
ich sehr häufig eine keine Reaktion mehr nach dem Absenden eines 
Kommandos.
Beispiel: connect -> ok, Ausgabe im Logfenster kommt
Kamera initialisieren -> ok, Ausgabe im Logfenster kommt
get camera status -> ok, Ausgabe im Logfenster kommt, Registerinhalte 
werden angezeigt.
Jetzt kann ich eigentlich anklicken, was ich will:
take Picture complete,
take Picture RbyR,
Read Device Settings usw.
Es wird unten links angezeigt, es wird ins Log-Fenster geschreiben und 
es passiert nichts. Ich kann dann auch ein anderes Kommando anwählen, 
wie gehabt.
Safe File, Open File usw. funktionieren aber weiterhin richtig.

Darüber muß ich erstmal nachdenken...

Andreas S.: was ich im Moment garnicht verstehe: ich lese in meinem 
Programm von der Kamera in den FiFo:
- auf VSYNC LOW warten um sicher zu sein, daß ich nicht in einen aktiven 
VSYNC gerate
- auf VSYNC HIGH warten
- WRST auf LOW
- auf VSYNC LOW warten (Endes des SYNC-Impulses)
- WRST auf HIGH
- WR auf HIGH
- auf VSYNC HIGH warten (beginn des SYNC-Impulses)
- WR auf LOW

Dann lese ich im loop 240 Zeilen zu je 320 Pixel aus und schicke die 
raus.
Es müssen also in einer Zeile jeweils 32ß Pixel im FiFo sein, sonst 
bekäme ich nie ein Bild weil es von zeile zu zeile eine Veschiebung 
gäbe.
Das am Rand fehlerhafte Pixel sind, heißt für mich, daß da von der 
Kamera Schrottdaten in den FiFo kamen, aber eben in der richtigen 
Anzahl.

Gruß aus Berlin
Michael

[Tom (Gast)]

Michael U. schrieb:
> 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...
Bisher habe ich in solchen Fällen die Chips gefunden, welche die 
Chinesen als Vorlage für die ihren genommen haben.
Mit den entsprechend besser lesbaren Datenblättern...

[Michael U. (amiga)]

Hallo,

@Tom (Gast): ist mir bisher nicht gelungen... FM6126A

zurück zur OV7670: ich komme erst morgen dazu, das jetzt hier 
aufzuräumen und weiter zu testen.

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Tom schrieb:
> Bisher habe ich in solchen Fällen die Chips gefunden, welche die
> Chinesen als Vorlage für die ihren genommen haben.
> Mit den entsprechend besser lesbaren Datenblättern...

Zeig mal

[David D. (saturi)]

Michael U. schrieb:
> take Picture complete,
> take Picture RbyR,
> Read Device Settings usw.
> Es wird unten links angezeigt, es wird ins Log-Fenster geschreiben und
> es passiert nichts. Ich kann dann auch ein anderes Kommando anwählen,
> wie gehabt.
> Safe File, Open File usw. funktionieren aber weiterhin richtig.

> take Picture complete,
> take Picture RbyR,
Setzten beide meine Software voraus, ich gehe davon aus, dass du diese 
benutzt, da sonst das Register Schreiben/Lesen ebenfalls nicht 
funktionieren würde.

Ich gebe zu, dass das Programm DERZEIT nicht wirklich intuitiv bzw. 
sogar sinnvoll zu bedienen ist. Ich bin aber gerade dabei, hier einiges 
anzupassen, das das Bild, das Andreas mit meinem Programm aufnehmen 
konnte, mir einen deutlichen Motivationsschub verpasst hat! :)

Nochmal eine ganz kurze Schritt für Schritt Anleitung wie es klappen 
sollte:
1) Com Port verbinden und Baudrate gleichhaben (brauche ich dir nicht zu 
sagen ;-)

2) Kamera initialisieren drücken. Jetzt sollten zwei einträge im Log 
erscheinen. 1. initialisiere Kamera, 2. initialisierung erfolgreich. 
Sollte hier die initialisierung fehlschlagen, einfach ein paar mal read 
register klicken und dann nocheinmal Kamera initialisieren versuchen. 
manchmal scheinen sich irgendwoher Bytes im PC-Seitigen COM Buffer 
einzufinden, die dann fälchlicherweise als ErrorCode identifiziert 
werden.

3) Klick auf get camera status. Jetzt sollte unbedingt, bei Version 0x76 
0x73 stehen. Damit ist sicher gestellt, dass die richtigen Register von 
der Kamera gelesen werden.

4. Register einstellen (entweder bei Write Register oder mit geladenen 
Settings.

Ich verwende aktuell:
0x11 0x00
0x12 0x16
0x40 0x14
0x42 0x08
0x15 0x00
(Ich hoffe ihr könnt die bestätigen)

5. get camera status klicken. Jetzt müssen Resolution auf QVGA und Color 
Format auf RGB565 stehen. Andere Formate werden noch nicht unterstützt 
und in einer internen Fallunterscheide fürs erste einfach übergangen. 
Dann tut sich bei deinem Bildaufbau garnichts.

6. Steht soweit erstmal alles richtig dar, kann jetzt mit take Picture 
complete oder take Picture RbyR ein Bild aufgenommen werden. (Ist auch 
etwas größer zu sehen unter dem tab _picture bei einem der Beiden 
Bildboxen das Häckchen zur Sychronisierung setzten.


Ich hoffe so hast du erfolg. Bitte um Rückmeldung :)

[Andreas S. (igel1)]

David D. schrieb:
> Ich gebe zu, dass das Programm DERZEIT nicht wirklich intuitiv bzw.
> sogar sinnvoll zu bedienen ist. Ich bin aber gerade dabei, hier einiges
> anzupassen, das das Bild, das Andreas mit meinem Programm aufnehmen
> konnte, mir einen deutlichen Motivationsschub verpasst hat! :)

Das freut mich sehr für Dich - ich bin ganz sicher, dass wir Dein 
MC-Programm auch noch in die Gänge bekommen.

Wenn Du Zeit und Lust hast, den o.g. Fehler bzgl. Abbruch beim 
Bildaufbau noch zu fixen (vgl. mein letztes Posting: 
Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)") so 
wäre das super.

Bitte nenne mir einmal Deine Funktion, in der Du das Bild als ganzes 
überträgst (also ohne CR+LF), dann würde ich mir diese Funktion einmal 
gesondert angucken und brauche mich nicht durch den ganzen Code zu 
wühlen.

Viele Grüße

Igel1

[David D. (saturi)]

Andreas S. schrieb:
> Wenn Du Zeit und Lust hast, den o.g. Fehler bzgl. Abbruch beim
> Bildaufbau noch zu fixen (vgl. mein letztes Posting:
> Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)") so
> wäre das super.


Tja... Da liegt der Hund begraben :D...

Ich denke, dass ist das gleiche Problem, dass ich auch bei den Read All 
Register auslesen habe. Es ist leider, wie du schon geschrieben hast, 
passiert es scheinbar zufällig... Ich kann mir da aktuell noch keinen 
Reim drauf bilden. Da kann ich leider nicht mit einem Hotfix dienen :D 
diese Problem verfolgt mich schon des längeren. Aber auch das werde ich 
hoffentlich irgendwann einmal finden

> Bitte nenne mir einmal Deine Funktion, in der Du das Bild als ganzes
> überträgst (also ohne CR+LF), dann würde ich mir diese Funktion einmal
> gesondert angucken und brauche mich nicht durch den ganzen Code zu
> wühlen.

Die ist relativ "einfach" gehalten:
es geht los in der main.c  case 0x0C:

OV7670_captureNewImage();
OV7670_ResetFifoReadPointer();
sendFrameBufferToUART (width, height, BytesPerPixel);

alle drei Funktionen aus der Datei: OV7670_withFifo.c
Die Namen sind denke ich selbsterklärend.

[David D. (saturi)]

Sonntag, 17.02.2019 .... irgendwann mitten in der Nacht,
David D. gelingt nach 1,5 JAHREN Entwicklungszeit der vermeintliche 
Durchbruch. Das bisherige Problem? BANAL!

Lediglich der pure Zufall brachte ihm die Erkenntnis. Er hatte sich 
entschlossen nur noch eine letzte Messung in dieser Nacht vorzunehmen, 
bevor er am nächsten Morgen mit der Betonwalze über diese Kamera fahren 
würde. Die Zielführende Messung war die Pulsdauer des WCK. Schon 
hundertmal durchgeführt, ohne Erfolg. Doch diesmal sollte es anders 
kommen, denn diesmal drehte er das Kamera Modul nicht einfach herum, um 
die Pins des Fifos zu erreichen. Dem Zufall geschuldet war, dass gerade 
seine 3. Hand Lupe in Reichweite stand, in die er die Kameraplatine 
einspannte und so die Verkabelung - eigentlich nicht hinnehmbar - unter 
Spannung setzte. Ein kurzer Klick auf take picture und den Blick zum 
Oszilloskop gewannt brachte die ernüchternde Erkenntnis nichts neues 
entdeckt zu haben. Ein Blick zurück zum Bildschirm, um erneut ein Bild 
aufzunehmen und.... WAS? eine Colorbar im Terminal Programm? Wo kommt 
die denn jetzt her? Nichts am uC verändert, nichts am Terminal Programm?
Kurze Augenblicke der Ratlosigkeit und dann der Gedanke daran, dass es 
wohl an der EMV liegen könnte, schließlich standen bei ihm einige 
elektrische Geräte in kurzer Distanz rund um den Versuchsaufbau. Kurz 
ausgespannt, wieder eingespannt.... und nichts...
Dann schoss ihm der Gedanke in den Kopf, evtl. mit der Oszilloskop Probe 
zwei Kontakte gleichzeitig berührt zu haben und so den FIFO in einen 
funktionierenden Zustand versetzt zu haben, doch nein, das erschien ihm 
dann doch zu unwahrscheinlich. Was konnte es also gewesen sein?
Es traf ihn wie einen Blitz: die Kabel der einzelnen 
Breadboardverbindern sind durch das einspannen in die andere Richtung 
gebogen gewesen als sonst, kurz nachgestellt und ZACK! die Colorbar ist 
da. Offenbar
handelt es sich um eine Kontaktschwierigkeit an den Steckern, die 
eigentlich allesamt bombenfest an der Kamera sitzen. Leichte 
Kontaktierungsprobleme die eine so fatale Wirkung haben, dass von dem 
eigentlichen Bild nichts mehr zu erkennen ist.

Ich danke an dieser Stelle dem Schicksal :D
Morgen wird also gelötet und dann bin ich wieder mit im Rennen!

Anbei zwei Bilder, 1x Colorbar (klar hier stimmt noch einiges nicht, 
aber es sind schonmal Balken zu sehen! und 2x meine Handy Taschenlampe 
in völliger Dunkelheit :D

Bis Morgen

Gruß

David

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Ich danke an dieser Stelle dem Schicksal :D
> Morgen wird also gelötet und dann bin ich wieder mit im Rennen!

erstmal Glückwunsch zum Erfolgserlebnis!
Und nun rate mal, warum ich mir die Adapterplatine gelötet habe...

Deine AVR-Source bei github ist die Deine aktuelle?
Ich habe es jetzt mal in ein AVR-Studio Projekt geworfen, muß nachher 
mal meinen Dragon raussuchen zum flashen.
Die 22 warnings ignoriere ich jetzt mal, sind zwar nicht ganz 
unberechtigt, stören aber die Funktion im Moment nicht.
Mal überlegen, ob ich den uralten GCC noch durch einen aktuellen 
ersetze, vermutlich nicht, es gibt da noch 3-4 fast 10 Jahre alte 
Projekte, an die ich vielleicht noch mal rangehe und wer weiß, ob die 
dann noch sauber laufen. ;-=

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Glückwunsch, David!
Welch ein Krimi, den Du da sehr nett und lustig beschrieben hast.
Besonders bei der Passage mit der Betonwalze musste ich lachen.

Sollte ich heute Zeit finden, so gucke ich mir Deinen Code einmal an.
Allerdings beweist das Colorbarbild, dass Du eigentlich schon alles 
richtig machst - bis auf die Farbdecodierung, also das Entnehmen der 
Farbinfio aus den 2 Bytes des RGB565.

Viele Grüße

Igel1

[Andreas S. (igel1)]

David D. schrieb:
> Die ist relativ "einfach" gehalten:
> es geht los in der main.c  case 0x0C:
> OV7670_captureNewImage();
> OV7670_ResetFifoReadPointer();
> sendFrameBufferToUART (width, height, BytesPerPixel);
>
> alle drei Funktionen aus der Datei: OV7670_withFifo.c
> Die Namen sind denke ich selbsterklärend.

Liegt hier die letzte Version Deines Codes:
https://github.com/igittigitt/ov7670/tree/TWI-Interfac/OV7670-AVR/OV7670-AVR
?

Scheint mir etwas alt zu sein - ausserdem gibt es dort keine Datei 
"OV7670_withFifo.c" sondern nur eine Datei "OV7670_with_Fifo.c", die 
immerhin schon 6 Tage alt ist. Die von Dir erwähnten Funktionen sind 
allerdings alle darin enthalten.

Bevor ich aber nun die falsche Datei analysiere, wollte ich erst einmal 
nachfragen ...

Viele Grüße

Igel1

PS: ... bin jetzt vermutlich erst einmal ein paar Stunden Wandern, dann 
Besuch, dann Familie ...

[David D. (saturi)]

Michael U. schrieb:
> Und nun rate mal, warum ich mir die Adapterplatine gelötet habe...
Ich hatte es auch schon länger vor, aber nunja... daran hätte ich nicht 
gedacht.

> Deine AVR-Source bei github ist die Deine aktuelle?

jetzt ja, warum er es gestern nicht sync. hat, weiß ich nicht. (also im 
TWI branch)

>Allerdings beweist das Colorbarbild, dass Du eigentlich schon alles
>richtig machst - bis auf die Farbdecodierung, also das Entnehmen der
>Farbinfio aus den 2 Bytes des RGB565.


Nein, leider nicht. denn wenn ich mehrmals auslese bekomme ich 
verschiedene Colorbars, zum Teil auch im Bild gewechselt, also schein 
ich troztdem ein Problem mit dem Rücksetzen des Read oder Write Pointers 
zu haben...

>Scheint mir etwas alt zu sein - ausserdem gibt es dort keine Datei
>"OV7670_withFifo.c" sondern nur eine Datei "OV7670_with_Fifo.c", die
>immerhin schon 6 Tage alt ist. Die von Dir erwähnten Funktionen sind
>allerdings alle darin enthalten.

ja, jetzt die neuste online. Ich dachte mir, die Transferaugabe, sich 
einen "_" zu denken kriegt ihr hin ;-) ich meine natürlich diese.

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

viel Spaß beim Wandern

[Michael U. (amiga)]

Hallo,

github ist für mich normalerweise nur Quelle irgendwelcher 
Arduino/ESP-Geschichten... Ich durchsuche die commits da normalerweise 
nur, wenn ich nach einem bestimmten Problem suche, das evtl. schon 
behoben ist, aber noch nicht im relaese gelandet ist. Ich werde mit 
Sicherheit auch hier nur das aktuelle Archiv runterladen und daruf 
vertrauen daß es das ist: aktuell.

Bei mir zumindest einer der Gründe, weshalb ich z.B. lieber ein 
aktuelles zip mit einem Projekt nehme und nur vergleiche, welche Dateien 
neuer sind.

So, ich habe jetzt meinen Dragon mal angeworfen und das, was ich hier 
hatte, im alten AVR-Sturdo compiliert und geflasht. Soweit erstmal ok.
Cam-Init klappt, Register klappt, Einstellungen passen irgendwie nicht, 
er setzt bei get camera status VGA und will 480 Zeilen einlesen.
Reproduzierbar kommt er dabei bis Zeile 29 und dann steht der Laden.
Terminal zu, AVR Reset, alles von vorn und wieder Zeile 29. Alles bei 
230400 getestet.
ok, bei 19200 liest er nur eine Zeile ein.
Jetzt doch mal alle Dateien durch die im Link von Andres S. ersetzt, 
identisches Ergebnis.
Ich habe nur mein Pinout in OV7670_with_Fifo.h angepasst und die 
Baudrate in UART.c, dort X2 gesetzt wegen des kleineren Fehlers bei 
hohen Baudraten und UBRR0L entsprechend gesetzt.

Jetzt sind auch hier erstmal andere Sachen auf dem Plan.

Gruß aus Berlin
Michael

[Michael U. (amiga)]

Hallo,

ok, Du bist schnell, David...
Sourcen aus Deinem letzten Link reingeworfen, compiliert.

Immernoch als default VGA und YUV? Warum nicht QVGA und RGB565?
Er macht beim Bild lesen alle 21-22 Zeilen eine Kaffepause, liest dann 
aber weiter. Muß ich später mal reinschauen, mit 230400 dauert ein Bild 
aus dem Fifo lesen doch sonst nur wenige Sekunden?

PS: er hat inzwischen 479 Zeilen abgeholt, für die letzte hat er keine 
Lust mehr...

PPS: nach Neustrta von Terminal und AVR läuft jetzt wieder kein Kamera 
Init, ich hör jetzt erstmal auf.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> PS: er hat inzwischen 479 Zeilen abgeholt, für die letzte hat er keine
> Lust mehr

... weil er vermutlich bei Zeile 0 beginnt ...

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> ... weil er vermutlich bei Zeile 0 beginnt ...

da steht doch aber "hole Zeile 479 von 480"... ;-)

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> da steht doch aber "hole Zeile 479 von 480"... ;-)

Da steht vermutlich auch "hole Zeile 0 von 480" ?
Wenn ja, so passt ja alles (... bis auf die Optik ...)

Viele Grüße

Igel1

[Andreas S. (igel1)]

Hi David,

weil sich Deine Camera->FiFo - Einleseroutine in einigen Punkten doch 
deutlich von meiner Routine unterscheidet, habe ich Deine Routine 
"OV7670_captureNewImage (void)" in ARM-Sprache übersetzt und 
anschließend testweise meine durch Deine Routine ersetzt:

void OV7670_captureNewImage_David (void)
 {
   //OV_WR_PORT &= ~(1<<OV_WR_PinNo); //Write Disabled (defined start value)
         Write_FIFO_WR(Bit_RESET);

   // while(!getValueOfPin(OV_VSync_PIN,OV_VSync_PinNo));  //Wait for VSync to indicate a new Frame
         while (!Read_VSYNC()) {}

   //OV7670_ResetFifoWritePointer();//Enable Write Pointer
         Write_FIFO_WRST(Bit_RESET);
         Delay(1);
         Write_FIFO_WRST(Bit_SET);

          
   //while(getValueOfPin(OV_VSync_PIN,OV_VSync_PinNo));
         while (Read_VSYNC()) {}

   //OV_WR_PORT |= (1<<OV_WR_PinNo);  //Write Enable so that the camera can write on the FrameBuffer
         Write_FIFO_WR(Bit_SET);

   //while(!getValueOfPin(OV_VSync_PIN,OV_VSync_PinNo)); //Wait for the next VSync Pulse, so the frame is complete
         while (!Read_VSYNC()) {}

   //OV_WR_PORT &= ~(1<<OV_WR_PinNo); //Write Disabled that the picture is safe in the Framebuffer
         Write_FIFO_WR(Bit_RESET);

  // _delay_ms(20);

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

Ergebnis: funktioniert auf meinem STM32F429 tadellos.

Viele Grüße

Igel1

[Andreas S. (igel1)]

Hi David,

habe gerade einmal gesucht, ob Du "Output Enable" auf LOW ziehst, aber 
auf die Schnelle nichts dergleichen in Deinem Code gefunden.

Bitte schau selbst einmal nach, ob Du den Pin FiFo_OE des Moduls 
irgendwo in Deinem Programm auf LOW ziehst.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> habe gerade einmal gesucht, ob Du "Output Enable" auf LOW ziehst, aber
> auf die Schnelle nichts dergleichen in Deinem Code gefunden.

er und auch ich haben ihn fest auf GND verdrahtet, wir sind ja alleine 
am Bus und lesen dort nur Daten.

PS: vorhin ganz vergessen...
Woltest Du nur ein Bild von der Uhrzeit auf dem Display oder soll noch 
eine Texterkennung mit formatierter serieller Ausgabe der Zeit rein? ;-)
PPS: ein Glück, meine Software geht noch undd as Geheimnis des 
UART-Wandlers auf dem UNO habe ich auch halbwegs ergründet bzw. 
umgangen, jetzt also wieder mit 1MBaud.
Mit dem Licht kommt sie bei den Einstellungen aber nicht richtig 
zurecht...

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> er und auch ich haben ihn fest auf GND verdrahtet, wir sind ja alleine
> am Bus und lesen dort nur Daten.

Das widerspricht aber dem Schaltplan von David:
Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)"

Dort liegt FiFo_OE an Pin D13.
Oder wurden danach noch andere Absprachen getroffen, die ich überlesen 
habe?

> PS: vorhin ganz vergessen...
> Woltest Du nur ein Bild von der Uhrzeit auf dem Display oder soll noch
> eine Texterkennung mit formatierter serieller Ausgabe der Zeit rein? ;-)

B)

> PPS: ein Glück, meine Software geht noch undd as Geheimnis des
> UART-Wandlers auf dem UNO habe ich auch halbwegs ergründet bzw.
> umgangen, jetzt also wieder mit 1MBaud.

> Mit dem Licht kommt sie bei den Einstellungen aber nicht richtig
> zurecht...

??
Willst Du sagen, dass das Bild aus Deinem letzten Posting von der 
OV7670-Camera stammt?

Viele Grüße

Igel1

[Andreas S. (igel1)]

Was mich noch sehr interessieren würde, ist folgendes:

Wenn man die Frame-Ausgabe von Davids MC-Programm per Realterm (also 
nicht mit Davids PC-Programm) mit gemütlichen 115200 baud empfängt und 
die Daten von Realterm direkt in eine Datei umleiten lässt, kommt dann 
ein korrektes Bild dabei heraus?

Will sagen: hat David schon sein PC-Programm als mögliche Fehlerursache 
ausgeschlossen?

Viele Grüße

Andreas

[Andreas S. (igel1)]

Andreas S. schrieb:
>> er und auch ich haben ihn fest auf GND verdrahtet, wir sind ja alleine
>> am Bus und lesen dort nur Daten.
>
> Das widerspricht aber dem Schaltplan von David:
> Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)"
>
> Dort liegt FiFo_OE an Pin D13.
> Oder wurden danach noch andere Absprachen getroffen, die ich überlesen
> habe?

Hat sich inzwischen geklärt: ich habe in einem der vorigen Posting 
folgende Aussage von David gefunden:

"Edit: OE überigens auf GND"

Damit ist das schon einmal geklärt und als Fehlerursache ausgeschlossen.

Viele Grüße

Igel1

[David D. (saturi)]

Hallo, hatte heute leider Vereins-Dienst und bin daher nich viel weiter 
gekommen, als 4 von 22 Pins fertig zu löten... Immerhin, damit läuft die 
Kamera schon und Register schreiben und lesen geht auch.
Leider bin ich ab morgen erstmal für zwei Tage weg und kann mich danach 
erst um deine Routine kümmern @ Igel. Aber ich wollte zuerst das 
gelötete fertig haben um sicher zu sein, dass ich keinen Wackler mehr im 
Kabel habe.

>Bitte schau selbst einmal nach, ob Du den Pin FiFo_OE des Moduls
>irgendwo in Deinem Programm auf LOW ziehst.
Michael hats richtig gesagt: Wir beide haben ihn HW technisch auf GND. 
Auch wenn es offensichtlich mal anders war :D das kann ich aber jetzt 
nicht mehr nachvollziehen. Bringe da auch gerne eine geupdatete 
schematic

Andreas S. schrieb:
> Wenn man die Frame-Ausgabe von Davids MC-Programm per Realterm (also
> nicht mit Davids PC-Programm) mit gemütlichen 115200 baud empfängt und
> die Daten von Realterm direkt in eine Datei umleiten lässt, kommt dann
> ein korrektes Bild dabei heraus?
>
> Will sagen: hat David schon sein PC-Programm als mögliche Fehlerursache
> ausgeschlossen?
>
> Viele Grüße
>
> Andreas
Nein habe ich nicht, ich dachte, das hättest du mit dem Beweisbild.
Bis Mittwoch (oder vlt. zwischendurch mobil)

Gruß
David

[Andreas S. (igel1)]

David D. schrieb:
> Andreas S. schrieb:
>> Wenn man die Frame-Ausgabe von Davids MC-Programm per Realterm (also
>> nicht mit Davids PC-Programm) mit gemütlichen 115200 baud empfängt und
>> die Daten von Realterm direkt in eine Datei umleiten lässt, kommt dann
>> ein korrektes Bild dabei heraus?
>>
>> Will sagen: hat David schon sein PC-Programm als mögliche Fehlerursache
>> ausgeschlossen?
>>
>> Viele Grüße
>>
>> Andreas
> Nein habe ich nicht, ich dachte, das hättest du mit dem Beweisbild.
> Bis Mittwoch (oder vlt. zwischendurch mobil)

Meinst Du mit "Beweisbild" das Bild aus diesem Posting:
Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)"  ?

Wenn ja, so beweist das leider nur, dass Dein PC-Programm teilweise 
funktioniert, denn es bricht ja immer nach X Zeilen ab.

Ich würde an Deiner Stelle das PC-Programm als Fehlerquelle erst einmal 
ausschließen, indem Du die Daten erst einmal mit Realterm in einer Datei 
auffängst. Mit meiner weiter oben erwähnten Website, kannst Du Dir diese 
Datei dann anzeigen lassen.

Wenn dabei Müll herauskommt => Bug im MC-Programm.

Außerdem würde ich den FiFo mehrfach auslesen und die per Realterm 
geschriebenen Dateien alle miteinander vergleichen.
Wenn nicht identisch => Bug im MC-Programm.

Sodann würde ich an vielen Stellen noch 20us delay einschieben, um das 
RCK-Signal etwas symmetrischer zu machen (nur so ein Bauchgefühl). Ich 
würde nicht in einem Befehl RCK=LOW und im nächsten Befehl direkt 
RCK=HIGH setzen (oder umgekehrt), sondern stets min. 20us Päuschen 
dazwischen spendieren.

Insgesamt würde ich sowieso eher den Timer-Ansatz bevorzugen und RCK 
gleichmäßig durchlaufen lassen. Ob das des Rätsels Lösung ist, kann ich 
Dir allerdings auch nicht versprechen.

> Die ist relativ "einfach" gehalten:
> es geht los in der main.c  case 0x0C:
>
> OV7670_captureNewImage();
> OV7670_ResetFifoReadPointer();
> sendFrameBufferToUART (width, height, BytesPerPixel);
>
> alle drei Funktionen aus der Datei: OV7670_withFifo.c
> Die Namen sind denke ich selbsterklärend.

Habe mir alle 3 Funktionen mittelgrob (d.h. nicht ganz oberflächlich, 
aber auch nicht ganz haarklitzeklein) angeschaut und keine direkten 
Fehler gefunden.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> ??
> Willst Du sagen, dass das Bild aus Deinem letzten Posting von der
> OV7670-Camera stammt?

ja sicher....
Ich schmeiße die Arduino-UNO-Hardware bald aus dem Fenster...
Der Mega16U2 als USB-seriell-Wandler macht da definitiv Mist, der CH340 
auf dem nano hatte die Probleme nicht. Ich will aber meinen Adapter 
nicht umlöten!!!
Das mit /OE hatte ich aus seinen Sourcen, ich muß die Pinzuordnung 
soweiso durch meine ersetzen, ich habe die Pins etwas anders verteilt.
Ich weiß im Moment noch nicht, wie ich mit Davids Source weiter vorgehe.
Entweder ich mache seine UART-Routinen auf dem AVR neu und anders, mit 
seinem terminal kompatibel zu beliben sollte nicht das Problem zu sein, 
mir ist das irgendwie zu instabil und nicht immer reproduzierbar, was da 
passiert.
SCCB scheint ja soweit zu spielen. Mich stört im Moment, daß ich nicht 
einfach ein Bild anfordern kann, VGA geht soweiso nicht wegen der 
Fifogröße, QVGA mit RGB565 und QVGA mit YUV und nur Y senden wären 
brauchbare Voreinstellungen. Ich werde mal meine Registersettings in 
sein Terminal laden und schauen, ob es Bilder ergibt, das geht ja jetzt 
als Struktur einfach.

Dazu muß aber das Fifo übertragen zuverlässig sein. Ich lese ja bei mir 
immernoch mit TeraTerm ein, speichere binär und lasse es mir von 
Irfanview anzeigen. Registerdaten sind nur im AVR-Source, compilieren 
und neu flashen dauert ja nicht lange, egal ob AVR-Studio oder 
ArduinoIDE.

Mal im Laufe des Tages in Ruhe drüber nachdenken...

so, inzwischen ist etwas mehr Licht in der Ecke, also noch ein Bild der 
OV7670 mit meiner Software.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> Hallo,
>
> Andreas S. schrieb:
>> ??
>> Willst Du sagen, dass das Bild aus Deinem letzten Posting von der
>> OV7670-Camera stammt?
>
> ja sicher....
> Ich schmeiße die Arduino-UNO-Hardware bald aus dem Fenster...
> Der Mega16U2 als USB-seriell-Wandler macht da definitiv Mist, der CH340
> auf dem nano hatte die Probleme nicht. Ich will aber meinen Adapter
> nicht umlöten!!!

Hmmm - Mist, das ist wirklich ärgerlich.
Ich kann Dich da gut verstehen.

> Das mit /OE hatte ich aus seinen Sourcen, ich muß die Pinzuordnung
> soweiso durch meine ersetzen, ich habe die Pins etwas anders verteilt.

Okay.

> Ich weiß im Moment noch nicht, wie ich mit Davids Source weiter vorgehe.
> Entweder ich mache seine UART-Routinen auf dem AVR neu und anders, mit
> seinem terminal kompatibel zu beliben sollte nicht das Problem zu sein,
> mir ist das irgendwie zu instabil und nicht immer reproduzierbar, was da
> passiert.

... hier hat's Deinen Satz irgendwie zerwürfelt ...

> SCCB scheint ja soweit zu spielen. Mich stört im Moment, daß ich nicht
> einfach ein Bild anfordern kann, VGA geht soweiso nicht wegen der
> Fifogröße, QVGA mit RGB565 und QVGA mit YUV und nur Y senden wären
> brauchbare Voreinstellungen.

Yep - sollte aber kein Akt sein, dies in Davids Code umzustellen.
Das wäre sowieso mein Ansatz: erst einmal nur ein schnödes QVGA 
RGB565-Bild aus dem FiFo auslesen - mit fixen Register-Settings.
Erst wenn das zuverlässig funktioniert, würde ich weitermachen.

Kurzum: Reduktion auf das Minimum, um maximal viele Fehlerquellen zu 
eliminieren.

> Ich werde mal meine Registersettings in
> sein Terminal laden und schauen, ob es Bilder ergibt, das geht ja jetzt
> als Struktur einfach.
>
> Dazu muß aber das Fifo übertragen zuverlässig sein. Ich lese ja bei mir
> immernoch mit TeraTerm ein, speichere binär und lasse es mir von
> Irfanview anzeigen.

Bevor ich lange suche: wie läßt Du Dir mit Irfanview ein QVGA 
RGB565-Bild, welches in einer Datei ohne jeglichen Header liegt, 
anzeigen?

> Registerdaten sind nur im AVR-Source, compilieren
> und neu flashen dauert ja nicht lange, egal ob AVR-Studio oder
> ArduinoIDE.
>
> Mal im Laufe des Tages in Ruhe drüber nachdenken...

Darum beneide ich Dich wirklich. Aktuell kann ich mir noch nicht einmal 
vorstellen, meine Rente lebend zu erreichen ...

> so, inzwischen ist etwas mehr Licht in der Ecke, also noch ein Bild der
> OV7670 mit meiner Software.

Sehr schön, Michael!
Die Bilder sind so gut, dass man vermutlich tatsächlich mit einfacher 
Bildverarbeitung die Uhrzeit daraus ablesen könnte :-)
KI soll dafür ja superfesch sein ...

Nochmals zurück zu David's Problemen: wenn ich noch ein zusätzliches 
OV7670+AL422B-Modul hätte, wäre meine Hemmschwelle zum Ausprobieren 
seines Codes auf meinem Arduino Nano deutlich niedriger.

Aber ohne zweites Modul schrecke ich wirklich vor der stundenlangen 
Kabellitis zurück (denn der LogicAnalyzer will ja auch noch verkabelt 
sein). Und mit dem Dragon habe ich auch noch nichts gemacht (wenngleich 
er hier rumliegt) und mein AVR-Studio ist auch mehrere Jahre nicht mehr 
geupdated worden und Plattenplatz habe ich auch irgendwie nicht mehr ...
Soll ich mir das wirklich alles antun, wo ich doch so schöne ARM-Boards 
hier rumliegen habe? Hmmm, ich weiß nicht, ich weiß nicht ...

Ich glaube, ich setze einfach auf Dich, Michael, dass Du David's Fehler 
findest - ist deutlich bequemer für mich ;-)

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Bevor ich lange suche: wie läßt Du Dir mit Irfanview ein QVGA
> RGB565-Bild, welches in einer Datei ohne jeglichen Header liegt,
> anzeigen?

Datei->Öffnen als-> RAW-Datei
Im Requester dann eben Größe einstellen, Header auf 0 Bytes, Format 
16BPP, 5:6:5, Big Endian, Interleaved und ok.
Oder eben 8BPP für nur Y.
Wenn die Datei .raw heißt und man sie Irfanview als default zuweist, 
kann man auch einfach doppelklicken und der Requester kommt sofort und 
man muß nur OK klicken.

Andreas S. schrieb:
> Die Bilder sind so gut, dass man vermutlich tatsächlich mit einfacher
> Bildverarbeitung die Uhrzeit daraus ablesen könnte :-)
> KI soll dafür ja superfesch sein ...

kein Problem. Habe ja erst 1148 Byte des 32k Flash belegt........

Mein AVR-Studio ist die 4.18, der GCC der WinAVR-20100110, na und? ;-)
Plattenplatz? Soll ich Dir ein paar TB abgeben? Mein Bekannter baut 
öfter mal sein Datengrab um und dann landen bei mir meist die kleinen 
Platten, de er ausgebaut hat. Im Moment sind wohl seine letzten 
3TB-Platten bei mir gelandet... Er möge mir also noch lange erhalten 
bleiben. :-))

LA hänge ich meist erst ran, wenn ich mir einbilde, keinen Fehler in den 
Sachen drinzuhaben. Ein 8Bit-AVR ist gut überschaubar und auch der alte 
GCC optimiert die IO-Sachen da schon (fast) perfekt.

Ich habe jetzt einfach mal angefangen, den UART-Kram umzubauen, keine 
Ahnung, ob David dann noch mit mir redet... ;-)

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> Datei->Öffnen als-> RAW-Datei
> Im Requester dann eben Größe einstellen, Header auf 0 Bytes, Format
> 16BPP, 5:6:5, Big Endian, Interleaved und ok.

Danke für den Tipp!

Ich wusste gar nicht, dass beim Öffnen von *.raw ein Dialog erscheint. 
Passt alles - aber bei mir fehlt ein Auswahlfeld für "Big Endian" und 
entsprechend geht die Sache schief.

Hast Du tatsächlich dieses Auswahlfeld?
Welche Irfanview-Version hast Du?

Evtl. muss ich ja noch ein Plugin installieren.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Welche Irfanview-Version hast Du?
>
> Evtl. muss ich ja noch ein Plugin installieren.

bis eben die 4.44 64Bit, gerade auf die 4.52 64Bit update gemacht.
PlugIn-Paket muß installiert sein und zur version passen.
https://www.irfanview.com/

Der Haken ist noch da.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hallo Michael,

in der Tat: es lag an der Irfanview-Version (obwohl die bestimmt noch 
gar nicht sooo alt war: 4.34**).

Seit meinem Upgrade auf die neueste Version (ich habe die 32-bit Version 
installiert, um die TWAIN-Schnittstelle meines Druckers weiterhin nutzen 
zu können), ist auch der Haken für Big-Endian-Auswahl da. Der fehlte 
vorher noch.

Ohne Deinen Hinweis hätte ich also stets gedacht, dass Irfanview mir 
nicht helfen kann. Danke also vielmals für den Tipp!

Viele Grüße

Igel1

PS:  ** Schock im Nachgang: Revision-History von Irfanview sagt, dass 
Version 4.34 im Jahr 2012 n.Chr. rauskam - as time goes by ...

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> PS:  ** Schock im Nachgang: Revision-History von Irfanview sagt, dass
> Version 4.34 im Jahr 2012 n.Chr. rauskam - as time goes by ...

:-))) Irfanview ist eins der sehr wenigen Programme, wo ich ab- und zu 
freiwillig nach aktuellen Versionen schaue. Immernoch recht klein und 
handlich, kann verdammt viel dafür und hat mich noch nie im Stich 
gelassen.

Gruß aus Berlin
michael

[Tom (Gast)]

Michael U. schrieb:
> ist mir bisher nicht gelungen... FM6126A
Schau mal, ob das passend ist:
Beitrag "Chinesische IC und ihre Verwandschaft"

[Andreas S. (igel1)]

... mir fehlt David - schnief - hoffentlich ist bald Mittwoch ...

Viele Grüße

Igel1

[Andreas S. (igel1)]

Also: bin gerade dabei, Davids Schaltung nachzubauen ...

Ja, ja - keine Ahnung, ist wohl ein Helfersyndrom gemäß:
"Watt tu'se nich alles, um de Jong zu helfen?!

Da ich AVR-mäßig allerdings ziemlich eingerostet bin, hier ein paar 
Fragen, bei denen Ihr bitte nicht zu hart mit dem Kopf auf der 
Tischkante aufschlagen möchtet:

- Wie lade ich Davids Programm am einfachsten in den Nano?
  Reicht dafür das USB-Kabel, oder muss ich den AVR-Dragon
 (den ich bislang noch nie benutzt habe) anschließen?

- Wenn ich den Dragon anschließen muss/soll, dann: wie?

- Mit welchem Programm sollte ich David's Projekt kompilieren
  und auf den Nano flashen (optimalerweise mit Null
  Code-Anpassungen)? Vermutlich mit dem neuesten
  AVR-Studiomonster, stimmt's?

Okay, ich gebe zu: ich bin etwas googlefaul, aber ich gebe zu: so 
richtig "heiß" bin ich auf diesen Retro-Ausflug in die 8-Bit-Welt nicht.
Ich befürchte daher, dass ich etwas "Anschubmotivation" in Form von ein 
paar Antworten auf die Fragen oben von Euch benötige  ...  (gerne auch 
in Form von ein paar guten Links).

Außerdem bedeutet es, dass ich 20 Kabel von meiner Kamera neu verdrahten 
muss (und später dann wieder Rolle rückwärts an den STM32 anstecken 
darf).

Macht schon mal das Bundesverdienstkreuz für mich klar ...

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Also: bin gerade dabei, Davids Schaltung nachzubauen ...
>
> Ja, ja - keine Ahnung, ist wohl ein Helfersyndrom gemäß:
> "Watt tu'se nich alles, um de Jong zu helfen?!

warum denke ish sowas auch gerade?!?!?

Andreas S. schrieb:
> - Wie lade ich Davids Programm am einfachsten in den Nano?
>   Reicht dafür das USB-Kabel, oder muss ich den AVR-Dragon
>  (den ich bislang noch nie benutzt habe) anschließen?
USb-nutzt Dir nur as für die serielle, ansonsten den "Drachen".

> - Wenn ich den Dragon anschließen muss/soll, dann: wie?
6-pin Verbinder hinten quer auf dem Nano und auf dem Dragon auf ISP, 
Verbindung ist 1:1. Falls Du 6-Pin Quetschbuchsen hast und 
Flachbandkabel....

Andreas S. schrieb:
> - Mit welchem Programm sollte ich David's Projekt kompilieren
>   und auf den Nano flashen (optimalerweise mit Null
>   Code-Anpassungen)? Vermutlich mit dem neuesten
>   AVR-Studiomonster, stimmt's?
Wenn Du es relativ einfach haben willst, nimm das uralte AVR-Studio 4.18
https://www.microchip.com/mplab/avr-support/avr-and-sam-downloads-archive
Bis fast ans Ende der Welt runter scrollen, ich glaube, Du brauchst alle 
4 Files, das Studio und die SPs. Unter Win7 geht es völlig problemlos, 
unter 10 sollte es auch noch gehen.
Dazu den antiken WinAVR:
https://sourceforge.net/projects/winavr/files/WinAVR/20100110/
Den WinAVR bitte in seinen Wunschordner auf C:/ installieren...
Ich glaube, wenn man WinAVR zuerst installiert, erkennt ihn AVR-Studio 
beim Installieren allein, das können wir aber noch klären.

Geht eigentlich alles problemlos zu installieren mit den 
default-Angaben.
Wenn Du dann das AVR-Studio startest une New Project öffnset, sieht 
gleich, ob er Dir außer AVR-Assemblaer auch AVR-GCC anbietet.
Wenn Du bis dahin kommst sehen wir weiter.....

Andreas S. schrieb:
> Außerdem bedeutet es, dass ich 20 Kabel von meiner Kamera neu verdrahten
> muss (und später dann wieder Rolle rückwärts an den STM32 anstecken
> darf).

Was sind schon 20 Dupont-Strippen??? Mehr als 19 haben doch gleichzeitig 
sowieso nie Kontakt. ;-)

Das Studio sollte auch den Treiber für den Dragon mitinstallieren 
(Jungo-Treiber).

Andreas S. schrieb:
> Macht schon mal das Bundesverdienstkreuz für mich klar ...

Geht auch ein Aktivisten-Orden? Der müßte hier noch irgendwo 
rumliegen...

PS: AVR-Kram belegt kanpp 200MB, der WinAVR gut 150MB.

Gruß aus Berlin
Michael

[Michael U. (amiga)]

Hallo,

so, Kurzfassung meines Standes mit Davids Sourcen:
main.c, OV7670_with_Fifo.c und .h, SCCB_old.c und h sowie uart.c und h 
in ein AVR-Studio-Projekt geworfen.
Dragon ausgebuddelt, rangesteckt und einen Arduino UNO zum Mega328 
"degradiert", also Bootloader runter, Fuses angepasst.
In OV7670_with_Fifo.h die Pins an meine Verteilung angepasst und in 
uart.h die Baudrate auf 230400 gesetzt.
Meldet sich auch in seinem Terminal, zumindest manchmal/meistens.
Dann beschlossen, das alles erstmal wegzulassen, zu seinem Terminal 
müßte ich mir erst einen seriellen Sniffer installieren, um sein 
Protokoll rauszufinden, also welches Kommando sendet was und wieviele 
Bytes in welchem Format (offenbar alles binär) und welche Antwort wird 
erwartet usw.
Da ich seine UART-Routinen auch nicht auf Anhieb durchschaut habe, 
beschlossen, das alles vorerst zu ignorieren...
uart.c umgebaut, TX-Interrupt aus, Senden im Busy-Loop. Seinen 
Bildersende Aufruf in die main7while(1) rein, Kommandoauswertung 
auskommentiert und nur endlos mit 30s Abstand Bild geholt und 
rausgeschickt.
Andres S.: falls Du den alten AVR-Kram beutzt: _delay_ms() kann da noch 
keine langen Zeiten, also

  for (uint8_t i = 0; i < 20; i++)
  {
    _delay_ms(1000);
  }

benutzen für längere Wartezeiten. Ich hatte kurz überlegt, ob ich das 
aktuelle GCC-Paket installiere, aber keine Lust, da man da ein paar 
Sachen passend basteln muß...

Zumindest kamen jetzt alle 20s meine 153600 Bytes an. height = 320 habe 
ich erstmal wieder gesetzt. Bildinhalt der Daten war irgendwas, aber 
reproduzierbar.

Kurzerhand meine Init-Strukturen in seine main geworfen und die Kamera 
nach seinem OV7670_init(); mit meinen Registerwerten initialisiert.
Das Ergebnis hängt oben dran.

Darüber kann ich jetzt erstmal in Ruhe nachdenken, ich ahbe auch an ein 
paar Stellen in OV7670_with_Fifo.c noch was von ihm auskommentiert, das 
muß ich jetzt erstmal vergleichen bzw. rückgängig machen.
Seine SCCB-Sachen laufen auf jeden Fall erstmal ohne Änderungen und 
Probleme, die OV7670_with_Fifo.c wohl auch.
Mit seinen UART-Routinen bekomme ich irgendwie immer nur um die 15xxx 
Byte, warum auch immer.
Warum mit meinen Init-Daten kein vernünftiges Bild rauskommt weiß ich 
auch noch nicht.

Gruß aus Berlin
Michael

[David D. (saturi)]

Hallo! Ich bin zurück! freut mich, dass ihr am Ball geblieben seid und 
mir weiterhin helfen wollt!
Heute Abend/Nachmittag habe ich wieder Zeit und werde mich in aller Ruhe 
mit euren Beiträgen auseinander setzten.

@Igel wenn dir der Speicherplatz auf dem Rechner erstmal nicht allzu 
wichtig ist, würde ich dir einfach empfehlen das neuste Atmel stuido zu 
ziehen. Dann brauchst du dich um den Kram wie GCC etc. garnicht erst 
kümmern. Dann läuft auch der Dragon Plug'n'Play.
Bis später!

Mir juckts schon in den Fingerspitzen

Gruß

David

[Andreas S. (igel1)]

Hi Leute,

habe das neueste AVR-Studio installiert (mein schöner Plattenplatz - 
schnief ...).

Heute Abend werde ich mich dann wohl erst einmal mit dem AVR-Dragon 
beschäftigen dürfen: habe ihn hier im Forum gebraucht gekauft und er kam 
nur mit einem 10-adrigen Stecker.

Ich hoffe, ich kann diesen Stecker versetzt auf die Pfostenleisten an 
beiden Ende aufsetzen, ohne mir einen neues Kabel basteln zu müssen 
(denn dafür fehlt mir gerade das Zeugs).

Hauptsache Michael löst nicht alle Probleme, bevor ich überhaupt das 
erste Byte auf meinen Nano geschoben habe ;-)

Muss ich eigentlich vorab noch irgendetwas mit dem Nano veranstalten? 
(Bootloader platt machen? Fuses verbiegen? Beschwörungssprüche 
drüberhauchen?)

Viele Grüße

Igel1

[David D. (saturi)]

ich kann dir heute abend ein foto von meinem schicken.

nein, wenn du einfach vom studio aus flashest ist halt der Bootloader 
fürs erste Weg und du wirst die Arduino suit damit nicht mehr benutzten 
können, bis du wieder den Bootloader dafür falshest. An den Fuses musst 
du meines wissens nichts ändern. Nur in den Debug mode kannst du mim 
Nano nicht, weil du dich dann aussperrst. (Aber das wäre eben eine 
solche Fuse die man setzen müsste, also solange du da nichts machst kann 
eig. nichts passieren

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Hallo! Ich bin zurück! freut mich, dass ihr am Ball geblieben seid und
> mir weiterhin helfen wollt!
Schö wieder von Dir zu hören.

Andreas S. schrieb:
> habe das neueste AVR-Studio installiert (mein schöner Plattenplatz -
> schnief ...).
Du hast es so gewollt... ;-))

Andreas S. schrieb:
> Hauptsache Michael löst nicht alle Probleme, bevor ich überhaupt das
> erste Byte auf meinen Nano geschoben habe ;-)
Mit Sicherheit nicht, ich mache auch nur mal 'ne Stude oder so was, es 
sei denn, hier geht gerade die Post ab.

Ich muß meinen Salat jetzt erstmal aufräumen, irgendwo habe ich bei 
meinem Sketch jetzt erstmal was durcheinander gebracht...
Ich will jetzt erstmal Dvids Sourcen mit nur den nötigsten Änderungen, 
meinen Arduino-Sketch und die im AVR-Studio compilierte Version dazu 
überreden, mir alle 20s ein RGB565-Bild bzw. den Farbbalken zu schicken.

10-pol. sollte machbar sein wenn auf dem Dragon nicht alle Steckleisten 
bestückt sind, beim Nano ist ja nach beiden Seiten Platz. Zur Not sind 
es eben 6 Dupont-Strippen mehr.....

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Noch eine kleine Frage in die Runde:

Wie versorgt Ihr Kamera und Level-Shifter mit Strom?

Lese gerade, dass der Original-Nano nur 50mA Belastbarkeit an seinem 
3,3V-Ausgangspin hat.

Muss ich jenseits von USB noch eine Stromversorgung für das Steckbrett 
aufbauen?

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

so, kurzer Nachtrag: Ordnung soweit gemacht.
Änderungen in Davids Source:
- uart.c - eigene Senderoutine ohne Interrupt, keine Empafamgsroutine
- main c - Kommandoauswertung auskommentiert, nur

while (1) 
{
  OV7670_captureNewImage();
  OV7670_ResetFifoReadPointer();
  sendFrameBufferToUART (width, height, BytesPerPixel);

  for (uint8_t i = 0; i < 20; i++)        //############## 20s warten
  {
    _delay_ms(1000);
  }
}

- main.c meine Register daten incl. Registersetzen eingefügt und nach 
seinem
OV7670_init(); aufgerufen.
So kommt alle 20s ein RGB565 Bild als RAW-Daten an.
Seltsamerweise kommen seine Daten Little Endian an????

Erstmal reicht es mir. ;-)
Bild ist auch "ok", ist aber zu dunkel in der Ecke für die 
Einstellungen.

Gruß aus Berlin
Michael

[David D. (saturi)]

Hi Michael,

vielen Dank für deine Mühen, das werde ich mir jetzt anschauen.
Ich habe soeben die Lötarbeiten fertig gestellt und siehe da! ich 
bekomme zuverlässig die gleiche Colorbar, auch nach mehrmaligem 
auslesen. Deaktiviere ich diese bekomme ich aber kein Bild sondern kann 
höchstens die Lampe sehen, wenn ich sie direkt davor halte. Ist aber 
auch logisch, weil ich noch keine Settings reingeladen habe.

Jetzt schaue ich mir mal an, was du Michael mit meinem Code 
veranstalltet hast und schaue auch mal, ob eure Registersettings von vor 
einigen Tagen/Wochen bei mir funktionieren ;-)

Dieser miese Wackelkontakt hat echt zu unglaublichen Sachen geführt 
:D...

@Igel ich habe so eine Spannungsversorgung fürs Steckbrett, die 3,3 und 
5V kann. Und jetzt mit Entwicklershield eben auf dem Uno, der ja 5V hat.

anbei ein Bild der Colorbar, meines neuen Testobjektes ;-) und dem 
Dragon für dich zur Veranschaung. Ich habe meinen in ein Gehäuse 
eingebaut und in meinem Unwissen alle Anschlüsse nach außen geführt, was 
im Nachhinein betrachtet nicht so clever war. Aber der ISP stecker ist 
blau markiert. Ist der 6er Stecker in der Mitte

[Tom (Gast)]

David D. schrieb:
> Dieser miese Wackelkontakt hat echt zu unglaublichen Sachen geführt
Ich sage immer:
Für über 90% aller Fehler in der Elektronik ist eine defekte Verbindung 
die Ursache.

[Michael U. (amiga)]

Hallo,

ok, das Problem mit der anderen byteorder hat sich für mich erstmal 
geklärt,

for(int ByteNumber =0; ByteNumber < BytesPerPixel; ByteNumber++)
{
  OV_RCK_PORT |= (1<<OV_RCK_PinNo);

  UART0_senden_Byte(Ov7670_readByte());
        
  OV_RCK_PORT &= ~(1<<OV_RCK_PinNo);
}

Du setzt RCK auf H und liest dann die Daten. TOH ist aber nur wenige ns, 
min. 4ns. Da der Fifo sehr schnell ist, liest Du sehr wahrscheinlich 
nicht das gewünschte, sondern schon das nächste Byte.

for(int ByteNumber =0; ByteNumber < BytesPerPixel; ByteNumber++)
{
  OV_RCK_PORT &= ~(1<<OV_RCK_PinNo);

  UART0_senden_Byte(Ov7670_readByte());

  OV_RCK_PORT |= (1<<OV_RCK_PinNo);      
}

macht es bei mir richtig rum. Da sind Timingprobleme zwischen Fifo und 
und dem "lahmen" AVR wohl schuld.
Ich habe jetzt keine Lust, den LA ranzuhängen und zu schauen, wann der 
Datenwechsel im Verhältnis zur RCK Flanke passiert, außerdem sind da die 
80MHz Samplerate meines LA sowieso zu langsam...

Gruß aus Berlin
Michael

[David D. (saturi)]

Das ist jetzt interessant.
Wenn ich jetzt meine routine so änder wie von dir vorgeschlagen, erhalte 
ich die Colorbar, die du vorher hattest :D

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Wenn ich jetzt meine routine so änder wie von dir vorgeschlagen, erhalte
> ich die Colorbar, die du vorher hattest :D

Und wenn Du mir jetzt noch sagst, welche ich vorher hatte... ;-)
Die aus dem Post von Datum: 20.02.2019 17:30 ist die richtige.
weiß-gelb-cyan-grün-magenta-rot-blau-schwarz ist richtig, der 
Standard-Farbbalken.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hi Leute,

ich hab's geahnt: Michael hat alle Probleme gefixed, bevor ich das erste 
Byte auf mein Arduino-Nano Board geschoben habe ...

Nach ein paar Anlaufschwierigkeiten mit dem ISP-Kabel, hat das Flashen 
gerade erstmals funktioniert - hurra.

Natürlich erst kurz nachdem Michael den Timing-Bug gefunden hat - so'n 
Mist, den hätte ich auch gern gefunden ...

Bevor ich jetzt die Kamera dranklemme, möchtet Ihr beide mir bitte 
nochmals genauer beschreiben, wie Ihr das Board mit Strom versorgt 
(sowohl Michael als auch David). Wie versorgt Ihr den Nano, die 
Level-Shifter (beide Seiten: 3,3V und 5V interessieren mich) und wie die 
Kamera?

Benutzt Ihr dafür etwa so eine Steckbrett-Versorgung wie unten rechts im 
Bild dargestellt?

Viele Grüße

Igel1

[David D. (saturi)]

Hallo Igel!
Freut mich riesig, dass du diese Bürde auf dich genommen hast. Ich kann 
dich beruhigen. Es ist noch lange nicht alles gefixed.

Ich habe mir jetzt mal auf die beiläufige Erwähnung von Michael, dass es 
com swiffer gibt, so ein Tool geladen und sehe, dass es nicht ganz 
meinen Erwartungen entspricht, bzw. Der uC aus irgendwelchen Gründen 
nicht weiter macht.

Zur Stromversorgung. (Ich kopiere einfach nochmal von oben ;-) )

"@Igel ich habe so eine Spannungsversorgung fürs Steckbrett, die 3,3 und 
5V kann. Und jetzt mit Entwicklershield eben auf dem Uno, der ja 5V 
hat."

Also zuvor auf meinem steckbrett habe ich die steckbrettversorgung mit 
ext. Netzteil genutzt und jetzt betreibe ich den uno nur noch per USB 
und greife von dort die 3,3 und 5v ab

[Andreas S. (igel1)]

David D. schrieb:

> Hallo Igel!
> Freut mich riesig, dass du diese Bürde auf dich genommen hast. Ich kann
> dich beruhigen. Es ist noch lange nicht alles gefixed.

Nu freu Dich mal nicht zu früh: ich kann am kommenden Wochenende
nicht mitmachen und Michael schickt sich gerade an, keinen Bug mehr
für mich übrig zu lassen.

> Zur Stromversorgung. (Ich kopiere einfach nochmal von oben ;-) )

Das hatte ich durchaus gelesen, aber eben nicht richtig verstanden.

> "@Igel ich habe so eine Spannungsversorgung fürs Steckbrett, die 3,3 und
> 5V kann. Und jetzt mit Entwicklershield eben auf dem Uno, der ja 5V
> hat."

Nun habe ich es zum 2. Mal nicht richtig verstanden ...

> Also zuvor auf meinem steckbrett habe ich die steckbrettversorgung mit
> ext. Netzteil genutzt und jetzt betreibe ich den uno nur noch per USB
> und greife von dort die 3,3 und 5v ab

Vielleicht stehe ich etwas auf der Leitung daher nochmals konkret 
gefragt:

- Meinst Du mit "Steckbrettversorgung" so etwas wie rechts unten auf
  meinem Bild aus meinem letzten Posting?

- Wirft Dein Entwicklershield (welches hast Du?) 3,3V und 5,0V raus?

- Den 3,3V-Ausgang des Uno-Boards hast Du nicht genutzt, oder?
  (... denn der kann ja nur 50mA liefern)

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> - Den 3,3V-Ausgang des Uno-Boards hast Du nicht genutzt, oder?
>   (... denn der kann ja nur 50mA liefern)

die 3,3V vom Nano reichen für die Kamera eigentlich aus, auch mit em 
FiFo.
Der AMS1117 auf dem Nano kann weit mehr, es wird ihm aber dann zu warm 
wegen der geringen Kühlfläche. Vusb geht über eine Schottkydiode an den 
Reglereingang, an üblichen USB-Ports sieht der also meist nur um 4,7V. 
Kannst Du ja am 5V Pin des Nano messen, was da bei USB wirklich anliegt.
Pegelwandler 5V vom 5V Nano-Pin, 3,3V und Kamera am 3,3V Pin.
Pegelwandler habe ich in den zur Kamera gehenden Leitungen, also SDA, 
SCK, RST, also was direkt zur OV7670 geht. Der Fifo hat sowieso 5V 
tolerante Eingänge.
Der UNo hat meist einen LP2985-33 drauf, der kann auch max. 150mA, kann 
aber eben auch thermische Probleme bekommen.
Bei gehen beise Varainten ohne erkennbare Probleme, Spannung eben normal 
vom USB-Port.

Ich habe mich gestern Abend irgendwie an "Processing" erinnert. Das ist 
eine Java-Geschichte im Arduino-Stile und habe es mal angeworfen.
Hmmmmm, wenn ich da durch die Funktionen usw. etwas durchgestiegen bin, 
habe ich da vermutlich in kruzer Zeit eine "Software", die die RAW-Daten 
vom Mega einliest und als Bild in ein Fenster pinselt.
Kann man einfach irgendwo hinwerfen und die .exe starten, 260MB tragen 
auch nicht so auf. :)

Ich werden an der OV7670 Software ohnehin jetzt nur was machen, wenn 
David "um Hilfe" schreit.
Ich kann bei Bedarf auch meine geänderte main.c und uart.c auch hier mal 
reinhängen.
Genauso auch meine Software, ist in einem kompletten .c File, läßt sich 
also auch problemlos in ein Studio-Projekt werfen.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

@Michael:  Danke für die Mühen, die Du Dir da mit Deiner ausführlichen 
Email zum Thema Stromversorgung gemacht hast!

Dann also Augen zu und durch: ich werde den Nano per USB-Kabel direkt 
vom Rechner aus versorgen und schließe alles andere an die Pins 5V und 
3,3V des Nano an.

Sollte das schief gehen, so habe ich noch einen Ersatz-Nano hier in der 
Tüte gefunden. Ihr werdet mich also so schnell vermutlich nicht los ...

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Sollte das schief gehen, so habe ich noch einen Ersatz-Nano hier in der
> Tüte gefunden. Ihr werdet mich also so schnell vermutlich nicht los ...

kannst ja einfach mal den Finger auf den Spannungsregler des Nano legen, 
wäre das einzige kritische Bauteil bei der Geschichte.

PS: meine ESP32-Espessif jungs waren auch fleißig. Endlich mal das 
aktuelle CamWebserver angepast und auf mein Cam-Modul geflasht.
Da muß ich mal mit rumspielen und schauen, was die da jetzt alles in die 
Lib für die Kameramodule gepackt haben.
Bild vom Webinterface mit Einzelbild in voller Auflösung in bekannter 
ziemlich schlechter Beleuchtung.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> PS: meine ESP32-Espessif jungs waren auch fleißig. Endlich mal das
> aktuelle CamWebserver angepast und auf mein Cam-Modul geflasht.

Meinst Du das "Cam-Modul": siehe Anhang ?

Das habe ich mir wegen Deiner positiven Bewertung in einem anderer 
Thread ebenfalls gekauft.

VG
Igel1

[Andreas S. (igel1)]

By the way: habe den ganzen Schmodder inzwischen verdrahtet: 2h 
Wurschteln. Ist ein fliegender, recht wackeliger Verhau geworden.
Bin dabei blind vertrauend nach David Schaltplan vorgegangen (nur OE 
habe ich fix auf GND gelegt).

@Michael: Ich würde nun zum Testen sehr gerne Deine Modifikationen von 
Davids Programm haben. Dann weiß ich zumindest, dass mein Drahtverhau 
passt, wenn ein Colorbar-Bild hinten rauskommt.

Bitte nur diejenigen Dateien hier einstellen, die sich von Davids 
Programm unterscheiden - dann würde ich diese Dateien schnell mal 
temporär tauschen und so die Schaltung testen.

Bleibt noch eine dumme Frage (bin zu müde, das nachzuprüfen - seht's mir 
nach):

Die Daten kommen seriell über die USB-Schnittstelle via virtuellem 
seriellem Port raus, stimmt's? Oder muss ich noch einen 
USB->RS232-Wandler irgendwo drankleben?

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Meinst Du das "Cam-Modul": siehe Anhang ?
ja, genau dieses. Da ist mir gestern noch was seltsames aufgefallen, was 
das Kamera-Modul selbst betrifft. Das muß ich mir aber erst genauer 
anschauen.

Andreas S. schrieb:
> Bitte nur diejenigen Dateien hier einstellen, die sich von Davids
> Programm unterscheiden - dann würde ich diese Dateien schnell mal
> temporär tauschen und so die Schaltung testen.
Wenn ich beim letzten Sortieren kenen Mist gebaut habe, passt es so.
Ich habe meine Eingriffe mit Kommentaren verziert, die  mit //######### 
beginnen.
UART steht auf 23400, alle 20s kommt ein RGB565 Bild.

Die Daten kommen seriell über die USB-Schnittstelle via virtuellem
seriellem Port raus, stimmt's? Oder muss ich noch einen
USB->RS232-Wandler irgendwo drankleben?
Kommen über USB, sollte beim Anstecken des Nano eine COM auftauchen wenn 
Du den Treiber drauf hast, meine Nano haben alle einen CH430 drauf.

Lassen wir uns mal überraschen.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

@Michael: Danke für die Starthilfe!

Damit konnte ich direkt den Funktionstest machen, der das Bild im Anhang 
ergab (allerdings Little Endian).

Fazit: kein Verkabelungsfehler (puhhh) - nicht zuletzt Dank David's 
sauberem Schaltplan.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Damit konnte ich direkt den Funktionstest machen, der das Bild im Anhang
> ergab (allerdings Little Endian).

schön. Wieder ein Spielzeug mehr. ;)

Byteorder: mein Post vom Datum: 20.02.2019 21:04

PS. heute die 64x64 LED-Matrix von der Post geholt, siehe oben der 
Uhr-Kram...

Gruß aus Berlin
Michael

[David D. (saturi)]

GUten Abend... endlich Feierabend, endlich Wochenende nach einer 
turbolenten Woche. Gleich nur noch der Tanzkurs zu dem ich genötigt 
werde und dann habe ich auch schon wieder die halbe Nacht und den 
Sonntag zeit, um mich meinem Lieblingsthema zu widmen. Juhu!


Dann mische ich wieder mit :)

Freut mich, dass wir alle wieder auf Hardware laufen und Michael ein 
Spielzeug für die Zwischenzeit gefunden hat :D
Bis später!

[Andreas S. (igel1)]

Hier eine Kleinigkeit:

Ich schaue mir gerade Davids Routine "UART0_init (void)" an.
Dabei fällt mir auf, dass dort 2 Stoppbits konfiguriert werden.
Ist sicherlich kein Beinbruch, aber ich vermute eher, dass eigentlich 
8N1 konfiguriert werden sollte.

Etwas kritischer ist das hier:

Außerdem würde ich erst einmal "klein anfangen": also max. 115200 baud 
einstellen - da weiss man, dass die Abweichung von Soll-Baudrate und 
Ist-Baudrate mit 2,1% noch halbwegs "legal" ist (vgl. S.199 hier: 
http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf) 
und es zu keinen Fehlern kommen sollte.
Alles darüber ist Glückssache (so jedenfalls mein Verständnis).

Und ganz kritisch sehe ich das hier:

Dann sehe ich den UART-Empfänger-Interrupt aktiviert.
Ohne dass ich bisher weiteren Code gesichtet hätte (... gleich ist erst 
einmal Familie dran ...) halte ich das bei den dort eingestellten 2 
Mbaud für sehr gewagt:  bei 16MHz Takt hätte die ISR ganze 8 Takte Zeit, 
um das empfangene Bit zu verarbeiten (inklusive Ein- und Rücksprung!). 
Meiner Meinung nach kann das nicht funktionieren.

Soweit erst einmal meine 10 Cent zum Thema "UART0_init (void)".

Viele Grüße

Igel1


PS: ich weiss, dass Michael auch schon etwas dazu geschrieben hatte, bin 
aber zu bequem, das alles nochmals rauszusuchen - meine Anmerkungen 
können daher doppelt-gemoppelt sein.

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Ich schaue mir gerade Davids Routine "UART0_init (void)" an.
> Dabei fällt mir auf, dass dort 2 Stoppbits konfiguriert werden.
> Ist sicherlich kein Beinbruch, aber ich vermute eher, dass eigentlich
> 8N1 konfiguriert werden sollte.

ist in diesem Fall egal bzw. sogar von Vorteil. Mir ist kein real 
existierender RS232-RX bekannt, der wirklich noch auf 2 Stoppbits 
auswertet selbst wenn man 8N2 einstellt.das müßte dann auf 
Empfängerseite einen Frame-Error erzeugen, ist mir aber noch nicht 
untergekommen.
Wenn der Empfänger auf 8N1 steht und man 8N2 sendet schindet man eine 
Bitzeit Zeit raus, um sicher auf das nächste Startbit reagieren zu 
können. War aber nur ganz früher (tm) wichtig, weil da nur einmal mit 
dem Lesetakt der Zustand eingelesen wurde und es eben stimmen mußte.
Ich hatte es gesehen und deshalb ignoriert.

Ansonsten habe ich seinen UART-Kram bisher einen riesen Bogen gemacht. 
;-)

Gruß aus Berlin
Michael

[Michael U. (amiga)]

Hallo,

OT: damit es nicht langweilig wird: ESP32 mit OV2640 vom neuen 
LED-Display 64x64 in 1600x1200.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

... David scheint einen Tanzunfall gehabt zu haben - man hört gar nichts 
mehr von ihm ...

[David D. (saturi)]

Andreas S. schrieb:
> Dabei fällt mir auf, dass dort 2 Stoppbits konfiguriert werden.
> Ist sicherlich kein Beinbruch, aber ich vermute eher, dass eigentlich
> 8N1 konfiguriert werden sollte.
Öhm naja mit 8n1 oder 8N2 "Standards" muss ich gestehen, kenne ich mich 
nicht aus. diese UART Routine habe ich ganz am Anfang meiner uC-Karriere 
mal ans laufen gebracht und nehme sie immer wieder her. Also sollte man 
eher nur 1 Stopp-Bit verwenden?

> Etwas kritischer ist das hier:
>
> Außerdem würde ich erst einmal "klein anfangen": also max. 115200 baud
> einstellen - da weiss man, dass die Abweichung von Soll-Baudrate und
> Ist-Baudrate mit 2,1% noch halbwegs "legal" ist (vgl. S.199 hier:
> 
http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf)
Ja, können wir machen, hatte sie nur damals hochgedreht, da ich 
vermutete, dass das rauschen von einem unzureichend refreshtem FIFO kam. 
War ja nicht der Fall. Allerdings habe ich noch keine anderen 
Verhaltensweisen mit dem 2MBaud festgestellt, das Verhalten ist genauso 
wie vorher.

> Und ganz kritisch sehe ich das hier:
>
> Dann sehe ich den UART-Empfänger-Interrupt aktiviert.
> Ohne dass ich bisher weiteren Code gesichtet hätte (... gleich ist erst
> einmal Familie dran ...) halte ich das bei den dort eingestellten 2
> Mbaud für sehr gewagt:  bei 16MHz Takt hätte die ISR ganze 8 Takte Zeit,
> um das empfangene Bit zu verarbeiten (inklusive Ein- und Rücksprung!).
> Meiner Meinung nach kann das nicht funktionieren.
Jap, verstanden. Allerdings scheint es aktuell zu funktionieren. Kann 
aber auch daran liegen, dass ich mit dem Atmega nur relativ Wenige Bytes 
(ich glaube maximal 3) hintereinander empfange. Das scheint er 
offensichtlich noch hin zu bekommen.

> Soweit erst einmal meine 10 Cent zum Thema "UART0_init (void)".
Das finde ich gut, weil ich denke, dass das Problem irgendwo in der UART 
routine liegt. Und ich aktuell davon ausgehe, dass es an einem nicht 
beachtetem Empfangenen Kommando auf dem uC liegt.

Solange das Terminal nicht zuverlässig "Serien" schreiben oder Lesen 
kann, macht muss/müssen ich/wir zunächst das in den Griff bekommen.

Michael schrieb:
>Ansonsten habe ich seinen UART-Kram bisher einen riesen Bogen gemacht.
>;-)
Schade :D da liegt denke ich der Fehler, der Rest scheint "relativ" 
gut/schlecht zu funktionieren.

Ich würde auch gerne auf deinen Vorschlag von vor ein paar posts 
eingehen und die UART routinen umbauen, wenn das zum Erfolg führen kann.

Andreas schrieb:
>... David scheint einen Tanzunfall gehabt zu haben - man hört gar nichts
>mehr von ihm ...

Nicht ganz, ich bin nur gestern einfach tot ins Bett gefallen und war zu 
garnichts mehr in der Lage. Heute dann Skifahren aber jetzt wieder 
daheim und schon wieder mitten drin :)

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Ich würde auch gerne auf deinen Vorschlag von vor ein paar posts
> eingehen und die UART routinen umbauen, wenn das zum Erfolg führen kann.

mal schauen, wie meine Meinung morgen ist. Wenn das Display am 
Wemos-ESP32-Modul sich meldet, habe ich durchuas Lust. ;) Im Moment geht 
es mir wie Dir: ich habe die Verbindungen jetzt 3x kontrolliert, 
jedesmal einen Fehler entdeckt und behoben und stehe trotzdem noch "im 
Dunkeln". Also vorhin entnervt in die Ecke gelegt.....

Ich hatte irgendwo hier auch schon eine Empfangsroutine reingebaut, mit 
einfachem Buffer und RX-IRQ. Lief prinzipiell auch, da ich aber erst 
hätte schauen müssen, was Dein Terminal beim Druck auf welchen Button 
eigentlich sendet, habe ich am anderen Ende angefangen.
ok, habe gerade mal einen Seriellen Portmonitor installiert, ist zwar 
eine Demo und läuft nur 14 Tage, aber sie macht erstmal, was sie soll.
Also morgen mal schauen...

Gruß aus Berlin
Michael

[David D. (saturi)]

Welche Software hast du da ausgewählt?
Ich nehme mir gerade die Warnings vor ;-)


Gruß
David

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Welche Software hast du da ausgewählt?
Die erstbeste, die mir in die Hände viel:
https://www.eltima.com/de/products/serial-port-monitor/

> Ich nehme mir gerade die Warnings vor ;-)
BNaja, die meisten sind ja nur warnings wegen den Zuweisungen in 
if-Anweisungen. Ein Klammerpaar drumrum und der Compiler erkennt die 
Absicht und vermutet keinen Tippfehler = <> ==

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hi Leutis,

habe gerade einmal Davids Code genommen und statt main.c und uart.c 
komplett durch Michaels Code zu ersetzen, habe ich nur main.c durch 
Michaels Code ersetzt.

Damit wird alle 20s die Routine "sendFrameBufferToUART (width, height, 
BytesPerPixel);" aufgerufen. Außerdem ist sichergestellt, dass die 
Kamera-Parameter auch wirklich ein Colorbar-Testbild erzeugen.

Fazit: der Nano sendet anschließend keinen Pieps mehr über Seriell - 
schade aber auch, denn die Uart-Routinen mit dem Ringbuffer sehen auf 
den ersten Blick sehr elegant aus.

@David: bist Du von allein auf solche Konstrukte hier gekommen? :

volatile struct UART0_tx        //Transmit Buffer
{
volatile char data[UART0_tx_size];
char read;
char write;
}UART0_tx= {{}, 0, 0};


int UART0_tx_in (char input)
{
  char next= ((UART0_tx.write+1)&UART0_tx_mask);
  if (next==UART0_tx.read)
  {
    return 0;
  }
  UART0_tx.data[UART0_tx.write] = input;
  UART0_tx.write =next;
  return 1;
}

Für einen Programmieranfänger fände ich das mehr als bemerkenswert:
Ringbuffer mit sehr raffinierter, handcodierter Modulo-Berechnung.
Meine ersten Versuche sahen da deutlich schlichter aus.

Jetzt muss ich nur noch den Fehler finden, warum das Dingen so gar 
keinen Mucks von sich gibt. Nur leider ist Basteltime für heute schon 
wieder over.

Viele Grüße

Igel1

[David D. (saturi)]

Hi,
Ich bin leider auch schon wieder im Land unterwegs, also bei dem 
Standard uart fürnktionen habe ich mich hier auf der Website  bei den 
avr "beispielen" bedient :D das hätte ich am Anfang niemals so 
hinbekommen. Das war ca. 2014 in meinem ersten uni Projekt.

Also bei mir läuft es mit meinem Terminal auch mehrmals hintereinander. 
Aber ich würde gefühlsmäßig nicht beim Bild anfangen sondern bei 
mehreren Registern lesen oder schreiben.
Also es liegt nicht an den Buffern habe breakpoints bei beiden fifo fiel 
Routinen gesetzt. Und die lösen nicht aus, wenn die Übertragung 
abbricht.
...
Hmm ich bin was ratlos
Grüße aus aktuell Regensburg

[Andreas S. (igel1)]

David D. schrieb:
> Hi,
> Ich bin leider auch schon wieder im Land unterwegs,

Du meine Güte - bist Du Vertreter (neudeutsch: Vertriebler?)
Die machen echt "Landverschickung" mit Dir.

> also bei dem
> Standard uart fürnktionen habe ich mich hier auf der Website  bei den
> avr "beispielen" bedient :D das hätte ich am Anfang niemals so
> hinbekommen. Das war ca. 2014 in meinem ersten uni Projekt.

Ah - der Mann hat doch stuckadiert.

> Also bei mir läuft es mit meinem Terminal auch mehrmals hintereinander.

Was genau?

> Aber ich würde gefühlsmäßig nicht beim Bild anfangen sondern bei
> mehreren Registern lesen oder schreiben.

Passt schon - Bildausgabe ist schon okay.

> Also es liegt nicht an den Buffern habe breakpoints bei beiden fifo fiel
> Routinen gesetzt.

Was meinst Du mit "fifo fiel Routinen"?

> Und die lösen nicht aus, wenn die Übertragung
> abbricht.
> ...
> Hmm ich bin was ratlos

Das werden wir schon gemeinsam schaukeln.

Inzwischen fiel mir auch ein, warum Dein Code nix sagt, wenn ich Deine 
"main.c" durch Michaels "main.c" ersetze: vermutlich hatte Michael den 
Interrupt deaktiviert...
Und so war's denn auch - ich hätte einfach nur genauer hinschauen 
müssen.

Habe ab Do ein paar Tage frei, dann kann ich mich etwas mehr eindenken - 
braucht halt doch Ruhe und Muße, so eine Fehleranalyse. Hoffentlich läßt 
mir Michael den oder die Fehler übrig - jetzt wo ich alles mühevoll 
zusammengestöpselt habe.

By the way: warum nutzt Ihr Eure Logic-Analyser nicht zur Analyse des 
seriellen Protokolls und hantiert statt dessen mit Software herum?
Mein Intronix LogicPort kann UART im Schlaf decodieren.


> Grüße aus aktuell Regensburg

Grüße aus - Du weißt schon wo

Igel1

[Andreas S. (igel1)]

Hi David,

schau mal das Bild im Anhang ...
Du wirst es nicht glauben: es stammt aus Deinem Programm - mit minimalen 
Anpassungen:

Ich habe - wie oben geschrieben - Deine "main.c" durch Michaels "main.c" 
ersetzt. Einziger Grund: ich wollte die Menüauswahl rauswerfen, um mich 
so auf die Routine "sendFrameBufferToUART (width, height, 
BytesPerPixel);" konzentrieren zu können.

Diese Routine habe ich dann wie folgt angepasst:

 void sendFrameBufferToUART (int ImageWidth, int ImageHeight, int BytesPerPixel)
 {
  OV7670_ResetFifoReadPointer();

  for(int height = 0; height < ImageHeight;height++)
  {
    for(int width =0; width < ImageWidth; width++)
    {
      for(int ByteNumber =0; ByteNumber < BytesPerPixel; ByteNumber++)
      {
        
        OV_RCK_PORT &= ~(1<<OV_RCK_PinNo);
        UART0_senden_Byte(Ov7670_readByte());
        _delay_us(300);
        OV_RCK_PORT |= (1<<OV_RCK_PinNo);
        
        
      }
    }
  }
 }

Begründung:

Flankenwechsel für RCK habe ich vertauscht, damit Du das erste Byte 
nicht verschlumpfst, denn wenn Du die Flanke von RCK von LOW nach HIGH 
gehen lässt und dann erst das Byte aus dem AL422B-FIFO liest, so landest 
Du schon beim zweiten Byte (Michael war das aufgefallen - diese Blumen 
gehen an ihn).

Sodann folgt das eigentliche Problem, das seinen Ursprung beim Aufruf 
von "UART0_senden_Byte(Ov7670_readByte())" hat.

Bei der Sichtung dieser Routine fiel mir auf: sie ruft die Unterroutine 
"UART0_tx_in(Byte)" auf und in dieser Unterroutine wiederum wird ein 
internen Puffer UART0_tx.data[] gefüllt. Das geht so:

int UART0_tx_in (char input)
{
  char next= ((UART0_tx.write+1)&UART0_tx_mask);
  if (next==UART0_tx.read)
  {
    return 0;
  }
  UART0_tx.data[UART0_tx.write] = input;
  UART0_tx.write =next;
  return 1;
}

Dieser Puffer wird dann anderweitig auch schön brav von der ISR-Routine 
gemäß Prinzip first-in-first-out ausgelesen und per UART auf die Leitung 
geschoben.

Der Knackpunkt: die Einleseroutine wartet nicht und schreibt immer 
weiter in den Puffer - solange, bis der Schreibzähler des Ringbuffers 
den Lesezähler quasi von hinten eingeholt hat. Spätestens dann sollte 
der Auslesevorgang aus dem AL422B eigentlich stoppen, denn der 
Ringbuffer ist ja voll.

Tut er aber nicht: statt dessen wird in obiger Routine ein "return 0" 
aufgerufen, was von der aufrufenden Routine "void UART0_senden_Byte(char 
Byte)" leider nicht als "Hilferuf" a la "ich bin voll, bitte nix mehr 
reinstopfen" beachtet wird.

Statt dessen kehrt diese zurück zur eingangs gelisteten 3-fachen 
for-Schleife, die ein weiteres Byte aus dem AL422B-FiFo ausliest und 
wiederum per Aufruf von "UART0_senden_Byte(char Byte) -> 
UART0_tx_in(Byte)" versucht in den Ringbuffer zu stopfen.

Genau hier nimmt das Unglück seinen Lauf, denn das Byte wird nicht mehr 
in den Ringbuffer geschrieben, weil die Routine "UART0_tx_in (char 
input)" per "return 0" verlassen wird. Die Folge: das Byte geht 
verloren.
Das ist übrigens auch der Grund dafür, warum dann später reproduzierbar 
zu wenig Bytes über die serielle Leitung rausgeschrieben werden - der 
fehlende Rest ist "per return 0" im Nirvana gelandet.

Verschafft man der ISR allerdings genügend Zeit, den Ringbuffer 
auszulesen und über die serielle Leitung zu schicken, so tritt kein 
Überlauf des Ringbuffers ein und alles ist gut. Das habe ich einfach 
durch Einfügen von "_delay_us(300);" im ganz oben zitierten Codeblock 
getan.

Alternativ kann man auch auch Warteschleifen innerhalb der Routine "void 
UART0_senden_Byte(char Byte)" fliegen - nämlich immer dann, wenn 
"UART0_tx_in(Byte);" ein "return 0" zurückgibt. Das sieht dann so aus:

void UART0_senden_Byte(char Byte)
{  
    while(!(UART0_tx_in(Byte))){}     
    UCSR0B |= 0b00100000;  // Data Register empty Interrupt anschalten
}

Das geht natürlich nur beim Betrieb mit AL422B FiFo. Ohne FiFo fliegen 
einem gnadenlos aus dem OV7670 die Bits weiter um die Ohren und man kann 
kein Warteschleifchen fliegen.

Ach ja: ich habe für meine Experimente die Baudrate auf 115200 Baud 
gedrosselt, indem ich in UART.c das Register UBRR0L auf den Wert 16 
gesetzt habe.

  UBRR0L = 0b00010000;  //115200

Viele Grüße

Igel1


PS: und Danke an Michael, dass er mir auch einen Fehler übriggelassen 
hat - er hatte obiges Problem sicherlich schon längst bemerkt und 
durchschaut und hat sich nur aus Edelmut zurückgehalten (ich meine 
sogar, er hatte in diesem Thread die Gefahr des Pufferüberlaufs schon 
einmal erwähnt).

[Andreas S. (igel1)]

Hier noch schnell die veränderten Dateien.
1:40 Uhr - au weia - das wird ein harter Tag morgen ...

Gute Nacht

Igel1

[David D. (saturi)]

Guten Morgen,

Define Lösung Mit der while schleife gefällt mir gut!
Leider -und ich traue es mich fast garnicht zu sagen- war oder ist mir 
das von dir erläuterte Problem bewusst und ich habe das auch immer 
berücksichtigt. Ich habe mit immer über die baudrate ausgerechnet, wie 
lange ich für die Übertragung brauche und dementsprechend ein delay 
reingesetzt. Bei 2MBaud vielen die delays dann ganz raus. Aber in eurer 
Version müssten noch die Kommentare drin sein.
Das erklärt jetzt auch warum bei euch die Bilder nicht "ganz" ankommen. 
Das konnte ich nicht nachvollziehen... da hätte ich vielleicht den von 
dir gefundenen Kniff erwähnen sollen (sorry).

Aber nur weiter so! :D
Jetzt weiß ich auch warum du beim Bild anfangen wolltest, wenn dass noch 
garnicht lief.

Was ich gestern schreiben wollte war, dass ich genau an diesen Stellen, 
wo die Funktionen um den Buffer zu füllen 0 zurückgeben, weil der Buffer 
voll ist, brake points gesetzt habe. Und bei mir löst der dort nicht 
aus.

Grüße,

David

[Michael U. (amiga)]

Hallo,

kommt ja etwas Leben in die Bude. ;)

Andreas S. schrieb:
> Ich habe - wie oben geschrieben - Deine "main.c" durch Michaels "main.c"
> ersetzt. Einziger Grund: ich wollte die Menüauswahl rauswerfen, um mich
> so auf die Routine "sendFrameBufferToUART (width, height,
> BytesPerPixel);" konzentrieren zu können.

Genau das war mein Grund auch, ich wollte erstmal was sehen und halbwegs 
sicher sein, daß SCCB und die OV7670 Routinen von ihm laufen und das 
machen sie ja auch.

Andreas S. schrieb:
> Flankenwechsel für RCK habe ich vertauscht, damit Du das erste Byte
> nicht verschlumpfst, denn wenn Du die Flanke von RCK von LOW nach HIGH
> gehen lässt und dann erst das Byte aus dem AL422B-FIFO liest, so landest
> Du schon beim zweiten Byte (Michael war das aufgefallen - diese Blumen
> gehen an ihn).

Danke für die Blumen, ich wollte nur wegen dieser Änderung die 
OV7670_with_Fifo.c nicht auch noch mitschicken, hätte nur verwirrt.

Andreas S. schrieb:
> PS: und Danke an Michael, dass er mir auch einen Fehler übriggelassen
> hat - er hatte obiges Problem sicherlich schon längst bemerkt und
> durchschaut und hat sich nur aus Edelmut zurückgehalten (ich meine
> sogar, er hatte in diesem Thread die Gefahr des Pufferüberlaufs schon
> einmal erwähnt).

Vermutet ja, aber eben einfach komplett bei mir ausgeklammert. Edelmut 
ist das weniger, ich habe ja auch noch meine Spielereien hier rumliegen 
und manchmal hae ich selbst als Rentner noch ein paar andere Dinge 
vor...
Ich werden Deine UART-Änderungen mal reinhängen und schauen, was 
passiert. Irgendwann nachher, später oder so.

Andreas S. schrieb:
> By the way: warum nutzt Ihr Eure Logic-Analyser nicht zur Analyse des
> seriellen Protokolls und hantiert statt dessen mit Software herum?
> Mein Intronix LogicPort kann UART im Schlaf decodieren.

Mein Eigenbau LA hat die Routinen dafür nie bekommen.
Dazu kommt ein Umstand aus alter Zeit: meine ersten Diskussionen mit 
UART und USART sind lange her und da war LA noch Fremdwort. Also mußte 
ich mir meine Machwerke meist sehr lange und genau überlegen.Ich finde 
Softwarefehler auch heute noch meist durch schrittweises gedankliches 
Durchspielen, was der µC da macht oder/und durch Brüten über 
Datenblattpassagen und Timingdiagramme.
Auch ein Grund, weshalb ich z.B. bei den ESP, speziell dem ESP32, da 
ungern selbst tief einsteige. Das Zusammenspiel der Hardwarekomponenten, 
dem RTOS und der IO-Matrix ist eine andere Größenordnung als auf einem 
Mega328 rumzuspielen, wo man die Registerbits noch beim Vornamen kennen 
kann.

David D. schrieb:
> Leider -und ich traue es mich fast garnicht zu sagen- war oder ist mir
> das von dir erläuterte Problem bewusst und ich habe das auch immer
> berücksichtigt. Ich habe mit immer über die baudrate ausgerechnet, wie
> lange ich für die Übertragung brauche und dementsprechend ein delay
> reingesetzt. Bei 2MBaud vielen die delays dann ganz raus. Aber in eurer
> Version müssten noch die Kommentare drin sein.
Naja, wäre für mich zumindest generell eine unschöne Lösung, notfalls 
kämen da eben einige #ifdef für die Baudrate rein, um das zur 
Compilezeit anzupassen.
Ich bin der Geschichte, daß meine UNOs über 230400 Misz bauen, auch nur 
am Rande auf den Grund geganen: es sieht so aus, als ob der Mega16U2 als 
USB-Wandler Mist baut, wenn mehr Daten als sein UART-Buffer kommen und 
er zwischendurch das USB-Paket rausschickt. Mit kleinen Datenmegen gehen 
alle Baudraten stabil. Ein CH340 hat das Problem eben nicht. Ich müßte 
also beim Senden des Bildes noch Wartezeiten im passenden Blockabstand 
einfügen, macht aber letztlich keinen Sinn, dann kann ich auch bei 
230kBaud bleiben...

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

David D. schrieb:
> Guten Morgen,
>
> Define Lösung Mit der while schleife gefällt mir gut!

Danke. Warten in while-Schleifen gehört zu meiner Spezialität:

while(I am working all day long and way to much)
{
   live passes by;
}

> Leider -und ich traue es mich fast garnicht zu sagen- war oder ist mir
> das von dir erläuterte Problem bewusst und ich habe das auch immer
> berücksichtigt.

Mist - dann habe ich mir die Nacht umsonst um die Ohren gehauen.
Na ja - bin vermutlich ein bisschen selber schuld - hätte halt genauer 
Deine Posts lesen sollen.

> Ich habe mit immer über die baudrate ausgerechnet, wie
> lange ich für die Übertragung brauche und dementsprechend ein delay
> reingesetzt. Bei 2MBaud vielen die delays dann ganz raus. Aber in eurer
> Version müssten noch die Kommentare drin sein.

Ich hatte mich nur auf "sendFrameBufferToUART (int ImageWidth, int 
ImageHeight, int BytesPerPixel)" konzentriert und da wa nischt drinne 
von wegen "delay" oder so.

> Das erklärt jetzt auch warum bei euch die Bilder nicht "ganz" ankommen.
> Das konnte ich nicht nachvollziehen... da hätte ich vielleicht den von
> dir gefundenen Kniff erwähnen sollen (sorry).

Immerhin: jetzt sind wir alle schlauer (bzw. genauso schlau, wie Du 
schon vorher warst :-))

> Aber nur weiter so! :D
> Jetzt weiß ich auch warum du beim Bild anfangen wolltest, wenn dass noch
> garnicht lief.

Okay - dann gehen wir bitte nochmals einen Schritt zurück und klärer 
erst einmal, was denn aktuell bei Dir nicht funktioniert?  (oder 
vermutlich genauer: wir repetieren noch einmal, was evtl. vor 100-200 
Posts schon einmal gesagt wurde).

Bitte beschreibe Deine Probleme netterweise noch einmal genauer (oder 
verlinke Deine Beschreibung, wenn Du die Probleme bereits vorher im 
Thread dokumentiert hast - ich habe nämlich etwas den Überblick 
verloren).

Dann könnten Michael und ich zielgenau versuchen, die Probleme zu 
reproduzieren, um sie anschließend einzugrenzen.

Ich selber möchte dabei Dein PC-Programm erst einmal außen vor lassen 
(also nicht nutzen) und mich nur auf das MC-Programm fokussieren. So 
können wir eine Fehlerquelle ausschließen.

> Was ich gestern schreiben wollte war, dass ich genau an diesen Stellen,
> wo die Funktionen um den Buffer zu füllen 0 zurückgeben, weil der Buffer
> voll ist, brake points gesetzt habe. Und bei mir löst der dort nicht
> aus.

Das war ein geschickter Schachzug von Dir, denn damit hast Du eindeutig 
bewiesen, dass der Puffer bei Dir nicht überläuft - gut.

> Grüße,
>
> David

Viele Grüße

Igel1

[Andreas S. (igel1)]

Andreas S. schrieb:
>
> Okay - dann gehen wir bitte nochmals einen Schritt zurück und klärer
> erst einmal, was denn aktuell bei Dir nicht funktioniert?  (oder
> vermutlich genauer: wir repetieren noch einmal, was evtl. vor 100-200
> Posts schon einmal gesagt wurde).
>

Oh ha - klingt furchtbar arrogant, was ich da heute zwischen Tür und 
Angel   formuliert hatte - sollte es aber gar nicht sein:

Ich bräuchte nur einfach nur nochmals eine Beschreibung, wo genau bei 
Dir der Schuh / die Software drückt, damit ich weiß, wo genau ich 
anfangen soll.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Oh ha - klingt furchtbar arrogant, was ich da heute zwischen Tür und
> Angel   formuliert hatte - sollte es aber gar nicht sein:
mach es nicht schlimmer als es ist. :-)

> Ich bräuchte nur einfach nur nochmals eine Beschreibung, wo genau bei
> Dir der Schuh / die Software drückt, damit ich weiß, wo genau ich
> anfangen soll.
Du triffst damit den Nagel ziemlich genau auf den Kopf.
Was mich dabei betrifft: Deine UART-Änderung werde ist erstmal 
reinwerfen und schauen was passiert. Sein Terminalprogramm werde ich 
nutzen bzw. testen wenn es um irgendwas konkretes geht. Eigentlich ist 
mir dieses ziemlich egal, für mich interessant ist, was geht mit der 
OV7670, was kann man da Erreichen, weiche Bedeutung und Funktion haben 
Einstellungen da auf die Bildqualität usw. usw. Ob ich Registersettings 
da per spezieller Software mache oder die im Source ändere und flashe 
ist mir da relativ egal. Einfach, weil aus meiner Sicht da mehr 
Datenblattstudien, Funktionen verstehen im Vordergrund steht.

Gruß aus berlin
Michael

[David D. (saturi)]

Andreas S. schrieb:
> Ich hatte mich nur auf "sendFrameBufferToUART (int ImageWidth, int
> ImageHeight, int BytesPerPixel)" konzentriert und da wa nischt drinne
> von wegen "delay" oder so.
Kann durchaus sein, weil ich ja immernur mit RbyR getestet hatte und das 
Empfangen des Gesamt bildes erst danach eingeführt habe.

> Okay - dann gehen wir bitte nochmals einen Schritt zurück und klärer
> erst einmal, was denn aktuell bei Dir nicht funktioniert?  (oder
> vermutlich genauer: wir repetieren noch einmal, was evtl. vor 100-200
> Posts schon einmal gesagt wurde).
Sehr gerne!

> Ich selber möchte dabei Dein PC-Programm erst einmal außen vor lassen
> (also nicht nutzen) und mich nur auf das MC-Programm fokussieren. So
> können wir eine Fehlerquelle ausschließen.
Das wird vermutlich nicht gehen, da das Problem folgendes ist:

Was funktioniert?
-einzelnes Register Lesen
-einzelnes Register Schreiben
-ein Bild requesten und Empfangen (solange es das komplette Bild und 
nicht Row by Row ist. (Colorbar und wenn ich auf Bild stelle ein sehr 
sehr matschiges Bild (siehe Anhang) (vermutlich wegen fehlender 
Registereinstellungen [habe nur die notwendigsten]) Die Einstellungen 
würde ich dann gerne mit dem Terminal machen können.

Was funktioniert nicht? (bzw. nicht zuverlässig?)
alle Register hintereinander lesen (obwohl hier rein befehlstechnisch 
nichts anderes passiert, als beim einzelnen Register lesen)
alle Register hintereinander schreiben
Besonders tragisch ist hier, dass das Problem sporadisch und nicht 
zuverlässig reproduzierbar auftaucht. Wenn ich so ein Tool zur 
überwachung wie Michael einsetze, so ist es laut meiner Anzeige der uC, 
der den einen Befehl des Terminals ignoriert und dieses dann aber auf 
Antwort wartet.
(Bin mir aber nicht sicher, ob ich das "Sniffer" Tool richtig eingesetzt 
habe.

Ist das ganze soweit verständlich?

Ein weiter Punkt, den wir - wie mir scheint - vööig außer acht gelassen 
haben ist, dass wir die Register einfach Blind schreiben, ohne Rücksicht 
auf evtl. reserved Bits richtig? Wie gehen wir damit um?

Gruß
David

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Ein weiter Punkt, den wir - wie mir scheint - vööig außer acht gelassen
> haben ist, dass wir die Register einfach Blind schreiben, ohne Rücksicht
> auf evtl. reserved Bits richtig? Wie gehen wir damit um?

Das Datenblatt der OV7670 ist da etwas... naja...
Im zweifel habe ich mich ausgehend von den dort angegeben Registerwerten 
an den Default-Werten orientiert. Genauso, wie bei reservierten 
Registern, orientiere ich mich im Zweifel an irgendwelchen 
Applikationsbeispielen usw.

Zum Terminal: ich werde mir zumindest die UART-Sachen auch nochmal 
genauer anschauen. Generell: mir erschließt sich der Zweck des 
Terminalprogramms irgendwie nicht.

Register lesen und schreiben: ok.
Alle Register lesen/schreiben und speichern/laden um einen bestimmten 
Zustand  schnell zu rekonstruieren ja, anschauen würde ich mir die Werte 
nur in einem Texteditor, wo ich scrollen, kommentieren, ändern könnte 
und eben bei Bedarf den Kram auch komplett in die AVR-Software 
übernehmen könnte.
Bild holen und evtl. gleich anzeigen ja, mit vordefinierten Formaten und 
im Stück. Die Formate würde ich dann bei bedarf erweitern, alle 
möglichen machen für mich sowieso keinen Sinn (Fifo-Größe/Verwendung).
Bei Register hätte ich vermitlich sogar noch eine änderbare 
Binärdarstellung eingebaut, um mit dem Datenblatt daneben geziehlt Bists 
setzen/löschen zu können.
Alles nur meine Gedanken...

PS: ich hätte die Daten außer den Bilddaten generell als ASCII/HEX 
geschickt/geholt. Dann würde jedes simple Terminalprogramm zum Debug 
reichen: a <enter> -> Kommando raus
35 2f 74 -> Antwort kontrolliert.
Der Aufwand HEX encode/decode ist auch auf dem AVR minimal und spielt 
auch keine Rolle, wenn der Mensch vor dem Bildschirm sowieso die Bremse 
ist.
Auch das ist Ansichtssache, aber sonst müßte ich mir für jedes 
Experiment mit irgendwelchen externen ICs erst ein Spezialprogramm 
basteln und dazu habe ich weder Lust noch nehme ich mir die Zeit.

Letztlich sind es aber Deine Pläne, Vorhaben und Absichten, die das 
alles entscheiden und ich gebe zu, daß ich da immernoch nicht so richtig 
durchschaue, wohin Dein Hase da eigentlich laufen soll.

Gruß aus Berlin
Michael

[David D. (saturi)]

Michael U. schrieb:
> Zum Terminal: ich werde mir zumindest die UART-Sachen auch nochmal
> genauer anschauen. Generell: mir erschließt sich der Zweck des
> Terminalprogramms irgendwie nicht.
Der ursprüngliche Gedanke war, mit dem Terminal ein einfaches Werkzeug 
zu haben, um Registerwerte während der Laufzeit bequem ändern zu können, 
ohne für jede Änderung neu compilen+flashen zu müssen. Um hier 
Änderungen an den Register ausprobieren zu können. (Ich weiß du siehst 
im Ausprobieren keinen Sinn. Aber ich bin noch naiv genug ;-) )

> Register lesen und schreiben: ok.
> Alle Register lesen/schreiben und speichern/laden um einen bestimmten
> Zustand  schnell zu rekonstruieren ja, anschauen würde ich mir die Werte
> nur in einem Texteditor, wo ich scrollen, kommentieren, ändern könnte
Das steht noch auf meiner ToDo-Liste, sodass ich die Änderungen auch im 
Terminal vornehmen kann und nicht den Umweg gehen muss.

> Bild holen und evtl. gleich anzeigen ja, mit vordefinierten Formaten und
> im Stück. Die Formate würde ich dann bei bedarf erweitern, alle
> möglichen machen für mich sowieso keinen Sinn (Fifo-Größe/Verwendung).
Ja, hatten wir schon vereinbart ;-) Angefangen wurde jetzt erstmal mit 
RGB565.

> Bei Register hätte ich vermitlich sogar noch eine änderbare
> Binärdarstellung eingebaut, um mit dem Datenblatt daneben geziehlt Bists
> setzen/löschen zu können.
steht ebenfalls auf der ToDo, sodass da auch ein Umstellen wie bei den 
einzelnen Registern möglich wird.

> PS: ich hätte die Daten außer den Bilddaten generell als ASCII/HEX
> geschickt/geholt. Dann würde jedes simple Terminalprogramm zum Debug
> reichen: a <enter> -> Kommando raus
> 35 2f 74 -> Antwort kontrolliert.
> Der Aufwand HEX encode/decode ist auch auf dem AVR minimal und spielt
> auch keine Rolle, wenn der Mensch vor dem Bildschirm sowieso die Bremse
> ist.
Das verstehe ich nicht muss ich gestehen. Also die Kommandos und auch 
Bild Bytes werden ja als Bytes geschickt, wie du sie dir dann im 
Terminal anzeigen lässt ist doch deine Sache. Du kannst auch einfach mit 
Terra Term mit meinem uC Programm kommunizieren. Die Befehle sind in der 
Tabelle in diesem Beitrag zu sehen:
Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)"

> Auch das ist Ansichtssache, aber sonst müßte ich mir für jedes
> Experiment mit irgendwelchen externen ICs erst ein Spezialprogramm
> basteln und dazu habe ich weder Lust noch nehme ich mir die Zeit.
Das verstehe ich ebenfalls nicht, vermutlich weil ich vorherige Aussage 
nicht verstanden habe :D

> Letztlich sind es aber Deine Pläne, Vorhaben und Absichten, die das
> alles entscheiden und ich gebe zu, daß ich da immernoch nicht so richtig
> durchschaue, wohin Dein Hase da eigentlich laufen soll.
Wie oben beschriebe: "einfaches" handeln der Kamera ohne hunderte flash 
Vorgänge.

Außerdem kann ich für meine späteren Zwecke teile dieses Programms 
weiterbenutzten (maschinelle Bildverarbeitung) (kein Video nur 
Einzelbilder) ;-)

Gruß

David

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Das verstehe ich nicht muss ich gestehen. Also die Kommandos und auch
> Bild Bytes werden ja als Bytes geschickt, wie du sie dir dann im
> Terminal anzeigen lässt ist doch deine Sache. Du kannst auch einfach mit
> Terra Term mit meinem uC Programm kommunizieren. Die Befehle sind in der
> Tabelle in diesem Beitrag zu sehen:

Ganz einfach: normalerweise nutze ich /und die Terminalprogramm) 
irgendeine Emualtion, meist VT100. Da ist es dann mühsam Controlcodes 
(0x00...0x1f) zu senden bzw. eine Einstellung zu finden, die empfangenen 
Daten als hex ausgibt. HTerm kann sowas, ist aber eigentlich auch eher 
ein Debug-Tool als ein Terminalprogramm.

David D. schrieb:
> Wie oben beschriebe: "einfaches" handeln der Kamera ohne hunderte flash
> Vorgänge.
Wenn es ein guter alter TEA5757 wäre würde ich Dir vorbehaltlos 
zustimmen, beim MAS3507D wurde es damals für mich schon haariger.
Beim ENC28J60 mußte ich mir erst Grundlagen von TCp/IP usw. 
zusammensuchen, für einen rudimentären Stack mit dem Chip reichte es 
dann auch, ARP-Ping und IDCP-Ping ging und dann fehlöte damals zeit und 
auch Lust und ich habe auf was hlabwegs fertiges genommen, das 
angepasst. Die gewonnenen Vorkenntnisse haben zumindest gereicht, recht 
zielsicher in den fremden Sourcen dir richtigen Stellen zu finden.

Bei den 201 Registern der OV7670 incl. haarsträubender Bitkombination 
und Abhängigkeiten würde ich mir das freiwillig nicht antun wollen.
Ich will aus dem Teil ein Bild haben, ich muß rausfinden, welce Register 
ich dazu anfassen muß und welche Rolle genau diese spielen. Was die 
anderen 182 machen ist mir da ziemlich egal. ;) Es würde mir auch wenig 
für andere Projekte (Spielereien) bringen, bei einem anderen Kameramodul 
geht das Suchen sowieso von vorn los.
- gewünschte Auflösung
- gewünschtes Bildformat
dann die ersten Extras:
- Belichtungssteuerung
- Gammakorrektur
- Farbkorrektur
dann die Spezialitäten:
- Belichtungsautomatik
- Weißabgleichautomatik
- 50/60Hz Erkennung (Kunstlicht)
- Gain-Regelung, Nachtmodus
und was die Teile konkret jeweils können.
Das muß ich bei Bedarf auch in einem anderen Datenblatt schnell finden 
und testen können.
Die Kamera liefert prinzipiell ein Bild im gewünschten Format.
Jetzt könnte ich mich z.B. mit den Registern auseinandersetzen, die die 
Bildlage auf dem Sensor bestimmen, eigentlich müßten die 320x240 ohne 
Fehler an den Rändern rauskommen.

David D. schrieb:
> Außerdem kann ich für meine späteren Zwecke teile dieses Programms
> weiterbenutzten (maschinelle Bildverarbeitung) (kein Video nur
> Einzelbilder) ;-)
keine Einwände dagegen. Meine damalige LA-Software in VB6 kann auch nur 
rund 10 Kommandos ,it Einstellungen zum AVR schicken und dann 32k 
Sampleram zurückbekommen. Die Software selbst auf dem PC ist dann 
Anwendung: Einstellbutton, Darstellung der Samledaten usw. Das lief auch 
nicht auf Anhieb, war aber das erste. was ich stabil in Gang bekommen 
mußte.

Genug philosophiert. ;)

Gruß aus Berlin
Michel

[Andreas S. (igel1)]

Hi David,

by the way:

Ich weiß nun, wann Dein Terminal-Programm (V0.6) am rechten Rand 
beschnitten wird:

Ich habe nämlich die Textgröße und weitere Elemente auf dem Bildschirm 
dauerhaft vergrößert, indem ich unter Win7 X64 in den Einstellungen 
Systemsteuerung\Darstellung und Anpassung\Anzeige im Fenster "Lesbarkeit 
auf dem Bildschirm erleichtern" die Vergrößerung auf "Mittel - 125%" 
eingestellt habe. Meine Auflösung ist dabei nach wie vor 1920x1200.

Sobald ich obige Einstellung auf 100% (Standard) zurücksetze, wird Dein 
Terminalfenster nicht mehr am rechten Rand beschnitten.

Es wäre super, wenn Du diesen Bug fixen könntest, denn dann könnte ich 
auch ein bisschen mit Deinem Terminalprogramm testen.

Viele Grüße

Igel1

[Andreas S. (igel1)]

David D. schrieb:
> Was funktioniert nicht? (bzw. nicht zuverlässig?)
> alle Register hintereinander lesen (obwohl hier rein befehlstechnisch
> nichts anderes passiert, als beim einzelnen Register lesen)
> alle Register hintereinander schreiben
> Besonders tragisch ist hier, dass das Problem sporadisch und nicht
> zuverlässig reproduzierbar auftaucht. Wenn ich so ein Tool zur
> überwachung wie Michael einsetze, so ist es laut meiner Anzeige der uC,
> der den einen Befehl des Terminals ignoriert und dieses dann aber auf
> Antwort wartet.
> (Bin mir aber nicht sicher, ob ich das "Sniffer" Tool richtig eingesetzt
> habe.
>
> Ist das ganze soweit verständlich?

Leider nein (sorry, wenn ich etwas langsam von Kapee bin):

Meinst Du mit "alle Register hintereinander lesen/schreiben", dass die 
Lese-/Schreibroutinen auf dem ATmega buggy sind, oder meinst Du dass der 
Lese-/Schreibvorgang (sporadisch) schief geht, wenn Du das 
Lesen-/Schreiben von Deinem Terminalprogamm aus anstößt?

Viele Grüße

Igel1

[David D. (saturi)]

Andreas S. schrieb:
> Leider nein (sorry, wenn ich etwas langsam von Kapee bin):
kein Problem!

Es gibt in meinem uC-Programm keine Routinen für das auslesen oder 
schreiben von mehreren Registern.

Auf meinem Terminal Programm gibt es das aber zum Beispiel beim klick 
auf "Read Device Setting", "get Camera Status" (lesen) und "write Device 
Settings" (schreiben) die Möglichkeit mehrere Register hintereinander zu 
lesen respektive zu schreiben. Dabei läuft dann folgender 
Kommunikationspingpong ab:

am Beispiel lesen:

Terminal fordert Wert für Register 0x01 an
Terminal wartet auf Antwort
uC gibt Wert für Register 0x01 aus

Terminal forder Wert für Register 0x02 an
Terminal wartet auf Antwort
uC gibt Wert für Register 0x02 aus

...


(Das Programm bleibt nicht während des Wartens in einer While schleife 
hängen, da das ganze in C# Eventbasiert verarbeitet wird)


wenn ich mir jetzt anschaue, welche Kommunikation statt findet wenn 
bspw. nicht alle Register gelesen werden, so gerät die Kommunikation 
nach Terminal wartet auf Antwort ins stocken, weil einach die Antwort 
vom uC ausbleibt. Das ganze tritt sporadisch auf, sprich manchmal hängt 
es nach wenigen Registern manchmal nach mehreren manchmal garnicht. Und 
genau das kann ich mir nicht erklären.

[Andreas S. (igel1)]

David D. schrieb:
(formatiert von Igel1)

> folgende Kommandos kann der uC empfangen:
> Command  Auswirkung     Byte1              Byte2             expected Return Value
> 0x01     Read Register  Register Address   -                 1 Byte register Value
> 0x02     Write Register Register Address   newRegisterValue  1 Byte Errorcode

Hmmm - mein Logic-Analyzer sagt da etwas anderes.
Du sendest in Wirklichkeit, z.B. beim Auslesen von Register 0x05:

0x01 0x05 0x0D 0x0A

Und erhältst in Wirklichkeit als Antwort:

0x05 0x80

... wobei 0x80 der Registerinhalt von Register 0x05 ist.

Und die Schreibfolge sieht so aus, wenn Du z.B. Register 0x05 mit Wert 
0x80 beschreibst:

0x02 0x05 0x80 0x0D 0x0A

Und als Antwort erhältst Du den Fehlercode:

0x00

Viele Grüße

Igel1

[Andreas S. (igel1)]

David D. schrieb:
> wenn ich mir jetzt anschaue, welche Kommunikation statt findet wenn
> bspw. nicht alle Register gelesen werden, so gerät die Kommunikation
> nach Terminal wartet auf Antwort ins stocken, weil einach die Antwort
> vom uC ausbleibt. Das ganze tritt sporadisch auf, sprich manchmal hängt
> es nach wenigen Registern manchmal nach mehreren manchmal garnicht. Und
> genau das kann ich mir nicht erklären.

Ah ja: Du meinst, der grüne Ladebalken hängt (manchmal), wenn Du auf den 
Button "Read Device Settings" drückst?

Yep - dieses Problem kann ich zumindest reproduzieren.

Viele Grüße

Igel1

[David D. (saturi)]

Ähm ja... :D

Das liegt daran, wie der uC erkennt ob ein Befehl vollständig gesendet 
wurde.

An jedes Kommando, dass das Terminal sendet wird am Ende ein CR+LF dran 
gehangen (13, 10 in dez. oder 0x0D 0x0A in Hex)


Anhand dieses Indikators wird der Rx Buffer in Sinnvolle empfangene 
Befehle gestückelt und sicher gestellt, dass ein Befehl erst verarbeitet 
wird, wenn alle notwendigen Informationen vorhanden sind.


Die Verarbeitung findet dann in UART.c unter der Funktion UART0_rx_work 
statt:

...
  if(UART0_rx_complete())
  {

  char Befehl[UART0_Befehl_FiFo] = {};      // Hier steht der Befehl
  volatile int j = 0;
  volatile int i = 0;
  do
  {
    char temp = UART0_rx_out();
      
    Befehl[i] = temp;
    i++;

    //Künstlicher Zähler, um das Abfragen der beiden Bits auch beim ersten zu ermöglichen
    if(i<2)
    j=1;
    else
    j=0;
  }while(((Befehl[i+j-2] != (char)0x0D) || (Befehl[i-1] != (char)0x0A))&&(i<UART0_Befehl_FiFo));        // solange kein CR+LF erkannt wird
...

[Michael U. (amiga)]

Hallo,

die Bytefolgen hatte ich mir im Sniffer auch angeschaut und bin zu dem 
gleichen Schluß gekommen, was gesendet wird usw.
Zum Glück für Andreas habe ich im Moment etwas wenig Zeit für die 
GEschichte, so kann er mir in Ruhe die Arbeit abnehmen. ;-))

Ich habbe mal eine IRQ-RX-Routine in die uart.c gepackt, weil ich mir 
Davids Ablauf noch nicht im Detail angeschaut habe.

Ich hänge die hier einfach mal ran, in main() müssen vorn noch 3 Zeilen 
eingefügt werden.
In uart.h muß die Zeile
#define UART_MAXSTRLEN 63
eingefügt werden und in main()

extern volatile uint8_t uart_str_complete;     // 1 .. String komplett empfangen
extern volatile uint8_t uart_str_count;
extern volatile char * uart_string[];

Ich wollte da eigentlich nur schnell testen, ob sein switch für die 
Kommandoauswertung das, macht, was er soll, ist aber noch nicht 
passiert.
Ist alles nicht schön gemacht, sollte nur gehen...

Es fehlt z.B. ein error-flag wenn der Buffer voll ist, da geht es dann 
nie weiter. Müßte in main() abgefragt werden um den Buffer einfach neu 
zu initialisieren bei einem derartigen Fehler und ein overflow zum 
Terminal gemeldet werden..

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> Zum Glück für Andreas habe ich im Moment etwas wenig Zeit für die
> GEschichte, so kann er mir in Ruhe die Arbeit abnehmen. ;-))

Na wenn Du Dich da mal nicht täuscht: Andreas ist die nächsten 5 Tage 
computerlos, wird also erst mal nix mit Weiterdebuggen. Ich lasse Euch 
zwei Hübschen also erst einmal alleine im Code weiterrühren.

Aber so ist das mit dem Hobby: ständig ist alles andere wichtiger - es 
ist zum Mäusemelken.

Viele Grüße

Igel1

[David D. (saturi)]

Na das klingt ja nach nem Karnevals Jecken... ich komm für den Samstag 
extra hoch ;-)

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Karnevals Jecken...

Was ist das??? ;-)

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hi David,

habe gerade eine heiße Spur entdeckt, werde aber keine Zeit mehr haben, 
sie zu verfolgen:

Dein Ringpuffer-Mechanismus funktioniert offenbar nicht so, wie er 
eigentlich angedacht ist.

So definierst Du den Ringpuffer und die zugehörigen Zähler "read" und 
"write":

#define UART0_rx_size 512          // Nur Werte 2^n zulässig !
#define UART0_rx_mask (UART0_rx_size-1)


//------------------------------------------------------------------------------

int temp = 0;  
struct UART0_rx        //Receive Buffer
{
char data[UART0_rx_size];
char read;
char write;
}UART0_rx= {{}, 0, 0};

Und so verwendest Du sie:

int UART0_rx_in (char input)
{
  char temp= ((UART0_rx.write+1)&UART0_rx_mask);  //
  if (temp==UART0_rx.read)              //FiFo voll ?
  {  
    return 0;                    //return 0 -> Fifo voll
  }
  UART0_rx.data[UART0_rx.write]=(char)input;    //Daten ins Array legen
  UART0_rx.write = temp;                //write auf nächste Specicherzelle schieben
  return 1;                      //return 1 -> Fifo abspeichern erfolgreich 
}

Dabei fällt auf, dass die beiden Zähler nur 8 Bit breit sind, Dein 
Modulo-Mechanismus mit

((UART0_rx.write+1)&UART0_rx_mask)

... aber offenbar von einem Integer-Wert ausgeht.

Will sagen: der Mechanismus läuft ins Leere.

Jetzt müsste man nochmals genau durchdenken, ob es trotzdem per Zufall 
funktioniert - an allen Stellen und sogar auch bei Subtraktionen, die ja 
ebenfalls vorkommen.

Jedenfalls scheint es nicht so gedacht gewesen zu sein und von Deinem 
512 Byte breiten Ringpuffer werden dadurch auch nur 256 Bytes genutzt.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Jedenfalls scheint es nicht so gedacht gewesen zu sein und von Deinem
> 512 Byte breiten Ringpuffer werden dadurch auch nur 256 Bytes genutzt.

warum reserviert man auf einem kleinen AVR mit nur 2k Ram solche 
Riesenbuffer? So lang kann doch keine Kommandofolge sein und bevor er 
die nicht bearbeitet und beantwortet hat, macht es doch keinen Sinn was 
neues zum AVR zu schicken. Beim Senden ist es doch auch egal, ob man 
128Byte oder 512Byte Häppchen schickt?
Ist vielleicht auch Vorurteil, aber bei mir heißt AVR eben immernoch Ram 
sparen, wo es geht und geziehlt dort einsetzen, wo es wirklich nötig 
ist.
Bei den ESPs bin ich da weit weniger sparsam... ;)

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hi Dirk,

schau mal hier:
https://ide.geeksforgeeks.org/E7p41NoTYk

Morgen mehr dazu.

Viele Grüße

Igel1

[Andreas S. (igel1)]

Uppps - aus David wurde Dirk - sorry...

[Andreas S. (igel1)]

... und noch mehr zum Thema:
https://ide.geeksforgeeks.org/nL9paB6EfN

Viele Grüße
Andreas

[Andreas S. (igel1)]

Und noch eine schönere Version:

https://ide.geeksforgeeks.org/PwEDpstPrZ

[Michael U. (amiga)]

Hallo,

ich bin mal auf meiner Spielwiese geblieben, also meine UART RX/TX 
Routine drin.
Schnelltest sagt: Register read/write geht, register komplett lesen 
geht, Kamera Init geht manchaml erst beim 2. Mal, Get Kamera Status 
geht.

Bilder holen passt von der Initalisierung nicht zusammen, er setzt VGA 
und holt dann 320 Zeilen und weiß nicht weiter. Es bleibt aber nichts 
hängen, ich kann im Terminalprogramm mit anderen Funktioneh weiter 
machen.
Es passieren bei Write Register seltsame Dinge: ich schreibe 0x40 in Reg 
0x80, bekomme ok zurück. Beim Lesen von Reg 0x80 meldet er meist 0x00 
zufürck obwohl definitiv geschrieben wurde.
Nochmal schreiben meldet 0x00 im seriellen Debug zurück, Terminal sagt 
Error 68. Muß ich mir mal genauer anschauen.
Andreas, ich lasse Dir weiter das Kramen in seinen UART-Sourcen und 
bleibe erstmal bei meiner Testversion...

Für David hänge ich mal meine modifizierte main.c und uart.c ran, falls 
er damit mal testen will, er kann ja sein Terminal sicher besser 
bedienen als ich...

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hi David,

hier eine noch bessere Version:
https://ide.geeksforgeeks.org/kueWbVYXmL

Der Code lautet:

#include <stdio.h>

#define SIZE 512
#define MASK (SIZE - 1)

int main() {
  char c;
  char carray[] = {0,1,2,126,127,128,129,-1,-2};
  char cplus1;
  int  cintplus1;
  int data[SIZE]={};
  
  for(int p=0; p<SIZE; p++){
      data[p] = p;
  }
  
  for(int k=0; k<sizeof(carray); k++){
  
    c=carray[k];
      cplus1=(c+1) & MASK;
      cintplus1=(c+1) & MASK;
  
    printf("c=%d\n", c);
    printf("cplus1=%d\n", cplus1);
    printf("cintplus1=%d\n", cintplus1);
    printf("data[c]=%d\n", data[c]);
    printf("data[(c-1) & MASK]=%d\n", data[(c-1) & MASK]);
    printf("data[c & MASK] = %d\n",   data[c & MASK]);
    printf("data[(c+1) & MASK]=%d\n", data[(c+1) & MASK]);
    printf("........................\n\n");
  }
  return 0;
}

Und das Ergebnis lautet:

c=0
cplus1=1
cintplus1=1
data[c]=0
data[(c-1) & MASK]=511
data[c & MASK] = 0
data[(c+1) & MASK]=1
........................

c=1
cplus1=2
cintplus1=2
data[c]=1
data[(c-1) & MASK]=0
data[c & MASK] = 1
data[(c+1) & MASK]=2
........................

c=2
cplus1=3
cintplus1=3
data[c]=2
data[(c-1) & MASK]=1
data[c & MASK] = 2
data[(c+1) & MASK]=3
........................

c=126
cplus1=127
cintplus1=127
data[c]=126
data[(c-1) & MASK]=125
data[c & MASK] = 126
data[(c+1) & MASK]=127
........................

c=127
cplus1=-128
cintplus1=128
data[c]=127
data[(c-1) & MASK]=126
data[c & MASK] = 127
data[(c+1) & MASK]=128
........................

c=-128
cplus1=-127
cintplus1=385
data[c]=710832128
data[(c-1) & MASK]=383
data[c & MASK] = 384
data[(c+1) & MASK]=385
........................

c=-127
cplus1=-126
cintplus1=386
data[c]=32517
data[(c-1) & MASK]=384
data[c & MASK] = 385
data[(c+1) & MASK]=386
........................

c=-1
cplus1=0
cintplus1=0
data[c]=0
data[(c-1) & MASK]=510
data[c & MASK] = 511
data[(c+1) & MASK]=0
........................

c=-2
cplus1=-1
cintplus1=511
data[c]=8
data[(c-1) & MASK]=509
data[c & MASK] = 510
data[(c+1) & MASK]=511
........................

Schau Dir nun Deine Routinen an, die Deinen Ringbuffer verwenden.
Z.B. Diese hier:

[code]
int UART0_rx_complete(void)
{
  //Wenn CR+LF empfangen wird, ist der Befehl vollständig
  if(UART0_rx.data[(UART0_rx.write -2)&UART0_rx_mask] == 0x0D 
&&UART0_rx.data[(UART0_rx.write-1)&UART0_rx_mask]==0x0A)
  {
    return 1;
  }
  else
  {
    return 0;
  }
}
[/code)

... und leite aus obigen Programm ab, was passiert, wenn z. B.
UART0_rx.write = 0 ist.

Ja, richtig: Du liest Puffer 510 und 511 aus.
Scheint noch halbwegs richtig zu sein.

Aber wirst Du diese Pufferplätze jemals beschreiben?

Schau Dir dafür diese Routine an:

[code]
int UART0_rx_in (char input)
{
  char temp= ((UART0_rx.write+1)&UART0_rx_mask);  //
  if (temp==UART0_rx.read)              //FiFo voll ?
  {
    return 0;                    //return 0 -> Fifo voll
  }
  UART0_rx.data[UART0_rx.write]=(char)input;    //Daten ins Array legen
  UART0_rx.write = temp;                //write auf nächste 
Specicherzelle schieben
  return 1;                      //return 1 -> Fifo abspeichern 
erfolgreich
}
[/code)

Mit Blick auf mein Testprogramm oben meine ich, dass spätesten ab 
UART0_rx.write=128

... einiges Unvorhergesehene passieren wird.

Viele Grüße

Igel1

[Andreas S. (igel1)]

Scharfes Nachdenken ergab: der Ringpuffer-Mechanismus sollte eigentlich 
funktionieren, wenn man für alle Variablen, die in Array-Indizes bzw. in 
Indexrechnungen verwendet werden, unsigned int Variablen verwendet.

Mangels Rechner kann ich das leider aktuell nicht testen.

Viele Grüße

Igel1

[Andreas S. (igel1)]

Habe hier mal den Typ der Indexvariablen „c“ von char auf unsigned int 
umgestellt:

https://ide.geeksforgeeks.org/kueWbVYXmL

Scheint zu funktionieren - insbesondere an den Rändern des Puffers:
Am oberen Rand wird von 511 sauber auf 0 gesprungen.
Und am unteren Rand wird von 0 sauber nach 511 hochgesprungen.
Genau so soll ein Ringpuffer ja funktionieren.

Viele Grüße

Andreas

[David D. (saturi)]

Hallo Andreas,
ich wollte ein kurzes Lebenszeichen von mir geben!

das sieht alles sehr sehr interessant aus. Leider bin ich noch nicht 
dazu gekommen dass in aller Ruhe zu überdenken, und nachzuvollziehen, 
sondern immernur zwischen Tür und Angel auf dem Handy, was dann auch 
nicht wirklich erfolgreich war.
Ich werde mir das jetzt die nächste halbe Stunde anschauen und 
spätestens Morgen gebe ich dir dann ein Statement ab!

@Michael, danke für Routinen. Das werde ich auch mal in meinen Code 
werfen und schauen wo/was da am Terminal klemmt.

Gruß

David

[David D. (saturi)]

Edit: in diesem post stand nur wirres Zeug :D einfach ignorieren....

[Andreas S. (igel1)]

David D. schrieb:
> Hallo Andreas,
> ich wollte ein kurzes Lebenszeichen von mir geben!

Wir hatten schon befürchtet, dass man Dich im Karneval totgebützt hat.

Was Deinen Code angeht, hier die Zusammenfassung:

- bei jeglichen Operationen mit char-Variablen, werden diese zunächst
  in int verwandelt - das ist einfach so in C.

- diese Verwandlung führt zusammen mit der Maskierung mit „& 0x1FF“
  zu nicht vorhergesehenen Ergebnissen - z.B. landest Du nach Arraywert
  127 als nächstes nicht bei 128, sondern bei 385, weil 128 bei signed
  char eben -128 entspricht (binär 0x1000 0001), was in int verwandelt 
zu
  binär 0x1111 1111 1000 0001 wird, was mit 0x1FF maskiert zu
  0x0000 0001 1000 0001 wird, was wiederum 385 entspricht.

- ein weiterer Bug ist die Verwendung von signed char statt einem
  unsigned Typen.

- und die Maskenlänge mit 9 Bit passt nicht so recht zum char-Wert.

Heilung aus der ganzen Misere könnte die Umstellung aller im
Zusammenhang mit Index-Zugriffen verwendeten Variablen auf
unsigned int bringen.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

wollte mich auch nur mal kurz melden, im Moment nicht weiter mit dem 
Kram gemacht. Ich werde nachher mal meinen Kram und den Sniffer mal 
anwerfen und schauen, wie sein Terminal mit dem AVR zusammenspielt. 
Bedienen kann ich das Terminal immernoch nicht ;-), es ist also "Button 
anlicken", schauen, was geschickt wird, schauen, was sein AVR-Code 
zurücksenden sollte und schauen, ob das auch kommt.
Andreas, schön daß Du seinen UART-Buffer so auseinandegenommen hast, ich 
werde den auch weiterhin erstmal ignorieren.

Mich interessiert im Moment da eher, was passiert bzw. passieren soll, 
wenn ich mein Registerinit auskommentiere, also nur Davids Vorgehen aus 
dem Terminal nachvollziehen kann, wie ich da zu einem Bild komme.

Gruß aus Berlin
Michael

[David D. (saturi)]

Hallo,
Andreas S. schrieb:
> - diese Verwandlung führt zusammen mit der Maskierung mit „& 0x1FF“
>   zu nicht vorhergesehenen Ergebnissen - z.B. landest Du nach Arraywert
>   127 als nächstes nicht bei 128, sondern bei 385, weil 128 bei signed
>   char eben -128 entspricht (binär 0x1000 0001), was in int verwandelt
> zu
>   binär 0x1111 1111 1000 0001 wird, was mit 0x1FF maskiert zu
>   0x0000 0001 1000 0001 wird, was wiederum 385 entspricht.
...
> Heilung aus der ganzen Misere könnte die Umstellung aller im
> Zusammenhang mit Index-Zugriffen verwendeten Variablen auf
> unsigned int bringen.
>
Verstanden. Aktuell habe ich bei allen Bufferzugriffen unsigned char und 
die Buffergröße kleiner auf 128 (also kleiner als ein Byte). Diese 
Änderungen kamen aus der Beseitigungen der ganzen Warnings, womit der 
Compiler vermutlich auf genau auf das von dir beschriebene Problem
hinweisen wollte. Was ich jetzt noch nicht ganz nachvollziehen kann ist, 
warum ich auf unsigned int wechseln soll. Okay, wenn du davon ausgehst, 
dass die Maske 512 darstellt, komme ich mit einem Byte nicht mehr hin. 
Aber nach dem Rüffel von Michael einige Posts zuvor hatte ich die 
Buffergröße wieder zurückgenommen.
Dann sollte unsigned char doch genauso funktionieren oder tut es das 
nicht?
vielen Dank für die ausführliche Untersuchung.

Wenn es wirklich so ist, dass char zunächst in int umgewandelt wird, 
warum gibt es dann den Datentyp? wenn ich mir damit keinen Speicherplatz 
spare kann ich ihn ja komplett weglassen?

Gruß
David

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Aber nach dem Rüffel von Michael einige Posts zuvor hatte ich die
> Buffergröße wieder zurückgenommen.

naja, ein Rüffel sollte es ja nicht gleich sein...
Unser Herangehen ist da nur verschieden. Du hast versucht, ein mehr oder 
weniger universelles Konzept für verscheidene Sachen einzubauen, finde 
auch ich prinzipiell sinnvoll.
Mein Ansatz war/ist es: ich habe einen kleinen AVR und der soll mit 
einem Kameramodul was machen, wofür er eigentlich sowieso zu klein ist.
Das auch noch möglichst gut und schnell.
Da ordne ich für mich erstmal alles andere unter.

David D. schrieb:
> Wenn es wirklich so ist, dass char zunächst in int umgewandelt wird,
> warum gibt es dann den Datentyp? wenn ich mir damit keinen Speicherplatz
> spare kann ich ihn ja komplett weglassen?

Hier lehen ich mich jetzt mal aus dem Fenster, weil ich nur C 
Hobbyprogrammierer bin, Andreas möge also korrigieren/ergänzen.
C berechnet generell mit int-Werten. int auf dem AVR ist 16Bit, auf 
anderen CPUs meist 32Bit, ist Architekturabhängig.
char a = 5;
char b = 3;
char c = 0;
c = a+b:
In der Berechnung wird a und b generell auf int konvertiert, dann 
gerechnet und das Ergebnis nach char konvertiert und c zugewiesen. Platz 
spare ich also mit char schon, die Rechnerei in int ist c geschuldet, es 
war nie für eine 8Bit-Umgebung gedacht...
Die Fallen entstehen z.B. bei anderen Datentypen.
int a = 123;
float c = 0;
c = a/10;
Da enthält c nach der Berechnung nicht etwas 123/10 =12.3 sondern 12.0.
Da a ein int ist und 10 auch in einen int passt, wird als int gerechnet 
und das Ergebnis nach float gewandelt.
c = a/10.0; macht aus der Konstanten einen float und damit findet auch 
die Berechung als float statt und es kommt 12.3 raus.
Bei mir hat das zur Folge, daß ich im Zweifel gern Klammer bei 
komplexeren Sachen setze, wo dann die C-Könner aufheulen, weil das doch 
auch ohne Klammern eindeutig und logisch ist...

Gruß aus Berlin
Michael

[David D. (saturi)]

Ernüchterung:
auch mit unsigned int ergibt sich selbiges Verhalten. Schade, das 
sporadische Auftreten wäre sogut mit dem Überlauf des Buffers zu 
erklären gewesen.

[Andreas S. (igel1)]

David D. schrieb:
> Was ich jetzt noch nicht ganz nachvollziehen kann ist,
> warum ich auf unsigned int wechseln soll. Okay, wenn du davon ausgehst,
> dass die Maske 512 darstellt, komme ich mit einem Byte nicht mehr hin.

Genau aus diesem Grunde ...
Außerdem willst Du ja evtl. später einmal die Kamera ohne FIFO auslesen 
und dann wirst Du vielleicht die 512 Bytes benötigen - zumindest wenn Du 
QVGA auslesen willst und evtl. darauf angewiesen bist, dass Du im 
horizontalen Austastzeitraum die restlichen Pixel seriell übertragen 
kannst, weil  während der 2x320 Pixel-Ausgabe nicht genügent Zeit zur 
seriellen Übertragung war.

> Aber nach dem Rüffel von Michael einige Posts zuvor hatte ich die
> Buffergröße wieder zurückgenommen.

Hat er nicht so gemeint ;-)   (siehe letztes Posting)

Ich habe gerade übrigens alle Variablen, die in Zs.hang mit Indizes 
verwendet werden, in UART.c auf uint16_t gesetzt und außerdem noch ein 
oder zwei weitere Typ-Ungenauigkeiten behoben.

Seitdem funktioniert das Auslesen der Registerwerte über Dein 
Terminal-Programm wunderbar (Notiz: ich habe 115200 Baud 8N1 in UART.c 
hineingecoded, um Bitübertragungsmäßig 100% auf der sicheren Seite zu 
sein)

Testszenario: ATmega frisch gestartet, dann Terminal-Programm frisch 
gestartet, dann Baudrate im Terminal-Programm eingestellt, dann auf 
Button "verbinden" geklickt, dann auf Button "Read Device Settings" 
gedrückt (bis zu 30x hintereinander - stets ohne Probleme).

Nun könnten wir die nächsten Probleme angehen: bitte beschreibe 
diejenigen Bugs, die Du als nächstes fixen willst, dann kann ich 
zunächst versuchen, sie zu reproduzieren.

Vermutlich benötige ich dafür dann allerdings ein komplettes 
Terminal-Fenster, welches nicht am rechten Rand beschnitten wird (vgl. 
meinen alten Post: 
Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)" )
Wäre nett, wenn Du, David, das fixen könntest ...

Ach ja: bitte erstelle noch eine kleine Hilfedatei, in der Du Deine 
Oberfläche etwas beschreibst. Felder, wie über dem Button "senden" oder 
über dem Button "empfangen" sind nicht selbsterklärend (jedenfalls nicht 
für mich). Ebenso weiß ich nicht, was sich hinter dem Button "read for 
change" verbirgt und die Buttons ganz rechts verstehe ich auch nicht 
genau - um nur wenige Beispiele zu nennen.

Viele Grüße

Igel1

[Andreas S. (igel1)]

David D. schrieb:
> Ernüchterung:
> auch mit unsigned int ergibt sich selbiges Verhalten. Schade, das
> sporadische Auftreten wäre sogut mit dem Überlauf des Buffers zu
> erklären gewesen.

Nein - es funktioniert bei mir reproduzierbar gut:

Ersetze einfach einmal Deine UART.c und die OV7670_with_Fifo.c durch 
meine Versionen aus dem letzten Posting und berichte ...

Viele Grüße

Igel1


PS: bitte genau das Testszenario aus dem letzten Posting einhalten, 
sonst spucken Dir evtl. andere Fehler dazwischen.

[Andreas S. (igel1)]

Hi David,

ich hätte aktuell gerade etwas Zeit und könnte die nächsten Bugs 
untersuchen, benötige dazu aber etwas Feedback von Dir (siehe meine 
letzten Postings).

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Terminalprogramm: Kamara initialisieren -> ok
Auch mehrmals hintereinander -> kein Problem, ok
Macht nur wenig Sinn, weil da jedesmal u.a.
Ov7670_initPins(); und OV_SCCB_Init();
aufgerufen wird, was ja eigentlich wenig Sinn macht, eine Anzeige, daß 
Init erfolgt, ist gibt es ja nicht außer im Logfenster.

Dann get camera status -> ok, auch mehrmals.
Jetzt wieder Kamara initialisieren -> angeblich Error Code 4.
Angeblich, weil vom AVR definitv 0 zurückkommt und die 4 wohl von der 
Quittung bei get camera status stammt...

Wenn nach AVR-Reset und Terminalstart nicht Kamara initialisieren 
aufgerufen wird, sondern z.B. get camera status oder read Device 
Settings gibt es keine Fehler. Die gelesenen Werte sind natürlich Unfug, 
weil weder die Ca-Pins noch SCCB auf dem AVR initialisiert sind...

Wenn nach AVR Reset und Terminalstart direkt nach Verbinden get camera 
status aufgerufen wird (ohne Init!) sagt die Anzeige:
Version: 0x0 0x73
Resolution: QVGA
Color Format: RGB565

Wunsch? Wirklichkeit kann es da ja nicht sein...

Jetzt Kamara initialisieren (endet mit dem falschen Error 4).
Dann wieder get camera status und jetzt ist es VGA und YUV.
Wohl auch nicht besser?
Ich setze immernoch direkt nach OV7670_init(); meine beiden 
default-Rgisterwerte, eigentlich müßte die Cam also auf QVGA 565 stehen. 
Ich habe gerade mal ein paar Stichproben gemacht, die vom Terminal 
gelesenen Cam-Registerwerte passen auch zu meinen Settings.

Ich hör jetzt erstmal auf... ;-)
Richtige Lust, auf jeden Deiner Button zu klicken und im Sniffer zu 
schauen, was Du da jeweils sendest und was zurückkommt, habe ich auch 
nicht so richtig...

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> Ich hör jetzt erstmal auf... ;-)
> Richtige Lust, auf jeden Deiner Button zu klicken und im Sniffer zu
> schauen, was Du da jeweils sendest und was zurückkommt, habe ich auch
> nicht so richtig...

Hmmm - da kann ich Michael sogar ein bisschen verstehen.

@Dirk: ich glaube, Du musst Deine zwei Debugging-Knechte etwas bei Laune 
halten, indem Du den einen oder anderen Button gaaaanz genau 
beschreibst. Ich selber bin insbesondere an folgendem interessiert:

- was Du mit dem jeweiligen Button/Feld genau bezweckst.
- welche Zeichen Du versendest, wenn man den Button drückt.
- welche Antwort Du erwartest.

Natürlich könnten wir das alles auch aus Deinem Terminal-Programmcode 
per reverse-engineering heraustüfteln, aber, wie schon gesagt: auch ein 
Debugging-Knecht will ab und an verwöhnt werden :-)


Nächstes Thema:

Nachdem der Button "Read Device Settings" ja nun zuverlässig 
funktioniert, habe ich mich einmal dem Button "get camera status" 
zugewandt.

Mein LogicAnalyzer liest dabei folgende Bytefolge:

Sample  Nano    Nano
No  TX  RX
---------------------
0    
5234    01h
5320    0Ch
5407    0Dh
5493    0Ah
14492  0Ch  
39386  00h  
40611    01h
40698    12h
40784    0Dh
40870    0Ah
49475  12h  
74370  00h  
75367    01h
75453    1Ch
75540    0Dh
75626    0Ah
84459  1Ch  
109355  7Fh  
110693    01h
110779    1Dh
110865    0Dh
110952    0Ah
119444  1Dh  
144340  A2h  
145526    01h
145612    3Ah
145698    0Dh
145785    0Ah
154428  3Ah  
179324  0Dh  
180713    01h
180799    3Dh
180886    0Dh
180972    0Ah
189413  3Dh  
214309  88h  
215460    01h
215546    3Eh
215633    0Dh
215719    0Ah
224398  3Eh  
249293  00h  
250509    01h
250596    40h
250682    0Dh
250768    0Ah
259381  40h  
284276  C0h  
285334    01h
285420    42h
285507    0Dh
285593    0Ah
294365  42h  
319260  00h  
320262    01h
320349    70h
320435    0Dh
320521    0Ah
329349  70h  
354245  3Ah  
355467    01h
355553    71h
355639    0Dh
355726    0Ah
364334  71h  
389229  35h  
390369    01h
390456    0Ah
390542    0Dh
390628    0Ah
399318  0Ah  
424214  76h  
425358    01h
425444    0Bh
425531    0Dh
425617    0Ah
434303  0Bh  
459199  73h  
505116    04h
505203    80h
505289    02h
505375    0Dh
505462    0Ah
514918  04h  
524123

Das Ergebnis irritiert/überrascht mich in mehrfacher Hinsicht:

Punkt 1:

Die Button-Bezeichnung "get camera status" lässt ja eigentlich vermuten, 
dass hier nur Register ausgelesen werden.

Ab Sample No 505116 wird dann aber plötzlich ein Schreibbefehl 
abgesetzt:
0x04 0x80 0x02 0x0D 0x0A

Mit Blick auf Dein Posting vom 14.02.2019 20:20 
(Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)") ist 0x04 
der Control-Command für "set xResolution".


Punkt 2:

Wenn ich Deine Syntax-Beschreibung und meine 
LogicAnalyzer-Sniffing-Daten untereinander schreibe (Dein CR & LF blende 
ich einfach einmal aus), so sieht das wie folgt aus:

Command Auswirkung       Byte1             Byte2             expected Return Value
0x04    set xResolution  Resolution x MSB  Resolution x LSB  1 Byte xres. Value
0x04                     0x80              0x02              0x04

Punkt 2a:

Deine Doku aus dem Posting und die tatsächlich gesendeten Daten stimmen 
nicht überein, denn Du sendest zunächst das LSB und dann erst dass MSB - 
in dem Posting hast Du es aber genau umgekehrt dokumentiert.
Ist das so gewollt oder ist das ein Bug?

Punkt 2b:

Ich hatte nie so richtig verstanden, wie der "expected Return Value" in 
diesem Falle funktionieren soll:  Mit "1 Byte xresolution Value" 
könntest Du ja eine max. X-resolution von 256 darstellen.
Anyway - statt dessen kommt als Antwort 0x04 - das irritiert mich noch 
mehr.


Punkt 3:

Nachdem Du die X-resolution per Befehl setzt, hätte ich jetzt eigentlich 
erwartet, dass anschließend die Y-resolution gesetzt wird. Aber nach dem 
Empfang von 0x04 vom MC scheint die Kommunikation abzubrechen.

Erwartet das Terminal-Programm an dieser Stelle noch weitere Bytes vom 
MC oder erwartet der MC noch weitere Bytes vom Terminal-Programm?

Ich tippe auf ersteres.

Diese Annahme würde bedeuten: beim Befehl 0x04 geht irgendetwas auf 
MC-Seite schief. Der nächste Job wäre dann also, den MC-Code etwas zu 
durchwühlen ...
Schau'n wir mal ...


Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Die Button-Bezeichnung "get camera status" lässt ja eigentlich vermuten,
> dass hier nur Register ausgelesen werden.
>
> Ab Sample No 505116 wird dann aber plötzlich ein Schreibbefehl
> abgesetzt:
> 0x04 0x80 0x02 0x0D 0x0A

Richtig. Er setzt 640 als width (LSB/MSB). Das macht er im AVR auch 
richtig. Warum auch immer er das dort setzt...

Andreas S. schrieb:
> Nachdem Du die X-resolution per Befehl setzt, hätte ich jetzt eigentlich
> erwartet, dass anschließend die Y-resolution gesetzt wird. Aber nach dem
> Empfang von 0x04 vom MC scheint die Kommunikation abzubrechen.

Auch richtig, Kommando 0x04 wird hartcoded mit 0x04 beendet.

Andreas S. schrieb:
> Diese Annahme würde bedeuten: beim Befehl 0x04 geht irgendetwas auf
> MC-Seite schief. Der nächste Job wäre dann also, den MC-Code etwas zu
> durchwühlen ...

Nein, der AVR Code macht genau daß, was Du auch gesehen hast.

Mein Problem im Moment ist einfach, daß ich seine geplanten Abläufe 
nicht verstehe. Wie soll aus dem Terminal wann und womit in der Kamera 
gesetzt werden um zu einem Bild in gewünschter Auflösung und Format zu 
kommen?

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hmmm - kaum will ich den MC-Code in Sachen "Command 0x04 - set 
xResolution" durchwühlen, da fällt mir auf, dass das Schreiben von 
Registern aus der Terminal-Oberfläche heraus Fehlermeldungen wirft.

Wenn das der Fall ist, so ist dieser Bug natürlich wichtiger und somit 
als erstes zu behandeln.

Szenario:

- Ich verwende den Code aus meinem letzten Posting mit Code-Anhängen 
(Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)").

- Ich starte den Nano frisch (= Versorgungsspannung wird angelegt).

- Ich startet das Terminalprogramm frisch.

- Ich setze die Baudrate auf 115200 und verbinde mich mit dem MC per
  Button "verbinden"

- Ich lese einmalig alle Register aus per Button "Reade Device Settings"

- Ich lese Register 0x00 (=GAIN) per Button "read for change" aus

- Ich Trage im Fensterbereich "Write Register" für Register 0x00
  als value 0x11 ein.

- Klick auf Button "write register" führt in der Fußleiste des
  Terminal-Fensters zur Fehlermeldung "Register Write Failed! ErrorCode 
105"

- Ein anschließender Klick auf Button "read register" ergibt als
  "Result" den Wert 0x6A, der nun angeblich in Register 0x00 stehen 
soll.

- Nachfolgende Operationen lesen/schreibe/lesen ergeben noch 
unlogischere
  Werte.

Fazit: da muss noch ein dicker Hund begraben sein. Ich fürchte, das 
sollten wir als allererstes fixen.

Viele Grüße

Igel1



PS:  weitere interessante Beobachtung: Habe in Register 0x01 einmal 
testweise den Wert 0x81 geschrieben. Ein Auslesen genau dieses Registers 
hat den Erfolg bestätigt. Ein Auslesen aller Register in einem Schwung 
zeigte dann allerdings den Wert 0x80? Bin mehr als irritiert darüber ...

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> - Ich startet das Terminalprogramm frisch.
>
> - Ich setze die Baudrate auf 115200 und verbinde mich mit dem MC per
>   Button "verbinden"
>
> - Ich lese einmalig alle Register aus per Button "Reade Device Settings"

wenn Du kein "kamera initialisieren" machst, sind weder die Cam-Pins 
noch SCCB initalisiert und Du hast Dir nur eine Würfelbude gebaut.
Siehe mein Post vom 06.03.2019 10:26 Uhr.

Gruß aus Berlin
michael

[Andreas S. (igel1)]

Michael U. schrieb:
> wenn Du kein "kamera initialisieren" machst, sind weder die Cam-Pins
> noch SCCB initalisiert und Du hast Dir nur eine Würfelbude gebaut.
> Siehe mein Post vom 06.03.2019 10:26 Uhr.

Sicher?

Ich dachte, der Aufruf von "OV7670_init();" relativ am Anfang von main() 
erledigt das?

Liege ich da falsch?

Viele Grüße

Igel1

[David D. (saturi)]

Hallo, Wow ihr habt ein Tempo drauf!
Das freut mich!
Umsomehr freut es mich, dass igel es offensichtlich geschafft hat, durch 
konsequentes umsetzen des Bufferzugriffs alle Register auslesen zu 
können. Ich werde schauen und verstehen, wo die Unterschiede unserer 
Codes liegen und deine Änderungen übernehmen.


Ich hoffe, ich werde keine Fragen offen lassen:

erstmal: Kamera initialisieren muss am Terminal nicht zwangsläufig 
gedrückt werden. Beim start von meinem AVR wird die init routine 
aufgerufen. Mit dem Button wollte ich die Möglichkeit liefern, diese 
Initialisierungsfrequenz per Terminal erneut auszuführen, falls nach dem 
Register schreiben mal garnichts mehr geht. (Das wirft aber glaube ich 
noch Fehler)
Allerdings weiß ich nicht, was Michael alles in meinem Code gekürzt hat:

>>Version: 0x0 0x73
>>Resolution: QVGA
>>Color Format: RGB565
Sollte jedenfalls nicht rauskommen, wenn man frisch startet (und mit 
frisch meine ich auch die Kamera zu initialisieren und einen Register 
Reset auszuführen)
Wichtig: wenn die Kamera am strom hängen bleibt und kein Reset 
durchgeführt wird, behällt sie logischer Weise ihre Registerwerte)

jetzt zu den Punkten:

>@Dirk: ich glaube, Du musst Deine zwei Debugging-Knechte etwas bei Laune
>halten, indem Du den einen oder anderen Button gaaaanz genau
>beschreibst. Ich selber bin insbesondere an folgendem interessiert:
David ;-)

- was Du mit dem jeweiligen Button/Feld genau bezweckst.
- welche Zeichen Du versendest, wenn man den Button drückt.
- welche Antwort Du erwartest.

Das habe ich mit der von der gefundenen Excel Docu eigentlich versucht 
zu Dokumentieren. Nevertheless die Hilfe Datei wird kommen. Das mit dem 
vertauschten LSB und MSB überprüfe ich, sobald ich endlich nochmal an 
meinem Rechner sitze:

>Die Button-Bezeichnung "get camera status" lässt ja eigentlich vermuten,
>dass hier nur Register ausgelesen werden.
>
>Ab Sample No 505116 wird dann aber plötzlich ein Schreibbefehl
>abgesetzt:
>0x04 0x80 0x02 0x0D 0x0A
genau, es sollten xRes, yRes und BytesPerPixel nacheinander geschrieben 
werden
@Michael: Die brauche ich am AVR um die Enden der For-Schleifen beim 
Buffer ReadOut zu steuern, und später evtl. auch einmal für eigene 
Auflösungen flexibel zu sein.
Die expected return value ist, wie von michael schon erkannt hardgecoded 
in der Main vom uC: für xRes 0x04 yres 0x05 und BPP 0x06 (Doku stimmt 
also nicht)... wenn ihr jetzt immer einen Fehlercode 0x04 habt frage ich 
mich natürlich grade ob ich das richtig im Terminal verarbeite. Bei 
einem klick auf read register oder read all register wird allerdings der 
Buffer am PC gelöscht.

Meine Empfehlung wäre es die "write All Register" als erstes zu 
überpüfen, ob ich hier zuverlässig alle Register schreiben kann. (Bei 
dem get Camera status sind evtl. Fehler im Terminal programm momentan 
nicht auszuschließen.)

So, die eh verspätete Pause leider schon wieder vorbei. Ich danke euch 
für den moment und hoffe zumindet ein kleines Bisschen auf eure Fragen 
eingegangen zu sein.

Bis heute Abend

David (nicht Dirk ;-) )

PS: Read for Change hatte mal einer von euch beiden gefragt macht 
einfach nur ein ganz normales Register read out und trägt die Register 
Adresse und die gelesen Value in das Write feld ein um dann ggf. nur ein 
einzelnes Bit ändern zu können.

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Ich dachte, der Aufruf von "OV7670_init();" relativ am Anfang von main()
> erledigt das?
>
> Liege ich da falsch?

nö. Wo Du Recht hast, hast Du defnitiv Recht...
Gerade mal probiert: Reg 0x00 läßt sich nicht beschreiben, ab 0x01 geht 
es...
Keine Zeit jetzt, da nachzugraben. 105 als Errorcode bei Dir ist auch 
seltsam, eigentlich gibt er da nur kleine Codes zurück?

Gruß aus Berlin
Michael

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> genau, es sollten xRes, yRes und BytesPerPixel nacheinander geschrieben
> werden

das passiert laut Sniffer nicht, xres wird geschickt und mit 0x04 
quittiert, danach sendet das Terminal bei mir nichts mehr.

David D. schrieb:
> Meine Empfehlung wäre es die "write All Register" als erstes zu
> überpüfen, ob ich hier zuverlässig alle Register schreiben kann.

Gerade noch "Schnelltest" gemacht: Reguster 0 wird auch da nicht richtig 
beschrieben, da war anschlißend 0xFF drin. Der Rest schien stimmen, da 
muß ich aber noch in Ruhe anschauen.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Nachtrag zum "Read Device Settings":

Habe gerade festgestellt, dass nach Abfrage des letzten Registers 0xAF 
völlig überraschend vom Terminal-Programm noch ein "0x04 0x80 0x02 0x0D 
0x0A" hinterher geschickt wird.

Ich vermute, das ist nicht beabsichtigt, sondern eher ein Bug?

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

gerade mal schnell geschaut: da hast Du völlig Recht.
Halte ich auch für einen Bug.
Er schickt z.B. auch beim Start des Terminals 0x0D 0x0A raus, das hat so 
zwar keine Bedeutung, aber wenn sich sowas z.B. mit Fehlern in 
UART-Bufferverwaltung oder dem Kommando-Parser trifft, sucht man schnell 
an völlig falschen Stellen.

PS: gerade über Deinen LogicAnalyzer Thread gestolpert: Dein Problem 
dürfte eher sein, eine Software mit Protokolldarstellung für UART dazu 
zu finden.
100kB Sampletiefe bei 10 oder 20MHz Samplerate müßte auch ein ESP32 mit 
I2S-DMA gut machen, mit den STM habe ich ja noch nie was gemacht, keine 
Ahnung, wieviel Ram man da im Stück hat. Zum Rechner schaffen ist ja 
auch nicht unlösbar.
Trotzdem muß man es dann ja noch anzeigen und auswerten können.
Ich weiß im Moment ja auch noch nicht, wie weiter, die Demo des Sniffers 
von Eltima läuft ja auch in 2 Tagen bei mir ab, die Software selbst ist 
einfach genial.
Notalls geht eben die Einrichterei mit COM2COM o.ä. auf dem PC los, da 
reiße ich mich aber auch nicht drum...

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> Hallo,
>
> gerade mal schnell geschaut: da hast Du völlig Recht.
> Halte ich auch für einen Bug.

Okay, dann sind wir uns einig.

> Er schickt z.B. auch beim Start des Terminals 0x0D 0x0A raus,

Richtig, war mir auch schon aufgefallen.

> das hat so
> zwar keine Bedeutung, aber wenn sich sowas z.B. mit Fehlern in
> UART-Bufferverwaltung oder dem Kommando-Parser trifft, sucht man schnell
> an völlig falschen Stellen.

Korrekt. Im Falle von dem 0x0D 0x0A, was nach dem Verbindungsaufbau 
geschickt wird, meine ich sogar, dass dies im Code (Routine 
"UART0_rx_work") gar nicht abgefangen wird und tatsächlich 0x0D als 
Command betrachtet wird.

Und überhaupt - ich verstehe in dieser Routine "UART0_rx_work" so 
einiges nicht. Hier ein Ausschnitt mit meinen Fragen:

int UART0_rx_work(int* Programmstatus)
{

//igel1: Warum wird hier UART0_rx_complete() aufgerufen, wo es doch
//       schon vor dem Aufruf der Routine "UART0_rx_work" aufgerufen 
//       wurde?

  if(UART0_rx_complete())
  {

  char Befehl[UART0_Befehl_FiFo] = {};      // Hier steht der Befehl
  volatile int j = 0;
  volatile int i = 0;

//igel1: Was ist der Sinn und Zweck dieser while-Schleife ??
//       Warum so kompliziert?
//       Was hat sich David dabei gedacht, was wir möglicherweise
//       übersehen?
  do
  {
    char temp = UART0_rx_out();
      
    Befehl[i] = temp;
    i++;

    //Künstlicher Zähler, um das Abfragen der beiden Bits auch beim ersten zu ermöglichen
    if(i<2)
    j=1;
    else
    j=0;
//igel1:  Hier passt der Kommentar nicht zum Code: es wird nicht
//        auf "CR UND LF" geprüft, sondern auf "CR ODER LF".
//        Da ich den Sinn und Zweck des Codes aber nicht verstehe,
//        so kann ich nicht beurteilen, ob der Kommentar oder der
//        Code falsch sind.
  }while(((Befehl[i+j-2] != (char)0x0D) || (Befehl[i-1] != (char)0x0A))&&(i<10));        // solange kein CR+LF erkannt wird

Anderes Thema:

Mal 'ne ganz doofe Frage: könnte ich eigentlich mit dem Dragon das 
Programm von David auch Schritt für Schritt (quasi im Single-Step-Modus) 
debuggen?

Also z.B. im obigen Fall exakt nachprüfen, welche Wirrungen und Irrungen 
das Programm nach einem 0x0D 0x0A so nimmt?
Mein Dragon sagt mir "ISP on AVR Dragon does not support debugging".

Mit den ARM-Prozessoren und meinem J-Link geht so ein Debugging super 
genial.

> PS: gerade über Deinen LogicAnalyzer Thread gestolpert: Dein Problem
> dürfte eher sein, eine Software mit Protokolldarstellung für UART dazu
> zu finden.

Ja, es gibt 1000 Projekte, aber ich habe die richtige Lösung noch nicht 
gefunden. Ich glaube, ich muss mir doch so ein Saleae-Clone bestellen - 
obwohl mir das widerstrebt, weil ich das Gefühl habe, die echten 
Entwickler damit um ihren gerechten Lohn zu bringen.

Gleichzeitig ist mir das Geld für das Original für diesen einen Zweck 
aber auch zu viel ... hmmmm ...

Und bis das Dingen aus China angekommen ist, ist mein Urlaub auch schon 
3x vorbei - Mist.

> 100kB Sampletiefe bei 10 oder 20MHz Samplerate müßte auch ein ESP32 mit
> I2S-DMA gut machen, mit den STM habe ich ja noch nie was gemacht, keine
> Ahnung, wieviel Ram man da im Stück hat. Zum Rechner schaffen ist ja
> auch nicht unlösbar.
> Trotzdem muß man es dann ja noch anzeigen und auswerten können.

Korrekt - und dafür braucht's fertige, freie Software.
Ich fange hier nicht an, einen LA zu programmieren - Du selbst weißt ja, 
welch ein Aufwand das ist.

> Ich weiß im Moment ja auch noch nicht, wie weiter, die Demo des Sniffers
> von Eltima läuft ja auch in 2 Tagen bei mir ab, die Software selbst ist
> einfach genial.

Ja, schade.

> Notalls geht eben die Einrichterei mit COM2COM o.ä. auf dem PC los, da
> reiße ich mich aber auch nicht drum...

Ach ja COM2COM - das hatte ich auch mal probiert.
Habe halt immer in bißchen Respekt vor solchen Dingen, die mir zu tief 
in die Windows-Treiber eingreifen - da weiß man nie, welche 
Seiteneffekte dabei rumkommen.

Anyway - ich denke, früher oder später müssen wir da ran.

Viele Grüße

Igel1

[Andreas S. (igel1)]

Habe mich gerade ein bisschen schlauer gemacht in Sachen Debugging.

Vermutlich erzähle ich Euch nichts Neues, aber debugWire scheint hier 
das Zauberwort zu sein.

Und damit debugWire funktioniert, muss man auf dem Nano sowohl den 
1k-Pullup-Widerstand als auch den Kondensator C4 vom Reset-Anschluss 
entfernen.
Korrekt?

Hmmm - und das, wo ich jetzt alles so schön verdrahtet habe - das muss 
ich mir aber 3x überlegen.

Wenn man nach der Nutzung von debugWire wieder nach ISP zurückschaltet, 
geht dann das Programmieren via ISP und AS7 noch problemlos? Ich las 
verschiedentlich, man müsse dann manuell resetten, was ich irgendwie 
nicht verstehe, denn der RESET-Pin vom ATmega328p ist doch nach wie vor 
mit der entsprechenden ISP-RESET-Leitung verbunden?!

Hmmm ...

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Korrekt. Im Falle von dem 0x0D 0x0A, was nach dem Verbindungsaufbau
> geschickt wird, meine ich sogar, dass dies im Code (Routine
> "UART0_rx_work") gar nicht abgefangen wird und tatsächlich 0x0D als
> Command betrachtet wird.

Du willst damit ausdrücken, daß ich mir das doch mal anschauen soll???
Ehrlich gesagt, ich wollte wegen David nur etwas mit OV7670 am AVR 
rumspielen..........

Andreas S. schrieb:
> Vermutlich erzähle ich Euch nichts Neues, aber debugWire scheint hier
> das Zauberwort zu sein.

Ich sage es mal so: man kamm mit dem Dragon am Mega328 debugWire nutzen, 
ja.
Der PullUp an Reset ist mit 1k zumindest grenzwertig, wenn er drin 
bleibt, könnte aber noch gehen. Der 100nF von Reset zum UART-chip muß 
auf jeden Fall raus, das spielt aber nur eine Rolle, wenn man direkt aus 
der ArduinoIDE mit dem Bootloader flasht.
Der AVR kann sich gern mal verheddern, wenn er im debugWire ist und 
irgendwie richtig abstürzt. SPI läßt sich aus debugWier NUR über 
debugWire wieder einschalten znbd man diskutiert dann gern mit dem 
Studio und dem Dragon, weil der meinst, daß der Mega328 nicht im 
debugWire-Mode wäre und ISP auch nicht geht. Läßt sich aber lösen, wenn 
es passiert.
Ich selbst habe es real nie wirklich benutzt.........

Andreas S. schrieb:
> Ach ja COM2COM - das hatte ich auch mal probiert.
Ich sage es mal so: wenn ich mir mit Win7 unsicher bin, wird die 
Free-Version von Macrium Reflect gestartet und nebenbei ein Image der 
Systempartition erstellt. Ganz früher (tm) habe ich da Acronis benutzt, 
das ist mir aber irgendwann zu kolossal und nervig geworden.

So, jetzt diskutiere ich aber erstmal mit meiner 64x64 LED-Matrix noch 
etwas, aber mehr zur Entspannung. ;)
Außerdem habe ich jetzt noch eine niedliche BT-Tastatur und eine Idee, 
aber dazu müßte ich mich mit ESP32 und BT näher auseinandersetzen, damit 
der mit der Tastatur redet.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Mist - David's Mittagspause scheint ihm heute gestrichen worden zu sein.
Dabei könnten wir gut ein bisschen Input gebrauchen ...

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Mist - David's Mittagspause scheint ihm heute gestrichen worden zu sein.
> Dabei könnten wir gut ein bisschen Input gebrauchen ...

Berliner ist er ja auch nicht, also morgen für ihn auch kein Feiertag...
Ich kann ja mal schauen, was da mit dem Rgister schreiben passiert, das 
macht ja mit meinem UART-Kram auch nicht, was es soll.

UART0_rx_work() habe ich bei mir ohnehin auskommetiert und habe das 
direkt in seinen switch in main eingebaut und erledige das gleich aus 
meinem rx_buffer ohne seine Hilfsvariablen.

ok. mein Display sieht immernoch etwas seltsam aus...

Gruß aus Berlin
Michael

[David D. (saturi)]

Nabend Männers...
Ja, in der kurzen Mittagspause war heute leider kein Handy drin ;-)

@Igel & DebugWire: Mein lieb gemeinter Rat: Beim Nano finger weg, wenn 
kein Ersatz zu Hand ist. Ich habe hier einen liegen, wo ich dachte: "ich 
aktivier mal kurz die debugWireFuse" und seit dem bin ich ausgesperrt :D 
weil wenn das mit dem Widerstand und dem Kondensator nicht funktioniert 
(hatte ich damals nicht ausprobiert) kannst du, wie Michael schon 
erklärt hat, nicht mehr per ISP flashen/Fuses setzen, solange du das 
nicht vom debugwire aus machst.
oder ebenfalls per dragon aber einiges komplizierter das HV-Programming 
machst.

Ich nutze aber den Uno, hier hat man sogar ein extra lödpad "Reset En", 
dass man einfach mit dem schraubenzieher frei kratzen kann und ab dann 
ist das setzten der debug-wire nur noch formsache um schritt für schritt 
debuggen zu können.

Ihr habt ja schon einiges Entdeckt, was ich alles sooo gerne 
ausprobieren würde und hoffentlich auch bald werde

Meine Kommentare:
>Habe gerade festgestellt, dass nach Abfrage des letzten Registers 0xAF
>völlig überraschend vom Terminal-Programm noch ein "0x04 0x80 0x02 0x0D
>0x0A" hinterher geschickt wird.

Nennen wir es halber Bug :D nachdem alle Register gelesen wurden, habe 
ich es offensichtlich für Sinnvoll erachtet wieder den "Sync" zwischen 
Terminal und uC zu vollziehen und xRes, yRes und BpP zu senden. 
(Übrigens die Doku war falsch, zuerst LSB dann MSB) warum er dann 
abbricht und nicht yRes und Bpp schickt ist mir noch nicht klar, dem 
muss ich noch auf den Grund gehen, aber das Problem haben wir ja schon 
vorher identifiziert.
 Wenn an dieser Stelle keine Antwort vom uC kommt, ist dass übrigens der 
Grund

>Er schickt z.B. auch beim Start des Terminals 0x0D 0x0A raus,...

oh man... das sollte definitiv nicht sein, mal gucken, ob ich das auch 
noch finde xD

>//igel1: Warum wird hier UART0_rx_complete() aufgerufen, wo es doch
>//       schon vor dem Aufruf der Routine "UART0_rx_work" aufgerufen
>//       wurde?
berechtigte Frage, ist überflüssig, bzw. in der main überflüssig. Da 
habe ich offensichtlich meine Genialität beim Funktionen schreiben 
unterschätzt ;-) :D


>//igel1: Was ist der Sinn und Zweck dieser while-Schleife ??
>//       Warum so kompliziert?
>//       Was hat sich David dabei gedacht, was wir möglicherweise
>//       übersehen?
  Diese funktion liest den ersten Befehl aus dem Buffer. Es könnten ja 
auch mehrere im Buffer liegen, die ich dann trennen muss, das mache ich 
mit dieser Funktion... Wenn du da eine wesentlich einfachere Idee hast, 
lasse ich mich sehr gerne Belehren :D

>//igel1:  Hier passt der Kommentar nicht zum Code: es wird nicht
>//        auf "CR UND LF" geprüft, sondern auf "CR ODER LF".
Naja, nach meiner Auslegung ist beides richtig: Ich prüfe auf CR und LF:
CR&CL = !!(CR&&CL) = !(!CR||!CL)  -->Da wir aber solange in der While 
schleife bleiben wollen, wie diese Bedingung nicht erfüllt ist, eine 
weiter Verneinung: !!(!CR||!CL) = (!CR||!CL) --> siehe code

  }while(((Befehl[i+j-2] != (char)0x0D) || (Befehl[i-1] != (char)0x0A))&&(i<10));        // solange kein CR+LF erkannt wird

Die (i<10) ist nur eine "Notfallbremse" falls mal aus irgendeinem Grund 
kein CR+LF gefunden wird, was aber eigentlich nicht vorkommen dürfte. 
(Aber hatte offensichtlich mal Probleme damit, sonst hätte ich es nicht 
eingebaut :D )


PS: und nein... morgen ist kein Feiertag und am Wochenende kommen die 
Schwiegereltern --> wieder wenig Zeit... es bleiben eben immernur die 
Abenden -.-

[David D. (saturi)]

Problem Solved: ab jetzt wird auch nach xRes yRes und BpP gesendet und 
die entsprechende Antwort überprüft.

warum sende ich am Terminal CR+LF auch das weiß ich wieder :D auch wenn 
der Punkt vlt. etwas beschämend ist:

beim Verbindes des Com anschlusses werden zeichen geschickt, die ich 
nicht beeinflussen kann. Scheint irgendein standard zu sein, jedenfalls 
wird das bei der COM-Port library von microsoft so gemacht... um diese 
Zeichen einfach zu verwerfen sende ich einfach ein CR+LF hinterher, 
womit das ganze als "Befehl" interpretiert wird, in der Switch anweisung 
im UART_Work aber nicht aufzufinden ist und somit einfach verworfen 
wird.

Edit: anbei noch der neue Release: incl. kurzfristigem Design umbau zur 
besseren Handhabung für Igel... habe es auf die Schnelle leider nicht 
besser hinbekommen
https://github.com/igittigitt/ov7670/tree/TWI-Interfac/OV7670-Terminal-Releases

[Michael U. (amiga)]

Hallo,

zu debugWire: Du nußt mit debugWire den Mode beneden, nur dann wechselt 
der AVR wieder auf ISP. Man bekommt den Chip wirklich nur per debugWire 
wieder in den Normalzustand. Problem ist dann gern, daß z.B. der Dragon 
nicht im debugWire conncted, weil er meint, der Chip wäre nicht im 
debugWire.
Da gibt es aber irgendwo einen Tipp, wie man den überreden kann.

David D. schrieb:
> Diese funktion liest den ersten Befehl aus dem Buffer. Es könnten ja
> auch mehrere im Buffer liegen, die ich dann trennen muss, das mache ich
> mit dieser Funktion... Wenn du da eine wesentlich einfachere Idee hast,
> lasse ich mich sehr gerne Belehren :D

Ich habe damit direkt kein Problem, aber das hängt eben von einer 
konkreten Anwendung ab. Wenn, wie hier ein Quittunhsverhalten zwischen 
Terminal und AVR benutzt wird, kann es keine mehreren Befehle geben, 
weil eben das Terminal nicht schicken darf, bevor es die Quittung des 
vorigen verarbeitet hat.
Es würde ja z.B. auch meist keinen Sinn machen, z.B. 3 Befehle 
hintereinander zu schicken und dann einen Errorcode beim 1. 
zurückzubekommen, der den Ablauf dann völlig aus dem Konzepte bringen 
kann.
Zumindest wäre das meine Vorstellung davon.

David D. schrieb:
> warum sende ich am Terminal CR+LF auch das weiß ich wieder :D auch wenn
> der Punkt vlt. etwas beschämend ist:

ok, ist dann klar, stört ja auch nicht. Ich muß mir das mal mit dem 
Sniffer ansehen, aufgefallen ist mir da eigentlich nichts überzähliges 
beim Start.

David D. schrieb:
> Wenn an dieser Stelle keine Antwort vom uC kommt, ist dass übrigens der
> Grund

Das 0x04 als Quittung von xRes kommt definitiv com AVR, vom Termial 
kommt aber nichts weiter danach.

Gruß aus Berlin
Michael

[David D. (saturi)]

Doch jetzt schon

[Andreas S. (igel1)]

Hi Leute,

schön, dass Du, David, eine neue Terminal-Version online gestellt hast!

Und schon gibt's Gemecker, denn: wo ist die Status-Fußleiste hin?
Die war sehr hilfreich beim Debuggen.
Falls möglich, bitte dringend wieder einbauen!

Habe Deine Erläuterungen zu der von mir angefragten Codesektion beim 
ersten Lesen noch nicht ganz verstanden. Ich muss es nachher nochmals 
genauer lesen.

Als David sein Posting mit dem Hinweis a la "lass die Hände weg vom 
DebugWire-Umbau des Nanos" eingestellt hat, war ich gerade mit dem 
Lötkolben zugange und habe daher seine Warnung nicht gesehen.
Aber ich hatte offenbar mehr Glück als er, denn ich habe nun einen 
wunderbar funktionierenden Nano, der DebugWire spricht.

Alles frei nach dem Rheinisches Grundgesetz: Et hätt noch emmer joot 
jejange..

Die Rolle rückwärts von DebugWire zu ISP hat zwar beim ersten Mal nicht 
funktioniert, aber nach etwas wildem Rumprobieren, hat auch das 
geklappt.
... was wiederum die universale Gültigkeit des Rheinische Grundgesetzes 
unterstreicht ...

Jetzt muss ich mich erst einmal mit dem Debugger von Atmel Studio 7 
anfreunden (... noch sind wir keine echten Freunde ...).
Scheint alles Meilen hinter der ARM-Technik hinterher zu hinken.

Viele Grüße

Igel1

[David D. (saturi)]

Das war keine Absicht... Achtung version 1.7.1 verwenden!
https://github.com/igittigitt/ov7670/tree/TWI-Interfac/OV7670-Terminal-Releases


da hab ich wohl beim scrollen ausversehen ne dropdown gedreht...
 Jetzt hast dus aber aufjedenfall wieder.


zum Debug-Wire mit Nano, dann hätte ich gerne von dir die Anleitung bzw. 
website wo beschrieben ist, was man zu löten hat.


Gib mir einfach Rückmeldung wenn das Verstehen beim zweiten Lesen besser 
funktioniert hat :D ansonsten muss ich wohl nochmal in etwas 
verständlicherem Deutsch schreiben.

[Andreas S. (igel1)]

David D. schrieb:

> zum Debug-Wire mit Nano, dann hätte ich gerne von dir die Anleitung bzw.
> website wo beschrieben ist, was man zu löten hat.

Danach habe ich zunächst auch 2h gesucht - erfolglos.
Dann bin ich einfach frei nach Schnauze vorgegangen.

Eine 1:1 Anleitung kann ich Dir nicht geben, weil ich festgestellt habe, 
dass es mindestens ein halbes Dutzend unterschiedliche Nano-Clone 
Layouts gibt (meines z.B. ist das hier: 
https://www.aliexpress.com/item/Mini-USB-Nano-V3-0-ATmega328P-CH340G-5V-16M-Micro-controller-board-for-arduino-NANO-328P/32951657212.html).

Wichtig ist nur: Damit DebugWire funktioniert, darf kein Kondensator am 
Reset-Pin des ATmega hängen und der Pullup am Reset-Pin muss mindestens 
10k haben (auch darin unterscheiden sich angeblich die Boards).

Dann schaust Du Dir das Schaltbild Deines Nano-Clones (meist mit CH340) 
genau an (ich habe hier geguckt: 
http://actrl.cz/blog/wp-content/uploads/nano_ch340_schematics-rev1.pdf).

Und dann versuchst Du die Leitungen zu verfolgen und misst zusätzlich 
mit dem Multimeter so lange herum, bis Du Dir absolut sicher bist, 
welcher Kondensator der Reset-Kondensator ist und welcher Widerstand der 
Reset-Widerstand ist. Das ging bei mir wesentlich schneller als die 2h 
erfolglose Internet-Recherche vorher.

Wenn der Reset-Widerstand 10k ist (wie in meinem Falle), so hast Du 
Glück und kannst ihn drin lassen. Der Kondensator muss in jedem Falle 
ausgelötet werden.

Wie Du von ISP auf DebugWire in AS7 umstellst, solltest Du aus Deinen 
Erfahrungen mit dem Uno-Board ja schon wissen.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Das war keine Absicht... Achtung version 1.7.1 verwenden!

tolle Wurst! ;-))
Jetzt habe ich rechts schönen großen Bereich im Fenster für Notizen und 
kann das Fenster nicht mehr kleiner schieben... :-))

Andreas S. schrieb:
> Danach habe ich zunächst auch 2h gesucht - erfolglos.
> Dann bin ich einfach frei nach Schnauze vorgegangen.

naja, Schaltungen zu den nanos gibt es im Netz, grundsätzlich ist da 
also immer ein PullUp und ein Kondensator für den Reset über DTR dran. 
Wo die auf den Versionen gelandet sind und welchen Wert die haben, ist 
dem Zufall überlassen. Suchen auf den Boards geht da immer schneller, 
als die Hoffnung, einen passenden "Bestückungsplan" zu finden. ;)

OT:
Falls es Dich tröstet: von meinen "Lieblings-"Display gibt es ungefähr 
genauso viele Varianten, die wohl nichtmal die Chinesen selbst 
auseinanderhalten können. Die von mir probierten Libraries können die 
vielleicht/manchmal/meist aus ansteuern. Irgendwie...

Inzwischen benimmt sich das 64x64 wie gewünscht, mein Bekannter war 
etwas schneller damit, die richtige Einstellung zu finden.
Falls es interessiert mal bei YouTube nach
led matrix 64x64 smartmatrix fastled
suchen und einen Blick auf die Demos dort werfen.
Nun muß mir nur noch eine Anwendung einfallen. :-)

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

@David:

Wunderbar: die Statusleiste im Fußbereich ist in Version 0.7.1 wieder 
drin.

Gleichzeitig stelle ich fest, dass ein "Read Device Settings" nun nicht 
mehr nur die Register 0x00 - 0xAF, sondern 0x00 - 0xC9 abfragt - voll 
korrekt.

Am ATmega-Code hast Du nichts verändert - dann verwende ich dort nach 
wie vor Deinen Originalcode, in dem ich allerdings drei Dateien durch 
diejenigen aus meinem Posting vom 05.03.2019 22:54 
(Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)") 
ersetze.

Weiter geht's ...

[Andreas S. (igel1)]

Michael U. schrieb:
> David D. schrieb:
>> Wenn an dieser Stelle keine Antwort vom uC kommt, ist dass übrigens der
>> Grund
>
> Das 0x04 als Quittung von xRes kommt definitiv com AVR, vom Termial
> kommt aber nichts weiter danach.
>

Daraufhin schrieb David D. im Beitrag #5762742:
> Doch jetzt schon

Wenn Ihr Euch auf das "Read Device Settings" bezieht, so hat Michael 
recht:
Nach dem Auslesen des letzten Registers 0xC9 kommt noch ein 0x04 0x80 
0x02 0x0D 0x0A vom Terminal und ein 0x04 vom ATmega und dann ist 
Funkstille.

Meiner Meinung nach ist das noch ein Bug.

Viele Grüße

Igel1

[David D. (saturi)]

Andreas S. schrieb:
> @David:
> Weiter geht's ...

für mich leider nicht :/ ich kann euch nicht folgen... Also gedanklich 
schon, aber ich habe alle Änderungen, die du in den Datein vorgenommen 
hast, geprüft und übernommen. Bis auf die delays beim Bildsenden(was ja 
aktuell überhaupt keine Rolle spielt) ist alles gleich. Sowohl in der 
main, in der Uart.c als auch in der OV7670_withFifo.... und trotzdem 
bleibt meiner nachwievor bei read device settings sporadisch hängen...
Habe jetzt nochmal meinen Code gepusht:
https://github.com/igittigitt/ov7670/tree/TWI-Interfac/OV7670-AVR/OV7670-AVR
Ich scheine Blind zu sein?! Es geht einfach nicht und ich weiß nicht 
warum.

was mir auffällt: du sagst du hättest das Format 8N1 (also 1 Stopbit) 
setzt aber Register UCSR0C = 0b00001110; womit mit bit[3] 2 Stopbits 
configurierst. Aber scheint keinen Unterschied zu machen.

PS: ja :D ich versuche kleine Fehler (wie zum Beispiel das Übersehen der 
letzten RegisterSeite im PDF.... mit jedem Update auszumerzen ;-) Freut 
mich, dass es dir auffällt.

[David D. (saturi)]

Andreas S. schrieb:
>
> Meiner Meinung nach ist das noch ein Bug.

und Michaels Meinung nach auch :D und ihr habt recht, jetzt hab ich ihn 
behoben. Aber bleibe nach wie vor hängen.

[Andreas S. (igel1)]

Habe Deinen Code aus GitHub gezogen, compiliert, geflashed und dann die 
Register-Komplett-Auslesefunktion mit Terminal 0.7.1 getestet:

- ATmega resettet (im DebugWire-Modus)
- Terminal frisch gestartet
- 115200 8N1 Verbindung aufgenommen
- "Read Device Settings" gedrückt  (... und zu ende laufen lassen)
=> complete
- "Read Device Settings" gedrückt  (... und zu ende laufen lassen)
=> complete
- "Read Device Settings" gedrückt  (... und zu ende laufen lassen)
=> complete
  ... ca. 20x hintereinander erfolgreich laufen lassen ...

Läuft bombenstabil !

Viele Grüße & gute Nacht

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Habe Deinen Code aus GitHub gezogen, compiliert, geflashed und dann die
> Register-Komplett-Auslesefunktion mit Terminal 0.7.1 getestet:
>
> - ATmega resettet (im DebugWire-Modus)
> - Terminal frisch gestartet
> - 115200 8N1 Verbindung aufgenommen
...
>   ... ca. 20x hintereinander erfolgreich laufen lassen ...
>
> Läuft bombenstabil !

bestätige ich so auch hier.
ich werde mir mal write register nachher anschauen, das ist immernoch 
eine Würfelbude. Die Fewhlernummern muß ich auch mal raussuchen, was da 
im Terminal angezeigt wird, passt irgendwie garnicht zum AVR-Source.
Mich stört auch immernoch etwas, daß die Cam auf VGA gesetzt wird. 
640x480 passt sowieso nicht in den Fifo und sinnlos 480 Zeilen einlesen 
ist mehr als langweilig. Die Statuszeile könnte man auch manchmal 
löschen,
"Empfange Bild  478 von 480Zeilen importiert, 0 RowRepeat requested"
sieht irgendwie irritierend aus.
Wenn nicht das obere Drittel des Fifo schon überschrieben würde, stimmt 
sogar das Bild...

Das läuft hier auch im wahllosen Wechsel mit Read Device Settings/Kamera 
initialisieren/get camera status/take Picture complett absolut stabil. 
Habe ich naber nur so 3-4x getestet, sonst wird mein Morgendkaffe kalt. 
;)

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> Hallo,
>
> Andreas S. schrieb:
>> Habe Deinen Code aus GitHub gezogen, compiliert, geflashed und dann die
>> Register-Komplett-Auslesefunktion mit Terminal 0.7.1 getestet:
>>
>> - ATmega resettet (im DebugWire-Modus)
>> - Terminal frisch gestartet
>> - 115200 8N1 Verbindung aufgenommen
> ...
>>   ... ca. 20x hintereinander erfolgreich laufen lassen ...
>>
>> Läuft bombenstabil !
>
> bestätige ich so auch hier.

Wunderbar!

> ich werde mir mal write register nachher anschauen, das ist immernoch
> eine Würfelbude.

Sehe ich auch so.

> Die Fewhlernummern muß ich auch mal raussuchen, was da
> im Terminal angezeigt wird, passt irgendwie garnicht zum AVR-Source.

Weil Du das Szenario nicht beschreibst, verstehe ich nicht, was Du genau 
meinst.

> Mich stört auch immernoch etwas, daß die Cam auf VGA gesetzt wird.
> 640x480 passt sowieso nicht in den Fifo und sinnlos 480 Zeilen einlesen
> ist mehr als langweilig.

3 x 100%ige Zustimmung.

> Die Statuszeile könnte man auch manchmal löschen,
> "Empfange Bild  478 von 480Zeilen importiert, 0 RowRepeat requested"
> sieht irgendwie irritierend aus.

100%ige Zustimmung.

> Wenn nicht das obere Drittel des Fifo schon überschrieben würde, stimmt
> sogar das Bild...

Hmmm - jetzt, wo Du's sagst: stimmt, sieht tatsächlich so aus.

> Das läuft hier auch im wahllosen Wechsel mit Read Device Settings/Kamera
> initialisieren/get camera status/take Picture complett absolut stabil.

Habe bislang nur "Read Device Settings" und "read register" genauer 
getestet und kann für diese beiden Buttons bestätigen: läuft absolut 
stabil.

> Habe ich naber nur so 3-4x getestet, sonst wird mein Morgendkaffe kalt.
> ;)

:-)

> Gruß aus Berlin
> Michael

Schön, wir kommen langsam weiter ...

Grüße aus Aachen

Igel1

[Andreas S. (igel1)]

So, das Debugging mit DebugWire macht folgende interessante Beobachtung 
möglich:

Szenario:

- ATmega resettet (im DebugWire-Modus)
- Terminal frisch gestartet
- 115200 8N1 Verbindung aufgenommen
- "Read Device Settings" gedrückt  (... und zu ende laufen lassen)
=> complete
- "read register" für Register 0x00 ausgeführt
=> successfull
- "read for change" für Register 0x00 ausgeführt
=> successfull
- "write register" für Register 0x00 mit value 0x10 ausgeführt
=> Statuszeile sagt: Register write complete
- "read register" für Register 0x00 ausgeführt
=> successfull, aber der Wert 0x10 ist nicht im Register 0x00 gelandet
===> das ist natürlich ein Fehler - der write-Befehl muss schiefgegangen 
sein.

Dabei habe ich die im Bild dargestellten Breakpoints gesetzt.

Ergebnis:  Die Routine wird korrekt angesprungen und hat nur beim ersten 
und beim letzten Breakpoint angehalten. Das ist scheinbar korrekt, aber 
trotzdem wird das Register nicht korrekt beschrieben.

Damit haben wir den Fehler schon einmal ziemlich eingegrenzt - es liegt 
nicht an der Kommunikation zwischen Terminal und ATmega, sondern am 
schnöden Beschreiben der Register (quasi das "Brot und Wasser - 
Geschäft")  über die Routine "OV7670_write  (char regID, char regData)".

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
>> Die Fewhlernummern muß ich auch mal raussuchen, was da
>> im Terminal angezeigt wird, passt irgendwie garnicht zum AVR-Source.
>
> Weil Du das Szenario nicht beschreibst, verstehe ich nicht, was Du genau
> meinst.

Ich fange mal irgendwo an:
oben bis Zeile 1249 ist das Ende von Read Device Setting.
Er sendet immernoch xres 640, das wird sauber mit 0x04 quittiert und 
dann kommt vom Terminal nichts mehr.
In Zeile 1250 schicke ich write register (0x02) für Register 0x00 mit 
Wert 0x88. Wird in 1253 mit 0x00 quittiert, also als ok.
Terminal zeigt an: write failed ErrorCode: 4
Das ist aber die 4 von 1249...

Läßt sich auch bei anderen Kombinationen erreichen, er zeigt bei write 
register nicht den angekommenen ErrorCode an, Screen2.jpg:
Zeile 4946 read register 0x00 -> 0x00
Zeile 4952 write register 0x00 mit 0x00
Zeile 4955 0x00 kein Fehler
Terminal ErrorCode: 15
Die ist aus Zeile 4951...

Geschrieben wird nach 0x00 nichts, noch ungklärt.
Gerade noch getestet: save to struct, 0x00 im File auf 0x88 gesetzt.
load from struct, compare Lists 0x00 wird markiert, kann man kaum sehen 
weil fast außerhalb der Liste...
save to file ist auch komplett verschwunden, auch wenn ich es nicht 
wirklich vermisse.
0x00 wird definitiv nicht geschrieben.
Andere Abweichungen zwisch geschrieben und gelesen können auf Kosten von 
reservierten Registern/Bits kommen, das wird aja alles rigiros 
reingeschrieben, ob es geht/zulässig ist oder nicht.
Nach welchem System einege Button-Texte auf rot wechseln und warum/woszu 
ist mir auch unklar.

Es geht mir garnicht um Maulen um jeden Preis, aber wenn ich mir solch 
ein Tool zusammenbaue, dann teste ich jedes Detail im Zusammspiel, bis 
ich sicher bin, das es macht, was ich erwarte.
Statusmeldungen, die dann nicht den wirklichen Status anzeigen usw. oder 
Kommandos, die garnicht rausgehen (yres usw.) würden mir real genau 
garnichts nutzen.
Ich werde jetzt erstmal schauen, warum Register 0x00 nicht geschreiben 
wird, das zumindest passiert eindeutig auf dem AVR.

Gruß aus Berlin
Michael




Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Noch ein Bug im Terminal, der zunächst gefixed werden sollte:

Die folgende Abfolge gaukelt korrektes Funktionieren vor:

- "read register"  für Register X
=> successfull
- "read for change" für Register X
=> successfull
- "write register" für Register X auf den neuen value Y
=> Statuszeile sagt: Register write complete
- "read register" für Register X
=> successfull (und zeigt schön brav den neuen value Y für Register X an

ABER: ein anschließendes "read device settings" zeigt an, dass Register 
X noch immer den alten Wert enthält.

Wenn man danach nochmals "read register" aufruft, so besinnt sich die 
Routine eines Besseren und zeigt dann ebenfalls den alten value für 
Register X an.

Das beweist klar:
Die "read register" Routine im Terminal baut in diesem Falle Mist.
Und dies, obwohl sie korrekt den ATmega anfragt und auch das korrekte 
Ergebnis von diesem zurückgemeldet bekommt (nämlich, dass sich Register 
X nicht verändert hat und noch den alten Wert enthält).

Fazit: @David: bitte zunächst "read register" im Terminal bugfixen - es 
ist wichtig, dass diese Funktion zuverlässig tickt, bevor wir den 
Write-Bug angehen.

Ich mach' dann mal für eine Weilchen Schluss.

Viele Grüße

Igel1

[Andreas S. (igel1)]

Hi,

Ich kann Michaels Kritik durchaus verstehen.

Zum Glück ist David ein netter, höflicher und bescheidener Mensch, dem 
man genau aus diesem Grunde so manchen programmatischen Lapsus gerne 
nachsieht.

Andernfalls wäre ich hier schon längst von der Fahne gegangen...

Viele Grüße

Igel1

[David D. (saturi)]

Hallo, hatte grade ein halbe Stunde Zeit.
Mein Problem ist, nachwievor, dass es bei mir nicht läuft. Danke, dass 
du meinen Code getestet hast, also scheint es ja wiedermal an der 
Hardware zu liegen, wobei ja Lötfehler eigentlich ausgeschlossen sind, 
weil es ja die Uart Kommunikation ist...
@Michael, warst du auf dem uno board unterwegs? oder auch der Nano?

Seid ihr beiden über das USB Kabel mit dem Comport verbunden oder habt 
ihr an die TxRx Pins ein Com modul gehangen? (Ich weiß, dass es nicht 
der richtige Name ist, aber ich hoffe ihr wisst was ich meine)

Zu der Register write/read geschichte, dass kann ich gerade nicht 
nachstellen, weil ich nicht bis zum Ende durchlaufe... Auf den ersten 
Blick sieht es gut aus, hatte aber eben kurzzeitig die gleiche 
Beobachtung, aber erst als es einmal durchgelaufen war. Komme aber 
gerade nichtmal mehr ein einziges mal durch... Es ist wieder zum Mäuse 
Melken...

@Michael ich werde natürlich all deine Wünsche einarbeiten!. Und damit 
du nicht noch länger über den 0x04 bug meckerst anbei ein update ;-)
https://github.com/igittigitt/ov7670/tree/TWI-Interfac/OV7670-Terminal-Releases

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> @Michael, warst du auf dem uno board unterwegs? oder auch der Nano?
Auf dem UNO.
>
> Seid ihr beiden über das USB Kabel mit dem Comport verbunden oder habt
> ihr an die TxRx Pins ein Com modul gehangen? (Ich weiß, dass es nicht
> der richtige Name ist, aber ich hoffe ihr wisst was ich meine)

Ich weiß jetzt wirklich nicht, wie ich mich ausdrücken soll, damit es 
nicht zu sarkastisch rüberkommt.

Ob ich einen Mega328 auf ein Steckbrett nagle oder auf Lochraster löte 
und da einen TTL-USB-Wandler mit FTDI/CH34x/CP210x an GND, TX und RX 
randrahte, oder ob der Mega328 auf einem Nano oder UNO sitzt und schon 
mit einem USB-Wandler verbunden ist, ist einfach gesagt sch***egal.
Wenn da ein intaktes USB-Kabel zum PC geht (schon erkennbar, weil der 
den USB-Wandler sicher anmeldet, der weiß sowiao nicht vom AVR, der da 
dran hängt, wenn der installierte Treiber bis zum COM läuft, ist alles 
ok.
Natürlich kann jetzt in unserem kompletten Konstrukt z.B. ein 
Kontaktproblem zu SDA/SCL der Cam oder deren Betriebsspannung oder 
Resetanschluß alles blokieren. Das wäre aber nur ein Zeichen dafür, daß 
Deine SCCB-Routinen solche Fehlerzustände nicht sauber abfangen und 
melden.
Da bleibt dann meist nur systematische Fehlereingrenzung übrig.

Ich kann hier, wie auch Andreas, nur sagen: das Lesen der Register  (und 
auch die anderen Geschichten) laufen hier absolut stabil, auch mit dem 
jetzt aktuellen Terminal.

Andreas S. schrieb:
> Zum Glück ist David ein netter, höflicher und bescheidener Mensch, dem
> man genau aus diesem Grunde so manchen programmatischen Lapsus gerne
> nachsieht.
>
> Andernfalls wäre ich hier schon längst von der Fahne gegangen...

Ich sehe das ganz genauso wie Du. Sonst hätte ich das hier nicht in 
Griffnähe und passend vorbereitet, um es jederzeit anwerfen zu können.
Ich habe einfach das Problem, daß ich dem Konzept des Ganzen immer 
weniger folgen kann.

Aus einem älteren Post von Dir:
Andreas S. schrieb:
> Die Button-Bezeichnung "get camera status" lässt ja eigentlich vermuten,
> dass hier nur Register ausgelesen werden.
>
> Ab Sample No 505116 wird dann aber plötzlich ein Schreibbefehl
> abgesetzt:
> 0x04 0x80 0x02 0x0D 0x0A

Da beginnen dann auch meine Probleme. Eine Lesefunktion hat zu lesen und 
nichts zu verändern, zumindest, wenn es Debug-Zwecken dienen soll.
Nun werden zwar alle 3 Parameter richtig geschickt und quittiert, der 
Sinn dahinter hat sich mir aber nicht erschlossen.
Das der Fifo für 640x480 zu klein, ist zieht sich auch durch den halben 
Thread, trotzdem wird weiterhin in VGA initialisiert.

David D. schrieb:
> @Michael ich werde natürlich all deine Wünsche einarbeiten!. Und damit
> du nicht noch länger über den 0x04 bug meckerst anbei ein update ;-)

Meine Wünsche sind größtenteils Anmerkungen zu solchen und ähnlichen 
Sachen.
Für mich persöhnlich hat das Terminal keinerlei praktischen Nutzen.
Maximal könnte ich ein Datenset für einige Register als Struct reinladen 
und zur Kamera schicken und take Picture komplett anklicken.
Würde einige Sekunden flashen sparen und die Nutzung von TeraTerm + 
Irfanview. Das wäre aber nichtmal langsamer als die jetzige zeilenweise 
Übertragung, nur etwas umständlicher.

So, nun hoffe ich mal mit Andreas, daß Du den Fehler bei Dir findet und 
dann sehen wir weiter.

PS: meine Bekannten wissen, daß ich da ziemlich dickköpfig sein kann bei 
meinem Hareangehen. Nicht unbelehrbar, wenn aber viele Wege nach Rom 
führen können, bin ich oft sehr pragmatisch im Herangehen. Mein Projekt 
sieht dann manchmal weniger schön in Hard- und Software aus, würde in 
Serie so auch kaum durchgehen, läuft aber stabil unter meinen 
Bedingungen.
Gut möglich, daß das dann bgei -30 oder +60 Grad Umgebungstemperatur 
spinnt, stört nicht, wenn die in meinem Wohnzimmer sind habe ich ganz 
andere Probleme. Wenn das Handy neben dem UNO die Funktion stört, nehme 
ich das Handy zur Seite und baue nicht eine Abschirmung um den 
Versuchsaufbau.

Gruß aus Berlin
Michael

[David D. (saturi)]

Wenn meine Vermutung richtig ist, dann habe ich den Fehler: (muss ich 
aber noch mit einem Sniffer nachweisen:


wenn hier was schief geht, flute ich den Buffer mit Bytes, die er nicht 
erwartet:
[code}void OV_SCCB_RegisterToUart(char RegisterAddress){
  char tempByte = 0x00;
  char ErrorByte;
  if(!(ErrorByte=OV7670_read(RegisterAddress,&tempByte)))
    UART0_senden_Byte(tempByte);
  else
  {
    UART0_senden("Error: ");
    UART0_senden_Byte(ErrorByte);
  }
}[/code]

Da muss ich mir jetzt mal gedanken machen, wie ich denn eine Sinnvolle 
Fehlerüberprüfung einbauen kann.

Edit: Nein... der Sniffer sagt: Befehl kommt vom Terminal, Antwort 
bleibt aus

[Andreas S. (igel1)]

Okay, Leute: bitte lasst uns mal die Reihenfolge, in der wir die Dinge 
angehen wollen, festlegen.

Hier mein Vorschlag:


- Auflösung von VGA -> QVGA im Terminal umstellen

Ist vermutlich ein Klacks für David und erleichtert Michael und mir die 
weitere Fehlersuche. Ist natürlich dann in einem Abwasch auch in allen 
Initialisierungsroutinen umzustellen.

- Davids Hardwareproblem(?) fixen.

Davids und unsere Umgebungen sollten unbedingt gleich ticken, sonst 
kommen wir hier nie auf einen grünen Zweig.

- Routinen hinter "read register" im Terminal fixen

Der "read register" - Button sollte unbedingt zuverlässig funktionieren 
(Szenario & Fehlerbeschreibung, siehe hier: 
Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)"). 
Andernfalls können wir die "Write Register"-Bugs nicht sauber bearbeiten 
(oder nur sehr umständlich über den Button "Read Device Settings"

- Statusleiste im Terminal fixen

Bevor ein neuer Status/Error dort ausgegeben wird (ist übrigens sehr 
praktisch), sollte der alte Text unbedingt weggelöscht werden.

- Schreiboperationen aus Lesebefehlen entfernen

Genau wie Michael würde ich wärmstens anraten, sämtliche 
Schreiboperationen aus der Routine, die hinter dem Button "Read Device 
Settings" liegt, auszubauen (notfalls in einen separaten Button 
auslagern).

- Routinen hinter "write register" fixen

Wie in Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)" 
geschrieben, liegt in der Funktion "OV7670_write  (char regID, char 
regData)" bzw. deren Unterfunktionen der Bug. Hier ist ein wenig 
SCCB-Grundlagenforschung/arbeit erforderlich.

- Button "Save to File" wieder einbauen

Der war irgendwo zwischen Version 0.6 und 0.8 verloren gegangen.

- Doku schreiben

Welcher Button macht genau was?
Welche Fehlermeldung bedeutet genau was?



Das wäre meine aktuelle Liste.
Fehlt noch was?

Sollen wir die Liste hier im Forum pflegen oder als Issue-Liste auf 
GitHub?

Oder sollen wir gar nichts in Richtung "Priorisierung der 
Vorgehensweise" pflegen, weil's sonst schon bald in Richtung "Arbeit" 
ausartet und das Ganze ja nach wie vor Spaß machen soll? Oder weil's 
"Überorganisation" wäre?

Viele Grüße

Igel1

[David D. (saturi)]

Die Github Variante würde ich ganz stark bevorzugen, weil sonst doch 
einiges hinten runter fällt, und man sich früher oder später im Kreis 
dreht. Allerdings fehlte mir da bisher etwas die Zustimmung.
Aber im Grunde ist es nach 5min Eingewöhnungszeit(wenn überhautp) 
wirklich gut strukturiert und gut zu bedienen

[Michael U. (amiga)]

Hallo,

der Liste von Andreas stimme ich so erstmal völlig zu.

Zu github: mir die aktuellen Versionen von github zu holen ist für mich 
völlig ok, komplett werde ich mich mit github nicht befassen. Da sehe 
ich aber auch kein wirkliches Problem, die real anfallenden kurzen 
Codeausschnitte kann man, denke ich zumindest, gut hier diskutieren.

Ich habe inzwischen nochmal wegen der writeRegister-Geschichte geschaut. 
Habe in meinen modifizierten Code (nur uart.h und main.c verändert) mal 
etwas debug reingemacht. Effekte: Register 0x00 wird offenbar wirklich 
nicht geschrieben, fällt bei meinem init nicht auf, weil 0x00 da sowieso 
auf 0x00 bleibt. Andere Werte werden aber definitiv nicht übernommen. 
Noch ziemlich ungeprüft: schreiben von 0x00 auf Register 0x04 setzt 
0x01, andere Werte ergeben auch falsche Ergebnisse. Die reserved Bits 
liefern mir da keine Erklärung. Ich werde mir das mal so ändern, daß ich 
nur nicht identische Werte gemeldet bekomme, sonst ist das zu langweilig 
zu kontrollieren.
Außerdem werde ich mprgen mal schauen, ob ich OV7670_read() und 
OV7670_write() problemlos durch meine I2C-Routinen ersetzen kann zum 
Vergleich. Wenn die Differenzen bleiben jängt es mit der Kamera direkt 
zusammen, wenn nicht muß ich mir die SCCB-Routinen mal genauer anschauen 
bzw. den LA wieder ranhängen.

Schönen Abend noch.
Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> Hallo,
>
> der Liste von Andreas stimme ich so erstmal völlig zu.
>
> Zu github: mir die aktuellen Versionen von github zu holen ist für mich
> völlig ok, komplett werde ich mich mit github nicht befassen. Da sehe
> ich aber auch kein wirkliches Problem, die real anfallenden kurzen
> Codeausschnitte kann man, denke ich zumindest, gut hier diskutieren.

Ich vermute, Du hast hier etwas falsch verstanden.
Wir sprechen nicht über die Code-Versionierungsmöglichkeiten von GitHub, 
sondern über die Möglichkeiten, dort Bugs und Feature-Requests zu 
hinterlegen, zu dokumentieren, zu priorisieren und deren Fortschritt zu 
tracken. Siehe z.B. dieses Video dazu:
https://www.youtube.com/watch?v=WCH0j1Ywgrw

> Ich habe inzwischen nochmal wegen der writeRegister-Geschichte geschaut.
> Habe in meinen modifizierten Code (nur uart.h und main.c verändert) mal
> etwas debug reingemacht. Effekte: Register 0x00 wird offenbar wirklich
> nicht geschrieben, fällt bei meinem init nicht auf, weil 0x00 da sowieso
> auf 0x00 bleibt. Andere Werte werden aber definitiv nicht übernommen.

Aha - interessante Erkenntnis.

> Noch ziemlich ungeprüft: schreiben von 0x00 auf Register 0x04 setzt
> 0x01, andere Werte ergeben auch falsche Ergebnisse. Die reserved Bits
> liefern mir da keine Erklärung. Ich werde mir das mal so ändern, daß ich
> nur nicht identische Werte gemeldet bekomme, sonst ist das zu langweilig
> zu kontrollieren.

Das heißt, Du willst alle Register beschreiben und dann auslesen und 
vergleichen, um zu dokumentieren, welche Register nicht beschrieben 
werden können?

> Außerdem werde ich mprgen mal schauen, ob ich OV7670_read() und
> OV7670_write() problemlos durch meine I2C-Routinen ersetzen kann zum
> Vergleich. Wenn die Differenzen bleiben jängt es mit der Kamera direkt
> zusammen, wenn nicht muß ich mir die SCCB-Routinen mal genauer anschauen
> bzw. den LA wieder ranhängen.

Schöne Maikäferarbeit, aber so ähnlich würde ich ebenfalls vorgehen.

> Schönen Abend noch.
> Gruß aus Berlin
> Michael

Dito

Igel1

[Andreas S. (igel1)]

David D. schrieb:
> Wenn meine Vermutung richtig ist, dann habe ich den Fehler: (muss ich
> aber noch mit einem Sniffer nachweisen:
>
>
> wenn hier was schief geht, flute ich den Buffer mit Bytes, die er nicht
> erwartet:
> [code}void OV_SCCB_RegisterToUart(char RegisterAddress){
>   char tempByte = 0x00;
>   char ErrorByte;
>   if(!(ErrorByte=OV7670_read(RegisterAddress,&tempByte)))
>     UART0_senden_Byte(tempByte);
>   else
>   {
>     UART0_senden("Error: ");
>     UART0_senden_Byte(ErrorByte);
>   }
> }[/code]
>
> Da muss ich mir jetzt mal gedanken machen, wie ich denn eine Sinnvolle
> Fehlerüberprüfung einbauen kann.
>
> Edit: Nein... der Sniffer sagt: Befehl kommt vom Terminal, Antwort
> bleibt aus

Verstehe nicht, was Du mit folgendem Satz meinst:

> wenn hier was schief geht, flute ich den Buffer mit Bytes, die er nicht
> erwartet:

Wenn Du bei "UART0_senden("Error: ");" landest, kann doch im AVR nichts 
Schlimmes passieren, oder?  Höchstens das Terminal-Programm kann 
Probleme bekommen, wenn es mit dieser Antwort nicht rechnet (im wahrsten 
Sinn des Wortes :-)  Meintest Du Letzteres?

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
>> Noch ziemlich ungeprüft: schreiben von 0x00 auf Register 0x04 setzt
>> 0x01, andere Werte ergeben auch falsche Ergebnisse. Die reserved Bits
>> liefern mir da keine Erklärung. Ich werde mir das mal so ändern, daß ich
>> nur nicht identische Werte gemeldet bekomme, sonst ist das zu langweilig
>> zu kontrollieren.
>
> Das heißt, Du willst alle Register beschreiben und dann auslesen und
> vergleichen, um zu dokumentieren, welche Register nicht beschrieben
> werden können?

Nicht direkt. Ich habe bei mir ja das Setzen der default Registerwerte 
mit seiner write Routine drin, die vergleiche ich erstmal nur mit read 
ob die übernommen wurden.

Andreas S. schrieb:
> Schöne Maikäferarbeit, aber so ähnlich würde ich ebenfalls vorgehen.

:-) Ich habe mir bei mir mal schnell ein UART_senden_Hex() eingebaut 
damit ich in TeraTerm gut zuschauen kann. Nun ist erstmal die Verwirrung 
komplett...
Es muß ein Timingproblem irgenbdwo bei OV7670_write/read geben. Wenn ich 
meine Ausgabe ausführlich genug mache, also zwischen den einzelnen 
OV7670_write/read Zeit vertrödle, werden alle Register fehlerfrei 
geschrieben, auch 0x00.

Schluß für heute.

Gruß aus Berlin
Michael

[Michael U. (amiga)]

Hallo,

so, mal schnell meine Hardware-I2C-SCCB-Routinen in seine SCCB_old.c 
geworfen, ging tatsächlich schnell und problemlos.
Test mit meiner modifizierten Version ergab erstmal, daß das 
"Timingproblem" weg zu sein scheint. Das muß ich aber noch in Ruhe 
eingrenzen und mal genauer in Davids SCCB-Routinen schauen.
I2C-Routinen in seinem aktuellen AVR-Paket gingen auch problemlos mit 
dem Terminal, aber dort letztlich so chaotisch wie seine 
SCCB-Funktionen...
Ich mau da aber erstmal schauen, weil ich als Errorcode immer hardcoded 
0x00 zurückgebe, ob das passt.
Wenn die I2C-Routine einen Übertragungsfehler bemerkt, geht die in eine 
Endlosschleife und blnkt mit der onBoard-LED, das habe ich mit 
dringelassen weil es bei mir zuverlässig maulte wenn z.B. I2C keinen 
Kontakt zur OV7670 bekam.

Jetzt ist aber erstmal Einkaufen und einige andere Sachen dran, also mal 
schauen, wann es hier weitergeht.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Bei mir ist auch Einkaufen angesagt.

Damit Ihr währenddessen nicht Däumchen dreht, hier die 
Original-Mitschnitte von Davids SCCB-Busprotokoll (bei 100MHz 
Abtastrate):

- Auslesen von Register  0x00 (mit Wert 0x00)
- Schreiben von Register 0x00 mit Wert 0x88

In meinem LA habe ich dabei den I2C-Interpreter über die beiden Signale 
SIOC und SIOD laufen lassen - daher bitte die interpretierten Werte 
etwas mit Vorsicht genießen, denn SCCB ist ja nicht gleich I2C.

Einen direkten Fehler kann ich aus dem Stegreif nicht erkennen, müsste 
mich zur genauen Analyse aber nochmals wieder tief in das SCCB-Protokoll 
einarbeiten (au Mann, hab' ich vielleicht eine Lust darauf ...)

Viele Grüße

Igel1

[Andreas S. (igel1)]

... und noch einmal mit Register 0x01 und anderen Werten:

- Auslesen von Register  0x01 (mit Wert 0x80)
- Schreiben von Register 0x01 mit Wert 0x59

Viele Grüße

Igel1

[Andreas S. (igel1)]

Zwischen zwei Einkäufen schnell noch ein Test, der seltsames liefert:

Wenn ich vor der while(1){}-Schleife (die mit den vielen case-Abfragen) 
folgenden Code einbaue:

OV7670_write (0x00, 0x88);
OV_SCCB_RegisterToUart(0x00);
while(1){}

... so verschwindet das Programm beim dem 
OV_SCCB_RegisterToUart(0x00)-Aufruf auf nimmerwiedersehen.


Gleiches passiert bei folgendem Konstrukt:

char iregData;
OV7670_write (0x00, 0x88);
OV7670_read (0x00, &iregData);
while(1){}

Hier verschwindet das Programm beim dem OV7670_read (0x00, 
&iregData)-Aufruf auf nimmerwiedersehen.


Gleichzeitig funktioniert das - mehr oder minder - gleiche Konstrukt in 
der  Case-Abfrage wunderbar:

  case 1: //ReadRegister and sent it to Uart
    UART0_senden_Byte(receivedAddress);
    //_delay_ms(1);
    OV_SCCB_RegisterToUart(receivedAddress);
    Programstatus=-1;

Bin dem jetzt noch nicht klitzeklein nachgegangen, aber so richtig 
"normal" scheint mir dieses Verhalten nicht zu sein. (oder mag das ein 
Problem mit dem Debugger sein??)

Viele Grüße

Igel1

[David D. (saturi)]

Hi Igel,

was genau meinst du mit "verschwinden"? hängen bleiben oder wie?
Ich werde mich heute nacht in eine Woche Urlaub verabschieden, nehme 
aber meinen Rechner mit. (vlt kann ich auch die Kamera mit schmuggeln 
;-))
aber meinen Dragon vermutlich nicht.

wo würdet ihr jetzt an meiner Stelle anfangen zu suchen, wenn die 
Software bei euch beiden Läuft und ich den COM-Port auch vernünftig 
verbinden kann?

Ich weiß einfach nicht, was ich jetzt machen soll? meine "Lötarbeiten" 
können ja nicht das Problem sein?!

Ich habe alle aufgeführten "Fehler" oder Aufgabenpakete in Github 
eingefügt, so wie du gestern schon begonnen hattest (@Igel) So stellen 
wir sicher, dass wir nichts vergessen.

Gruß
David

[Andreas S. (igel1)]

David D. schrieb:
> Hi Igel,
>
> was genau meinst du mit "verschwinden"? hängen bleiben oder wie?

Das Programm ruft die besagte Funktion auf und taucht danach nicht mehr 
aus der Funktion auf. Aber wie gesagt: bitte diesen "Bug" mit Vorbehalt 
betrachten - es kann auch am Debugger liegen: dort kann ich nach der 
besagten Funktion keinen Breakpoint mehr setzen und ich weiß nicht 
warum. Ich werde das noch genauer untersuchen.

> Ich werde mich heute nacht in eine Woche Urlaub verabschieden,

Ich dachte, die Schwiegereltern kommen am Wochenende?
Oder hat Dich allein die Ankündigung der Schwiegereltern schon 
urlaubsreif gemacht?  ;-)

> nehme aber meinen Rechner mit.

Brav!

> (vlt kann ich auch die Kamera mit schmuggeln
> ;-)) aber meinen Dragon vermutlich nicht.

Na auf den Dragon kommt's dann doch auch nicht mehr an.

> wo würdet ihr jetzt an meiner Stelle anfangen zu suchen, wenn die
> Software bei euch beiden Läuft und ich den COM-Port auch vernünftig
> verbinden kann?

Lade mal ein Bild von Deinem Drahtverhau hier hoch.

Folgende Ideen hätte ich:

- Leitungen zum OV7670 Modul zu lang
- Masseleitungen ungünstig geführt
- Levelshifter falsch herum angeschlossen
- Feng Shui bei der Bestückung nicht beachtet

In der höchsten Not würde ich tatsächlich auf den Nano schwenken (wenn 
Du noch einen rumfliegen hast). Vorher unbedingt die 
DebugWire-Modifikation machen.

Was ich nicht geschrieben hatte: ich habe 2 Nanos. Die 
DebugWire-Modifikation habe ich nur am 2. Nano durchgeführt und dann 
anschließend in der Schaltung den ersten Nano durch den modifizierten 
ersetzt. Beide Nanos funktionieren in Deiner Schaltung - und dies, 
obwohl es ganz unterschiedliche Nanos sind (unterschiedliches Layout).


> Ich weiß einfach nicht, was ich jetzt machen soll?

Urlaub :-)

> meine "Lötarbeiten" können ja nicht das Problem sein?!

Läßt sich niemals ausschließen.
Notfalls mit dem Multimeter alles einmal durchpiepen.

> Ich habe alle aufgeführten "Fehler" oder Aufgabenpakete in Github
> eingefügt, so wie du gestern schon begonnen hattest (@Igel) So stellen
> wir sicher, dass wir nichts vergessen.

Oh, supi - das ist klasse, da kommt etwas Struktur in unsere Zs.arbeit.

Wenn wir das Dingen jemals zum Fliegen bekommen, müssen wir unbedingt 
mal ein Bier zusammen darauf trinken (oder uns wenigstens einmal 
zusammentelefonieren) - ich bin ja so neugierig, mit welchen Freaks ich 
mich hier seit Wochen herumbalge ...

> Gruß
> David

Gruß

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> - Leitungen zum OV7670 Modul zu lang
Bei mir ließ sie sich auch von 20cm Dupontkabeln noch nicht aus der Ruhe 
bringen, obwohl das natürlich nicht zu empfehlen ist.

> - Masseleitungen ungünstig geführt
Schafft man das in unserem Kontext wirklich? Auch Arduino Mini + 
getrenntem USB-Wandler mit besagten Strippen hat da real noch nie 
Probleme gemacht.

Generell liegen natürlich Kontaktunsicherheiten da gern auf der Lauer, 
ich sortiere vei den China-Strippen ziemlich schnell in Richtung 
Rundordner, wenn da was zu lose ist beim Stecken. Kosten ja nichts.....

> - Levelshifter falsch herum angeschlossen
Möglich, ich habe jetzt aber nicht geschaut, ob überhaupt etwas ginge.

> - Feng Shui bei der Bestückung nicht beachtet

Sehr gern auftretendes Problem, oder wie Herr Murphy sagte: Toleranzen 
summieren sich immer nach der ungünstigsten Seite.

Andreas S. schrieb:
>> meine "Lötarbeiten" können ja nicht das Problem sein?!
>
> Läßt sich niemals ausschließen.
> Notfalls mit dem Multimeter alles einmal durchpiepen.

Mache ich bei Fragwürdigkeiten immer und zwar möglichst direkt zwischen 
den Pins, wo es ankommen soll. Also auch z.B. AVR und Fifo-Pins als 
Beispiel.

Andreas S. schrieb:
> Wenn wir das Dingen jemals zum Fliegen bekommen, müssen wir unbedingt
> mal ein Bier zusammen darauf trinken (oder uns wenigstens einmal
> zusammentelefonieren) - ich bin ja so neugierig, mit welchen Freaks ich
> mich hier seit Wochen herumbalge ...

Der Idee schleiße ich mich unbedingt an, wenn statt Bier auch Kaffe 
zulässig ist. ;-).

Andreas S. schrieb:
> ... so verschwindet das Programm beim dem
> OV_SCCB_RegisterToUart(0x00)-Aufruf auf nimmerwiedersehen.
>
> Gleiches passiert bei folgendem Konstrukt:
> char iregData;
> OV7670_write (0x00, 0x88);
> OV7670_read (0x00, &iregData);
> while(1){}

teste ich mal bei mir, sehe ich aber auch eher als Debug-Problem, ich 
habe schon etliche Zusatzausgaben auch da vorn reingeklebt, da ist mir 
nicht Negatives aufgefallen.

Sorry für das chaotische Zitieren, aber ich denke, Ihr kommt damit 
klar...

PS: zur Entspannung versuche ich gerade, auf dem Odroid Go eine 
"Navi-"software in Gang zu bekommen, da hett im Netz jemad Langeweile...
https://forum.odroid.com/viewtopic.php?t=33629

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

ENTWARNUNG !

Kurzes Update zu folgendem Problem:


Andreas S. schrieb:
> David D. schrieb:
>> Hi Igel,
>>
>> was genau meinst du mit "verschwinden"? hängen bleiben oder wie?
>
> Das Programm ruft die besagte Funktion auf und taucht danach nicht mehr
> aus der Funktion auf. Aber wie gesagt: bitte diesen "Bug" mit Vorbehalt
> betrachten - es kann auch am Debugger liegen: dort kann ich nach der
> besagten Funktion keinen Breakpoint mehr setzen und ich weiß nicht
> warum. Ich werde das noch genauer untersuchen.


In der Tat: das Problem war der Debugger - oder genauer: der Typ, der 
vor dem Debugger saß.  Erst wenn man die Compiler-Optimierungen 
ausschaltet, funktioniert das "Durchsteppen" durch den Code so richtig.

Nur leider benötigt dann das Flashen des Programmes via DebugWire ca. 
10x so lang - echt nervig.

Immerhin - ich kann jetzt sauber durch den Code steppen und der 
verschollene Programcounter kehrt mit ausgeschalteter Optimierung auch 
irgendwann wieder aus der aufgerufenen Routine zurück.
Also: Entwarnung.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> In der Tat: das Problem war der Debugger - oder genauer: der Typ, der
> vor dem Debugger saß.  Erst wenn man die Compiler-Optimierungen
> ausschaltet, funktioniert das "Durchsteppen" durch den Code so richtig.

Ja, das ist das Problem: Debug geht nur zuverlässig ohne Optimierung 
weil der GCC sonst zuviel umsortiert.
Einer der Gründe, weshalb ich selten so auf dem AVR debugge, wenn ich 
Pech habe passt das Programm dann nicht in den Flash oder die Laufzeiten 
ändern sich drastisch.
Wenn sich nicht geändert hat, stimmt -delay_ms() ohne optimierung auch 
nicht.

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Liebe Mitstreiter,

uns allen ist klar, das "vorgefertigte, wundersame Einstellungen" 
richtig sind. O.K.

Ich habe nur mit "Realtime"-Abfragen gearbeitet und bin daher - 
zumindest in der Auflösung - starkt eingeschränkt.

Ihr arbeitet mit Puffer und habt "alle Zeit der Welt" ein Bild 
abzuholen. Meinetwegen auch mit z. B. 300 Baud.

Wo ist da das Problem? Wenn ein Bild im Puffer ist kann man es in aller 
Ruhe - Takt für Takt - auslesen und z. B. seriell an ein 
Terminal-Programm etc. übergeben.

Habt ihr ein Problem mit der seriellen Schnittstelle? Binärdaten 
übertragen ist immer etwas speziell, da es dann keine Steuerzeichen gibt 
/ geben kann.

VG
Dieter

[Andreas S. (igel1)]

@Dieter F.:

Du willst helfen? Prima, das ist nett.

Bitte schau Dir einmal die Signalverläufe in diesem Posting an:
Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)"

... und sage uns, warum das Beschreiben des Registers nicht 
funktioniert.
Ich hoffe, Du hast gute SCCB-Protokoll-Erfahrung - mir fehlt hier 
irgendein Puzzlestück in meinem Halbwissen.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Wo ist da das Problem? Wenn ein Bild im Puffer ist kann man es in aller
> Ruhe - Takt für Takt - auslesen und z. B. seriell an ein
> Terminal-Programm etc. übergeben.

Es gibt kein wirkliches Problem die Daten zu übertragen.
Mit CH34x oder FTDI kann ich die auch mit 500kBaud oder 1MBaud von einem 
AVR zuverlässig im Stück als RAW-Daten rüberschicken, ohne jeden Fehler, 
reproduzierbar.  Mit dem Mega16U2 als UBS-Wandler gehen nicht mehr als 
230400 und mit kleinen Pausen zwischen den Bytes, das ist aber ein 
problem der Firmware auf dem Mega16U2, seine Bufferverwaltung hat da 
offenbar Grenzen.
Das real die 500kBaud/1MBaud nicht erreicht werden, isz auch klar, weil 
das Abholen des Bytes aus dem Fifo eben auch ein paar Takte kostet und 
16NHz Takt des AVR nicht endlos schnell sind.
Dazu muß aber eben auf dem PC etwas die Daten entgegen nehmen, teraTerm 
macht das z.B. bei mir als Binär-Log auf die HD ohne Probleme.

Davids PC-Programm macht das prinzipiell sicher auch, da haben wir ihm 
aber noch ein paar Denkaufgaben gegeben. ;)

Die Farge von Andreas hat sich dabei auch ergeben, ich habe noch nicht 
genauer geschaut, das Problem besteht aber offenbar mit den 
SCBB-Routinen von David und isr noch sehr rätselhaft. Meit meinen 
Hardware-I2C-Routinen (ok, die sind nicht wirklich von mir...) passiert 
das aber nicht.
Ich hatte aber den LA noch nicht dran, um zu vergleichen.

Das nur als eine Art Zusammenfassung weil der Thread ja recht lang und 
damit teilweise unübersichtlich geworden ist.

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Andreas S. schrieb:
> ... und sage uns, warum das Beschreiben des Registers nicht
> funktioniert

Kannst Du bitte SCCB_E zusätzlich aufzeichnen?

[Andreas S. (igel1)]

Dieter F. schrieb:
> Andreas S. schrieb:
>> ... und sage uns, warum das Beschreiben des Registers nicht
>> funktioniert
>
> Kannst Du bitte SCCB_E zusätzlich aufzeichnen?

Wird bei dem Modul nicht nach außen geführt => kann ich nicht 
aufzeichnen.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,
der OV7670 Chip hat nur SIO_C und SIO_D.
Ist auch in der SCCB-Doku als Anmerkung erwähnt, daß das möglich ist.
Bei mir in der v2.2 vom 25.06.2007 Table 2.2 Seite 6.

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Andreas S. schrieb:
> Wird bei dem Modul nicht nach außen geführt => kann ich nicht
> aufzeichnen.

Habe ich jetzt auch gesehen - danke :-)

Die Adresse ist (auf 7-Bit-Basis) grundsätzlich richtig - wird aber nach 
links geschoben damit das read-/write-Bit gesetzt werden kann - damit 
wird die Adresse zu 0x42 (write) oder 0x43 (read).

Mit 0x21 (lt. Deiner Aufzeichnung) "fühlt" sich die Kamera nicht 
angesprochen.

[Andreas S. (igel1)]

Hi Leute,

in meinem STM32F429-Code bin ich mir relativ sicher, dass die 
Register-Lese- und Register-Schreibfunktionen funktionieren.

Also habe ich dort einmal über aller Register (0x00 - 0xC9) folgende 
Operation durchgeführt:

- Wert aus Register gelesen
- Wert 0x88 in Register geschrieben
- Wert nach der Schreiboperation erneut aus Register gelesen
- Wenn Wert==0x88 => SUCCESS, sonst FAILURE ausgegeben
- Danach nochmals alle Register in einer Schleife ausgelesen

Weiter unten findet Ihr meinen Code und noch weiter unten das Ergebnis.

Ich gebe zu: ich bin etwas ratlos, wie ich mit dem Ergebnis umgehen 
soll:

- zum einen scheinen nicht alle Register sauber mit dem Wert 0x88
  beschrieben werden zu können

- zum anderen scheint sich auch der Wert in den Registern bei einem
  späteren Auslesen nochmals verändert zu haben.

Hmmm .... grübel, grübel und kopfkratz ...

Viele Grüße

Igel1


-------------------------------------------------------------------

   I2C_Config(); // Initialize I2C
  printf("I2C_Config() done\n");

  OV7670_Reset();

 
  uint16_t regaddr = 0x00;
  uint8_t regdatabefore  = 0x00;
  uint8_t regdataafter   = 0x00;
  uint8_t regdatanew = 0x88;
  uint8_t retval   = 0x00;
  uint32_t delval  = 100;

  Delay(delval);
  printf("Writing 0x%x to registers\n\n", regdatanew);
  printf("regaddr       value before mod             value after mod\n");
  printf("-------------------------------------------------------------------------\n");

  // for register 0x00 .. 0x9C:  
  //   read register, write 0x88 into register, read register again ...
  for (regaddr = 0; regaddr <= 0xC9; regaddr++) {
    regdatabefore = OV7670_ReadReg(regaddr);
    Delay(delval);
    printf("regaddr=0x%X   regdata=0x%X  ", regaddr, regdatabefore);
    retval = OV7670_WriteReg(regaddr, regdatanew);
    Delay(delval);
    regdataafter = OV7670_ReadReg(regaddr);
    Delay(delval);
    printf("regdata=0x%X  ", regdataafter);
    if(regdataafter == 0x88){
      printf("SUCCESS\n");
    } else  {
      printf("FAILURE\n");
    }
  }

  printf("-------------------------------------------------------------------------\n");
   
  // ... and read out all registers again ...
  for (regaddr = 0; regaddr <= 0xC9; regaddr++) {
    regdataafter = OV7670_ReadReg(regaddr);
    printf("regaddr=0x%X   regdata=0x%X  \n", regaddr, regdataafter);
    Delay(delval);
  }

Ergebnis:

I2C_Config() done
Writing 0x88 to registers

regaddr       value before mod             value after mod
-------------------------------------------------------------------------
regaddr=0x0   regdata=0x3  regdata=0x3  FAILURE
regaddr=0x1   regdata=0x80  regdata=0x80  FAILURE
regaddr=0x2   regdata=0x82  regdata=0x82  FAILURE
regaddr=0x3   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x4   regdata=0x1  regdata=0x89  FAILURE
regaddr=0x5   regdata=0x7F  regdata=0x7F  FAILURE
regaddr=0x6   regdata=0x5F  regdata=0x6B  FAILURE
regaddr=0x7   regdata=0x40  regdata=0x40  FAILURE
regaddr=0x8   regdata=0x80  regdata=0x80  FAILURE
regaddr=0x9   regdata=0x1  regdata=0x88  SUCCESS
regaddr=0xA   regdata=0x76  regdata=0x76  FAILURE
regaddr=0xB   regdata=0x73  regdata=0x73  FAILURE
regaddr=0xC   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xD   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xE   regdata=0x1  regdata=0x88  SUCCESS
regaddr=0xF   regdata=0x43  regdata=0x88  SUCCESS
regaddr=0x10   regdata=0x7F  regdata=0x7F  FAILURE
regaddr=0x11   regdata=0x80  regdata=0x88  SUCCESS
regaddr=0x12   regdata=0x0  regdata=0x0  FAILURE
regaddr=0x13   regdata=0x8F  regdata=0x88  SUCCESS
regaddr=0x14   regdata=0x4A  regdata=0x88  SUCCESS
regaddr=0x15   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x16   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x17   regdata=0x11  regdata=0x88  SUCCESS
regaddr=0x18   regdata=0x61  regdata=0x88  SUCCESS
regaddr=0x19   regdata=0x3  regdata=0x88  SUCCESS
regaddr=0x1A   regdata=0x7B  regdata=0x88  SUCCESS
regaddr=0x1B   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x1C   regdata=0x7F  regdata=0x7F  FAILURE
regaddr=0x1D   regdata=0xA2  regdata=0xA2  FAILURE
regaddr=0x1E   regdata=0x1  regdata=0x88  SUCCESS
regaddr=0x1F   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x20   regdata=0x4  regdata=0x88  SUCCESS
regaddr=0x21   regdata=0x2  regdata=0x88  SUCCESS
regaddr=0x22   regdata=0x1  regdata=0x88  SUCCESS
regaddr=0x23   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x24   regdata=0x75  regdata=0x88  SUCCESS
regaddr=0x25   regdata=0x63  regdata=0x88  SUCCESS
regaddr=0x26   regdata=0xD4  regdata=0x88  SUCCESS
regaddr=0x27   regdata=0x80  regdata=0x88  SUCCESS
regaddr=0x28   regdata=0x80  regdata=0x88  SUCCESS
regaddr=0x29   regdata=0x7  regdata=0x88  SUCCESS
regaddr=0x2A   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x2B   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x2C   regdata=0x80  regdata=0x88  SUCCESS
regaddr=0x2D   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x2E   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x2F   regdata=0xE  regdata=0x88  SUCCESS
regaddr=0x30   regdata=0x8  regdata=0x88  SUCCESS
regaddr=0x31   regdata=0x30  regdata=0x88  SUCCESS
regaddr=0x32   regdata=0x80  regdata=0x88  SUCCESS
regaddr=0x33   regdata=0x8  regdata=0x88  SUCCESS
regaddr=0x34   regdata=0x11  regdata=0x88  SUCCESS
regaddr=0x35   regdata=0x1A  regdata=0x88  SUCCESS
regaddr=0x36   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x37   regdata=0x3F  regdata=0x88  SUCCESS
regaddr=0x38   regdata=0x1  regdata=0x88  SUCCESS
regaddr=0x39   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x3A   regdata=0xD  regdata=0x88  SUCCESS
regaddr=0x3B   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x3C   regdata=0x68  regdata=0x88  SUCCESS
regaddr=0x3D   regdata=0x88  regdata=0x88  SUCCESS
regaddr=0x3E   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x3F   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x40   regdata=0xC0  regdata=0x88  SUCCESS
regaddr=0x41   regdata=0x8  regdata=0x88  SUCCESS
regaddr=0x42   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x43   regdata=0x14  regdata=0x88  SUCCESS
regaddr=0x44   regdata=0xF0  regdata=0x88  SUCCESS
regaddr=0x45   regdata=0x45  regdata=0x88  SUCCESS
regaddr=0x46   regdata=0x61  regdata=0x88  SUCCESS
regaddr=0x47   regdata=0x51  regdata=0x88  SUCCESS
regaddr=0x48   regdata=0x79  regdata=0x88  SUCCESS
regaddr=0x49   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x4A   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x4B   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x4C   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x4D   regdata=0x4  regdata=0x88  SUCCESS
regaddr=0x4E   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x4F   regdata=0x40  regdata=0x88  SUCCESS
regaddr=0x50   regdata=0x34  regdata=0x88  SUCCESS
regaddr=0x51   regdata=0xC  regdata=0x88  SUCCESS
regaddr=0x52   regdata=0x17  regdata=0x88  SUCCESS
regaddr=0x53   regdata=0x29  regdata=0x88  SUCCESS
regaddr=0x54   regdata=0x40  regdata=0x88  SUCCESS
regaddr=0x55   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x56   regdata=0x40  regdata=0x88  SUCCESS
regaddr=0x57   regdata=0x80  regdata=0x88  SUCCESS
regaddr=0x58   regdata=0x1E  regdata=0x88  SUCCESS
regaddr=0x59   regdata=0x91  regdata=0x88  SUCCESS
regaddr=0x5A   regdata=0x94  regdata=0x88  SUCCESS
regaddr=0x5B   regdata=0xAA  regdata=0x88  SUCCESS
regaddr=0x5C   regdata=0x71  regdata=0x88  SUCCESS
regaddr=0x5D   regdata=0x8D  regdata=0x88  SUCCESS
regaddr=0x5E   regdata=0xF  regdata=0x88  SUCCESS
regaddr=0x5F   regdata=0xF0  regdata=0x88  SUCCESS
regaddr=0x60   regdata=0xF0  regdata=0x88  SUCCESS
regaddr=0x61   regdata=0xF0  regdata=0x88  SUCCESS
regaddr=0x62   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x63   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x64   regdata=0x50  regdata=0x88  SUCCESS
regaddr=0x65   regdata=0x30  regdata=0x88  SUCCESS
regaddr=0x66   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x67   regdata=0x80  regdata=0x88  SUCCESS
regaddr=0x68   regdata=0x80  regdata=0x88  SUCCESS
regaddr=0x69   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x6A   regdata=0x82  regdata=0x88  SUCCESS
regaddr=0x6B   regdata=0xA  regdata=0x88  SUCCESS
regaddr=0x6C   regdata=0x2  regdata=0x88  SUCCESS
regaddr=0x6D   regdata=0x55  regdata=0x88  SUCCESS
regaddr=0x6E   regdata=0xC0  regdata=0x88  SUCCESS
regaddr=0x6F   regdata=0x9A  regdata=0x88  SUCCESS
regaddr=0x70   regdata=0x3A  regdata=0x88  SUCCESS
regaddr=0x71   regdata=0x35  regdata=0x88  SUCCESS
regaddr=0x72   regdata=0x11  regdata=0x88  SUCCESS
regaddr=0x73   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x74   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x75   regdata=0xF  regdata=0x88  SUCCESS
regaddr=0x76   regdata=0x1  regdata=0x88  SUCCESS
regaddr=0x77   regdata=0x10  regdata=0x88  SUCCESS
regaddr=0x78   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x79   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x7A   regdata=0x24  regdata=0x88  SUCCESS
regaddr=0x7B   regdata=0x4  regdata=0x88  SUCCESS
regaddr=0x7C   regdata=0x7  regdata=0x88  SUCCESS
regaddr=0x7D   regdata=0x10  regdata=0x88  SUCCESS
regaddr=0x7E   regdata=0x28  regdata=0x88  SUCCESS
regaddr=0x7F   regdata=0x36  regdata=0x88  SUCCESS
regaddr=0x80   regdata=0x44  regdata=0x88  SUCCESS
regaddr=0x81   regdata=0x52  regdata=0x88  SUCCESS
regaddr=0x82   regdata=0x60  regdata=0x88  SUCCESS
regaddr=0x83   regdata=0x6C  regdata=0x88  SUCCESS
regaddr=0x84   regdata=0x78  regdata=0x88  SUCCESS
regaddr=0x85   regdata=0x8C  regdata=0x88  SUCCESS
regaddr=0x86   regdata=0x9E  regdata=0x88  SUCCESS
regaddr=0x87   regdata=0xBB  regdata=0x88  SUCCESS
regaddr=0x88   regdata=0xD2  regdata=0x88  SUCCESS
regaddr=0x89   regdata=0xE5  regdata=0x88  SUCCESS
regaddr=0x8A   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x8B   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x8C   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x8D   regdata=0xF  regdata=0x88  SUCCESS
regaddr=0x8E   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x8F   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x90   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x91   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x92   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x93   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x94   regdata=0x50  regdata=0x88  SUCCESS
regaddr=0x95   regdata=0x50  regdata=0x88  SUCCESS
regaddr=0x96   regdata=0x1  regdata=0x88  SUCCESS
regaddr=0x97   regdata=0x1  regdata=0x88  SUCCESS
regaddr=0x98   regdata=0x10  regdata=0x88  SUCCESS
regaddr=0x99   regdata=0x40  regdata=0x88  SUCCESS
regaddr=0x9A   regdata=0x40  regdata=0x88  SUCCESS
regaddr=0x9B   regdata=0x20  regdata=0x88  SUCCESS
regaddr=0x9C   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0x9D   regdata=0x99  regdata=0x88  SUCCESS
regaddr=0x9E   regdata=0x7F  regdata=0x88  SUCCESS
regaddr=0x9F   regdata=0xC0  regdata=0x88  SUCCESS
regaddr=0xA0   regdata=0x90  regdata=0x88  SUCCESS
regaddr=0xA1   regdata=0x3  regdata=0x88  SUCCESS
regaddr=0xA2   regdata=0x2  regdata=0x88  SUCCESS
regaddr=0xA3   regdata=0x1E  regdata=0x88  SUCCESS
regaddr=0xA4   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xA5   regdata=0xF  regdata=0x88  SUCCESS
regaddr=0xA6   regdata=0xF0  regdata=0x88  SUCCESS
regaddr=0xA7   regdata=0xC1  regdata=0x88  SUCCESS
regaddr=0xA8   regdata=0xF0  regdata=0x88  SUCCESS
regaddr=0xA9   regdata=0xC1  regdata=0x88  SUCCESS
regaddr=0xAA   regdata=0x14  regdata=0x88  SUCCESS
regaddr=0xAB   regdata=0xF  regdata=0x88  SUCCESS
regaddr=0xAC   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xAD   regdata=0x80  regdata=0x88  SUCCESS
regaddr=0xAE   regdata=0x80  regdata=0x88  SUCCESS
regaddr=0xAF   regdata=0x80  regdata=0x88  SUCCESS
regaddr=0xB0   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xB1   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xB2   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xB3   regdata=0x80  regdata=0x88  SUCCESS
regaddr=0xB4   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xB5   regdata=0x4  regdata=0x88  SUCCESS
regaddr=0xB6   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xB7   regdata=0x66  regdata=0x88  SUCCESS
regaddr=0xB8   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xB9   regdata=0x6  regdata=0x88  SUCCESS
regaddr=0xBA   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xBB   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xBC   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xBD   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xBE   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xBF   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xC0   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xC1   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xC2   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xC3   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xC4   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xC5   regdata=0x0  regdata=0x88  SUCCESS
regaddr=0xC6   regdata=0x88  regdata=0x88  SUCCESS
regaddr=0xC7   regdata=0x88  regdata=0x88  SUCCESS
regaddr=0xC8   regdata=0x88  regdata=0x88  SUCCESS
regaddr=0xC9   regdata=0xC0  regdata=0x82  FAILURE
-------------------------------------------------------------------------
regaddr=0x0   regdata=0x0  
regaddr=0x1   regdata=0x80  
regaddr=0x2   regdata=0x82  
regaddr=0x3   regdata=0x0  
regaddr=0x4   regdata=0x1  
regaddr=0x5   regdata=0x24  
regaddr=0x6   regdata=0x24  
regaddr=0x7   regdata=0x40  
regaddr=0x8   regdata=0x24  
regaddr=0x9   regdata=0x1  
regaddr=0xA   regdata=0x76  
regaddr=0xB   regdata=0x73  
regaddr=0xC   regdata=0x0  
regaddr=0xD   regdata=0x0  
regaddr=0xE   regdata=0x1  
regaddr=0xF   regdata=0x43  
regaddr=0x10   regdata=0x7F  
regaddr=0x11   regdata=0x80  
regaddr=0x12   regdata=0x0  
regaddr=0x13   regdata=0x88  
regaddr=0x14   regdata=0x88  
regaddr=0x15   regdata=0x88  
regaddr=0x16   regdata=0x88  
regaddr=0x17   regdata=0x88  
regaddr=0x18   regdata=0x88  
regaddr=0x19   regdata=0x88  
regaddr=0x1A   regdata=0x88  
regaddr=0x1B   regdata=0x88  
regaddr=0x1C   regdata=0x7F  
regaddr=0x1D   regdata=0xA2  
regaddr=0x1E   regdata=0x88  
regaddr=0x1F   regdata=0x88  
regaddr=0x20   regdata=0x88  
regaddr=0x21   regdata=0x88  
regaddr=0x22   regdata=0x88  
regaddr=0x23   regdata=0x88  
regaddr=0x24   regdata=0x88  
regaddr=0x25   regdata=0x88  
regaddr=0x26   regdata=0x88  
regaddr=0x27   regdata=0x88  
regaddr=0x28   regdata=0x88  
regaddr=0x29   regdata=0x88  
regaddr=0x2A   regdata=0x88  
regaddr=0x2B   regdata=0x88  
regaddr=0x2C   regdata=0x88  
regaddr=0x2D   regdata=0x0  
regaddr=0x2E   regdata=0x0  
regaddr=0x2F   regdata=0x24  
regaddr=0x30   regdata=0x88  
regaddr=0x31   regdata=0x88  
regaddr=0x32   regdata=0x88  
regaddr=0x33   regdata=0x88  
regaddr=0x34   regdata=0x88  
regaddr=0x35   regdata=0x88  
regaddr=0x36   regdata=0x88  
regaddr=0x37   regdata=0x88  
regaddr=0x38   regdata=0x88  
regaddr=0x39   regdata=0x88  
regaddr=0x3A   regdata=0x88  
regaddr=0x3B   regdata=0x88  
regaddr=0x3C   regdata=0x88  
regaddr=0x3D   regdata=0x88  
regaddr=0x3E   regdata=0x88  
regaddr=0x3F   regdata=0x88  
regaddr=0x40   regdata=0x88  
regaddr=0x41   regdata=0x88  
regaddr=0x42   regdata=0x88  
regaddr=0x43   regdata=0x88  
regaddr=0x44   regdata=0x88  
regaddr=0x45   regdata=0x88  
regaddr=0x46   regdata=0x88  
regaddr=0x47   regdata=0x88  
regaddr=0x48   regdata=0x88  
regaddr=0x49   regdata=0x88  
regaddr=0x4A   regdata=0x88  
regaddr=0x4B   regdata=0x88  
regaddr=0x4C   regdata=0x88  
regaddr=0x4D   regdata=0x88  
regaddr=0x4E   regdata=0x88  
regaddr=0x4F   regdata=0x88  
regaddr=0x50   regdata=0x88  
regaddr=0x51   regdata=0x88  
regaddr=0x52   regdata=0x88  
regaddr=0x53   regdata=0x88  
regaddr=0x54   regdata=0x88  
regaddr=0x55   regdata=0x88  
regaddr=0x56   regdata=0x88  
regaddr=0x57   regdata=0x88  
regaddr=0x58   regdata=0x88  
regaddr=0x59   regdata=0x88  
regaddr=0x5A   regdata=0x88  
regaddr=0x5B   regdata=0x88  
regaddr=0x5C   regdata=0x88  
regaddr=0x5D   regdata=0x88  
regaddr=0x5E   regdata=0x88  
regaddr=0x5F   regdata=0x88  
regaddr=0x60   regdata=0x88  
regaddr=0x61   regdata=0x88  
regaddr=0x62   regdata=0x88  
regaddr=0x63   regdata=0x88  
regaddr=0x64   regdata=0x88  
regaddr=0x65   regdata=0x88  
regaddr=0x66   regdata=0x88  
regaddr=0x67   regdata=0x88  
regaddr=0x68   regdata=0x88  
regaddr=0x69   regdata=0x88  
regaddr=0x6A   regdata=0x88  
regaddr=0x6B   regdata=0x88  
regaddr=0x6C   regdata=0x88  
regaddr=0x6D   regdata=0x88  
regaddr=0x6E   regdata=0x88  
regaddr=0x6F   regdata=0x88  
regaddr=0x70   regdata=0x88  
regaddr=0x71   regdata=0x88  
regaddr=0x72   regdata=0x88  
regaddr=0x73   regdata=0x88  
regaddr=0x74   regdata=0x88  
regaddr=0x75   regdata=0x88  
regaddr=0x76   regdata=0x88  
regaddr=0x77   regdata=0x88  
regaddr=0x78   regdata=0x88  
regaddr=0x79   regdata=0x88  
regaddr=0x7A   regdata=0x88  
regaddr=0x7B   regdata=0x88  
regaddr=0x7C   regdata=0x88  
regaddr=0x7D   regdata=0x88  
regaddr=0x7E   regdata=0x88  
regaddr=0x7F   regdata=0x88  
regaddr=0x80   regdata=0x88  
regaddr=0x81   regdata=0x88  
regaddr=0x82   regdata=0x88  
regaddr=0x83   regdata=0x88  
regaddr=0x84   regdata=0x88  
regaddr=0x85   regdata=0x88  
regaddr=0x86   regdata=0x88  
regaddr=0x87   regdata=0x88  
regaddr=0x88   regdata=0x88  
regaddr=0x89   regdata=0x88  
regaddr=0x8A   regdata=0x88  
regaddr=0x8B   regdata=0x88  
regaddr=0x8C   regdata=0x88  
regaddr=0x8D   regdata=0x88  
regaddr=0x8E   regdata=0x88  
regaddr=0x8F   regdata=0x88  
regaddr=0x90   regdata=0x88  
regaddr=0x91   regdata=0x88  
regaddr=0x92   regdata=0x88  
regaddr=0x93   regdata=0x88  
regaddr=0x94   regdata=0x88  
regaddr=0x95   regdata=0x88  
regaddr=0x96   regdata=0x88  
regaddr=0x97   regdata=0x88  
regaddr=0x98   regdata=0x88  
regaddr=0x99   regdata=0x88  
regaddr=0x9A   regdata=0x88  
regaddr=0x9B   regdata=0x88  
regaddr=0x9C   regdata=0x88  
regaddr=0x9D   regdata=0x88  
regaddr=0x9E   regdata=0x88  
regaddr=0x9F   regdata=0x88  
regaddr=0xA0   regdata=0x88  
regaddr=0xA1   regdata=0x88  
regaddr=0xA2   regdata=0x88  
regaddr=0xA3   regdata=0x1E  
regaddr=0xA4   regdata=0x88  
regaddr=0xA5   regdata=0x88  
regaddr=0xA6   regdata=0x88  
regaddr=0xA7   regdata=0x88  
regaddr=0xA8   regdata=0x88  
regaddr=0xA9   regdata=0x88  
regaddr=0xAA   regdata=0x88  
regaddr=0xAB   regdata=0x88  
regaddr=0xAC   regdata=0x88  
regaddr=0xAD   regdata=0x88  
regaddr=0xAE   regdata=0x88  
regaddr=0xAF   regdata=0x88  
regaddr=0xB0   regdata=0x88  
regaddr=0xB1   regdata=0x88  
regaddr=0xB2   regdata=0x88  
regaddr=0xB3   regdata=0x88  
regaddr=0xB4   regdata=0x88  
regaddr=0xB5   regdata=0x88  
regaddr=0xB6   regdata=0x88  
regaddr=0xB7   regdata=0x88  
regaddr=0xB8   regdata=0x88  
regaddr=0xB9   regdata=0x88  
regaddr=0xBA   regdata=0x88  
regaddr=0xBB   regdata=0x88  
regaddr=0xBC   regdata=0x88  
regaddr=0xBD   regdata=0x88  
regaddr=0xBE   regdata=0x88  
regaddr=0xBF   regdata=0x88  
regaddr=0xC0   regdata=0x88  
regaddr=0xC1   regdata=0x88  
regaddr=0xC2   regdata=0x88  
regaddr=0xC3   regdata=0x88  
regaddr=0xC4   regdata=0x88  
regaddr=0xC5   regdata=0x88  
regaddr=0xC6   regdata=0x88  
regaddr=0xC7   regdata=0x88  
regaddr=0xC8   regdata=0x88  
regaddr=0xC9   regdata=0x82

Viele Grüße

Igel1

[Dieter F. (Gast)]

Andreas S. schrieb:
> Weiter unten findet Ihr meinen Code

... leider ohne die ausführenden Routinen ....

[Dieter F. (Gast)]

Dieter F. schrieb:
> Mit 0x21 (lt. Deiner Aufzeichnung) "fühlt" sich die Kamera nicht
> angesprochen.

Ah - ich habe mich auf die 0x21 aus dem Protokoll des Analysers 
verlassen - gesendet wird aber 0x42 zum Schreiben (also korrekt) - 
erkennbar am " W :21h" (und wenn man sich die Bits anschaut ...).
Der Schreib-Befehl bekommt ein ACK und sieht für mich deswegen gut aus.

Der Lese-Befehl bekommt aber ein NACK als Ergebnis - läuft also schief. 
Den muss man sich wohl etwas genauer anschauen.

Nach "I2C-Standard" sollte ein "Repeated-Start"-Kommando vor dem Read 
(nach dem vorangehenden Write-Kommando) kommen. Bei der SCCB-App-Note 
finde ich nichts anderslautendes (aber auch nichts direkt 
bestätigendes). In dem von mir missbrauchten Code wird ein Stopp- mit 
anschließendem neune Start-Kommando versendet - allerdings wird da auch 
nichts gelesen, ist also vermutlich auch nur irgendwo abgekupfert.

Ich würde also mal ein "Repeated-Start" oder auch nur ein Start-Kommando 
für das Read-Kommando (nach vorhergehendem Write-Kommando) - ohne 
eingeschobenes STOP - ausprobieren und schauen, ob ein ACK zurück kommt.

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Der Lese-Befehl bekommt aber ein NACK als Ergebnis - läuft also schief.
> Den muss man sich wohl etwas genauer anschauen.

SCCB ist kein I2C. Das 9.Bit ist nicht NACK/ACK nsch I2C Konvention.

Zitat aus SCCB-Doc:
The ninth Bit is a Don't-Care or an NA bit, depending on wether the data 
transmission is a write or read.

Ich komme im Moment nicht dazu, den Kram anzuwerfen, vielleicht später 
noch...

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Michael U. schrieb:
> or an NA bit, depending on wether the data
> transmission is a write or read

Kommt also darauf an :-) und bei READ spielt es wohl auch eine Rolle.

Außerdem frage ich mich, was das (Bild) ist (Steckbrett ?).

So sieht ein erfolgreiches WRITE aus meiner Sicht aus (Bild 2)

[Andreas S. (igel1)]

@Dieter F.: schön, dass Du hier so mitmischt!

Dieter F. schrieb:
> Michael U. schrieb:
>> or an NA bit, depending on wether the data
>> transmission is a write or read
>
> Kommt also darauf an :-) und bei READ spielt es wohl auch eine Rolle.

Hmmm - hört sich so an, als ob wir da nochmals ein näheres Auge drauf 
werfen sollten.

Ich werde nachher ebenfalls versuchen, eine Signalsequenz von meinem 
funktionierenden STM32F429<->OV7670_mit_FiFo - Aufbau per LA 
mitzuprotokollieren.

> Außerdem frage ich mich, was das (Bild) ist (Steckbrett ?).

Hatte ich auch schon gesehen, hab's aber unter EMV-"Einstreuung" 
verbucht.
Hatte solche Artefakte schön öfter mal bei meinem LA - war bislang noch 
niemals relevant.

> So sieht ein erfolgreiches WRITE aus meiner Sicht aus (Bild 2)

Mich würde nun brennend interessieren:
Wo genau hast Du die Sequenz aufgenommen?
Hast Du bereits einen funktionierenden Aufbau "MC <-> OV7670" am Start?

Wenn ja: könntest Du bitte einmal testen, ob Du ähnliche Probleme beim 
Schreiben der Register 0x00 - 0x10 hast, wie oben in meinem letzten 
Posting geschildert?

Wenn ja, so liegt der Schluss nahe, dass man eben nicht alle Register 
mit beliebigen Werten beschreiben kann - da waren Michael U. und ich uns 
bislang unsicher.

Viele Grüße

Igel1

[Andreas S. (igel1)]

Hei Leutis,

manchmal soll ja pures Lesen helfen ...

So z.B. die Lektüre von OV7670-Datasheet (Version 1.4) - dort 
insbesondere  Tabelle 5. Dort werden die Register der Kamera beschrieben 
und dort ist z.B. dem Inhalt nach zu zu lesen:

Register 05:  "Automatically updated based on chip output format"
Register 06:  "Automatically updated based on chip output format"

Kurzum: wir haben wohl in einigen Fällen versucht, Register zu 
beschreiben, die von der Kamera selbst beschrieben werden.

Kein Wunder, dass das nicht funktioniert.

Ähnlich lautet meine Vermutung bei Registern, die zwar scheinbar korrekt 
auf den Wert 0x88 beschrieben wurden, beim zweiten, späteren Auslesen 
aber wieder einen ganz anderen Wert aufweisen (siehe z.B. Register 0x2D 
und 0x2E). Vermutlich ändern bestimmte Register auch Ihren Inhalt, wenn 
man andere Register beschreibt ...

Fazit: zum Austesten der SCCB-Lese- und Schreibroutinen eignen sich die 
untersten Register eher nicht.

Mein Vorschlag daher: bei unseren SCCB-Lese und Schreibversuchen 
beschränken wir uns auf die Register 0x4F - 0x54. Das sind sogenannten 
"Matrix-Koeffizienten", bei denen ich mal ganz stark davon ausgehe, dass 
sie explizit zum Setzen durch den Benutzer vorgesehen sind.

Hier die Register mit Ihren default-Werten (Spalte 2), die netterweise 
sogar mit dem Datasheet übereinstimmen:

regaddr=0x4F   regdata=0x40  regdata=0x88  SUCCESS
regaddr=0x50   regdata=0x34  regdata=0x88  SUCCESS
regaddr=0x51   regdata=0xC  regdata=0x88  SUCCESS
regaddr=0x52   regdata=0x17  regdata=0x88  SUCCESS
regaddr=0x53   regdata=0x29  regdata=0x88  SUCCESS
regaddr=0x54   regdata=0x40  regdata=0x88  SUCCESS

Viele Grüße

Igel1

[Dieter F. (Gast)]

Andreas S. schrieb:
> Wo genau hast Du die Sequenz aufgenommen?
> Hast Du bereits einen funktionierenden Aufbau "MC <-> OV7670" am Start?

Ja - hatte ich ja geschrieben und auch verlinkt. Ich habe schlicht 
"abgekupfert" und es hat gut funktioniert.

Andreas S. schrieb:
> Wenn ja: könntest Du bitte einmal testen, ob Du ähnliche Probleme beim
> Schreiben der Register 0x00 - 0x10 hast, wie oben in meinem letzten
> Posting geschildert?

Gerne - aber erst in ca. 3 Wochen. Ab morgen sind wir 3 Wochen in Asien 
und da kümmere ich mich vorwiegend um den Reis-Abbau :-)

VG
Dieter

[Andreas S. (igel1)]

Na tolles Projekt hier:

Zwei Urlauber und ein Rentner.
Was würde Deutschland nur ohne mich machen?!

Jetzt muss ich also für Euch 3 mitarbeiten ...

Um das Bruttosozialprodukt weiter hochzuhalten, findet Ihr im Anhang die 
Register-Read- bzw. Write-Sequenz von meiner Konstellation 
STM32F429<->OV7670.

Ganz analog zum Posting vom 09.03.2019 12:13 
(Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)") 
wieder:

- Auslesen von Register  0x00 (mit Wert 0x00)
- Schreiben von Register 0x00 mit Wert 0x88

Wobei die hier abgebildete Folge definitiv korrekt ist!
(auch wenn Register 0x00 scheinbar nicht beschreibbar ist - wie wir 
inzwischen mit hoher Wahrscheinlichkeit vermuten - siehe meine 
vorangegangenes Posting)

Viele Grüße

Igel1

[Andreas S. (igel1)]

Und noch ein "Nachthüpferle" (wie meine Oma zu sagen pflegte):

Habe in anliegender PDF-Datei die SCCB-Protokoll-Bilder von David's 
Schaltung mit meinen STM32F429*-SCCB-Protokollbildern zusammengeführt.

Read-Sequenz unter Read-Sequenz und Write-Sequenz unter Write-Sequenz.

Damit lassen sich die Protokolle optimal vergleichen und eventuelle 
Abweichungen finden.

Jetzt seid Ihr dran mit der Interpretation ...

Viele Grüße

Igel1


PS:  * was übrigens I2C-StdPeriphLib-Befehle nutzt

PPS:  vielleicht brauchen wir ja auch gar keine Fehler mehr suchen, wenn 
wir David's Schaltung einfach nochmals ausprobieren und diesmal nicht 
versuchen Register 0x00 zu beschreiben, sondern Register 0x50.

Vielleicht gab's ja gar keine Fehler in David's Programm ...

Ich kann den Test nur leider nicht so schnell durchführen, weil ich 
dafür erst einmal wieder die Kamera mit Ihren 22 Kabeln umstöpseln muss 
...

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Und noch ein "Nachthüpferle" (wie meine Oma zu sagen pflegte):

Hier: Betthupfer... :-)

Ich schau mir das morgen mal alles an, ich bin auch nicht sicher, ob es 
überhaupt einen Fehler gibt.
Bei Register 0x00 habe ich nur eine Unsicherheit: es ist AGC Gain, eine 
Abhängigkeit kann also zu 0x03 (VREF) bestehen, das veruche ich mal 
rauszufinden.
Daß man nicht alle Register unabhängig auf beliebige Werte setzen kann, 
ist ja klar, vielleicht habe ich mich da auch bei 0x00 verwirren lassen, 
es schien zumindest unabhängig zu sein.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:

> Hier: Betthupfer... :-)

Au Mist, ja natürlich: meine Oma sagte "Betthüpferle" und nicht 
"Nachthüpferle" - danke für die Korrektur! Ist schon erschreckend, wie 
man Dinge, von denen man gedacht hat, man würde sie niemals im Leben 
vergessen, dann doch vergisst.

> Ich schau mir das morgen mal alles an, ich bin auch nicht sicher, ob es
> überhaupt einen Fehler gibt.

Habe gerade mit den oben erwähnten Registern 0x49 - 0x54 getestet:
Diese Register sollten nun wirklich von außen beschreibbar sein und 
nicht vom System in irgendeiner weise beeinflusst werden.

Ergebnis:

Zunächst die wirklich gute Nachricht:

Schreib- und Leseoperationen haben korrekt die Register gesetzt bzw. 
ausgelesen.

Und nun der kleine Wermutstropfen:

Trotz der korrekten Funktionsweise und obwohl der ATmega jeweils per 
USART Fehlercode "0" (=alles korrekt) zurückmeldete, zeigte das 
OV7670-Terminal in der Statusleiste Fehler an. Will sagen: trotz 
korrekter Funktionsweise wird ein Fehler ausgewiesen => Das 
OV7670-Terminal hat hier ganz klar einen Bug, den ich soeben in unserem 
Issue-Tracker hinterlegt habe:
https://github.com/igittigitt/ov7670/issues

> Bei Register 0x00 habe ich nur eine Unsicherheit: es ist AGC Gain, eine
> Abhängigkeit kann also zu 0x03 (VREF) bestehen, das veruche ich mal
> rauszufinden.

Gerne - tu Du mal ...

> Daß man nicht alle Register unabhängig auf beliebige Werte setzen kann,
> ist ja klar, vielleicht habe ich mich da auch bei 0x00 verwirren lassen,
> es schien zumindest unabhängig zu sein.

Yep - ich bin auf dieselbe Falle reingefallen.

> Gruß aus Berlin
> Michael

Gruß aus Aachen ins ferne Berlin (Michael U.), Asien (Dieter F.) und 
nach ??? (David)

Igel1

[Andreas S. (igel1)]

Mist, bevor David sich in den Urlaub abgesetzt hat, hätte er uns seinen 
Code für das OV7670-Terminal dalassen sollen ...

Jetzt hängen wir etwas fest ...

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Mist, bevor David sich in den Urlaub abgesetzt hat, hätte er uns seinen
> Code für das OV7670-Terminal dalassen sollen ...
>
> Jetzt hängen wir etwas fest ...

Prinzipiell hast Du ja recht, aber ich zumindest muß ausnahmsweise mal 
was für Geld machen, also ist etwas PHP, mySQL und Amazon-MWS 
Reportdaten angesagt...

Ansonsten habe ich ja noch die Odroid Go Standortanzeige (Navi will ich 
es nicht nennen), da mußte mir Maperitive erstmal gut 50000 nette kleine 
Kartenbildchen vom OpenStreetMap generieren und runterladen...
Außerdem weiß ich jetzt, daß die JDY-40 2.4GHz Modul vom netten Chinesen 
wirklich gut als serielle bridge zu gebrauchen sind.
Neo6M GPS an die Bridge, LiFePO4-Akkuzelle dazu und ich kann den 
GPS-Empfänger schön am Fenster plazieren, wo er genug Satelliten sieht.
2. Modul an den Odroid Go gesteckt, klappte auf Anhieb.

Hat keinen wirklichen Sinn, das Ganze, aber der Weg ist auch hier das 
Ziel. ;-)

OV7670 und Dragon liegen inzwischen auch parat, ich wollte ja eigentlich 
heute mal ein paar Register beschreiben...

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hatte mir vor 1 Jahr auch mal so einen Neo6M GPS aus China kommen lassen 
- liegt bis heute noch im Dornröschenschlaf.

Aber Danke für den Tip mit den JDY-40 2.4GHz Modulen.

Viele Grüße

Igel1

[Andreas S. (igel1)]

@David:

Habe mir inzwischen Visual Studio installiert - ein echtes Monster ...

Könntest Du evtl. die Sourcen Deiner letzten OV7670-Terminalversion in 
GitHub online stellen?

Viele Grüße

Igel1

[David D. (saturi)]

Hallo!

Trotz, mitgenommenen PC und uC+Camera war Island einfach zu bezaubernd 
und hat mich ganz gefesselt ;-)
Jetzt sitze ich am Flughafen und warte auf den Rückflug. Dann bin ich 
wieder voll dabei! :)
Sourcecode kommt dann auch sobald möglich.
@Igel habe ich dich richtig verstanden? wenn du über den Sniffer 
schaust, stimmt die Kommunikation aber es wird ein Fehler ausgegeben? 
Bei einem einzelnen Register auselsen? Das sollte definitiv nicht so 
sein. Kannst du nochmal wie immer die genauen Schritte zur reproduktion 
mitteilen? Anschalten beschreiben lesen?

Gruß und bis Sonntag!

Andreas S. schrieb:
> @David:
>
> Habe mir inzwischen Visual Studio installiert - ein echtes Monster ...
>
> Könntest Du evtl. die Sourcen Deiner letzten OV7670-Terminalversion in
> GitHub online stellen?
>
> Viele Grüße
>
> Igel1

[Michael U. (amiga)]

Hallo David,

schön, daß Dein Urlaub Dir so gefallen hat.

Michael U. schrieb:
> Dann get camera status -> ok, auch mehrmals.
> Jetzt wieder Kamara initialisieren -> angeblich Error Code 4.
> Angeblich, weil vom AVR definitv 0 zurückkommt und die 4 wohl von der
> Quittung bei get camera status stammt...

Momentaner Stand ist also:

Kopie von oben, das klappt immernoch so (nicht), allerdings kommt jetzt 
Error Code 6, weil Du ja inzwischen die damals fehlenden Kommandos beim 
Init schickst. Es wird also nicht der aktuelle Rückgabecode (der ist 
hier definitiv 0x00) angezeigt, sindern der von der letzten Operation 
davor.

Kamera Init, Camera get status, read Register 0x01:
es wird aus Reg. 0x01 0x80 gelesen (Sniffer) und damit 0x01 0x80 
zurückgeliefert.
Terminal zeigt als gelesen aber 0x01 an.
Schreiben Register 0x01 mit 0x33 ergibt Error Code 128 -> das ist die 
0x80 vom letzten Lesen des Register 0x01 davor.

Jetzt lesen von 0x01 (da wurde ja eben 0x33 reingeschrieben) ergibt 
jetzt scheinbar richtig 0x33, das stimmt aber nicht, die Camera meldet 
immernoch 0x80 als Registerinhalt.

Read Device Settings liefer jetzt aber richtig 0x80 als Inhalt von 0x01,
Im Registerfeld von 0x01 steht immernoch die 0x33, Lesen setzt da jetzt 
richtig die 0x80.

Die Frage, ob die Register in der Camera richtig beschreiben werden bzw. 
ob die sich jeweils mit dem gewünschten Wert überhaupt beschreiben 
lassen, habe ich jetzt mal völlig igniriert. Da müßte man jeweils im 
Datenblatt schauen, ob es da Abhängigkeiten geben könnte usw.
Macht aber im Moment wenig Sinn, wenn das Terminal nicht das anzeigt, 
was laut Sniffer eindeutig vom AVR kommt.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

David D. schrieb:
> Hallo!
>
> Trotz, mitgenommenen PC und uC+Camera war Island einfach zu bezaubernd
> und hat mich ganz gefesselt ;-)

Oh ja - das kann ich mir vorstellen.
Du scheinst ein harter Kerl zu sein, wenn Du um diese Jahrezeit dort 
Urlaub verbringst ...

> Jetzt sitze ich am Flughafen und warte auf den Rückflug. Dann bin ich
> wieder voll dabei! :)

Ha supi - dann kommt wieder Leben in die Bude!

> Sourcecode kommt dann auch sobald möglich.

Wunderbar.

Vielleicht könntest Du mir auch ein paar Tipps dazu geben, wie ich Dein 
Projekt in Visual Studio öffnen sollte - das Teil ist ein Molloch und 
ich möchte nicht unendlich viel Zeit dort reinstecken.

(Ich hab's zwar schon irgendwie geöffnet bekommen, bin mir aber nicht 
wirklich sicher, was ich da tue und wo und wie die Dateien 
sortiert/geordnet sind und welche Datei nun wofür zuständig ist.)

> @Igel habe ich dich richtig verstanden? wenn du über den Sniffer
> schaust, stimmt die Kommunikation aber es wird ein Fehler ausgegeben?

Yep.

> Bei einem einzelnen Register auselsen?

Nein.

Wenn ich ATmega und Terminal neu starte und mich dann ausschließlich auf 
das Einzel-Lesen und Einzel-Schreiben von Registern konzentriere (ich 
teste nur noch mir Register 0x49 - 0x54), so funktioniert das wunderbar.
Keine Fehlermeldung, alles läuft, wie's laufen sollte - supi.

Aber: wenn ich als erste Aktion ein "Read Device Settings" ausführe und 
dann anschließend ein "write register" (Ziel: Register 0x50, Value: 
0x88) ausführe, so erhalte ich die Fehlermeldung:
"Register write failed! ErrorCode: 6"

Und das, obwohl der ATmega per UART mit 0x00 quittiert hatte, dass der 
Schreibbefehl erfolgreich war.

Danach wird's noch wilder:
Wenn ich dann per Einzel-Read-Befehl das Register 0x50 auslese, so wird 
mir im Terminal der Wert 0x34 angezeigt (also der alte Wert, der vor der 
Schreibaktion im Register stand), obwohl der ATmega per UART bereits den 
neuen Wert 0x88 zurückmeldet.

Erst nach einem erneuten "Read Device Settings", besinnt sich der 
Einzel-Lesebefehl, dass doch 0x88 im Register 0x50 zu finden ist.

> Das sollte definitiv nicht so sein.

Nö.

> Kannst du nochmal wie immer die genauen Schritte zur reproduktion
> mitteilen?
> Anschalten beschreiben lesen?

... Wie zuvor beschrieben ...

> Gruß und bis Sonntag!

Gute Reise!

Viele Grüße

Igel1

[Andreas S. (igel1)]

Schade - ich hätte ja mal gerne etwas in Davids Terminal-Code 
herumgeschnüffelt, aber ohne Code wird das nix und das Wochenende ist 
auch bald schon wieder vorbei ...

Viele Grüße

Igel1

[David D. (saturi)]

Andreas S. schrieb:
> Schade - ich hätte ja mal gerne etwas in Davids Terminal-Code
> herumgeschnüffelt, aber ohne Code wird das nix und das Wochenende ist
> auch bald schon wieder vorbei ...
>
> Viele Grüße
>
> Igel1

entschuldige bitte... Mein Fazit vom Wochenende:Samstag spät aus dem 
Urlaub heim gekommen, quasi den ganzen Sonntag geschlafen und heute mit 
zu vielen Eskalationen in den Arbeitsaltag gestartet -.-

nichts desto trotz lade ich jetzt endlich mal das studio projekt hoch.

@Igel: Kurzanleitung: einfach das Projekt öffnen und dann im 
Projektexplorer die einzelnen Klassen öffnen. (Achtung das Programm ist 
sehr unübersichtlich. Das ganze aber in Textform zu erklären ist vlt. 
auch etwas viel :D...

unter bekanntem Link unter Solution zu finden:

https://github.com/igittigitt/ov7670/blob/TWI-Interfac/OV7670-Terminal-Releases/OV7670-Terminal-Solution_V0_9.zip

[Andreas S. (igel1)]

Hi David,

Okay, ich will ja keinen Stress machen - soll ja alles noch Spaß machen 
und locker bleiben.

Hätte halt nur am WE so gut Zeit gehabt ... diese Woche muss ich leider 
Keulen bis zum Umfallen, wird also nix mit Weiter-Debuggen. Allerdings 
müsste ich sowieso erst einmal etwas C# und Visual Studio lernen, bevor 
ich den Terminal- Code sichten könnte.

Viele Grüße

Igel1

[David D. (saturi)]

Whoop Whoop,
ich habe heute doch tatsächlich die nächste halbe Stunde Zeit mich 
endlich nochmal meinem elektro Hobby zu widmen.

In der zwischenzeit habe ich mir gedanken über das 
Kommunikationsprotokoll gemacht.

Was haltet ihr davon, nach JEDEM gesendeten Kommando an den uC einen 
Fehlercode zu erwarten? und dann kann ich abhängig von dem Fehlercode 
entscheiden was zu tun ist.

[Michael U. (amiga)]

Hallo,

ich habe mich im Moment ja auch etwas rar gemacht hier.
Zumindest, was das Terminal angeht, wird sich das auch kaum ändern, mehr 
als Testen werde ich da nichts.
Mir fehlt da einfach eine reale Anwendung dafür. Vor allem, weil ich für 
die OV7670 keinerlei reale Anwendung für mich finde.

Ganz allgemein von meiner Seite: das Kommandoprotokoll würde ich immer 
so anlegen, wie ich es für die Anwendung brauche, um alles Nötige 
abzufangen.
Als Antwort vielleicht hier generell als Erstes den Fehlercode, 0x00 für 
alles ok usw.
Hat den Vorteil, daß man nichts nutzloses senden muß, wenn ein Fehler 
auftritt. Bei z.B. Register lesen brauche ich ja als Antwort nur den 
Inhalt, wenn es geklappt hat. Die Registeradresse kann man mitschicken 
(dann eben immer bei Erfolg) wenn man sich beim Auswerten nicht merken 
will/kann, was man angefordert hat. Macht z.B. Sinn, wenn ich eine 
Sammlung Register zum Ändern rüberschicke und die Differenzen erkennen 
will.
Andere Sachen, wie Dein zeilenweises Lesen des Bildes, machen für mich 
keinen wirklichen Sinn, normalerweise klappt die Übertragung ohne 
Probleme.
Bild anfordern -> 0x00 und dann die Bilddaten oder eben Errorcode und 
Schluß.
Bei ok würde ich noch die erwartete Byteanzahl am Ende prüfen (Timeout 
einplanen, wenn zuwenig Daten kommen, Fehlerzustand, wenn mehr als 
erwartet. usw. usw.
Aber das sind alles Planungen, nur mit Deinen konkreten Vorstellungen 
von der Anwendung Deines Terminal bestimmt werden.

Gruß aus Berlin
Michael