Wieviel internen Speicher haben DSLRs?

[Gondomir]

Die Canons haben alle Arbeitsspeicher, wie in einem normalen PC. Denn sie sind PCs, sog. embedded PC. Die ersten Modelle (300D/10D) hatten die Embedded Variante des 8086, den 80186 Prozessor integriert. Der 80186 hat den gleichen Kern wie ein 8086 nur dass zusätzliche Komponenten, wie z.B. die RTC direkt auf dem Chip integriert sind.

Leider kann ich auf die Schnelle nicht herausfinden wieviel Arbeitsspeicher diese embedded Rechner haben. Aber wen es wirklich interessiert kann dies sicherlich mit Google selber herausfinden.

Übrigens hier ein paar mehr Informationen dazu:
- Schnellübersicht: http://wiki.alexbernstein.com/CanonDigitalRebelHacking
- Bilder: http://wiki.alexbernstein.com/ImageProcessingCircuitBoard

PS: Der DIGIC-Prozessor für die Bildberechnungen wird vom embedded PC gesteuert. Auf diesen läuft übrigens eine Variante von MS-DOS .

Der "embedded" Prozessor ist anscheinend ein emulierter NEC V30. V30 sind 80186 kompatible Prozessoren und können daher nur 1MB RAM ansprechen. Deswegen denke ich dass der nur für Menü usw. zuständig ist und JPEG/RAW Handling wohl der Digic macht.

 

[Christof Abt]

Der "embedded" Prozessor ist anscheinend ein emulierter NEC V30. V30 sind 80186 kompatible Prozessoren und können daher nur 1MB RAM ansprechen. Deswegen denke ich dass der nur für Menü usw. zuständig ist und JPEG/RAW Handling wohl der Digic macht.

Da hast du recht. Eine so alte Gurke wie der 8086 wäre mit der Bildbearbeitung überfordert. Der Digic muss ein Spezialprozessor sein, auf dem Bildbearbeitungsroutinen hart implementiert sind. Ohne solch festverdrahtete Logik wäre die Geschwindigkeit nicht zu erreichen. Überlegt mal, wie lange ein leistungsfähiger Computer zur Wandlung der RAW in eine TIFF oder JPG Datei braucht. Ich kann mir auch nicht vorstellen, dass die AF-Software auf dem 8086 läuft. Ich finde die Fragestellung nicht unpräzise. Ein Schulbub hat von dem Thema eben noch nicht die Ahnung.
Gruß Christof

 

[LGW]

Ich wollte aber auch sagen - eine Kröte wie ein 80286 oder gar noch langsamer wäre absolut nicht im Stande, in halbwegs vertretbarer Zeit so was wie eine RAW-Konvertierung zu machen. Dafür braucht ja auch ein aktueller Pentium durchaus mal mehr als ne Sekunde. Ich hab die Dinger damals mit Assembler gequält, und an sowas wie "13MB *kopieren*" hätte man schon nicht wirklich im Traum gedacht

Nene, für Bildverarbeitung werden eigentlich immer Spezialprozessoren eingesetzt. Aber so gut kenne ich mich mit dem Innenleben nicht aus, das war nur ein "Educated Guess"

 

[MI5]

Himmelhergottnochmalsackzement.

Für eine präzise Berechnung sicher nicht zu gebrauchen, aber als Näherungswert, mit ein bischen rechnen und schätzen, sicher.

Wenn ich auslöse, und wenn die Framerate einbricht, den Auslöser loslasse. bekomme ich ungefähr die Anzahl an Bildern die in den Puffer passt. Und ich glaube nicht das die Kamera schneller weg als reinschreibt, schliesslich bricht die Framerate ja ein. Also kann da nicht viel auf der Karte sein, wenn der Puffer vollläuft.

