Mittlerweile hab ich ein bißchen geschmökert...

Noch kurz zum Überlauf. Ich meine, die Graustufenauflösung durch Weglassen des untersten Bits auf 128 vergröbern, und das oberste Bit quasi als Offset beim Dunkelbild weglassen, und beim Signalbild setzen. Dann kann die Differenz nur zwischen 1 und 128 liegen. Soo verdreht sind die Daten dann auch nicht. Aber das sind Details.

Wichtig ist mir, welcher Prozessor?
Nach einigem Herumgelese stelle ich fest, hobbymäßig sind vor allem der Philips LPC21.. und der Atmel AT91.. verbreitet, beides sind ARM7. Was drüber liegt, brauche ich wohl nicht.
Viel wurde über die Geschwindigkeit diskutiert.
Ich glaube, die höchste Geschwindigkeit brauche ich beim Sampeln, aber gerade da sinds wohl nur ein paar Port- und Speicherzugriffe und da ist der Geschwindigkeitsvorteil eines ARM gar nicht so groß.
Bin daher am Überlegen, ob ich vielleicht auch mit einem ATMega64 zurechtkomme. Der wäre halt geradeaus 8Bit und bei meiner Anwendung, wo es nur große Mengen an 8bit-Daten herumzuschieben, bestenfalls zu vergleichen und aufzusummieren gilt, vielleicht sogar besser geeignet. Allerdings ist er fast teurer als der ARM, und einen externen Speicher muß ich auch dazufrickeln, was die Platine wieder aufwendiger macht.

Vielleicht muß man sich mal darüber klarwerden, was ich mit den gesampelten Bildern machen will.

Weiter oben im Thread habe ich schon einen Link auf meine Anwendung gegeben, es geht also im Prinzip darum, das Differenzbild Spalte (!) für Spalte durchzugehen und den hellsten Punkt zu suchen.

Vielleicht gibt es aber pfiffigere Verfahren als die sture Suche nach dem Maximum - zum Beispiel Mustervergleich mit einem einige Pixel breiten Peak. Das könnte dann fehlertoleranter bei einer Spalte mit verrauschten Daten und einem sehr schwach ausgeprägten hellsten Pixel sein. Oder man macht eine Plausibilitätskontrolle mit den benachbarten Spalten, wo ist dort der hellste Punkt? Diese Ideen vergrößern natürlich den Rechenaufwand.

Danach werden dann den hellsten Punkten anhand eines einmal aufgenommenen Kennfelds Entfernungen zugewiesen. Das erscheint mir einfacher als das herumjonglieren mit trigonometischen Funktionen. Und zuletzt steht ein Entfernungsprofil im Speicher, das über UART übertragen werden kann.

Das habe ich jetzt mal so explizit geschrieben, damit man den Rechenaufwand abschätzen kann.

Übrigens: Über das Videosignal habe ich mich bei Wikipedia schlau gemacht. Es ist schon so, ein S/W-Videosignal ist ab dem HSync nur noch ein analoger Verlauf der Grauwerte. Man kann also mit einem freilaufenden Algorithmus sampeln und muß eben über NOPs oder kleine NOP-Schleifen den Pixelclock anpassen, sowie die Pixel mitzählen. Man muß doch auch mit einem ARM ein ganz hartes Timing des Programmablaufs hinbringen, oder?