Brauche Unterstützung beim OV7670 (bzw. SCCB)

[David D. (saturi)]

Hallo Michael,

deine Vorschläge werde ich auch auf die ToDo-Liste in Github einpflegen. 
Die gefallen mir sehr gut. Gerade bin ich dabei, die default 
Einstellungen nach der Initialisierung anzupassen, sodass wir QVGA und 
RGB565 haben.

Bei weiteren Code Verbesserungen ist mir nocheinmal Register 0x40 
(COM15) aufgefallen:

"[Bit5:4] RGB 555/565 option....
x0: Normal RGB output
01: RGB565
11: RGB555

Was bedeutet an dieser Stelle für uns Normal RGB? RGB888? Hatten wir 
nicht gesagt, dass die Kamera das nicht kann?

Ich weiß, dass du mal was zu gesagt hattest, aber ich kriege es gerade 
leider nicht mehr wirklich zusammen

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Was bedeutet an dieser Stelle für uns Normal RGB? RGB888? Hatten wir
> nicht gesagt, dass die Kamera das nicht kann?

hängt von 0x12 ab und wohl auch von 0x8C, müßte RGB444 sein.
Ich hatte mich da auf RGB565 festgelegt un nicht weiter geschaut.
Hinweise auf mehr als 2 Byte für die Bildinformation habe ich nirgends 
gefunden.

Gruß aus Berlin
Michael

[David D. (saturi)]

Guten Abend,

neuer Release:
https://github.com/igittigitt/ov7670/blob/master/OV7670-Terminal-Releases/OV7670-Terminal_V0_10.zip

change log:
- kleiner Bugfix
- default Camera Einstellung bei Kamera initialisieren: QVGA RGB565
- read/write register Fehler sollte behoben sein
- Meldungen in der Statusleiste verbessert
- Write Register jetzt ebenfalls in der History
- ComSniffer (in absoluter Beta Version ;-) ) als Tab hinzugefügt.

Könnt ihr mal schauen, ob das mit den Fehlern bei euch behoben ist? Und 
falls weitere Fehler auftauchen und identifiziert sind wieder Bescheid 
geben :)

Bei mir funktioniert Read Device Settings immernoch sporadisch nicht.... 
:/

[Andreas S. (igel1)]

Hi David,

zu dem neuen Terminal gehört aber noch der alte AVR-Code, stimmt's?
Oder wurde der AVR-Code auch angepasst?

Könntest Du netterweise den Code vom Terminal auch noch einstellen - ich 
lerne doch gerade C# dafür ...

Lesen und Schreiben von Registern scheint auf den ersten Blick nun gut 
zu funktionieren. Bild-Einlesen macht Mucken, muss ich morgen testen.

Viele Grüße

Igel1

[David D. (saturi)]

ist mir auch schon aufgefallen, liegt an dem "Sniffer"... Das Empfangen 
des Bildes überfordert ihn...

Daher in diesem Release wieder deaktiviert

uC Programm sollte noch das gleiche sein... entweder habe ich eben 
unbeabsichtigt was gelöscht, was beim Mousepad am Laptop leider schonmal 
schnell vorkommen kann, oder ich habe einen Riesen Bock im uC Programm 
gefunden... Das muss ich noch mit einer altern Version vergleichen.

https://github.com/igittigitt/ov7670

sowohl die gesamte Projekt Datei, als auch die .exe als release

[Andreas S. (igel1)]

Hi David,

also:  Oberfläche sieht jetzt in Deiner Version 0.11 irgendwie schöner 
und aufgeräumter aus.

"Read register", "Write Register" und "Read Device Settings" scheinst Du 
inzwischen voll im Griff zu haben.

"take Picture" ging allerdings noch ziemlich daneben:

Szenario:

- AVR reset  (im DebugWire mode)
- COM-Port im Terminal-Programm verbunden
- Button "Kamera initialisieren"
- Button "get camera"
- Button "take picture"

Resultat siehst Du im 2. Bild im Anhang - da war die Terminal-Version 
0.7.0.1 schon einmal weiter (wenngleich auch nur s/w - vgl. 1. Bild im 
Anhang).

Aber: wenn ich die bekannten Colorbar-Initwerte manuell in die Register 
pumpe, so erhalte ich tatsächlich ein schönes Testbild (siehe Bild 3 im 
Anhang).

Erstaulich dabei: obwohl von Hand in die Register geschrieben, erkennt 
Dein Programm das Pattern und zeigt an: "Testpattern Colorbar".

Das führt mich zu der Vermutung, dass Dein "take Picture" eigentlich 
funktioniert, aber die Kombination der gesendeten "Kamera 
Initialisieren"-Registerwerte zu einem Bild führt, was auflösungs- oder 
formatmäßig nicht zu Deiner im Terminal gewählten X-/Y-Auflösung bzw. 
dem dort gewählten Format des Bildes passt.

Weitere "Bugs" und Verbesserungen hier (bin aktuell zu faul, sie alle 
ins GIT einzutragen):

- Button "read for change" schreibt keine Logmeldung
- Buttonbeschriftung solltest Du vereinheitlichen:
  Heute:  "read register",
          "Read Device Settings",
          "Kamera Initialisieren", ...
  Besser: "Read Register" oder "Init Camera"
          Also einheitliche Schreibweise in Englisch
- Die Idee mit dem "List not up to date" nach Schreiboperationen
  finde ich richtig gut! Du solltest das aber konsequent durchhalten -
  also auch bei "Kamera initialisieren" muss "List not up to date"
  gesetzt werden.
- Richtig wichtig fände ich unter dem Bild die Anzeige, mit welcher
  X- bzw. Y-Auflösung das Bild im Terminal dargestellt wird
- Umschalten zwischen den Tabs scheint nicht mehr zu funktionieren:
  Im Tab "manueller Modus" wird nach Umschalten noch weiterhin
  das rechte Fenster mit dem "take Picture" vom Tab "Settings" 
angezeigt.


Viele Grüße

Igel1

[Andreas S. (igel1)]

Als Visual Studio - Newbie habe ich folgende Frage:

Welche "Workload" soll ich in Visual Studio installieren, um Dein 
Programm richtig bearbeiten zu können?

Viele Grüße

Igel1

[David D. (saturi)]

Andreas S. schrieb:
> Hi David,
> "Read register", "Write Register" und "Read Device Settings" scheinst Du
> inzwischen voll im Griff zu haben.
sehr gut
> "take Picture" ging allerdings noch ziemlich daneben:
>
> Szenario:
>
> - AVR reset  (im DebugWire mode)
> - COM-Port im Terminal-Programm verbunden
> - Button "Kamera initialisieren"
> - Button "get camera"
> - Button "take picture"
Das ist korrekt, das liegt daran, dass wir mit der init routine die 
Register der Auflösung ändern. (Die init routine läuft übrigens im 
Terminal) Jetzt erkennt das Terminal anhand der Register Werte, welche 
Auflösung eingestellt ist. (Der uC weiß das aber nicht). Das bedeutet, 
dass ich jetzt noch die passende Auflösung und BytesPerPixel an de uC 
senden muss. Ihr wolltet aber sämtliche Schreibbefehle aus der get 
Status funktion raus haben. Daher sind die jetzt zu dem Butten sync 
Camera gewandert. Sprich:
nachdem ich die auflösung ändere (passiert bei init Kamera) muss danach 
zwingend der sync Camera knopf gedrückt werden.
Das versuche ich noch ersichtlicher zu machen

> Aber: wenn ich die bekannten Colorbar-Initwerte manuell in die Register
> pumpe, so erhalte ich tatsächlich ein schönes Testbild (siehe Bild 3 im
> Anhang).
Das widerrum ist merkwürdig... vlt. sollte ich mir das nochmal anschauen


> Erstaulich dabei: obwohl von Hand in die Register geschrieben, erkennt
> Dein Programm das Pattern und zeigt an: "Testpattern Colorbar".
Jap :)

> Das führt mich zu der Vermutung, dass Dein "take Picture" eigentlich
> funktioniert, aber die Kombination der gesendeten "Kamera
> Initialisieren"-Registerwerte zu einem Bild führt, was auflösungs- oder
> formatmäßig nicht zu Deiner im Terminal gewählten X-/Y-Auflösung bzw.
> dem dort gewählten Format des Bildes passt.
>
s.o.
> Weitere "Bugs" und Verbesserungen hier (bin aktuell zu faul, sie alle
> ins GIT einzutragen):
>
> - Button "read for change" schreibt keine Logmeldung
> - Buttonbeschriftung solltest Du vereinheitlichen:
>   Heute:  "read register",
>           "Read Device Settings",
>           "Kamera Initialisieren", ...
>   Besser: "Read Register" oder "Init Camera"
>           Also einheitliche Schreibweise in Englisch
> - Die Idee mit dem "List not up to date" nach Schreiboperationen
>   finde ich richtig gut! Du solltest das aber konsequent durchhalten -
>   also auch bei "Kamera initialisieren" muss "List not up to date"
>   gesetzt werden.
> - Richtig wichtig fände ich unter dem Bild die Anzeige, mit welcher
>   X- bzw. Y-Auflösung das Bild im Terminal dargestellt wird
> - Umschalten zwischen den Tabs scheint nicht mehr zu funktionieren:
>   Im Tab "manueller Modus" wird nach Umschalten noch weiterhin
>   das rechte Fenster mit dem "take Picture" vom Tab "Settings"
> angezeigt.
sehr gut :)


Zu dem Studio "Workload"... Ich habe da leider nicht den leisesten 
Schimmer was du damit meinst. Also dur brauchst c# windows forms (oder 
so ähnlich) und .net Framework

Edit: sorry Bild nicht gesehen: also im ersten Schritt brauchst du nur 
das oben rechts .net desktop development
Öffnen kannst du das Projekt einfach über die .sln datei.

viele Grüße
David

[Andreas S. (igel1)]

David D. schrieb:
> Andreas S. schrieb:
>> [...]
>> "take Picture" ging allerdings noch ziemlich daneben:
>> [...]
> Das ist korrekt, das liegt daran, dass wir mit der init routine die
> Register der Auflösung ändern. (Die init routine läuft übrigens im
> Terminal)

Ja klar: sie sendet ein reset 0x12 0x80 und dann 2 
Register-write-Aktionen an den MC (so meine Erinnerung).

Die genaue Sendefolge solltest Du im Log ausgeben - der Benutzer sollte 
stets wissen, was exakt an den AVR gesendet wird.

> Jetzt erkennt das Terminal anhand der Register Werte, welche
> Auflösung eingestellt ist. (Der uC weiß das aber nicht).

Diese 2 Sätze verstehe ich nicht: das Setting von Registern kurz zuvor 
beeinflusst doch automatisch schon die Auflösung? Und der uC weiß doch 
davon?! Die Register-Write-Befehle werden ja an ihn geschickt?
Ich glaube, ich stehe aktuell wieder einmal ein wenig auf der Leitung?

> Das bedeutet,
> dass ich jetzt noch die passende Auflösung und BytesPerPixel an de uC
> senden muss.

> Ihr wolltet aber sämtliche Schreibbefehle aus der get
> Status funktion raus haben.

Ja, das ist unbedingt richtig!

> Daher sind die jetzt zu dem Butten sync Camera gewandert. Sprich:
> nachdem ich die auflösung ändere (passiert bei init Kamera) muss danach
> zwingend der sync Camera knopf gedrückt werden.
> Das versuche ich noch ersichtlicher zu machen

Au ja, das wäre gut, denn ich habe hier wieder Deine Erklärung noch das 
Zusammenspiel der beiden Buttons verstanden.

>> Aber: wenn ich die bekannten Colorbar-Initwerte manuell in die Register
>> pumpe, so erhalte ich tatsächlich ein schönes Testbild (siehe Bild 3 im
>> Anhang).
> Das widerrum ist merkwürdig... vlt. sollte ich mir das nochmal anschauen

Magic, magic ...

>> Erstaulich dabei: obwohl von Hand in die Register geschrieben, erkennt
>> Dein Programm das Pattern und zeigt an: "Testpattern Colorbar".
> Jap :)
>
>> Das führt mich zu der Vermutung, dass Dein "take Picture" eigentlich
>> funktioniert, aber die Kombination der gesendeten "Kamera
>> Initialisieren"-Registerwerte zu einem Bild führt, was auflösungs- oder
>> formatmäßig nicht zu Deiner im Terminal gewählten X-/Y-Auflösung bzw.
>> dem dort gewählten Format des Bildes passt.
>>
> s.o.

Wie gesagt: die Zs.hänge habe ich auch nach Deiner Erklärung noch nicht 
richtig verstanden.

>> Weitere "Bugs" und Verbesserungen hier (bin aktuell zu faul, sie alle
>> ins GIT einzutragen):
>>
>> - Button "read for change" schreibt keine Logmeldung
>> - Buttonbeschriftung solltest Du vereinheitlichen:
>>   Heute:  "read register",
>>           "Read Device Settings",
>>           "Kamera Initialisieren", ...
>>   Besser: "Read Register" oder "Init Camera"
>>           Also einheitliche Schreibweise in Englisch
>> - Die Idee mit dem "List not up to date" nach Schreiboperationen
>>   finde ich richtig gut! Du solltest das aber konsequent durchhalten -
>>   also auch bei "Kamera initialisieren" muss "List not up to date"
>>   gesetzt werden.
>> - Richtig wichtig fände ich unter dem Bild die Anzeige, mit welcher
>>   X- bzw. Y-Auflösung das Bild im Terminal dargestellt wird
>> - Umschalten zwischen den Tabs scheint nicht mehr zu funktionieren:
>>   Im Tab "manueller Modus" wird nach Umschalten noch weiterhin
>>   das rechte Fenster mit dem "take Picture" vom Tab "Settings"
>> angezeigt.
> sehr gut :)

Was meinst Du mit "sehr gut :)"?

Meinst Du:

- ich habe die Verbesserungsvorschläge/Bugbeschreibungen alle verstanden 
und werde sie umsetzen/fixen?
- Oder meinst Du: ich werde die Bugbeschreibungen alle in GIT 
nachtragen?
- Oder meinst Du: sehr gut, dass Dir, Igel1, die Dinge aufgefallen sind, 
aber ich arbeite aktuell an anderen Baustellen im Terminal?

> Zu dem Studio "Workload"... Ich habe da leider nicht den leisesten
> Schimmer was du damit meinst. Also dur brauchst c# windows forms (oder
> so ähnlich) und .net Framework

Immerhin sagt mir das, ich sollte mir neben C# auch etwas "windows 
forms" anlesen. Mann, oh Mann - ich werde hier in diesem Projekt noch 
richtig schlau ;-)

> Edit: sorry Bild nicht gesehen: also im ersten Schritt brauchst du nur
> das oben rechts .net desktop development
> Öffnen kannst du das Projekt einfach über die .sln datei.

Ah supi - das war die entscheidende Info, die ich benötigt habe.
Damit muss ich mir meinen schönen Compi nicht mit 16GB-Mikroschrott 
vollmüllen, sondern "nur" mit 4GB. Und öffnen via .sln-Datei habe ich 
mir inzwischen fast gedacht - danke trotzdem für die Bestätigung.

> viele Grüße
> David

Viele Grüße

Igel1

[David D. (saturi)]

Hallo,
nach nun fast einer Woche funkstille möchte ich nochmal ein 
Lebenszeichen abfragen ;-) ich hoffe ihr verliert nicht die Lust. Bei 
mir war es die letzten zwei Wochen leider wieder sehr turbulent.
ich habe jetzt alles von dir genannte in die Issue liste übernommen und 
versuche mich mit dem Thema der Auflösung nochmal verständlicher 
auszudrücken:

1. die Auflösung die der Imager überträgt und in den Fifo ablegt hängt 
von den Registerwerten ab (Ich denke hier sind wir uns einig)

2. das Terminal liest die entsprechenden Register aus und entscheidet 
anhand einer Switch-Case-Anweisung welche Auflösung (und Farbformat) nun 
eingestellt wird.

3. Mit dem button Sync Camera werden die Auflösung und die BytesPerPixel 
and den uController gesendet, weil dieser bei der Übertragung von einem 
Bild ja die dreifach geschachtelte for-schleife durchläuft, deren 
Austrittskriterien ja die x-Res, y-Res und die BytesPerPixel sind:

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

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

die Variablen die in dieser Funktion übergeben werden, können vom 
Terminal aus angepasst werden (anhand des sync Camera buttons.

ein nicht Übermitteln der Auflösung/des Farbformates sollte aber 
höchstens eine falsche Anzahl der gesendeten Bytes verursachen. Das Bild 
sollte aber dennoch zumindest zum Teil richtig angezeigt werden. (Daher 
weiß ich gerade noch nicht, was jetzt wirklich im Terminal schief läuft.
Morgen habe ich aber wieder etwas Zeit und werde weiter arbeiten.

Bis dahin,

Gruß David

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> nach nun fast einer Woche funkstille möchte ich nochmal ein
> Lebenszeichen abfragen ;-)

Hatte ich gestern Abend auch schon überlegt. ;-)
Aus der Terminal-Programmierung selbst werde ich mit Sicherheit 
raushalten, ich werde aber sicher mittesten, wenn es das was zu testen 
gibt.
Der Kram liegt weiterhin parat, eine Terminalversion oder AVR-Source 
runterladen ist auch kein Problem und der serielle Sniffer lauert auch 
weiterhin auf Daten.
Ich werde in den aktuellen Stand also morgen mal reinschauen und mich 
überraschen lassen.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Bin auch noch mit von der Partie.

Wenn ich einen ganz kleinen Wunsch frei hätte, so würde ich mir manchmal 
etwas schnellere Reaktionen von David auf meine Fragen wünschen ...

Denn manchmal hätte ich Zeit und würde gerne weitermachen, hänge dann 
aber an fehlenden Antworten fest.

Andererseits akzeptiere ich es selbstverständlich, wenn David einfach 
keine Zeit hat - nur manchmal würden mir schon 5 Minuten Invest in eine 
schnelle Antwort sehr helfen.

Die letzten Erklärungen haben mir übrigens sehr geholfen - vorher war 
mir der Sinn des Sync-Camera-Buttons völlig schleierhaft.

Viele Grüße

Igel1



PS: ... ansonsten lese ich mir noch immer ein C# Tutorial durch - hatte 
die letzten 2 Wochen extrem viel zu tun.

[David D. (saturi)]

17 min Reaktionszeit... Ich bin da :D

[Andreas S. (igel1)]

Mist - und ich habe jetzt keine passende Frage ...

Oder vielleicht doch: wie ist das Wetter? ?

[Andreas S. (igel1)]

Und noch eine Bonusfrage:

Du hast Dein Terminalprogramm mit Windows Forms geschrieben, korrekt?
Wenn ja: kannst Du mir eine gute Anleitung zur Einarbeitung (Windows 
Forms unter C#) empfehlen?

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Oder vielleicht doch: wie ist das Wetter? ?

hier laut meinem Balkon-Sensor: pffff.... Schau doch selber. ;)
http://www.roehres-home.de/fhem/fhem.png

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> hier laut meinem Balkon-Sensor: pffff.... Schau doch selber. ;)
> http://www.roehres-home.de/fhem/fhem.png

Ziemlich cool ...
Selbst gebaut oder selbst gekauft?

Viele Grüße

Igel1

[David D. (saturi)]

Also ich habe damals meine ersten Schritte mit youtube gemacht. da gibt 
es tausende Videos wo es schritt für schritt erklärt wird. Einfach mal 
"Windows forms C# deutsch" oder so ähnlich eingeben. Noch mehr gibt es, 
wenn man keine probleme mit dem indischen englisch akzent hat ;-)

Beispielhaft: https://www.youtube.com/watch?v=x-qg5vQwu0s

Allerdings wäre es vermutlich gut, die absoluten Grundlagen zum 
Objektorientierten Programmierung zu kennen. (Klassen, Methoden, 
Objekte, Eigenschaften)

Aktuell "renoviere" ich gerade das Terminal programm. Weil es viele 
Sachen gab, die auf den ersten Blick zwar durch die Programmierung 
gelöst waren, aber Änderungen immer einen riesen Rattenschwanz nach sich 
gezogen haben.

Um das etwas elegenater und schlanker zu Lösen baue ich grade um und 
hoffe, dass ich nichts übersehe ;-)

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Selbst gebaut oder selbst gekauft?

Sensoren Tiny45/FOST02/RFM02, eigenes Protokoll, gebaut um 2009.
Datenerfassung inzwischen mit 433MHz Bridge RFM12/ESP8266 und Umsetzung 
nach MQTT und WLAN. MQTT-Broker und FHEM auf RasPi3. Das Bild erzeugt 
FHEM auf dem RasPi für ein altes 7" Tablett, das noch rumlag. Irgendwann 
dann dem RasPi gesagt, er soll das Bild alle paar Minuten auf meinen 
Webspace legen.
Hängen auch noch Funksteckdosen, PIRs und sonstiger Kram dran, gesteuert 
mit FHEM.
Nichts davon wirklich nötig, aber man will doch was zum Basteln haben...
Die Oberfläche von FEHM auf dem PC dazu...

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

David D. schrieb:
> Also ich habe damals meine ersten Schritte mit youtube gemacht. da gibt
> es tausende Videos wo es schritt für schritt erklärt wird.

Ach ja - Du gehörst schon zu der Generation, die sich alles per Video 
beibringt. Ich gehöre noch zu der Generation, die lieber liest - ich 
persönlich kann mir den Stoff dann ca. 2-3x schneller "reinpfeifen", als 
wenn ich mir Videos anschaue.

Auch fehlt mir dann die Möglichkeit, das Gelernte nochmals schnell 
nachzuschlagen. Auf der anderen Seite ist die Bedienung von grafischen 
Oberflächen im Video zugegeben etwas besser zu verstehen.


Ist halt alles Geschmackssache.

> Einfach mal
> "Windows forms C# deutsch" oder so ähnlich eingeben. Noch mehr gibt es,
> wenn man keine probleme mit dem indischen englisch akzent hat ;-)

Englisch geht einigermaßen bei mir, aber zugegeben: je nach Inder 
verstehe ich wirklich manchmal nur Bahnhof.

>
> Beispielhaft: https://www.youtube.com/watch?v=x-qg5vQwu0s
>

Okay - die 20 Minuten werde ich mir einmal antun, wenn ich heute neben 
Gartenarbeit, Job-Nacharbeit und Kinder-Abi-klar-machen noch etwas Zeit 
finde.

> Allerdings wäre es vermutlich gut, die absoluten Grundlagen zum
> Objektorientierten Programmierung zu kennen. (Klassen, Methoden,
> Objekte, Eigenschaften)

Ich kann Java, C, C++, Perl, Python, verschiedene Assembler-Sprachen - 
das sollte für den Einstieg in C# reichen ;-)   C# scheint mir eh nur 
ein Microsoft-Abklatsch von C++ und etwas Java zu sein - aber trotzdem 
möchte ich es mir halbwegs anständig beibringen. Mein Hauptproblem ist 
eher, dass ich immer mehr die Programmiersprachen durcheinanderwerfe und 
mit Java-Konstrukten in C++ herummache und umgekehrt.

> Aktuell "renoviere" ich gerade das Terminal programm. Weil es viele
> Sachen gab, die auf den ersten Blick zwar durch die Programmierung
> gelöst waren, aber Änderungen immer einen riesen Rattenschwanz nach sich
> gezogen haben.

Ah - das hört sich interessant an.

> Um das etwas elegenater und schlanker zu Lösen baue ich grade um und
> hoffe, dass ich nichts übersehe ;-)

Bin dann mal gespannt auf Deinen überarbeiteten Code (evtl. möchtest Du 
ihn ja einfach in GitHub pflegen bzw. häufig einchecken?)

Bis dahin werde ich mich weiter in C# und Windows Forms 
einlesen/eingucken.