Vor 2 Jahren habe ich mir einen Neuwagen gekauft. Da legt man 25.000 EUR auf den Tisch und der Tank ist noch nicht einmal voll, eine Frechheit. Naja, seitdem tanke ich jeden Mittwoch 20 Liter Diesel und der Wagen fährt wie eine Eins.
Letzten Mittwoch ist mir was unglaubliches passiert. Ich war mal wieder an der Tanke und als ich versuchte 20 Liter Diesel zu tanken ist der Diesel nach ca. 19 Liter ausgelaufen. Das ist mir vorher noch nie passiert!

Dann dachte ich mir "Komm Junge streng mal deinen Kopf an". Ich strengte mich an und fing an ein bischen zu rechnen und zu schätzen und kam auf eine Tankvolumen von sage und schreibe 2079 Liter (2*52*20-1). Könnt ihr euch das vorstellen? Ich weiss gar nicht wo da unter dem Rücksitz soviel Platz sein soll. Aber das müsste nach meiner Schätzung stimmen.

Oder habe ich da was falsch geschätzt?


Ein Freund von mir (er ist eher der Theoretiker) sagte mir allerdings das mein Tankvolumen maximal 2079 Liter betrage. Dann fing er an sich selbst zu widersprechen und sagte mir das mein Tankvolumen unmöglich 2079 Liter betragen kann weil ich keinen Perpetuum Mobile hätte. Was ein Schwätzer, woher soll der wissen was ich habe?

Ich bleibe dabei mein Tankvolumen müsste ziemlich genau, ungefähr, geschätzte, 2079+- Liter betragen.

 

[LGW]

Was fürn Blödsinn.

 

[PinguTS]

Das ist richtig, dass der V30 nicht die Bildbearbeitung übernimmt. Deswegen hatte ich oben auch geschrieben, dass er den DIGIC steuert. Aber nur der V30 hat Zugriff auf die Flash-Karte, also müssen alle Bilder da durch

 

[BuzzJoe]

Da hast du recht. Eine so alte Gurke wie der 8086 wäre mit der Bildbearbeitung überfordert. Der Digic muss ein Spezialprozessor sein, auf dem Bildbearbeitungsroutinen hart implementiert sind. Ohne solch festverdrahtete Logik wäre die Geschwindigkeit nicht zu erreichen. Überlegt mal, wie lange ein leistungsfähiger Computer zur Wandlung der RAW in eine TIFF oder JPG Datei braucht. Ich kann mir auch nicht vorstellen, dass die AF-Software auf dem 8086 läuft. Ich finde die Fragestellung nicht unpräzise. Ein Schulbub hat von dem Thema eben noch nicht die Ahnung.
Gruß Christof

Hartverdrahtet glaube ich gar nicht mal unbedingt. Allerhöchstens einige Routinen, die wirklich nicht mehr geändert werden müssen.
Alles Andere wird eventuell über eine Art Shaderprogramme laufen, wie sie auch auf Grafikkarten zu finden sind. Also eine Art halbprogrammierbare Sub-Logikhardware ( )
Ich komme nur darauf, weil man ja auch mit Firmwareänderungen schon viel erreichen kann. Deshalb wird der Digic-Prozessor wohl eine Art "Abstellplatz" für direktverdrahtete Berechnungen sein, die nicht geändert werden müssen oder können (Teile der JPEG-Komprimierung) und zusätzlich diese Halbblut-Hardware enthalten. Das so als Überlegung. Aber durchaus interessant

Es ist ja auch eine Sache der Geschwindigkeit und des Stromverbrauchs... Software ist nunmal langsam und braucht dadurch viel Strom. Andererseits ist sie aber auch flexibel. Deshalb glaube ich wirklich, dass man da wohl eher so ein Hybridding aus Hard- und Software gebaut hat. Denn gerade in Sachen Fehlerbeseitigung ist Software eindeutig die einfachere Variante

 

[LGW]

Letztlich geht es darum, bestimmte Rechenoperationen speziell zu beschleunigen, indem man sie direkt in Hardware implementiert. Ob das dann ein ganzer JPEG-Algorithmus ist, oder nur ein paar Transistoren die direkt eine DCT machen können, obliegt wohl in erster Linie dem Hersteller.

