mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Brauche Unterstützung beim OV7670 (bzw. SCCB)


Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... und noch mehr zum Thema:
https://ide.geeksforgeeks.org/nL9paB6EfN

Viele Grüße
Andreas

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und noch eine schönere Version:

https://ide.geeksforgeeks.org/PwEDpstPrZ

Autor: Michael U. (amiga)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Edit: in diesem post stand nur wirres Zeug :D einfach ignorieren....

: Bearbeitet durch User
Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (igel1)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 -.-

: Bearbeitet durch User
Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Doch jetzt schon

Autor: Andreas S. (igel1)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ...

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
Youtube-Video "Human Connection - Wofür gibt es das "Project" Board auf Github?"

> 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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
... 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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dieter F. (jim_quakenbush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

: Bearbeitet durch User
Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dieter F. (jim_quakenbush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> ... und sage uns, warum das Beschreiben des Registers nicht
> funktioniert

Kannst Du bitte SCCB_E zusätzlich aufzeichnen?

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dieter F. (jim_quakenbush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dieter F. (jim_quakenbush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Weiter unten findet Ihr meinen Code

... leider ohne die ausführenden Routinen ....

Autor: Dieter F. (jim_quakenbush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dieter F. (jim_quakenbush)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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)

: Bearbeitet durch User
Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dieter F. (jim_quakenbush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 
...

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

: Bearbeitet durch User
Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: David D. (saturi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Andreas S. (igel1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.