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
