Hallo, ich lese Daten mit dem Kammerainterface (DCMI) ein. Beim Starten der Auswertung warte ich logischerweise immer bis keine Daten anliegen (Framesignal aus), erst dann starte ich den Capture Modus. Das muss ich machen weil der nur Pegel gesteuert ist. Bis jetzt waren die Datenraten und Pausen so das ich bequem einen INT auf das Frameende setzten und den Empfang und den DMA neu starten konnte. Fehlende Bytes konnte ich auch erkennen, weil der DMA nicht fertig war. Jetzt aber werden die Pausen zwischen den Paketen zu kurz (Alt:10us neu:0,2us), die Daten Pakete brauchen ca. 40us zum einlesen. Also habe ich einen DMA Doublebuffer eingebaut und Nur jetzt finde ich keine Möglichkeit der Synchronisierung. Gibt es da eine Möglichkeit? Das Problem ist halt das mal ein paar Byte zuviel oder zuwenig ankommen. Beides sind Fehler Situationen die ich mit meiner alten Methode abfangen konnte. In den Daten an sich gibt es leider keine Kennung oder CRC um hier was auszuwerten. Gibt es einen Interrupt wenn der Datenpuffer gewechselt wird? Ich finde den nicht. VG, Peter
Also den Interrupt für den Pufferwechsel habe ich gefunden. Nur brauche ich den nicht wirklich, ist aber auch gut das jetzt zu wissen. Das andere Problem ist aber das was ich löschen muss. VG, Peter
Ehm, verstehe ich das richtig, dass du das DCMI als paralleles Interface ohne Kamera brauchst? Weil normalerweise übernimmt die Synchronisation des ganzen die Kamera und das DCMI. Du brauchst dann nur noch ein Frame-Interrupt, Line-Interrupt oder was auch immer auszuwerten. Was machst du dann mit den Daten? Speichern oder auf ein Display oder gleich über RS232/USB weiter senden? Bei einem Display musst du nichtmal ein Interrupt nutzen (kannst direkt auf den Speicherbereich des Displays schreiben, da der STM32F4 ein Displaycontroller hat). Ein paar zusätzliche Infos zu deinem Projekt wären sehr Hilfreich. Mit den aktuellen Infos kann man höchstens raten...
Es kommen halt Daten, CLK und Enable. Ist somit eine Art Parallele SPI. Von der Technik her das selbe in grün wie eine Kamera. Nur das Timing ist etwas schlimmer und es sind mehr Daten. Ich kann Simulierte Daten senden lassen von denen ich den Aufbau kenne. Darum kann ich erkennen wenn was nicht stimmt. Im Normalfall ist der Aufbau der Daten nicht überprüfbar, ausser der festen Länge pro Paket. Aber es gibt Fehler Situationen wo halt mal was fehlt oder zu viel gesendet wird. Die Daten werden über Ethernet weiter gesendet. Bis jetzt hatte auch alles super geklappt, nur jetzt muss noch mehr übertragen werden. Da ich aber kaum Einfluss (Mode slow / fast) auf die Datenquelle habe muss ich mit den kürzeren Pausen zu recht kommen. Und die Pausen sind halt das was mir Probleme bereitet. Wie gesagt 0,2us sind etwas zu kurz um da mal eben mit einem INT vernünftig rein zukommen und alles nötige zu machen. Der Frameende INT scheint nicht zu gehen zu mindestens hat anscheinend der DMA hin und wieder noch nicht den Speicher umgeschaltet. Habe es schon mit warten probiert, hat nichts gebracht. Da fällt mir gerade ein: Kann man den Frame Pin zusätzlich als INT Quelle nehmen? Dann versuche ich mal beim Starten einen Int zu erzeugen. Das DCMI ist wirklich ein sch.... Teil: kein Counter, keine vernünftige DMA Fehler Synchronisation. VG, Peter
Ok, jetzt ist schon mehr klar. Werden die HSYNC, VSYNC, auch irgendwie angesteuert? Wenn ja, dann musst du halt nur das Timing der DCMI-Schnittstelle einhalten (min Setup time,...), und schon könntest du Packete generieren. Es können bei keiner (einiger massen schlauen) Übertragung xyMByte pro Sekunde ohne Packete gesendet werden. Ich hatte bei einer 1.3 Megapixel Kamera das ganze Bild mit ~15fps eingelesen (2 Bytes pro Pixel). Dieses Bild habe ich dann aufgeteilt (~50 Zeilen, da der DMA Counter "nur" 16Bit gross ist). Den DMA-Interrupt nutzte ich schlussendlich um die Zieladresse des DMA anzupassen. Konnte dies sogar ohne ASM umsetzten (einfach direkt auf die Register schreiben und wirklich nur das nötigste setzen). So gesehen sollten deine 0,2us reichen (was ja etwa 34 Takte sind). Die genaue Interrupt-Latenz must du halt aus dem Datenblatt raussuchen, und schon weisst du ob deine ISR zu lange ist. Im schlimmsten Fall einfach auf asm wechseln. Ein anderer Vorschlag ist, dass du dich mit dem Daten-Sender absprichst: Dann könntest du ~65kByte mit ~40MHz PXCLK übertragen werden. Dan hättest du in ca 20ms dieses Packet empfangen. Anschliessend könnte eine kleine Pause von 10us (zum Umschalten) locker genutzt werden. Das Ethernet muss dann auch noch mit deiner Datenmenge nachkommen... (wie schiebst du diese dahin, was für ein Speicher hast du?). Achja, sind deine Daten kontinuierlich oder einfach ne menge gespeicherte Messwerte?
So nach dem diesem super Wochenende kann ich jetzt wieder besser denken. Also, die Daten kommen immer und die Pakete kann ich nicht ändern lassen. Das einzige ist die maximale Samplerate (slow/fast) die ich beeinflussen kann. Die Pakete haben auch nur 200Byte und werden mit maximal 8MHz (PXCLK) gesendet. H & V Sync sind parallel angeschlossen (== enable Leitung). Das ganze ist eigentlich so was von harmlos, wenn die blöde kurze Pause nicht wäre, bzw die Hardware besser wäre. An Assembler hatte ich auch schon gedacht, als Vorstufe hatte ich die ganzen CMSIS Funktionen schon ersetzt, aber wie Du schon erkannt hast 34 Takte sind nicht wirklich viel. Besonders da ich mir nicht sicher bin das aus dem Flash der Code überhaupt so schnell ist, ein verschieben ins RAM wollte der Compiler nicht, die Anweisung hat der einfach ignoriert (mit einer entsprechenden Meldung). Das Senden erfolgt in größeren Daten Paketen und sollte nicht auch noch ein Problem werden. In der SLOW Version wurden die Daten noch nicht einmal um kopiert sondern beim einlesen habe ich die Adressen immer so verbogen das die ETH Pakete direkt von DCMI/DMA aufgebaut wurden. Ich bin gerade dran beim Starten der Übertragung mir einen INT geben zulassen, dann habe ich genug Zeit alles zu bearbeiten. Aber wie ich da auf Fehler reagieren kann ist mir noch ein Rätsel. Wenn ich das Layout ändern könnte dann würde ich noch Counter auf die Leitungen setzen aber das ist jetzt nicht finanzierbar. VG, Peter
So an Alle die auch mal dieses Problem haben. Bei extrem kurzen Pausen zwischen den Daten: Vergesst die Interrupts auf eine Flanke oder auf das Frameende bei DMA doublebuffer. Das geht absolut nicht sauber! Die Interrupts kommen zwar alle, aber der DMA hatte bei mir bei ungefähr 10% noch nicht oder schon 2 mal den Buffer umgeschaltet (abfrage auf sein Flag). Warten war absolut keine Lösung, weil dann nichts mehr lief, ausser der Warteschleife. Das einzige was geht ist ein DMA Int auf "Transfer fertig". Der kommt immer sauber (parallel verglichen mit den anderen INTs). Hatte mit der Stoppuhr auch grob nach gemessen, ob die Anzahl stimmen kann. Das einzige blöde ist das man kaum überprüfen kann, ob die Daten Stimmen. Zu mindestens ist das bei meinen Daten so der Fall (keine Start Kennung kein CRC ...). Aber auch wenn das eine Normale Kamera wäre würde ein Versatz von wenigen Bytes kaum auffallen, ausser bei einem Testbild mit entsprechenden Linien. VG, Peter
Thread beobachten
Seitenaufteilung abschaltenBitte 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.