Hier übrigens das Tutorial, das ich nutze:
https://csharp.net-tutorials.com/
Ist für Anfänger sicherlich nicht optimal, für mich aber genau richtig.
Bin jetzt gerade beim Abschnitt "Operators".

Ach hätte ich doch nur mehr Zeit, ich würde es so gerne heute zu Ende 
durcharbeiten - aber that's life ...

Viele Grüße

Igel1

[Andreas S. (igel1)]

Michael U. schrieb:
> Hallo,
>
> Andreas S. schrieb:
>> Selbst gebaut oder selbst gekauft?
>
> Sensoren Tiny45/FOST02/RFM02, eigenes Protokoll, gebaut um 2009.
> Datenerfassung inzwischen mit 433MHz Bridge RFM12/ESP8266 und Umsetzung
> nach MQTT und WLAN. MQTT-Broker und FHEM auf RasPi3. Das Bild erzeugt
> FHEM auf dem RasPi für ein altes 7" Tablett, das noch rumlag. Irgendwann
> dann dem RasPi gesagt, er soll das Bild alle paar Minuten auf meinen
> Webspace legen.
> Hängen auch noch Funksteckdosen, PIRs und sonstiger Kram dran, gesteuert
> mit FHEM.
> Nichts davon wirklich nötig, aber man will doch was zum Basteln haben...
> Die Oberfläche von FEHM auf dem PC dazu...
>
> Gruß aus Berlin
> Michael


Wow - nicht schlecht: Du hast das, wovon ich für unsere Wohnung schon 
immer geträumt habe, scheinbar bei Dir in vollem Umfang umgesetzt. Und 
das vor 10 Jahren, als die Technik noch ziemlich revolutionär war - 
nicht schlecht, Herr Specht!

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Wow - nicht schlecht: Du hast das, wovon ich für unsere Wohnung schon
> immer geträumt habe, scheinbar bei Dir in vollem Umfang umgesetzt. Und
> das vor 10 Jahren, als die Technik noch ziemlich revolutionär war -
> nicht schlecht, Herr Specht!

Schuld waren schon damals die Chinesen... HopeRF tauchte auf, 433MHz 
Funkmodule mit interessanten Funktionen, Temp./Feuchte/Luftdrucksensoren 
mit digitalen Schnittstellen und alles für Preise um 5€/Stück statt 
30-50€.
http://www.avr.roehres-home.de/sensoren/index.html
Dann lange nichts, erst als die ESP-Module kamen habe ich da 
weitergemacht, wieder wiel WLAN für kein Geld -> interessant...
FHEM auf dem RasPi kam erst 2016 dazu, der Rest ist nach und nach 
dazugewachsen. Ich wollte auch noch meine Wärme- und Wasserzähler 
reinnehmen, mit denen ich vor 2 Jahren beglückt wurde, mitlesen ist 
pronzipiell kein Problem, Teile für den CUL für die Anbindung sind auch 
da, mehr ist aber bisher nicht passiert.
Alexa hat auch Einzug gehalten, sie darf zumindest etwas Licht ein- und 
ausschalten, Bridge ist auch da ein ESP.
Die meisten Sachen sind nur aus Neugier mal angetestet, irgendwann kommt 
dann eine unsinnige Idee bei mir oder meinem Bekannten zustande, da wird 
dann was ausgekramt und zwischendurch eben realisiert, oft nur 
halbfertig. ;-)

Davids Kamerageschichte ist ja auch nur deshalb hier dabei. Die kleinen 
AVR sind immernoch meine Freunde, die Cam lag rum und meinen 
C-Kenntnissen schadet das auch nicht, sind ohnehin relativ bescheiden.
Müssen muß ich da ja nichts mehr... :-)

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> Ich wollte auch noch meine Wärme- und Wasserzähler
> reinnehmen, mit denen ich vor 2 Jahren beglückt wurde, mitlesen ist
> pronzipiell kein Problem, Teile für den CUL für die Anbindung sind auch
> da, mehr ist aber bisher nicht passiert.
> Problem, Teile für den CUL für die Anbindung sind auch da,
> mehr ist aber bisher nicht passiert

Was ist denn ein „CUL“?

Viele Grüße

Andreas

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Was ist denn ein „CUL“?

Ich zitiere mal aus dem FHEMWIKI:
"CUL (CC1101 USB Lite) ist ein RF-Gerät im Formfaktor eines USB-Dongles 
mit externer Antenne."

Hat sich bei dem Home-Automatisierungskram irgendwie eingebürgert für 
alle Sachen, die irgendwelche (kommerziellen) Funksensorren einsammeln, 
die Daten dekodieren/aufbereiten und per USB seriell zur Verfügung 
stellen.
Bei mir Arduino Nano mit passendem Funkmodul für 433 oder 868 MHz, meist 
CC1101, manchmal auch RFM12 oder RFM95 o.ä.
Die stecken dann am RasPi-USB und der darf sich mit den Daten rumärgern, 
FHEM und openHAB unterstützen die dann direkt.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

@Michael U.:

Danke für die Erklärungen - wieder was gelernt ...

Viele Grüße

Igel1

[David D. (saturi)]

Ja, ich werde das Terminal Projekt so wie das AVR-Projekt in Github 
ablegen, sodass jede Code-Änderung nachvollziehbar wird.

Dann tust du dich vielleicht leichter. Allerdings würde ich für diesen 
Schritt gerne auf mein "eigenes" Github Projekt umswitchen. Weil das auf 
dem wir aktuell unterwegs sind von einem User hier im Forum ist, der 
ganz am Anfang mal dabei war, dann aber ausgestiegen ist.

Da ich nicht weiß in wiefern man bei so github Projekten von dem "Host" 
ist, würde ich es einfach kurz auf meinen Account ziehen und den Link 
dann hier teilen.

@Michael, ich glaube die Frage habe ich dir schonmal gestellt. Wärst du 
bereit auch auf der Github-Plattform zu kommentieren? (Keiner erwartet 
dass du am Terminal mit codest) Nur die auftretenden Fehler etc. lassen 
sich dann strukturierter bearbeiten.

Gruß

David

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> @Michael, ich glaube die Frage habe ich dir schonmal gestellt. Wärst du
> bereit auch auf der Github-Plattform zu kommentieren? (Keiner erwartet
> dass du am Terminal mit codest) Nur die auftretenden Fehler etc. lassen
> sich dann strukturierter bearbeiten.

ja, kann ich auf jeden Fall machen.
Nimm es mir nicht allzu übel, wenn ich hier manchmal etwas "spitz" 
kommentiere, mir geht nur manchmal durch den Kopf, ob Du Dir das zur 
Lebensaufgabe gemacht hast. Ich habe auch erst jetzt als Rentner mehr 
Zeit, fürher (tm) mit Berufsleben, Familie und Tocher waren auch meine 
Priorotäten andere. Trotzdem habe ich manches elektronische angefangen 
und etliches auch zu Ende gebracht. Wenn ich da so zurückdenke: das 
Westfernsehen führt Stereoton im Fernsehen ein, keine wirklichen Infos 
zum Verfahren hier im Osten verfügbar, nur wenige Randinformatinen und 
die damasl nog Mittgas gesendetet Testsendungen mit Testbild und eben 
dann auch Sereotest. das 2 Träger genutzt werden war schnell klar, ein 
Tonmodul von 5,5MHz auf 5,74MHz abgeglichen und es kam was raus. Bis wir 
rausgefunden haben, daß sie R+L und 2xR senden und das mit passiver 
Matrix zusammengenotet hatten, dauerte dann ein paar Tage. Letztlich 
habe aich aber mit einem Fragwürdigen Drahtverhau neben meinem Raduga 
Farb-TV die Eröffnungssendung von der Funkschau in Stereo gehört. Mit 
etwas Rauschen auf dem rechten Kanal garniert, aber Stereo.
Sorry, aber "alte" Leute reden eben gern "vom Krieg". ;)))

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Michael U. schrieb:
> Sorry, aber "alte" Leute reden eben gern "vom Krieg". ;)))

Schön - oder auch nicht - ich habe mal ein Modul mit Speicher bestellt, 
mal schauen, was dabei herauskommt.

[Dieter F. (Gast)]

Michael U. schrieb:
> Sorry, aber "alte" Leute reden eben gern "vom Krieg". ;)))

Wenn ich von 1945 ausgehe - und wenigstens 15 Jahre annehme, dann musst 
Du knapp 90 Jahre alt sein. Gratuliere.

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Michael U. schrieb:
>> Sorry, aber "alte" Leute reden eben gern "vom Krieg". ;)))
>
> Wenn ich von 1945 ausgehe - und wenigstens 15 Jahre annehme, dann musst
> Du knapp 90 Jahre alt sein. Gratuliere.

Das ist eine Redensart... Und meist ist der erste dann gemeint. ;)
Ansonsten: da fehlen mir noch 22 Jahre. :-)

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Michael U. schrieb:
> Ansonsten: da fehlen mir noch 22 Jahre. :-)

Also - nix Krieg.

[Andreas S. (igel1)]

Michael U. schrieb:
>> Wenn ich von 1945 ausgehe - und wenigstens 15 Jahre annehme, dann musst
>> Du knapp 90 Jahre alt sein. Gratuliere.
>
> Das ist eine Redensart... Und meist ist der erste dann gemeint. ;)
> Ansonsten: da fehlen mir noch 22 Jahre. :-)

Hui - gut gehalten, Michael (vor allem mit Blick auf Deine 
elektronischen a jour - Kenntnisse)!

@David: kannst den Speed hier aus dem Projekt rausnehmen  Michael wird 
uns noch ein paar Jahrzehnte erhalten bleiben  ;-)

Viele Grüße

Igel1

[Andreas S. (igel1)]

David D. schrieb:
> Dann tust du dich vielleicht leichter.

Och, ich finde gar nicht, dass ich mich schwer tue :-)
Ich habe halt einfach nur suuuper wenig Zeit, weil ich irgendein 
verrücktes internationales Chaos-Projekt mit dutzenden von Beteiligten 
schon seit vielen Monaten am Fliegen halten muss.

Und für den Flickenteppich an freien Zeitscheiben, der mir neben Arbeit 
und Familie zur Verfügung steht, halte ich mich hier ziemlich gut - 
finde ich wenigstens :-)

> Allerdings würde ich für diesen
> Schritt gerne auf mein "eigenes" Github Projekt umswitchen. Weil das auf
> dem wir aktuell unterwegs sind von einem User hier im Forum ist, der
> ganz am Anfang mal dabei war, dann aber ausgestiegen ist.

Yep - geht klar. Schade, dass uns Olli Z. seinerzeit von der Stange 
gegangen ist - der war auch schön engagiert und sehr gründlich. Hätte 
gut hier in den Club der toten AVR'ler reingepasst.

Viele Grüße

Igel1

[David D. (saturi)]

ja... hatte sogar versucht Olli per E-Mail zu reaktivieren. Eine nette 
antwort kam auch, aber leider keine Folgetaten ... naja kann man nix 
machen.
Ich finde das wir 3,5 uns auch gut schlagen! :)

@Michael deine spitzen Kommentare sind dir schon verziehen und deine 
Geschichten sind auch immer interssant. Immerhin kenne ich noch Stereo 
und Röhrenbildschirme ;-D

setzte mich jetzt dran und morgen hoffe ich euch den link incl. source 
code schicken zu können

heute war erstmal Geburtstag feiern dran ;-)

in diesem Sinne bis morgen!

Gruß
David

Edit:
dennoch muss ich anscheinend in meiner Hardware noch nach was suchen
camera anstecken mim terminal verbinden, read device settings klicken: 
läuft durch. nochmal klicken läuft durch, nochmal klicken läuft bis 
register 31. kamera abstecken, terminal neustarten, kamera anstecken, 
verbinden und read device settings klicken, läuft bis register 180
...

oder ich warte nochmal bis wir alle im gleichen projektstatus sind (mit 
dem neuen Github projekt)

[Andreas S. (igel1)]

David D. schrieb:
> ja... hatte sogar versucht Olli per E-Mail zu reaktivieren. Eine nette
> antwort kam auch, aber leider keine Folgetaten ... naja kann man nix
> machen.
> Ich finde das wir 3,5 uns auch gut schlagen! :)

Ja, finde ich auch.

> heute war erstmal Geburtstag feiern dran ;-)

Na dann herzlichen Glückwunsch, David!
Du holst also auch altersmäßig kräftig auf!

> Edit:
> dennoch muss ich anscheinend in meiner Hardware noch nach was suchen
> camera anstecken mim terminal verbinden, read device settings klicken:
> läuft durch. nochmal klicken läuft durch, nochmal klicken läuft bis
> register 31.

Yep - da ist bei Dir noch etwas faul.
Klemm vielleicht mal den LogicAnalyzer ab und teste dann nochmsls.
Oder bestelle Dir einen Haufen Nanos - die laufen bei mir schön rund.

> oder ich warte nochmal bis wir alle im gleichen projektstatus sind (mit
> dem neuen Github projekt)

Auch 'ne Möglichkeit ...

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

da habe ich doch glatt die Geburtstagsmeldung überlesen, also:
nachträglich alles Gute, auch Du kannst also das älterwerden offenbar 
nicht verhindern. ;-)

Hier scheint ja die Sonne, also ist Ruhe im Thread.
OT:
Mich verwirren im Moment mal wieder die chinesichen Freunde:
auf dem aktuellen ESP32-OV2640 Modul ist ein Powerbank-IC IP5306 drauf, 
das war auch schon auf der kleinen M5Stack-Cam drauf.
Chinesischens Datenblatt ist verfügbar, die Übersetzung ...nja... 
ausreichend. Soweit, so gut.
Das IC hat 3 Ausgänge für LEDs zur Ladezustandanzeige, die sind bei der 
M5Stack-Cam unbeschaltet, ok.
Witzigerweise sind sie beim neuen Modul beschaltet, als I2C Bus, und 
werden auch wirklich in der Software angesprochen.
In einem Forum habe ich jetzt zumindest ein "Datenblatt" dazu gefunden. 
Es ist eine Custom-Version IP5306_I2C. An der Bezeichnung auf den beiden 
ICs durch nichts zu unterscheiden...
Man kann den Ladezustand auslesen, Abschaltspannung und Ladestrom 
einstellen, abfragen, ob viel oder wenig Last am Ausgang hängt, den 5V 
Boost-Converter abschalten und noch ein paar Sachen, die ich noch nicht 
ganz verstanden habe.
Völlig OT:
Zur Volksbelustigung hänge ich die deutsche "Übersetzung" einfach mal 
an, die Fachleute hier werden die Bit-Beschreibungen der Register sicher 
auf Anhieb verstehen. :-)

Gruß aus Berlin
Michael

[Nosnibor (Gast)]

Michael U. schrieb:
> Es ist eine Custom-Version IP5306_I2C. An der Bezeichnung auf den beiden
> ICs durch nichts zu unterscheiden...

Je nachdem, wie die LEDs beschaltet und genutzt werden, könnte das ja 
rückwärtskompatibel sein. Mit den open-collector-Ausgängen am I2C kann 
man ja genausogut LEDs treiben. Wenn die LEDs nur auf Anforderung 
(Taster gedrückt) leuchten sollen, muß der Chip gar nicht wissen, wie er 
beschaltet ist (bis jemand den Taster drückt)...

[Michael U. (amiga)]

Hallo,

Nosnibor schrieb:
> Je nachdem, wie die LEDs beschaltet und genutzt werden, könnte das ja
> rückwärtskompatibel sein.

da habe ich auch kurz drüber nachgedacht. Eigentlich ist das ja ein 
Powerbank-IC, wo eben mit dem Taster der 5V-Wandler gestartet wird und 
mit den LEDs der Ladezustand angezeigt wird.
Vielleicht teste ich das mal mit der anderen Cam-Version, wo der drauf 
ist. Sagt aber dann auch nur bedingt was aus, die Pins dort sind ja 
unbeschaltet und aus der IC-Bezeichnung ist nichts rauszulesen. Ist 
einfach nur interessant das Teil...

Gruß aus berlin
Michael

[David D. (saturi)]

Sooo auf ins Wochenende.

Eigenes Github Projekt mit beiden Code-Strukturen ist jetzt online:
https://github.com/Saturi92/OV7670_AVR

Pflege heute Abend noch die ToDo-Liste ein und dann könnten wir da auch 
Lösungen erarbeiten ;-)

[David D. (saturi)]

Andreas S. schrieb:
> Klemm vielleicht mal den LogicAnalyzer ab und teste dann nochmsls.
> Oder bestelle Dir einen Haufen Nanos - die laufen bei mir schön rund.

leider habe ich immernoch keinen zuverlässigen logic Analyzer -.- und 
mein "workaround" funktioniert leider auch nicht mehr?! warum auch 
immer, aber das javatool erkennt die HW nicht mehr :/ war eh immer nur 
ein Glücksgriff wenn es dann eins von zehn malen tat.


die nanos würde ich glatt machen... aber jetzt habe ich doch gerade das 
shield für den Uno gelötet :D da würde ich mir eher nochmal einen uno 
bestellen :D

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Eigenes Github Projekt mit beiden Code-Strukturen ist jetzt online:
> https://github.com/Saturi92/OV7670_AVR

den Link habe ich mir erstmal als aktuell hingelegt.

David D. schrieb:
> die nanos würde ich glatt machen... aber jetzt habe ich doch gerade das
> shield für den Uno gelötet :D da würde ich mir eher nochmal einen uno
> bestellen :D

richtig erklären kann ich mir eigentlich nicht, was da bei Dir passiert. 
Ich habe es ja aus mechanischen Gründen auch als Uno-Shield 
zusammengelötet. Hatte es vorher mit Dupount-Kabeln an einem Nano, das 
war mir aber wegen des Drahtverhaus zu wacklig um es zwischendurch 
einfach weglegen zu können.
Due kannst ja nochmal Bilder von Deinem Aufbau posten, vielleicht fällt 
mir irgendwas auf.
LA habe ich im Moment nicht dran, da muß ich bei meinem Eigenbau auch 
etwas aufpassen, weil die Eingangsschaltung 100k PullUp gegen die 
internen 5V hat.
Da passiert zwar nichts, das hat mir aber schon die Pegel versaut, wenn 
ich z.B. vergesse, den an USB zu stekchen und mit Spannung zu versorgen.
Es läuft das mit dem UNO genauso wie mit dem nano, aus AVR-Sicht sind 
die ja im Prinzip identisch.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

David D. schrieb:
> Andreas S. schrieb:
>> Klemm vielleicht mal den LogicAnalyzer ab und teste dann nochmsls.
>> Oder bestelle Dir einen Haufen Nanos - die laufen bei mir schön rund.
>
> leider habe ich immernoch keinen zuverlässigen logic Analyzer -.- und
> mein "workaround" funktioniert leider auch nicht mehr?! warum auch
> immer, aber das javatool erkennt die HW nicht mehr :/ war eh immer nur
> ein Glücksgriff wenn es dann eins von zehn malen tat.
>
>
> die nanos würde ich glatt machen... aber jetzt habe ich doch gerade das
> shield für den Uno gelötet :D da würde ich mir eher nochmal einen uno
> bestellen :D

Gerade heute kamen 2 LA bei mir aus dem Reich der Mitte an - Stück 5 
EUR.
Ich denke, diesen Invesr solltest Du Dir auch einmal gönnen.

Und bevor Du jetzt noch lange nach dem Fehler suchst, würde ich die 
Schaltung mit einem für DebugWire präparierten Nano oder meinetwegen 
auch einem UNO nochmals aufbauen und Fertig.

Ich selber hätte gerne jetzt am Wochenende meine ersten C# Gehversuche 
gemacht, habe mir aber einen Infekt eingefangen und bin leider ziemlich 
platt. Wünsche Euch gute Fortschritte!

Igel1

[Andreas S. (igel1)]

@David: Tschuldigung für den letzten Post - klingt sehr arrogant.
Bin halt aktuell ziemlich matsche in der Birne.

Da kommt mir in den Sinn: was mache ich mit 2 LA?
Darf ich Dir einen der beiden LA als Wiedergutmachung schenken?

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

@Andreas: erstmal gute Besserung.
Sind das die üblichen 8-Kanal/24MHz-Teile?
Als Software dann die von Sigrok?

Ich denke also wiedermal darüber nach, bei meiner AVR-Firmware das 
Protokoll anzupassen, weil ja meine Eigenbau 8-Kanal/80MHz Hardware 
stabil läuft.
Wollte ich schon immer mal, weil ich die Protokolldecoder (das Einzige, 
was fehlt) wohl sowieso nicht mehr in die alte VB6-Software einbaue.
Zumal ich den I2C-Decoder gerade für einen anderen "Hack" brauchen 
würde...

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> Hallo,
>
> @Andreas: erstmal gute Besserung.

Danke!

> Sind das die üblichen 8-Kanal/24MHz-Teile?

Yep.

> Als Software dann die von Sigrok?
>

Keine Ahnung, muss ich mich noch mit beschäftigen, wenn der Kopf wieder 
klar ist. Aber vermutlich hast Du recht.

> Ich denke also wiedermal darüber nach, bei meiner AVR-Firmware das
> Protokoll anzupassen, weil ja meine Eigenbau 8-Kanal/80MHz Hardware
> stabil läuft.
> Wollte ich schon immer mal, weil ich die Protokolldecoder (das Einzige,
> was fehlt) wohl sowieso nicht mehr in die alte VB6-Software einbaue.
> Zumal ich den I2C-Decoder gerade für einen anderen "Hack" brauchen
> würde...

Gut, bräuchte dann nur noch die Lieferadresse.
Sobald ich wieder fit bin, geht das Dingen auf die Reise.

>
> Gruß aus Berlin
> Michael

Gruß aus dem Bett

Igel1

[David D. (saturi)]

Hallo, Bilder vom Aufbau folgen heute Nachmittag.

@Igel das wollte ich wirklich nicht mit meinem Gejammer erreichen... 
dein Angebot ist sehr sehr nett, aber das kann ich nicht annehmen. einen 
Investor von 5€ werde ich schon stemmen können. Habt ihr da gute 
Erfahrungen? Und evtl. Nen Link?

Hatten wir genau das Thema nicht schon vor zwei Monaten? Ich meine schon 
mal gefragt zu haben... wenn ja, tut es mir leid.

