mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Brauche Uhr/Zähler/Generator mit Frameanzeige und 100stel Sekunden, RS232 Anschluß


Autor: Andreas M. (kautschuknagel)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Guten Tag zusammen,

ich brauche einen Generator mit den folgenden Eigenschaften:

- Anzeige von Stunden:Minuten:Sekunden:fps
- variable Framerate von 1 bis 400 fps
- Start via RS232
- Startzeit frei wählbar

Im Prinzip ist so etwas als Timecodegenerator erhältlich, aber nicht mit 
variablen Frameraten bis 400 fps.

Ich benötige entweder ein fertiges Gerät oder eine Schaltung.
Ob das mit LCD oder Segmentanzeigen oder LED gemacht wird, ist egal. 
Letztlich wird nur eine Hochgeschwindigkeitskamera darauf gerichtet.

Kann mich da jemand erleuchten?

Danke vorab!

Autor: Jonas G. (jstjst)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Ich würde das jetzt mit LEDs und einem mikroc Mikrocontroller aufbauen. 
LED multiplexen braucht man wohl gar nicht probieren wenn es um eine 
highspeed Kamera geht.

Gruß Jonas

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> - Anzeige von Stunden:Minuten:Sekunden:fps

Wo bleiben die 100stel Sekunden aus der Überschrift?

Für die schnelle Anzeige eignet sich eine statisch angesteuerte 
LED-7-Segmentanzeige wie hier: 
http://mino-elektronik.de/7-Segment-Variationen/LCD.htm#led1

Autor: Andreas M. (kautschuknagel)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Korrekterweise handelt es sich nicht um hunderstel Sekunden, sondern um 
Anzahl der Bilder pro Sekunde. Auch hier sind drei Stellen nach der 
Sekundeneinheit benötigt, doch die Länge der Darstellung einer solchen 
Zeiteinheit hängt von der Framerate ab. Das ist dann allerdings eine 
Sache der Software, die die Anzeige ansteuert.

Ich kann bestenfalls eine Platine bestücken, leider reichen meine 
Fertigkeiten nicht für mehr und die Software dazu kann ich auch nicht 
erstellen. Insofern ist der genannte Link sicher hilfreich für jemand 
mit mehr Erfahrung, aber ich kann das nicht auf meine Bedürfnisse 
anpassen.

Highspeed Kameras: Das Maximum, das ich jemals benötigen würde, liegt 
bei 400 Bilder/s. Zu Beginn reichen mir erstmal 100 Bilder/s, also auch 
drei Stellen nach der Sekunde.

