Hi @ all, Ich plane ein Projekt bei dem ich wohl auf einen Digitalen Signal Prozessor zurück greifen muss. Leider habe ich noch nie mit einem DSP gearbeitet, habe lediglich mal einen Blackfin gesehen. Da die Developmentboards sehr teuer sind wollte ich hier fragen welcher DSP für mein Projekt in frage kommt. Anforderungen: Ich möchte Video Daten von einer Parallele Kamera empfangen und auswerten. im Moment verwende ich die AR0130 (12 bit Parallel, I²C Steuerung, 1.8V Signalpegel). Unter Umstände muss ich aber noch auf eine andere wechseln (wegen fps). Ich möchte die empfangenen Bilddaten (geringe Auflösung rund 80000 pixel zu je 12bit) auswerten (Mittelwerte, FFT, Filterung, ...) und das mit einer Framerate von 60 bis eventuell 120fps. Die durch die Auswertung gewonnen Daten( 10x 16bit variablen) möchte ich anschießend über Funk (z.b. Bluetooth) an einen PC später auch Handy übertragen. Das ganze Projekt soll später mal mobil sein (Akku). Dass bedeute der Energieverbrauch sollte so gering wie möglich sein.
Joachim J. schrieb: > Da die Developmentboards sehr teuer sind Nicht unbedingt. Gibt auch im Bereich von so 100 bis 500 Dollar schon einiges an Auswahl. Eine Übersicht über Developer Boards und Preise gibt es zum Beispiel hier: http://www.digikey.com/product-search/en/programmers-development-systems/evaluation-boards-embedded-mcu-dsp/2621773 Wenn es auch ein Mikrocontroller sein darf und nicht zwingend ein DSP sein muss, ist die Auswahl noch sehr viel größer. > Ich möchte die empfangenen Bilddaten (geringe Auflösung rund 80000 pixel > zu je 12bit) auswerten (Mittelwerte, FFT, Filterung, ...) und das mit > einer Framerate von 60 bis eventuell 120fps. Die zu verarbeitende Datenmenge wäre demnach: (80000 * 12 Bit) / (8 * 1024 ) = 117,1875 KB pro Frame bzw. das 60-fache davon: 6,8665 MB pro Sekunde > Das ganze Projekt soll später mal mobil sein (Akku). Dass bedeute der > Energieverbrauch sollte so gering wie möglich sein. Wenn Du es super energiesparend haben willst, verzichte auf Bluetooth/WLAN und nimm lieber n Kabel ;-)
:
Bearbeitet durch User
Mark B. schrieb: > Wenn es auch ein Mikrocontroller sein darf und nicht zwingend ein DSP > sein muss, ist die Auswahl noch sehr viel größer. Der Knackpunkt ist die große Datenrate und der Auswertealgorithmus. Zwischen jedem Frame werden Filterungen eingesetzt und mittelwerte berechnet und alle 1-2 Sekunden eine FFT ausgeführt und dessen Ergebnis wieder ausgewertet. anschießend werden die Ergebnisse übertragen. ein dsp ist nicht Pflicht, schien mir aber angebracht. > Wenn Du es super energiesparend haben willst, verzichte auf > Bluetooth/WLAN und nimm lieber n Kabel ;-) Auf Grund des Einsatzgebietes komme ich an einer Funkübertragung leider nicht vorbei. Eine spätere Applikation soll dann auch mit einem Handys kommunizieren können. also Bluetooth ist wohl Pflicht.
:
Bearbeitet durch User
Joachim J. schrieb: > Der Knackpunkt ist die große Datenrate und der Auswertealgorithmus. > Zwischen jedem Frame werden Filterungen eingesetzt und mittelwerte > berechnet und alle 1-2 Sekunden eine FFT ausgeführt und dessen Ergebnis > wieder ausgewertet. anschießend werden die Ergebnisse übertragen. ein > dsp ist nicht Pflicht, schien mir aber angebracht. Nun, dann würde ich hergehen und überschlagsweise berechnen, wieviel Speicher und welche Rechenleistung der DSP haben soll. Also z.B. Pro Frame: Speicher für die Rohdaten (hier also ca. 120 KB) + Speicher für die Mittelwertberechnung + Speicher für die digitalen Filter (je nach Filterordnung) Plus Speicher für die Fouriertransformation. Bei der Rechenleistung dann ähnlich, also abschätzen wieviele Multiplikationen und Additionen man in jedem Zyklus (also pro Frame) benötigt. Also 79999 Additionen und eine Division für den Mittelwert + Operationen für die digitalen Filter je nach Filterordnung + Fouriertransformation abhängig davon wieviele Punkte man verwendet. Man kann das auch bis auf die siebte Stelle hinterm Komma ausrechnen, und dann zur Sicherheit Faktor 2 draufschlagen. ;-)
:
Bearbeitet durch User
Hallo, also dann kommen ja auch eine Menge an Bildfilter Algo´s dazu. Das ganze kann schon etwas Rechenleistung verbrauchen. Deine CPU sollte auf jeden fall ein Camera IF Modul haben und Notfalls auch einen TFT-Display Anschluss, könnte sehr hilfreich sein beim Debuggen. mein Vorschlag: Cortex M4F z.B. ST STM32F429 Cortex M7F z.B. Atmel CM7 E70,V70 Reihe ansehen Wenn die CPU ohne Flash auch sein kann würde ich einen Cortex A5 nehmen. Wenn du aber full HD machen willst, wirds eng! 80000 Pixels würde ungefähr 320x240 QVGA entsprechen, das müsste noch machbar sein. Gruß Sascha
Überschlagen wir mal: pro Frame: Ich habe man an der Kamera gemessen Frame rate: 102,56Hz 100 Zeilen mit je 990 Pixeln 5,1ms Übertragungszeit pro Frame 4,6ms Berechnungszeit Pro Frame 33,7us Übertragungszeit pro Zeile(990 Pixel/Zeile) Pixelclok 29,33MHz pro Pixeltakt werden 12bit eingelesen und zwischengespeichert (interupt, 12bit einlesen, in Speicher schreiben, Pointer erhöhen(zeile spalte), ein bis zwei Eingänge abfragen) da kommt ganz schön was zusammen. Ich könnte den Pixelclok, bei gleichbleibender Frame rate, auch verringern, aber dann wird die Übertragungszeit/Frame größer und die Berechnungszeit kleiner. 4,6ms ist viel Zeit aber ich weiß noch nicht wie aufwendig die Berechnung schlussendlich werden wir. Zu welche Taktfrequenz würdet ihr mir raten? 200MHz/30MHz=6 Operationen ist wohl zu wenig. Speicher: 100 Zeilen * 990 Spalten = 99000Pixel 16bit Variablen weil es 12bit Variablen nicht gibt:) 99000*16bit/2 = 792000 Byte = 792 KByte/Frame Mittelwerte voraussichtlich 2KByte Filterung der Mittelwerte geschätzt 6KByte variablen und Pointer pauschal 1KByte FFT geschätzt 5KByte summe gerundet: 810KByte da das Programm und auch der exakte auswerte Algorithmus noch nicht Entwickelt sind, kann ich hier nur schätzen.
Joachim J. schrieb: > 99000*16bit/2 = 792000 Byte = 792 KByte/Frame Du hast da mit Bit/Byte durcheinander gerechnet. Je nach Algorithmus könnte ein 500MHz Blackfin das schon schaffen. Ein Cortex-M4 packt es jedenfalls sicher nicht. > habe lediglich mal einen Blackfin gesehen. > Da die Developmentboards sehr teuer sind eigenwerbung Schau mal im Markt Forum nach Blackfin, vielleicht findest Du da ja was passendes.
D. H. schrieb: > Joachim J. schrieb: >> 99000*16bit/2 = 792000 Byte = 792 KByte/Frame > > > Du hast da mit Bit/Byte durcheinander gerechnet. stimmt sorry Denkfehler (2byte pro Var aber 8bit/Byte) 99000*16bit/(8bit/Byte) = 198000 Byte = 198 KByte/Frame
:
Bearbeitet durch User
D. H. schrieb: > *eigenwerbung* > Schau mal im Markt Forum nach Blackfin, vielleicht findest Du da ja was > passendes. Das Angebot ist echt gut Beitrag "[V] Blackfin DSP BF548, BF537, Industrie Module, BF533 Stamp, Evalboards, ICEbear USB JTAG" :) Doch diese Jahr werde ich das nicht mehr entscheiden. Ich komme darauf vielleicht im nächsten Jahr nochmal zurück.
:
Bearbeitet durch User
Tach, für die 1.8V I/O musst du ev. auf einen der neueren Typen (BF51x) zurückgreifen. Ansonsten kann ich nach rund 10 Jahren Kamerabau mit gutem Gewissen Fazit ziehen: Für die meisten nicht 0815-Entwicklungen hat der Blackfin die Nase vorn und ist unterm Strich in der Entwicklung am günstigsten. Wenn Stromsparaspekte noch dazukommen, gibt's eigentlich kaum eine Alternative bei optimaler (minimaler) mW/MIPS. Nur der Toolwirrwarr und der inhomogene Support von ADI ist mühsam, das kann TI etwas besser, die Inhomogenitäten findet man dort eher auf dem Chip :-) Zur FFT gibt es für den Blackfin einiges an asm-optimierten libraries, allenfalls muss man noch die 2D-Sachen etwas optimieren, aber die Einarbeitung in bfin-assembler lohnt sich eh. Grüsse, - Strubi
Joachim J. schrieb: > Das ganze Projekt soll später mal mobil sein (Akku). Dass bedeute der > Energieverbrauch sollte so gering wie möglich sein. Ich würde bei diesen Anforderungen ein FPGA wählen. Der Vorteil ist, dass bei Bildverarbeitung viel parallel ablaufen kann, und da ein FPGA letztendlich nur programmierte Logik ist, wo ohnehin alles parallel abläuft, kommt dies Deiner Aufgabe sehr entgegen. Sämtliche Anbieter von Industriekameras (ich weiß es von Basler, AVT und IDS sicher) haben intern ein gar nicht so fettes FPGA, wo die aufwändigen Dinge per Logik erledigt werden und die Kommunikation per Softcore implementiert ist. Dazu ein DRAM-Chip für den Softcore und die Buffer und ggf ein Gigabit-Ethernet-PHY zum Rausschaufeln der Daten. Diese Hersteller verwenden alle auch nur die üblichen, am Markt erhältlichen Bildsensor-Chips. Schau Dir mal als Beispiel das hier an: https://de.ids-imaging.com/store/produkte/kameras/ui-5581le.html Da siehst Du, wie so eine Kamera von innen aussieht. Vorne der Sensor von Aptina, auf der Rückseite ein Altera-FPGA (mit Aufkleber), ein RAM-Chip von Hynix, ein Gigabit-Ethernet-PHY, Magnetics, RJ45 und etwas Kleinkram. So, wenn die Profis das alle so machen (und das machen sie), dann solltest Du Dir wirklich überlegen, ob Du gute Gründe zusammen bekommst, um es anders zu machen. "Keine Ahnung" ist kein hinreichender Grund! fchk
Strubi schrieb: > für die 1.8V I/O musst du ev. auf einen der neueren Typen (BF51x) > zurückgreifen. Der Sensor kann auch 2.8V. Ansonsten Levelshifter.
Frank K. schrieb: > Joachim J. schrieb: > >> Das ganze Projekt soll später mal mobil sein (Akku). Dass bedeute der >> Energieverbrauch sollte so gering wie möglich sein. > > Ich würde bei diesen Anforderungen ein FPGA wählen. Der Vorteil ist, > dass bei Bildverarbeitung viel parallel ablaufen kann, und da ein FPGA > letztendlich nur programmierte Logik ist, wo ohnehin alles parallel > abläuft, kommt dies Deiner Aufgabe sehr entgegen. > Hast Du dir denn die Anforderungen oben mal durchgelesen? - Stromsparend (!) - Bluetooth-Komm. - Etwas komplexere Operationen wie FFT Es gibt also hier keinen Grund ein FPGA zu nehmen, warum die Sache unnötig verkomplizieren? > So, wenn die Profis das alle so machen (und das machen sie), dann > solltest Du Dir wirklich überlegen, ob Du gute Gründe zusammen bekommst, > um es anders zu machen. "Keine Ahnung" ist kein hinreichender Grund! > Die Profis bauen ihre intelligenten Kameras sehr oft auf Blackfin-Systemen auf, ein grosser z.B. ist Cognex. FPGAs machen nur Sinn, wenn man eine lineare schnelle Verarbeitungspipe braucht (wie Debayering oder Vorfilterung). Ein paar "Profis" mit grossem Namen bauen in der Tat komplexe Systeme mit UDP-Stacks und GenIcam auf FPGAs auf, aber das sind oft von-hinten-durch-die-Brust-Designs, die muss man nicht unbedingt nachmachen. Stromsparend ist da schon mal nix mehr, und die Entwicklungskosten sollte man auch mit einrechnen. Cheers, - Strubi
Ich habe auch ein paar Profi-Kameras von AVT und Baumer auf dem Schreibtisch. Die werden teilweise so warm, dass man sie kaum anfassen kann. Und FPGAs sind nicht gerade fürs Stromsparen bekannt. Ich würde das umgekehrt aufziehen. Alles erst mal auf einem großen Prozessor berechnen Intel/Arm. Und wenn alle Algorithmen laufen, dann berechnen/messen, welche CPU-Leistung wirklich benötigt wird und dann erst eine passende kleine CPU wählen. Evtl muss da ja auch noch ein RTOS oder Mini-Linux drauf laufen. Das sollte auch bedacht werden.
PittyJ schrieb: > Ich würde das umgekehrt aufziehen. Alles erst mal auf einem großen > Prozessor berechnen Intel/Arm. Und wenn alle Algorithmen laufen, dann > berechnen/messen, welche CPU-Leistung wirklich benötigt wird Ich würde das genau so machen. Es ist sinnlos, sich von vorn herein auf etwas festzulegen, ohne zu wissen, was man überhaupt braucht. Bitte beachten: ich unterscheide hier braucht unbedingt von will!
:
Bearbeitet durch Moderator
Frohes neues Jahr:) da bin ich wieder PittyJ schrieb: > Ich würde das umgekehrt aufziehen. Alles erst mal auf einem großen > Prozessor berechnen Intel/Arm. Und wenn alle Algorithmen laufen, dann > berechnen/messen, welche CPU-Leistung wirklich benötigt wird und dann > erst eine passende kleine CPU wählen. > Evtl muss da ja auch noch ein RTOS oder Mini-Linux drauf laufen. Das > sollte auch bedacht werden. genau so habe ich jetzt angefangen. ich habe mir ein DART-MX6 von Variscite besorgt. Diese hat sogar eine Schnittstelle für eine Parallele Kamera. Damit werde ich das erste Bildmaterial aufnehmen und auswerten und den Algorithmus entwerfen. Ich gehe aber davon aus, dass die hohe Übertragungsrate der Kamera die Taktfrequenz vorgibt. Der Algorithmus wird klein und kompakt. Erst werden die rund 80000 Pixel mit Hilfe von Mittelwertberechnung verringert auf rund 1500 werte. Dann eventuell ein filter. Aus diesen 1500 werten wird der erste Messwert abgeleitet. Danach werden die 1500 werte zu einem zusammengefasst. Dieser eine Messwert (100/s) wird gespeichert und dann mit 1000 werten (t=10s) in die FFT geschickt. Im Anschluss kann man weitere Messwerte ableiten. Ich erwarte das der Algorithmus nicht viel Rechenleistung benötigen wird. Die Kamera hingegen sendet 12bit pro Pixel Paralel und der Pixelcolck wird wohl bei 20-30MHz liegen. (80000 Pixel/Bild 100 Bilder/s) Ich habe auch schon an so was wie DMA gedacht aber nichts gescheites gefunden. Ein paralleler Port mit 12bit der abwechselnd in zwei Speicherbereiche schreibt. Während das eine Bild in den ersten Speicherbereiche geschrieben wird, wird das andere im anderen Speicherbereiche ausgewertet. Bei 100 Bilder/s ist zur Auswertung viel Zeit, so das eine recht kleine Taktfrequenz reichen würde(z.B.50MHz).
:
Bearbeitet durch User
Hallo Joachim, ein Camera Interface der Controller macht alles genau das was du willst. Sie haben eine DMA, erzeugen die Clocks und übernehmen die 12 Bit Parallel zur DMA bis in den Speicher. Dazu sortieren oder konvertieren sie auch noch die Pixeldaten nach RGB in verschiedene Formate. Nach jedem Frame kannst du dir einen Interrupt erzeugen lassen, und die neue Adresse des übernächsten Frames im Speicher angeben. Was will man mehr. Stichwort: Camera IF, Camera Interface. Einfach mal Datenblätter studieren. gruß Sascha Nur mal so als Beispiel: http://www.atmel.com/images/Atmel-11296-32-bit-Cortex-M7-Microcontroller-SAM-E70Q-SAM-E70N-SAM-E70J_Datasheet.pdf PS. es gibt auch noch bessere ISI-Interface.
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.