Ich habe jetzt mal den Level shifter getauscht (weil der das einzige 
Bauteil ist, dass ich mehrfach habe. Lief auf Anhieb besser, hat jetzt 
aber die gleichen Probleme nur seltener... ob es der Level shifter sein 
kann? Aber dann müsste der Arduino doch Fehler auswerfen?
Werde mir jetzt noch nen zweiten UNO bestellen und heute Abend ne 
Platine für den Nano löten. Sobald ich von dem Frühlingsmarkt zurück 
bin, wo meine Dame hinmöchte -.- :D

@Igel gute Besserung, mich hat es diese Woche auch halb erwischt.

Und den Invest für einen kleinen LA werde ich jetzt auch tätigen...

Und einen nano auf debug umbauen werde ich auch versuchen.

Da hab ich mir wieder viel vorgenommen für ein paar freie Stunden. 
Leider spinnt mein Visual Studio gerade.  Sonst könnte ich euch schon 
den neuen release zur Verfügung stellen.

Wünsche euch einen schönen Sonntag.

[Andreas S. (igel1)]

David D. schrieb:
> Hallo, Bilder vom Aufbau folgen heute Nachmittag.
>
> @Igel das wollte ich wirklich nicht mit meinem Gejammer erreichen...
> dein Angebot ist sehr sehr nett, aber das kann ich nicht annehmen. einen
> Investor von 5€ werde ich schon stemmen können. Habt ihr da gute
> Erfahrungen? Und evtl. Nen Link?

https://www.aliexpress.com/item/USB-Logic-Analyzer-24M-8CH-Microcontroller-ARM-FPGA-Debug-Tool-24MHz-16MHz-12MHz-8MHz-4MHz-2MHz/32960102049.html

Kannst Du ruhig von mir annehmen: ist ja kein Allmosen, sondern einfach 
nur 'ne kleine Aufmerksamkeit von mir. Ich habe hier im Forum auch schon 
so viele tolle Sachen geschenkt bekommen - warum nicht auch einmal 
anderen eine Freude machen? Wenn Du den LA aus China bestellst, musst Du 
halt 3 Wochen warten - so lange hat's jedenfalls bei mir gedauert.

>
> Hatten wir genau das Thema nicht schon vor zwei Monaten? Ich meine schon
> mal gefragt zu haben... wenn ja, tut es mir leid.
>
> Ich habe jetzt mal den Level shifter getauscht (weil der das einzige
> Bauteil ist, dass ich mehrfach habe. Lief auf Anhieb besser, hat jetzt
> aber die gleichen Probleme nur seltener... ob es der Level shifter sein
> kann?

Ja schon, ich habe den hier:
https://www.ebay.de/itm/3x-I2C-5V-3-3V-4-Kanal-Level-Shifter-Konverter-Pegelwandler-Arduino-Raspberry/253048505379

Extra in DE bestellt, weil ich nicht lange warten wollte.
Und immer schön auf die "Polungsrichtung" achten.

> Aber dann müsste der Arduino doch Fehler auswerfen?
> Werde mir jetzt noch nen zweiten UNO bestellen und heute Abend ne
> Platine für den Nano löten. Sobald ich von dem Frühlingsmarkt zurück
> bin, wo meine Dame hinmöchte -.- :D
>
> @Igel gute Besserung, mich hat es diese Woche auch halb erwischt.
>
> Und den Invest für einen kleinen LA werde ich jetzt auch tätigen...
>
> Und einen nano auf debug umbauen werde ich auch versuchen.
>
> Da hab ich mir wieder viel vorgenommen für ein paar freie Stunden.
> Leider spinnt mein Visual Studio gerade.  Sonst könnte ich euch schon
> den neuen release zur Verfügung stellen.
>
> Wünsche euch einen schönen Sonntag.

Dito.

Igel1

[David D. (saturi)]

Guten Abend,

anbei die Bilder vom derzeitigen Aufbau. Meine LvL-Shifter unterscheiden 
sich von deinen gezeigten jetzt eigentlich nur in der Anzahl der Ein- 
bzw. Ausgänge.

> 
https://www.aliexpress.com/item/USB-Logic-Analyzer-24M-8CH-Microcontroller-ARM-FPGA-Debug-Tool-24MHz-16MHz-12MHz-8MHz-4MHz-2MHz/32960102049.html

ist bestellt, allerdings bei E-Bay und sollte diese Woche noch kommen 
;-) dennoch vielen Dank für das Angebot, das weiß ich wirklich zu 
schätzen :-))


Der nano läuft auch im Debug-Modus... war ja einfach... musste nur einen 
Kondensator raus nehmen (fälschlicherweise hab ich zuerst einen falschen 
Entfernt, der dann verschwunden ist :D läuft trotzdem o.O :D

Gruß
David

[Andreas S. (igel1)]

David D. schrieb:
> Guten Abend,
>
> anbei die Bilder vom derzeitigen Aufbau. Meine LvL-Shifter unterscheiden
> sich von deinen gezeigten jetzt eigentlich nur in der Anzahl der Ein-
> bzw. Ausgänge.
>
>>
> 
https://www.aliexpress.com/item/USB-Logic-Analyzer-24M-8CH-Microcontroller-ARM-FPGA-Debug-Tool-24MHz-16MHz-12MHz-8MHz-4MHz-2MHz/32960102049.html
>
> ist bestellt, allerdings bei E-Bay und sollte diese Woche noch kommen
> ;-) dennoch vielen Dank für das Angebot, das weiß ich wirklich zu
> schätzen :-))

Schade - ich hätte Dir auch gerne eine Freude gemacht.

> Der nano läuft auch im Debug-Modus... war ja einfach... musste nur einen
> Kondensator raus nehmen (fälschlicherweise hab ich zuerst einen falschen
> Entfernt, der dann verschwunden ist :D läuft trotzdem o.O :D

Na Du hast Nerven ...
Bevor es später zu unerklärlichen Seiteneffekten kommt, würde ich 
dringend nachforschen, welchen Kondensator Du da versehentlich entfernt 
hast.
Das würde ich an Deiner Stelle wirklich dringend(!) tun, denn auf den 
Boards ist kein einziges Bauteil zuviel drauf und jedes Bauteil hat 
Nebenwirkungen, wenn es fehlt.

Viele Grüße

Igel1

[David D. (saturi)]

Andreas S. schrieb:
> Bevor es später zu unerklärlichen Seiteneffekten kommt, würde ich
> dringend nachforschen, welchen Kondensator Du da versehentlich entfernt
> hast.

Das hatte ich natürlich sowieso vor ;-)

Es handelt sich um den 0,1uF der direkt neben der Spannungsregler (5V 
sitzt), parallel geschaltet zum 4,7uF.

Kann mir einer von euch Elektronikspezialisten den schaltungstechnischen 
Sinn davon erklären? warum setzte ich einen kleinen Kondensator parallel 
zu einem um den Faktor 50 größeren?

Hat das was mit der Polungrichtung des größeren zu tun der nur Ladungen 
in eine Richtung aufnehmen kann?


@Igel um dich zu beruhigen: Er ist wieder an Ort und Stelle ;-)
 Und mein Visual studio läuft auch wieder... aber leider ist die 
Mittagspause schon wieder vorbei...


Bis heute Abend!

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Kann mir einer von euch Elektronikspezialisten den schaltungstechnischen
> Sinn davon erklären? warum setzte ich einen kleinen Kondensator parallel
> zu einem um den Faktor 50 größeren?

Weil die größeren Kapazitäten bei höheren Frequenzen schlechtere 
Eigenschaften haben (Stichwort Serieninduktivität und ESR).
Der größere liefert die Energie bei sehr schnellen Spannungsänderungen 
zu langsam, der kleinere alleine hätte zu wenig Kapazität und längere 
Einbrüche zu überbrücken.
Eigentlich spielen noch mehr Faktoren eine Rolle, für eigene 
Einschätzungen für die Notwendigkeit reicht das so aber durchaus aus.
Siehe auch die Dauerdiskussionen, warum an den µC oder an getaktete ICs 
allgemein nahe an die Spannungsanschlüsse Kondensatoren gehören.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hallo David,

es ist, wie Michael gesagt hat. Je nach Deinem "Background" empfehle ich 
ggf. etwas Lektüre dazu. Ich selber hatte früher jedenfalls eine ganze 
Weile benötigt, um die Zs.hänge auch nur einigermaßen zu verstehen.

So richtig "klick" gemacht hat es bei mir erst, als ich mich im Studium 
mit komplexer Wechselstromrechnung beschäftigen durfte (@David: hast Du 
das ebenfalls in Deinem Studium/Ausbildung gehabt? Das mit 1/jwC bzw. 
jwL ... ). Erst danach habe ich wirklich verstanden, warum ein RC-Kreis 
dämpft, oder was Resonanz bedeutet oder welche Auswirkungen eine 
Induktivität in Zs.hang mit einem Kondensator hat.

Wenn Du es also ganz genau wissen willst, empfehle ich diese Seiten:
https://elektroniktutor.de/elektrophysik/zeiger.html
https://elektroniktutor.de/bauteilkunde/kondens.html

Wenn's Dir nicht so genau drauf ankommt, hier eine halbwegs 
"Laienkonforme" Erklärung:
https://rn-wissen.de/wiki/index.php/Abblockkondensator

Im ersten "Weiterführenden Weblink" gibt's die volle Theorie-Breitseite 
...
Im zweiten gibt's ein nettes YouTube-Video, was die Auswirkungen eines 
fehlenden 100nF Kondensators sehr eindrucksvoll zeigt.

Etwas anspruchsvoller sind dann schon diese Links hier:
http://www.g-qrp-dl.de/Projekte/bypass/bypass.pdf

Oder - wieder einmal supergenial - die Seite von Lothar Miller (er ist 
meiner Meinung nach einer der genialsten Elektroniker, die hier im Forum 
herumhüpfen - frage mich immer, wie man ein so universelles Wissen im 
Bereich FPGA und Elektronik allgemein auftürmen kann):
http://www.lothar-miller.de/s9y/categories/14-Entkopplung

Viele Grüße

Igel1

PS: hoffentlich habe ich mit meinem dröhnenden Schädel nicht zu viel 
Mist geschrieben.

[David D. (saturi)]

Guten Abend,

vielen Dank für die Informationen, @Michael das war genau das was ich 
wissen wollte.

@Igel vielen Dank für die Zusammenstellung der Links. Diese Seite (ich 
spreche von den ersten Links) ist wirklich gut um das Wissen nochmal 
aufzufrischen.Ja ich hatte die komplexe Wechselstrom Lehre, allerdings 
im ersten bzw. zweiten Semester. Damals (vor 6 Jahren) hatte ich aber 
leider überhaupt keinen praktischen Bezug dazu. Beim durchlesen der 
Seiten kamen mir die Formeln aber noch sehr bekannt vor. Für morgen habe 
ich mir schon die nächsten Lese-Zeichen gesetzt. Jetzt Rückblickend 
macht alles so viel mehr Sinn :D...

Da noch keiner mit dem Morgenstern über meine Lötkünste hergefallen ist 
nehme ich entweder an, dass ihr noch keine Zeit hattet die Bilder zu 
betrachten oder mir keine groben Schnitzer unterlaufen sind (ist 
natürlich aus der Ferne nur schwer zu beurteilen).

Ich habe gerade eine neue Version vom Terminal hochgeladen. Mit vielen 
Bug-Fixes wodurch sich die Anzahl der Fehlermeldungen deutlich reduziert 
haben sollte. (Also nicht nur die Meldungen ^^)

Da ich die Probleme vom Read Device Settings ebenfalls beim Write Device 
Settings habe, würde es mich interessieren, ob die bei euch auch 
durchlaufen.

Wünsche euch einen schönen Abend.

Gruß David

[Andreas S. (igel1)]

Prüfe nochmals Deine Levelshifterbeschaltung:
- 5V an HV ?
- 3,3V an LV ?
- Beide Seiten an GND angeschlossen ?
- Optimalerweise alle GND-Leitungen sternförmig am GND-Pol des 
Versorgungskondensators zusammenführen

Mehr fällt mir gerade auch nicht ein.
Aus den Fotos kann man die Verschaltung leider nicht genau 
zurückverfolgen - es wird zu vieles verdeckt und es wäre auch mit 
optimalen Fotos wahnsinnig aufwändig.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> - Beide Seiten an GND angeschlossen ?
Die üblichen Levelshifter mit MosFET und den 2 Widerständen brauche GND 
garnicht, es ist einfach nur durchverbunden, wenn überhaupt vorhanden.
Ich habe auch welche, wo es keinen GND gibt.

> - Optimalerweise alle GND-Leitungen sternförmig am GND-Pol des
> Versorgungskondensators zusammenführen
Wie Du schon schreibst optimalerweise. Allerdings sind mir bisher da bei 
dieser Art Schaltungen im AVR-Umfeld (nur digitale Komponenten, keine 
AD-Wandlung, kein Audio usw.), den relativ kurzen Leitungen (da zähle 
ich aich noch 10cm Dupontkabel dazu) und Frequenzen um 10MHz noch nie 
passiert.
Kontaktunsicherheiten speziell durch Dupontkabel, Litzen, wo Drähte 
abstanden und benachbarte Sachen berührten, Zinnbrücken, die man kaum 
sieht usw. dagegen öfter. Ich löten Lochrasterkram generell mit 0,4er 
Blankdraht und, wenn nötig ein Stück Gewebeschlauch, für die 
Spannungsversorgung.
Der Rest ist Warpdraht, eine Sorte zu finden, wo die Isolierung sich 
1-2mm sauber zurückzieht, wenn man die Lötspitze senkerecht an den 
abgeschnittenen Draht hält, ist mühsam, aber möglich. ;)
Die Sorte, wo Du mir das Bienchen aberkannt hast, ist leider eine, wo 
das nicht schön klappt...
Sein Problem wird sein, rauszufinden, wobei sich der Kram aufhängt.
Wenn man mit seinem Aufbau etwas "rumrandaliert" wenn der in Betrieb ist 
darf nichts aussetzen, sonst ist da Ursachenforschung angesagt...

Gruß aus Berlin
Michael

[David D. (saturi)]

Ein hoch auf den Händler und den fleißigen Paketboten!

Jetzt muss ich das Ding nur noch zum laufen bringen und dann schauen wir 
mal wo es klemmt

Aus Spaß ist auch ein stm32 dabei ;-) für die ganz ganz ganz weite 
Zukunft

[Andreas S. (igel1)]

David D. schrieb:
> Ein hoch auf den Händler und den fleißigen Paketboten!
>
> Jetzt muss ich das Ding nur noch zum laufen bringen und dann schauen wir
> mal wo es klemmt

Bitte schreibe ein bisschen Doku dazu - wenn ich wieder gesund bin, 
möchte ich meine LA's ja auch ans Laufen bringen und könnte dann ggf. 
von Deinen Erfahrungen lernen.

> Aus Spaß ist auch ein stm32 dabei ;-) für die ganz ganz ganz weite
> Zukunft

Ah - der Mann kommt langsam zur Vernunft :-)

Konnte inzwischen Deinen Code aus GitHub in mein VS clonen und 
erfolgreich aus Laufen bringen - wegen Bettlage aber noch ohne 
angeschlossenen AVR. Der für Dich spannende Teil, fehlt also leider 
noch.

Habe gerade bemerkt, dass Dein Code mit Events vollgestopft ist und in 
meinem Tutorial das Thema "Events" nicht vorkam. So'n Pech - jetzt mit 
dem Düllekopp passt aktuell leider nicht viel in den Kopf außer das 
Event "schlafen".

Anyway - kommt Zeit, kommt Rat.

Viele Grüße

Igel1

[David D. (saturi)]

An Events habe ich mich sehr sehr lange auch nicht ran getraut (deshalb 
gibt es auch immernoch Altlasten in diesem Projekt, die mit einem Event 
wesentlich eleganter zu lösen wären. Folge Seiten haben mir sehr 
geholfen, die kann ich wirklich nur empfehlen:

https://www.youtube.com/watch?v=jQgwEsJISy0
(ja ein Video... Aber für den ersten Anlauf und den ersten "Kontakt" mit 
events wirklich sehr zu empfehelen)

http://www.hinzberg.net/csharp/csharp/csharp/threadevents.html
Hier die beiden Kapitel Threads u. Events und Threads u. Invoke
(Nach diesem Beispiel wirst du sie auch bei mir im Code finden)

und noch was über delegates:
https://www.tutorialspoint.com/csharp/csharp_delegates.htm

[David D. (saturi)]

Soo noch kurz vor dem Schlafengehen den LA zum laufen gebracht... Da 
kann ich die Software Sigrok (bzw. PulseView) nur empfehlen. Das sieht 
auf den ersten Blick richtig gut aus und um Welten besser, als alles was 
ich bisher hatte:

hier die Anleitung:
https://sigrok.org/wiki/Windows

für den LA brauchen wir nur den PulseView. Im gesamten Sigrok paket ist 
aber die "zagdig.exe" drin, die man braucht um den LA mit dem Win-USB 
driver zu verknüpfen. Danach läuft es!


Dann kann ich mich morgen Abend endlich an die Fehlerursachenforschung 
machen. Auch wenn morgen erstmal ein langer Tag bevorsteht -.-


bis denne.

Gruß
David

[Andreas S. (igel1)]

@David: Danke für die Links - so etwas hilft immer sehr.

Habe Delegates und Events inzwischen halbwegs kapiert (soweit mein Kopf 
das aktuell zulässt).

Habe nun erstmals in Deinen Code geguckt - fürchte, es wird ein Weilchen 
dauern, bis ich da durchblicke, denn es sind ja doch ein paar Zeilchen.

Immerhin habe ich C#-mäßig kaum Konstrukte entdeckt, die ich 
sprachenmäßig nicht verstanden habe. Die Tutorials scheinen besser 
angeschlagen zu haben, als die Medizin, die ich aktuell reinkomme - das 
macht schon mal Mut.

Jetzt kann ich mich der Programmlogik widmen, wobei mir ein paar 
grundsätzliche Worte von Dir, David, zur Funktionsweise sicherlich das 
Reverse-Engineering etwas vereinfachen könnten.

Beabsichtigst Du in den kommenden Tagen noch größere Änderungen am 
Terminal-Code? Sollte ich einen eigenen Branch in GitHub aufmachen, 
damit wir dann ggf. Codemerges machen können? Keine Ahnung, wie das in 
VS funktioniert ... Aber das ist auch erst einmal nur Prio2.

Viele Grüße

Igel1

PS: und Danke für die Erläuterungen zur LA-Inbetriebnahme!

[David D. (saturi)]

> Habe nun erstmals in Deinen Code geguckt - fürchte, es wird ein Weilchen
> dauern, bis ich da durchblicke, denn es sind ja doch ein paar Zeilchen.
Ja mittlerweile hat sich da was angehäuft.
Ich hoffe du hast schon das Form gefunden und kannst es im Ansicht 
designer sehen. dann kannst du einfach auf einen button doppelklicken 
und er führt dich zu dem Startpunkt und von da aus würde ich mich mit 
rechtsklick definition anzeigen am code entlanghangeln. Ich werde dir 
auch am Wochenende etwas mehr zusammenschreiben. erstmal würde ich sagen 
sind die beiden "Klassen" (im weitesten Sinne) OV7670_Device und 
Form_Terminal die wichtigsten in denen alles abläuft.

> Immerhin habe ich C#-mäßig kaum Konstrukte entdeckt, die ich
> sprachenmäßig nicht verstanden habe.

das ist gut, da ich ja auch kein "gelernter" Programmierer bin fehlt mir 
wahrscheinlich auch der ein oder andere Kniff mit dem es sich besser 
machen ließe. Aber wir sind ja zum Lernen hier ;-)

> Beabsichtigst Du in den kommenden Tagen noch größere Änderungen am
> Terminal-Code? Sollte ich einen eigenen Branch in GitHub aufmachen,
> damit wir dann ggf. Codemerges machen können? Keine Ahnung, wie das in
> VS funktioniert ... Aber das ist auch erst einmal nur Prio2.
Ja im Grunde halte ich das für eine Gute Idee, auch wenn ich das noch 
nie gemacht habe. Auch cool finde ich es, dass du Github anscheinend ins 
VS eingebunden hast, das werde ich mir mal anschauen. Da ich es ja 
ursprünglich nur für den uC code gedacht hatte, habe ich "Github 
Desktop" verwendet. Damit kann man dann einfach einen comit mit 
anschließendem Push ausführen. Aber das geht bestimmt auch aus dem VS.
Gute Besserung weiterhin.
-----------------------------------


Back to Topic:"Read Device Settings stoppt mitten drin"
habe jetz Tx,Rx,SIOC,SIOD (alles direkt am uC) am LA hängen. Folgende , 
angehängte Beobachtung:
rx kommt noch auf dem uC an (zumindest auf der rx Leitung) danach 
passiert nichts mehr, kein tx, kein SIOC, kein SIOD.
Damit gehe ich davon aus, dass das Problem keins ist, welches durch 
meine adapter Platine und die Lötkünste verbunden ist. Teilt ihr diese 
Ansicht?

Da ich das Problem auf beiden Uno-Boards habe, gehe ich weiterhin davon 
aus, dass es sich nicht um ein defektes Board handelt.

Bleiben zwei Möglichkeiten:
- Es liegt am Code... Warum um alles in der Welt funktioniert der dann 
bei euch?!

- Es scheint ein generelles Problem mit dem Uno zu geben.
Das wäre zu Überprüfen mit einem Adapter board für den Nano, dass ich 
mir am Wochenende basteln könnte.

Gruß
David


PS: dieser LA und die Software sind ein Traum!
ich kann mir sowohl die UART symbole als auch die I2C Symbole anzeigen 
lassen. (Für euch vlt. nichts neues) Aber ich schwebe auf Wolke 7 :D

[Andreas S. (igel1)]

Habe gerade Terminal-Programm V0.12 mit meiner AVR-Codeversion (keine 
Ahnung, welche Version es war) zusammen kurz getestet:

- Read Device Settings funktioniert zuverlässig und stabil
- read register funktioniert zuverlässig und stabil
- write register funktioniert zuverlässig und stabil

Drücke dann nacheinander "Camera initialisieren", "get Camera", "sync 
Camera", "take Picture". Das Ergebnis siehst Du im Anhang.

Neue Terminal-Version sieht chic aus.
Folgende Probleme hatte ich:

- Die Tabelle "Device Settings" ist zu schmal - es geht Info verloren - 
siehe Bild im Anhang

- Gleiches gilt vermutlich für "Loaded Settings"

Viele Grüße

Igel1

[Andreas S. (igel1)]

David D. schrieb:

> Ich hoffe du hast schon das Form gefunden und kannst es im Ansicht
> designer sehen.

Yep - läuft.

> dann kannst du einfach auf einen button doppelklicken
> und er führt dich zu dem Startpunkt

Yep - klappt.

> und von da aus würde ich mich mit
> rechtsklick definition anzeigen am code entlanghangeln. Ich werde dir
> auch am Wochenende etwas mehr zusammenschreiben.

Au ja - das wäre klasse.

> erstmal würde ich sagen
> sind die beiden "Klassen" (im weitesten Sinne) OV7670_Device und
> Form_Terminal die wichtigsten in denen alles abläuft.

Das habe ich schon geblickt.

>
>> Immerhin habe ich C#-mäßig kaum Konstrukte entdeckt, die ich
>> sprachenmäßig nicht verstanden habe.
>
> das ist gut, da ich ja auch kein "gelernter" Programmierer bin fehlt mir
> wahrscheinlich auch der ein oder andere Kniff mit dem es sich besser
> machen ließe. Aber wir sind ja zum Lernen hier ;-)

Nur aus Neugierde: Hattest Du vorher schon C# programmiert?

>> Beabsichtigst Du in den kommenden Tagen noch größere Änderungen am
>> Terminal-Code? Sollte ich einen eigenen Branch in GitHub aufmachen,
>> damit wir dann ggf. Codemerges machen können? Keine Ahnung, wie das in
>> VS funktioniert ... Aber das ist auch erst einmal nur Prio2.
> Ja im Grunde halte ich das für eine Gute Idee, auch wenn ich das noch
> nie gemacht habe. Auch cool finde ich es, dass du Github anscheinend ins
> VS eingebunden hast, das werde ich mir mal anschauen.

Habe ich im "Team Explorer" gefunden:
Dort unter "Manage Connections" > Local Git Repo. > Clone

> Da ich es ja
> ursprünglich nur für den uC code gedacht hatte, habe ich "Github
> Desktop" verwendet.

Was ist "Github Desktop"?  Eine Einstellung bei Github oder eine 
Einstellung in VS?

> Damit kann man dann einfach einen comit mit
> anschließendem Push ausführen. Aber das geht bestimmt auch aus dem VS.
> Gute Besserung weiterhin.

Danke - heute Abend ist erstmals leichte Besserung zu spüren.
Klassische Männergrippe halt ...

> Back to Topic:"Read Device Settings stoppt mitten drin"
> habe jetz Tx,Rx,SIOC,SIOD (alles direkt am uC) am LA hängen. Folgende ,
> angehängte Beobachtung:
> rx kommt noch auf dem uC an (zumindest auf der rx Leitung) danach
> passiert nichts mehr, kein tx, kein SIOC, kein SIOD.

