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
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
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.... :/
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
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
Angehängte Dateien:
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
Angehängte Dateien:
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
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
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
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:
1 | void sendFrameBufferToUART (int ImageWidth, int ImageHeight, int BytesPerPixel) |
2 | {
|
3 | OV7670_ResetFifoReadPointer(); |
4 | |
5 | for(int height = 0; height < ImageHeight;height++) |
6 | {
|
7 | for(int width =0; width < ImageWidth; width++) |
8 | {
|
9 | for(int ByteNumber =0; ByteNumber < BytesPerPixel; ByteNumber++) |
10 | {
|
11 | OV_RCK_PORT &= ~(1<<OV_RCK_PinNo); |
12 | _delay_us(85); |
13 | UART0_senden_Byte(Ov7670_readByte()); |
14 | OV_RCK_PORT |= (1<<OV_RCK_PinNo); |
15 | _delay_us(85); |
16 | } |
17 | } |
18 | } |
19 | } |
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
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
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.
Mist - und ich habe jetzt keine passende Frage ... Oder vielleicht doch: wie ist das Wetter? ?
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
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
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
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 ;-)
Angehängte Dateien:
-
FHEM.jpg
150 KB
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
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
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
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
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
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
@Michael U.: Danke für die Erklärungen - wieder was gelernt ... Viele Grüße Igel1
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
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
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.
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.
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
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
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
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)
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
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
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)...
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
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 ;-)
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
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
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
@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
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
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
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.
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
Angehängte Dateien:
-
20190407_173429.jpg
200 KB -
20190407_173440.jpg
200 KB -
20190407_173457.jpg
190 KB -
20190407_173509.jpg
240 KB -
20190407_173521.jpg
230 KB
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
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
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!
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
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.
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
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
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
Angehängte Dateien:
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
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
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
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
@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!
Angehängte Dateien:
-
Unbenannt.PNG
13 KB
> 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
Angehängte Dateien:
-
Terminal.v0_12.PNG
97 KB
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
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
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
@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
> 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
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.
Angehängte Dateien:
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
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
> 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...
Mahlzeit :-) Du solltest Deine serielle Kommunikation mal auf den Prüfstand stellen.
1 | while(((Befehl[i+j-2] != (char)0x0D) || (Befehl[i-1] != (char)0x0A))&&(i<10)); // solange kein CR+LF erkannt wird |
2 | |
3 | ...
|
4 | |
5 | if(Befehl[0]==0x0A) //new Line from Buffer requested by the Terminal |
6 | {
|
7 | *Programmstatus = 0x0A ; |
8 | }
|
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
Hi, wenn ich schon mal am schauen bin ...
1 | UCSR0C = 0b00001110; |
2 | ^^|||||| USART Mode Select |
3 | ^^|||| Parity Mode Bits |
4 | ^||| STOP Bit Select -> damit setzt Du 2 Stop-Bits |
5 | ^^| Character Size 11 -> 8Bit |
6 | ^ Clock Polarity |
... oder habe ich Tomaten auf den Augen? VG
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.
Angehängte Dateien:
-
12.04.png
36 KB
Nochmal hi, für heute die letzte Baustelle - siehe Hardcopy. Was passiert bei den längeren Strings? VG
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.
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?
Ähmm ich stehe gerade mächtig auf dem Schlauch... Hier müsste mich mal jemand runter schubsen: In unserer UART_init:
1 | void UART0_init (void) |
2 | {
|
3 | TX_DDR |=(1<<TX_Pin); //definiere TX Pin als Ausgang |
4 | RX_DDR &=~(1<<RX_Pin); //definiere RX Pin als Eingang |
5 | |
6 | |
7 | UBRR0H = 0b00000000; // Setzt Baudrate |
8 | //UBRR0L = 0b00110011; // dezimal : 103->9600; dez 68->14400;dez 51->19200; dez 8 ->115200 |
9 | //UBRR0L = 0b00011001; //38400 |
10 | //UBRR0L = 0b00000011; //230400 |
11 | //UBRR0L = 0b11001111; //9600 |
12 | UBRR0L = 0b00010000; //115200 |
13 | UCSR0A = 0b00000010; |
14 | |
15 | UCSR0A |=0b00000000; |
16 | // ^---U2X |
17 | ... |
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...
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).
> 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?
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
> 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
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.
1 | 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 :-)
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?
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.
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
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 :-)
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.
> 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
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.
1 | while(((Befehl[i+j-2] != (char)0x0D) || (Befehl[i-1] != (char)0x0A))&&(i<10)); // solange kein CR+LF erkannt wird |
2 | 51c: eb 85 ldd r30, Y+11 ; 0x0b |
3 | 51e: fc 85 ldd r31, Y+12 ; 0x0c |
4 | 520: 8d 85 ldd r24, Y+13 ; 0x0d |
5 | 522: 9e 85 ldd r25, Y+14 ; 0x0e |
6 | 524: a1 e0 ldi r26, 0x01 ; 1 |
7 | 526: b0 e0 ldi r27, 0x00 ; 0 |
8 | 528: ac 0f add r26, r28 |
9 | 52a: bd 1f adc r27, r29 |
10 | 52c: ea 0f add r30, r26 |
11 | 52e: fb 1f adc r31, r27 |
12 | 530: e8 0f add r30, r24 |
13 | 532: f9 1f adc r31, r25 |
14 | 534: 32 97 sbiw r30, 0x02 ; 2 |
15 | 536: 80 81 ld r24, Z |
16 | 538: 8d 30 cpi r24, 0x0D ; Wenn 0x0D erkannt wird wird 0x0A nicht mehr verprobt |
17 | Es geht dann direkt zum Check auf kleiner 10 |
18 | 53a: 39 f4 brne .+14 ; 0x54a <UART0_rx_work+0xa2> |
19 | 53c: eb 85 ldd r30, Y+11 ; 0x0b |
20 | 53e: fc 85 ldd r31, Y+12 ; 0x0c |
21 | 540: ec 0f add r30, r28 |
22 | 542: fd 1f adc r31, r29 |
23 | 544: 80 81 ld r24, Z |
24 | 546: 8a 30 cpi r24, 0x0A ; 10 |
25 | 548: 21 f0 breq .+8 ; 0x552 <UART0_rx_work+0xaa> |
26 | 54a: 8b 85 ldd r24, Y+11 ; 0x0b |
27 | 54c: 9c 85 ldd r25, Y+12 ; 0x0c |
28 | 54e: 0a 97 sbiw r24, 0x0a ; 10 |
29 | 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.
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.)
David D. schrieb: > spätestens beim > dritten durchlauf von Read Device Settings bleibts hängen. (meistens > schon beim 1. oder 2.) Willkommen im Club :-(
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:
1 | while(true); //Endlosschleife. Da sind wir uns einig denke ich. |
2 | while(true || false) //Endlosschleife, weil die Bedingung (true||false) immer true ist. |
3 | |
4 | I=0; |
5 | while((true||false)&&(i<10)){
|
6 | i++ |
7 | }//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
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
Ich kann leider den Assambler Code nicht lesen. vielleicht würde ich sonst verstehen, auf was du mich aufmerksam machen möchtest.
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.
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
Beitrag #5807520 wurde von einem Moderator gelöscht.
David D. schrieb: > Sind wir dann JETZT einer Meinung? Ja. Ich werde mal die UART-Routinen ersetzen und schauen, ob es dann stabiler wird.
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
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 :-)
Angehängte Dateien:
-
13.04.png
74 KB
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 :-)
Angehängte Dateien:
-
SendMaster.v0.01.PNG
53 KB
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
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
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
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
@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
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
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
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
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
> 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
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
@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
Angehängte Dateien:
-
SendMaster.v0.02.PNG
71 KB
... 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
Hallo, @Andreas: das gefällt mir, gleich mal eingelagert. Eine Verwendung bei einem anderen Modul ist mir auch schon eingefallen. Gruß aus Berlin Michael
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
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.
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
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
Beitrag #5810269 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
SendMaster.v0.03.PNG
57 KB
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
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
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
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
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
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. 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
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
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
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
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
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
Angehängte Dateien:
-
SendMaster.v0.04.PNG
65 KB
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:
1 | 08 0D 0A . |
2 | 02 12 16 0D 0A . |
3 | 02 40 14 0D 0A * |
4 | 02 3A 05 0D 0A . |
5 | 02 42 08 0D 0A . |
6 | 04 72 02 0D 0A . |
7 | 05 F0 00 0D 0A . |
8 | 06 01 00 0D 0A . |
9 | 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
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
kurzes Lebenszeichen... Die Woche ist wieder besonders schlimm...
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
Frohe Ostern, Ihr Lieben! Wer als erstes den Osterhasen mit unserer OV7670 ablichtet, hat gewonnen! Viele Grüße Igel1
Angehängte Dateien:
-
SendMaster.v0.05.PNG
87 KB
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
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
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 :-(
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
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.
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
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
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
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
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
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
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:
1 | 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: |
2 | |
3 | The DataReceived event (100% redundant, also completely unreliable) |
4 | The BytesToRead property (completely unreliable) |
5 | The Read, ReadExisting, ReadLine methods (handle errors completely wrong, and are synchronous) |
6 | The PinChanged event (delivered out of order with respect to every interesting thing you might want to know about it) |
7 | |
8 | Members that are safe to use: |
9 | |
10 | The mode properties: BaudRate, DataBits, Parity, StopBits, but only before opening the port. And only for standard baud rates. |
11 | Hardware handshaking control: the Handshake property |
12 | Port selection: constructors, PortName property, Open method, IsOpen property, GetPortNames method |
13 | |
14 | And the one member that no one uses because MSDN gives no example, but is absolutely essential to your sanity: |
15 | |
16 | The BaseStream property |
17 | |
18 | 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
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
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
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
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
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
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
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
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
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
Angehängte Dateien:
-
Circuit.jpg
240 KB -
Frame.jpg
240 KB
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.
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
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
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
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.
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
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.