@Michael: Schickes Display - versuche doch mal mit der OV7670-Kamera die Uhrzeit abzulesen - das wäre vermutlich genau die richtige Herausforderung für einen Hobbyisten Deines Kalibers :-) Viele Grüße Igel1 PS: Juhu, gewonnen: erster Beitrag in der dritten MC-Threadseite.
:
Bearbeitet durch User
Glückwunsch:D > Leider stürzt Dein Programm im "Manuellem Modus" beim Versuch "Bild > empfangen" sang und klanglos bereits nach ein paar Zeilen Übertragung > (115200 baud, 8N1) ab - siehe Bild im Anhang. Das sollte nicht so sein :D ... Hmm hab eine Vermutung ab2r kannst du mir genau sagen was du machst? Du hast aber schon die x y und Bytes per Pixel Felder mit integren gefüllt? Ich geh der Sache nachher auf den Grund, wenn ich wieder zuhause bin
Problem gefunden! Da sieht man, dass ich kein gelernter Programmierer bin ... ich sollte doch öfter mit exceptions arbeiten... Naja, hier fürs erste die neuste Version, mit der du jetzt aber ein Bild empfangen können solltest. https://github.com/igittigitt/ov7670/tree/TWI-Interfac/OV7670-Terminal-Releases Bei Problemen einfach wieder den report und das Vorgehen schreiben :D dann finde ich die Fehler schon.. hoffentlich
David D. schrieb: > Problem gefunden! Na wenn das mal keine Weltklasse-Supportzeiten sind, dann weiß ich auch nicht mehr :-) Also: der Durchbruch ist fast geschafft (wie Du im Anhang sehen kannst). Aber: Der Bildaufbau geht nur die ersten Zeilen flott und kommt dann seltsam ins Stocken. Erst wenn mein Bild zu ende übertragen ist, flutscht Dein Bildaufbau wieder weiter, bricht dann aber bei Zeile 90 ab. Offensichtlich wurden aber alle Pixel eingeladen - denn wenn ich ein (oder manchmal gar mehrere) weiteres, neues Bild übertrage, so wird das alte, abgebrochene Bild zuende aufgebaut - erst bis Zeile 183, dann beim nächsten Bildsenden bis Zeile 239 - fertig. Ich sende mit 115200 baud, 8N1. Das Verhalten ist nicht ganz deterministisch - manchmals werden mehr Zeilen übertragen und dann bricht's ab, manchmal weniger. Viele Grüße Igel1 PS: ... bin jetzt mal ein Weilchen weg ...
Hallo, ich habe jetzt noch nicht wirklich was mit dem terminal weitergemacht, aber das Window-Problem ist hier noch nie aufgetrreten. Einen Absturz hat es zumindest auch noch nie gegeben, allerdings bekomme ich sehr häufig eine keine Reaktion mehr nach dem Absenden eines Kommandos. Beispiel: connect -> ok, Ausgabe im Logfenster kommt Kamera initialisieren -> ok, Ausgabe im Logfenster kommt get camera status -> ok, Ausgabe im Logfenster kommt, Registerinhalte werden angezeigt. Jetzt kann ich eigentlich anklicken, was ich will: take Picture complete, take Picture RbyR, Read Device Settings usw. Es wird unten links angezeigt, es wird ins Log-Fenster geschreiben und es passiert nichts. Ich kann dann auch ein anderes Kommando anwählen, wie gehabt. Safe File, Open File usw. funktionieren aber weiterhin richtig. Darüber muß ich erstmal nachdenken... Andreas S.: was ich im Moment garnicht verstehe: ich lese in meinem Programm von der Kamera in den FiFo: - auf VSYNC LOW warten um sicher zu sein, daß ich nicht in einen aktiven VSYNC gerate - auf VSYNC HIGH warten - WRST auf LOW - auf VSYNC LOW warten (Endes des SYNC-Impulses) - WRST auf HIGH - WR auf HIGH - auf VSYNC HIGH warten (beginn des SYNC-Impulses) - WR auf LOW Dann lese ich im loop 240 Zeilen zu je 320 Pixel aus und schicke die raus. Es müssen also in einer Zeile jeweils 32ß Pixel im FiFo sein, sonst bekäme ich nie ein Bild weil es von zeile zu zeile eine Veschiebung gäbe. Das am Rand fehlerhafte Pixel sind, heißt für mich, daß da von der Kamera Schrottdaten in den FiFo kamen, aber eben in der richtigen Anzahl. Gruß aus Berlin Michael
Michael U. schrieb: > Das > Display spielt bei keinem wirklich, Stromquellen-Schieberegister für die > Zeilen und Decoer/MosFET-IC für die Spalten. Beides China, chinesiche > Datenblätter in denen alles wichtige nicht drinsteht... Bisher habe ich in solchen Fällen die Chips gefunden, welche die Chinesen als Vorlage für die ihren genommen haben. Mit den entsprechend besser lesbaren Datenblättern...
Hallo, @Tom (Gast): ist mir bisher nicht gelungen... FM6126A zurück zur OV7670: ich komme erst morgen dazu, das jetzt hier aufzuräumen und weiter zu testen. Gruß aus Berlin Michael
Tom schrieb: > Bisher habe ich in solchen Fällen die Chips gefunden, welche die > Chinesen als Vorlage für die ihren genommen haben. > Mit den entsprechend besser lesbaren Datenblättern... Zeig mal
Michael U. schrieb: > take Picture complete, > take Picture RbyR, > Read Device Settings usw. > Es wird unten links angezeigt, es wird ins Log-Fenster geschreiben und > es passiert nichts. Ich kann dann auch ein anderes Kommando anwählen, > wie gehabt. > Safe File, Open File usw. funktionieren aber weiterhin richtig. > take Picture complete, > take Picture RbyR, Setzten beide meine Software voraus, ich gehe davon aus, dass du diese benutzt, da sonst das Register Schreiben/Lesen ebenfalls nicht funktionieren würde. Ich gebe zu, dass das Programm DERZEIT nicht wirklich intuitiv bzw. sogar sinnvoll zu bedienen ist. Ich bin aber gerade dabei, hier einiges anzupassen, das das Bild, das Andreas mit meinem Programm aufnehmen konnte, mir einen deutlichen Motivationsschub verpasst hat! :) Nochmal eine ganz kurze Schritt für Schritt Anleitung wie es klappen sollte: 1) Com Port verbinden und Baudrate gleichhaben (brauche ich dir nicht zu sagen ;-) 2) Kamera initialisieren drücken. Jetzt sollten zwei einträge im Log erscheinen. 1. initialisiere Kamera, 2. initialisierung erfolgreich. Sollte hier die initialisierung fehlschlagen, einfach ein paar mal read register klicken und dann nocheinmal Kamera initialisieren versuchen. manchmal scheinen sich irgendwoher Bytes im PC-Seitigen COM Buffer einzufinden, die dann fälchlicherweise als ErrorCode identifiziert werden. 3) Klick auf get camera status. Jetzt sollte unbedingt, bei Version 0x76 0x73 stehen. Damit ist sicher gestellt, dass die richtigen Register von der Kamera gelesen werden. 4. Register einstellen (entweder bei Write Register oder mit geladenen Settings. Ich verwende aktuell: 0x11 0x00 0x12 0x16 0x40 0x14 0x42 0x08 0x15 0x00 (Ich hoffe ihr könnt die bestätigen) 5. get camera status klicken. Jetzt müssen Resolution auf QVGA und Color Format auf RGB565 stehen. Andere Formate werden noch nicht unterstützt und in einer internen Fallunterscheide fürs erste einfach übergangen. Dann tut sich bei deinem Bildaufbau garnichts. 6. Steht soweit erstmal alles richtig dar, kann jetzt mit take Picture complete oder take Picture RbyR ein Bild aufgenommen werden. (Ist auch etwas größer zu sehen unter dem tab _picture bei einem der Beiden Bildboxen das Häckchen zur Sychronisierung setzten. Ich hoffe so hast du erfolg. Bitte um Rückmeldung :)
David D. schrieb: > Ich gebe zu, dass das Programm DERZEIT nicht wirklich intuitiv bzw. > sogar sinnvoll zu bedienen ist. Ich bin aber gerade dabei, hier einiges > anzupassen, das das Bild, das Andreas mit meinem Programm aufnehmen > konnte, mir einen deutlichen Motivationsschub verpasst hat! :) Das freut mich sehr für Dich - ich bin ganz sicher, dass wir Dein MC-Programm auch noch in die Gänge bekommen. Wenn Du Zeit und Lust hast, den o.g. Fehler bzgl. Abbruch beim Bildaufbau noch zu fixen (vgl. mein letztes Posting: Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)") so wäre das super. Bitte nenne mir einmal Deine Funktion, in der Du das Bild als ganzes überträgst (also ohne CR+LF), dann würde ich mir diese Funktion einmal gesondert angucken und brauche mich nicht durch den ganzen Code zu wühlen. Viele Grüße Igel1
Andreas S. schrieb: > Wenn Du Zeit und Lust hast, den o.g. Fehler bzgl. Abbruch beim > Bildaufbau noch zu fixen (vgl. mein letztes Posting: > Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)") so > wäre das super. Tja... Da liegt der Hund begraben :D... Ich denke, dass ist das gleiche Problem, dass ich auch bei den Read All Register auslesen habe. Es ist leider, wie du schon geschrieben hast, passiert es scheinbar zufällig... Ich kann mir da aktuell noch keinen Reim drauf bilden. Da kann ich leider nicht mit einem Hotfix dienen :D diese Problem verfolgt mich schon des längeren. Aber auch das werde ich hoffentlich irgendwann einmal finden > Bitte nenne mir einmal Deine Funktion, in der Du das Bild als ganzes > überträgst (also ohne CR+LF), dann würde ich mir diese Funktion einmal > gesondert angucken und brauche mich nicht durch den ganzen Code zu > wühlen. Die ist relativ "einfach" gehalten: es geht los in der main.c case 0x0C:
1 | OV7670_captureNewImage(); |
2 | OV7670_ResetFifoReadPointer(); |
3 | sendFrameBufferToUART (width, height, BytesPerPixel); |
alle drei Funktionen aus der Datei: OV7670_withFifo.c Die Namen sind denke ich selbsterklärend.
Sonntag, 17.02.2019 .... irgendwann mitten in der Nacht, David D. gelingt nach 1,5 JAHREN Entwicklungszeit der vermeintliche Durchbruch. Das bisherige Problem? BANAL! Lediglich der pure Zufall brachte ihm die Erkenntnis. Er hatte sich entschlossen nur noch eine letzte Messung in dieser Nacht vorzunehmen, bevor er am nächsten Morgen mit der Betonwalze über diese Kamera fahren würde. Die Zielführende Messung war die Pulsdauer des WCK. Schon hundertmal durchgeführt, ohne Erfolg. Doch diesmal sollte es anders kommen, denn diesmal drehte er das Kamera Modul nicht einfach herum, um die Pins des Fifos zu erreichen. Dem Zufall geschuldet war, dass gerade seine 3. Hand Lupe in Reichweite stand, in die er die Kameraplatine einspannte und so die Verkabelung - eigentlich nicht hinnehmbar - unter Spannung setzte. Ein kurzer Klick auf take picture und den Blick zum Oszilloskop gewannt brachte die ernüchternde Erkenntnis nichts neues entdeckt zu haben. Ein Blick zurück zum Bildschirm, um erneut ein Bild aufzunehmen und.... WAS? eine Colorbar im Terminal Programm? Wo kommt die denn jetzt her? Nichts am uC verändert, nichts am Terminal Programm? Kurze Augenblicke der Ratlosigkeit und dann der Gedanke daran, dass es wohl an der EMV liegen könnte, schließlich standen bei ihm einige elektrische Geräte in kurzer Distanz rund um den Versuchsaufbau. Kurz ausgespannt, wieder eingespannt.... und nichts... Dann schoss ihm der Gedanke in den Kopf, evtl. mit der Oszilloskop Probe zwei Kontakte gleichzeitig berührt zu haben und so den FIFO in einen funktionierenden Zustand versetzt zu haben, doch nein, das erschien ihm dann doch zu unwahrscheinlich. Was konnte es also gewesen sein? Es traf ihn wie einen Blitz: die Kabel der einzelnen Breadboardverbindern sind durch das einspannen in die andere Richtung gebogen gewesen als sonst, kurz nachgestellt und ZACK! die Colorbar ist da. Offenbar handelt es sich um eine Kontaktschwierigkeit an den Steckern, die eigentlich allesamt bombenfest an der Kamera sitzen. Leichte Kontaktierungsprobleme die eine so fatale Wirkung haben, dass von dem eigentlichen Bild nichts mehr zu erkennen ist. Ich danke an dieser Stelle dem Schicksal :D Morgen wird also gelötet und dann bin ich wieder mit im Rennen! Anbei zwei Bilder, 1x Colorbar (klar hier stimmt noch einiges nicht, aber es sind schonmal Balken zu sehen! und 2x meine Handy Taschenlampe in völliger Dunkelheit :D Bis Morgen Gruß David
:
Bearbeitet durch User
Hallo, David D. schrieb: > Ich danke an dieser Stelle dem Schicksal :D > Morgen wird also gelötet und dann bin ich wieder mit im Rennen! erstmal Glückwunsch zum Erfolgserlebnis! Und nun rate mal, warum ich mir die Adapterplatine gelötet habe... Deine AVR-Source bei github ist die Deine aktuelle? Ich habe es jetzt mal in ein AVR-Studio Projekt geworfen, muß nachher mal meinen Dragon raussuchen zum flashen. Die 22 warnings ignoriere ich jetzt mal, sind zwar nicht ganz unberechtigt, stören aber die Funktion im Moment nicht. Mal überlegen, ob ich den uralten GCC noch durch einen aktuellen ersetze, vermutlich nicht, es gibt da noch 3-4 fast 10 Jahre alte Projekte, an die ich vielleicht noch mal rangehe und wer weiß, ob die dann noch sauber laufen. ;-= Gruß aus Berlin Michael
Glückwunsch, David! Welch ein Krimi, den Du da sehr nett und lustig beschrieben hast. Besonders bei der Passage mit der Betonwalze musste ich lachen. Sollte ich heute Zeit finden, so gucke ich mir Deinen Code einmal an. Allerdings beweist das Colorbarbild, dass Du eigentlich schon alles richtig machst - bis auf die Farbdecodierung, also das Entnehmen der Farbinfio aus den 2 Bytes des RGB565. Viele Grüße Igel1
David D. schrieb: > Die ist relativ "einfach" gehalten: > es geht los in der main.c case 0x0C: > OV7670_captureNewImage(); > OV7670_ResetFifoReadPointer(); > sendFrameBufferToUART (width, height, BytesPerPixel); > > alle drei Funktionen aus der Datei: OV7670_withFifo.c > Die Namen sind denke ich selbsterklärend. Liegt hier die letzte Version Deines Codes: https://github.com/igittigitt/ov7670/tree/TWI-Interfac/OV7670-AVR/OV7670-AVR ? Scheint mir etwas alt zu sein - ausserdem gibt es dort keine Datei "OV7670_withFifo.c" sondern nur eine Datei "OV7670_with_Fifo.c", die immerhin schon 6 Tage alt ist. Die von Dir erwähnten Funktionen sind allerdings alle darin enthalten. Bevor ich aber nun die falsche Datei analysiere, wollte ich erst einmal nachfragen ... Viele Grüße Igel1 PS: ... bin jetzt vermutlich erst einmal ein paar Stunden Wandern, dann Besuch, dann Familie ...
:
Bearbeitet durch User
Michael U. schrieb: > Und nun rate mal, warum ich mir die Adapterplatine gelötet habe... Ich hatte es auch schon länger vor, aber nunja... daran hätte ich nicht gedacht. > Deine AVR-Source bei github ist die Deine aktuelle? jetzt ja, warum er es gestern nicht sync. hat, weiß ich nicht. (also im TWI branch) >Allerdings beweist das Colorbarbild, dass Du eigentlich schon alles >richtig machst - bis auf die Farbdecodierung, also das Entnehmen der >Farbinfio aus den 2 Bytes des RGB565. Nein, leider nicht. denn wenn ich mehrmals auslese bekomme ich verschiedene Colorbars, zum Teil auch im Bild gewechselt, also schein ich troztdem ein Problem mit dem Rücksetzen des Read oder Write Pointers zu haben... >Scheint mir etwas alt zu sein - ausserdem gibt es dort keine Datei >"OV7670_withFifo.c" sondern nur eine Datei "OV7670_with_Fifo.c", die >immerhin schon 6 Tage alt ist. Die von Dir erwähnten Funktionen sind >allerdings alle darin enthalten. ja, jetzt die neuste online. Ich dachte mir, die Transferaugabe, sich einen "_" zu denken kriegt ihr hin ;-) ich meine natürlich diese. https://github.com/igittigitt/ov7670/tree/TWI-Interfac/OV7670-AVR/OV7670-AVR viel Spaß beim Wandern
Hallo, github ist für mich normalerweise nur Quelle irgendwelcher Arduino/ESP-Geschichten... Ich durchsuche die commits da normalerweise nur, wenn ich nach einem bestimmten Problem suche, das evtl. schon behoben ist, aber noch nicht im relaese gelandet ist. Ich werde mit Sicherheit auch hier nur das aktuelle Archiv runterladen und daruf vertrauen daß es das ist: aktuell. Bei mir zumindest einer der Gründe, weshalb ich z.B. lieber ein aktuelles zip mit einem Projekt nehme und nur vergleiche, welche Dateien neuer sind. So, ich habe jetzt meinen Dragon mal angeworfen und das, was ich hier hatte, im alten AVR-Sturdo compiliert und geflasht. Soweit erstmal ok. Cam-Init klappt, Register klappt, Einstellungen passen irgendwie nicht, er setzt bei get camera status VGA und will 480 Zeilen einlesen. Reproduzierbar kommt er dabei bis Zeile 29 und dann steht der Laden. Terminal zu, AVR Reset, alles von vorn und wieder Zeile 29. Alles bei 230400 getestet. ok, bei 19200 liest er nur eine Zeile ein. Jetzt doch mal alle Dateien durch die im Link von Andres S. ersetzt, identisches Ergebnis. Ich habe nur mein Pinout in OV7670_with_Fifo.h angepasst und die Baudrate in UART.c, dort X2 gesetzt wegen des kleineren Fehlers bei hohen Baudraten und UBRR0L entsprechend gesetzt. Jetzt sind auch hier erstmal andere Sachen auf dem Plan. Gruß aus Berlin Michael
Hallo, ok, Du bist schnell, David... Sourcen aus Deinem letzten Link reingeworfen, compiliert. Immernoch als default VGA und YUV? Warum nicht QVGA und RGB565? Er macht beim Bild lesen alle 21-22 Zeilen eine Kaffepause, liest dann aber weiter. Muß ich später mal reinschauen, mit 230400 dauert ein Bild aus dem Fifo lesen doch sonst nur wenige Sekunden? PS: er hat inzwischen 479 Zeilen abgeholt, für die letzte hat er keine Lust mehr... PPS: nach Neustrta von Terminal und AVR läuft jetzt wieder kein Kamera Init, ich hör jetzt erstmal auf. Gruß aus Berlin Michael
:
Bearbeitet durch User
Michael U. schrieb: > PS: er hat inzwischen 479 Zeilen abgeholt, für die letzte hat er keine > Lust mehr ... weil er vermutlich bei Zeile 0 beginnt ...
Hallo, Andreas S. schrieb: > ... weil er vermutlich bei Zeile 0 beginnt ... da steht doch aber "hole Zeile 479 von 480"... ;-) Gruß aus Berlin Michael
Michael U. schrieb: > da steht doch aber "hole Zeile 479 von 480"... ;-) Da steht vermutlich auch "hole Zeile 0 von 480" ? Wenn ja, so passt ja alles (... bis auf die Optik ...) Viele Grüße Igel1
Hi David, weil sich Deine Camera->FiFo - Einleseroutine in einigen Punkten doch deutlich von meiner Routine unterscheidet, habe ich Deine Routine "OV7670_captureNewImage (void)" in ARM-Sprache übersetzt und anschließend testweise meine durch Deine Routine ersetzt:
1 | void OV7670_captureNewImage_David (void) |
2 | { |
3 | //OV_WR_PORT &= ~(1<<OV_WR_PinNo); //Write Disabled (defined start value) |
4 | Write_FIFO_WR(Bit_RESET); |
5 | |
6 | // while(!getValueOfPin(OV_VSync_PIN,OV_VSync_PinNo)); //Wait for VSync to indicate a new Frame |
7 | while (!Read_VSYNC()) {} |
8 | |
9 | //OV7670_ResetFifoWritePointer();//Enable Write Pointer |
10 | Write_FIFO_WRST(Bit_RESET); |
11 | Delay(1); |
12 | Write_FIFO_WRST(Bit_SET); |
13 | |
14 | |
15 | //while(getValueOfPin(OV_VSync_PIN,OV_VSync_PinNo)); |
16 | while (Read_VSYNC()) {} |
17 | |
18 | //OV_WR_PORT |= (1<<OV_WR_PinNo); //Write Enable so that the camera can write on the FrameBuffer |
19 | Write_FIFO_WR(Bit_SET); |
20 | |
21 | //while(!getValueOfPin(OV_VSync_PIN,OV_VSync_PinNo)); //Wait for the next VSync Pulse, so the frame is complete |
22 | while (!Read_VSYNC()) {} |
23 | |
24 | //OV_WR_PORT &= ~(1<<OV_WR_PinNo); //Write Disabled that the picture is safe in the Framebuffer |
25 | Write_FIFO_WR(Bit_RESET); |
26 | |
27 | // _delay_ms(20); |
28 | |
29 | //Reset the Write Pointer, (not sure, if that will work) |
30 | //OV7670_ResetFifoWritePointer(); |
31 | } |
Ergebnis: funktioniert auf meinem STM32F429 tadellos. Viele Grüße Igel1
:
Bearbeitet durch User
Hi David, habe gerade einmal gesucht, ob Du "Output Enable" auf LOW ziehst, aber auf die Schnelle nichts dergleichen in Deinem Code gefunden. Bitte schau selbst einmal nach, ob Du den Pin FiFo_OE des Moduls irgendwo in Deinem Programm auf LOW ziehst. Viele Grüße Igel1
Hallo, Andreas S. schrieb: > habe gerade einmal gesucht, ob Du "Output Enable" auf LOW ziehst, aber > auf die Schnelle nichts dergleichen in Deinem Code gefunden. er und auch ich haben ihn fest auf GND verdrahtet, wir sind ja alleine am Bus und lesen dort nur Daten. PS: vorhin ganz vergessen... Woltest Du nur ein Bild von der Uhrzeit auf dem Display oder soll noch eine Texterkennung mit formatierter serieller Ausgabe der Zeit rein? ;-) PPS: ein Glück, meine Software geht noch undd as Geheimnis des UART-Wandlers auf dem UNO habe ich auch halbwegs ergründet bzw. umgangen, jetzt also wieder mit 1MBaud. Mit dem Licht kommt sie bei den Einstellungen aber nicht richtig zurecht... Gruß aus Berlin Michael
:
Bearbeitet durch User
Michael U. schrieb: > er und auch ich haben ihn fest auf GND verdrahtet, wir sind ja alleine > am Bus und lesen dort nur Daten. Das widerspricht aber dem Schaltplan von David: Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)" Dort liegt FiFo_OE an Pin D13. Oder wurden danach noch andere Absprachen getroffen, die ich überlesen habe? > PS: vorhin ganz vergessen... > Woltest Du nur ein Bild von der Uhrzeit auf dem Display oder soll noch > eine Texterkennung mit formatierter serieller Ausgabe der Zeit rein? ;-) B) > PPS: ein Glück, meine Software geht noch undd as Geheimnis des > UART-Wandlers auf dem UNO habe ich auch halbwegs ergründet bzw. > umgangen, jetzt also wieder mit 1MBaud. > Mit dem Licht kommt sie bei den Einstellungen aber nicht richtig > zurecht... ?? Willst Du sagen, dass das Bild aus Deinem letzten Posting von der OV7670-Camera stammt? Viele Grüße Igel1
Was mich noch sehr interessieren würde, ist folgendes: Wenn man die Frame-Ausgabe von Davids MC-Programm per Realterm (also nicht mit Davids PC-Programm) mit gemütlichen 115200 baud empfängt und die Daten von Realterm direkt in eine Datei umleiten lässt, kommt dann ein korrektes Bild dabei heraus? Will sagen: hat David schon sein PC-Programm als mögliche Fehlerursache ausgeschlossen? Viele Grüße Andreas
Andreas S. schrieb: >> er und auch ich haben ihn fest auf GND verdrahtet, wir sind ja alleine >> am Bus und lesen dort nur Daten. > > Das widerspricht aber dem Schaltplan von David: > Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)" > > Dort liegt FiFo_OE an Pin D13. > Oder wurden danach noch andere Absprachen getroffen, die ich überlesen > habe? Hat sich inzwischen geklärt: ich habe in einem der vorigen Posting folgende Aussage von David gefunden: "Edit: OE überigens auf GND" Damit ist das schon einmal geklärt und als Fehlerursache ausgeschlossen. Viele Grüße Igel1
Hallo, hatte heute leider Vereins-Dienst und bin daher nich viel weiter gekommen, als 4 von 22 Pins fertig zu löten... Immerhin, damit läuft die Kamera schon und Register schreiben und lesen geht auch. Leider bin ich ab morgen erstmal für zwei Tage weg und kann mich danach erst um deine Routine kümmern @ Igel. Aber ich wollte zuerst das gelötete fertig haben um sicher zu sein, dass ich keinen Wackler mehr im Kabel habe. >Bitte schau selbst einmal nach, ob Du den Pin FiFo_OE des Moduls >irgendwo in Deinem Programm auf LOW ziehst. Michael hats richtig gesagt: Wir beide haben ihn HW technisch auf GND. Auch wenn es offensichtlich mal anders war :D das kann ich aber jetzt nicht mehr nachvollziehen. Bringe da auch gerne eine geupdatete schematic Andreas S. schrieb: > Wenn man die Frame-Ausgabe von Davids MC-Programm per Realterm (also > nicht mit Davids PC-Programm) mit gemütlichen 115200 baud empfängt und > die Daten von Realterm direkt in eine Datei umleiten lässt, kommt dann > ein korrektes Bild dabei heraus? > > Will sagen: hat David schon sein PC-Programm als mögliche Fehlerursache > ausgeschlossen? > > Viele Grüße > > Andreas Nein habe ich nicht, ich dachte, das hättest du mit dem Beweisbild. Bis Mittwoch (oder vlt. zwischendurch mobil) Gruß David
David D. schrieb: > Andreas S. schrieb: >> Wenn man die Frame-Ausgabe von Davids MC-Programm per Realterm (also >> nicht mit Davids PC-Programm) mit gemütlichen 115200 baud empfängt und >> die Daten von Realterm direkt in eine Datei umleiten lässt, kommt dann >> ein korrektes Bild dabei heraus? >> >> Will sagen: hat David schon sein PC-Programm als mögliche Fehlerursache >> ausgeschlossen? >> >> Viele Grüße >> >> Andreas > Nein habe ich nicht, ich dachte, das hättest du mit dem Beweisbild. > Bis Mittwoch (oder vlt. zwischendurch mobil) Meinst Du mit "Beweisbild" das Bild aus diesem Posting: Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)" ? Wenn ja, so beweist das leider nur, dass Dein PC-Programm teilweise funktioniert, denn es bricht ja immer nach X Zeilen ab. Ich würde an Deiner Stelle das PC-Programm als Fehlerquelle erst einmal ausschließen, indem Du die Daten erst einmal mit Realterm in einer Datei auffängst. Mit meiner weiter oben erwähnten Website, kannst Du Dir diese Datei dann anzeigen lassen. Wenn dabei Müll herauskommt => Bug im MC-Programm. Außerdem würde ich den FiFo mehrfach auslesen und die per Realterm geschriebenen Dateien alle miteinander vergleichen. Wenn nicht identisch => Bug im MC-Programm. Sodann würde ich an vielen Stellen noch 20us delay einschieben, um das RCK-Signal etwas symmetrischer zu machen (nur so ein Bauchgefühl). Ich würde nicht in einem Befehl RCK=LOW und im nächsten Befehl direkt RCK=HIGH setzen (oder umgekehrt), sondern stets min. 20us Päuschen dazwischen spendieren. Insgesamt würde ich sowieso eher den Timer-Ansatz bevorzugen und RCK gleichmäßig durchlaufen lassen. Ob das des Rätsels Lösung ist, kann ich Dir allerdings auch nicht versprechen. > Die ist relativ "einfach" gehalten: > es geht los in der main.c case 0x0C: > > OV7670_captureNewImage(); > OV7670_ResetFifoReadPointer(); > sendFrameBufferToUART (width, height, BytesPerPixel); > > alle drei Funktionen aus der Datei: OV7670_withFifo.c > Die Namen sind denke ich selbsterklärend. Habe mir alle 3 Funktionen mittelgrob (d.h. nicht ganz oberflächlich, aber auch nicht ganz haarklitzeklein) angeschaut und keine direkten Fehler gefunden. Viele Grüße Igel1
Hallo, Andreas S. schrieb: > ?? > Willst Du sagen, dass das Bild aus Deinem letzten Posting von der > OV7670-Camera stammt? ja sicher.... Ich schmeiße die Arduino-UNO-Hardware bald aus dem Fenster... Der Mega16U2 als USB-seriell-Wandler macht da definitiv Mist, der CH340 auf dem nano hatte die Probleme nicht. Ich will aber meinen Adapter nicht umlöten!!! Das mit /OE hatte ich aus seinen Sourcen, ich muß die Pinzuordnung soweiso durch meine ersetzen, ich habe die Pins etwas anders verteilt. Ich weiß im Moment noch nicht, wie ich mit Davids Source weiter vorgehe. Entweder ich mache seine UART-Routinen auf dem AVR neu und anders, mit seinem terminal kompatibel zu beliben sollte nicht das Problem zu sein, mir ist das irgendwie zu instabil und nicht immer reproduzierbar, was da passiert. SCCB scheint ja soweit zu spielen. Mich stört im Moment, daß ich nicht einfach ein Bild anfordern kann, VGA geht soweiso nicht wegen der Fifogröße, QVGA mit RGB565 und QVGA mit YUV und nur Y senden wären brauchbare Voreinstellungen. Ich werde mal meine Registersettings in sein Terminal laden und schauen, ob es Bilder ergibt, das geht ja jetzt als Struktur einfach. Dazu muß aber das Fifo übertragen zuverlässig sein. Ich lese ja bei mir immernoch mit TeraTerm ein, speichere binär und lasse es mir von Irfanview anzeigen. Registerdaten sind nur im AVR-Source, compilieren und neu flashen dauert ja nicht lange, egal ob AVR-Studio oder ArduinoIDE. Mal im Laufe des Tages in Ruhe drüber nachdenken... so, inzwischen ist etwas mehr Licht in der Ecke, also noch ein Bild der OV7670 mit meiner Software. Gruß aus Berlin Michael
Michael U. schrieb: > Hallo, > > Andreas S. schrieb: >> ?? >> Willst Du sagen, dass das Bild aus Deinem letzten Posting von der >> OV7670-Camera stammt? > > ja sicher.... > Ich schmeiße die Arduino-UNO-Hardware bald aus dem Fenster... > Der Mega16U2 als USB-seriell-Wandler macht da definitiv Mist, der CH340 > auf dem nano hatte die Probleme nicht. Ich will aber meinen Adapter > nicht umlöten!!! Hmmm - Mist, das ist wirklich ärgerlich. Ich kann Dich da gut verstehen. > Das mit /OE hatte ich aus seinen Sourcen, ich muß die Pinzuordnung > soweiso durch meine ersetzen, ich habe die Pins etwas anders verteilt. Okay. > Ich weiß im Moment noch nicht, wie ich mit Davids Source weiter vorgehe. > Entweder ich mache seine UART-Routinen auf dem AVR neu und anders, mit > seinem terminal kompatibel zu beliben sollte nicht das Problem zu sein, > mir ist das irgendwie zu instabil und nicht immer reproduzierbar, was da > passiert. ... hier hat's Deinen Satz irgendwie zerwürfelt ... > SCCB scheint ja soweit zu spielen. Mich stört im Moment, daß ich nicht > einfach ein Bild anfordern kann, VGA geht soweiso nicht wegen der > Fifogröße, QVGA mit RGB565 und QVGA mit YUV und nur Y senden wären > brauchbare Voreinstellungen. Yep - sollte aber kein Akt sein, dies in Davids Code umzustellen. Das wäre sowieso mein Ansatz: erst einmal nur ein schnödes QVGA RGB565-Bild aus dem FiFo auslesen - mit fixen Register-Settings. Erst wenn das zuverlässig funktioniert, würde ich weitermachen. Kurzum: Reduktion auf das Minimum, um maximal viele Fehlerquellen zu eliminieren. > Ich werde mal meine Registersettings in > sein Terminal laden und schauen, ob es Bilder ergibt, das geht ja jetzt > als Struktur einfach. > > Dazu muß aber das Fifo übertragen zuverlässig sein. Ich lese ja bei mir > immernoch mit TeraTerm ein, speichere binär und lasse es mir von > Irfanview anzeigen. Bevor ich lange suche: wie läßt Du Dir mit Irfanview ein QVGA RGB565-Bild, welches in einer Datei ohne jeglichen Header liegt, anzeigen? > Registerdaten sind nur im AVR-Source, compilieren > und neu flashen dauert ja nicht lange, egal ob AVR-Studio oder > ArduinoIDE. > > Mal im Laufe des Tages in Ruhe drüber nachdenken... Darum beneide ich Dich wirklich. Aktuell kann ich mir noch nicht einmal vorstellen, meine Rente lebend zu erreichen ... > so, inzwischen ist etwas mehr Licht in der Ecke, also noch ein Bild der > OV7670 mit meiner Software. Sehr schön, Michael! Die Bilder sind so gut, dass man vermutlich tatsächlich mit einfacher Bildverarbeitung die Uhrzeit daraus ablesen könnte :-) KI soll dafür ja superfesch sein ... Nochmals zurück zu David's Problemen: wenn ich noch ein zusätzliches OV7670+AL422B-Modul hätte, wäre meine Hemmschwelle zum Ausprobieren seines Codes auf meinem Arduino Nano deutlich niedriger. Aber ohne zweites Modul schrecke ich wirklich vor der stundenlangen Kabellitis zurück (denn der LogicAnalyzer will ja auch noch verkabelt sein). Und mit dem Dragon habe ich auch noch nichts gemacht (wenngleich er hier rumliegt) und mein AVR-Studio ist auch mehrere Jahre nicht mehr geupdated worden und Plattenplatz habe ich auch irgendwie nicht mehr ... Soll ich mir das wirklich alles antun, wo ich doch so schöne ARM-Boards hier rumliegen habe? Hmmm, ich weiß nicht, ich weiß nicht ... Ich glaube, ich setze einfach auf Dich, Michael, dass Du David's Fehler findest - ist deutlich bequemer für mich ;-) Viele Grüße Igel1
Hallo, Andreas S. schrieb: > Bevor ich lange suche: wie läßt Du Dir mit Irfanview ein QVGA > RGB565-Bild, welches in einer Datei ohne jeglichen Header liegt, > anzeigen? Datei->Öffnen als-> RAW-Datei Im Requester dann eben Größe einstellen, Header auf 0 Bytes, Format 16BPP, 5:6:5, Big Endian, Interleaved und ok. Oder eben 8BPP für nur Y. Wenn die Datei .raw heißt und man sie Irfanview als default zuweist, kann man auch einfach doppelklicken und der Requester kommt sofort und man muß nur OK klicken. Andreas S. schrieb: > Die Bilder sind so gut, dass man vermutlich tatsächlich mit einfacher > Bildverarbeitung die Uhrzeit daraus ablesen könnte :-) > KI soll dafür ja superfesch sein ... kein Problem. Habe ja erst 1148 Byte des 32k Flash belegt........ Mein AVR-Studio ist die 4.18, der GCC der WinAVR-20100110, na und? ;-) Plattenplatz? Soll ich Dir ein paar TB abgeben? Mein Bekannter baut öfter mal sein Datengrab um und dann landen bei mir meist die kleinen Platten, de er ausgebaut hat. Im Moment sind wohl seine letzten 3TB-Platten bei mir gelandet... Er möge mir also noch lange erhalten bleiben. :-)) LA hänge ich meist erst ran, wenn ich mir einbilde, keinen Fehler in den Sachen drinzuhaben. Ein 8Bit-AVR ist gut überschaubar und auch der alte GCC optimiert die IO-Sachen da schon (fast) perfekt. Ich habe jetzt einfach mal angefangen, den UART-Kram umzubauen, keine Ahnung, ob David dann noch mit mir redet... ;-) Gruß aus Berlin Michael
Michael U. schrieb: > Datei->Öffnen als-> RAW-Datei > Im Requester dann eben Größe einstellen, Header auf 0 Bytes, Format > 16BPP, 5:6:5, Big Endian, Interleaved und ok. Danke für den Tipp! Ich wusste gar nicht, dass beim Öffnen von *.raw ein Dialog erscheint. Passt alles - aber bei mir fehlt ein Auswahlfeld für "Big Endian" und entsprechend geht die Sache schief. Hast Du tatsächlich dieses Auswahlfeld? Welche Irfanview-Version hast Du? Evtl. muss ich ja noch ein Plugin installieren. Viele Grüße Igel1
Hallo, Andreas S. schrieb: > Welche Irfanview-Version hast Du? > > Evtl. muss ich ja noch ein Plugin installieren. bis eben die 4.44 64Bit, gerade auf die 4.52 64Bit update gemacht. PlugIn-Paket muß installiert sein und zur version passen. https://www.irfanview.com/ Der Haken ist noch da. Gruß aus Berlin Michael
Hallo Michael, in der Tat: es lag an der Irfanview-Version (obwohl die bestimmt noch gar nicht sooo alt war: 4.34**). Seit meinem Upgrade auf die neueste Version (ich habe die 32-bit Version installiert, um die TWAIN-Schnittstelle meines Druckers weiterhin nutzen zu können), ist auch der Haken für Big-Endian-Auswahl da. Der fehlte vorher noch. Ohne Deinen Hinweis hätte ich also stets gedacht, dass Irfanview mir nicht helfen kann. Danke also vielmals für den Tipp! Viele Grüße Igel1 PS: ** Schock im Nachgang: Revision-History von Irfanview sagt, dass Version 4.34 im Jahr 2012 n.Chr. rauskam - as time goes by ...
Hallo, Andreas S. schrieb: > PS: ** Schock im Nachgang: Revision-History von Irfanview sagt, dass > Version 4.34 im Jahr 2012 n.Chr. rauskam - as time goes by ... :-))) Irfanview ist eins der sehr wenigen Programme, wo ich ab- und zu freiwillig nach aktuellen Versionen schaue. Immernoch recht klein und handlich, kann verdammt viel dafür und hat mich noch nie im Stich gelassen. Gruß aus Berlin michael
Michael U. schrieb: > ist mir bisher nicht gelungen... FM6126A Schau mal, ob das passend ist: Beitrag "Chinesische IC und ihre Verwandschaft"
... mir fehlt David - schnief - hoffentlich ist bald Mittwoch ... Viele Grüße Igel1
Also: bin gerade dabei, Davids Schaltung nachzubauen ... Ja, ja - keine Ahnung, ist wohl ein Helfersyndrom gemäß: "Watt tu'se nich alles, um de Jong zu helfen?! Da ich AVR-mäßig allerdings ziemlich eingerostet bin, hier ein paar Fragen, bei denen Ihr bitte nicht zu hart mit dem Kopf auf der Tischkante aufschlagen möchtet: - Wie lade ich Davids Programm am einfachsten in den Nano? Reicht dafür das USB-Kabel, oder muss ich den AVR-Dragon (den ich bislang noch nie benutzt habe) anschließen? - Wenn ich den Dragon anschließen muss/soll, dann: wie? - Mit welchem Programm sollte ich David's Projekt kompilieren und auf den Nano flashen (optimalerweise mit Null Code-Anpassungen)? Vermutlich mit dem neuesten AVR-Studiomonster, stimmt's? Okay, ich gebe zu: ich bin etwas googlefaul, aber ich gebe zu: so richtig "heiß" bin ich auf diesen Retro-Ausflug in die 8-Bit-Welt nicht. Ich befürchte daher, dass ich etwas "Anschubmotivation" in Form von ein paar Antworten auf die Fragen oben von Euch benötige ... (gerne auch in Form von ein paar guten Links). Außerdem bedeutet es, dass ich 20 Kabel von meiner Kamera neu verdrahten muss (und später dann wieder Rolle rückwärts an den STM32 anstecken darf). Macht schon mal das Bundesverdienstkreuz für mich klar ... Viele Grüße Igel1
:
Bearbeitet durch User
Hallo, Andreas S. schrieb: > Also: bin gerade dabei, Davids Schaltung nachzubauen ... > > Ja, ja - keine Ahnung, ist wohl ein Helfersyndrom gemäß: > "Watt tu'se nich alles, um de Jong zu helfen?! warum denke ish sowas auch gerade?!?!? Andreas S. schrieb: > - Wie lade ich Davids Programm am einfachsten in den Nano? > Reicht dafür das USB-Kabel, oder muss ich den AVR-Dragon > (den ich bislang noch nie benutzt habe) anschließen? USb-nutzt Dir nur as für die serielle, ansonsten den "Drachen". > - Wenn ich den Dragon anschließen muss/soll, dann: wie? 6-pin Verbinder hinten quer auf dem Nano und auf dem Dragon auf ISP, Verbindung ist 1:1. Falls Du 6-Pin Quetschbuchsen hast und Flachbandkabel.... Andreas S. schrieb: > - Mit welchem Programm sollte ich David's Projekt kompilieren > und auf den Nano flashen (optimalerweise mit Null > Code-Anpassungen)? Vermutlich mit dem neuesten > AVR-Studiomonster, stimmt's? Wenn Du es relativ einfach haben willst, nimm das uralte AVR-Studio 4.18 https://www.microchip.com/mplab/avr-support/avr-and-sam-downloads-archive Bis fast ans Ende der Welt runter scrollen, ich glaube, Du brauchst alle 4 Files, das Studio und die SPs. Unter Win7 geht es völlig problemlos, unter 10 sollte es auch noch gehen. Dazu den antiken WinAVR: https://sourceforge.net/projects/winavr/files/WinAVR/20100110/ Den WinAVR bitte in seinen Wunschordner auf C:/ installieren... Ich glaube, wenn man WinAVR zuerst installiert, erkennt ihn AVR-Studio beim Installieren allein, das können wir aber noch klären. Geht eigentlich alles problemlos zu installieren mit den default-Angaben. Wenn Du dann das AVR-Studio startest une New Project öffnset, sieht gleich, ob er Dir außer AVR-Assemblaer auch AVR-GCC anbietet. Wenn Du bis dahin kommst sehen wir weiter..... Andreas S. schrieb: > Außerdem bedeutet es, dass ich 20 Kabel von meiner Kamera neu verdrahten > muss (und später dann wieder Rolle rückwärts an den STM32 anstecken > darf). Was sind schon 20 Dupont-Strippen??? Mehr als 19 haben doch gleichzeitig sowieso nie Kontakt. ;-) Das Studio sollte auch den Treiber für den Dragon mitinstallieren (Jungo-Treiber). Andreas S. schrieb: > Macht schon mal das Bundesverdienstkreuz für mich klar ... Geht auch ein Aktivisten-Orden? Der müßte hier noch irgendwo rumliegen... PS: AVR-Kram belegt kanpp 200MB, der WinAVR gut 150MB. Gruß aus Berlin Michael
:
Bearbeitet durch User
Hallo, so, Kurzfassung meines Standes mit Davids Sourcen: main.c, OV7670_with_Fifo.c und .h, SCCB_old.c und h sowie uart.c und h in ein AVR-Studio-Projekt geworfen. Dragon ausgebuddelt, rangesteckt und einen Arduino UNO zum Mega328 "degradiert", also Bootloader runter, Fuses angepasst. In OV7670_with_Fifo.h die Pins an meine Verteilung angepasst und in uart.h die Baudrate auf 230400 gesetzt. Meldet sich auch in seinem Terminal, zumindest manchmal/meistens. Dann beschlossen, das alles erstmal wegzulassen, zu seinem Terminal müßte ich mir erst einen seriellen Sniffer installieren, um sein Protokoll rauszufinden, also welches Kommando sendet was und wieviele Bytes in welchem Format (offenbar alles binär) und welche Antwort wird erwartet usw. Da ich seine UART-Routinen auch nicht auf Anhieb durchschaut habe, beschlossen, das alles vorerst zu ignorieren... uart.c umgebaut, TX-Interrupt aus, Senden im Busy-Loop. Seinen Bildersende Aufruf in die main7while(1) rein, Kommandoauswertung auskommentiert und nur endlos mit 30s Abstand Bild geholt und rausgeschickt. Andres S.: falls Du den alten AVR-Kram beutzt: _delay_ms() kann da noch keine langen Zeiten, also
1 | for (uint8_t i = 0; i < 20; i++) |
2 | { |
3 | _delay_ms(1000); |
4 | } |
benutzen für längere Wartezeiten. Ich hatte kurz überlegt, ob ich das aktuelle GCC-Paket installiere, aber keine Lust, da man da ein paar Sachen passend basteln muß... Zumindest kamen jetzt alle 20s meine 153600 Bytes an. height = 320 habe ich erstmal wieder gesetzt. Bildinhalt der Daten war irgendwas, aber reproduzierbar. Kurzerhand meine Init-Strukturen in seine main geworfen und die Kamera nach seinem OV7670_init(); mit meinen Registerwerten initialisiert. Das Ergebnis hängt oben dran. Darüber kann ich jetzt erstmal in Ruhe nachdenken, ich ahbe auch an ein paar Stellen in OV7670_with_Fifo.c noch was von ihm auskommentiert, das muß ich jetzt erstmal vergleichen bzw. rückgängig machen. Seine SCCB-Sachen laufen auf jeden Fall erstmal ohne Änderungen und Probleme, die OV7670_with_Fifo.c wohl auch. Mit seinen UART-Routinen bekomme ich irgendwie immer nur um die 15xxx Byte, warum auch immer. Warum mit meinen Init-Daten kein vernünftiges Bild rauskommt weiß ich auch noch nicht. Gruß aus Berlin Michael
Hallo! Ich bin zurück! freut mich, dass ihr am Ball geblieben seid und mir weiterhin helfen wollt! Heute Abend/Nachmittag habe ich wieder Zeit und werde mich in aller Ruhe mit euren Beiträgen auseinander setzten. @Igel wenn dir der Speicherplatz auf dem Rechner erstmal nicht allzu wichtig ist, würde ich dir einfach empfehlen das neuste Atmel stuido zu ziehen. Dann brauchst du dich um den Kram wie GCC etc. garnicht erst kümmern. Dann läuft auch der Dragon Plug'n'Play. Bis später! Mir juckts schon in den Fingerspitzen Gruß David
:
Bearbeitet durch User
Hi Leute, habe das neueste AVR-Studio installiert (mein schöner Plattenplatz - schnief ...). Heute Abend werde ich mich dann wohl erst einmal mit dem AVR-Dragon beschäftigen dürfen: habe ihn hier im Forum gebraucht gekauft und er kam nur mit einem 10-adrigen Stecker. Ich hoffe, ich kann diesen Stecker versetzt auf die Pfostenleisten an beiden Ende aufsetzen, ohne mir einen neues Kabel basteln zu müssen (denn dafür fehlt mir gerade das Zeugs). Hauptsache Michael löst nicht alle Probleme, bevor ich überhaupt das erste Byte auf meinen Nano geschoben habe ;-) Muss ich eigentlich vorab noch irgendetwas mit dem Nano veranstalten? (Bootloader platt machen? Fuses verbiegen? Beschwörungssprüche drüberhauchen?) Viele Grüße Igel1
ich kann dir heute abend ein foto von meinem schicken. nein, wenn du einfach vom studio aus flashest ist halt der Bootloader fürs erste Weg und du wirst die Arduino suit damit nicht mehr benutzten können, bis du wieder den Bootloader dafür falshest. An den Fuses musst du meines wissens nichts ändern. Nur in den Debug mode kannst du mim Nano nicht, weil du dich dann aussperrst. (Aber das wäre eben eine solche Fuse die man setzen müsste, also solange du da nichts machst kann eig. nichts passieren
Hallo, David D. schrieb: > Hallo! Ich bin zurück! freut mich, dass ihr am Ball geblieben seid und > mir weiterhin helfen wollt! Schö wieder von Dir zu hören. Andreas S. schrieb: > habe das neueste AVR-Studio installiert (mein schöner Plattenplatz - > schnief ...). Du hast es so gewollt... ;-)) Andreas S. schrieb: > Hauptsache Michael löst nicht alle Probleme, bevor ich überhaupt das > erste Byte auf meinen Nano geschoben habe ;-) Mit Sicherheit nicht, ich mache auch nur mal 'ne Stude oder so was, es sei denn, hier geht gerade die Post ab. Ich muß meinen Salat jetzt erstmal aufräumen, irgendwo habe ich bei meinem Sketch jetzt erstmal was durcheinander gebracht... Ich will jetzt erstmal Dvids Sourcen mit nur den nötigsten Änderungen, meinen Arduino-Sketch und die im AVR-Studio compilierte Version dazu überreden, mir alle 20s ein RGB565-Bild bzw. den Farbbalken zu schicken. 10-pol. sollte machbar sein wenn auf dem Dragon nicht alle Steckleisten bestückt sind, beim Nano ist ja nach beiden Seiten Platz. Zur Not sind es eben 6 Dupont-Strippen mehr..... Gruß aus Berlin Michael
Noch eine kleine Frage in die Runde: Wie versorgt Ihr Kamera und Level-Shifter mit Strom? Lese gerade, dass der Original-Nano nur 50mA Belastbarkeit an seinem 3,3V-Ausgangspin hat. Muss ich jenseits von USB noch eine Stromversorgung für das Steckbrett aufbauen? Viele Grüße Igel1
Hallo, so, kurzer Nachtrag: Ordnung soweit gemacht. Änderungen in Davids Source: - uart.c - eigene Senderoutine ohne Interrupt, keine Empafamgsroutine - main c - Kommandoauswertung auskommentiert, nur
1 | while (1) |
2 | { |
3 | OV7670_captureNewImage(); |
4 | OV7670_ResetFifoReadPointer(); |
5 | sendFrameBufferToUART (width, height, BytesPerPixel); |
6 | |
7 | for (uint8_t i = 0; i < 20; i++) //############## 20s warten |
8 | { |
9 | _delay_ms(1000); |
10 | } |
11 | } |
- main.c meine Register daten incl. Registersetzen eingefügt und nach seinem OV7670_init(); aufgerufen. So kommt alle 20s ein RGB565 Bild als RAW-Daten an. Seltsamerweise kommen seine Daten Little Endian an???? Erstmal reicht es mir. ;-) Bild ist auch "ok", ist aber zu dunkel in der Ecke für die Einstellungen. Gruß aus Berlin Michael
Hi Michael, vielen Dank für deine Mühen, das werde ich mir jetzt anschauen. Ich habe soeben die Lötarbeiten fertig gestellt und siehe da! ich bekomme zuverlässig die gleiche Colorbar, auch nach mehrmaligem auslesen. Deaktiviere ich diese bekomme ich aber kein Bild sondern kann höchstens die Lampe sehen, wenn ich sie direkt davor halte. Ist aber auch logisch, weil ich noch keine Settings reingeladen habe. Jetzt schaue ich mir mal an, was du Michael mit meinem Code veranstalltet hast und schaue auch mal, ob eure Registersettings von vor einigen Tagen/Wochen bei mir funktionieren ;-) Dieser miese Wackelkontakt hat echt zu unglaublichen Sachen geführt :D... @Igel ich habe so eine Spannungsversorgung fürs Steckbrett, die 3,3 und 5V kann. Und jetzt mit Entwicklershield eben auf dem Uno, der ja 5V hat. anbei ein Bild der Colorbar, meines neuen Testobjektes ;-) und dem Dragon für dich zur Veranschaung. Ich habe meinen in ein Gehäuse eingebaut und in meinem Unwissen alle Anschlüsse nach außen geführt, was im Nachhinein betrachtet nicht so clever war. Aber der ISP stecker ist blau markiert. Ist der 6er Stecker in der Mitte
David D. schrieb: > Dieser miese Wackelkontakt hat echt zu unglaublichen Sachen geführt Ich sage immer: Für über 90% aller Fehler in der Elektronik ist eine defekte Verbindung die Ursache.
Hallo, ok, das Problem mit der anderen byteorder hat sich für mich erstmal geklärt,
1 | for(int ByteNumber =0; ByteNumber < BytesPerPixel; ByteNumber++) |
2 | { |
3 | OV_RCK_PORT |= (1<<OV_RCK_PinNo); |
4 | |
5 | UART0_senden_Byte(Ov7670_readByte()); |
6 | |
7 | OV_RCK_PORT &= ~(1<<OV_RCK_PinNo); |
8 | } |
Du setzt RCK auf H und liest dann die Daten. TOH ist aber nur wenige ns, min. 4ns. Da der Fifo sehr schnell ist, liest Du sehr wahrscheinlich nicht das gewünschte, sondern schon das nächste Byte.
1 | for(int ByteNumber =0; ByteNumber < BytesPerPixel; ByteNumber++) |
2 | { |
3 | OV_RCK_PORT &= ~(1<<OV_RCK_PinNo); |
4 | |
5 | UART0_senden_Byte(Ov7670_readByte()); |
6 | |
7 | OV_RCK_PORT |= (1<<OV_RCK_PinNo); |
8 | } |
macht es bei mir richtig rum. Da sind Timingprobleme zwischen Fifo und und dem "lahmen" AVR wohl schuld. Ich habe jetzt keine Lust, den LA ranzuhängen und zu schauen, wann der Datenwechsel im Verhältnis zur RCK Flanke passiert, außerdem sind da die 80MHz Samplerate meines LA sowieso zu langsam... Gruß aus Berlin Michael
Das ist jetzt interessant. Wenn ich jetzt meine routine so änder wie von dir vorgeschlagen, erhalte ich die Colorbar, die du vorher hattest :D
Hallo, David D. schrieb: > Wenn ich jetzt meine routine so änder wie von dir vorgeschlagen, erhalte > ich die Colorbar, die du vorher hattest :D Und wenn Du mir jetzt noch sagst, welche ich vorher hatte... ;-) Die aus dem Post von Datum: 20.02.2019 17:30 ist die richtige. weiß-gelb-cyan-grün-magenta-rot-blau-schwarz ist richtig, der Standard-Farbbalken. Gruß aus Berlin Michael
Hi Leute, ich hab's geahnt: Michael hat alle Probleme gefixed, bevor ich das erste Byte auf mein Arduino-Nano Board geschoben habe ... Nach ein paar Anlaufschwierigkeiten mit dem ISP-Kabel, hat das Flashen gerade erstmals funktioniert - hurra. Natürlich erst kurz nachdem Michael den Timing-Bug gefunden hat - so'n Mist, den hätte ich auch gern gefunden ... Bevor ich jetzt die Kamera dranklemme, möchtet Ihr beide mir bitte nochmals genauer beschreiben, wie Ihr das Board mit Strom versorgt (sowohl Michael als auch David). Wie versorgt Ihr den Nano, die Level-Shifter (beide Seiten: 3,3V und 5V interessieren mich) und wie die Kamera? Benutzt Ihr dafür etwa so eine Steckbrett-Versorgung wie unten rechts im Bild dargestellt? Viele Grüße Igel1
Hallo Igel! Freut mich riesig, dass du diese Bürde auf dich genommen hast. Ich kann dich beruhigen. Es ist noch lange nicht alles gefixed. Ich habe mir jetzt mal auf die beiläufige Erwähnung von Michael, dass es com swiffer gibt, so ein Tool geladen und sehe, dass es nicht ganz meinen Erwartungen entspricht, bzw. Der uC aus irgendwelchen Gründen nicht weiter macht. Zur Stromversorgung. (Ich kopiere einfach nochmal von oben ;-) ) "@Igel ich habe so eine Spannungsversorgung fürs Steckbrett, die 3,3 und 5V kann. Und jetzt mit Entwicklershield eben auf dem Uno, der ja 5V hat." Also zuvor auf meinem steckbrett habe ich die steckbrettversorgung mit ext. Netzteil genutzt und jetzt betreibe ich den uno nur noch per USB und greife von dort die 3,3 und 5v ab
David D. schrieb: > Hallo Igel! > Freut mich riesig, dass du diese Bürde auf dich genommen hast. Ich kann > dich beruhigen. Es ist noch lange nicht alles gefixed. Nu freu Dich mal nicht zu früh: ich kann am kommenden Wochenende nicht mitmachen und Michael schickt sich gerade an, keinen Bug mehr für mich übrig zu lassen. > Zur Stromversorgung. (Ich kopiere einfach nochmal von oben ;-) ) Das hatte ich durchaus gelesen, aber eben nicht richtig verstanden. > "@Igel ich habe so eine Spannungsversorgung fürs Steckbrett, die 3,3 und > 5V kann. Und jetzt mit Entwicklershield eben auf dem Uno, der ja 5V > hat." Nun habe ich es zum 2. Mal nicht richtig verstanden ... > Also zuvor auf meinem steckbrett habe ich die steckbrettversorgung mit > ext. Netzteil genutzt und jetzt betreibe ich den uno nur noch per USB > und greife von dort die 3,3 und 5v ab Vielleicht stehe ich etwas auf der Leitung daher nochmals konkret gefragt: - Meinst Du mit "Steckbrettversorgung" so etwas wie rechts unten auf meinem Bild aus meinem letzten Posting? - Wirft Dein Entwicklershield (welches hast Du?) 3,3V und 5,0V raus? - Den 3,3V-Ausgang des Uno-Boards hast Du nicht genutzt, oder? (... denn der kann ja nur 50mA liefern) Viele Grüße Igel1
:
Bearbeitet durch User
Hallo, Andreas S. schrieb: > - Den 3,3V-Ausgang des Uno-Boards hast Du nicht genutzt, oder? > (... denn der kann ja nur 50mA liefern) die 3,3V vom Nano reichen für die Kamera eigentlich aus, auch mit em FiFo. Der AMS1117 auf dem Nano kann weit mehr, es wird ihm aber dann zu warm wegen der geringen Kühlfläche. Vusb geht über eine Schottkydiode an den Reglereingang, an üblichen USB-Ports sieht der also meist nur um 4,7V. Kannst Du ja am 5V Pin des Nano messen, was da bei USB wirklich anliegt. Pegelwandler 5V vom 5V Nano-Pin, 3,3V und Kamera am 3,3V Pin. Pegelwandler habe ich in den zur Kamera gehenden Leitungen, also SDA, SCK, RST, also was direkt zur OV7670 geht. Der Fifo hat sowieso 5V tolerante Eingänge. Der UNo hat meist einen LP2985-33 drauf, der kann auch max. 150mA, kann aber eben auch thermische Probleme bekommen. Bei gehen beise Varainten ohne erkennbare Probleme, Spannung eben normal vom USB-Port. Ich habe mich gestern Abend irgendwie an "Processing" erinnert. Das ist eine Java-Geschichte im Arduino-Stile und habe es mal angeworfen. Hmmmmm, wenn ich da durch die Funktionen usw. etwas durchgestiegen bin, habe ich da vermutlich in kruzer Zeit eine "Software", die die RAW-Daten vom Mega einliest und als Bild in ein Fenster pinselt. Kann man einfach irgendwo hinwerfen und die .exe starten, 260MB tragen auch nicht so auf. :) Ich werden an der OV7670 Software ohnehin jetzt nur was machen, wenn David "um Hilfe" schreit. Ich kann bei Bedarf auch meine geänderte main.c und uart.c auch hier mal reinhängen. Genauso auch meine Software, ist in einem kompletten .c File, läßt sich also auch problemlos in ein Studio-Projekt werfen. Gruß aus Berlin Michael
:
Bearbeitet durch User
@Michael: Danke für die Mühen, die Du Dir da mit Deiner ausführlichen Email zum Thema Stromversorgung gemacht hast! Dann also Augen zu und durch: ich werde den Nano per USB-Kabel direkt vom Rechner aus versorgen und schließe alles andere an die Pins 5V und 3,3V des Nano an. Sollte das schief gehen, so habe ich noch einen Ersatz-Nano hier in der Tüte gefunden. Ihr werdet mich also so schnell vermutlich nicht los ... Viele Grüße Igel1
Hallo, Andreas S. schrieb: > Sollte das schief gehen, so habe ich noch einen Ersatz-Nano hier in der > Tüte gefunden. Ihr werdet mich also so schnell vermutlich nicht los ... kannst ja einfach mal den Finger auf den Spannungsregler des Nano legen, wäre das einzige kritische Bauteil bei der Geschichte. PS: meine ESP32-Espessif jungs waren auch fleißig. Endlich mal das aktuelle CamWebserver angepast und auf mein Cam-Modul geflasht. Da muß ich mal mit rumspielen und schauen, was die da jetzt alles in die Lib für die Kameramodule gepackt haben. Bild vom Webinterface mit Einzelbild in voller Auflösung in bekannter ziemlich schlechter Beleuchtung. Gruß aus Berlin Michael
Michael U. schrieb: > PS: meine ESP32-Espessif jungs waren auch fleißig. Endlich mal das > aktuelle CamWebserver angepast und auf mein Cam-Modul geflasht. Meinst Du das "Cam-Modul": siehe Anhang ? Das habe ich mir wegen Deiner positiven Bewertung in einem anderer Thread ebenfalls gekauft. VG Igel1
By the way: habe den ganzen Schmodder inzwischen verdrahtet: 2h Wurschteln. Ist ein fliegender, recht wackeliger Verhau geworden. Bin dabei blind vertrauend nach David Schaltplan vorgegangen (nur OE habe ich fix auf GND gelegt). @Michael: Ich würde nun zum Testen sehr gerne Deine Modifikationen von Davids Programm haben. Dann weiß ich zumindest, dass mein Drahtverhau passt, wenn ein Colorbar-Bild hinten rauskommt. Bitte nur diejenigen Dateien hier einstellen, die sich von Davids Programm unterscheiden - dann würde ich diese Dateien schnell mal temporär tauschen und so die Schaltung testen. Bleibt noch eine dumme Frage (bin zu müde, das nachzuprüfen - seht's mir nach): Die Daten kommen seriell über die USB-Schnittstelle via virtuellem seriellem Port raus, stimmt's? Oder muss ich noch einen USB->RS232-Wandler irgendwo drankleben? Viele Grüße Igel1
:
Bearbeitet durch User
Hallo, Andreas S. schrieb: > Meinst Du das "Cam-Modul": siehe Anhang ? ja, genau dieses. Da ist mir gestern noch was seltsames aufgefallen, was das Kamera-Modul selbst betrifft. Das muß ich mir aber erst genauer anschauen. Andreas S. schrieb: > Bitte nur diejenigen Dateien hier einstellen, die sich von Davids > Programm unterscheiden - dann würde ich diese Dateien schnell mal > temporär tauschen und so die Schaltung testen. Wenn ich beim letzten Sortieren kenen Mist gebaut habe, passt es so. Ich habe meine Eingriffe mit Kommentaren verziert, die mit //######### beginnen. UART steht auf 23400, alle 20s kommt ein RGB565 Bild. Die Daten kommen seriell über die USB-Schnittstelle via virtuellem seriellem Port raus, stimmt's? Oder muss ich noch einen USB->RS232-Wandler irgendwo drankleben? Kommen über USB, sollte beim Anstecken des Nano eine COM auftauchen wenn Du den Treiber drauf hast, meine Nano haben alle einen CH430 drauf. Lassen wir uns mal überraschen. Gruß aus Berlin Michael
@Michael: Danke für die Starthilfe! Damit konnte ich direkt den Funktionstest machen, der das Bild im Anhang ergab (allerdings Little Endian). Fazit: kein Verkabelungsfehler (puhhh) - nicht zuletzt Dank David's sauberem Schaltplan. Viele Grüße Igel1
Hallo, Andreas S. schrieb: > Damit konnte ich direkt den Funktionstest machen, der das Bild im Anhang > ergab (allerdings Little Endian). schön. Wieder ein Spielzeug mehr. ;) Byteorder: mein Post vom Datum: 20.02.2019 21:04 PS. heute die 64x64 LED-Matrix von der Post geholt, siehe oben der Uhr-Kram... Gruß aus Berlin Michael
GUten Abend... endlich Feierabend, endlich Wochenende nach einer turbolenten Woche. Gleich nur noch der Tanzkurs zu dem ich genötigt werde und dann habe ich auch schon wieder die halbe Nacht und den Sonntag zeit, um mich meinem Lieblingsthema zu widmen. Juhu! Dann mische ich wieder mit :) Freut mich, dass wir alle wieder auf Hardware laufen und Michael ein Spielzeug für die Zwischenzeit gefunden hat :D Bis später!
Hier eine Kleinigkeit: Ich schaue mir gerade Davids Routine "UART0_init (void)" an. Dabei fällt mir auf, dass dort 2 Stoppbits konfiguriert werden. Ist sicherlich kein Beinbruch, aber ich vermute eher, dass eigentlich 8N1 konfiguriert werden sollte. Etwas kritischer ist das hier: Außerdem würde ich erst einmal "klein anfangen": also max. 115200 baud einstellen - da weiss man, dass die Abweichung von Soll-Baudrate und Ist-Baudrate mit 2,1% noch halbwegs "legal" ist (vgl. S.199 hier: http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf) und es zu keinen Fehlern kommen sollte. Alles darüber ist Glückssache (so jedenfalls mein Verständnis). Und ganz kritisch sehe ich das hier: Dann sehe ich den UART-Empfänger-Interrupt aktiviert. Ohne dass ich bisher weiteren Code gesichtet hätte (... gleich ist erst einmal Familie dran ...) halte ich das bei den dort eingestellten 2 Mbaud für sehr gewagt: bei 16MHz Takt hätte die ISR ganze 8 Takte Zeit, um das empfangene Bit zu verarbeiten (inklusive Ein- und Rücksprung!). Meiner Meinung nach kann das nicht funktionieren. Soweit erst einmal meine 10 Cent zum Thema "UART0_init (void)". Viele Grüße Igel1 PS: ich weiss, dass Michael auch schon etwas dazu geschrieben hatte, bin aber zu bequem, das alles nochmals rauszusuchen - meine Anmerkungen können daher doppelt-gemoppelt sein.
Hallo, Andreas S. schrieb: > Ich schaue mir gerade Davids Routine "UART0_init (void)" an. > Dabei fällt mir auf, dass dort 2 Stoppbits konfiguriert werden. > Ist sicherlich kein Beinbruch, aber ich vermute eher, dass eigentlich > 8N1 konfiguriert werden sollte. ist in diesem Fall egal bzw. sogar von Vorteil. Mir ist kein real existierender RS232-RX bekannt, der wirklich noch auf 2 Stoppbits auswertet selbst wenn man 8N2 einstellt.das müßte dann auf Empfängerseite einen Frame-Error erzeugen, ist mir aber noch nicht untergekommen. Wenn der Empfänger auf 8N1 steht und man 8N2 sendet schindet man eine Bitzeit Zeit raus, um sicher auf das nächste Startbit reagieren zu können. War aber nur ganz früher (tm) wichtig, weil da nur einmal mit dem Lesetakt der Zustand eingelesen wurde und es eben stimmen mußte. Ich hatte es gesehen und deshalb ignoriert. Ansonsten habe ich seinen UART-Kram bisher einen riesen Bogen gemacht. ;-) Gruß aus Berlin Michael
Hallo, OT: damit es nicht langweilig wird: ESP32 mit OV2640 vom neuen LED-Display 64x64 in 1600x1200. Gruß aus Berlin Michael
... David scheint einen Tanzunfall gehabt zu haben - man hört gar nichts mehr von ihm ...
Andreas S. schrieb: > Dabei fällt mir auf, dass dort 2 Stoppbits konfiguriert werden. > Ist sicherlich kein Beinbruch, aber ich vermute eher, dass eigentlich > 8N1 konfiguriert werden sollte. Öhm naja mit 8n1 oder 8N2 "Standards" muss ich gestehen, kenne ich mich nicht aus. diese UART Routine habe ich ganz am Anfang meiner uC-Karriere mal ans laufen gebracht und nehme sie immer wieder her. Also sollte man eher nur 1 Stopp-Bit verwenden? > Etwas kritischer ist das hier: > > Außerdem würde ich erst einmal "klein anfangen": also max. 115200 baud > einstellen - da weiss man, dass die Abweichung von Soll-Baudrate und > Ist-Baudrate mit 2,1% noch halbwegs "legal" ist (vgl. S.199 hier: > http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf) Ja, können wir machen, hatte sie nur damals hochgedreht, da ich vermutete, dass das rauschen von einem unzureichend refreshtem FIFO kam. War ja nicht der Fall. Allerdings habe ich noch keine anderen Verhaltensweisen mit dem 2MBaud festgestellt, das Verhalten ist genauso wie vorher. > Und ganz kritisch sehe ich das hier: > > Dann sehe ich den UART-Empfänger-Interrupt aktiviert. > Ohne dass ich bisher weiteren Code gesichtet hätte (... gleich ist erst > einmal Familie dran ...) halte ich das bei den dort eingestellten 2 > Mbaud für sehr gewagt: bei 16MHz Takt hätte die ISR ganze 8 Takte Zeit, > um das empfangene Bit zu verarbeiten (inklusive Ein- und Rücksprung!). > Meiner Meinung nach kann das nicht funktionieren. Jap, verstanden. Allerdings scheint es aktuell zu funktionieren. Kann aber auch daran liegen, dass ich mit dem Atmega nur relativ Wenige Bytes (ich glaube maximal 3) hintereinander empfange. Das scheint er offensichtlich noch hin zu bekommen. > Soweit erst einmal meine 10 Cent zum Thema "UART0_init (void)". Das finde ich gut, weil ich denke, dass das Problem irgendwo in der UART routine liegt. Und ich aktuell davon ausgehe, dass es an einem nicht beachtetem Empfangenen Kommando auf dem uC liegt. Solange das Terminal nicht zuverlässig "Serien" schreiben oder Lesen kann, macht muss/müssen ich/wir zunächst das in den Griff bekommen. Michael schrieb: >Ansonsten habe ich seinen UART-Kram bisher einen riesen Bogen gemacht. >;-) Schade :D da liegt denke ich der Fehler, der Rest scheint "relativ" gut/schlecht zu funktionieren. Ich würde auch gerne auf deinen Vorschlag von vor ein paar posts eingehen und die UART routinen umbauen, wenn das zum Erfolg führen kann. Andreas schrieb: >... David scheint einen Tanzunfall gehabt zu haben - man hört gar nichts >mehr von ihm ... Nicht ganz, ich bin nur gestern einfach tot ins Bett gefallen und war zu garnichts mehr in der Lage. Heute dann Skifahren aber jetzt wieder daheim und schon wieder mitten drin :)
Hallo, David D. schrieb: > Ich würde auch gerne auf deinen Vorschlag von vor ein paar posts > eingehen und die UART routinen umbauen, wenn das zum Erfolg führen kann. mal schauen, wie meine Meinung morgen ist. Wenn das Display am Wemos-ESP32-Modul sich meldet, habe ich durchuas Lust. ;) Im Moment geht es mir wie Dir: ich habe die Verbindungen jetzt 3x kontrolliert, jedesmal einen Fehler entdeckt und behoben und stehe trotzdem noch "im Dunkeln". Also vorhin entnervt in die Ecke gelegt..... Ich hatte irgendwo hier auch schon eine Empfangsroutine reingebaut, mit einfachem Buffer und RX-IRQ. Lief prinzipiell auch, da ich aber erst hätte schauen müssen, was Dein Terminal beim Druck auf welchen Button eigentlich sendet, habe ich am anderen Ende angefangen. ok, habe gerade mal einen Seriellen Portmonitor installiert, ist zwar eine Demo und läuft nur 14 Tage, aber sie macht erstmal, was sie soll. Also morgen mal schauen... Gruß aus Berlin Michael
Welche Software hast du da ausgewählt? Ich nehme mir gerade die Warnings vor ;-) Gruß David
Hallo, David D. schrieb: > Welche Software hast du da ausgewählt? Die erstbeste, die mir in die Hände viel: https://www.eltima.com/de/products/serial-port-monitor/ > Ich nehme mir gerade die Warnings vor ;-) BNaja, die meisten sind ja nur warnings wegen den Zuweisungen in if-Anweisungen. Ein Klammerpaar drumrum und der Compiler erkennt die Absicht und vermutet keinen Tippfehler = <> == Gruß aus Berlin Michael
Hi Leutis, habe gerade einmal Davids Code genommen und statt main.c und uart.c komplett durch Michaels Code zu ersetzen, habe ich nur main.c durch Michaels Code ersetzt. Damit wird alle 20s die Routine "sendFrameBufferToUART (width, height, BytesPerPixel);" aufgerufen. Außerdem ist sichergestellt, dass die Kamera-Parameter auch wirklich ein Colorbar-Testbild erzeugen. Fazit: der Nano sendet anschließend keinen Pieps mehr über Seriell - schade aber auch, denn die Uart-Routinen mit dem Ringbuffer sehen auf den ersten Blick sehr elegant aus. @David: bist Du von allein auf solche Konstrukte hier gekommen? :
1 | volatile struct UART0_tx //Transmit Buffer |
2 | { |
3 | volatile char data[UART0_tx_size]; |
4 | char read; |
5 | char write; |
6 | }UART0_tx= {{}, 0, 0}; |
7 | |
8 | |
9 | int UART0_tx_in (char input) |
10 | { |
11 | char next= ((UART0_tx.write+1)&UART0_tx_mask); |
12 | if (next==UART0_tx.read) |
13 | { |
14 | return 0; |
15 | } |
16 | UART0_tx.data[UART0_tx.write] = input; |
17 | UART0_tx.write =next; |
18 | return 1; |
19 | } |
Für einen Programmieranfänger fände ich das mehr als bemerkenswert: Ringbuffer mit sehr raffinierter, handcodierter Modulo-Berechnung. Meine ersten Versuche sahen da deutlich schlichter aus. Jetzt muss ich nur noch den Fehler finden, warum das Dingen so gar keinen Mucks von sich gibt. Nur leider ist Basteltime für heute schon wieder over. Viele Grüße Igel1
Hi, Ich bin leider auch schon wieder im Land unterwegs, also bei dem Standard uart fürnktionen habe ich mich hier auf der Website bei den avr "beispielen" bedient :D das hätte ich am Anfang niemals so hinbekommen. Das war ca. 2014 in meinem ersten uni Projekt. Also bei mir läuft es mit meinem Terminal auch mehrmals hintereinander. Aber ich würde gefühlsmäßig nicht beim Bild anfangen sondern bei mehreren Registern lesen oder schreiben. Also es liegt nicht an den Buffern habe breakpoints bei beiden fifo fiel Routinen gesetzt. Und die lösen nicht aus, wenn die Übertragung abbricht. ... Hmm ich bin was ratlos Grüße aus aktuell Regensburg
David D. schrieb: > Hi, > Ich bin leider auch schon wieder im Land unterwegs, Du meine Güte - bist Du Vertreter (neudeutsch: Vertriebler?) Die machen echt "Landverschickung" mit Dir. > also bei dem > Standard uart fürnktionen habe ich mich hier auf der Website bei den > avr "beispielen" bedient :D das hätte ich am Anfang niemals so > hinbekommen. Das war ca. 2014 in meinem ersten uni Projekt. Ah - der Mann hat doch stuckadiert. > Also bei mir läuft es mit meinem Terminal auch mehrmals hintereinander. Was genau? > Aber ich würde gefühlsmäßig nicht beim Bild anfangen sondern bei > mehreren Registern lesen oder schreiben. Passt schon - Bildausgabe ist schon okay. > Also es liegt nicht an den Buffern habe breakpoints bei beiden fifo fiel > Routinen gesetzt. Was meinst Du mit "fifo fiel Routinen"? > Und die lösen nicht aus, wenn die Übertragung > abbricht. > ... > Hmm ich bin was ratlos Das werden wir schon gemeinsam schaukeln. Inzwischen fiel mir auch ein, warum Dein Code nix sagt, wenn ich Deine "main.c" durch Michaels "main.c" ersetze: vermutlich hatte Michael den Interrupt deaktiviert... Und so war's denn auch - ich hätte einfach nur genauer hinschauen müssen. Habe ab Do ein paar Tage frei, dann kann ich mich etwas mehr eindenken - braucht halt doch Ruhe und Muße, so eine Fehleranalyse. Hoffentlich läßt mir Michael den oder die Fehler übrig - jetzt wo ich alles mühevoll zusammengestöpselt habe. By the way: warum nutzt Ihr Eure Logic-Analyser nicht zur Analyse des seriellen Protokolls und hantiert statt dessen mit Software herum? Mein Intronix LogicPort kann UART im Schlaf decodieren. > Grüße aus aktuell Regensburg Grüße aus - Du weißt schon wo Igel1
:
Bearbeitet durch User
Hi David, schau mal das Bild im Anhang ... Du wirst es nicht glauben: es stammt aus Deinem Programm - mit minimalen Anpassungen: Ich habe - wie oben geschrieben - Deine "main.c" durch Michaels "main.c" ersetzt. Einziger Grund: ich wollte die Menüauswahl rauswerfen, um mich so auf die Routine "sendFrameBufferToUART (width, height, BytesPerPixel);" konzentrieren zu können. Diese Routine habe ich dann wie folgt angepasst:
1 | void sendFrameBufferToUART (int ImageWidth, int ImageHeight, int BytesPerPixel) |
2 | { |
3 | OV7670_ResetFifoReadPointer(); |
4 | |
5 | for(int height = 0; height < ImageHeight;height++) |
6 | { |
7 | for(int width =0; width < ImageWidth; width++) |
8 | { |
9 | for(int ByteNumber =0; ByteNumber < BytesPerPixel; ByteNumber++) |
10 | { |
11 | |
12 | OV_RCK_PORT &= ~(1<<OV_RCK_PinNo); |
13 | UART0_senden_Byte(Ov7670_readByte()); |
14 | _delay_us(300); |
15 | OV_RCK_PORT |= (1<<OV_RCK_PinNo); |
16 | |
17 | |
18 | } |
19 | } |
20 | } |
21 | } |
Begründung: Flankenwechsel für RCK habe ich vertauscht, damit Du das erste Byte nicht verschlumpfst, denn wenn Du die Flanke von RCK von LOW nach HIGH gehen lässt und dann erst das Byte aus dem AL422B-FIFO liest, so landest Du schon beim zweiten Byte (Michael war das aufgefallen - diese Blumen gehen an ihn). Sodann folgt das eigentliche Problem, das seinen Ursprung beim Aufruf von "UART0_senden_Byte(Ov7670_readByte())" hat. Bei der Sichtung dieser Routine fiel mir auf: sie ruft die Unterroutine "UART0_tx_in(Byte)" auf und in dieser Unterroutine wiederum wird ein internen Puffer UART0_tx.data[] gefüllt. Das geht so:
1 | int UART0_tx_in (char input) |
2 | { |
3 | char next= ((UART0_tx.write+1)&UART0_tx_mask); |
4 | if (next==UART0_tx.read) |
5 | { |
6 | return 0; |
7 | } |
8 | UART0_tx.data[UART0_tx.write] = input; |
9 | UART0_tx.write =next; |
10 | return 1; |
11 | } |
Dieser Puffer wird dann anderweitig auch schön brav von der ISR-Routine gemäß Prinzip first-in-first-out ausgelesen und per UART auf die Leitung geschoben. Der Knackpunkt: die Einleseroutine wartet nicht und schreibt immer weiter in den Puffer - solange, bis der Schreibzähler des Ringbuffers den Lesezähler quasi von hinten eingeholt hat. Spätestens dann sollte der Auslesevorgang aus dem AL422B eigentlich stoppen, denn der Ringbuffer ist ja voll. Tut er aber nicht: statt dessen wird in obiger Routine ein "return 0" aufgerufen, was von der aufrufenden Routine "void UART0_senden_Byte(char Byte)" leider nicht als "Hilferuf" a la "ich bin voll, bitte nix mehr reinstopfen" beachtet wird. Statt dessen kehrt diese zurück zur eingangs gelisteten 3-fachen for-Schleife, die ein weiteres Byte aus dem AL422B-FiFo ausliest und wiederum per Aufruf von "UART0_senden_Byte(char Byte) -> UART0_tx_in(Byte)" versucht in den Ringbuffer zu stopfen. Genau hier nimmt das Unglück seinen Lauf, denn das Byte wird nicht mehr in den Ringbuffer geschrieben, weil die Routine "UART0_tx_in (char input)" per "return 0" verlassen wird. Die Folge: das Byte geht verloren. Das ist übrigens auch der Grund dafür, warum dann später reproduzierbar zu wenig Bytes über die serielle Leitung rausgeschrieben werden - der fehlende Rest ist "per return 0" im Nirvana gelandet. Verschafft man der ISR allerdings genügend Zeit, den Ringbuffer auszulesen und über die serielle Leitung zu schicken, so tritt kein Überlauf des Ringbuffers ein und alles ist gut. Das habe ich einfach durch Einfügen von "_delay_us(300);" im ganz oben zitierten Codeblock getan. Alternativ kann man auch auch Warteschleifen innerhalb der Routine "void UART0_senden_Byte(char Byte)" fliegen - nämlich immer dann, wenn "UART0_tx_in(Byte);" ein "return 0" zurückgibt. Das sieht dann so aus:
1 | void UART0_senden_Byte(char Byte) |
2 | { |
3 | while(!(UART0_tx_in(Byte))){} |
4 | UCSR0B |= 0b00100000; // Data Register empty Interrupt anschalten |
5 | } |
Das geht natürlich nur beim Betrieb mit AL422B FiFo. Ohne FiFo fliegen einem gnadenlos aus dem OV7670 die Bits weiter um die Ohren und man kann kein Warteschleifchen fliegen. Ach ja: ich habe für meine Experimente die Baudrate auf 115200 Baud gedrosselt, indem ich in UART.c das Register UBRR0L auf den Wert 16 gesetzt habe.
1 | UBRR0L = 0b00010000; //115200 |
Viele Grüße Igel1 PS: und Danke an Michael, dass er mir auch einen Fehler übriggelassen hat - er hatte obiges Problem sicherlich schon längst bemerkt und durchschaut und hat sich nur aus Edelmut zurückgehalten (ich meine sogar, er hatte in diesem Thread die Gefahr des Pufferüberlaufs schon einmal erwähnt).
:
Bearbeitet durch User
Hier noch schnell die veränderten Dateien. 1:40 Uhr - au weia - das wird ein harter Tag morgen ... Gute Nacht Igel1
Guten Morgen, Define Lösung Mit der while schleife gefällt mir gut! Leider -und ich traue es mich fast garnicht zu sagen- war oder ist mir das von dir erläuterte Problem bewusst und ich habe das auch immer berücksichtigt. Ich habe mit immer über die baudrate ausgerechnet, wie lange ich für die Übertragung brauche und dementsprechend ein delay reingesetzt. Bei 2MBaud vielen die delays dann ganz raus. Aber in eurer Version müssten noch die Kommentare drin sein. Das erklärt jetzt auch warum bei euch die Bilder nicht "ganz" ankommen. Das konnte ich nicht nachvollziehen... da hätte ich vielleicht den von dir gefundenen Kniff erwähnen sollen (sorry). Aber nur weiter so! :D Jetzt weiß ich auch warum du beim Bild anfangen wolltest, wenn dass noch garnicht lief. Was ich gestern schreiben wollte war, dass ich genau an diesen Stellen, wo die Funktionen um den Buffer zu füllen 0 zurückgeben, weil der Buffer voll ist, brake points gesetzt habe. Und bei mir löst der dort nicht aus. Grüße, David
Hallo, kommt ja etwas Leben in die Bude. ;) Andreas S. schrieb: > Ich habe - wie oben geschrieben - Deine "main.c" durch Michaels "main.c" > ersetzt. Einziger Grund: ich wollte die Menüauswahl rauswerfen, um mich > so auf die Routine "sendFrameBufferToUART (width, height, > BytesPerPixel);" konzentrieren zu können. Genau das war mein Grund auch, ich wollte erstmal was sehen und halbwegs sicher sein, daß SCCB und die OV7670 Routinen von ihm laufen und das machen sie ja auch. Andreas S. schrieb: > Flankenwechsel für RCK habe ich vertauscht, damit Du das erste Byte > nicht verschlumpfst, denn wenn Du die Flanke von RCK von LOW nach HIGH > gehen lässt und dann erst das Byte aus dem AL422B-FIFO liest, so landest > Du schon beim zweiten Byte (Michael war das aufgefallen - diese Blumen > gehen an ihn). Danke für die Blumen, ich wollte nur wegen dieser Änderung die OV7670_with_Fifo.c nicht auch noch mitschicken, hätte nur verwirrt. Andreas S. schrieb: > PS: und Danke an Michael, dass er mir auch einen Fehler übriggelassen > hat - er hatte obiges Problem sicherlich schon längst bemerkt und > durchschaut und hat sich nur aus Edelmut zurückgehalten (ich meine > sogar, er hatte in diesem Thread die Gefahr des Pufferüberlaufs schon > einmal erwähnt). Vermutet ja, aber eben einfach komplett bei mir ausgeklammert. Edelmut ist das weniger, ich habe ja auch noch meine Spielereien hier rumliegen und manchmal hae ich selbst als Rentner noch ein paar andere Dinge vor... Ich werden Deine UART-Änderungen mal reinhängen und schauen, was passiert. Irgendwann nachher, später oder so. Andreas S. schrieb: > By the way: warum nutzt Ihr Eure Logic-Analyser nicht zur Analyse des > seriellen Protokolls und hantiert statt dessen mit Software herum? > Mein Intronix LogicPort kann UART im Schlaf decodieren. Mein Eigenbau LA hat die Routinen dafür nie bekommen. Dazu kommt ein Umstand aus alter Zeit: meine ersten Diskussionen mit UART und USART sind lange her und da war LA noch Fremdwort. Also mußte ich mir meine Machwerke meist sehr lange und genau überlegen.Ich finde Softwarefehler auch heute noch meist durch schrittweises gedankliches Durchspielen, was der µC da macht oder/und durch Brüten über Datenblattpassagen und Timingdiagramme. Auch ein Grund, weshalb ich z.B. bei den ESP, speziell dem ESP32, da ungern selbst tief einsteige. Das Zusammenspiel der Hardwarekomponenten, dem RTOS und der IO-Matrix ist eine andere Größenordnung als auf einem Mega328 rumzuspielen, wo man die Registerbits noch beim Vornamen kennen kann. David D. schrieb: > Leider -und ich traue es mich fast garnicht zu sagen- war oder ist mir > das von dir erläuterte Problem bewusst und ich habe das auch immer > berücksichtigt. Ich habe mit immer über die baudrate ausgerechnet, wie > lange ich für die Übertragung brauche und dementsprechend ein delay > reingesetzt. Bei 2MBaud vielen die delays dann ganz raus. Aber in eurer > Version müssten noch die Kommentare drin sein. Naja, wäre für mich zumindest generell eine unschöne Lösung, notfalls kämen da eben einige #ifdef für die Baudrate rein, um das zur Compilezeit anzupassen. Ich bin der Geschichte, daß meine UNOs über 230400 Misz bauen, auch nur am Rande auf den Grund geganen: es sieht so aus, als ob der Mega16U2 als USB-Wandler Mist baut, wenn mehr Daten als sein UART-Buffer kommen und er zwischendurch das USB-Paket rausschickt. Mit kleinen Datenmegen gehen alle Baudraten stabil. Ein CH340 hat das Problem eben nicht. Ich müßte also beim Senden des Bildes noch Wartezeiten im passenden Blockabstand einfügen, macht aber letztlich keinen Sinn, dann kann ich auch bei 230kBaud bleiben... Gruß aus Berlin Michael
David D. schrieb: > Guten Morgen, > > Define Lösung Mit der while schleife gefällt mir gut! Danke. Warten in while-Schleifen gehört zu meiner Spezialität:
1 | while(I am working all day long and way to much) |
2 | { |
3 | live passes by; |
4 | } |
> Leider -und ich traue es mich fast garnicht zu sagen- war oder ist mir > das von dir erläuterte Problem bewusst und ich habe das auch immer > berücksichtigt. Mist - dann habe ich mir die Nacht umsonst um die Ohren gehauen. Na ja - bin vermutlich ein bisschen selber schuld - hätte halt genauer Deine Posts lesen sollen. > Ich habe mit immer über die baudrate ausgerechnet, wie > lange ich für die Übertragung brauche und dementsprechend ein delay > reingesetzt. Bei 2MBaud vielen die delays dann ganz raus. Aber in eurer > Version müssten noch die Kommentare drin sein. Ich hatte mich nur auf "sendFrameBufferToUART (int ImageWidth, int ImageHeight, int BytesPerPixel)" konzentriert und da wa nischt drinne von wegen "delay" oder so. > Das erklärt jetzt auch warum bei euch die Bilder nicht "ganz" ankommen. > Das konnte ich nicht nachvollziehen... da hätte ich vielleicht den von > dir gefundenen Kniff erwähnen sollen (sorry). Immerhin: jetzt sind wir alle schlauer (bzw. genauso schlau, wie Du schon vorher warst :-)) > Aber nur weiter so! :D > Jetzt weiß ich auch warum du beim Bild anfangen wolltest, wenn dass noch > garnicht lief. Okay - dann gehen wir bitte nochmals einen Schritt zurück und klärer erst einmal, was denn aktuell bei Dir nicht funktioniert? (oder vermutlich genauer: wir repetieren noch einmal, was evtl. vor 100-200 Posts schon einmal gesagt wurde). Bitte beschreibe Deine Probleme netterweise noch einmal genauer (oder verlinke Deine Beschreibung, wenn Du die Probleme bereits vorher im Thread dokumentiert hast - ich habe nämlich etwas den Überblick verloren). Dann könnten Michael und ich zielgenau versuchen, die Probleme zu reproduzieren, um sie anschließend einzugrenzen. Ich selber möchte dabei Dein PC-Programm erst einmal außen vor lassen (also nicht nutzen) und mich nur auf das MC-Programm fokussieren. So können wir eine Fehlerquelle ausschließen. > Was ich gestern schreiben wollte war, dass ich genau an diesen Stellen, > wo die Funktionen um den Buffer zu füllen 0 zurückgeben, weil der Buffer > voll ist, brake points gesetzt habe. Und bei mir löst der dort nicht > aus. Das war ein geschickter Schachzug von Dir, denn damit hast Du eindeutig bewiesen, dass der Puffer bei Dir nicht überläuft - gut. > Grüße, > > David Viele Grüße Igel1
Andreas S. schrieb: > > Okay - dann gehen wir bitte nochmals einen Schritt zurück und klärer > erst einmal, was denn aktuell bei Dir nicht funktioniert? (oder > vermutlich genauer: wir repetieren noch einmal, was evtl. vor 100-200 > Posts schon einmal gesagt wurde). > Oh ha - klingt furchtbar arrogant, was ich da heute zwischen Tür und Angel formuliert hatte - sollte es aber gar nicht sein: Ich bräuchte nur einfach nur nochmals eine Beschreibung, wo genau bei Dir der Schuh / die Software drückt, damit ich weiß, wo genau ich anfangen soll. Viele Grüße Igel1
Hallo, Andreas S. schrieb: > Oh ha - klingt furchtbar arrogant, was ich da heute zwischen Tür und > Angel formuliert hatte - sollte es aber gar nicht sein: mach es nicht schlimmer als es ist. :-) > Ich bräuchte nur einfach nur nochmals eine Beschreibung, wo genau bei > Dir der Schuh / die Software drückt, damit ich weiß, wo genau ich > anfangen soll. Du triffst damit den Nagel ziemlich genau auf den Kopf. Was mich dabei betrifft: Deine UART-Änderung werde ist erstmal reinwerfen und schauen was passiert. Sein Terminalprogramm werde ich nutzen bzw. testen wenn es um irgendwas konkretes geht. Eigentlich ist mir dieses ziemlich egal, für mich interessant ist, was geht mit der OV7670, was kann man da Erreichen, weiche Bedeutung und Funktion haben Einstellungen da auf die Bildqualität usw. usw. Ob ich Registersettings da per spezieller Software mache oder die im Source ändere und flashe ist mir da relativ egal. Einfach, weil aus meiner Sicht da mehr Datenblattstudien, Funktionen verstehen im Vordergrund steht. Gruß aus berlin Michael
Andreas S. schrieb: > Ich hatte mich nur auf "sendFrameBufferToUART (int ImageWidth, int > ImageHeight, int BytesPerPixel)" konzentriert und da wa nischt drinne > von wegen "delay" oder so. Kann durchaus sein, weil ich ja immernur mit RbyR getestet hatte und das Empfangen des Gesamt bildes erst danach eingeführt habe. > Okay - dann gehen wir bitte nochmals einen Schritt zurück und klärer > erst einmal, was denn aktuell bei Dir nicht funktioniert? (oder > vermutlich genauer: wir repetieren noch einmal, was evtl. vor 100-200 > Posts schon einmal gesagt wurde). Sehr gerne! > Ich selber möchte dabei Dein PC-Programm erst einmal außen vor lassen > (also nicht nutzen) und mich nur auf das MC-Programm fokussieren. So > können wir eine Fehlerquelle ausschließen. Das wird vermutlich nicht gehen, da das Problem folgendes ist: Was funktioniert? -einzelnes Register Lesen -einzelnes Register Schreiben -ein Bild requesten und Empfangen (solange es das komplette Bild und nicht Row by Row ist. (Colorbar und wenn ich auf Bild stelle ein sehr sehr matschiges Bild (siehe Anhang) (vermutlich wegen fehlender Registereinstellungen [habe nur die notwendigsten]) Die Einstellungen würde ich dann gerne mit dem Terminal machen können. Was funktioniert nicht? (bzw. nicht zuverlässig?) alle Register hintereinander lesen (obwohl hier rein befehlstechnisch nichts anderes passiert, als beim einzelnen Register lesen) alle Register hintereinander schreiben Besonders tragisch ist hier, dass das Problem sporadisch und nicht zuverlässig reproduzierbar auftaucht. Wenn ich so ein Tool zur überwachung wie Michael einsetze, so ist es laut meiner Anzeige der uC, der den einen Befehl des Terminals ignoriert und dieses dann aber auf Antwort wartet. (Bin mir aber nicht sicher, ob ich das "Sniffer" Tool richtig eingesetzt habe. Ist das ganze soweit verständlich? Ein weiter Punkt, den wir - wie mir scheint - vööig außer acht gelassen haben ist, dass wir die Register einfach Blind schreiben, ohne Rücksicht auf evtl. reserved Bits richtig? Wie gehen wir damit um? Gruß David
Hallo, David D. schrieb: > Ein weiter Punkt, den wir - wie mir scheint - vööig außer acht gelassen > haben ist, dass wir die Register einfach Blind schreiben, ohne Rücksicht > auf evtl. reserved Bits richtig? Wie gehen wir damit um? Das Datenblatt der OV7670 ist da etwas... naja... Im zweifel habe ich mich ausgehend von den dort angegeben Registerwerten an den Default-Werten orientiert. Genauso, wie bei reservierten Registern, orientiere ich mich im Zweifel an irgendwelchen Applikationsbeispielen usw. Zum Terminal: ich werde mir zumindest die UART-Sachen auch nochmal genauer anschauen. Generell: mir erschließt sich der Zweck des Terminalprogramms irgendwie nicht. Register lesen und schreiben: ok. Alle Register lesen/schreiben und speichern/laden um einen bestimmten Zustand schnell zu rekonstruieren ja, anschauen würde ich mir die Werte nur in einem Texteditor, wo ich scrollen, kommentieren, ändern könnte und eben bei Bedarf den Kram auch komplett in die AVR-Software übernehmen könnte. Bild holen und evtl. gleich anzeigen ja, mit vordefinierten Formaten und im Stück. Die Formate würde ich dann bei bedarf erweitern, alle möglichen machen für mich sowieso keinen Sinn (Fifo-Größe/Verwendung). Bei Register hätte ich vermitlich sogar noch eine änderbare Binärdarstellung eingebaut, um mit dem Datenblatt daneben geziehlt Bists setzen/löschen zu können. Alles nur meine Gedanken... PS: ich hätte die Daten außer den Bilddaten generell als ASCII/HEX geschickt/geholt. Dann würde jedes simple Terminalprogramm zum Debug reichen: a <enter> -> Kommando raus 35 2f 74 -> Antwort kontrolliert. Der Aufwand HEX encode/decode ist auch auf dem AVR minimal und spielt auch keine Rolle, wenn der Mensch vor dem Bildschirm sowieso die Bremse ist. Auch das ist Ansichtssache, aber sonst müßte ich mir für jedes Experiment mit irgendwelchen externen ICs erst ein Spezialprogramm basteln und dazu habe ich weder Lust noch nehme ich mir die Zeit. Letztlich sind es aber Deine Pläne, Vorhaben und Absichten, die das alles entscheiden und ich gebe zu, daß ich da immernoch nicht so richtig durchschaue, wohin Dein Hase da eigentlich laufen soll. Gruß aus Berlin Michael
Michael U. schrieb: > Zum Terminal: ich werde mir zumindest die UART-Sachen auch nochmal > genauer anschauen. Generell: mir erschließt sich der Zweck des > Terminalprogramms irgendwie nicht. Der ursprüngliche Gedanke war, mit dem Terminal ein einfaches Werkzeug zu haben, um Registerwerte während der Laufzeit bequem ändern zu können, ohne für jede Änderung neu compilen+flashen zu müssen. Um hier Änderungen an den Register ausprobieren zu können. (Ich weiß du siehst im Ausprobieren keinen Sinn. Aber ich bin noch naiv genug ;-) ) > Register lesen und schreiben: ok. > Alle Register lesen/schreiben und speichern/laden um einen bestimmten > Zustand schnell zu rekonstruieren ja, anschauen würde ich mir die Werte > nur in einem Texteditor, wo ich scrollen, kommentieren, ändern könnte Das steht noch auf meiner ToDo-Liste, sodass ich die Änderungen auch im Terminal vornehmen kann und nicht den Umweg gehen muss. > Bild holen und evtl. gleich anzeigen ja, mit vordefinierten Formaten und > im Stück. Die Formate würde ich dann bei bedarf erweitern, alle > möglichen machen für mich sowieso keinen Sinn (Fifo-Größe/Verwendung). Ja, hatten wir schon vereinbart ;-) Angefangen wurde jetzt erstmal mit RGB565. > Bei Register hätte ich vermitlich sogar noch eine änderbare > Binärdarstellung eingebaut, um mit dem Datenblatt daneben geziehlt Bists > setzen/löschen zu können. steht ebenfalls auf der ToDo, sodass da auch ein Umstellen wie bei den einzelnen Registern möglich wird. > PS: ich hätte die Daten außer den Bilddaten generell als ASCII/HEX > geschickt/geholt. Dann würde jedes simple Terminalprogramm zum Debug > reichen: a <enter> -> Kommando raus > 35 2f 74 -> Antwort kontrolliert. > Der Aufwand HEX encode/decode ist auch auf dem AVR minimal und spielt > auch keine Rolle, wenn der Mensch vor dem Bildschirm sowieso die Bremse > ist. Das verstehe ich nicht muss ich gestehen. Also die Kommandos und auch Bild Bytes werden ja als Bytes geschickt, wie du sie dir dann im Terminal anzeigen lässt ist doch deine Sache. Du kannst auch einfach mit Terra Term mit meinem uC Programm kommunizieren. Die Befehle sind in der Tabelle in diesem Beitrag zu sehen: Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)" > Auch das ist Ansichtssache, aber sonst müßte ich mir für jedes > Experiment mit irgendwelchen externen ICs erst ein Spezialprogramm > basteln und dazu habe ich weder Lust noch nehme ich mir die Zeit. Das verstehe ich ebenfalls nicht, vermutlich weil ich vorherige Aussage nicht verstanden habe :D > Letztlich sind es aber Deine Pläne, Vorhaben und Absichten, die das > alles entscheiden und ich gebe zu, daß ich da immernoch nicht so richtig > durchschaue, wohin Dein Hase da eigentlich laufen soll. Wie oben beschriebe: "einfaches" handeln der Kamera ohne hunderte flash Vorgänge. Außerdem kann ich für meine späteren Zwecke teile dieses Programms weiterbenutzten (maschinelle Bildverarbeitung) (kein Video nur Einzelbilder) ;-) Gruß David
Hallo, David D. schrieb: > Das verstehe ich nicht muss ich gestehen. Also die Kommandos und auch > Bild Bytes werden ja als Bytes geschickt, wie du sie dir dann im > Terminal anzeigen lässt ist doch deine Sache. Du kannst auch einfach mit > Terra Term mit meinem uC Programm kommunizieren. Die Befehle sind in der > Tabelle in diesem Beitrag zu sehen: Ganz einfach: normalerweise nutze ich /und die Terminalprogramm) irgendeine Emualtion, meist VT100. Da ist es dann mühsam Controlcodes (0x00...0x1f) zu senden bzw. eine Einstellung zu finden, die empfangenen Daten als hex ausgibt. HTerm kann sowas, ist aber eigentlich auch eher ein Debug-Tool als ein Terminalprogramm. David D. schrieb: > Wie oben beschriebe: "einfaches" handeln der Kamera ohne hunderte flash > Vorgänge. Wenn es ein guter alter TEA5757 wäre würde ich Dir vorbehaltlos zustimmen, beim MAS3507D wurde es damals für mich schon haariger. Beim ENC28J60 mußte ich mir erst Grundlagen von TCp/IP usw. zusammensuchen, für einen rudimentären Stack mit dem Chip reichte es dann auch, ARP-Ping und IDCP-Ping ging und dann fehlöte damals zeit und auch Lust und ich habe auf was hlabwegs fertiges genommen, das angepasst. Die gewonnenen Vorkenntnisse haben zumindest gereicht, recht zielsicher in den fremden Sourcen dir richtigen Stellen zu finden. Bei den 201 Registern der OV7670 incl. haarsträubender Bitkombination und Abhängigkeiten würde ich mir das freiwillig nicht antun wollen. Ich will aus dem Teil ein Bild haben, ich muß rausfinden, welce Register ich dazu anfassen muß und welche Rolle genau diese spielen. Was die anderen 182 machen ist mir da ziemlich egal. ;) Es würde mir auch wenig für andere Projekte (Spielereien) bringen, bei einem anderen Kameramodul geht das Suchen sowieso von vorn los. - gewünschte Auflösung - gewünschtes Bildformat dann die ersten Extras: - Belichtungssteuerung - Gammakorrektur - Farbkorrektur dann die Spezialitäten: - Belichtungsautomatik - Weißabgleichautomatik - 50/60Hz Erkennung (Kunstlicht) - Gain-Regelung, Nachtmodus und was die Teile konkret jeweils können. Das muß ich bei Bedarf auch in einem anderen Datenblatt schnell finden und testen können. Die Kamera liefert prinzipiell ein Bild im gewünschten Format. Jetzt könnte ich mich z.B. mit den Registern auseinandersetzen, die die Bildlage auf dem Sensor bestimmen, eigentlich müßten die 320x240 ohne Fehler an den Rändern rauskommen. David D. schrieb: > Außerdem kann ich für meine späteren Zwecke teile dieses Programms > weiterbenutzten (maschinelle Bildverarbeitung) (kein Video nur > Einzelbilder) ;-) keine Einwände dagegen. Meine damalige LA-Software in VB6 kann auch nur rund 10 Kommandos ,it Einstellungen zum AVR schicken und dann 32k Sampleram zurückbekommen. Die Software selbst auf dem PC ist dann Anwendung: Einstellbutton, Darstellung der Samledaten usw. Das lief auch nicht auf Anhieb, war aber das erste. was ich stabil in Gang bekommen mußte. Genug philosophiert. ;) Gruß aus Berlin Michel
Hi David, by the way: Ich weiß nun, wann Dein Terminal-Programm (V0.6) am rechten Rand beschnitten wird: Ich habe nämlich die Textgröße und weitere Elemente auf dem Bildschirm dauerhaft vergrößert, indem ich unter Win7 X64 in den Einstellungen Systemsteuerung\Darstellung und Anpassung\Anzeige im Fenster "Lesbarkeit auf dem Bildschirm erleichtern" die Vergrößerung auf "Mittel - 125%" eingestellt habe. Meine Auflösung ist dabei nach wie vor 1920x1200. Sobald ich obige Einstellung auf 100% (Standard) zurücksetze, wird Dein Terminalfenster nicht mehr am rechten Rand beschnitten. Es wäre super, wenn Du diesen Bug fixen könntest, denn dann könnte ich auch ein bisschen mit Deinem Terminalprogramm testen. Viele Grüße Igel1
David D. schrieb: > Was funktioniert nicht? (bzw. nicht zuverlässig?) > alle Register hintereinander lesen (obwohl hier rein befehlstechnisch > nichts anderes passiert, als beim einzelnen Register lesen) > alle Register hintereinander schreiben > Besonders tragisch ist hier, dass das Problem sporadisch und nicht > zuverlässig reproduzierbar auftaucht. Wenn ich so ein Tool zur > überwachung wie Michael einsetze, so ist es laut meiner Anzeige der uC, > der den einen Befehl des Terminals ignoriert und dieses dann aber auf > Antwort wartet. > (Bin mir aber nicht sicher, ob ich das "Sniffer" Tool richtig eingesetzt > habe. > > Ist das ganze soweit verständlich? Leider nein (sorry, wenn ich etwas langsam von Kapee bin): Meinst Du mit "alle Register hintereinander lesen/schreiben", dass die Lese-/Schreibroutinen auf dem ATmega buggy sind, oder meinst Du dass der Lese-/Schreibvorgang (sporadisch) schief geht, wenn Du das Lesen-/Schreiben von Deinem Terminalprogamm aus anstößt? Viele Grüße Igel1
:
Bearbeitet durch User
Andreas S. schrieb: > Leider nein (sorry, wenn ich etwas langsam von Kapee bin): kein Problem! Es gibt in meinem uC-Programm keine Routinen für das auslesen oder schreiben von mehreren Registern. Auf meinem Terminal Programm gibt es das aber zum Beispiel beim klick auf "Read Device Setting", "get Camera Status" (lesen) und "write Device Settings" (schreiben) die Möglichkeit mehrere Register hintereinander zu lesen respektive zu schreiben. Dabei läuft dann folgender Kommunikationspingpong ab: am Beispiel lesen: Terminal fordert Wert für Register 0x01 an Terminal wartet auf Antwort uC gibt Wert für Register 0x01 aus Terminal forder Wert für Register 0x02 an Terminal wartet auf Antwort uC gibt Wert für Register 0x02 aus ... (Das Programm bleibt nicht während des Wartens in einer While schleife hängen, da das ganze in C# Eventbasiert verarbeitet wird) wenn ich mir jetzt anschaue, welche Kommunikation statt findet wenn bspw. nicht alle Register gelesen werden, so gerät die Kommunikation nach Terminal wartet auf Antwort ins stocken, weil einach die Antwort vom uC ausbleibt. Das ganze tritt sporadisch auf, sprich manchmal hängt es nach wenigen Registern manchmal nach mehreren manchmal garnicht. Und genau das kann ich mir nicht erklären.
David D. schrieb:
(formatiert von Igel1)
1 | > folgende Kommandos kann der uC empfangen: |
2 | > Command Auswirkung Byte1 Byte2 expected Return Value |
3 | > 0x01 Read Register Register Address - 1 Byte register Value |
4 | > 0x02 Write Register Register Address newRegisterValue 1 Byte Errorcode |
Hmmm - mein Logic-Analyzer sagt da etwas anderes. Du sendest in Wirklichkeit, z.B. beim Auslesen von Register 0x05: 0x01 0x05 0x0D 0x0A Und erhältst in Wirklichkeit als Antwort: 0x05 0x80 ... wobei 0x80 der Registerinhalt von Register 0x05 ist. Und die Schreibfolge sieht so aus, wenn Du z.B. Register 0x05 mit Wert 0x80 beschreibst: 0x02 0x05 0x80 0x0D 0x0A Und als Antwort erhältst Du den Fehlercode: 0x00 Viele Grüße Igel1
David D. schrieb: > wenn ich mir jetzt anschaue, welche Kommunikation statt findet wenn > bspw. nicht alle Register gelesen werden, so gerät die Kommunikation > nach Terminal wartet auf Antwort ins stocken, weil einach die Antwort > vom uC ausbleibt. Das ganze tritt sporadisch auf, sprich manchmal hängt > es nach wenigen Registern manchmal nach mehreren manchmal garnicht. Und > genau das kann ich mir nicht erklären. Ah ja: Du meinst, der grüne Ladebalken hängt (manchmal), wenn Du auf den Button "Read Device Settings" drückst? Yep - dieses Problem kann ich zumindest reproduzieren. Viele Grüße Igel1
Ähm ja... :D Das liegt daran, wie der uC erkennt ob ein Befehl vollständig gesendet wurde. An jedes Kommando, dass das Terminal sendet wird am Ende ein CR+LF dran gehangen (13, 10 in dez. oder 0x0D 0x0A in Hex) Anhand dieses Indikators wird der Rx Buffer in Sinnvolle empfangene Befehle gestückelt und sicher gestellt, dass ein Befehl erst verarbeitet wird, wenn alle notwendigen Informationen vorhanden sind. Die Verarbeitung findet dann in UART.c unter der Funktion UART0_rx_work statt:
1 | ... |
2 | if(UART0_rx_complete()) |
3 | { |
4 | |
5 | char Befehl[UART0_Befehl_FiFo] = {}; // Hier steht der Befehl |
6 | volatile int j = 0; |
7 | volatile int i = 0; |
8 | do |
9 | { |
10 | char temp = UART0_rx_out(); |
11 | |
12 | Befehl[i] = temp; |
13 | i++; |
14 | |
15 | //Künstlicher Zähler, um das Abfragen der beiden Bits auch beim ersten zu ermöglichen |
16 | if(i<2) |
17 | j=1; |
18 | else |
19 | j=0; |
20 | }while(((Befehl[i+j-2] != (char)0x0D) || (Befehl[i-1] != (char)0x0A))&&(i<UART0_Befehl_FiFo)); // solange kein CR+LF erkannt wird |
21 | ... |
Hallo, die Bytefolgen hatte ich mir im Sniffer auch angeschaut und bin zu dem gleichen Schluß gekommen, was gesendet wird usw. Zum Glück für Andreas habe ich im Moment etwas wenig Zeit für die GEschichte, so kann er mir in Ruhe die Arbeit abnehmen. ;-)) Ich habbe mal eine IRQ-RX-Routine in die uart.c gepackt, weil ich mir Davids Ablauf noch nicht im Detail angeschaut habe. Ich hänge die hier einfach mal ran, in main() müssen vorn noch 3 Zeilen eingefügt werden. In uart.h muß die Zeile #define UART_MAXSTRLEN 63 eingefügt werden und in main()
1 | extern volatile uint8_t uart_str_complete; // 1 .. String komplett empfangen |
2 | extern volatile uint8_t uart_str_count; |
3 | extern volatile char * uart_string[]; |
Ich wollte da eigentlich nur schnell testen, ob sein switch für die Kommandoauswertung das, macht, was er soll, ist aber noch nicht passiert. Ist alles nicht schön gemacht, sollte nur gehen... Es fehlt z.B. ein error-flag wenn der Buffer voll ist, da geht es dann nie weiter. Müßte in main() abgefragt werden um den Buffer einfach neu zu initialisieren bei einem derartigen Fehler und ein overflow zum Terminal gemeldet werden.. Gruß aus Berlin Michael
:
Bearbeitet durch User
Michael U. schrieb: > Zum Glück für Andreas habe ich im Moment etwas wenig Zeit für die > GEschichte, so kann er mir in Ruhe die Arbeit abnehmen. ;-)) Na wenn Du Dich da mal nicht täuscht: Andreas ist die nächsten 5 Tage computerlos, wird also erst mal nix mit Weiterdebuggen. Ich lasse Euch zwei Hübschen also erst einmal alleine im Code weiterrühren. Aber so ist das mit dem Hobby: ständig ist alles andere wichtiger - es ist zum Mäusemelken. Viele Grüße Igel1
Na das klingt ja nach nem Karnevals Jecken... ich komm für den Samstag extra hoch ;-)
Hi David, habe gerade eine heiße Spur entdeckt, werde aber keine Zeit mehr haben, sie zu verfolgen: Dein Ringpuffer-Mechanismus funktioniert offenbar nicht so, wie er eigentlich angedacht ist. So definierst Du den Ringpuffer und die zugehörigen Zähler "read" und "write":
1 | #define UART0_rx_size 512 // Nur Werte 2^n zulässig ! |
2 | #define UART0_rx_mask (UART0_rx_size-1) |
3 | |
4 | |
5 | //------------------------------------------------------------------------------ |
6 | |
7 | int temp = 0; |
8 | struct UART0_rx //Receive Buffer |
9 | { |
10 | char data[UART0_rx_size]; |
11 | char read; |
12 | char write; |
13 | }UART0_rx= {{}, 0, 0}; |
Und so verwendest Du sie:
1 | int UART0_rx_in (char input) |
2 | { |
3 | char temp= ((UART0_rx.write+1)&UART0_rx_mask); // |
4 | if (temp==UART0_rx.read) //FiFo voll ? |
5 | { |
6 | return 0; //return 0 -> Fifo voll |
7 | } |
8 | UART0_rx.data[UART0_rx.write]=(char)input; //Daten ins Array legen |
9 | UART0_rx.write = temp; //write auf nächste Specicherzelle schieben |
10 | return 1; //return 1 -> Fifo abspeichern erfolgreich |
11 | } |
Dabei fällt auf, dass die beiden Zähler nur 8 Bit breit sind, Dein Modulo-Mechanismus mit
1 | ((UART0_rx.write+1)&UART0_rx_mask) |
... aber offenbar von einem Integer-Wert ausgeht. Will sagen: der Mechanismus läuft ins Leere. Jetzt müsste man nochmals genau durchdenken, ob es trotzdem per Zufall funktioniert - an allen Stellen und sogar auch bei Subtraktionen, die ja ebenfalls vorkommen. Jedenfalls scheint es nicht so gedacht gewesen zu sein und von Deinem 512 Byte breiten Ringpuffer werden dadurch auch nur 256 Bytes genutzt. Viele Grüße Igel1
Hallo, Andreas S. schrieb: > Jedenfalls scheint es nicht so gedacht gewesen zu sein und von Deinem > 512 Byte breiten Ringpuffer werden dadurch auch nur 256 Bytes genutzt. warum reserviert man auf einem kleinen AVR mit nur 2k Ram solche Riesenbuffer? So lang kann doch keine Kommandofolge sein und bevor er die nicht bearbeitet und beantwortet hat, macht es doch keinen Sinn was neues zum AVR zu schicken. Beim Senden ist es doch auch egal, ob man 128Byte oder 512Byte Häppchen schickt? Ist vielleicht auch Vorurteil, aber bei mir heißt AVR eben immernoch Ram sparen, wo es geht und geziehlt dort einsetzen, wo es wirklich nötig ist. Bei den ESPs bin ich da weit weniger sparsam... ;) Gruß aus Berlin Michael
Hi Dirk, schau mal hier: https://ide.geeksforgeeks.org/E7p41NoTYk Morgen mehr dazu. Viele Grüße Igel1
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
Hi David, hier eine noch bessere Version: https://ide.geeksforgeeks.org/kueWbVYXmL Der Code lautet:
1 | #include <stdio.h> |
2 | |
3 | #define SIZE 512 |
4 | #define MASK (SIZE - 1) |
5 | |
6 | int main() { |
7 | char c; |
8 | char carray[] = {0,1,2,126,127,128,129,-1,-2}; |
9 | char cplus1; |
10 | int cintplus1; |
11 | int data[SIZE]={}; |
12 | |
13 | for(int p=0; p<SIZE; p++){ |
14 | data[p] = p; |
15 | } |
16 | |
17 | for(int k=0; k<sizeof(carray); k++){ |
18 | |
19 | c=carray[k]; |
20 | cplus1=(c+1) & MASK; |
21 | cintplus1=(c+1) & MASK; |
22 | |
23 | printf("c=%d\n", c); |
24 | printf("cplus1=%d\n", cplus1); |
25 | printf("cintplus1=%d\n", cintplus1); |
26 | printf("data[c]=%d\n", data[c]); |
27 | printf("data[(c-1) & MASK]=%d\n", data[(c-1) & MASK]); |
28 | printf("data[c & MASK] = %d\n", data[c & MASK]); |
29 | printf("data[(c+1) & MASK]=%d\n", data[(c+1) & MASK]); |
30 | printf("........................\n\n"); |
31 | } |
32 | return 0; |
33 | } |
Und das Ergebnis lautet:
1 | c=0 |
2 | cplus1=1 |
3 | cintplus1=1 |
4 | data[c]=0 |
5 | data[(c-1) & MASK]=511 |
6 | data[c & MASK] = 0 |
7 | data[(c+1) & MASK]=1 |
8 | ........................ |
9 | |
10 | c=1 |
11 | cplus1=2 |
12 | cintplus1=2 |
13 | data[c]=1 |
14 | data[(c-1) & MASK]=0 |
15 | data[c & MASK] = 1 |
16 | data[(c+1) & MASK]=2 |
17 | ........................ |
18 | |
19 | c=2 |
20 | cplus1=3 |
21 | cintplus1=3 |
22 | data[c]=2 |
23 | data[(c-1) & MASK]=1 |
24 | data[c & MASK] = 2 |
25 | data[(c+1) & MASK]=3 |
26 | ........................ |
27 | |
28 | c=126 |
29 | cplus1=127 |
30 | cintplus1=127 |
31 | data[c]=126 |
32 | data[(c-1) & MASK]=125 |
33 | data[c & MASK] = 126 |
34 | data[(c+1) & MASK]=127 |
35 | ........................ |
36 | |
37 | c=127 |
38 | cplus1=-128 |
39 | cintplus1=128 |
40 | data[c]=127 |
41 | data[(c-1) & MASK]=126 |
42 | data[c & MASK] = 127 |
43 | data[(c+1) & MASK]=128 |
44 | ........................ |
45 | |
46 | c=-128 |
47 | cplus1=-127 |
48 | cintplus1=385 |
49 | data[c]=710832128 |
50 | data[(c-1) & MASK]=383 |
51 | data[c & MASK] = 384 |
52 | data[(c+1) & MASK]=385 |
53 | ........................ |
54 | |
55 | c=-127 |
56 | cplus1=-126 |
57 | cintplus1=386 |
58 | data[c]=32517 |
59 | data[(c-1) & MASK]=384 |
60 | data[c & MASK] = 385 |
61 | data[(c+1) & MASK]=386 |
62 | ........................ |
63 | |
64 | c=-1 |
65 | cplus1=0 |
66 | cintplus1=0 |
67 | data[c]=0 |
68 | data[(c-1) & MASK]=510 |
69 | data[c & MASK] = 511 |
70 | data[(c+1) & MASK]=0 |
71 | ........................ |
72 | |
73 | c=-2 |
74 | cplus1=-1 |
75 | cintplus1=511 |
76 | data[c]=8 |
77 | data[(c-1) & MASK]=509 |
78 | data[c & MASK] = 510 |
79 | data[(c+1) & MASK]=511 |
80 | ........................ |
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
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
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
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
Edit: in diesem post stand nur wirres Zeug :D einfach ignorieren....
:
Bearbeitet durch User
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
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
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
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
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.
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
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.
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
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
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:
1 | Sample Nano Nano |
2 | No TX RX |
3 | --------------------- |
4 | 0 |
5 | 5234 01h |
6 | 5320 0Ch |
7 | 5407 0Dh |
8 | 5493 0Ah |
9 | 14492 0Ch |
10 | 39386 00h |
11 | 40611 01h |
12 | 40698 12h |
13 | 40784 0Dh |
14 | 40870 0Ah |
15 | 49475 12h |
16 | 74370 00h |
17 | 75367 01h |
18 | 75453 1Ch |
19 | 75540 0Dh |
20 | 75626 0Ah |
21 | 84459 1Ch |
22 | 109355 7Fh |
23 | 110693 01h |
24 | 110779 1Dh |
25 | 110865 0Dh |
26 | 110952 0Ah |
27 | 119444 1Dh |
28 | 144340 A2h |
29 | 145526 01h |
30 | 145612 3Ah |
31 | 145698 0Dh |
32 | 145785 0Ah |
33 | 154428 3Ah |
34 | 179324 0Dh |
35 | 180713 01h |
36 | 180799 3Dh |
37 | 180886 0Dh |
38 | 180972 0Ah |
39 | 189413 3Dh |
40 | 214309 88h |
41 | 215460 01h |
42 | 215546 3Eh |
43 | 215633 0Dh |
44 | 215719 0Ah |
45 | 224398 3Eh |
46 | 249293 00h |
47 | 250509 01h |
48 | 250596 40h |
49 | 250682 0Dh |
50 | 250768 0Ah |
51 | 259381 40h |
52 | 284276 C0h |
53 | 285334 01h |
54 | 285420 42h |
55 | 285507 0Dh |
56 | 285593 0Ah |
57 | 294365 42h |
58 | 319260 00h |
59 | 320262 01h |
60 | 320349 70h |
61 | 320435 0Dh |
62 | 320521 0Ah |
63 | 329349 70h |
64 | 354245 3Ah |
65 | 355467 01h |
66 | 355553 71h |
67 | 355639 0Dh |
68 | 355726 0Ah |
69 | 364334 71h |
70 | 389229 35h |
71 | 390369 01h |
72 | 390456 0Ah |
73 | 390542 0Dh |
74 | 390628 0Ah |
75 | 399318 0Ah |
76 | 424214 76h |
77 | 425358 01h |
78 | 425444 0Bh |
79 | 425531 0Dh |
80 | 425617 0Ah |
81 | 434303 0Bh |
82 | 459199 73h |
83 | 505116 04h |
84 | 505203 80h |
85 | 505289 02h |
86 | 505375 0Dh |
87 | 505462 0Ah |
88 | 514918 04h |
89 | 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:
1 | Command Auswirkung Byte1 Byte2 expected Return Value |
2 | 0x04 set xResolution Resolution x MSB Resolution x LSB 1 Byte xres. Value |
3 | 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
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
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 ...
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
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
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.
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
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
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
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
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:
1 | int UART0_rx_work(int* Programmstatus) |
2 | { |
3 | |
4 | //igel1: Warum wird hier UART0_rx_complete() aufgerufen, wo es doch |
5 | // schon vor dem Aufruf der Routine "UART0_rx_work" aufgerufen |
6 | // wurde? |
7 | |
8 | if(UART0_rx_complete()) |
9 | { |
10 | |
11 | char Befehl[UART0_Befehl_FiFo] = {}; // Hier steht der Befehl |
12 | volatile int j = 0; |
13 | volatile int i = 0; |
14 | |
15 | //igel1: Was ist der Sinn und Zweck dieser while-Schleife ?? |
16 | // Warum so kompliziert? |
17 | // Was hat sich David dabei gedacht, was wir möglicherweise |
18 | // übersehen? |
19 | do |
20 | { |
21 | char temp = UART0_rx_out(); |
22 | |
23 | Befehl[i] = temp; |
24 | i++; |
25 | |
26 | //Künstlicher Zähler, um das Abfragen der beiden Bits auch beim ersten zu ermöglichen |
27 | if(i<2) |
28 | j=1; |
29 | else |
30 | j=0; |
31 | //igel1: Hier passt der Kommentar nicht zum Code: es wird nicht |
32 | // auf "CR UND LF" geprüft, sondern auf "CR ODER LF". |
33 | // Da ich den Sinn und Zweck des Codes aber nicht verstehe, |
34 | // so kann ich nicht beurteilen, ob der Kommentar oder der |
35 | // Code falsch sind. |
36 | }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
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
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
Mist - David's Mittagspause scheint ihm heute gestrichen worden zu sein. Dabei könnten wir gut ein bisschen Input gebrauchen ...
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
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
1 | }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
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
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
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
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.
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
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
@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 ...
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
Michael U. schrieb: > Hallo, > > der Liste von Andreas stimme ich so erstmal völlig zu. > > Zu github: mir die aktuellen Versionen von github zu holen ist für mich > völlig ok, komplett werde ich mich mit github nicht befassen. Da sehe > ich aber auch kein wirkliches Problem, die real anfallenden kurzen > Codeausschnitte kann man, denke ich zumindest, gut hier diskutieren. Ich vermute, Du hast hier etwas falsch verstanden. Wir sprechen nicht über die Code-Versionierungsmöglichkeiten von GitHub, sondern über die Möglichkeiten, dort Bugs und Feature-Requests zu hinterlegen, zu dokumentieren, zu priorisieren und deren Fortschritt zu tracken. Siehe z.B. dieses Video dazu: https://www.youtube.com/watch?v=WCH0j1Ywgrw > Ich habe inzwischen nochmal wegen der writeRegister-Geschichte geschaut. > Habe in meinen modifizierten Code (nur uart.h und main.c verändert) mal > etwas debug reingemacht. Effekte: Register 0x00 wird offenbar wirklich > nicht geschrieben, fällt bei meinem init nicht auf, weil 0x00 da sowieso > auf 0x00 bleibt. Andere Werte werden aber definitiv nicht übernommen. Aha - interessante Erkenntnis. > Noch ziemlich ungeprüft: schreiben von 0x00 auf Register 0x04 setzt > 0x01, andere Werte ergeben auch falsche Ergebnisse. Die reserved Bits > liefern mir da keine Erklärung. Ich werde mir das mal so ändern, daß ich > nur nicht identische Werte gemeldet bekomme, sonst ist das zu langweilig > zu kontrollieren. Das heißt, Du willst alle Register beschreiben und dann auslesen und vergleichen, um zu dokumentieren, welche Register nicht beschrieben werden können? > Außerdem werde ich mprgen mal schauen, ob ich OV7670_read() und > OV7670_write() problemlos durch meine I2C-Routinen ersetzen kann zum > Vergleich. Wenn die Differenzen bleiben jängt es mit der Kamera direkt > zusammen, wenn nicht muß ich mir die SCCB-Routinen mal genauer anschauen > bzw. den LA wieder ranhängen. Schöne Maikäferarbeit, aber so ähnlich würde ich ebenfalls vorgehen. > Schönen Abend noch. > Gruß aus Berlin > Michael Dito Igel1
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
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
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
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
... 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
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:
1 | OV7670_write (0x00, 0x88); |
2 | OV_SCCB_RegisterToUart(0x00); |
3 | while(1){} |
... so verschwindet das Programm beim dem OV_SCCB_RegisterToUart(0x00)-Aufruf auf nimmerwiedersehen. Gleiches passiert bei folgendem Konstrukt:
1 | char iregData; |
2 | OV7670_write (0x00, 0x88); |
3 | OV7670_read (0x00, &iregData); |
4 | 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:
1 | case 1: //ReadRegister and sent it to Uart |
2 | UART0_senden_Byte(receivedAddress); |
3 | //_delay_ms(1); |
4 | OV_SCCB_RegisterToUart(receivedAddress); |
5 | 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
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
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
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
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
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
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
@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
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
Andreas S. schrieb: > ... und sage uns, warum das Beschreiben des Registers nicht > funktioniert Kannst Du bitte SCCB_E zusätzlich aufzeichnen?
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
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
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.
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 -------------------------------------------------------------------
1 | I2C_Config(); // Initialize I2C |
2 | printf("I2C_Config() done\n"); |
3 | |
4 | OV7670_Reset(); |
5 | |
6 | |
7 | uint16_t regaddr = 0x00; |
8 | uint8_t regdatabefore = 0x00; |
9 | uint8_t regdataafter = 0x00; |
10 | uint8_t regdatanew = 0x88; |
11 | uint8_t retval = 0x00; |
12 | uint32_t delval = 100; |
13 | |
14 | Delay(delval); |
15 | printf("Writing 0x%x to registers\n\n", regdatanew); |
16 | printf("regaddr value before mod value after mod\n"); |
17 | printf("-------------------------------------------------------------------------\n"); |
18 | |
19 | // for register 0x00 .. 0x9C:
|
20 | // read register, write 0x88 into register, read register again ...
|
21 | for (regaddr = 0; regaddr <= 0xC9; regaddr++) { |
22 | regdatabefore = OV7670_ReadReg(regaddr); |
23 | Delay(delval); |
24 | printf("regaddr=0x%X regdata=0x%X ", regaddr, regdatabefore); |
25 | retval = OV7670_WriteReg(regaddr, regdatanew); |
26 | Delay(delval); |
27 | regdataafter = OV7670_ReadReg(regaddr); |
28 | Delay(delval); |
29 | printf("regdata=0x%X ", regdataafter); |
30 | if(regdataafter == 0x88){ |
31 | printf("SUCCESS\n"); |
32 | } else { |
33 | printf("FAILURE\n"); |
34 | }
|
35 | }
|
36 | |
37 | printf("-------------------------------------------------------------------------\n"); |
38 | |
39 | // ... and read out all registers again ...
|
40 | for (regaddr = 0; regaddr <= 0xC9; regaddr++) { |
41 | regdataafter = OV7670_ReadReg(regaddr); |
42 | printf("regaddr=0x%X regdata=0x%X \n", regaddr, regdataafter); |
43 | Delay(delval); |
44 | }
|
Ergebnis:
1 | I2C_Config() done |
2 | Writing 0x88 to registers |
3 | |
4 | regaddr value before mod value after mod |
5 | ------------------------------------------------------------------------- |
6 | regaddr=0x0 regdata=0x3 regdata=0x3 FAILURE |
7 | regaddr=0x1 regdata=0x80 regdata=0x80 FAILURE |
8 | regaddr=0x2 regdata=0x82 regdata=0x82 FAILURE |
9 | regaddr=0x3 regdata=0x0 regdata=0x88 SUCCESS |
10 | regaddr=0x4 regdata=0x1 regdata=0x89 FAILURE |
11 | regaddr=0x5 regdata=0x7F regdata=0x7F FAILURE |
12 | regaddr=0x6 regdata=0x5F regdata=0x6B FAILURE |
13 | regaddr=0x7 regdata=0x40 regdata=0x40 FAILURE |
14 | regaddr=0x8 regdata=0x80 regdata=0x80 FAILURE |
15 | regaddr=0x9 regdata=0x1 regdata=0x88 SUCCESS |
16 | regaddr=0xA regdata=0x76 regdata=0x76 FAILURE |
17 | regaddr=0xB regdata=0x73 regdata=0x73 FAILURE |
18 | regaddr=0xC regdata=0x0 regdata=0x88 SUCCESS |
19 | regaddr=0xD regdata=0x0 regdata=0x88 SUCCESS |
20 | regaddr=0xE regdata=0x1 regdata=0x88 SUCCESS |
21 | regaddr=0xF regdata=0x43 regdata=0x88 SUCCESS |
22 | regaddr=0x10 regdata=0x7F regdata=0x7F FAILURE |
23 | regaddr=0x11 regdata=0x80 regdata=0x88 SUCCESS |
24 | regaddr=0x12 regdata=0x0 regdata=0x0 FAILURE |
25 | regaddr=0x13 regdata=0x8F regdata=0x88 SUCCESS |
26 | regaddr=0x14 regdata=0x4A regdata=0x88 SUCCESS |
27 | regaddr=0x15 regdata=0x0 regdata=0x88 SUCCESS |
28 | regaddr=0x16 regdata=0x0 regdata=0x88 SUCCESS |
29 | regaddr=0x17 regdata=0x11 regdata=0x88 SUCCESS |
30 | regaddr=0x18 regdata=0x61 regdata=0x88 SUCCESS |
31 | regaddr=0x19 regdata=0x3 regdata=0x88 SUCCESS |
32 | regaddr=0x1A regdata=0x7B regdata=0x88 SUCCESS |
33 | regaddr=0x1B regdata=0x0 regdata=0x88 SUCCESS |
34 | regaddr=0x1C regdata=0x7F regdata=0x7F FAILURE |
35 | regaddr=0x1D regdata=0xA2 regdata=0xA2 FAILURE |
36 | regaddr=0x1E regdata=0x1 regdata=0x88 SUCCESS |
37 | regaddr=0x1F regdata=0x0 regdata=0x88 SUCCESS |
38 | regaddr=0x20 regdata=0x4 regdata=0x88 SUCCESS |
39 | regaddr=0x21 regdata=0x2 regdata=0x88 SUCCESS |
40 | regaddr=0x22 regdata=0x1 regdata=0x88 SUCCESS |
41 | regaddr=0x23 regdata=0x0 regdata=0x88 SUCCESS |
42 | regaddr=0x24 regdata=0x75 regdata=0x88 SUCCESS |
43 | regaddr=0x25 regdata=0x63 regdata=0x88 SUCCESS |
44 | regaddr=0x26 regdata=0xD4 regdata=0x88 SUCCESS |
45 | regaddr=0x27 regdata=0x80 regdata=0x88 SUCCESS |
46 | regaddr=0x28 regdata=0x80 regdata=0x88 SUCCESS |
47 | regaddr=0x29 regdata=0x7 regdata=0x88 SUCCESS |
48 | regaddr=0x2A regdata=0x0 regdata=0x88 SUCCESS |
49 | regaddr=0x2B regdata=0x0 regdata=0x88 SUCCESS |
50 | regaddr=0x2C regdata=0x80 regdata=0x88 SUCCESS |
51 | regaddr=0x2D regdata=0x0 regdata=0x88 SUCCESS |
52 | regaddr=0x2E regdata=0x0 regdata=0x88 SUCCESS |
53 | regaddr=0x2F regdata=0xE regdata=0x88 SUCCESS |
54 | regaddr=0x30 regdata=0x8 regdata=0x88 SUCCESS |
55 | regaddr=0x31 regdata=0x30 regdata=0x88 SUCCESS |
56 | regaddr=0x32 regdata=0x80 regdata=0x88 SUCCESS |
57 | regaddr=0x33 regdata=0x8 regdata=0x88 SUCCESS |
58 | regaddr=0x34 regdata=0x11 regdata=0x88 SUCCESS |
59 | regaddr=0x35 regdata=0x1A regdata=0x88 SUCCESS |
60 | regaddr=0x36 regdata=0x0 regdata=0x88 SUCCESS |
61 | regaddr=0x37 regdata=0x3F regdata=0x88 SUCCESS |
62 | regaddr=0x38 regdata=0x1 regdata=0x88 SUCCESS |
63 | regaddr=0x39 regdata=0x0 regdata=0x88 SUCCESS |
64 | regaddr=0x3A regdata=0xD regdata=0x88 SUCCESS |
65 | regaddr=0x3B regdata=0x0 regdata=0x88 SUCCESS |
66 | regaddr=0x3C regdata=0x68 regdata=0x88 SUCCESS |
67 | regaddr=0x3D regdata=0x88 regdata=0x88 SUCCESS |
68 | regaddr=0x3E regdata=0x0 regdata=0x88 SUCCESS |
69 | regaddr=0x3F regdata=0x0 regdata=0x88 SUCCESS |
70 | regaddr=0x40 regdata=0xC0 regdata=0x88 SUCCESS |
71 | regaddr=0x41 regdata=0x8 regdata=0x88 SUCCESS |
72 | regaddr=0x42 regdata=0x0 regdata=0x88 SUCCESS |
73 | regaddr=0x43 regdata=0x14 regdata=0x88 SUCCESS |
74 | regaddr=0x44 regdata=0xF0 regdata=0x88 SUCCESS |
75 | regaddr=0x45 regdata=0x45 regdata=0x88 SUCCESS |
76 | regaddr=0x46 regdata=0x61 regdata=0x88 SUCCESS |
77 | regaddr=0x47 regdata=0x51 regdata=0x88 SUCCESS |
78 | regaddr=0x48 regdata=0x79 regdata=0x88 SUCCESS |
79 | regaddr=0x49 regdata=0x0 regdata=0x88 SUCCESS |
80 | regaddr=0x4A regdata=0x0 regdata=0x88 SUCCESS |
81 | regaddr=0x4B regdata=0x0 regdata=0x88 SUCCESS |
82 | regaddr=0x4C regdata=0x0 regdata=0x88 SUCCESS |
83 | regaddr=0x4D regdata=0x4 regdata=0x88 SUCCESS |
84 | regaddr=0x4E regdata=0x0 regdata=0x88 SUCCESS |
85 | regaddr=0x4F regdata=0x40 regdata=0x88 SUCCESS |
86 | regaddr=0x50 regdata=0x34 regdata=0x88 SUCCESS |
87 | regaddr=0x51 regdata=0xC regdata=0x88 SUCCESS |
88 | regaddr=0x52 regdata=0x17 regdata=0x88 SUCCESS |
89 | regaddr=0x53 regdata=0x29 regdata=0x88 SUCCESS |
90 | regaddr=0x54 regdata=0x40 regdata=0x88 SUCCESS |
91 | regaddr=0x55 regdata=0x0 regdata=0x88 SUCCESS |
92 | regaddr=0x56 regdata=0x40 regdata=0x88 SUCCESS |
93 | regaddr=0x57 regdata=0x80 regdata=0x88 SUCCESS |
94 | regaddr=0x58 regdata=0x1E regdata=0x88 SUCCESS |
95 | regaddr=0x59 regdata=0x91 regdata=0x88 SUCCESS |
96 | regaddr=0x5A regdata=0x94 regdata=0x88 SUCCESS |
97 | regaddr=0x5B regdata=0xAA regdata=0x88 SUCCESS |
98 | regaddr=0x5C regdata=0x71 regdata=0x88 SUCCESS |
99 | regaddr=0x5D regdata=0x8D regdata=0x88 SUCCESS |
100 | regaddr=0x5E regdata=0xF regdata=0x88 SUCCESS |
101 | regaddr=0x5F regdata=0xF0 regdata=0x88 SUCCESS |
102 | regaddr=0x60 regdata=0xF0 regdata=0x88 SUCCESS |
103 | regaddr=0x61 regdata=0xF0 regdata=0x88 SUCCESS |
104 | regaddr=0x62 regdata=0x0 regdata=0x88 SUCCESS |
105 | regaddr=0x63 regdata=0x0 regdata=0x88 SUCCESS |
106 | regaddr=0x64 regdata=0x50 regdata=0x88 SUCCESS |
107 | regaddr=0x65 regdata=0x30 regdata=0x88 SUCCESS |
108 | regaddr=0x66 regdata=0x0 regdata=0x88 SUCCESS |
109 | regaddr=0x67 regdata=0x80 regdata=0x88 SUCCESS |
110 | regaddr=0x68 regdata=0x80 regdata=0x88 SUCCESS |
111 | regaddr=0x69 regdata=0x0 regdata=0x88 SUCCESS |
112 | regaddr=0x6A regdata=0x82 regdata=0x88 SUCCESS |
113 | regaddr=0x6B regdata=0xA regdata=0x88 SUCCESS |
114 | regaddr=0x6C regdata=0x2 regdata=0x88 SUCCESS |
115 | regaddr=0x6D regdata=0x55 regdata=0x88 SUCCESS |
116 | regaddr=0x6E regdata=0xC0 regdata=0x88 SUCCESS |
117 | regaddr=0x6F regdata=0x9A regdata=0x88 SUCCESS |
118 | regaddr=0x70 regdata=0x3A regdata=0x88 SUCCESS |
119 | regaddr=0x71 regdata=0x35 regdata=0x88 SUCCESS |
120 | regaddr=0x72 regdata=0x11 regdata=0x88 SUCCESS |
121 | regaddr=0x73 regdata=0x0 regdata=0x88 SUCCESS |
122 | regaddr=0x74 regdata=0x0 regdata=0x88 SUCCESS |
123 | regaddr=0x75 regdata=0xF regdata=0x88 SUCCESS |
124 | regaddr=0x76 regdata=0x1 regdata=0x88 SUCCESS |
125 | regaddr=0x77 regdata=0x10 regdata=0x88 SUCCESS |
126 | regaddr=0x78 regdata=0x0 regdata=0x88 SUCCESS |
127 | regaddr=0x79 regdata=0x0 regdata=0x88 SUCCESS |
128 | regaddr=0x7A regdata=0x24 regdata=0x88 SUCCESS |
129 | regaddr=0x7B regdata=0x4 regdata=0x88 SUCCESS |
130 | regaddr=0x7C regdata=0x7 regdata=0x88 SUCCESS |
131 | regaddr=0x7D regdata=0x10 regdata=0x88 SUCCESS |
132 | regaddr=0x7E regdata=0x28 regdata=0x88 SUCCESS |
133 | regaddr=0x7F regdata=0x36 regdata=0x88 SUCCESS |
134 | regaddr=0x80 regdata=0x44 regdata=0x88 SUCCESS |
135 | regaddr=0x81 regdata=0x52 regdata=0x88 SUCCESS |
136 | regaddr=0x82 regdata=0x60 regdata=0x88 SUCCESS |
137 | regaddr=0x83 regdata=0x6C regdata=0x88 SUCCESS |
138 | regaddr=0x84 regdata=0x78 regdata=0x88 SUCCESS |
139 | regaddr=0x85 regdata=0x8C regdata=0x88 SUCCESS |
140 | regaddr=0x86 regdata=0x9E regdata=0x88 SUCCESS |
141 | regaddr=0x87 regdata=0xBB regdata=0x88 SUCCESS |
142 | regaddr=0x88 regdata=0xD2 regdata=0x88 SUCCESS |
143 | regaddr=0x89 regdata=0xE5 regdata=0x88 SUCCESS |
144 | regaddr=0x8A regdata=0x0 regdata=0x88 SUCCESS |
145 | regaddr=0x8B regdata=0x0 regdata=0x88 SUCCESS |
146 | regaddr=0x8C regdata=0x0 regdata=0x88 SUCCESS |
147 | regaddr=0x8D regdata=0xF regdata=0x88 SUCCESS |
148 | regaddr=0x8E regdata=0x0 regdata=0x88 SUCCESS |
149 | regaddr=0x8F regdata=0x0 regdata=0x88 SUCCESS |
150 | regaddr=0x90 regdata=0x0 regdata=0x88 SUCCESS |
151 | regaddr=0x91 regdata=0x0 regdata=0x88 SUCCESS |
152 | regaddr=0x92 regdata=0x0 regdata=0x88 SUCCESS |
153 | regaddr=0x93 regdata=0x0 regdata=0x88 SUCCESS |
154 | regaddr=0x94 regdata=0x50 regdata=0x88 SUCCESS |
155 | regaddr=0x95 regdata=0x50 regdata=0x88 SUCCESS |
156 | regaddr=0x96 regdata=0x1 regdata=0x88 SUCCESS |
157 | regaddr=0x97 regdata=0x1 regdata=0x88 SUCCESS |
158 | regaddr=0x98 regdata=0x10 regdata=0x88 SUCCESS |
159 | regaddr=0x99 regdata=0x40 regdata=0x88 SUCCESS |
160 | regaddr=0x9A regdata=0x40 regdata=0x88 SUCCESS |
161 | regaddr=0x9B regdata=0x20 regdata=0x88 SUCCESS |
162 | regaddr=0x9C regdata=0x0 regdata=0x88 SUCCESS |
163 | regaddr=0x9D regdata=0x99 regdata=0x88 SUCCESS |
164 | regaddr=0x9E regdata=0x7F regdata=0x88 SUCCESS |
165 | regaddr=0x9F regdata=0xC0 regdata=0x88 SUCCESS |
166 | regaddr=0xA0 regdata=0x90 regdata=0x88 SUCCESS |
167 | regaddr=0xA1 regdata=0x3 regdata=0x88 SUCCESS |
168 | regaddr=0xA2 regdata=0x2 regdata=0x88 SUCCESS |
169 | regaddr=0xA3 regdata=0x1E regdata=0x88 SUCCESS |
170 | regaddr=0xA4 regdata=0x0 regdata=0x88 SUCCESS |
171 | regaddr=0xA5 regdata=0xF regdata=0x88 SUCCESS |
172 | regaddr=0xA6 regdata=0xF0 regdata=0x88 SUCCESS |
173 | regaddr=0xA7 regdata=0xC1 regdata=0x88 SUCCESS |
174 | regaddr=0xA8 regdata=0xF0 regdata=0x88 SUCCESS |
175 | regaddr=0xA9 regdata=0xC1 regdata=0x88 SUCCESS |
176 | regaddr=0xAA regdata=0x14 regdata=0x88 SUCCESS |
177 | regaddr=0xAB regdata=0xF regdata=0x88 SUCCESS |
178 | regaddr=0xAC regdata=0x0 regdata=0x88 SUCCESS |
179 | regaddr=0xAD regdata=0x80 regdata=0x88 SUCCESS |
180 | regaddr=0xAE regdata=0x80 regdata=0x88 SUCCESS |
181 | regaddr=0xAF regdata=0x80 regdata=0x88 SUCCESS |
182 | regaddr=0xB0 regdata=0x0 regdata=0x88 SUCCESS |
183 | regaddr=0xB1 regdata=0x0 regdata=0x88 SUCCESS |
184 | regaddr=0xB2 regdata=0x0 regdata=0x88 SUCCESS |
185 | regaddr=0xB3 regdata=0x80 regdata=0x88 SUCCESS |
186 | regaddr=0xB4 regdata=0x0 regdata=0x88 SUCCESS |
187 | regaddr=0xB5 regdata=0x4 regdata=0x88 SUCCESS |
188 | regaddr=0xB6 regdata=0x0 regdata=0x88 SUCCESS |
189 | regaddr=0xB7 regdata=0x66 regdata=0x88 SUCCESS |
190 | regaddr=0xB8 regdata=0x0 regdata=0x88 SUCCESS |
191 | regaddr=0xB9 regdata=0x6 regdata=0x88 SUCCESS |
192 | regaddr=0xBA regdata=0x0 regdata=0x88 SUCCESS |
193 | regaddr=0xBB regdata=0x0 regdata=0x88 SUCCESS |
194 | regaddr=0xBC regdata=0x0 regdata=0x88 SUCCESS |
195 | regaddr=0xBD regdata=0x0 regdata=0x88 SUCCESS |
196 | regaddr=0xBE regdata=0x0 regdata=0x88 SUCCESS |
197 | regaddr=0xBF regdata=0x0 regdata=0x88 SUCCESS |
198 | regaddr=0xC0 regdata=0x0 regdata=0x88 SUCCESS |
199 | regaddr=0xC1 regdata=0x0 regdata=0x88 SUCCESS |
200 | regaddr=0xC2 regdata=0x0 regdata=0x88 SUCCESS |
201 | regaddr=0xC3 regdata=0x0 regdata=0x88 SUCCESS |
202 | regaddr=0xC4 regdata=0x0 regdata=0x88 SUCCESS |
203 | regaddr=0xC5 regdata=0x0 regdata=0x88 SUCCESS |
204 | regaddr=0xC6 regdata=0x88 regdata=0x88 SUCCESS |
205 | regaddr=0xC7 regdata=0x88 regdata=0x88 SUCCESS |
206 | regaddr=0xC8 regdata=0x88 regdata=0x88 SUCCESS |
207 | regaddr=0xC9 regdata=0xC0 regdata=0x82 FAILURE |
208 | ------------------------------------------------------------------------- |
209 | regaddr=0x0 regdata=0x0 |
210 | regaddr=0x1 regdata=0x80 |
211 | regaddr=0x2 regdata=0x82 |
212 | regaddr=0x3 regdata=0x0 |
213 | regaddr=0x4 regdata=0x1 |
214 | regaddr=0x5 regdata=0x24 |
215 | regaddr=0x6 regdata=0x24 |
216 | regaddr=0x7 regdata=0x40 |
217 | regaddr=0x8 regdata=0x24 |
218 | regaddr=0x9 regdata=0x1 |
219 | regaddr=0xA regdata=0x76 |
220 | regaddr=0xB regdata=0x73 |
221 | regaddr=0xC regdata=0x0 |
222 | regaddr=0xD regdata=0x0 |
223 | regaddr=0xE regdata=0x1 |
224 | regaddr=0xF regdata=0x43 |
225 | regaddr=0x10 regdata=0x7F |
226 | regaddr=0x11 regdata=0x80 |
227 | regaddr=0x12 regdata=0x0 |
228 | regaddr=0x13 regdata=0x88 |
229 | regaddr=0x14 regdata=0x88 |
230 | regaddr=0x15 regdata=0x88 |
231 | regaddr=0x16 regdata=0x88 |
232 | regaddr=0x17 regdata=0x88 |
233 | regaddr=0x18 regdata=0x88 |
234 | regaddr=0x19 regdata=0x88 |
235 | regaddr=0x1A regdata=0x88 |
236 | regaddr=0x1B regdata=0x88 |
237 | regaddr=0x1C regdata=0x7F |
238 | regaddr=0x1D regdata=0xA2 |
239 | regaddr=0x1E regdata=0x88 |
240 | regaddr=0x1F regdata=0x88 |
241 | regaddr=0x20 regdata=0x88 |
242 | regaddr=0x21 regdata=0x88 |
243 | regaddr=0x22 regdata=0x88 |
244 | regaddr=0x23 regdata=0x88 |
245 | regaddr=0x24 regdata=0x88 |
246 | regaddr=0x25 regdata=0x88 |
247 | regaddr=0x26 regdata=0x88 |
248 | regaddr=0x27 regdata=0x88 |
249 | regaddr=0x28 regdata=0x88 |
250 | regaddr=0x29 regdata=0x88 |
251 | regaddr=0x2A regdata=0x88 |
252 | regaddr=0x2B regdata=0x88 |
253 | regaddr=0x2C regdata=0x88 |
254 | regaddr=0x2D regdata=0x0 |
255 | regaddr=0x2E regdata=0x0 |
256 | regaddr=0x2F regdata=0x24 |
257 | regaddr=0x30 regdata=0x88 |
258 | regaddr=0x31 regdata=0x88 |
259 | regaddr=0x32 regdata=0x88 |
260 | regaddr=0x33 regdata=0x88 |
261 | regaddr=0x34 regdata=0x88 |
262 | regaddr=0x35 regdata=0x88 |
263 | regaddr=0x36 regdata=0x88 |
264 | regaddr=0x37 regdata=0x88 |
265 | regaddr=0x38 regdata=0x88 |
266 | regaddr=0x39 regdata=0x88 |
267 | regaddr=0x3A regdata=0x88 |
268 | regaddr=0x3B regdata=0x88 |
269 | regaddr=0x3C regdata=0x88 |
270 | regaddr=0x3D regdata=0x88 |
271 | regaddr=0x3E regdata=0x88 |
272 | regaddr=0x3F regdata=0x88 |
273 | regaddr=0x40 regdata=0x88 |
274 | regaddr=0x41 regdata=0x88 |
275 | regaddr=0x42 regdata=0x88 |
276 | regaddr=0x43 regdata=0x88 |
277 | regaddr=0x44 regdata=0x88 |
278 | regaddr=0x45 regdata=0x88 |
279 | regaddr=0x46 regdata=0x88 |
280 | regaddr=0x47 regdata=0x88 |
281 | regaddr=0x48 regdata=0x88 |
282 | regaddr=0x49 regdata=0x88 |
283 | regaddr=0x4A regdata=0x88 |
284 | regaddr=0x4B regdata=0x88 |
285 | regaddr=0x4C regdata=0x88 |
286 | regaddr=0x4D regdata=0x88 |
287 | regaddr=0x4E regdata=0x88 |
288 | regaddr=0x4F regdata=0x88 |
289 | regaddr=0x50 regdata=0x88 |
290 | regaddr=0x51 regdata=0x88 |
291 | regaddr=0x52 regdata=0x88 |
292 | regaddr=0x53 regdata=0x88 |
293 | regaddr=0x54 regdata=0x88 |
294 | regaddr=0x55 regdata=0x88 |
295 | regaddr=0x56 regdata=0x88 |
296 | regaddr=0x57 regdata=0x88 |
297 | regaddr=0x58 regdata=0x88 |
298 | regaddr=0x59 regdata=0x88 |
299 | regaddr=0x5A regdata=0x88 |
300 | regaddr=0x5B regdata=0x88 |
301 | regaddr=0x5C regdata=0x88 |
302 | regaddr=0x5D regdata=0x88 |
303 | regaddr=0x5E regdata=0x88 |
304 | regaddr=0x5F regdata=0x88 |
305 | regaddr=0x60 regdata=0x88 |
306 | regaddr=0x61 regdata=0x88 |
307 | regaddr=0x62 regdata=0x88 |
308 | regaddr=0x63 regdata=0x88 |
309 | regaddr=0x64 regdata=0x88 |
310 | regaddr=0x65 regdata=0x88 |
311 | regaddr=0x66 regdata=0x88 |
312 | regaddr=0x67 regdata=0x88 |
313 | regaddr=0x68 regdata=0x88 |
314 | regaddr=0x69 regdata=0x88 |
315 | regaddr=0x6A regdata=0x88 |
316 | regaddr=0x6B regdata=0x88 |
317 | regaddr=0x6C regdata=0x88 |
318 | regaddr=0x6D regdata=0x88 |
319 | regaddr=0x6E regdata=0x88 |
320 | regaddr=0x6F regdata=0x88 |
321 | regaddr=0x70 regdata=0x88 |
322 | regaddr=0x71 regdata=0x88 |
323 | regaddr=0x72 regdata=0x88 |
324 | regaddr=0x73 regdata=0x88 |
325 | regaddr=0x74 regdata=0x88 |
326 | regaddr=0x75 regdata=0x88 |
327 | regaddr=0x76 regdata=0x88 |
328 | regaddr=0x77 regdata=0x88 |
329 | regaddr=0x78 regdata=0x88 |
330 | regaddr=0x79 regdata=0x88 |
331 | regaddr=0x7A regdata=0x88 |
332 | regaddr=0x7B regdata=0x88 |
333 | regaddr=0x7C regdata=0x88 |
334 | regaddr=0x7D regdata=0x88 |
335 | regaddr=0x7E regdata=0x88 |
336 | regaddr=0x7F regdata=0x88 |
337 | regaddr=0x80 regdata=0x88 |
338 | regaddr=0x81 regdata=0x88 |
339 | regaddr=0x82 regdata=0x88 |
340 | regaddr=0x83 regdata=0x88 |
341 | regaddr=0x84 regdata=0x88 |
342 | regaddr=0x85 regdata=0x88 |
343 | regaddr=0x86 regdata=0x88 |
344 | regaddr=0x87 regdata=0x88 |
345 | regaddr=0x88 regdata=0x88 |
346 | regaddr=0x89 regdata=0x88 |
347 | regaddr=0x8A regdata=0x88 |
348 | regaddr=0x8B regdata=0x88 |
349 | regaddr=0x8C regdata=0x88 |
350 | regaddr=0x8D regdata=0x88 |
351 | regaddr=0x8E regdata=0x88 |
352 | regaddr=0x8F regdata=0x88 |
353 | regaddr=0x90 regdata=0x88 |
354 | regaddr=0x91 regdata=0x88 |
355 | regaddr=0x92 regdata=0x88 |
356 | regaddr=0x93 regdata=0x88 |
357 | regaddr=0x94 regdata=0x88 |
358 | regaddr=0x95 regdata=0x88 |
359 | regaddr=0x96 regdata=0x88 |
360 | regaddr=0x97 regdata=0x88 |
361 | regaddr=0x98 regdata=0x88 |
362 | regaddr=0x99 regdata=0x88 |
363 | regaddr=0x9A regdata=0x88 |
364 | regaddr=0x9B regdata=0x88 |
365 | regaddr=0x9C regdata=0x88 |
366 | regaddr=0x9D regdata=0x88 |
367 | regaddr=0x9E regdata=0x88 |
368 | regaddr=0x9F regdata=0x88 |
369 | regaddr=0xA0 regdata=0x88 |
370 | regaddr=0xA1 regdata=0x88 |
371 | regaddr=0xA2 regdata=0x88 |
372 | regaddr=0xA3 regdata=0x1E |
373 | regaddr=0xA4 regdata=0x88 |
374 | regaddr=0xA5 regdata=0x88 |
375 | regaddr=0xA6 regdata=0x88 |
376 | regaddr=0xA7 regdata=0x88 |
377 | regaddr=0xA8 regdata=0x88 |
378 | regaddr=0xA9 regdata=0x88 |
379 | regaddr=0xAA regdata=0x88 |
380 | regaddr=0xAB regdata=0x88 |
381 | regaddr=0xAC regdata=0x88 |
382 | regaddr=0xAD regdata=0x88 |
383 | regaddr=0xAE regdata=0x88 |
384 | regaddr=0xAF regdata=0x88 |
385 | regaddr=0xB0 regdata=0x88 |
386 | regaddr=0xB1 regdata=0x88 |
387 | regaddr=0xB2 regdata=0x88 |
388 | regaddr=0xB3 regdata=0x88 |
389 | regaddr=0xB4 regdata=0x88 |
390 | regaddr=0xB5 regdata=0x88 |
391 | regaddr=0xB6 regdata=0x88 |
392 | regaddr=0xB7 regdata=0x88 |
393 | regaddr=0xB8 regdata=0x88 |
394 | regaddr=0xB9 regdata=0x88 |
395 | regaddr=0xBA regdata=0x88 |
396 | regaddr=0xBB regdata=0x88 |
397 | regaddr=0xBC regdata=0x88 |
398 | regaddr=0xBD regdata=0x88 |
399 | regaddr=0xBE regdata=0x88 |
400 | regaddr=0xBF regdata=0x88 |
401 | regaddr=0xC0 regdata=0x88 |
402 | regaddr=0xC1 regdata=0x88 |
403 | regaddr=0xC2 regdata=0x88 |
404 | regaddr=0xC3 regdata=0x88 |
405 | regaddr=0xC4 regdata=0x88 |
406 | regaddr=0xC5 regdata=0x88 |
407 | regaddr=0xC6 regdata=0x88 |
408 | regaddr=0xC7 regdata=0x88 |
409 | regaddr=0xC8 regdata=0x88 |
410 | regaddr=0xC9 regdata=0x82 |
Viele Grüße Igel1
Andreas S. schrieb: > Weiter unten findet Ihr meinen Code ... leider ohne die ausführenden Routinen ....
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.
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
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)
@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
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:
1 | regaddr=0x4F regdata=0x40 regdata=0x88 SUCCESS |
2 | regaddr=0x50 regdata=0x34 regdata=0x88 SUCCESS |
3 | regaddr=0x51 regdata=0xC regdata=0x88 SUCCESS |
4 | regaddr=0x52 regdata=0x17 regdata=0x88 SUCCESS |
5 | regaddr=0x53 regdata=0x29 regdata=0x88 SUCCESS |
6 | regaddr=0x54 regdata=0x40 regdata=0x88 SUCCESS |
Viele Grüße Igel1
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
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
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 ...
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
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
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
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
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
@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
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
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
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
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
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
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
Whoop Whoop, ich habe heute doch tatsächlich die nächste halbe Stunde Zeit mich endlich nochmal meinem elektro Hobby zu widmen. In der zwischenzeit habe ich mir gedanken über das Kommunikationsprotokoll gemacht. Was haltet ihr davon, nach JEDEM gesendeten Kommando an den uC einen Fehlercode zu erwarten? und dann kann ich abhängig von dem Fehlercode entscheiden was zu tun ist.
Hallo, ich habe mich im Moment ja auch etwas rar gemacht hier. Zumindest, was das Terminal angeht, wird sich das auch kaum ändern, mehr als Testen werde ich da nichts. Mir fehlt da einfach eine reale Anwendung dafür. Vor allem, weil ich für die OV7670 keinerlei reale Anwendung für mich finde. Ganz allgemein von meiner Seite: das Kommandoprotokoll würde ich immer so anlegen, wie ich es für die Anwendung brauche, um alles Nötige abzufangen. Als Antwort vielleicht hier generell als Erstes den Fehlercode, 0x00 für alles ok usw. Hat den Vorteil, daß man nichts nutzloses senden muß, wenn ein Fehler auftritt. Bei z.B. Register lesen brauche ich ja als Antwort nur den Inhalt, wenn es geklappt hat. Die Registeradresse kann man mitschicken (dann eben immer bei Erfolg) wenn man sich beim Auswerten nicht merken will/kann, was man angefordert hat. Macht z.B. Sinn, wenn ich eine Sammlung Register zum Ändern rüberschicke und die Differenzen erkennen will. Andere Sachen, wie Dein zeilenweises Lesen des Bildes, machen für mich keinen wirklichen Sinn, normalerweise klappt die Übertragung ohne Probleme. Bild anfordern -> 0x00 und dann die Bilddaten oder eben Errorcode und Schluß. Bei ok würde ich noch die erwartete Byteanzahl am Ende prüfen (Timeout einplanen, wenn zuwenig Daten kommen, Fehlerzustand, wenn mehr als erwartet. usw. usw. Aber das sind alles Planungen, nur mit Deinen konkreten Vorstellungen von der Anwendung Deines Terminal bestimmt werden. Gruß aus Berlin Michael
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.