> Damit gehe ich davon aus, dass das Problem keins ist, welches durch
> meine adapter Platine und die Lötkünste verbunden ist. Teilt ihr diese
> Ansicht?

Aber Du hast doch geschrieben, "Read Device Settings stoppt mitten 
drin".
Dann muss doch rx beim AVR ankommen und tx einiges senden bevor die 
Sache stoppt, oder?

Bitte beschreibe die Dinge etwas genauer - ich kann das Problem mit 
Deiner Beschreibung leider nicht nachvollziehen.

> Da ich das Problem auf beiden Uno-Boards habe, gehe ich weiterhin davon
> aus, dass es sich nicht um ein defektes Board handelt.
>
> Bleiben zwei Möglichkeiten:
> - Es liegt am Code... Warum um alles in der Welt funktioniert der dann
> bei euch?!

Komisch.
Sollte Dein AVR-Code fritte sein?
Im Anhang findest Du denjenigen Code, der bei mir läuft.
Ein Verzweifelungsversuch ist's ja vielleicht wert:
Einfach mal einspielen und gucken, ob's läuft.

> - Es scheint ein generelles Problem mit dem Uno zu geben.
> Das wäre zu Überprüfen mit einem Adapter board für den Nano, dass ich
> mir am Wochenende basteln könnte.

Hmmm ...

Also: ich würde systematisch vorgehen und dabei DebugWire nutzen:

- Starte Dein AVR-Programm im Debug-Modus und setze Breakpoints
- Sende vom Terminal ein "read register" und schau dann per Debugging,
  was auf dem AVR passiert.
- Wenn Du dann parallel noch per LA mitschneidest, was auf rx, tx,
  SIOC, SIOD passiert, so musst Du das Problem mit 100%iger Wahr-
  scheinlichkeit herausbekommen können.

> PS: dieser LA und die Software sind ein Traum!
> ich kann mir sowohl die UART symbole als auch die I2C Symbole anzeigen
> lassen. (Für euch vlt. nichts neues) Aber ich schwebe auf Wolke 7 :D

Ah - das hört sich gut an und macht mich sehr neugierig.
Ich schwebe mit meinem Intronix-LA schon seit langem auf Wolke 140 (weil 
er halt die 20-fache Bandbreite des China-Clones hat: 500MHz ...).
Ich erhoffe mir einzig und allein vom China-LA, dass ich damit beliebig 
lange Serielle oder I2C-Übertragungen angucken kann - das fehlt bei 
meinem Intronix leider.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> PS: dieser LA und die Software sind ein Traum!
> ich kann mir sowohl die UART symbole als auch die I2C Symbole anzeigen
> lassen. (Für euch vlt. nichts neues) Aber ich schwebe auf Wolke 7 :D

Auch wenn ich im Moment nur mitlese:
Kann man mit der Software die decodierten I2C-Daten irgendwie sinnvoll 
speichern? Ich will die Daten, die an einen SI4735 geschickt werden, 
mitloggen. Normalerweise Adresse, Kommando und dann 3-8 Datenbytes. Das 
müßte praktisch bis zum I2C Stop jeweis in eine Zeile geschrieben 
werden.
Eben so, das ich es extern passen formatieren kann.

Ist völlig OT, aber ich komme da im Moment sowieso nur theoretisch dazu.
Ja, Rentner haben niemals Zeit... ;-)

Gruß aus Berlin
Michael

[David D. (saturi)]

@Michael die Antwort liefer ich dir heute Abend.

@Igel, meine Schilderung bezieht sich auf das letzte abgefragte Register 
(vgl. Bild) davor läuft es so wie ich es mir vorstelle

[David D. (saturi)]

> Nur aus Neugierde: Hattest Du vorher schon C# programmiert?
Nein, nicht mal in Informatik behandelt. Alles learning by doing... mit 
vielen Fehlgriffen :D

> Was ist "Github Desktop"?  Eine Einstellung bei Github oder eine
> Einstellung in VS?
Weder noch, ein kostenloses Programm, mit dem man quasi ein Github 
projekt in einen Ordner clonen kann (ich denke so wie in VS) und dann 
eben von dort aus pull requests geben kann.

> Aber Du hast doch geschrieben, "Read Device Settings stoppt mitten
> drin".
> Dann muss doch rx beim AVR ankommen und tx einiges senden bevor die
> Sache stoppt, oder?
wie heute mittag schon gesagt, es wird einiges gesendet und empfangen 
und irgendwann reißt der informationsfluss ab. Und das ist dann immer 
nach einem (richtigen) Rx also es kommen die richtigen daten noch auf 
dem Rx Pin des uC an.

> Komisch.
> Sollte Dein AVR-Code fritte sein?
> Im Anhang findest Du denjenigen Code, der bei mir läuft.
> Ein Verzweifelungsversuch ist's ja vielleicht wert:
> Einfach mal einspielen und gucken, ob's läuft.

Danke, habe ich getan (allerdings meine Projektdatei und den Ordner mit 
den Source-Dateien durch deinen ersetzt. Ergebniss ist das gleiche wie 
vorher.... Jetzt bin ich wirklich ratlos...

> Also: ich würde systematisch vorgehen und dabei DebugWire nutzen:

Tolle Idee aber wie soll ich bei einem sporadischen Fehler Debug-Wire 
nutzen? Wenn es erst beim 138sten mal auftritt klick ich mir einen 
Wolf?! das halte ich für nicht machbar. Oder hast du da einen Trick auf 
Lager?

> Ah - das hört sich gut an und macht mich sehr neugierig.
> Ich schwebe mit meinem Intronix-LA schon seit langem auf Wolke 140 (weil
> er halt die 20-fache Bandbreite des China-Clones hat: 500MHz ...).
> Ich erhoffe mir einzig und allein vom China-LA, dass ich damit beliebig
> lange Serielle oder I2C-Übertragungen angucken kann - das fehlt bei
> meinem Intronix leider.
Naja nicht beliebig aber bis zu 1T Samples kann man aufzeichnen. Dann 
hängt es von deiner Sample Frequenz die du einstellst ab, wie lange 
aufgezeichnet wird. Aber es gibt sogar ne Trigger funktion ab der dann 
gestartet wird.

Ich hoffe ihr könnt mir helfen :( :/ und habt noch ne coole idee bevor 
ich mich ans löten mache...


@Michael, es gibt mehrere export möglichkeiten: rechtsklick auf die i2C 
Zeile eröffnet nochmal weitere Möglichkeiten, hier ein Beispiel zu einer 
der Möglichkeiten:

4007-4007 I²C: Address/Data: Start
6319-6620 I²C: Address/Data: Write
4209-6319 I²C: Address/Data: Address write: 21
6620-6921 I²C: Address/Data: ACK
7023-9434 I²C: Address/Data: Data write: 00
9434-9735 I²C: Address/Data: ACK
9935-9935 I²C: Address/Data: Stop


Gruß

David

[Andreas S. (igel1)]

David D. schrieb:
>> Also: ich würde systematisch vorgehen und dabei DebugWire nutzen:
>
> Tolle Idee aber wie soll ich bei einem sporadischen Fehler Debug-Wire
> nutzen? Wenn es erst beim 138sten mal auftritt klick ich mir einen
> Wolf?! das halte ich für nicht machbar. Oder hast du da einen Trick auf
> Lager?

Der Fehler ist wirklich absolut sporadisch/beliebig?

Leider fehlt noch die exakte Beschreibung, wann der Fehler auftritt.
Ich mache mal ein Beispiel, was ich meine:

- AVR per USB bestromen
- OV7670-Terminal-Prog starten
- Button "verbinden" klicken
- Button "Read Device Settings" klicken ... läuft durch ...
- Denselben Button nochmals drücken ... bricht bei Register XYZ ab ???

Ist das der Ablauf?

Viele Grüße

Igel1


PS: sollte das wirklich Dein erstes C#-Programm sein, so hast Du schon 
ziemlich viele Stilmittel angewendet (soweit ich das überhaupt 
beurteilen kann) - Junge, Junge: Respekt, Respekt.

[Andreas S. (igel1)]

Andreas S. schrieb:
> - AVR per USB bestromen
> - OV7670-Terminal-Prog starten
> - Button "verbinden" klicken
> - Button "Read Device Settings" klicken ... läuft durch ...
> - Denselben Button nochmals drücken ... bricht bei Register XYZ ab ???
>
> Ist das der Ablauf?

... sollte das tatsächlich der Ablauf sein, so gibt es eine gute (und 
gleichzeitig auch schlechte) Nachricht:

Ich konnte Dein Problem soeben reproduzieren:

Auch bei mir bricht Deine OV7670-Terminal Version 0.12 beim Einlesen der 
Register per "Read Device Settings"-Button sporadisch (ja sogar häufig) 
ab.

Ich scheine also bei meinem letzten vor-vorigen Posting, als ich Dir 
"funktioniert zuverlässig und stabil" bescheinigt habe, entweder nicht 
vernünftig getestet zu haben (zu meiner Entschuldigung: da brummte mein 
Schädel auch noch deutlich mehr als aktuell) oder ich hatte einfach 
Glück.

Aktuell kann ich das Problem aber sicher reproduzieren.
Bei Version 0.10 tritt es übrigens viel, viel seltener auf - aber auch 
dort tritt es auf.

Auch bei mir scheint das Terminal noch korrekt einen letzten 
Registerwert anzufragen, aber der AVR antwortet nicht mehr - gleiches 
Fehlerbild wie bei Dir (siehe auch Bild im Anhang).


Was ich dabei nicht verstehe: warum passiert das bei Version 0.12 viel 
häufiger als bei Version 0.10, wenn's laut LA doch eigentlich am AVR 
liegt, der nicht mehr antwortet ??

Immerhin: Du weisst jetzt, dass Du mit Deinem Problem nicht allein bist 
und es scheinbar nicht an Deiner Verdrahtung liegt.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

@David: Danke fürs Nachschauen, sieht ja ganz gut aus. Ich werden mal 
heute Abend meinen Bekannten fragen, ob er Sigrok bzw. PulseView 
benutzt.

Ansonsten: ich werde morgen mal Deinen aktuellen Kram aufspielen und 
schauen, ob ich den Erkenntnissen von Andreas was möglichst sinnvolles 
hinzufügen kann.

Gruß aus Berlin
Michael

[David D. (saturi)]

> Was ich dabei nicht verstehe: warum passiert das bei Version 0.12 viel
> häufiger als bei Version 0.10, wenn's laut LA doch eigentlich am AVR
> liegt, der nicht mehr antwortet ??
Das verstehe ich auch nicht. vielleicht Zufall?

Du hast aber seit dem letzten mal (also als es bei dir und bei Michael 
zuverlässig lief so an die 10-30 mal wie ihr mir versichert habt, nicht 
nochmal ein anderes AVR Programm geflashed?

> Immerhin: Du weisst jetzt, dass Du mit Deinem Problem nicht allein bist
> und es scheinbar nicht an Deiner Verdrahtung liegt.

ja... geteiltes Leid ist halbes Leid...

Aber ich weiß nicht wo ich ansetzen soll?
Ich bräuchte sowas wie einen reverse debugger :D mit dem ich schritte 
rückwärts gehen kann...

[Dieter F. (Gast)]

Mahlzeit :-)

Du solltest Deine serielle Kommunikation mal auf den Prüfstand stellen.

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

if(Befehl[0]==0x0A)    //new Line from Buffer requested by the Terminal
    {
      *Programmstatus = 0x0A ;
    }

Es ist nicht besonders geschickt, "Befehle" mit Linefeed, CR etc. zu 
mischen. Reduziere Deine Main mal auf die reine Reaktion auf Befehle 
ohne die Kamera ins Spiel zu bringen. Also immer die erwarteten 
(O.K.)-Werte zurückgeben (bei Register lesen z.B. die Registernummer als 
Rückgabewert etc.) und je nach Bild-Lese-Befehl verschiedene Bit-Muster 
(0x11001100, 0x10101010, 0x00110011).

Das wird sicher interessant für Dich :-)

Ich werde am Wochenende mal wieder "mitspielen" - habe eine Kamera mit 
Fifo bekommen und werde die auch einsetzen.

VG
Dieter

[Dieter F. (Gast)]

Hi,

wenn ich schon mal am schauen bin ...

   UCSR0C = 0b00001110;
             ^^|||||| USART Mode Select
               ^^|||| Parity Mode Bits
                 ^||| STOP Bit Select          -> damit setzt Du 2 Stop-Bits
                  ^^| Character Size 11 -> 8Bit
                    ^ Clock Polarity

... oder habe ich Tomaten auf den Augen?

VG

[Andreas S. (igel1)]

Dieter F. schrieb:
> ... oder habe ich Tomaten auf den Augen?

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

... und bitte auch das darauf folgende Posting von Michael lesen.

[Dieter F. (Gast)]

Nochmal hi,

für heute die letzte Baustelle - siehe Hardcopy.

Was passiert bei den längeren Strings?

VG

[Dieter F. (Gast)]

Andreas S. schrieb:
> ... und bitte auch das darauf folgende Posting von Michael lesen.

Und warum testet ihr dann damit weiter, statt es zu korrigieren?

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


Ich bin kein U(S)ART-Spezialist, aber das wird schon seine Berechtigung 
haben:

https://electronics.stackexchange.com/questions/335695/why-the-start-bit-and-the-stop-bits-are-necessary

Keine Ahnung, wann und wie ein "Framing-Error" erkannt wird - aber ich 
versuche schon, gleiche Einstellungen auf beiden Seiten herzustellen.

Ob und wie sich da die akzeptierte Fehlerrate von 2,1 % bei der 
Einstellung der Baudrate (bei 16 MHz Takt) kumuliert ist mir auch nicht 
bekannt.

[David D. (saturi)]

Dieter F. schrieb:
> Nochmal hi,
>
> für heute die letzte Baustelle - siehe Hardcopy.
>
> Was passiert bei den längeren Strings?
>
> VG

Guten Abend Dieter!

schön von dir zu hören, schön, dass du jetzt Auch eine Kamera mit Fifo 
zum "mitspielen" hast :)

Und noch schöner, dass du schon fleißig im Code gewühlt hast.

dein Einwandt zum Uart senden ist berechtigt!
Allerdings tritt dieser Fall nur auf, wenn es einen Fehler bei der 
Kommunikation mit dem SCCB gibt. Soweit kommen wir aber garnicht.

Das das Problem beim Bildempfang nicht auftritt stimmt. Also wird das 
Problem wie von dir erkannt vielleicht in meiner wahrscheinlich in der 
Befehlsdetektion liegen. Was genau meinst du mit:"Es ist nicht besonders 
geschickt, "Befehle" mit Linefeed, CR etc. zu
mischen." Wo liegt das Problem oder wie würdest du es geschickter lösen?

[David D. (saturi)]

Ähmm ich stehe gerade mächtig auf dem Schlauch... Hier müsste mich mal 
jemand runter schubsen:
In unserer UART_init:

void UART0_init (void)
{
  TX_DDR |=(1<<TX_Pin);    //definiere TX Pin als Ausgang
  RX_DDR &=~(1<<RX_Pin);    //definiere RX Pin als Eingang


  UBRR0H = 0b00000000;      // Setzt Baudrate
  //UBRR0L = 0b00110011;      // dezimal : 103->9600; dez 68->14400;dez 51->19200; dez 8 ->115200 
  //UBRR0L = 0b00011001;  //38400
  //UBRR0L = 0b00000011;  //230400
  //UBRR0L = 0b11001111;  //9600
  UBRR0L = 0b00010000;  //115200
  UCSR0A = 0b00000010;

  UCSR0A |=0b00000000;
        //   ^---U2X  
...

Laut Datenblatt und Kommentar ist bei 16.0 MHz bei UBRR0n = 8 die 
Baudrate 115200.

Das läuft ja auch schon seit Tagen/Wochen auf dieser Baudrate. im Code 
ist aber UBRR0L auf 16 und nicht auf 8? Wie kann das sein? ebenso die 
anderen Baudraten... sind ebenfalls "verschoben" ich habe das gefühl 
gerade völlig verrückt zu sein? :O
Ddas gibts doch nicht. WO ist mein Denkfehler?


EDIT: hat sich erledigt.... das U2X bit ist ja gesetzt... warum zum 
Teufel wird dann nochmal mit dem gleichen Register verodert? :D... das 
nehm ich jetzt erstmal raus...

[Dieter F. (Gast)]

David D. schrieb:
> WO ist mein Denkfehler?

Alles gut - ich hatte nicht gesehen, dass

  UCSR0A = 0b00000010;
  UCSR0A |=0b00000000;

doch auf 0b00000010 und damit U2X auf 1 steht. Daher habe ich den 
Kommentar wieder zurück genommen (nachdem Du zitiert hast :-) )

David D. schrieb:
> warum zum
> Teufel wird dann nochmal mit dem gleichen Register verodert? :D... das
> nehm ich jetzt erstmal raus...

Genau das hat mich auf den falschen Weg geführt ...



David D. schrieb:
> Was genau meinst du mit:"Es ist nicht besonders
> geschickt, "Befehle" mit Linefeed, CR etc. zu
> mischen." Wo liegt das Problem oder wie würdest du es geschickter lösen?

Wenn ein Befehl 0x0A lautet und LF ist auch 0x0A (so ist es nunmal), 
dann kneift sich das.

https://de.wikipedia.org/wiki/Zeilenumbruch

Ich würde generell alles unter 0x20 nicht als "Befehl" verwenden (bei 
einer seriellen Übertragung).

[David D. (saturi)]

> Wenn ein Befehl 0x0A lautet und LF ist auch 0x0A (so ist es nunmal),
> dann kneift sich das.
Ja verstehe ich. Daher verwende ich zwei "Stop-Zeichen" CR+LF um genau 
diesen Fall ausschließen zu können.

(Wobei ausschließen natürlich auch nicht stimmt, wenn ich in Register 
0x0C 0x0A schreiben würde... hmm da sollten wir nochmal drüber 
nachdenken...


> Ich würde generell alles unter 0x20 nicht als "Befehl" verwenden (bei
> einer seriellen Übertragung).
ja verstanden... aber wie ist es mit Werten die zwischen 0 und 255 
liegen können? Wie würdest du die dann übertragen?

[Dieter F. (Gast)]

David D. schrieb:
> aber wie ist es mit Werten die zwischen 0 und 255
> liegen können? Wie würdest du die dann übertragen?

Bei den Werten erwartest Du genau x Werte bis zum Ende der Übertragung. 
Die überträgst Du binär und zählst mit.

Bei den Befehlen erwartest Du (in Deinem Programm) nach jedem Befehl ein 
LF (0x0A) und CR (0x0C). Wenn ein Befehl 0x0A lautet und Du 0x0A als LF 
abfragst um das Ende eines Befehls zu erkennen, dann kneift sich das 
natürlich, weil dann 0x0A nicht mehr als Befehl erkannt werden kann.

Um das unterscheiden zu können musst Du ein Protokoll "vereinbaren" (was 
Du ja auch irgendwie gemacht hast - nur nicht ganz ausreichend). Das 
muss eindeutig sein. Dazu gibt es verschiedene Ansätze (da kennen sich 
andere besser aus ...) z.B.

https://cache.industry.siemens.com/dl/files/253/24178253/att_101236/v1/uss_24178253_spez_00.pdf

[David D. (saturi)]

> Bei den Befehlen erwartest Du (in Deinem Programm) nach jedem Befehl ein
> LF (0x0A) und CR (0x0C). Wenn ein Befehl 0x0A lautet und Du 0x0A als LF
> abfragst um das Ende eines Befehls zu erkennen, dann kneift sich das
> natürlich, weil dann 0x0A nicht mehr als Befehl erkannt werden kann.


Hmmm... das werde ich mir jetzt einmal durchlesen.

Aber bist du sicher? also um diese "Feinheit" klar zu stellen ich warte 
zuerst auf 0x0D und dann auf 0x0Aund nur wenn beide aufeinander folgen 
wird die Zeichenfolge als solche erkannt. kommt nur ein 0x0D oder nur 
ein 0x0A passiert nichts, das Zeichen geht auch nicht verloren. 
Zumindest sollte das so ablaufen. Wenn ich hier einen Fehler habe, mach 
mich bitte darauf aufmerksam!

Danke :)

David

[Dieter F. (Gast)]

David D. schrieb:
> ich warte
> zuerst auf 0x0D und dann auf 0x0A

Nö, auf beides (ODER) - wenn Du es so "vereinbart hast". Wobei auch das 
wieder unschön ist, weil eigentlich die "Folge" LF und CR vereinbart 
ist.

while(((Befehl[i+j-2] != (char)0x0D) || (Befehl[i-1] != (char)0x0A))&&(i<10));

Dein ODER sagt, dass Du bei einem 0x0A ein Zeilenende (und KEINEN 
Befehl) oder ein 0x0D (auch kein Befehl) erkannt hast und damit auch 
KEINEN gleichlautenden Befehl abarbeiten wirst. Dein "i+j-2" vs. "i-1" 
entwirrst Du bitte selbst :-)

[David D. (saturi)]

Da fällst du glaube ich über den selben Fallstrick wie einst Igel:


David D. schrieb:
>>//igel1:  Hier passt der Kommentar nicht zum Code: es wird nicht
>>//        auf "CR UND LF" geprüft, sondern auf "CR ODER LF".
> Naja, nach meiner Auslegung ist beides richtig: Ich prüfe auf CR und LF:
> CR&CL = !!(CR&&CL) = !(!CR||!CL)  -->Da wir aber solange in der While
> schleife bleiben wollen, wie diese Bedingung nicht erfüllt ist, eine
> weiter Verneinung: !!(!CR||!CL) = (!CR||!CL) --> siehe code
> }while(((Befehl[i+j-2] != (char)0x0D) || (Befehl[i-1] !=
> (char)0x0A))&&(i<10));        // solange kein CR+LF erkannt wird

stimmst du mir da zu?

[Dieter F. (Gast)]

David D. schrieb:
> stimmst du mir da zu?

Nein.

Befehl: 0x01 0x0D 0x0A

I     J     I+J-2     I-1     Befehl[i+j-2]  Befehl[i-1]

1     1      0        0       0x01           0x01
2     0      0        1       0x01           0x0D
3     0      1        2       0x0D           0x0A
4

Bei I = 3 greift die Bedingung "Befehl[i+j-2] != (char)0x0D" und es ist 
Schluss. "Befehl[i-1] != (char)0x0A" wird gar nicht mehr ausgewertet, 
weil der erste Teil der kombinierten ODER-Verknüpfung bereits wahr ist.

Das kannst Du auch schön im LSS-File im generierten Assembler-Code 
nachlesen.

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Andreas S. schrieb:
>> - AVR per USB bestromen
>> - OV7670-Terminal-Prog starten
>> - Button "verbinden" klicken
>> - Button "Read Device Settings" klicken ... läuft durch ...
>> - Denselben Button nochmals drücken ... bricht bei Register XYZ ab ???
>>
>> Ist das der Ablauf?
>
> ... sollte das tatsächlich der Ablauf sein, so gibt es eine gute (und
> gleichzeitig auch schlechte) Nachricht:
>
> Ich konnte Dein Problem soeben reproduzieren:
>
> Auch bei mir bricht Deine OV7670-Terminal Version 0.12 beim Einlesen der
> Register per "Read Device Settings"-Button sporadisch (ja sogar häufig)
> ab.

Ich nicht, wie oft muß ich da raufklicken? Bin jetzt vermutlich beom 20. 
Durchlauf, alles ok...
Aktueller Kram von github auf dem AVR und Terminal 0.12

Und nun?

Dieter F. schrieb:
> Befehl: 0x01 0x0D 0x0A