Wäre mal interessant, den kompletten Aufbau zu kennen, aber das rückt wohl kaum jemand raus...

Software per se ist auch nicht "langsamer" oder "schneller" als Hardware.

Aber wenn man bspw. nur Multiplikation und Division jeweils zweier Ganzzahlen zur Verfügung hat (8086/80286), aber ständig ganz bestimmte Operationen durchführen muss, so lassen sich diese Operationen eben gezielt in "Hardware implementieren". Man könnte bspw. einen Chip bauen, der sehr schnell sowas ausrechnen kann wie:

(x+y)*z = ?

Wobei man x,y,z reinwirft, und hinten sofort ? rauskommt.

Würde man das mit einem herkömmlichen 8086-Chipsatz machen, würde das etwa so aussehen:

mov ax, es:[di]
mov bx, es:[di+4]
add ax,bx
mov bx, es:[di+4]
imul bx

oder so ähnlich, ganz schön lange her. Dabei benötigen alleine die Speicherzugriffe 2 Taktzyklen, der add auf dem 8086 bestimmt auch noch 2-4, und der imul skaliert auf dem 8086 glaube ich noch mit l2(bx) oder so was furchtbarem. Sprich: je nach Eingangszahlen ist die CPU Ewigkeiten beschäftigt, weil sie zwar alle Grundrechenarten beherrscht, aber die speziellen Algorithmen damit mühsam "nachbilden" muss - etwa so, wie wir alles der Reihe nach in einen Taschenrechner tippen müssten.

Und dabei hat man dann nur mit 16-Bit-Zahlen gerechnet, mehr kann der gar nicht - ohne Kunstgriffe und Überlaufbehandlung. Ein entsprechend angepasster Chipsatz könnte hingegen ohne weiteres und ganz entspannt 64-Bit-Floats in <8 Taktzyklen verrechnen, ein entsprechend breiter BUS vorausgesetzt... aber das lässt sich ja alles bauen. Einfach, indem sämtliche "Einzeloperationen" fest als "ein Befehl" verdrahtet sind. Mit einer entsprechend großen Anzahl an "Taschenrechnern" lässt sich dann eine komplexe Berechnung eben auch "auf einmal" ausführen.

Klassisches Beispiel wäre ein MPEG2-Encoder-Chip für Videos. Die kann man schon ziemlich lange so effizient bauen, dass man vorne einfach das uncodierte Video reinwerfen konnte, und hinten kam das codierte Video raus (RAW=>compressed-Converter) - das ging schon zu 80486er-Zeiten in Echtzeit, als eine normale CPU samt optimierter Software noch ohne weiteres ein vielfaches der Zeit herumrechnen musste.

Das Ding (8086) wurde zwar noch in div. Weltraum-Missionen der NASA eingesetzt, aber in aktuellen Kameras dürfte es allenfalls zur Knopf- und Bildschirmsteuerung herhalten oder so

 

[Christof Abt]

Hallo BuzzJoe und LGW,
ich denke nicht, dass man bei dem DIGIC um festverdrahtete Logik herumkommt. Man braucht ja zum Beispiel auf jeden Fall eine diskrete Cosinustransformation bei der JPEG Komprimierung. Warum sollte man das im Programm machen. Das dauert nur länger und braucht mehr Strom, aber wissen tu ich's auch nicht. Man könnte auch programmierbare Bausteine wie zum Beispiel FPGAs verwenden, aber die sind auch teurer und brauchen mehr Strom als dezidierte Spezialchips, die sich bei den Stückzahlen auch schon lohnen.
Woher wisst ihr, das tatsächlich ein 8086 oder ein Verwandter in der 40D verwendet wird?
Gruß Christof

 

[LGW]

Weiss ich doch gar nicht - ich argumentiere ja gerade dagegen, und für fest verdrahtete Logik

 

[Frank Klemm]