Autor: Sebastian S. (amateur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorsicht bissiger Hund!
Viele Anzeigen werden im Multiplexbetrieb betrieben. Das kann man mit 
einer Hochgeschwindigkeitskamera sehen. Ob man dabei noch die 
tatsächliche Zeit zu erkennen kann ist aber fraglich.

Autor: Max D. (max_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, 7-Segs kann man ja einfachst statisch ansteuern. Ein 74HC595 o.Ä. 
pro Digit ist schnell gemacht und wird einfach per Spi aufgefüllt und 
dann gelatcht...

Autor: Sebastian S. (amateur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Max
Das ist mir klar, aber da das bei einer "normalen" Uhr ein unnötiger 
Aufwand ist, ist die Chance groß, das bei einer "gekauften" Uhr der 
Aufwand unterblieben ist.

Autor: Max D. (max_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, der TO hat ja nach "oder Schaltung" gefragt.
Und das war halt ein schaltungsvorschlag...

Autor: Max D. (max_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mir noch einfällt bei "Start via RS232". Bei niedrigeren Baudraten 
ist ein UART-Zeichen länger als 1/400 s. Damit dürfte deine Startzeit 
nichtmehr hinhauen.

Autor: W.A. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Max D. schrieb:
> Was mir noch einfällt bei "Start via RS232". Bei niedrigeren Baudraten
> ist ein UART-Zeichen länger als 1/400 s. Damit dürfte deine Startzeit
> nichtmehr hinhauen.

Und was spräche aus deiner Sicht dagegen, höhere Baudraten zu verwenden, 
abgesehen davon, dass du mit deinem Einwand etwas daneben liegst?
Welches der drei Worte in "Start via RS232" bei der Beschreibung hast du 
nicht richtig verstanden?

Schlimmstenfalls verschiebt sich der Startzeitpunkt um ein paar 
Bit-Zeiten.

Autor: Max D. (max_d)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Der "Start via RS232" ist halt etwas generisch und ich wollte den TO auf 
dieses potentielle Problem hinweisen bevor er mit der fertigen Kiste 
dasteht die dann falsch geht...
Ein Forumspost kostet ja nichts.

Autor: Draco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also die Anzeige soll so sein:

01:12:34.241

Mit nem normalen LCD oder einer normalen 7seg im Multiplex wirst du da 
nicht glücklich. Da du bei deiner Aufnahme jeden Wechsel des LCD oder 
der 7seg Anzeige siehst. Du musst die statisch ansteuern. Das ist halt 
unüblich.

Du musst da 8 Byte (8 Bit x8 Stellen) in den Latch schieben, bei 
400Herz, das dürfte nen AVR8 locker machen. Nur die Frameberechnung wird 
nen bissle tricky ohne mit großartiger Division hinzukommen. Laufen die 
fps mit? Also von 0-n ? Oder stehen die statisch?

Autor: Hp M. (nachtmix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> variable Framerate von 1 bis 400 fps

Wo kommt das Steuersignal dafür her?

Autor: Max D. (max_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also so wie ich das verstanden habe, zählen die letzten drei Ziffern die 
Frames im Verlauf der Sekunde hoch und beim Überlauf zählt die Sekunde.
Was problematisch sein könnte ist die synchronisation der updates auf 
die shutter-öffnung der Kamera. Wenn man grade die grenze erwischt, dann 
hat man evtl. beide Zahlen überlagert dargestellt.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas Mann (kautschuknagel)

>ich brauche einen Generator mit den folgenden Eigenschaften:

>- Anzeige von Stunden:Minuten:Sekunden:fps
>- variable Framerate von 1 bis 400 fps

Wozu braucht man bei High Speed Aufnahmen Stunden und Minuten? So eine 
Aufnahme dauert doch typisch nur ein paar Sekunden.

>- Start via RS232
>- Startzeit frei wählbar

Also per RS232 voreinstellbar. Soll es echtes RS232 sein oder geht auch 
ein virtueller COM-Port über USB? Das wäre zeitgemäßer. Aber 
wahrscheinlich hat euer alter Steuer-PC nur einen echten COM-Port.

>Ich benötige entweder ein fertiges Gerät oder eine Schaltung.
>Ob das mit LCD oder Segmentanzeigen oder LED gemacht wird, ist egal.

Nicht ganz, LCDs brauchen Licht von außen und sind im Normalfall sehr 
langsam. LEDs leuchten selber und können locker Dutzende von kHz sauber 
anzeigen.

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weiter oben hatte ich schon eine statische Ansteuerung einer 
7-Segmentanzeige vorgeschlagen. Auch für µC mit serieller Schnittstelle 
habe ich fertige Sachen in der Schublade: 
http://mino-elektronik.de/7-Segment-Variationen/LCD.htm#led2

Bei dieser Schaltung steuert ein ATmega328 eine 6-stellige Anzeige mit 
13-14 mm Höhe an; die Anzeige ist kaskadierbar, sodaß weitere 3- oder 
6-stellige Anzeigen (Hardware vorhanden) nachgeschaltet werden können. 
Wenn Du mit einem '.' anstatt eines ':' in der Anzeige leben kannst, 
könnte die Hardware direkt verwendet werden. Alternativ müßten zwischen 
den betreffenden Ziffern zwei LEDs den ':' nachbilden.

Die Schaltung kann mit einem trimmbaren Quarz oder TCXO betrieben 
werden, sodaß auch längere Zeitintervalle sehr genau einstellbar sind.
Falls Du an der Schaltung/Programm Interesse haben solltest, kannst Du 
Dich ja melden. Allerdings habe ich erst ab September wieder Zeit.

Draco schrieb:
> Nur die Frameberechnung wird
> nen bissle tricky ohne mit großartiger Division hinzukommen.

Das ist kein Problem, wenn man mit den Timern nett umgeht ;-)
http://mino-elektronik.de/Generator/takte_impulse.htm

Autor: Andreas M. (kautschuknagel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die rege Teilnahme!

Der Wunsch ist, einen Zähler zu haben, der z.B. 25, 30, 50, 60, 100,
120, 160 oder 400 fps darstellt. Bei 25 fps wird die jeweilige Zahl des
Bildes für 40 ms angezeigt, bei 100 fps sind es 10 ms Anzeigedauer, bei
400 fps dann nur mehr 2,5 ms. Ich weiß nicht, welche Technik dazu
eingesetzt werden kann. Der Wechsel von z.B. 01:00:00:023 auf 
01:00:00:024 muß schneller 2,5 ms erfolgen, da die schnellste Kamera 
sonst beide Werte aufnehmen würde.

Mit irgendeinem Wert muß der Zähler ja beginnen. Er soll beliebig
einstellbar sein, etwa 01:00:00:000 oder 12:30:00:000. Ob der mit BCD
Schaltern eingestellt wird oder per Software von einem Raspberry/PC
übermittelt wird, ist egal.

Der Startbefehl muß nicht zwangsweise über RS232 kommen; es kann auch
ein einfacher Taster sein. Wichtig dabei ist lediglich, daß der Start
auch gleichzeitig eine andere Aktion an einem Raspberry/PC auslöst. Das 
kann
z.B. ein Licht oder ein Ton sein oder ein Skript.

Es ist richtig, bei Highspeedaufnahmen gehen die Zeiten nicht in die 
Stunden. Das Gerät soll aber auch verwendet werden bei Aufnahmen mit 
25/30 fps und die können durchaus auch mal ein paar Stunden laufen.

Ja, die Anzeige kann natürlich auch . statt : anzeigen. Es geht nur bei 
der Auswertung darum, die Werte lesen zu können. Nötigenfalls auch ohne 
Trennung. Da könnte man Stunden und Sekunden in rot anzeigen lassen und 
die anderen Zahlen in einer anderen Farbe.

: Bearbeitet durch User
Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein paar Zähler in einen FPGA eines einfachen FPGA Boards.
Über 63 pins die gewünschten 7segment-Anzeigen direkt ansteuern.

Das Aufwändigste wird das Anschließen der LEDs.

Alternativ die Zähler, BCD-Logik sowie SET/RESET diskret aufbauen und 
das LSB sowie SET/RESET mit dem uC steuern (vermutlich entsprechend 
Vorschlag oben)


Wie dringend ist es?

Autor: Falk B. (falk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@Andreas Mann (kautschuknagel)

>Der Wunsch ist, einen Zähler zu haben, der z.B. 25, 30, 50, 60, 100,
>120, 160 oder 400 fps darstellt.

Man kann das auch problemlos frei konfigurierbar machen, von 1-1000 fps.

> Bei 25 fps wird die jeweilige Zahl des
>Bildes für 40 ms angezeigt, bei 100 fps sind es 10 ms Anzeigedauer, bei
>400 fps dann nur mehr 2,5 ms. Ich weiß nicht, welche Technik dazu
>eingesetzt werden kann.

08/15 Digitalkram.

> Der Wechsel von z.B. 01:00:00:023 auf
>01:00:00:024 muß schneller 2,5 ms erfolgen, da die schnellste Kamera
>sonst beide Werte aufnehmen würde.

Trivial. Die Umschaltung schaffen die LEDs in wenigen Mikrosekunden. 
Trotzdem hast du das Problem, das bei unsynchronisiertert Umschaltung 
deine Kamera die Hälfte der Belichtungszeit eine Zahl sieht und die 
andere Hälfte die nächste Zahl. Optimal wäre es, wenn die Kamera selber 
die Einblendung ins Bild machen würde.

>Mit irgendeinem Wert muß der Zähler ja beginnen. Er soll beliebig
>einstellbar sein, etwa 01:00:00:000 oder 12:30:00:000. Ob der mit BCD
>Schaltern eingestellt wird oder per Software von einem Raspberry/PC
>übermittelt wird, ist egal.

Dann ist UART/RS232 schon das günstigste, mit DIP-Schaltern wird es 
reudig.

>auch gleichzeitig eine andere Aktion an einem Raspberry/PC auslöst. Das
>kann
>z.B. ein Licht oder ein Ton sein oder ein Skript.

Das ist dann ein Problem des PCs, nicht der Anzeige.

Autor: Wolfgang (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Ich weiß nicht, welche Technik dazu
> eingesetzt werden kann. Der Wechsel von z.B. 01:00:00:023 auf
> 01:00:00:024 muß schneller 2,5 ms erfolgen, da die schnellste Kamera
> sonst beide Werte aufnehmen würde.

Der Wechsel muss nicht nur schneller als die Framerate sein, sondern er 
muss auch noch synchronisiert sein. Was nützt es, wenn die Anzeige 
zufällig immer mitten im Bild wechselt.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:

> Korrekterweise handelt es sich nicht um hunderstel Sekunden, sondern um
> Anzahl der Bilder pro Sekunde.

Nein. Es handelt sich um einen Framezähler. Nur dessen Zählumfang 
entspricht der Framerate in Bilder pro Sekunde, dieser Zählumfang wird 
aber gerade niemals angezeigt, denn der angezeigt Wertebereich geht ja 
jeweils von 0 bis fps-1. Soviel zur Richtigstellung des physikalischen 
Sachverhaltes.


Übrigens ist die Aufgabe garnicht so einfach, wie es im ersten Moment 
scheinen mag, jedenfalls dann nicht, wenn wirklich jede ganzzahlige 
Framerate zwischen 1 und 400 möglich sein soll und das auch wirklich 
exakt (ohne zeitlichen Jitter) angezeigt werden soll, jede Zahl also 
exakt gleich lange im Display erscheinen soll.

Zwischen 1 und 400 gibt es nämlich 78 Primzahlen und deren Produkt ist 
ziemlich gross. Und um o.g. Forderungen umzusetzen, müsste der Takt 
mindestens so hoch sein wie eben dieses Produkt.

Wie du leicht ausrechnen kannst, wird sich das eher nicht realisieren 
lassen. Du wirst also mit einem gewissen zeitlichen Jitter leben und vor 
Beginn der Umsetzung definieren müssen, wie hoch der sein darf...

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Andreas M. schrieb:
>> Ich weiß nicht, welche Technik dazu
>> eingesetzt werden kann. Der Wechsel von z.B. 01:00:00:023 auf
>> 01:00:00:024 muß schneller 2,5 ms erfolgen, da die schnellste Kamera
>> sonst beide Werte aufnehmen würde.
>
> Der Wechsel muss nicht nur schneller als die Framerate sein, sondern er
> muss auch noch synchronisiert sein. Was nützt es, wenn die Anzeige
> zufällig immer mitten im Bild wechselt.

So oft kann das ja nicht der Fall sein. Und wenn doch, so bräuchte es 
mehr Nachkommastellen

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Zwischen 1 und 400 gibt es nämlich 78 Primzahlen und deren Produkt ist
> ziemlich gross.

Das dürfte für die Anwendung ziemlich belanglos sein.

Schon wenn man eine minimale Totzeit zwischen zwei Anzeigewerten 
einbaut, d.h. das Display kurz dunkel läßt, tritt der Jitter nicht 
störend in Erscheinung.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ c-hater (Gast)

>Übrigens ist die Aufgabe garnicht so einfach, wie es im ersten Moment
>scheinen mag,

Doch, mit dem allbekannten DDS Prinzip.

>jedenfalls dann nicht, wenn wirklich jede ganzzahlige
>Framerate zwischen 1 und 400 möglich sein soll und das auch wirklich
>exakt (ohne zeitlichen Jitter) angezeigt werden soll,

Das ist keine Forderung.

>Wie du leicht ausrechnen kannst, wird sich das eher nicht realisieren
>lassen. Du wirst also mit einem gewissen zeitlichen Jitter leben und vor
>Beginn der Umsetzung definieren müssen, wie hoch der sein darf...

Bei 16 MHz Zählertakt sind das unglaubliche 62,5ns, die wohl ganz sicher 
zu verschmerzen sind, auch bei 1000 Bilder/Sekunde. Selbst wenn es 1us 
wäre, ist das gerade mal 1/1000 der Bilddauer.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lars R. schrieb:
> So oft kann das ja nicht der Fall sein.

Das passiert genau einmal bei jedem Kamerabild, wenn der Zähler genau 
für die Dauer eines Bildes den Wert des Bildzählers innerhalb einer 
Sekunde anzeigt.

Andreas M. schrieb:
> - Anzeige von Stunden:Minuten:Sekunden:fps

... immer voraus gesetzt, dass hier mit "fps" nicht die Bildrate, 
sondern die Bildnummer gemeint ist. Anders würde eine Anzeigedauer von 
z.B. 2,5ms bei 400fps aber unverständlich.

Andreas M. schrieb:
> Bei 25 fps wird die jeweilige Zahl des Bildes für 40 ms angezeigt, bei
> 100 fps sind es 10 ms Anzeigedauer, bei 400 fps dann nur mehr 2,5 ms.

Autor: Max D. (max_d)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hat die Kamera denn einen Ausgang der den Beginn eines frames markiert?
Ansonsten dürfte das ziemlich spaßig sein bei 400fps die Synchronisation 
hinzukriegen...

Autor: Lars R. (lrs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Lars R. schrieb:
>> So oft kann das ja nicht der Fall sein.
>
> Das passiert genau einmal bei jedem Kamerabild, wenn der Zähler genau
> für die Dauer eines Bildes den Wert des Bildzählers innerhalb einer
> Sekunde anzeigt.

Der Zählimpuls kommt beispielsweise mit einer Genauigkeit von 4+x MHz. 
Auf einem Bild kann eine Stelle flippen. Diese hat aber in der 
Bildaufnahme zuvor nicht geflippt.


Edit: Falls das mit dem uC nicht einfach geht, so benötigt es 
stattdessen eine andere Lösung oder einen diskreten Aufbau. Dafür jedoch 
eine Synchronisation zwischen Highspeed-Camera und einem kleinen uC zu 
implementieren, ggf. auch noch für verschiedene Anwendungsfälle und 
Kameras, ist IMHO übertrieben.

: Bearbeitet durch User
Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lars R. schrieb:
> Dafür jedoch
> eine Synchronisation zwischen Highspeed-Camera und einem kleinen uC zu
> implementieren, ggf. auch noch für verschiedene Anwendungsfälle und
> Kameras, ist IMHO übertrieben.

Wenn Sync-Impulse der Kamera verwendet werden, werden diese einfach 
gezählt. Ein Ereigniszähler ist doch eher banal, auch wenn man ihn hier 
am besten als BCD-Zähler arrangiert.
Wo soll hier ein Problem sein?

Autor: Lars R. (lrs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
m.n. schrieb:
> Lars R. schrieb:
>> Dafür jedoch
>> eine Synchronisation zwischen Highspeed-Camera und einem kleinen uC zu
>> implementieren, ggf. auch noch für verschiedene Anwendungsfälle und
>> Kameras, ist IMHO übertrieben.
>
> Wenn Sync-Impulse der Kamera verwendet werden, werden diese einfach
> gezählt. Ein Ereigniszähler ist doch eher banal, auch wenn man ihn hier
> am besten als BCD-Zähler arrangiert.
> Wo soll hier ein Problem sein?

Die Aufgabenstellung und was Du mit dem Triggersignal machen möchtest. 
Vielleicht habe jedoch ich etwas nicht richtig verstanden oder 
übersehen.


Vom Trigger bekommst Du automatisch die Framerate. Diese kann von 
Aufnahme zu Aufnahme verschieden sein und sie kann während der Aufnahme 
je nach Kamera und Bedingungen driften.

Die Zeitdifferenz Trigger->Belichtung_Start ist Kamera-individuell. Der 
Zeitpunkt Belichtung_Ende ist von der Belichtungszeit abhängig. Die 
Steuerung von Belichtung_Ende kann je nach Kameraaufbau von einem 
weiteren "Trigger"-Signal frame-individuell gesteuert sein.
Dieses Signal Belichtung_Ende bräuchtest Du eigentlich (sofern es 
verfügbar ist), weil Du nach der Belichtung die LEDs ändern möchtest. 
Alternativ extrapolierst Du zur Laufzeit aus der Historie der 
Trigger-Signale den Zeitpunkt des nächsten Triggersignals und beginnst 
ausreichend vorher mit dem LED-Wechsel.

Auch dies ist mit einem FPGA relativ einfach realisierbar und man 
bekommt mehr Stellen scharf. Beim uC kommt noch der iterative 
Programmablauf dazu. 400fps sind aufgerundet 1 kHz. Typischerweise ist 
die Belichtungszeit bei hohen fps bereits am Anschlag und Du suchst die 
Stelle kurz vor dem nächsten Trigger, wo gerade nicht belichtet wird.

Die Frage ist jedoch, ob diese Funktionalität entsprechend 
Aufgabenstellung benötigt wird, oder ob es nicht auch so reicht. Für 
viele Anwendungen ist es auch ohne Synchronisation ausreichend.
Weiterhin kann man jede BCD-Stelle (zusätzlich) mit einer Reihe von 9 
LEDs kodieren und diese LEDs der Reihe nach anschalten (0...9)

Es ist die "echte", gerade aktuelle Zeit, die die Uhr immer dann 
anzeigen soll, wenn belichtet wird. Warum bräuchte man sonst die Uhr?
Beispielsweise nutzt man die Uhr, weil man eben gerade nicht genau 
berechnen möchte oder wissen kann (den Aufwand dafür nicht betreiben 
möchte), zu welchem Zeitpunkt genau die Kamera die eben gerade als Daten 
vorliegenden Pixel belichtet hat. Vielleicht möchte man sogar genau 
diese Abweichungen (Belichtungszeit->Daten liegen vor) vermessen.

Edit:
Und noch genauer:
Die Uhr soll den Zeitpunkt zeigen, der gekommen ist, wenn belichtet 
wird. Und nicht den Zeitpunkt, zu dem die LEDs zuletzt geändert wurden.

Mit ExtraAufwand die letzten Nachkommastellen scharf abbilden, nur damit 
sie zusammenhanglosen Schrott anzeigen, bringt keinen Mehrwert.

: Bearbeitet durch User
Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lars R. schrieb:
> Vom Trigger bekommst Du automatisch die Framerate.

Nur indirekt über eine Frequenzmessung; direkt bekommt man den 
Frame-Takt.
Die Probleme, die Du konstruierst, habe ich jetzt nicht mehr gelesen.

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Lars R. schrieb:
>> Vom Trigger bekommst Du automatisch die Framerate.
>
> Nur indirekt über eine Frequenzmessung; direkt bekommt man den
> Frame-Takt.
> Die Probleme, die Du konstruierst, habe ich jetzt nicht mehr gelesen.

Wenn Du das bereits indirekt nennst, so ist es gut, dass Du nicht 
weitergelesen hast. Sorry, dass ich Dir auf Deine Frage geantwortet 
hatte...

: Bearbeitet durch User
Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lars R. schrieb:
> Wenn Du das bereits indirekt nennst, so ist es gut, dass Du nicht
> weitergelesen hast.

Die Framerate ist der nominelle Wert, wie c-hater schon um 13:00 Uhr 
richtig bemerkt hatte. Diese muß per Vorgabe oder durch genaue Messung 
bekannt sein, sonst ist die ganze Zählfunktion sinnlos.

Wenn Du hier mit FPGA einsteigen willst, ist das in keiner Weise 
nachvollziehbar. Ein µC schafft es locker, Frequenz, Phase und Anzeige 
in korrekten Zusammenhang zu bringen.
Was allerdings fehlt, ist eine hinreichend genaue Beschreibung der 
Funktion durch den TO. Da sehe ich ein Problem, was allerdings nicht 
technischer Natur ist.

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist ein Fehler auf meiner Seite aufgefallen. Beim Format hatte ich 
"Frameanzahl" mehrfach überlesen und ich war von hh:mm:ss:ttt 
ausgegangen mit ttt=Millisekunden.

Einige der von mir angedeuteten Aspekte sind IMHO dennoch relevant.
Wird der Zählstand auf das Trigger-Signal hin verändert, so ist die 
letzte Stelle immer unscharf, weil die LEDs immer innerhalb der 
Belichtungszeit verändert werden.
Bei 500 Frames/s und einer Belichtungszeit von 1.9x ms ist die Zeit, in 
der nicht belichtet wird, entsprechend kurz. Für dieses, auch von Falk 
beschriebene Problem habe ich eine Lösung vorgeschlagen. Wenn man auf 
die letzte Stelle verzichten kann, dann passt es.

Weiter oben hatte ich bereits geschrieben: Einfacher FPGA/CPLD oder uC 
mit diskretem Aufbau (Dein Aufbau).

Wenn der TO jedoch den genauen zeitlichen Bezug nicht benötigt, dann ist 
mir unklar, wofür er überhaupt die Uhr benötigt. Weiter oben wurde 
Abzählen vorgeschlagen.

: Bearbeitet durch User
Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lars R. schrieb:
> Wird der Zählstand auf das Trigger-Signal hin verändert, so ist die
> letzte Stelle immer unscharf, weil die LEDs immer innerhalb der
> Belichtungszeit verändert werden.

Das muß überhaupt nicht sein!

Sobald dieses Trigger-Signal erscheint, werden die Inhalte der 
Schieberegister (4094 z.B.) in deren Ausgaberegister übernommen 
(strobe-Signal) und die Anzeige binnen µs aktualisiert. Anschließend 
wird der nächste Anzeigenwert berechnet und schon mal in die 
Schieberegister geschrieben. Danach wird wieder gewartet, bis das 
Trigger-Signal den nächsten Anzeigenwert anfordert. Der µC hat also sehr 
viel Zeit.

Falls genaueres Timing < 1 µs notwendig sein sollte, kann das 
Trigger-Signal per Input-Capture erfaßt und eine Verzögerung über 
Output-Compare erzeugt werden.
Aber selbst per Software kann der Belichtungszeitpunkt schon hineichend 
genau eingehalten werden.

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Typischerweise beginnt die Belichtung immer nach dem Trigger. Die LEDs 
sollten demnach ganz kurz vor dem nächsten Trigger geändert werden
...oder eben doch zu einem anderen Zeitpunkt. Es hängt von der Kamera 
und den Trigger-Einstellungen ab.

Bei hohen fps gibt es keinen "Belichtungszeitpunkt", sondern einen 
"Belichtungszeitraum" und einen "Nichtbelichtungszeitpunkt". Bei manchen 
Modellen mit rolling shutter vielleicht nicht einmal diesen.

> Trigger-Signal per Input-Capture erfaßt und eine Verzögerung über Output-Compare 
erzeugt werden.

Klingt gut.

Autor: Andreas M. (kautschuknagel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oha, da habe ich eine ganze Lawine losgetreten...

Der aktuelle Bedarf ist noch relativ einfach und mir scheint, die 
Highspeedkameras stellen die besondere Herausforderung dar. Zum 
Hintergrund:

Ich muß wissen, wie weit Bild und Ton bei Aufnahmen von mehreren 
unterschiedlichen Kameras, die nicht getaktet werden können, 
auseinanderliegen. Es kann vorkommen, daß Bild und Ton langsam 
auseinanderlaufen und das deutlicher wird, je länger die Aufnahme läuft.

Dazu lasse ich bisher ein Video auf einem Monitor laufen. Es zeigt 
fortlaufenden Timecode und gibt alle 30 Sekunden einen Ton mit der Dauer 
von 5 Bildern aus. Gleichzeitig wird ein Kreis ebenfalls 5 Bilder lang 
angezeigt.

Die Kameras nehmen diesen Film auf und bei der Prüfung der Aufnahme kann 
ich leicht feststellen, welche keine Asynchronität von Bild und Ton 
aufweist. Für die Entwicklung einer Aufnahmesoftware soll die 
fehlerfreie Funktion geprüft werden können. Bild und Ton kommen dabei 
nicht von der Kamera sondern von unterschiedlichen Quellen. Auch kann 
man dann leicht feststellen, welche Rechner zum Aufnehmen geeignet sind 
und welche nicht.

Das ist noch relativ simpel, wenn es um die üblichen Frameraten von 
25,30,50 und 60 geht. Dazu muß ich aber schon vier Filme erstellen und 
jeder läuft 12 Stunden.

Problematisch wird es, wenn höhere Frameraten ins Spiel kommen. Das 
stellt dann die Grafikkarte nicht mehr dar, mal ganz vom Schnittprogramm 
abgesehen, das ja auch mit der Framerate umgehen muß.

Bei Kameras für 100 fps und mehr ist der Ton meist irrlevant. Da ist 
dann wichtiger, wie weit die Kameras zueinander synchron sind. Bei den 
Standardframeraten ist das eher unwichtig, da diese einen anderem Zweck 
dienen.

Insofern kam mir der Gedanke ein für alle Zwecke gleichermaßen 
taugliches Gerät zu haben. Mein Gedanke war, daß z.B. ein Raspberry die 
Startzeit an die Anzeige sendet und diese dann startet. Gleichzeitig 
würde er eine LED ansteuern und den Ton senden (beide z.B. 5 Frames 
lang). Grundsätzlich könnte aber die ganze Funktionalität in einem 
einzigen Gerät stecken. Die Lautstärke des Tons wäre eigentlich das 
einzige, das man ändern können sollte und natürlich die Framerate. Ich 
bin sicher, daß längst nicht jede Framerate benötigt wird. Es macht 
keinen Sinn mit z.B. 133 oder 41 Frames anzuzeigen, wenn die Kameras 
diese nicht unterstützen. Da würden auch 5er Schritte genügen. Ich kann 
nur nicht absehen, welche Kameras in Zukunft unterstützt werden sollen 
und wenn es nur eine Sache der Programmierung wäre und es keinen 
nennenswerten Aufwand bedeutet, wäre natürlich die frei wählbare 
Framerate von 1-400 die sicherste Lösung.

Im Grunde ist das ganze eine Filmklappe mit erweiterter Funktion.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Lars R. (lrs)

>Typischerweise beginnt die Belichtung immer nach dem Trigger.

Wahrscheinlich.

> Die LEDs
>sollten demnach ganz kurz vor dem nächsten Trigger geändert werden

Naja, diese Frage ist schon recht akademisch. Denn was macht ein 
Übersprechen von vielleicht 1-2us bei einer Belichtungszeit von fast 
1000us aus?

>> Trigger-Signal per Input-Capture erfaßt und eine Verzögerung über
>Output-Compare erzeugt werden.

>Klingt gut.

Oder man hängt das Triggersignal gleich direkt an den Übernahmepuls der 
Schieberegister, dann sind es nur ein paar Dutzend Nanosekunden 
Verzögerung.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas Mann (kautschuknagel)

>Ich muß wissen, wie weit Bild und Ton bei Aufnahmen von mehreren
>unterschiedlichen Kameras, die nicht getaktet werden können,
>auseinanderliegen. Es kann vorkommen, daß Bild und Ton langsam
>auseinanderlaufen und das deutlicher wird, je länger die Aufnahme läuft.

Wer macht denn sowas? Bild und Ton getrennt und plesiochron aufzeichnen?

>Das ist noch relativ simpel, wenn es um die üblichen Frameraten von
>25,30,50 und 60 geht. Dazu muß ich aber schon vier Filme erstellen und
>jeder läuft 12 Stunden.

???

>nennenswerten Aufwand bedeutet, wäre natürlich die frei wählbare
>Framerate von 1-400 die sicherste Lösung.

Das ist einfach.

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Andreas M.:

Für den Highspeed-Fall:

Wenn Du von jeder Kamera ein Trigger-Signal hast, so kann man die 
Triggersignale miteinander vergleichen.

Wenn das Trigger-Signal jedoch nicht von den Kameras kommt, woher kommt 
es? Von einer Uhr?

Autor: Andreas M. (kautschuknagel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt schlicht und ergreifend keinen externen Takt. Die Kameras werden 
manuell gestartet und fertig. Natürlich sind die nicht synchron 
zueinander. Was für den Anwendungsfall nicht sonderlich relevant ist.

Wichtig aber ist, daß das Bild zum Ton passen muß. Eine Abweichung von 
+/- 40 ms ist akzeptabel, solange diese konstant bleibt.

Bei den Highspeedkameras wäre eigentlich nur wichtig zu sehen, ob die 
bei der Kamera eingestellte Framerate von 400 korrekt vom Programm 
aufgezeichnet wird. Wenn ich davon ausgehen kann, daß das Gerät korrekte 
400 Bilder pro Sekunde darstellt, muß in der Aufzeichnung jeder Wert 
sauber lesbar sein. Ist das nicht der Fall, kann entweder die Kamera 
nicht die versprochene Framerate einhalten oder - was wahrscheinlicher 
ist - das Aufnahmeprogramm muß nachgebessert werden.
Ob dann Kamera 1 bis Kamera n alle das gleiche Bild bei z.B. TC 
01:00:00:234 anzeigen, ist unerheblich. Sie müssen nicht synchron 
zueiander laufen.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deine Anwendung ist mysteriös! Und wenn eine Kamera nicht exakt die 
eingestellt Framerate aufzeichnet, sollte man sie wegwerfen.

>Wenn ich davon ausgehen kann, daß das Gerät korrekte
>400 Bilder pro Sekunde darstellt, muß in der Aufzeichnung jeder Wert
>sauber lesbar sein.

Das haben dir mehrere Leute versucht zu erklären. Ohne Synchronisation 
wirst du viele verschwommene Geisterbilder bei deiner Uhr sehen! Auch 
wenn die korrekt funktioniert! Man könnte das höchstens mildern, indem 
man die Anzeigezeit kürzer als die Periodendauer eines Bilds/Belichtung 
macht. Alsi bei 100 Bildern/s die Anzeige nur 3ms anstatt 10ms leuchten 
läßt, dafür aber heller. Dann ist die Chance auf Doppelbelichtung 
geringer.

Autor: Andreas M. (kautschuknagel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sprechen wir bei den verschwommenen Bildern von den Highspeedkameras? 
Ich vergleiche das mit einer elektronischen Filmklappe. Da laufen die 
Kameras frei und zeigen den Timecode der Klappe Bild für Bild an. So 
hatte ich das gedacht, nur eben mit höherer Framerate.

Autor: Max D. (max_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Da laufen die
> Kameras frei und zeigen den Timecode der Klappe Bild für Bild an.

Ja, weil die Klappe nur Sekunden zählt und damit ein Übergang nur alle 
24 Bilder stattfindet.

Autor: Andreas M. (kautschuknagel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>
> Ja, weil die Klappe nur Sekunden zählt und damit ein Übergang nur alle
> 24 Bilder stattfindet.

Da muß ich Dich korrigieren. Elektronische Klappen zeigen in aller Regel 
den Timecode achtstellig mit Frames an.

Autor: Jonas G. (jstjst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du meine PN bekommen?

Autor: Andreas M. (kautschuknagel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jonas G. schrieb:
> Hast du meine PN bekommen?

Ja, und ich habe dann über das Forum eine Mail an Dich geschrieben.

Autor: Jonas G. (jstjst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir kam mal nichts an.

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau so etwas wollte ich schon lange bauen.
Wenn jemand eine weitere Platine für mich mit-baut, kaufe ich sie 
sofort.
Rel. große Displays (25mm?) wären gut.
Das mit dem Frame-Syncro sehe ich nicht so tragisch. Meist kann man die 
zwei verwaschenen Ziffern doch erkennen, da sie nicht gleich hell sind.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Apropos abstruse Framerates: Wenn schon eierlegende Wollmilchsau, dann 
aber auch alle Framerates auch noch um 1000/1001 vermindert - altes 
NTSC-Relikt, das sich bis in die Neuzeit weiterschleppt und nicht 
totzukriegen ist ;-)

Gruss
WK

Autor: Falk B. (falk)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

gibt es noch Bedarf an der Anzeige? Ich hab mal einen Schaltung 
erstellt, wenn gleich bisher nur auf dem elektronischen Papier. Wenn der 
OP bzw. der eProfi noch Interesse haben, würde ich mal ein paar Platinen 
in China bestellen (wir wollen ja zum globalen Wirtschaftswachstum und 
auch der globalen Umweltverschmutzung beitragen ;-)

Ich würde dann eine bestücken und alles entwickeln und testen. Den 
Prototypen würde ich dann hier verkaufen, Material + Versandkosten + ein 
kleines, symbolisches Entgeld. Ich würde bei Elecrow bestellen, dort 
gibt es 5 Stück zu Superpreis von 30 Euro, bzw. 6 Euro pro Stück. Die 
könnten dann auch von mir gekauft werden.

Die Anzeige hat 9 7-Segmentanzeigen mit 20mm Höhe, alles direkt per 
LED-Treiber angesteuert (kein Multiplexing). Ein optionaler SYNC-Eingang 
kann zum Zählen der Frames verwendet werden, falls es mit dem 
unsynchronisierten Zählen nicht so recht klappen sollte. Die Platine ist 
50mmx180mm klein, Speisung per 3,3V aus einem Steckernetzteil. 
Kommunikation per USB/virtueller COM-Port.

Interesse?

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gute Idee, Falk!  Bin mit 2 Platinen dabei.
Ein Gehäuse wäre ebenfalls gefragt.

Autor: Andreas M. (kautschuknagel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Besten Dank für das Aufgreifen. Ja, da bin ich natürlich auch dabei.

Autor: Thomas E. (picalic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich so die Abbildung der 7-Segment Displays ansehe: wäre es nicht 
schöner, die Minuten/Sekunden/Frames optisch etwas voneinander zu 
trennen?

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Trennung erfolgt mittels Dezimalpunkt auf den Anzeigen.

Autor: Andreas M. (kautschuknagel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre für meine Zwecke absolut ausreichend.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, die Bestellungen für die Bauteile und die Platinen sind raus, 
letztere könnte bis zu 25 Tage für die Lieferung dauern. In der 
Zwischenzeit werd ich mal die Software vorbereiten.

Autor: Andreas M. (kautschuknagel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wunderbar, vielen Dank für Deine Mühe!

Autor: Falk B. (falk)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, die Boards sind fertig und nun unterwegs nach Deutschland, das kann 
aber 1-4 Wochen dauern 8-0

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anstatt die Luft weiter umzurühren, solltest Du lieber die zu Grunde 
liegende Schaltung zeigen. Dann kann man sehen, was geht und was nicht.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Moin,

m.n. schrieb:
> Anstatt die Luft weiter umzurühren, solltest Du lieber die zu
> Grunde
> liegende Schaltung zeigen. Dann kann man sehen, was geht und was nicht.

Ja, so macht ehrenamtliches Entwickeln doch gleich viel mehr Spass.

SCNR,
WK

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verstehe nicht, was Du uns/mir sagen willst.

Autor: Falk B. (falk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@m.n. (Gast)

>Anstatt die Luft weiter umzurühren, solltest Du lieber die zu Grunde
>liegende Schaltung zeigen. Dann kann man sehen, was geht und was nicht.

"Vertrauen Sie mir, ich weiß was ich tue" (tm)

;-)

Autor: m.n. (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Falk B. schrieb:
> "Vertrauen Sie mir, ich weiß was ich tue" (tm)

Du bist ja ein Spaßvogel!

Hier im Forum geht es darum, Informationen auszutauschen. Zu Deiner 
Katze im Sack gibt es keinerlei dergleichen. Welche Displaytreiber? 
Welcher Prozessor? Alles Fehlanzeige.

Du bist jemand, der wiederholt mit dem Hinweis auf Netiquette auffällt. 
Auf der anderen Seite spielst Du hier mit verdeckten Karten - nur nichts 
verraten.
So ist das eben mit Leuten, die sich wichtig machen wollen.

Autor: Falk B. (falk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@ m.n. (Gast)

>> "Vertrauen Sie mir, ich weiß was ich tue" (tm)

>Du bist ja ein Spaßvogel!

In der Tat!

>Hier im Forum geht es darum, Informationen auszutauschen.

Stimmt.

>Zu Deiner
>Katze im Sack gibt es keinerlei dergleichen. Welche Displaytreiber?
>Welcher Prozessor? Alles Fehlanzeige.

Könnte ich nennen, ist auch kein wirkliches Geheimnis oder Rocket 
Science.
Ist ein uralter ATmega8 mit 7,3728 MHz Quarz, 5x TLC59284 + Gemüse. 
Laaaaangweilig.

>Du bist jemand, der wiederholt mit dem Hinweis auf Netiquette auffällt.
>Auf der anderen Seite spielst Du hier mit verdeckten Karten - nur nichts
>verraten.
>So ist das eben mit Leuten, die sich wichtig machen wollen

Keine Sekunde. Ich liefere ein fertiges Produkt, dann darf sich auch 
jeder den Schaltplan anschauen und es nach Herzenslust kommentieren. 
Aber vorher will der Künster nicht gestört werden ;-)

In Wahrheit brennst du doch nur darauf, ein Haar in der Suppe zu finden 
und mich mal richtig runter zu machen, nicht wahr?

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:

> Ist ein uralter ATmega8 mit 7,3728 MHz Quarz, 5x TLC59284 + Gemüse.
> Laaaaangweilig.

Du sagst es.
So ein großer Affe, für so eine kleine Frage :-(

Autor: Andreas M. (kautschuknagel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich lasse mich einfach überraschen und vertraue darauf, daß Falk 
verstanden hat, was mir wichtig ist. Es brennt nicht unter den Nägeln, 
ob das nun 4 oder 8 Wochen dauert, ist mir gleich.

Danke schonmal für die Mühe!

Autor: Falk B. (falk)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, die Brieftaube war diesmal außerordentlich schnell und die Boards 
sind schon da! Sie sehen sehr gut aus, nur der Bestückungsdruck ist um 
einen Tick verschoben, aber das macht keine Probleme, die SMD-Pads sind 
frei.

Autor: Falk B. (falk)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, das Board ist fast komplett, es fehlt nur noch der MUX für den SYNC 
Eingang (falschen Typen bestellt). Ansonsten funktioniert alles wie 
erwartet. Das Ding zieht ~1,4A@3,3V, also knapp 5W, das macht ordentlich 
Wärme und Licht ;-) Aber bei 1000 fps wird man es brauchen. Die 
Framerate ist von 1-1000 frei einstellbar, siehe Anhang.

Leider gibt es einen großen Abzug in der B-Note 8-( Die scheiß 
Footprints der LED-Treiber sind zu breit!!! Die Jungs von TI nennen das 
Gehäuse zwar SSOP24, aber DIESE haben erstens 0,635mm (25mil) Pitch 
anstatt 0,65 wie die allermeisten metrischen SSOPs und zweitens sind sie 
schmaler!!! Den Pitch hab ich vorher gesehen und korrigiert, die Breite 
nicht! ARRRRGG!!!!
Damit berühren die Beinchen die Pads nur minimal, so ca. 0,2mm auf jeder 
Seite. Aber mit etwas Geschick kann man sie dennoch anlöten und es hält.

@Andreas Mann (kautschuknagel)

So, nun zum "Geschäftlichen". Ich hab hier den kompletten Prototypen, 
der ist für dich. Kostet 50 Euro incl. Versand für Material + Platine. 
Dazu ein symbolisches Entgeld, daß dir diese Platine wert ist, wenn sie 
ein guter Freund für dich gebaut hätte.

Dann hab ich noch einmal komplett alle Bauteile für einen 2. Prototypen, 
der steht zum gleichen Preis zum Verkauf, ist aber nicht bestückt.

Die restlich 3 Platinen gebe ich jeweils mit 5x TLC59284 für 15 Euro 
incl. Versand ab, das sind die reinen Materialkosten . . . Die TLC 
deshalb, weil man die nicht überall kaufen kann, den Rest gibt es bei 
Reichelt & Co.

Und last but not least ist noch eine 6. Platine übrig, gab's als 
Überproduktion kostenlos vom freundlichen Chinamann dazu, Kostenpunkt 8 
Euro incl. Versand. |-) Diese allerdings ohne die TLCs.

ACHTUNG!!! Hier noch einmal der Hinweis an potentielle Käufer! Die 
Footprints für die LED-Treiber sind zu breit, aber mit etwas Geschick 
kann man sie anlöten! Außerdem ist auf dem Bestückungsaufdruck R4 und 
C13 vertauscht.

Die Projektdaten lade ich nächste Woche hoch, wenn der Feinschliff 
fertig ist.

Autor: Andreas M. (kautschuknagel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Besten Dank Falk!

Ich habe schon mal mails an Beutzer hier verschickt, das hat nicht 
geklappt. Schick mir bitte Deine Kontaktdaten an pebi52@web.de und wir 
machen das weitere direkt. Die Adresse kann man gerne zumüllen, ich 
lösche den Account ohnehin.

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch von mir ein DICKES Dankeschön!
Bin so frei und nehme das Komplettset, die drei Boards und die 
Extra-Platine. Bitte schicke mir eine PM (/user/show/eprofi) mit den 
Bank- oder PP-Daten.
Was ich mir noch gewünscht hätte: ein RTC-Chip, damit man das Teil als 
Uhr verwenden kann. Ist aber einfach mit Fädeldraht nachrüstbar.
Auch DCF-Empfang sollte machbar sein.

Wie schaut es mit einem Gehäuse aus? Gibt es etwas passendes oder muss 
ein 3D-Druck angekurbelt werden?

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weitere Einträge auf dem Wunschzettel:
Display-On-Off-Kommandos und falls möglich -Eingang
Display-Auto-Off, wenn kein Sync-Signal am Eingang (nach einstellbarer 
Zeit)
Ein weiterer Mode mit einem weiteren Eingangssignal (falls HW-nicht 
möglich, dann das Sync-Signal dazu verwenden):
Es soll die Sekunden:Frames auf 00.000 stellen und die Hh.Mm hochzählen 
(0000-9999, also Ereigniszählung). Das ist hilfreich beim Filmen von 
sich wiederholenden Ereignissen.

Für den Betrieb als Normal-Uhr: Dimmen der LED-Helligkeit mittels 
highSpeedPWM.
Schade, dass es nicht 10 stellig ist, IC7 ist unterbeschäftigt.
Dann hätte man Datum (ohne Jahr) und Uhrzeit darstellen können.
Datumformat einstellbar, ob MmDd (USA, JP) oder DdMm (EU).

Wie ist die Darstellung bei Frame-Zahlen unter 10 / unter 100?
right-justified oder left-justified?   Am besten einstellbar machen.


Autor:  Lars R. (lrs)  Datum: 13.08.2016 15:37
> Weiterhin kann man jede BCD-Stelle (zusätzlich) mit einer Reihe
> von 9 LEDs kodieren und diese LEDs der Reihe nach anschalten (0...9)
Noch ein Vorschlag gegen das Verwaschen der letzten Stelle: statt dort 
eine Ziffer anzuzeigen, nur ein Segment bzw. zwei nicht benachbarte,
also z.B.
Zi Segment
0  a   a
1  b   b
2  c   c
3  d   d
4  e   e
5  g   f
6  c   g
7  d  a+d
8  e  b+f
9  f  c+e

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@eProfi (Gast)

>Weitere Einträge auf dem Wunschzettel:

...

Ähm, ich glaube das ufert jetzt ein wenig aus. Der OP war der 
Ausgangspunkt was Soft- und Hardware angeht. Die eierlegende 
Wollmilchsau sollte es nicht werden. Wenn du die Boards aufbohren 
willst, kannst du das gern tun. Die Doku incl. Software dazu folgt 
nächste Woche.

>Noch ein Vorschlag gegen das Verwaschen der letzten Stelle: statt dort
>eine Ziffer anzuzeigen, nur ein Segment bzw. zwei nicht benachbarte,
>also z.B.

Das löst das Problem auch nicht, dann sind halt 2 Einzelsegmente 
verwaschen. Das ist aber ggf. besser erkennbar, weil sich 
aufeinanderfolgende Zahlen deutlicher unterscheiden als bei 
Zifferndarstellung, wie z.B. 2 und 3.

Autor: Andreas M. (kautschuknagel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin begeistert und bedanke mich ausdrücklich bei Falk für die 
wirklich ordentliche Arbeit. Eine kurze Installationsschwierigkeit 
bezüglich des Treibers für W7/64 ließ sich schnell beheben. Ich habe den 
passenden Treiber installiert und dann war ein Neustart notwendig. Jetzt 
läuft es einwandfrei.

Treiber: http://www.ftdichip.com/Drivers/VCP.htm

Lediglich den Start via externem Signal habe ich noch nicht probiert. 
Ich vermute, das Signal muß über den schwarzen Anschluß mit den 6 Pins 
kommen. Welche Spannung und an welche Pins?

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Andreas Mann (kautschuknagel)

>passenden Treiber installiert und dann war ein Neustart notwendig. Jetzt
>läuft es einwandfrei.

Schön zu hören.

>Lediglich den Start via externem Signal habe ich noch nicht probiert.
>Ich vermute, das Signal muß über den schwarzen Anschluß mit den 6 Pins
>kommen. Welche Spannung und an welche Pins?

NEIN! Dafür gibt es J1! Dort kann man ein 3,3V CMOS Signal einspeisen, 
TTL mit 5V geht auch (weil das nur bis ca. 3,7V hoch geht).

Autor: Andreas M. (kautschuknagel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen J1 sehe ich nicht. Ich vermute, es ist der JP1 gemeint?
Wenn ich von vorne auf das Board sehe, also die Segmentanzeigen sichtbar 
sind, dann scheint mir der linke Pin für Minus zu sein und der rechte 
für Plus, der zum IC 10 führt. Ist das richtig?

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas Mann (kautschuknagel)

>Einen J1 sehe ich nicht. Ich vermute, es ist der JP1 gemeint?

Ja

>Wenn ich von vorne auf das Board sehe, also die Segmentanzeigen sichtbar
>sind, dann scheint mir der linke Pin für Minus zu sein

Ja, das ist Masse/GND

>und der rechte für Plus, der zum IC 10 führt. Ist das richtig?

Ja

Autor: Falk B. (falk)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
OK, hier die Projektdaten.

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
--- gestern getippt ---
Falks Packerl kam am Samstag an. Vielen Dank, 1A Qualität und sehr 
sauber gelötet.
Aber: ich habe das Display ins temporäre digitale Nirvana geschickt:
Ich hatte die oben gepostete Anleitung nur kurz überflogen.

Beim Ausprobieren hatte ich nur ein 3V-4A-Netzteil (das vom BC700 Accu 
Charger) und einen Rechner, kein iNet und kein PDF.
Angestöpselt, Selbsttest (alle Segmente werden lauflicht-artig 
durchlaufen), FDTI-Treiber lädt erfolgreich.
verschiedene Baudraten durchprobiert, 4. Treffer war 38400.
Dank der Fehlermeldungen schnell die gültigen Befehle herausgefunden.
(ein Help-Text mit ? wäre hilfreich gewesen).
Starten und Stoppen, alles klappt gut.

Aber dann: über das X-Kommando (Quarzabgleich) gestolpert.
ohne Parameter stellt es auf ca. -16560 ppm. Die Uhr lief viel zu 
langsam.
Dann einen Wert herausgefunden, der -0.0 ppm anzeigt, aber nicht stimmen 
kann.  Dann versehentlich X,6000 eingegeben, das war's. Das Ding 
reagiert nicht mehr auf Eingaben, es gibt nur noch die Einschaltmeldung 
aus und zeigt 00.00.00.000 an.
Vermutlich läuft jetzt ein Interrupt viel zu schnell, so dass die 
serielle nicht mehr zum Zug kommmt.
Dazwischen hatte ich nämlich schon Werte gefunden, mit denen die Uhr 
viel zu schnell lief und dabei "verwaschen" die Stellen (übersprechen), 
d.h. man konnte die benachbarten Stellen mitglimmen sehen, ähnlich wie 
bei einer gemultiplexten Anzeige.
Leider habe ich kein Programmierzeug da und kann das EPROM nicht 
löschen.

Weitere Eintragungen der zu späten Wunsch-Liste:
Step-Down-Regler, damit man das Display auch mit 5, 12 oder 24V speisen 
kann.
Freie Prozessor-Pins auf Stecker führen, damit Erweiterungen möglich 
sind.


--- heute getippt ---
Also, ich muss sagen, unser Falk hat das Ganze sehr professionell 
aufgezogen. Hut ab!
Eine Kleinigkeit: Vorsicht beim X-Befehl (Quarzfrequenz genau 
einstellen).
Wenn man versehentlich X,6000 eingibt, ist keine serielle Kommunikation 
mehr möglich. Überhaupt nicht mehr, auch nach Wiedereinschalten, da die 
Daten im EEPROM gespeichert werden.
Mir ist noch nicht klar, was da passiert. Ich vermute zu schnelle 
Interrupts, die das System voll auslasten.
In der Software ist eine Abfrage drin, die eigentlich nur +/- 1000 ppm 
zulässt, aber ...
Nach Löschen der ersten EEPROM-Bytes (es stand 00 00 e0 2e (12000) 
drin)geht nun wieder alles.

Falk, welches ist die älteste Software, mit der man das Projekt 
compilieren kann?

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@eProfi (Gast)

>Dank der Fehlermeldungen schnell die gültigen Befehle herausgefunden.
>(ein Help-Text mit ? wäre hilfreich gewesen).

Stimmt.

>Aber dann: über das X-Kommando (Quarzabgleich) gestolpert.
>ohne Parameter stellt es auf ca. -16560 ppm. Die Uhr lief viel zu
>langsam.

Das sollte eigentlich nicht möglich sein, denn die Eingabe wird geprüft.

Siehe cmd_terminal.c, cmd_cal_fcpu()

>In der Software ist eine Abfrage drin, die eigentlich nur +/- 1000 ppm
>zulässt, aber ...

Eben!

>Falk, welches ist die älteste Software, mit der man das Projekt
>compilieren kann?

Ich hab es mit AVR-Studio 4.18 und avr gcc 2010??? erstellt, sollte aber 
auch noch mit deutlich älternen Versionen laufen, hat ja keine 
besonderen Tricks drin.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Das sollte eigentlich nicht möglich sein, denn die Eingabe wird geprüft.

Nicht die Länge der Eingabe, len existiert zwar, wird aber nicht 
geprüft. Ein Kommando ohne Parameter übernimmt einfach irgendwelche 
vorhergehende Werte aus dem Puffer.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MWS (Gast)

>Nicht die Länge der Eingabe, len existiert zwar, wird aber nicht
>geprüft. Ein Kommando ohne Parameter übernimmt einfach irgendwelche
>vorhergehende Werte aus dem Puffer.

Ja, aber wenn der umgewandelte Wert zu weit vom Sollwert abweicht, wird 
der Befehl verweigert. Damit kann eigentlich kein total abweichender 
Wert aktiv werden.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Ja, aber wenn der umgewandelte Wert zu weit vom Sollwert abweicht, wird
> der Befehl verweigert. Damit kann eigentlich kein total abweichender
> Wert aktiv werden.

Nö, probier' mal:
uint32_t f_cpu, delta;
  f_cpu = 2*atol("-1");          // f_cpu = 4294967294
  delta = abs(f_cpu - T_CPU);    // delta = 4610
    if ( delta < T_CPU/1000 ) {  // true
        gconfig.f_cpu = f_cpu;   // oops
  }
Du hättest labs() nehmen müssen, abs() geht nur für Integer.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Testcode hätte auch noch ein:
define T_CPU 8000000
gehört.
Bzw., ich hätt's für mein Post wieder zurück benennen sollen.

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke fürs Finden, MWS!
Ich hätte es erst mit einem Simulator / Debugger herausgebracht.

Weitere Wunschliste:
Die Uhr könnte gleich beim PowerOn loslaufen. Für einfache Tests reicht 
das, man braucht keinen Rechner zum Starten.

Oder man verwendet vier der freien Pins, um zu starten  lappen  
stoppen, resetten, dann hätte man eine schöne Stoppuhr.

Ein paar Dipschalter, um die Betriebsart zu wählen.

Up/Down/Dir/Reset-Counter-Eingänge, z.B. zum Debuggen von 
Schrittmotoren.

Ein "Grafikmodus", bei dem man jedes Segment einzeln ansteuern kann, 
wäre für Animationen auch nett.

Und überhaupt hätte man auch die 16-Segment-Displays PSA 08-11 verwenden 
können, um Texte darzustellen ;-)
http://cdn-reichelt.de/documents/datenblatt/A500/P...
Aber die haben ja 17 LEDs (Dezimalpunkt), dann reichen die 
Treiberausgänge nicht.
Die PSA 08-12 haben nur 16 LEDs (kein DP), dafür aber eine komplett 
andere Pinbelegung.

Apropos DP: die gelieferten Displays schauen anders aus als im 
Datenblatt, sie sind schmaler und haben kein Loch für den linken DP1.
http://cdn-reichelt.de/documents/datenblatt/A500/S...

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eProfi schrieb:
> Ich hätte es erst mit einem Simulator / Debugger herausgebracht.

Man kann's an meinen Bemerkungen im Quelltext sehen, dass ich das auch 
nicht anders gemacht haben konnte.

> Weitere Wunschliste:

An wen richtest Du eigentlich Deine Wünsche?
Falk hat erklärt, dass er das Aufmotzen über die ursprünglich angefragte 
Lösung hinaus nicht als Lebensbeschäftigung ansieht und der TE scheint 
zufrieden zu sein.

Es sieht für mich so aus, also ob diese Wunschliste von Dir umgesetzt 
werden müsste. Da die Projektdaten vorhanden sind, steht dem nichts im 
Wege, frisch an's Werk ;-)

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas Mann (kautschuknagel)

Was macht das Display? Schon erfolgreich benutzt?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.