Nicht in den Source reingeschaut, nur getestet: 01 0a 0d 0a, also lesen 
Register 0d - ok.
02 0d 0a 0d 0a, also 0d mit 0a beschreiben - ok.
Auch alle anderen Kombinationen daraus werden ausgeführt und 
beantwortet.
Register 0a mit 0d beschreiben klappt natürlich nicht, ist die PID und 
read only.

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Michael U. schrieb:
> 02 0d 0a 0d 0a, also 0d mit 0a beschreiben - ok.
> Auch alle anderen Kombinationen daraus werden ausgeführt und
> beantwortet.

Dann probiere doch mal Register 0x0D mit 0x0D zu beschreiben

0x02 0x0D 0x0D 0x0D 0x0A :-)

[David D. (saturi)]

Dieter F. schrieb:

> Bei I = 3 greift die Bedingung "Befehl[i+j-2] != (char)0x0D" und es ist
> Schluss. "Befehl[i-1] != (char)0x0A" wird gar nicht mehr ausgewertet,
> weil der erste Teil der kombinierten ODER-Verknüpfung bereits wahr ist.

hmm das verstehe ich nicht? Deine tabellarische Aufschlüsselung 
entspricht erstmal meinem Gedankengang und damit kann ich auch mitgehen.
ABER: Bei I=3 greift keine der beiden Bedingungen und deswegen wird aus 
der whileschleife ausgestiegen. Genau das ist ja der Clou an der 
Oder-Verknüpfung. Ich bleibe solange in der Schleifen, bis beide 
bedingungen nicht mehr erfüllt sind.

In diesem Beispiel steige ich trotzem bei I=3 aus, aber nur weil die 
zweite Bedingung "Befehl[i-1] != (char)0x0A" auch unwahr ist:

I     J     I+J-2     I-1     Befehl[i+j-2](!= 0x0D)  Befehl[i-1](!= 
0x0A)

1     1      0        0       0x01(WAHR)               0x01(WAHR)
2     0      0        1       0x01(WAHR)               0x0D(WAHR)
3     0      1        2       0x0D(FALSE)              0x0A(FALSE)

aus der While-Schleife wird nur ausgestiegen, wenn beide Bedingungen 
False sind. (Sie sind ja oder verknüpft) sonst erfüllt eines die 
Bedingung und die While Schleife läuft freudig weiter.

Stimmst du mir jetzt zu? :D Sonst habe ich wohl noch nicht verstanden wo 
du das Problem siehst.

Es ist allerdings richtig, was Michael auch schon getestet hat, dass 
wenn die Daten innerhalb des Befehls(oder der Datenbytes) 0x0D 0x0A 
nacheinander sind, wird fälschlicherweise ein BefehlsabschlussSignal 
erkannt. (Gilt es für die Zukunft zu umgehen)

> Das kannst Du auch schön im LSS-File im generierten Assembler-Code
> nachlesen.
Das weiß ich leider nicht wie funktioniert.

[David D. (saturi)]

> Dann probiere doch mal Register 0x0D mit 0x0D zu beschreiben
>
> 0x02 0x0D 0x0D 0x0D 0x0A :-)

Habe ich und funktioniert. Obwohl es sich dabei um reserved Bits 
handelt, deren Reaktion nich immer absehbar ist.


Gruß
David

[Dieter F. (Gast)]

David D. schrieb:
> aus der While-Schleife wird nur ausgestiegen, wenn beide Bedingungen
> False sind. (Sie sind ja oder verknüpft)

Sobald EINE der Nicht-Bedingungen zutrifft wird ausgestiegen - weil sie 
ODER-verknüpft sind.

    while(((Befehl[i+j-2] != (char)0x0D) || (Befehl[i-1] != (char)0x0A))&&(i<10));        // solange kein CR+LF erkannt wird
 51c:  eb 85         ldd  r30, Y+11  ; 0x0b
 51e:  fc 85         ldd  r31, Y+12  ; 0x0c
 520:  8d 85         ldd  r24, Y+13  ; 0x0d
 522:  9e 85         ldd  r25, Y+14  ; 0x0e
 524:  a1 e0         ldi  r26, 0x01  ; 1
 526:  b0 e0         ldi  r27, 0x00  ; 0
 528:  ac 0f         add  r26, r28
 52a:  bd 1f         adc  r27, r29
 52c:  ea 0f         add  r30, r26
 52e:  fb 1f         adc  r31, r27
 530:  e8 0f         add  r30, r24
 532:  f9 1f         adc  r31, r25
 534:  32 97         sbiw  r30, 0x02  ; 2
 536:  80 81         ld  r24, Z
 538:  8d 30         cpi  r24, 0x0D  ; Wenn 0x0D erkannt wird wird 0x0A nicht mehr verprobt
                                       Es geht dann direkt zum Check auf kleiner 10
 53a:  39 f4         brne  .+14       ; 0x54a <UART0_rx_work+0xa2>
 53c:  eb 85         ldd  r30, Y+11  ; 0x0b
 53e:  fc 85         ldd  r31, Y+12  ; 0x0c
 540:  ec 0f         add  r30, r28
 542:  fd 1f         adc  r31, r29
 544:  80 81         ld  r24, Z
 546:  8a 30         cpi  r24, 0x0A  ; 10
 548:  21 f0         breq  .+8        ; 0x552 <UART0_rx_work+0xaa>
 54a:  8b 85         ldd  r24, Y+11  ; 0x0b
 54c:  9c 85         ldd  r25, Y+12  ; 0x0c
 54e:  0a 97         sbiw  r24, 0x0a  ; 10
 550:  64 f2         brlt  .-104      ; 0x4ea <UART0_rx_work+0x42>

David D. schrieb:
> Habe ich und funktioniert.

Ja, weil Du (wie ich zu spät gesehen habe) damit ja zufällig die 
korrekte Folge schon im Speicher hast - obwohl Du den Terminator (0x0D 
und 0x0A) noch gar nicht gelesen hast und auch nie lesen wirst, weil ja 
0x0D schon erkannt worden ist.

[David D. (saturi)]

Michael U. schrieb:
> Ich nicht, wie oft muß ich da raufklicken? Bin jetzt vermutlich beom 20.
> Durchlauf, alles ok...
> Aktueller Kram von github auf dem AVR und Terminal 0.12
>
> Und nun?

Das gibts doch nicht. ich steck die Kamera ein, verbinde die Kamera 
8Datenbits 1 stoppbit, parity none handshake none. und spätestens beim 
dritten durchlauf von Read Device Settings bleibts hängen. (meistens 
schon beim 1. oder 2.)

[Dieter F. (Gast)]

David D. schrieb:
> spätestens beim
> dritten durchlauf von Read Device Settings bleibts hängen. (meistens
> schon beim 1. oder 2.)

Willkommen im Club :-(

[David D. (saturi)]

Dieter F. schrieb:
>Sobald EINE der Nicht-Bedingungen zutrifft wird ausgestiegen - weil sie
>ODER-verknüpft sind.

Das sehe ich anders:
in einer while schleife wird solange verweilt, bis die Bedingung falsch 
ist:

while(true); //Endlosschleife. Da sind wir uns einig denke ich.
while(true || false) //Endlosschleife, weil die Bedingung (true||false) immer true ist.

I=0;
while((true||false)&&(i<10)){
i++
}//10 Schleifen Durchläufe, weil die erste Bedingung true ist. Wenn jetzt der Assambler (oder welcher Baustein auch immmer dafür verantwortlich ist) feststellt dass bei der ersten oder Bedingung der 1. parameter schon true ist, brauche ich die restlichen garnicht mehr prüfen (weil mit true verodert immer true ist) und springe direkt zum nächsten && verknüpften teil.

>>Wenn 0x0D erkannt wird wird 0x0A nicht mehr verprobt.Es geht dann direkt >>zum 
Check auf kleiner 10

Exakt, habe ich versucht oben zu beschreiben.
Ich hoffe ich konnte mich verständlich ausdrücken :)

Sind wir dann JETZT einer Meinung? :D Oder kannst du mich doch noch von 
einem Fehler überzeugen :)

Gruß und vielen Dank!

 David

[Michael U. (amiga)]

Hallo,

ich habe da jetzt kurz über Deinen Ausschitt des ASM-Listings geschaut 
ohne mir alles zusammenzusuchen.
while(((Befehl[i+j-2] != (char)0x0D) || (Befehl[i-1] != 
(char)0x0A))&&(i<10));

Was ist hier j?
Wenn er auf die letzten Bytes im Buffer auf 0x0D 0x0A prüfen will, hätte 
ich mir jetzt ein simples
while(((Befehl[i-2] != (char)0x0D) && (Befehl[i-1] != (char)0x0A)) && 
(i<10));
vorgestellt.
Vielleicht komme ich nachher dazu, mir das mal selber genauer 
anzuschauen.

Gruß aus Berlin
Michael

[David D. (saturi)]

Ich kann leider den Assambler Code nicht lesen. vielleicht würde ich 
sonst verstehen, auf was du mich aufmerksam machen möchtest.

[David D. (saturi)]

Michael U. schrieb:

> Was ist hier j?
> Wenn er auf die letzten Bytes im Buffer auf 0x0D 0x0A prüfen will, hätte
> ich mir jetzt ein simples
> while(((Befehl[i-2] != (char)0x0D) && (Befehl[i-1] != (char)0x0A)) &&
> (i<10));
> vorgestellt.
genau das ist es auch, allerdings kommst du jetzt an ein Problem, wenn 
du gerade bei Befehl[0] bist, weil Befehl[0-2] zu einem Fehler führt. 
Daher gibt es j als "künstlichen" Zähler, der i für die ersten beiden 
Befehle beeinflusst.
Es mag sein, dass es da eine bessere Art gibt, das zu Umgehen aber so 
hatte ich es mir ganz am Anfang mal überlegt.

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> Es mag sein, dass es da eine bessere Art gibt, das zu Umgehen aber so
> hatte ich es mir ganz am Anfang mal überlegt.

Sieht an dieser Stelle kompliziert aus und was kompliziert aussieht, ist 
meist keine gute Lösung.
Ok, muß ich mir heute Nachmittag mal in Ruhe anschauen.
Wenn i Dein Zeiger auf den Buffer ist und die Auswertung erst nach 
mindestens 3 Zeichen beginnen soll weil es 1 Byte Kommandos ohne 
Parameter nicht gibt, warum dann nicht einfach einen Vergleich auf i > 2 
mit in die Abfrage?

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

David D. schrieb:
> Sind wir dann JETZT einer Meinung?

Ja.

Ich werde mal die UART-Routinen ersetzen und schauen, ob es dann 
stabiler wird.

[David D. (saturi)]

Dieter F. schrieb:
> David D. schrieb:
>> Sind wir dann JETZT einer Meinung?
>
> Ja.
>
> Ich werde mal die UART-Routinen ersetzen und schauen, ob es dann
> stabiler wird.

Sehr gut :) und vielen Dank für das Sparring :) das hilft immer bei der 
Verbesserung. Du hattest die Lösung ja schon mit dem gelöschten Wiki 
Beitrag geschickt ;-)

Jetzt müssen wir den Fehler aber wo anders suchen

[Dieter F. (Gast)]

David D. schrieb:
> Jetzt müssen wir den Fehler aber wo anders suchen

So - die serielle Kommunikation funktioniert jetzt zuverlässig. Ich habe 
Peter Danneggers Routinen mit Ringpuffer eingebaut und bei 76.800 und 
250.000 Baud funktioniert alles tadellos (mit Dummy-Werten). Bei 115.200 
Baud habe ich jede Menge Fehler und nichts geht richtig (habe ein 
SSD1306 LCD drangehängt und mir die übertragenen Bytes mal angeschaut). 
Mit dem LA habe ich immer nur gesehen, dass es nicht weiter ging - 
vielleicht habe ich da noch Schwächen in der Bedienung :-/

Die Fehlerrate ist vermutlich schlicht zu hoch - das hat ggf. nicht mal 
etwas mit Davids Routinen zu tun (rückbauen werde ich aber jetzt nicht 
mehr). Warum das bei Michael ohne Probleme funktioniert verstehe ich 
nicht - macht aber nichts. Hauptsache das Problem ist erstmal weg.

Nachher werde ich die Kamera mal anstecken und weiter schauen :-)

[Dieter F. (Gast)]

Na ja - SCCB scheint auch noch zu haken.

Register schreiben funktioniert erst im 2. Ansatz, Register lesen bringt 
nich zuverlässig identische Werte.

Ich muss dazu schreiben, dass ich ohne Level-Shifter arbeite. Lt. 
Datenblatt V 1.01 für den AL422B Punkt 8.2 "In either case the AL422B is 
5V or 3.3V I/O tolerant." sollte das gehen.

An SIOC und SIOD habe ich jeweils einen pullup - das hat mit meiner 
Routine prima funktioniert. Vielleicht schreibe ich die auch noch um.

Morgen ist auch noch ein Tag :-)

[Andreas S. (igel1)]

Hi Leute,

ganz schön was los hier!
Super, das Dieter hier so kräftig mitmischt.

Ich habe derweil meine neue erworbenen C# Kenntnisse einmal ausprobiert, 
um eine kleine Testutility zu schreiben, mit der man auch Davids 
MC-Programm prima testen kann.

Ich habe das Tool "SendMaster" genannt, weil es beliebige Bytes über die 
serielle Schnittstelle senden (und auch empfangen) kann.

Nix Dolles, aber man kann damit einfachste Protokolle gut nachstellen:

Dazu werden die zu sendenden Bytes als Folge von Hex-Zahlen im 
Sende-Fenster eingegeben. Wenn das Tool auf Antwort-Bytes warten soll, 
trägt man an der jeweiligen Stelle einfach Punkte '.' ein. Jeder Punkt 
steht für ein zu empfängendes Byte.

Mit der folgenden Sequenz kann man z.B. via Davids MC-Programm das 
Kamera-Register 0x50 abfragen, es dann auf den Wert 0x88 setzen und es 
anschließend nochmals abfragen.

01 50 0D 0A . .
02 50 88 0D 0A .
01 50 0D 0A . .

Die Antwort seht Ihr im Screenshot im Anhang.
Das Programm habe ich ebenfalls angehängt.

Der Code ist allerdings aktuell noch so grottig, dass ich ihn niemandem 
zumuten möchte (und so richtig auf Herz und Nieren ist er auch noch 
nicht getestet - erwartet also das Schlimmste und freut Euch, wenn's 
trotzdem funktioniert)

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Ich muss dazu schreiben, dass ich ohne Level-Shifter arbeite. Lt.
> Datenblatt V 1.01 für den AL422B Punkt 8.2 "In either case the AL422B is
> 5V or 3.3V I/O tolerant." sollte das gehen.

Der Fifo ja, der OV7670 aber nicht, XCLK, RESET usw.
Möglich, daß sie mitspielt, aber nicht sicher.

Dieter F. schrieb:
> So - die serielle Kommunikation funktioniert jetzt zuverlässig. Ich habe
> Peter Danneggers Routinen mit Ringpuffer eingebaut und bei 76.800 und
> 250.000 Baud funktioniert alles tadellos (mit Dummy-Werten). Bei 115.200
> Baud habe ich jede Menge Fehler und nichts geht richtig (habe ein
> SSD1306 LCD drangehängt und mir die übertragenen Bytes mal angeschaut).

Ich hatte irgendwann früher auch schon mal einen Ersatz für die 
UART-Routinen gemacht und wohl auch hier reingestellt. War primitiv und 
nur auf die Verwendung mit der Kamera-Geschichte zugeschnitten.
David hat ja nunmal den Ehrgeiz, jedes Fahrrad neu erfinden zu wollen, 
kann man machen, trifft zugegebener Weise aber weniger meinen Nerv.
Das zieht sich hier jetzt schon über 1 Jahr so hin, ohne für mich 
erkennbares Ziel und eigentlich auch ohne wirklichen Fortschritt.

Andreas S. schrieb:
> Mit der folgenden Sequenz kann man z.B. via Davids MC-Programm das
> Kamera-Register 0x50 abfragen, es dann auf den Wert 0x88 setzen und es
> anschließend nochmals abfragen.

Wenn für Dich Kenntnisse in C# sinnvoll sind ist das natürlich sinnvoll, 
Dich damit auseinanderzusetzen. Mir reicht es schon, meine durchaus 
mangelhaften C/C++ Kenntnisse aufzubessern. ;)
Das, was Deine Programmierübung da macht, kann ich auch mit HTerm 
erledigen, wenn ich es will.
So, vermutlich habe ich den Sonntag Morgen falsch angefangen, aber 
egal...

ok. Der UART hat bei 16MHz Takt und 115200 Baud einen Fehler von +2,1% 
mit gesetztem U2X-Bit, eigentlich geht das noch gut. Auch die -3,5% bei 
U2X = 0 gehen eigentlich noch. Beim UNO kommt noch die Tolereanz des 
Ceramic-Resonators dazu, der Nano kommt mit seinem Quarz da wohl etwas 
besser weg.
Interessant ist ja, daß Probleme ja auch dem Board zwischen AVR und 
UART-Bridge passieren müssen, zum Rechner per USB ist das ja egal.
Bei mir laufen auch die 230400 noch völlig stabil, warum auch immer...
Da ist der Fehler dann ja schon -3,5%.
Der CH340 auf dem Nano ist friedlicher, die Firmware Mega16U2 auf dem 
UNO kann man überfahren, wenn man bei der Bildübertragung zuviele Bytes 
direkt hintereinander schickt. 500000 sind da bei mir nicht mehr stabil, 
da verliert er willkürlich Bytes, wenn ich ein komplettes Bild 
rüberschicke.
Ich habe ja noch meine ürsprüngliche Testsoftware, die einfach nur alle 
60s ein komplettes Bild schickt, da kann ich das gut reproduzieren.

Der Kram liegt weiterhin hier griffbereit, wenn ich was bestimmtes 
Testen soll, gern. Am Besten eine Bediensequenz für sein Terminal 
mitteilen und was passieren soll oder auch nicht. Ich schau da auch 
weiterhin gern in den AVR-Code, wo er da evtl. klemmt.

Sich mit der OV7670 zu befassen, mit ihren Möglichkeiten und Grenzen, 
ist ja irgendwie in weiter Ferne...

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> Das, was Deine Programmierübung da macht, kann ich auch mit HTerm
> erledigen, wenn ich es will.
> So, vermutlich habe ich den Sonntag Morgen falsch angefangen, aber
> egal...

Oh ja - heute bist Du wirklich nicht gut drauf und wir bekommen alle 
unser Fett weg. Vermutlich zu recht, denn HTerm scheint wirklich toll zu 
sein.
Aber mein SendMaster kann sich ja noch mausern und scheint mir für die 
Analyse von Davids Programm auch ganz gut geeignet.

Und was Davids Code angeht, so kann man die Fehler selbstverständlich 
mit vorhandenen Bibliotheken ausmerzen, aber David hat nun mal den 
Ehrgeiz, die Dinge mit eigenem Code ans Laufen zu bringen und das finde 
ich bewundernswert - zumal er in seinen jungen Jahren hier schon so 
einiges auf den Tisch legt. Sein C# Code ist jedenfalls auch nicht von 
schlechten Eltern ...

Ich war mit 26 (Schätzung korrekt? Oder hatte sich David hier dazu schon 
mal geoutet?) jedenfalls noch nicht so weit, dass ich C# programmieren 
konnte (hi, hi - Ältere wissen, warum ...).

Ausserdem ist David nicht nur clever sondern hat auch noch gute Manieren 
- und diese Kombination ist hier im Forum eher selten anzutreffen. Schon 
aus diesen 2 Gründen macht es Spaß, hier in diesem Thread mitzumischen.

Natürlich ist es ebenfalls toll, von alten Hasen wie Michael oder Dieter 
noch etwas dazu zu lernen.

Deine, Michaels, Anregungen haben übrigens dazu geführt, dass ich hier 
schon eine erquicklicher Sammlung weiterer interessanter Module liegen 
habe - habe nämlich so einiges von Deinen Ideen aufgegriffen - Danke 
dafür!

So - ich hoffe, der Sonntag fängt nun etwas versöhnlicher an ...

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Oh ja - heute bist Du wirklich nicht gut drauf und wir bekommen alle
> unser Fett weg. Vermutlich zu recht, denn HTerm scheint wirklich toll zu
> sein.

Naja, irgendwie war mir eben nach "ausheulen", man möge mir bitte 
verzeihen. ;-))

Andreas S. schrieb:
> Ich war mit 26 (Schätzung korrekt? Oder hatte sich David hier dazu schon
> mal geoutet?) jedenfalls noch nicht so weit, dass ich C# programmieren
> konnte (hi, hi - Ältere wissen, warum ...).

Ich auch nicht, ich kann es auch heute noch nicht... ;-)))

Andreas S. schrieb:
> Ausserdem ist David nicht nur clever sondern hat auch noch gute Manieren
> - und diese Kombination ist hier im Forum eher selten anzutreffen. Schon
> aus diesen 2 Gründen macht es Spaß, hier in diesem Thread mitzumischen.

Ich will ihm auf keinen Fall den Spaß an der Sache irgendwie verderben, 
eigentlich wollte ich nur sagen, warum ich in manche Tiefe da nicht 
einsteigen will.

Andreas S. schrieb:
> Natürlich ist es ebenfalls toll, von alten Hasen wie Michael oder Dieter
> noch etwas dazu zu lernen.

Danke für die Blumen, für mich war Elektronik immer nur Hobby, auch wenn 
ich im Laufe der Jahre über Wartung/Instandhaltung später auch zu ein 
paar beruflichen Programmierübungen gekommen bin, aber nur Richtung 
HTML/PHP/MySQL usw. Ansonsten war immer Hardware meine Lieblingsrichtung 
und Software dann Mittel zum Zweck.

Andreas S. schrieb:
> Deine, Michaels, Anregungen haben übrigens dazu geführt, dass ich hier
> schon eine erquicklicher Sammlung weiterer interessanter Module liegen
> habe - habe nämlich so einiges von Deinen Ideen aufgegriffen - Danke
> dafür!

Oh ja, im "dumme Ideen haben" sind mein Bekannter und ich Spitze...
Die 64x64 LED-Matrix von irgendwo oben hat inzwischen ein Lagerfeuer, 
zeigt die Uhr an und scrollt den Wetterbericht von Apixu_Weather an. Der 
Softwarestand stammt allerdings von meinem Bekannten. MQTT natürlich 
auch für lokale Meldungen und bei ihm noch das CD-Cover wenn der 
Audioplayer läuft. ok, ein Cover in 64x64 sieht etwas ...seltsam... aus.
Ich muß das mal sinnvoll in mein FHEM einbinden.
Aktueller Blödsinn: ich habe den SI4735 ausgegraben, der schon ewig 
rumlag und diskutiere mit dessen Datenblatt, durchaus erfolgreich. Da 
ich irgendwo im Netz den SSB-Patch ausgegraben habe und mein Bekannter 
Amateurfunker (um Gottes Willen... natürlich Funkamateure...) hat...

Ich hoffe durchaus, daß ich hier zwischendurch auch bei Davis Kamerakram 
was zu tun finde. :-)

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

@Michael:

Na das hört sich doch schon wieder alles viel versöhnlicher an ...
Ich denke, der Kaffee war gut und die Croissants waren frisch?  :-)

> Ich will ihm auf keinen Fall den Spaß an der Sache irgendwie verderben,
> eigentlich wollte ich nur sagen, warum ich in manche Tiefe da nicht
> einsteigen will.

Ist schon gut. Zum Glück ist das hier ja alles nur Hobby und niemand 
zwingt niemanden, bei der zweiten Erfindung des Rades mitzumachen. Ich 
gebe zu: hier ist wirklich nur der Weg das Ziel.

Mir selber macht's halt gerade Spaß und ich werde daher gerne auch in 
Davids Code weiterhin mit herumstochern. Wie schon der alte Fritz sagte: 
jeder soll nach seiner Facon glücklich werden.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Na das hört sich doch schon wieder alles viel versöhnlicher an ...
> Ich denke, der Kaffee war gut und die Croissants waren frisch?  :-)