Ich wollte aber auch sagen - eine Kröte wie ein 80286 oder gar noch langsamer wäre absolut nicht im Stande, in halbwegs vertretbarer Zeit so was wie eine RAW-Konvertierung zu machen. Dafür braucht ja auch ein aktueller Pentium durchaus mal mehr als ne Sekunde. Ich hab die Dinger damals mit Assembler gequält, und an sowas wie "13MB *kopieren*" hätte man schon nicht wirklich im Traum gedacht

Nene, für Bildverarbeitung werden eigentlich immer Spezialprozessoren eingesetzt. Aber so gut kenne ich mich mit dem Innenleben nicht aus, das war nur ein "Educated Guess"

Ach, endlich mal jemand, der kein Hochvakuum zwischen den Ohren hat.

Für die Signalverarbeitung in Canon-Kameras kommen ARM-Prozessoren zum Einsatz,
bis vor kurzem unter dem Betriebssystem VxWorks, mittlerweile (seit knapp einem Jahr)
unter einem selbstentwickelten Betriebssystem DryOS.

[Quelle: Canon Hacker's Development Kit-Forum]

Die Canon EOS 300D hatte einen vergleichsweise langsamen Prozessor in der Kamera, das Puffern geschah dort VOR der Signalverarbeitung und dauerte Äonen.

3 Bilder konnten hintereinander geschossen werden, dann war erst mal für viele Sekunden Ruhe. 2 Bilder davon lauerten im RAM auf die Verarbeitung (2x 16 bit x 6 MPixel = 24 MByte), eines wurde verarbeitet (verbraucht dabei je nach Verarbeitungsstufe 36 MByte [Dematrixierung], 9 MByte [Konvertierung nach YUV, Konvertierung nach JPEG]). Kommt auf ca. 60 MByte. Noch etwas Platz für Programm, Betriebssystem und Dateisystemverwaltung landet man bei 64 MByte.

Für die folgenden Kameras wurde der Bildverarbeitungsprozessor schnell genug, um die Pufferung nach der Signalverarbeitung durchzuführen. Bei Abschätzung der Puffergrößen landet man jeweils in der Nähe von Zweierpotenzen (bei den Kameras mit einem Prozessor), die da wären:

• Canon EOS 350D: 64 MByte
• Canon EOS 400D: 128 MByte
• Canon EOS 450D: 128 MByte
• Canon EOS 20D: 128 MByte
• Canon EOS 30D: 128 MByte
• Canon EOS 40D: 256 MByte
• Canon EOS 5D: 256 MByte

Komplizierter ist es bei Kameras mit 2 Prozessoren, die Canon EOS 1D Mark III könnte 128 MByte (primäre Bildverarbeitung) + 256 MByte (Menüs, CF-Controller, AF) haben.
Das ist jetzt aber hochgradig spekulativ.

 

[Gondomir]

Woher wisst ihr, das tatsächlich ein 8086 oder ein Verwandter in der 40D verwendet wird?
Gruß Christof

Einige Posts vorher hat jemand Links gepostet, da gings aber um die EOS 300D glaub ich. Wenn man da weiterklickt kommt man auf eine V30 Emulation, V30 ist ein 80186er mit Erweiterungen von NEC. Also 16-bit, 1MB Adressraum.

 

[Frank Klemm]

Einige Posts vorher hat jemand Links gepostet, da gings aber um die EOS 300D glaub ich. Wenn man da weiterklickt kommt man auf eine V30 Emulation, V30 ist ein 80186er mit Erweiterungen von NEC. Also 16-bit, 1MB Adressraum.

Eine Prozessor der Klasse 8086 ist zu langsam, um einen Autofokus einer normalen Kamera zu implementieren. Eine Multiplikation von zwei 16 bit-Zahlen dauert zwischen 282 Takten und 399 Takten. Allein die 48 Multiplikationen für das Dematrixieren eines 6 Megapixelbildes würden auf einem mit 20 MHz getakteten 8086 etwa 90 Minuten dauern!

Divisionen (16 bit, nicht etwa Gleitkomma!) dauerten 749 Takte.

Ein 8086 mit 20 MHz ist für die Aufgaben einer Digitalkamera etwa um den Faktor 10.000 zu langsam. Auch zum MP3-Abspielen wäre er etwa um den Faktor 100 zu langsam.

 

[Gondomir]

Eine Prozessor der Klasse 8086 ist zu langsam, um einen Autofokus einer normalen Kamera zu implementieren.
...
Ein 8086 mit 20 MHz ist für die Aufgaben einer Digitalkamera etwa um den Faktor 10.000 zu langsam. Auch zum MP3-Abspielen wäre er etwa um den Faktor 100 zu langsam.

Sagte ich doch, der ist höchstens fürs Menü zuständig. Weisst du welcher ARM? Ein ARM9 mit >300MHz dürfte bestimmt schon reichen.

 

[Frank Klemm]

Sagte ich doch, der ist höchstens fürs Menü zuständig. Weisst du welcher ARM? Ein ARM9 mit >300MHz dürfte bestimmt schon reichen.

Keine Ahnung.

Die "Spezialität" dieses Prozessors dürfte ohnehin in den 15 bis 20 Spezialbefehlen, die im SoC stecken, liegen. Mehroperandenbefehle für Dematrixing, Schärfen und Rauschfilter, Farbraumumwandlung, JPEG- und RAW-Konvertierung.

Alles Befehle, die in 1 bis 2 Takten abgearbeitet werden und die mit herkömmlichen Befehlen viele Takte dauern würden.

 

[Christof Abt]

Keine Ahnung.

Die "Spezialität" dieses Prozessors dürfte ohnehin in den 15 bis 20 Spezialbefehlen, die im SoC stecken, liegen. Mehroperandenbefehle für Dematrixing, Schärfen und Rauschfilter, Farbraumumwandlung, JPEG- und RAW-Konvertierung.

Alles Befehle, die in 1 bis 2 Takten abgearbeitet werden und die mit herkömmlichen Befehlen viele Takte dauern würden.

Hallo Frank,

ein ARM kommt mir schon wesentlich wahrscheinlicher vor. Die von dir erwähnten Spezialbefehle für die Bildverarbeitung hat ein Standard-ARM aber nicht. Die muss der Kunde, in diesem Fall Canon, dann selbst implementieren.
Gruß Christof

 

[LGW]

Macht ja nichts, sowas wird auch gerne in externe Chips gesetzt. Im Video-Bereich wie gesagt seit Jahren gang ung gäbe.

 

[Sebastian W.]

Den Fehler durch das Wegschreiben der Bilddaten auf die Speicherkarte während einer Serienbildreihe lässt sich nährungsweise bestimmen, indem man die Zeit zwischen erstem Aufleuchten der Speicher-LED und dem Erlöschen misst und eine konstante und pausenlose Datenübertragung unterstellt..

 

[Frank Klemm]

ein ARM kommt mir schon wesentlich wahrscheinlicher vor. Die von dir erwähnten Spezialbefehle für die Bildverarbeitung hat ein Standard-ARM aber nicht. Die muss der Kunde, in diesem Fall Canon, dann selbst implementieren.

Firmen wie z.B. Micronas (http://de.wikipedia.org/wiki/Micronas) stellen Designtools zur Verfügung,
mit denen man aus vorgefertigten Funktiongruppen selbst Chips designen kann.
Für so einen Kameraprozessor kann das dann in etwa so aussehen:

• Design für eine Betriebsspannung von 1,8 V
• ARM7-Kern mit 400 MHz
• 32 bit-Interface für DDR2-400 RAM (macht theoretisch 1600 MByte/s)
• 8 KByte Zwischenspeicher für zeitkritischen Programmcode
• 32 KByte Zwischenspeicher für Daten
• 4x 1 KByte für Lookup-Tabellen
• 2 LVDS-Links + DMA für Anbindung des Bildsensors
• 1 LVDS-Link + DMA zur Anbindung des AF-Sensor-Controllerchips (an dem dann die 7 bis 45 AF-Sensoren hängen)
• 1 LVDS-Link + CRT zur Anbindung des Displays
• CRT-Controller + PAL/NTSC-Videomodulator für Videoanschluß
• 1 LVDS-Link + DMA zur Anbindung der Belichtungsmessung
• Port zur Ansteuerung von bis zu 32 Tasten + andere Eingabesensoren (bis hin zur Akkuklappe und der Detektion eines externen Blitzgeräts)
• Port zur Ansteuerung von bis zu 3 Tasten, die den Prozessor aus dem Tiefschlaf aufwachen lassen können
• USB 2.0-Port
• Port zur Anbindung einer SD-Karte und einer CF-Karte
• IO zur Ansteuerung der Speicher-LED
• CMOS-Uhr + CMOS-Speicher für wichtige Einstellungen + Anschluß Stützbatterie
• 6 bit-AD-Wandler zur Überwachung der Betriebsspannung
• IO zur Ansteuerung von Objektiven, Klappspiegel und Verschluß
• IO zur Ansteuerung von Monochrom-LCD-Displays auf der Kamera und im Sucher + Helligkeitssteuerung
• IO zur Blitzsteuerung (Kommunikation, Blitz-Taste, Blitz entriegeln, Blitz ist entriegelt?, Blitzauslösung, Kommunikation externer Blitz)
• 128 bit-Spezial-ALU für Bildverarbeitung (ähnlich zu Intels MMX/SSE)
• Spezialbefehle zur hochwertigen Dematrixierung (12/14 bit Bayer-Pattern => 3x 16 bit RGB)
• Spezialbefehle zur Farbraumumrechnung (Linear RGB => Gamma YUV)
• Spezialbefehle zum hochwertigen Schärfen und Rauschfiltern
• Spezialbefehle für die DCT und iDCT
• DMA-Controller mit einfacher Bildverarbeitung für Liveview
• Anschluß für Flash-Speicher mit Betriebssystem + Kameraprogramm
• Beeper-Anschluß
• Ansteuerung AF-LEDs

Das ganze ist dann ein Chip, auf dem der ursprüngliche ARM-Kern vielleicht
15% bis 20% der Chipfläche ausmacht. Der Rest sind die ganzen Zusatzfunktionen
(die man bei derzeitigen PCs in der North- und South-Bridge konzentriert hat),
dran kommen noch 2 oder 4 RAM-Chips, ein über einen seriellen Link
angeschlossener Boot-Flash und fertig ist das System.

Auch wenn diese Funktionalität auf ein Chip konzentriert ist, es kommt noch genug
Schmodder für den ganzen anderen Rest zusammen (externe Sensoren, wie Bildsensor,
AF, Belichtungssteuerung, Eye-Sensor, Spannungswandler, internes Blitzgerät, AF-LEDs,
Beeper, ...), man braucht keine Angst zu haben, es wird auch so eng genug in einem
Gehäuse einer 400D oder 450D.

Eine Mehrchiplösung würde bei den Stückzahlen, mit der Kameras wie die 400D, 450D, 30D
und 40D verkauft werden, für Canon Millionenmehrkosten verursachen. Auf andere Chips
auszulagern lohnt sich nur für Dinge, die Millionen von Transistoren benötigen und die
es als kostengünstiges Konsumgut gibt (RAM, Flash) oder die extern sein müssen, weil sie
sich an einem speziellen Platz befinden müssen.

 

[Frank Klemm]

Macht ja nichts, sowas wird auch gerne in externe Chips gesetzt. Im Video-Bereich wie gesagt seit Jahren gang und gäbe.

Einige Operationen erfordern sehr hohe Datenraten (~ 5 GByte/s). Diese werden kaum auf externe Chips ausgelagert, sondern eher in der Nähe des CPU-Kerns.

Bei Video kann das wieder ganz anders aussehen, wenn man die Verarbeitung vollständig auf einen externen Chip verlagert.

Wenn man Funktionalität auf mehrere Chips verteilt, ist eine der kompliziertesten Aufgaben die Aufteilung der Aufgabe, so daß zwischen Funktionsblocks nicht zu große Datenraten auftreten und das vor allem diese nicht kritisch auf Latenzzeiten reagieren.