Programmierer sind die einzige Spezie des Menschen, die Kaffee direkt in 
Programmcode umwandeln können.

Andreas S. schrieb:
> Wie schon der alte Fritz sagte:
> jeder soll nach seiner Facon glücklich werden.

Der alte Fritz... Von dem habe ich ja lange nichts mehr gehört...

Ich zitiere mich mal selbst:

Michael U. schrieb:
> Oh ja, im "dumme Ideen haben" sind mein Bekannter und ich Spitze...

Vorhin Mail von meinem Bekannten mit Betreff "nutzloses Zeug" und einem 
Link:
https://www.thingiverse.com/thing:3417955

Hmmm... wäre dann wohl die 9. Uhr, die hier irgendwo rumsteht. Naja, 
warum auch nicht, VFD in dieser Bauform ist noch nicht dabei...

Gruß aus Berlin
Michael

[David D. (saturi)]

Guten Tag zusammen,
na da bin ich ja froh, dass sich die Wogen schon wieder geglättet haben 
:)
interessant fande ich Michaels Aussage über die unterschiedlichen UART 
komponenten zwischen Uno und Nano. VIelleicht löte ich mir doch einfach 
mal eine Aufnahme. Ansonsten werde ich die Beobachtung von Dieter vorher 
noch ausprobieren. Hat die anderen Baudraten schon jemand mit "meinen" 
Uart routinen ausprobiert? ich bin gerade leider nicht zuhause :/...

@Igel dein Programm werde ich mir auch anschauen und finde es stark, 
dass du das anscheinend schon auf die Beine gestellt hast. Ich würde dir 
aber anbieten wollen, dass doch einfach in unser gemeinsames Terminal 
Programm zu "implementieren". Vielleicht auf einer anderen Tab seite. 
Dann entwicklen wir nicht zwei "tools" parallel zueinander.

Einfach während der Testphase eine neue Branch erstellen und los gehts 
:)

@Michael die Aussage, dass es keinen erkennbaren Fortschritt gibt nehme 
ich dir Übel :D... vlt. nicht so schnell wie du es sonst gewohnt bist, 
aber wenn ich mir die Posts von vor einem Jahr aufrufen, waren wir da 
noch an einer ganz anderen Baustelle ;-)

viele Grüße

David

[Michael U. (amiga)]

Hallo,

David D. schrieb:
> @Michael die Aussage, dass es keinen erkennbaren Fortschritt gibt nehme
> ich dir Übel :D... vlt. nicht so schnell wie du es sonst gewohnt bist,
> aber wenn ich mir die Posts von vor einem Jahr aufrufen, waren wir da
> noch an einer ganz anderen Baustelle ;-)

ok, ich entschuldige mich dafür in aller Form. Zumindest ein wenig. ;)
Mein "Tempo" ist hier garnicht nicht entscheidend. Ist mehr so eine 
Sache der Erwartungshaltung. Kleiner AVR und die OV7670 - reizvoll, weil 
an der Grenze des machbaren. Ausloten, welche Möglichkeiten diese 
Kombination und auch die OV7670 selbst bietet oder auch nicht. Das ging 
mir eben die letzten Tage so durch den Kopf und heute morgen eben auch 
etwas durch die Tastatur...

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

David D. schrieb:
> @Igel dein Programm werde ich mir auch anschauen und finde es stark,
> dass du das anscheinend schon auf die Beine gestellt hast. Ich würde dir
> aber anbieten wollen, dass doch einfach in unser gemeinsames Terminal
> Programm zu "implementieren". Vielleicht auf einer anderen Tab seite.
> Dann entwicklen wir nicht zwei "tools" parallel zueinander.

Ja, habe ich auch schon überlegt und fände ich gut.
Aktuell ist das ganze allerdings eher eine Lern-Fallstudie als etwas, 
was Du integrieren möchtest. Du würdest Dir vermutlich mehr Baustellen 
ins Haus holen, als Du jemals haben möchtest.

Außerdem müßten wir uns vorab sowieso abstimmen, damit sich unsere 
Programme nicht gleichzeitig um die serielle Schnittstelle prügeln.

Trotzdem: sobald mein C# - Kenntnisse halbwegs passabel sind, können wir 
die Integration gerne angehen.

> Einfach während der Testphase eine neue Branch erstellen und los gehts
> :)

Das sagst Du so "einfach".
Ich weiß leider aktuell nicht wie und bin zugegeben aktuell etwas zu 
faul, mich in die Branching-/Merging-Technologie unter VS einzulesen.
Wenn Du da schon weiter bist, so freue ich mich über ein paar 
Instruktionen von Dir ...

Viele Grüße

Igel1

[Andreas S. (igel1)]

> Dieter F. schrieb:
>> Ich muss dazu schreiben, dass ich ohne Level-Shifter arbeite. Lt.
>> Datenblatt V 1.01 für den AL422B Punkt 8.2 "In either case the AL422B is
>> 5V or 3.3V I/O tolerant." sollte das gehen.
>

Woraufhin Michael U. schrieb:
> Der Fifo ja, der OV7670 aber nicht, XCLK, RESET usw.
> Möglich, daß sie mitspielt, aber nicht sicher.


@Dieter F.:
Ich glaube auch, Du sparst hier an der falschen Stelle: auf diese Weise 
kannst Du Dir Fehler ins Haus holen, die Du später an völlig anderen 
Ecken suchst - das würde ich mir wirklich nicht antun.

Um Dir das Leben zu erleichtern, hier zwei Quellen, über die ich 
Level-Shifter bezogen habe:

Wenn's schnell gehen muss, aus Deutschland
(3x Level-Shifter mit je 4 Ports für zusammen 2,65 € inkl. Versand):
https://www.ebay.de/itm/253048505379?ul_noapp=true

Wer Zeit hat, kann in China bestellen
(5x Level-Shifter mit je 4 Ports für zusammen 1 EUR inkl. Versand):
https://www.aliexpress.com/snapshot/0.html?spm=a2g0s.9042647.6.2.74c34c4dXKYa0u&orderId=508148612005408&productId=32697947079

Viele Grüße

Igel1

[Dieter F. (Gast)]

Andreas S. schrieb:
> @Dieter F.:
> Ich glaube auch, Du sparst hier an der falschen Stelle: auf diese Weise
> kannst Du Dir Fehler ins Haus holen, die Du später an völlig anderen
> Ecken suchst - das würde ich mir wirklich nicht antun.

Danke für das Angebot - Level-Shifter habe ich (die aus Deinem ersten 
Link).

Ich hatte noch eine Unsicherheit - ein Breadboard. Das habe ich jetzt 
durch Dupont-Kabel abgelöst. Die sitzen fest und es gbt keine "Wackler".

Aus meiner Sicht bereiten jetzt noch die SCCB-Routinen Probleme. Die 
serielle Kommunikation ist korrekt. Ich stelle auf I2C /TWI um. 
"Bitbanging" ist mir zu aufwändig und I2C /TWI funktioniert 
nachweislich.

Heute wird das aber nichts mehr - das Wetter ist hier zu schön und heute 
Abend wird gefeiert :-)

Melde mich morgen wieder.

VG
Dieter

[Andreas S. (igel1)]

@Dieter: ich sehe, Du bist sehr schnell - hier geht's sonst etwas 
gemütlicher zu ...

@All:  Habe gerade mein SendMaster-Progrämmchen erweitert:
Es kann jetzt auch nur ein Byte pro Tastendruck versenden - das 
erleichtert das Debugging noch mehr.

Viele Grüße
Igel1

[Andreas S. (igel1)]

... hier schnell noch die neue Version von SendMaster mit der 
Möglichkeit, nun auch Bytes im Einzelstep-Verfahren zu versenden.
Zu diesem Zweck gibt es den neuen Button "Send 1 Byte".

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

@Andreas: das gefällt mir, gleich mal eingelagert. Eine Verwendung bei 
einem anderen Modul ist mir auch schon eingefallen.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> Hallo,
>
> @Andreas: das gefällt mir, gleich mal eingelagert. Eine Verwendung bei
> einem anderen Modul ist mir auch schon eingefallen.
>
> Gruß aus Berlin
> Michael

Danke, Michael.
Solltest Du spezielle Wünsche an das Tool haben, Du kennst ja den 
Entwickler :-) ...

Ich selber habe aktuell noch einen Haufen Ideen, wie ich SendMaster 
erweitern/optimieren möchte. Ich mache einfach so lange weiter, bis ich 
keine Lust mehr habe. Dieses C#-Gedöhnse macht mehr Spaß als ich 
erwartet hatte - vor allem wegen der VisualStudio-IDE - bietet eine 
wirklich intelligente Unterstützung des Entwicklers.

Hier meine aktuelle Prio-Liste:

1.) Statt Punkten "." für zu empfangende Bytes,  möchte ich auch ein
    "p" als Zeichen für ein zu empfangendes Bild zulassen.
    Dazu möchte ich auf der rechten Seite einen konfigurierbaren
    Bildbereich einrichten. Konfigurierbar wären Xdim, Ydim,
    Bytes/Pixel, Bildformat (z.B. RGB565, ...).
    Wenn man dann auf ein "p" im "Send" Fenster stößt, werden
    genausoviele Bytes eingelesen, wie der konfigurierte Bildbereich
    erwartet. Ich möchte die Bild-Bytes dabei zunächst in einen
    Buffer einlesen, so dass man verschiedene Bildformate auf die
    bereits gespeicherten Bytes anwenden kann (um so
    z.B. per Try & Error die Bilddimensionen ermitteln zu können).
    Das Bild wird dann jeweils im geänderten Format mit den Daten aus
    dem Buffer neu dargestellt.

2.) Byte-/Befehls-Folgen im "Send"-Feld sollen aus aus Dateien
    eingelesen bzw. dorthin abgespeichert werden können.

3.) Ich möchte "X" als Breakpoint im "Send"-Feld zulassen, dann könnte
    man von Breakpoint zu Breakpoint rauschen und alle dazwischen-
    liegenden Bytes ausgeben lassen.

4.) Eher Fleißarbeit: den seriellen Port noch etwas konfigurierbaren
    machen - z.B Baudrate, Stopbits, ...

Soweit ein Teil meiner aktuellen Ideen ...

Viele Grüße

Igel1

[David D. (saturi)]

Hallo Igel,
freut mich, dass dir C# so viel freude bereitet.

Trotzdem würde ich gerne nochmal darauf hinweisen, dass es doch mehr 
Sinn machen würde alles in einem zu vereinen.
Passende Klassen wären schon vorhanden und du hast alle freiheit sie 
nach deinen Wünschen zu Editieren ;-)

Das mit dem Comport sehe ich als nicht so kritisch an. (Sobald der 
Comport connected ist, kannst du über den senden und empfangen wie du 
lustig bist, da funkt das bestehende Programm dann eigentlich nicht 
rein.

ich werde dir heute abend eine branch erstellen und schauen wie das im 
vs einzubinden ist.

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Solltest Du spezielle Wünsche an das Tool haben, Du kennst ja den
> Entwickler :-) ...

:-))

Zu Deine Ideen: man kann alles machen, was man will. Ich habe nur gerade 
überlegt, welche Verwendung ich für Dein Tool hätte. Einige sind mir 
eingefallen, speziell Sachen, die wenig Datenverkehr brauchen und wo das 
Protokoll unklar/unhandlich/binär ist. Da kommen Terminalprogramme dann 
nicht gut klar und das von mir schon erwähnte HTerm kann eigentlich 
schon wieder zuviel. Für Deine Bildidee fehlt mir im Moment die reale 
Anwendung, es gibt nicht viel außer mal einem Kameramodul, was mir 
Bilddaten schicken könnte.
Beipisle bei mir: das Billig-China Funkbridge-Modul redet irgendwie 
nicht mit mir. Will es CR oder NL oder beides und wierum dann? Genau 
sowas sollte mit Deinem Tool gut rauszufinden sein. Auch bei Spielereien 
mit dem SI4735, den ich gerade in der Mache habe, könnte es praktisch 
sein: ich klebe einfach in die ESP32 Routinen zum Test eine 
seriell-I2C-bridge rein, da passt auch Dein Format sehr gut, Hex 
Adresse, Kommando, Datenbytes und die Anzahl Punkte für die Antworten. 
Hmmm... Punkte: Ziffer in Kalmmern für erwartete Anzahl Antwortbytes 
wahlweise statt der Punkte?

David D. schrieb:
> Trotzdem würde ich gerne nochmal darauf hinweisen, dass es doch mehr
> Sinn machen würde alles in einem zu vereinen.
> Passende Klassen wären schon vorhanden und du hast alle freiheit sie
> nach deinen Wünschen zu Editieren ;-)

Da halte ich mich mal komplett raus, für mich wäre es nur schade, wenn 
sein kleines Tool irgendwo in Deinem Terminal "versinkt".

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Hi,

ich hangle mich von Baustelle zu Baustelle :-)

SCCB läuft (mit I2C) ordentlich. Jetzt beschäftige ich mich mit der 
Kommunikation mit dem FiFo :-\

Es klemmt - und ich weiß noch nicht, wo. Das wird ein wenig dauern, da 
ich leider auch ab und an meiner Arbeit nachgehen muss. Ostern geht es 
weiter :-)

VG
Dieter

[Andreas S. (igel1)]

Michael U. schrieb:
> Hmmm... Punkte: Ziffer in Kalmmern für erwartete Anzahl Antwortbytes
> wahlweise statt der Punkte?

Geliefert wie bestellt (oder genauer: fast, wie bestellt - ich finde 
sogar noch etwas eleganter, als bestellt): anbei Version 0.03 vom 
SendMaster.

Neuigkeiten:

* Baudrate läßt sich nun auswählen

* Timeout läßt sich in ms einstellen:  Kommt > Timeout ms nichts am 
seriellen Port an, so wird dies [-] gekennzeichnet, wenn ein Byte 
erwartet wurde (also ein Dot '.' gesetzt war).

* Neben den Dots '.' gibt es jetzt auch Sternchen '*' - die stehen für 
beliebig viele zu empfangende Bytes. Erst wenn keine Bytes mehr am 
seriellen Port ankommen (will sagen: die konfigurierbare Timeout-Zeit 
überschritten wird), werden weitere Zeichen im Sende-Fenster geparst. 
Extra-Gimmick: die Anzahl der empfangenen Bytes wird zusätzlich 
ausgegeben (siehe Bild im Anhang).


Sieht hübsch aus und scheint auch auf den ersten Blick mit Davids 
MC-Programm zusammen zu ticken.

Allerdings ist mein SendMaster definitiv noch nicht auf Herz und Nieren 
getestet - bitte also keine Atomkraftwerke damit steuern :-)

Insbesondere fürchte ich, dass bei einem "*" und Anlieferung größerer 
Bytemengen, das Schreiben in das Result-Fenster irgendwann nicht mehr 
hinterher kommt und es ggf. zu Aufzeichnungsfehlern kommt.

Hier müsste ich etwas mehr Hirnschmalz reinstecken, als mir aktuell zur 
Verfügung steht.

Was die Bilddarstellungsklamotte angeht, so scheint mir das 
.NET-Framework diesbezüglich etwas sperrig zu sein. Will sagen: geht 
nicht so geschmeidig in den Kopp und es fehlt noch definitiv an 
Kenntnissen bei mir - aber was nicht ist, kann ja bald sein ...

Wäre schon cool, wenn ich durch schöde Eingabe von Bytes (also 
handgestricktes David-Protokoll) aus Davids AVR-Programm ein Bild 
herauslutschen könnte.

David möchte sich bitte trotzdem nicht ärgern, denn so ein SendMaster 
habe ich mir für unterschiedlichste Zwecke schon immer einmal gewünscht 
- wird also keine "Konkurrenzveranstaltung" zu Deinem Programm, David, 
und zielt eher in Richtung "schweizer Messer für serielle Protokolle"

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Geliefert wie bestellt (oder genauer: fast, wie bestellt - ich finde
> sogar noch etwas eleganter, als bestellt): anbei Version 0.03 vom
> SendMaster.

Das ist ein Service! Morgen komme ich nicht zum Testen, ich muß wirklich 
mal für meinen Rentner-Nebenverdienst auch noch arbeiten.... ;-)

OT: da Du ja seltsame Sachen magst, heute entdeckt und einfach mal 
bestellt (wofür auch immer...):
https://www.shotech.de/de/advanced_search_result.php?categories_id=0&keywords=air602&inc_subcat=1

Bei Seeedstudio sind die Unterlagen und das SDK verlinkt:
https://www.seeedstudio.io/Air602-WiFi-Module-p-3139.html
irgendwo ziemlich unten auf der Seite.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> OT: da Du ja seltsame Sachen magst, heute entdeckt und einfach mal
> bestellt (wofür auch immer...):

... ja, man kann nie wissen: der nächste Krieg kommt bestimmt :-)
Aber mal im Ernst: das Teil macht wirklich einen  interessanten Eindruck 
- immerhin ist ein ARM Cortex-M3 Prozessor mir 8MB Flash und 288k RAM 
drauf.

Beim Ali für ca. 1 EUR zu bekommen - Wahnsinn. Hab's mir direkt schon 
mal in den Warenkorb gelegt.

Bliebe nur zu recherchieren, wie gut die Doku dazu ist.
Ohne anständige Doku ist das Ding schlichtweg ein Lebenszeitfresser.

Viele Grüße

Igel1

[Dieter F. (Gast)]

Andreas S. schrieb:
> David möchte sich bitte trotzdem nicht ärgern

Na ja, David hat ja schon mehrfach darum gebeten, die Entwicklung zu 
integrieren. Irgendwie ging (geht ?) es ja hier auch darum, seine Lösung 
funktionsfähig zu bekommen.

Wenn ich rein mit der seriellen Schnittstelle spielen/testen will nutze 
ich Hterm. (http://www.der-hammer.info/terminal/) das ist zwar alt - ber 
bietet alles, was ich mir so wünsche.

Habe beschlossen den verbleibenden Pin, den ich eigentlich für OE 
verwenden wollte, für ein Debug-Schalterchen einzusetzten. Dann kann ich 
gezielt Debug-Meldungen ausgeben, wenn ich nicht mit Davids Programm 
steuere. Dann brauche ich nicht jedesmal neu zu flashen.

VG
Dieter

[Andreas S. (igel1)]

Dieter F. schrieb:
> Andreas S. schrieb:
>> David möchte sich bitte trotzdem nicht ärgern
>
> Na ja, David hat ja schon mehrfach darum gebeten, die Entwicklung zu
> integrieren. Irgendwie ging (geht ?) es ja hier auch darum, seine Lösung
> funktionsfähig zu bekommen.

Ja, Integration können wir auch gerne angehen, wenn SendMaster einen 
gewissen Reifegrad erreicht hat. Allerdings würde ich SendMaster halt 
gerne auch in anderen Projekten einsetzen und dafür ist es als 
Stand-Alone Tool dann doch irgendwie praktischer.

> Wenn ich rein mit der seriellen Schnittstelle spielen/testen will nutze
> ich Hterm. (http://www.der-hammer.info/terminal/) das ist zwar alt - ber
> bietet alles, was ich mir so wünsche.

Das hat Michael ebenfalls angepriesen. Muss ich mir nochmals näher 
angucken. Kann man damit auch serielle Protokolle "nachspielen": also 
z.B. 4 Bytes senden, dann 2 Bytes empfangen, dann 5 Bytes senden, dann 3 
Bytes empfangen, ...  - so, wie es mit meinem SendMaster und dem 
"."-Dot-Mechanismus funktioniert?

> Habe beschlossen den verbleibenden Pin, den ich eigentlich für OE
> verwenden wollte, für ein Debug-Schalterchen einzusetzten. Dann kann ich
> gezielt Debug-Meldungen ausgeben, wenn ich nicht mit Davids Programm
> steuere. Dann brauche ich nicht jedesmal neu zu flashen.

So ganz habe ich jetzt nicht verstanden, was Du vorhast, aber ich 
entnehme dem, dass Du vermutlich kein DebugWire zum Debugging nutzt?

Wenn nein: denke einmal über den Invest in einen AVR-Dragon nach - ist 
echt 'ne coole Sache. David, Michael und ich nutzen den ebenfalls: 
ermöglicht Breakpoints und Einzelschritt-Debugging auf der Hardware. 
Geht schon ein wenig in die Richtung, was ARM-Prozessoren so bieten.

> VG
> Dieter

VG
Andreas

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Aber mal im Ernst: das Teil macht wirklich einen  interessanten Eindruck
> - immerhin ist ein ARM Cortex-M3 Prozessor mir 8MB Flash und 288k RAM
> drauf.
...
> Bliebe nur zu recherchieren, wie gut die Doku dazu ist.
> Ohne anständige Doku ist das Ding schlichtweg ein Lebenszeitfresser.

Naja, bei dem Beschaffungspreis und der Baugröße landet es 
schlimmstenfalls in der Schachtel: irgendwann schaue ich mir das mal 
genauer an. ;-)

Dieter F. schrieb:
> Na ja, David hat ja schon mehrfach darum gebeten, die Entwicklung zu
> integrieren. Irgendwie ging (geht ?) es ja hier auch darum, seine Lösung
> funktionsfähig zu bekommen.

Du gehst ja im Moment wohl auch den Weg, bekannte Lösungen zu nutzen 
(peda's Serielle Lib, Hardware-I2C). Da habe ich hier ja auch eine 
Version, die macht, was ich erwarte. Aber eben ohne Davids Terminal (das 
kam ja erst später von ihm). Ich bin da im Moment in etwas abwartender 
Haltung, wohin der Hase läuft.

Dieter F. schrieb:
> Wenn ich rein mit der seriellen Schnittstelle spielen/testen will nutze
> ich Hterm. (http://www.der-hammer.info/terminal/) das ist zwar alt - ber
> bietet alles, was ich mir so wünsche.

Hatte ich auch schonmal erwähnt und nutze ich manchmal auch.

Dieter F. schrieb:
> Habe beschlossen den verbleibenden Pin, den ich eigentlich für OE
> verwenden wollte, für ein Debug-Schalterchen einzusetzten.

Auch eine gute Idee. Bei mir ist der freie Pin die interne LED des UNO, 
in meiner anderen Software hatte der Programmierer da schön I2C 
(SCCB)-Fehler abgefangen und dann im Endlos-Loop die LED blinken lassen. 
Hatte mir am Anfang gut geholfen als Schnelltest, ob die Drähte noch 
dran sind. ;)

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Andreas S. schrieb:
> Michael U. schrieb:
>> OT: da Du ja seltsame Sachen magst, heute entdeckt und einfach mal
>> bestellt (wofür auch immer...):
>
> ... ja, man kann nie wissen: der nächste Krieg kommt bestimmt :-)
[...]
>
> Bliebe nur zu recherchieren, wie gut die Doku dazu ist.
> Ohne anständige Doku ist das Ding schlichtweg ein Lebenszeitfresser.
>

Habe mal ein Weilchen recherchiert.

Ergebnis: Doku scheint grottig zu sein und Community ist bislang nicht 
vorhanden. Ergo => Finger weg vom W600 (auch wenn's wirklich schade 
ist).

Immer wieder erstaunlich, dass die Chinesen in der Lage sind, solche 
tollen Chips zu designen und dann wiederum nicht in der Lage sind, eine 
vernünftige Doku dazu zu schreiben. Zum Vergleich: die Referenz-Manuals 
von ST zu deren Cortex-M4-Prozessoren sind >1000 Seiten. Die 
Datenblätter mit den genauen Specs, nochmals ein paarhundert Seiten - 
und das braucht man auch.

Viele Grüße

Igel1

[Dieter F. (Gast)]

Andreas S. schrieb:
> Kann man damit auch serielle Protokolle "nachspielen": also
> z.B. 4 Bytes senden, dann 2 Bytes empfangen, dann 5 Bytes senden, dann 3
> Bytes empfangen, ...  - so, wie es mit meinem SendMaster und dem
> "."-Dot-Mechanismus funktioniert?

Jein. Nicht analog Deines "."-Mechanismus - aber man kann natürlich 
entsprechende Eingaben (auch per Datei) machen und die Rückgabewerte 
anschauen.

Andreas S. schrieb:
> So ganz habe ich jetzt nicht verstanden, was Du vorhast, aber ich
> entnehme dem, dass Du vermutlich kein DebugWire zum Debugging nutzt?

Genau - hier reicht es mir aus, an bestimmten Stellen kleine Ausgaben zu 
erzeugen um zu schauen, ob alles O.K. ist. Ansonsten habe ich den Atmel 
ICE zur Verfügung.

VG (Viele Grüße)
Dieter

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Ergebnis: Doku scheint grottig zu sein und Community ist bislang nicht
> vorhanden. Ergo => Finger weg vom W600 (auch wenn's wirklich schade
> ist).

naja, ich habe vorerst nichts anderes erwartet. Man muß ja nicht alles 
gleich selber programmieren können/wollen.
Der AT-Kommandosatz sieht merklich sinnvoller aus als der der ersten 
ESP8266.
Grundfunktionen MQTT, HTTP GET/POST sind da schon drin.
Ein bißchen Spaß muß sein. ;)

Andreas S. schrieb:
> Immer wieder erstaunlich, dass die Chinesen in der Lage sind, solche
> tollen Chips zu designen und dann wiederum nicht in der Lage sind, eine
> vernünftige Doku dazu zu schreiben.

Auch hier naja. Sie können sowas offenbar entwickeln und herstellen und 
auch liefern. Sie stellen relativ schnell überhaupt was zur Verfügung, 
ohne NDA usw. Kenne ich von anderen namhaften Herstellern durchaus 
anders.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Dieter F. schrieb:

> Jein. Nicht analog Deines "."-Mechanismus - aber man kann natürlich
> entsprechende Eingaben (auch per Datei) machen und die Rückgabewerte
> anschauen.

Ah, interessant.  Das mit dem Datei-Einlesen wollte ich bei mir auch 
noch einbauen - schau'n wir mal.

> Andreas S. schrieb:
>> So ganz habe ich jetzt nicht verstanden, was Du vorhast, aber ich
>> entnehme dem, dass Du vermutlich kein DebugWire zum Debugging nutzt?
>
> Genau - hier reicht es mir aus, an bestimmten Stellen kleine Ausgaben zu
> erzeugen um zu schauen, ob alles O.K. ist.

Claro - so geht's auch - ist halt etwas umständlicher als Breakpoints 
und DebugWire. Aber bekanntlich führen ja viele Wege nach Rom.

> Ansonsten habe ich den Atmel
> ICE zur Verfügung.

Dann scheinst Du auf der Sonnenseite des Lebens zu parken (mal rein 
investment-mäßig gesprochen) :-)

Die Anleitung hier scheint ganz gut zu beschreiben, wie Du Deinen ICE 
mit einem Nano zusammenschrauben und ans Fliegen bringen kannst:
http://www.crash-bang.com/debug-atmel-ice/

Falls das wirklich funktioniert, so würde ich dieses Feature an Deiner 
Stelle unbedingt nutzen - Debugging im Studio mit Breakpoints und 
Single-Step Modus erleichtert die Entwicklung und das Debuggen nach 
meiner Erfahrung massiv. 1-2h Einarbeitung, danach nie wieder 
Print-Statements in den Code einfügen und wieder rauslöschen - das lohnt 
sich.

> VG (Viele Grüße)
> Dieter

VGZ (Viele Grüße zurück)
Andreas

[Dieter F. (Gast)]

Andreas S. schrieb:
> Dann scheinst Du auf der Sonnenseite des Lebens zu parken (mal rein
> investment-mäßig gesprochen) :-)

Nö - nur die Billig-Version (Platine) mit selbst gedrucktem Gehäuse und 
selbst gefertigtem Kabel. So in etwa - aber noch ein paar € güstiger (da 
gab es mal ein Angebot, dem ich nicht widerstehen konnte) 
http://shop.mymcu.de/index.php?sp=article.sp.php&artID=200142

Ich habe auch schon "früher" mit JTAG debugging betrieben. Für mich 
macht das bei diesem "Projekt" aber aktuell keinen Sinn (ist ja 
eigentlich nicht sooo komplex). Mir reicht es, wenn ich sehe, wo es 
klemmt (und was dann dort so ankommt). Das geht mit Ausgaben über die 
serielle Schnittstelle sehr gut.

VGZZ
Dieter

[Andreas S. (igel1)]

Dieter F. schrieb:
> Ich habe auch schon "früher" mit JTAG debugging betrieben. Für mich
> macht das bei diesem "Projekt" aber aktuell keinen Sinn (ist ja
> eigentlich nicht sooo komplex). Mir reicht es, wenn ich sehe, wo es
> klemmt (und was dann dort so ankommt). Das geht mit Ausgaben über die
> serielle Schnittstelle sehr gut.

Alles klar - Du scheinst mehr Erfahrung auf diesem Gebiet zu besitzen 
als ich  - man kann das hier im Forum manchmal schlecht einschätzen.
Werde ich mein Klugschwätzen etwas zurückfahren :-)

Viele Grüße

Igel1

[Andreas S. (igel1)]

Hi Leute,

anbei die abendliche Lieferung: diesmal SendMaster V0.04

Zu dem Dot '.' und dem Asterisk '*' hat sich noch ein Dollar '$' als 
Steuerzeichen hinzugesellt. '$' steht für ein zu empfangendes Bild,
was dann auf dem Panel rechts dargestellt wird (wenn's gut läuft -
ist aktuell noch ziemlich buggy).

Die erwartete Bildgröße ist derzeit noch auf 313x240 fest codiert,
wird in Version 0.05 dann aber über die Oberfläche frei
konfigurierbar werden.

Anbei das Ergebnis (siehe Bild im Anhang), wenn ich diese Steuersequenz 
zu David's AVR-Programm sende:

08 0D 0A .
02 12 16 0D 0A .
02 40 14 0D 0A *
02 3A 05 0D 0A .
02 42 08 0D 0A .
04 72 02 0D 0A .
05 F0 00 0D 0A .
06 01 00 0D 0A .
0C 0D 0A $

Leider sind die Streifen des Testbildes noch schief - ich hoffe,
ich finde die Ursache noch. Aktuell fällt mir gerade nichts dazu ein.

Wie immer gilt: alles bislang nur sehr vage getestet - wer's
ausprobieren möchte braucht derzeit noch starke Nerven.


Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Andreas S. schrieb:
> Wie immer gilt: alles bislang nur sehr vage getestet - wer's
> ausprobieren möchte braucht derzeit noch starke Nerven.

warum? Explodiert der Arduino dabei? ;-)

OT: China-WLAN-Schnipsel lagen heute im Briefkasten. 5 bestellt, 6 
bekommen???
4 Drähte ran, an mein USB-Modul mit 3,3V Spannungsregler gesteckt, 3cm 
Draht als WLAN-Hochanrtenne ans Modul gelötet und TeraTerm gestartet.
Anmelden in meinem WLAN ok, anmelden am MQTT-Broker ok, Publish Message 
ok.
MQTT-Subscribe in der Beschreibung erstmal nicht verstanden.
Es gibt bereits eine Einbindung in die Arduino-IDE in Version 0.2.0, die 
sieht dafür nichtmal so schlecht aus...

Gruß aus Berlin
Michael

[David D. (saturi)]

kurzes Lebenszeichen...

Die Woche ist wieder besonders schlimm...

[Andreas S. (igel1)]

Andreas S. schrieb:
> Leider sind die Streifen des Testbildes noch schief - ich hoffe,
> ich finde die Ursache noch. Aktuell fällt mir gerade nichts dazu ein.

Verdammt, das war schwierig und ich habe ca. 10h gebraucht, um meinen 
(nicht Davids!) Fehler zu finden:

Das Testbild kommt von David's AVR-Programm mit 313x240 im rgb565 Format 
- ohne Header, ohne alles - so weit, so gut.

C# arbeitet intern nun aber massiv mit Bitmap-Objekten.
Also musste ich Davids Roh-Bilddaten in C# in ein Bitmap-Objekt 
einlesen, wobei man sich allein dabei schon halb die Ohren bricht. In 
Summe ist es trotzdem nichts anderes, als dass man den Roh-Bilddaten 
noch einen Bitmap-Header davorspannt. Anschließend kann man diese 
erweiterten Daten in ein Bitmap-Objekt einlesen und dieses Objekt dann 
mit .NET-Bibliotheken auf dem Bildschirm zeichnen lassen. Das 
frustrierende Ergebnis seit 2 Tagen: die vertikalen Teststreifen waren 
und blieben im C#-Programm diagonal.

Nach unendlichem Suchen fand ich heraus:
Bitmap specification requires, to pad row size to a multiple of 4 Bytes.
https://upload.wikimedia.org/wikipedia/commons/c/c4/BMPfileFormat.png

Will sagen: die Zeilenbreite des OV7670-Colorbar-Testbildes von 313 
Pixeln entsprach wegen rgb565 genau 626 Bytes. 626 ist aber kein 
Vielfaches von 4 - daher müssen noch 2 Füllbytes an jede Zeile angehängt 
werden - "Padding" eben. Danach hat man ein Bitmap-Bild, wo jede Zeile 
eigentlich aus 628 Bytes besteht, wo im Header jedoch als Zeilenbreite 
313 vermerkt ist.
Kaum war das getan, schon wurden die Streifen schön senkrecht!

Da muss man erst einmal drauf kommen ...

Viele Grüße

Igel1

[Andreas S. (igel1)]

Frohe Ostern, Ihr Lieben!
Wer als erstes den Osterhasen mit unserer OV7670 ablichtet, hat 
gewonnen!

Viele Grüße

Igel1

[Andreas S. (igel1)]

Hi Leute,

anbei eine Osteredition von SendMaster: SendMaster v0.05

* In einer "history.xml"-Datei kann man Sende-Sequenzen speichern,
  um sie später schnell per DropDown in das Send-Feld einfügen zu
  können - sehr praktisch.

* Erstmals generiert '$' ein korrektes Bild im rechten Bereich
  (aktuell nur mit Colorbar-Testbild getestet) - siehe Screenshot
  im Anhang.

* Die Anzeige der Bilddaten erfolgt in einem Bildframe, dessen X- und 
Y-Dimensionen sowie dessen Pixelformat frei konfigurierbar sind.

* Einmal eingelesene Bilddaten können mit dem "Apply"-Button
  in unterschiedlichsten X-/Y-Dimensionen und unterschiedlichsten
  Pixelformaten angezeigt werden

* Bilder können gespeichert und aus Dateien eingeladen werden.

Wie immer gilt: es gibt noch viel Optimierungsbedarf und alles ist
bislang nur sehr vage getestet - aber so langsam mausert sich das
Programm und man kann inzwischen ganz passabel damit testen.

@Michael: ... und nein, es explodiert nicht :-)

Trotzdem gibt es auch noch echte Baustellen:

* Aktuell blockiert das Einlesen serieller Daten das gesamte Programm -
  das ist insbesondere beim Bildempfang etwas nervig.
  Ich muss das früher oder später in Threads auslagern.

* Eingehende Daten, die nicht per "." oder "*" oder "$" erwartet
  wurden, werden bislang nicht angezeigt bzw. erst beim nächsten
  "." oder '*' oder '$' angezeigt - das verwirrt manchmal.

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

schöne Ostern erstmal noch, natürlich auch allen anderen.

Andreas S. schrieb:
> anbei eine Osteredition von SendMaster: SendMaster v0.05

:-( kein Osterhase...
Dein Farbbalken ist kaputt ;-)

Andreas S. schrieb:
> @Michael: ... und nein, es explodiert nicht :-)

Das kann ich so 100% bestätigen. :-)

Andreas S. schrieb:
> * Aktuell blockiert das Einlesen serieller Daten das gesamte Programm -
>   das ist insbesondere beim Bildempfang etwas nervig.
>   Ich muss das früher oder später in Threads auslagern.

Das macht z.B. mein altes VB-Programm vom LA auch.
Für mich gibt es da immer die Frage: stört das? Also kann ich 
währenddessen überhaupt was sinnvolles anderes mit dem Programm machen?
Bei mir war die Antwort nein, also wurde nur der Start-Button 
währenddessen in Stop umbenannt und ein Break eingebaut, um Abzubrechen.

Würde meiner Meinung nach auch hier reichen falls das Bild einlesen mal 
hängt oder man schon nach den ersten Zeilen sieht, das nur Müll kommt.

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Hi,

ich habe leider nicht so intensiv gearbeitet, wie ich wollte.

Ostern war einfach (vom Wetter her) zu schön.

USART und SCCB (TWI) funktionieren zuverlässig - nur mit der 
Fifo-Kommunikation hapert es noch. Verständlich, weil weder RE noch OE 
beschaltet sind. Eines von beiden benötigt man wohl für einen 
Read-Reset.

Es dauert noch etwas, bis ich die anderen "Parameter" durchschaut habe - 
aber es wird. Ich melde mich wieder - leider aktuell kein Osterhase :-(

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> USART und SCCB (TWI) funktionieren zuverlässig - nur mit der
> Fifo-Kommunikation hapert es noch. Verständlich, weil weder RE noch OE
> beschaltet sind. Eines von beiden benötigt man wohl für einen
> Read-Reset.

Wenn Du mit OE den FIFO_OE (/OE vom Fifo) meinst: der kann fest auf Low, 
zumindest solange der AVR-Port schön auf Eingang bleibt.
/RE vom FiFo ist auf den üblichen OV7670-Fifo Boards doch sowieso fest 
auf GND und nicht rausgeführt?

Gruß aus Berlin
Michael

[Dieter F. (Gast)]

Michael U. schrieb:
> Wenn Du mit OE den FIFO_OE (/OE vom Fifo) meinst: der kann fest auf Low,
> zumindest solange der AVR-Port schön auf Eingang bleibt.
> /RE vom FiFo ist auf den üblichen OV7670-Fifo Boards doch sowieso fest
> auf GND und nicht rausgeführt?

Ja - aber nicht beide.

Entweder oder - das sagt das Datenblatt.

[Michael U. (amiga)]

Hallo,

Dieter F. schrieb:
> Entweder oder - das sagt das Datenblatt.

Das Thema gab es schon ganz am Anfang hier mal. Das Datenblatt verbietet 
es nicht direkt, beide Signale dürfen bleibig lange aktiv sein. /RE 
stoppt intern den Lesecounter, auch wenn RCK weiterläuft.
AL422-08 Read Cycle Timing (Read Enable)

/OE aktiviert unabhängig davon den Ausgangstreiber unabhängig davon, was 
intern passiert.
AL422-09 Read Cycle Timing (Output Enable)

Wir steuern aber über RCK, damit entscheidet derFlankenwechsel von RCK, 
wann gültige Daten ausgegeben werden, auch wenn beide städig auf Low 
liegen.
Ein paar ns nach der fallenden Flanke von RCK liegen gültige Daten an 
und können eingelesen werden.

Da gab es auch am Anfang ein Timingproblem bei David, weil er wohl nach 
der steigenden Flanke gelesen hat. Da sind die Daten aber nur noch für 
TOH (4ns) gülig und nach TAC (max. 15ns) liegt bereits das nächste Byte 
gülig an. So fehlte am Anfang das erste Byte bzw, die vermeintlich 
falsche Byteorder wurde angenommen.

Gerade gesehen: er warte da jetzt auch unnötig lange bis er einliest, da 
reichen ein paar ns bzw. keine Wartezeit, weil schon der Aufruf der 
Funktion UART0_senden_Byte() länger dauert.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Dieter F. schrieb:

> Ostern war einfach (vom Wetter her) zu schön.

Gut so!

> USART und SCCB (TWI) funktionieren zuverlässig - nur mit der
> Fifo-Kommunikation hapert es noch.

Evtl. möchtest Du Dir einmal diese beiden Posts von mir anschauen,
dort habe ich in Pseudocode die Vorgehensweise zum Beschreiben und
zum Auslesen des FiFo's aufgeschrieben (und später danach erfolgreich
auf einem ARM-Prozessor 1:1 implementiert):
Beitrag "Re: Brauche Unterstützung beim OV7670 (bzw. SCCB)"

> Verständlich, weil weder RE noch OE
> beschaltet sind. Eines von beiden benötigt man wohl für einen
> Read-Reset.

In einigen Posts vor dem o.g. Link hatten wir herausgefunden,
dass mit der vorgegebenen inneren Beschaltung der Module die Spec
in bestimmten Punkten nicht eingehalten werden kann.
Genauso gut möglich ist es aber auch,  dass die Spec in einigen
Punkten nicht korrekt ist.

Wenn Du Dir also ab und an sagst "pfeif" drauf, und ein wenig nach
"Intuition" interpretierst und implementierstso ist das der
richtige Weg, das Dingen ans Fliegen zu bringen.

> Es dauert noch etwas, bis ich die anderen "Parameter" durchschaut habe -
> aber es wird. Ich melde mich wieder - leider aktuell kein Osterhase :-(

Wird schon noch ...

Viele Grüße

Igel1

[David D. (saturi)]

Guten Abend zusammen,
das lange Osterwochenende ist um und ich bin zu NICHTS gekommen... (also 
zumindest was das elektro Hobby angeht ;-) ich lese mich jetzt erstmal 
durch die posts durch und zu allzuviel mehr wird es heute wohl nicht 
reichen... Morgen dann :)

beste Grüße aus dem Süden

David

[Michael U. (amiga)]

Hallo,

Ostern ist vorbei, da war auch bei mir reihum Durchfuttern gehen 
angesagt. ;-)
Das Älterwerden habe ich auch dieses Jahr erfolgreich überstanden und 
den Pollin-Gutschein in Empfang genommen. :-)

Noch die OT-Runde, wohl speziell an Andreas:
Meine ESP32-Cams haben zum Test eine Software bekommen, die das Bild per 
FTP-Client auf mein NAS legt. DeepSleep läuft auch wie gewünscht, Wecken 
entweder per Timer oder bei dem Modul mit dem PIR auch damit.

Der China-WLAN-Schnipsel (Air602) ist jetzt im Test auch stabil, schickt 
mir alle Minute per MQTT die Uhrzeit, NTP läuft also auch.

Alles (natürlich) aus der Arduino-IDE, ich bin ja bequem.
Wenn ich nur wüßte, wozu???

Ich habe auch mal spaßeshalber ein paar CH552 bestellt:
https://www.shotech.de/de/
Der Händler ist gut, lag jeweils nach 2 Tagen im Briefkasten.
Auch keine Ahnung, wozu, mit der ArduinoIDE ist da ja erstmal nichts zu 
machen...

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Michael U. schrieb:
> Hallo,
>
> Ostern ist vorbei, da war auch bei mir reihum Durchfuttern gehen
> angesagt. ;-)

Gut gemacht!  Ähnliches habe ich auch über Ostern getan.

Meine Waage meinte daraufhin, die Stelle vor dem Dezimalpunkt um 2 
Nummern hochdrehen zu müssen. Seitdem ist das Dingen nicht mehr mein 
Freund.

> Das Älterwerden habe ich auch dieses Jahr erfolgreich überstanden und
> den Pollin-Gutschein in Empfang genommen. :-)

Glückwunsch (zum neuen Lebensjahr - nicht zum Pollin-Gutschein)!

> Noch die OT-Runde, wohl speziell an Andreas:

Ah - kleine Ausflug - das ist immer interessant bei Michael ...

> Meine ESP32-Cams haben zum Test eine Software bekommen, die das Bild per
> FTP-Client auf mein NAS legt. DeepSleep läuft auch wie gewünscht, Wecken
> entweder per Timer oder bei dem Modul mit dem PIR auch damit.

Huch - war da auch ein PIR drauf?
Meine 2 Module sind inzwischen ja auch angekommen, liegen aber noch 
unberührt in der Schublade. Hast Du Deine Aktionen/Aktivitäten hier im 
Forum irgendwo dokumentiert? Würde ich später gerne einmal darauf 
zurückgreifen.

> Der China-WLAN-Schnipsel (Air602) ist jetzt im Test auch stabil, schickt
> mir alle Minute per MQTT die Uhrzeit, NTP läuft also auch.
> Alles (natürlich) aus der Arduino-IDE, ich bin ja bequem.

Hast Du das in einem Thread beschrieben?
Oder kannst du einen Thread dazu empfehlen?

> Wenn ich nur wüßte, wozu???

Um andere (wie mich) neugierig zu machen ;-)

> Ich habe auch mal spaßeshalber ein paar CH552 bestellt:
> https://www.shotech.de/de/

Du meine Güte - was sind die Dinger billig!

> Der Händler ist gut, lag jeweils nach 2 Tagen im Briefkasten.
> Auch keine Ahnung, wozu, mit der ArduinoIDE ist da ja erstmal nichts zu
> machen...

Macht nix - war allemal interessant und lesenswert.

> Gruß aus Berlin
> Michael

Viele Grüße

Igel1

[Michael U. (amiga)]

Andreas S. schrieb:
> Meine Waage meinte daraufhin, die Stelle vor dem Dezimalpunkt um 2
> Nummern hochdrehen zu müssen. Seitdem ist das Dingen nicht mehr mein
> Freund.
Wieso? Kann man doch bestimmt die Firmware anpassen. ;)

> Glückwunsch (zum neuen Lebensjahr - nicht zum Pollin-Gutschein)!
Danke.

>> Meine ESP32-Cams haben zum Test eine Software bekommen, die das Bild per
>> FTP-Client auf mein NAS legt. DeepSleep läuft auch wie gewünscht, Wecken
>> entweder per Timer oder bei dem Modul mit dem PIR auch damit.
>
> Huch - war da auch ein PIR drauf?
Das war dieses Modul, hatte ich beim Erscheinen für 15€ bestellt, bei 
mir ist sogar der BME280 bestückt, obwohl der nur die Temperatur obwohl 
der nur die Temperatur des Regler-IC misst, der auf der Rückseite ist...

> Meine 2 Module sind inzwischen ja auch angekommen, liegen aber noch
> unberührt in der Schublade. Hast Du Deine Aktionen/Aktivitäten hier im
> Forum irgendwo dokumentiert? Würde ich später gerne einmal darauf
> zurückgreifen.
Jein, das Interesse ist da allgemein ziemlich bescheiden, spielt wohl 
kaum jemand damit rum...
Hier kurz erwähnt:
Beitrag "ov2640 Bild schießen und speichern"

>> Der China-WLAN-Schnipsel (Air602) ist jetzt im Test auch stabil, schickt
>> mir alle Minute per MQTT die Uhrzeit, NTP läuft also auch.
>> Alles (natürlich) aus der Arduino-IDE, ich bin ja bequem.
>
> Hast Du das in einem Thread beschrieben?
> Oder kannst du einen Thread dazu empfehlen?
Eigentlich nicht. Erwähnt und drüber gemault wurde mal, gekauft hat sie 
wohl keiner und gemacht auch nichts?

>> Ich habe auch mal spaßeshalber ein paar CH552 bestellt:
>> https://www.shotech.de/de/
> Du meine Güte - was sind die Dinger billig!
:-)
Beitrag "uC für 0,20€ CH552 / CH554 von WCH Billig Micro mit USB Funktion, Chip vorstellung"
Ein wenig habe ich zu den Teilen schon zusammengesucht, aber noch nichts 
gemacht.

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hi Leute,

um einmal wieder etwas "OnTopic" zu schreiben:

Ich kämpfe aktuell damit, die serielle Schnittstelle in meinem 
SendMaster-C# Programm von synchron auf asynchron umzustellen.

Synchron hat den riesigen Nachteil: das Programm hängt so lange, bis die 
serielle Schnittstelle fertiggelesen bzw. in Timeout gelaufen ist.
Und "Hängen" bedeutet: es geht während dieser Zeit wirklich nichts.
Das ist unschön und gefällt mir nicht.

Außerdem hatte sich Michael einen Break-Button gewünscht und den soll er 
auch bekommen ...

Leider muss ich für die Umstellung deutlich tiefer in C# eintauchen, als 
ich mir eigentlich vorgenommen hatte: Die Themen Threads, Delegates, 
Events, Callbacks, Invoke und all so'n Gemüse kenne ich zwar von anderen 
Programmiersprachen (Ausnahme: Delegates), aber eben noch nicht in C#.

Trotzdem ist dieses C# irgendwie interessant: Teils elegant, teils 
verwirrend. Elegant finde ich die Einbindung von SQL direkt in die 
Sprache via LINQ und die Einbindung von Lambda-Expressions. Verwirrend 
finde ich nach wie vor, dass Groß-Kleinschreibkonventionen oftmals nicht 
beachtet werden - da sind die Java-Jünger deutlich pingeliger. Auch gibt 
es in C# viele Abkürzungen für Dinge, die sauber ausgeschrieben meiner 
Meinung nach verständlicher wären - auch wenn man dann mal 10 Tasten 
mehr drücken muss.

Nach wie vor fasziniert mich aber die Entwicklungsumgebung Visual Studio 
mit Ihren Tooltips, Syntax-Hinweisen, der Voranzeige von 
Funktions-Signaturen, der Auto-Completion-Funktion. Und das alles bei 
wirklich guter Performance. Da stecken bestimmt hunderte von Mannjahren 
drin - sehr beeindruckend.

Jetzt aber nochmals konkret zur Implementierung der Abfrage des 
seriellen Ports unter C#.  David möchte bitte einmal diesen Artikel 
lesen:
https://www.sparxeng.com/blog/software/must-use-net-system-io-ports-serialport

Darin (und in vielen anderen "Profi"-Artikeln im Internet) wird 
beschrieben, das die SerialPort-Implementierung unter .Net äußerst buggy 
ist. Zitat:

The worst offending System.IO.Ports.SerialPort members, ones that not only should not be used but are signs of a deep code smell and the need to rearchitect all IOPSP usage:

    The DataReceived event (100% redundant, also completely unreliable)
    The BytesToRead property (completely unreliable)
    The Read, ReadExisting, ReadLine methods (handle errors completely wrong, and are synchronous)
    The PinChanged event (delivered out of order with respect to every interesting thing you might want to know about it)

Members that are safe to use:

    The mode properties: BaudRate, DataBits, Parity, StopBits, but only before opening the port. And only for standard baud rates.
    Hardware handshaking control: the Handshake property
    Port selection: constructors, PortName property, Open method, IsOpen property, GetPortNames method

And the one member that no one uses because MSDN gives no example, but is absolutely essential to your sanity:

    The BaseStream property

The only serial port read approaches that work correctly are accessed via BaseStream.  Its implementation, the System.IO.Ports.SerialStream class (which has internal visibility; you can only use it via Stream virtual methods) is also home to the few lines of code which I wouldn’t choose to rewrite.

Nach meinem aktuellen Stand der Recherchen kommen all diese Artikel zu 
dem Schluss, dass nur der Zugriff via SerialPort.Basestream zuverlässig 
funktioniert.

Anfänger-Artikel (leider die große Masse der Artikel im Netz), bewerben 
die Event-Mechanismen via "DataReceived event" und die Nutzung von 
"BytesToRead".

Bei den Profi-Artikeln (also von Leuten, die wirklich die Schnittstelle 
dann auch richtig genutzt haben - nicht nur für "Hello World") steht 
jedes Mal: Finger weg von diesen (deutlich einfacher) zu nutzenden 
Funktionen/Properties.

Dies nur als Hinweis für Dich, David, da wir vermutlich beide bislang 
"auf das falsche Pferd" gesetzt haben.

Viele Grüße

Andreas

[David D. (saturi)]

Andreas S. schrieb:

> Nach meinem aktuellen Stand der Recherchen kommen all diese Artikel zu
> dem Schluss, dass nur der Zugriff via SerialPort.Basestream zuverlässig
> funktioniert.

Auf dieses Basestream war ich auch schoneinmal gestoßen, allerdings 
nicht darauf, dass das andere unzuverlässig ist. Das einzige was ich 
einmal gelesen hab war, dass man sich nicht "sicher" sein kann, dass das 
serialPort.received() event auch wirklich für jedes empfangene Byte 
auslöst.

Das habe ich auch berücksichtigt, indem ich in meinen Verarbeitungen 
immernoch die Anzahl der empfangenen Bytes kontrolliert habe.

Wahrscheinlich haben die "Profis" recht und es wäre durchaus sinnvoll 
sich auch hier etwas tiefer in Mater einzuarbeiten. Allerdings frage ich 
mich ob das für unsere "unprofessionelle" Anwendung wirklich notwendig 
ist. Ich gehe davon aus, dass die uC mit ihrer Baudrate hier nicht 
wirklich an das "Limit" von C# und der SerialPort klasse kommen? Unsere 
beobachteten Fehler sind ja nachgewiesener maßen eher auf Seiten de uCs 
zu finden.


> Dies nur als Hinweis für Dich, David, da wir vermutlich beide bislang
> "auf das falsche Pferd" gesetzt haben.

vielen Dank, das werde ich in meine To-Do liste aufnehmen. Allerdings 
fehlt mir aktuell mal wieder die Zeit... Ich habe es nochnichtmal 
geschafft die "funktionierenden" Baudraten auszuprobieren.

Auch toll, dass dich C# so fesselt. Schade nur, dass das eigentlich 
Terminal (noch) nicht davon profitiert ;-) Du hättest auch dort absolute 
Gestalltungsfreiheit ;-) Aber vermutlich kann ich dich von deinem 
eigenen Projekt nichtmehr abbringen.

Gruß aus dem aktuell regnerischen Süden

David

[Andreas S. (igel1)]

David D. schrieb:
> Auch toll, dass dich C# so fesselt. Schade nur, dass das eigentlich
> Terminal (noch) nicht davon profitiert ;-) Du hättest auch dort absolute
> Gestalltungsfreiheit ;-) Aber vermutlich kann ich dich von deinem
> eigenen Projekt nichtmehr abbringen.

Ein Anfang wäre, wenn Du den  versprochenen Branch anlegst und 
herausfindest, wie Code-Merging - also das Übernehmen meiner Änderungen 
in Deinen Branch - funktioniert.

Und keine Sorge: wenn ich mich genügend in C# ausgetobt habe, dann 
wollte ich als  nächstes in Deinem uC-Programm auf Bugjagd gehen. Ich 
warte aktuell noch auf den Motivationsschub, denn die Bugsuche riecht 
mächtig nach Arbeit ...

VG
Igel1

[David D. (saturi)]

Hi Igel, den Branch hatte ich doch schon erstellt? einfach mal in Github 
auf das Branch: Master klicken, dann kannst du da ein anderes auswählen. 
(hoffe ich) und wenn du in VS dann auch dadrauf umstellst werden alle 
Änderungen in das/den Branch übernommen.

Das mergen sollte dann auch kein Problemm sein: hier erklärt für git. 
Das ganze Kommandozeilen getue brauchen wir an dieser Stelle nicht, weil 
Github uns das ganze als grafische Oberfläche zur Verfügung stellt.

https://git-scm.com/book/de/v1/Git-Branching-Einfaches-Branching-und-Merging

Gruß
David

[Andreas S. (igel1)]

Hallo David, hi Leute,

wollte nur sagen: mich gibt's noch, habe aber gerade andere private 
Baustellen (Auto). Werde mich mit Deinen GIT-Tipps (danke dafür) die 
Tage einmal beschäftigen.

In der freien Zeit versuche ich immer noch, die serielle Schnittstelle 
unter C# über das Auslesen des Basestreams ans Laufen zu bekommen - 
bislang leider nur mit sehr mäßigem Erfolg:

Lesen geht schon irgendwie, aber ich möchte auch wissen, wann ein 
Timeout passiert und das geht aktuell noch nicht, weil der Timeout von 
Serialport.Basestream scheinbar keine Exceptions wirft.

Außerdem ist alles in diesem Bereich nur sehr mau von Microsoft 
dokumentiert. Macht nicht sonderlich viel Spaß, die Raterei.

Viele Grüße

Igel1

[nickdann27 (Gast)]

Hallo Leute,

erstmal danke für die tolle Ideen, die hiergepostet wurden. Damit konnte 
ich schneller einstegen.

Jetzt zu meiner Frage:

Ich verwende wie die meisten hier ein OV7670+Al422B mit 12 MHz. Ich 
konnte schon das Kameramodul mit einem Arduino steuern und Bilder 
aufnehmen. Jetzt möchte ich dieses Modul mit einem FPGA zum Laufen 
bringen aber im Internet werden nur meistens ohne FIFO mit dem FPGA 
verwendet. Ich weiß auch, dass man mit einem FPGA kein Modul mit einem 
FIFO braucht, weil er schnell genug ist aber in meinem Fall benutze ich 
5 davon und die Bilderaufnahme müssen gleichzeitig laufen und in dem 
FIFO gespeichert werden, um später beliebig verarbeitet zu werden.

Bis jetzt Konnte ich schon Pixeldaten in dem FIFO einlesen und auslesen 
aber die Ausgangdaten sind noch falsch.

Hat schon jemand hier Erfahrung mit diesem Kamera Modul mit FPGA 
gemacht?

Ich freue mich schon über eure Antworten :)

Liebe Grüße

[Andreas S. (igel1)]

nickdann27 schrieb:
> erstmal danke für die tolle Ideen, die hiergepostet wurden.
> Damit konnte ich schneller einstegen.

Um ehrlich zu sein: ich zweifle ein ganz kleines bisschen, ob Du
wirklich alles hier gelesen hast - sonst wären Deine Fragen nämlich
schon beantwortet :-)

> Bis jetzt Konnte ich schon Pixeldaten in dem FIFO einlesen und auslesen
> aber die Ausgangdaten sind noch falsch.

Womit hast Du das getestet?
Mit einem Atmega oder einem anderen MC oder schon mit Deinem FPGA?
(by the way: welchen verwendest Du?)
Und was genau ist an den Ausgangsdaten falsch?
Wie sehen sie aus und wie sieht das Bild mit diesen "falschen 
Ausgangsdaten" aus?


> Hat schon jemand hier Erfahrung mit diesem Kamera Modul mit FPGA
> gemacht?

Aus unserer kleinen, bescheidenen Runde hier in diesem Thead,
vermutlich nicht. Ist aber irgendwie auch nicht nötig, denn der
FPGA muss protokollmäßig einfach nur das machen, was wir hier mit
dem MC veranstaltet haben - und schon wird es auch mit dem FPGA
klappen.

Ich könnte das vermutlich auf meinem Xilinx-Board hinbekommen,
aber dann wären meine Weihnachtsferien vorbei und das wollen
wir ja nicht :-)

>
> Ich freue mich schon über eure Antworten :)

Zu früh gefreut ;-)

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

hier lebt ja noch jemand... :-)

Andreas S. schrieb:
> Aus unserer kleinen, bescheidenen Runde hier in diesem Thead,
> vermutlich nicht. Ist aber irgendwie auch nicht nötig, denn der
> FPGA muss protokollmäßig einfach nur das machen, was wir hier mit
> dem MC veranstaltet haben - und schon wird es auch mit dem FPGA
> klappen.

auch bei mir hat er Pech, nix mit FPGA am Hut bisher.

Um auf das alte Thema zu kommen: irgendwo liegt die OV7670 immernoch an 
anen AVR gesteckt und verstaubt. Beim ESP32 Modul mit der OV2640 habe 
ich mir eine Software fertig gemacht, die alle x Minuten ein Bild auf 
meinen internen FTP Server legt. Sollte auf den Balkon für 
Wolkenaufnahmen. Stromversorgung sollte eine LiFePO4 Zelle mit einem 
kleinen Solarmodule und Laderegler werden. Die liegt seit Monaten auf 
dem Balkon und hält den Akku auch artig voll. Den benutzt aber keiner, 
weil das Cam-Modul noch nicht im gedruckten Gehäuse und auch hier 
irgendwo rumliegt.
Ansonsten habe ich z.B. mit dem BME680 diskutiert und mir aus Blödsinn 
einen Geigerzählerbausatz geholt. War bei Banggood gerade im Angebot...
Fehlt mir nur noch ein Orchester dazu. ;-)

Gruß aus Berlin
Michael

[Andreas S. (igel1)]

Hallo Michael,

schön, einmal wieder etwas von Dir zu hören!

Bei mir liegt die Kiste mit dem OV7670 inklusive verkabeltem 
LogicAnalyzer und allem drum herum auch in der Ecke und setzt Staub an. 
Sollte es etwa eines der vielen begonnenen und niemals fertiggestellten 
Projekte werden?
Nicht auszudenken .... ;-)

Immerhin habe ich durch David's Inspiration C# gelernt (und inzwischen 
leider auch schon wieder vergessen). Außerdem habe ich im Rahmen dieses 
Threads erstmals so richtig mit VisualStudio programmiert, was ein 
interessanter "Blick über den Tellerrand" für mich war.

Habe mir seit unserem OV7670-Projektchen die Zeit ein wenig mit 
Pferdeortung vertrieben: eine Beate suchte hier im Forum eine Methode, 
damit sich das Gatter zu Ihrem Stall nur für ihr Pferd öffnet:
Beitrag "Elektromagneten mit NFC/RFID Chipimplantat steuern *Auftrag*"

Über diesen Pferde-Thread bin ich zu Bluetooth Low Energie gekommen und 
habe mich dort ein wenig mit Beacons und deren Ortung beschäftigt. 
Allerdings nur sehr rudimentär - wie's die Zeit eines stressgeplagten 
Hobby-Elektronikers halt hergibt.

Aktuell rüste ich gerade optikmäßig etwas auf: die Augen werden 
schlechter und ich konnte ein Mantis Vision Mikroskop günstig samt 3 
Objektiven (2x, 4x, 8x Vergrößerung) in zwei Privatverkäufen gebraucht 
schießen. Ist gerade alles auf dem Postweg und ich bin ja schon sooooo 
gespannt! Das Dingen wird oft in Dental-Laboren verwendet und soll 
angeblich für Hobby-Elektronik ideal sein.

Nun aber zurück zu unserem Thread:

Irgendwie hätte ich schon Spaß, das OV7670-Projektchen hier wieder neu 
aufleben zu lassen, denn es war echt nett und angenehm hier mit Dir und 
David: hatte das Gefühl, dass hier jeder etwas vom anderen lernen 
konnte.

Allerdings stehen bei mir jetzt erst einmal andere Sachen an:  ich muss 
dringend mein Messy-Arbeitszimmer in den Griff bekommen, sonst gehe ich 
hier unter. Die Weihnachtsferien sind ideal dafür und wenn ich jetzt 
wieder hier im Thread einsteige, würde mein innerer Schweinehund 
abermals siegen, indem er das Angenehme vor dem Notwendigen priorisiert 
(das kann er suuuuper gut).

Was Deine Projektchen angeht, so ist es immer spannend davon zu hören. 
Ich kannte den BME280, aber der BMP680 scheint ja ein wahres 
Wundertierchen zu sein. Die Bosch-Leute sind da ganz weit vorn in Sachen 
Sensortechnik - schön zu sehen. Der Drucksensor ist so genau, dass ich 
damit doch glatt einen Höhentracker für unsere Familiendrohne bauen 
könnte - hmmm, schon wieder lauter interessante, verführerische Ideen 
...

Apropos Geigerzähler: könntest Du mir einen Link auf Dein 
Ali-Schnäppchen senden? Ich wollte mir auch immer mal wieder einen neuen 
Geigerzähler anschaffen - das nächste Atomkraftwerk geht bestimmt noch 
vor meinem Ableben in die Luft - da kann man dann wieder schöne Kurven 
aufzeichnen (auch wenn's vielleicht die Letzten sind).

Stammt die Ali-Schaltung von einem gängigen Schaltplan, der irgendwo im 
Internet, im MC-Forum oder in der Elektor entwickelt & diskutiert wurde? 
Das machen die Jungs aus Fernost ja ganz gerne und höchst erfolgreich: 
warum auch selbst entwickeln, wenn man doch gut abkupfern kann? (okay, 
okay - wir machen hier in diesem Thread zu 99% genau dasselbe, daher 
packe ich den moralischen Zeigefinger sofort wieder ein)

Und ah jaaa - jetzt erst, wo ich "GEIGER"zähler dreimal geschrieben 
habe, verstehe ich Deinen Wortwitz mit dem fehlenden "Orchester" ...

Viele Grüße

Igel1

[Michael U. (amiga)]

Hallo,

Geiegerzähler:
https://www.banggood.com/Assembled-DIY-Geiger-Counter-Kit-Module-Miller-Tube-GM-Tube-Nuclear-Radiation-Detector-p-1136883.html?rmmds=myorder&cur_warehouse=CN

Ich gestelle öfter bei Banggood, bisher keine Probleme. Lieferzeit 
üblicherweise 2-3 Wochen, bisher nur ein Ausreißer mit 6 Wochen.

Der Bausatz geistert überall rum, allerdings zu ziemlich traumhafte 
Preisen.
Ich hätte auch selber gebaut, aber inzwischen haben die Händler wohl 
alle Zählrohre aus der Ukraine für ihre Bausätze aufgekauft, damit sind 
die Zählrohre nicht mehr um 25€ zu bekommen...
Etwas dumma war, daß inzwischen ein anderes Zählrohr geliefert wird, für 
das es etwas Sucherei im Netz war, um den passenden Korrekturfaktor 
dafür zu finden. Schaltung ist an sich dem Zweck entsprechend und 
funktioniert. Allerdings haben die Jungs den Impulsausgang mit einem 
470k in Reihe gemacht, ein ESP8266 war da nicht gewillt, irgendeine 
Flanke zu erkennen. Ich habe mich jetzt einfach hinter den Monoflog 
gehängt, direkt an die rote Kontrollled. Mit 1,6V als High triggert der 
IRQ des ESP8266 hier zuverlässig.

BME680 ist eigentlich mehr lustig. Luftdruckwerte stimmen gut mit meinen 
beiden BME280 überein, Feuchte ist erwartungsgemäß eben ungefähr. 
Temperatur hat natürlich das gleiche Problem wie beim BME280, es wird 
die Chiptemperatur gemessen. Nachteil ist aber: der BME680 muß 
durchlaufen, sonst geht des IAQ-Sensor nicht sinnvoll. Damit geht die 
Temperatur immer vor...
IAQ muß man die BSEC Lib von Bosch nehmen, nur die wissen, was sie da 
treiben und verraten das auch nicht wirklich.

Andreas S. schrieb:
> Und ah jaaa - jetzt erst, wo ich "GEIGER"zähler dreimal geschrieben
> habe, verstehe ich Deinen Wortwitz mit dem fehlenden "Orchester" ...

:-)) Naja, einen Pferdezähler hatten sie leider nicht im Angebot...

Gruß aus Berlin
Michael

[nickdann27 (Gast)]

Andreas S. schrieb:
> Womit hast Du das getestet?
> Mit einem Atmega oder einem anderen MC oder schon mit Deinem FPGA?
> (by the way: welchen verwendest Du?)
> Und was genau ist an den Ausgangsdaten falsch?
> Wie sehen sie aus und wie sieht das Bild mit diesen "falschen
> Ausgangsdaten" aus?

Hallo Igel1 und Frohe Weihnachten :),

Ich habe das mit dem LA getestet und damit konnte ich feststellen, dass 
Pixeldaten reinkommen.
Ich verwende einen Cora Z7-10 von Digilent.
Das Ausgangsbild habe ich angehängt.

Ich versuche jetzt nochmal alle Schritte durchzugehen ( Von der 
Initialisation bis zum Auslesen der Pixeldaten aus dem FIFO, um zu 
sehen, woran das Problem liegt)
Im Anhang habe ich eine PDF-Datei von meinem Blockdesign.

Ich würde auch gerne meine Pixeldaten über eine UART Schnittstelle 
beobachten können aber das ist etwa kompliziert mit dem Cora z7, da er 
nur ein UART Pin auf dem PS Logic hat und dort müsste alles über Xilinx 
SDK programmiert werden, damit bin ich noch nicht fit.

[Michael U. (amiga)]

Hallo,

welche Datenbeispiele nimmst Du für Init usw.?
Leihe Dir unsere irgendwo oben aus der Gegend mit dem 
Farbbalken-Testbild aus, die gehen zumindest dann erstmal.

Gruß aus Berlin
Michael

[David D. (saturi)]

Welch eine Überraschung!!!
Da verrät mein E-Mail Postfach mir, dass hier wieder etwas los ist :)
Das freut mich sehr! Außerdem möchte ich mich zu tiefst entschuldigen, 
dass die ganze Sache so abrupt eingeschlafen war. vielleicht schaffen 
wir es ja nochmal Zeitnah das unterfangen aufleben zu lassen :)
Ich melde mich die Tage wieder.

Gruß

David

[Andreas S. (igel1)]

Och ja - das wäre irgendwie schön, denn hier war's doch ganz nett ...
Aber gräme Dich nicht - Du warst ja nicht der einzige, der ein Päuschen 
eingelegt hat.

Ich muss allerdings gestehen, dass ich aktuell hier noch ein paar 
größere Baustellen (also echte ...) habe.

Nevertheless läßt mich die Geschichte mit dem OV7670 auch irgendwie 
nicht los - wir haben es final nie so richtig gelöst und so etwas kann 
ich eigentlich nicht so gut leiden: es fehlt der "Deckel drauf".

Allerdings müßte ich jetzt vermutlich fast wieder bei Null anfangen. 
Seit unserer Zäsur bin ich leider zu so gar nichts Elektronischem 
gekommen - ein Jammer.

Viele Grüße

Igel1

[David D. (saturi)]

richtig! Das stört mich auch etwas. Vor allem, dass die Kritiker zu 
Beginn des Projektes dadurch womöglich recht bekommen würden ;-)

ich habe zwischenzeitlich immernur zwischen Tür und Angel sachen 
ausprobiert. Aber nicht spezifisch auf dieses Projekt bezogen.

Allerdings habe ich dadurch das UART Protokoll weiter verbessert, 
nachdem Vorbild - (ich glaube es war Michael, wenn ich mich recht 
erinnere) -  des Siemens Protokoll, welches hier mal gepostet wurde.

[Michael U. (amiga)]

Hallo,

ich lebe auch noch, der Kram liegt noch irgendwo zusammengesteckt rum 
usw.
Für mich ist es aber nach wie vor nur eine Art von Lernprojekt ohne 
irgendeinen praktisch nutzbaren Zweck.
Angefangene Projekte liegen auch bei mir ausreichend rum, es ist ohnehin 
nur Rentnerhobby, aber ein paar davon sollen durchuas mal fertig werden.
Das ESP32 Cam Modul mit der OV2640 soll eigentlich immernoch auf dem 
Balkon landen und Bilder vom Himmel zu meinen privaten Wetterdaten 
legen.
Sinn- und nutzlos, macht mir aber eben Spaß.
AVR mit OV7660 wäre von vielen Jahren interessant gewesen, wo es nicht 
anderes beschaff- und bezahlbares gab, da ist die Zeit aber eben 
weitergegangen.

Es war und ist aber hier eine nette Truppe zusammengekommen und der 
Thread bot immer wieder was Neues, insofern ist es schade, daß es so 
eingeschalfen ist.

Gruß aus Berlin
Michael