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!
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
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
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.
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.
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...
@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.
Naja, der TO hat ja nach "oder Schaltung" gefragt. Und das war halt ein schaltungsvorschlag...
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.
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.
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.
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?
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.
@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.
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
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
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?
@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.
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.
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...
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
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.
@ 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.
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.
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...
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
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?
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
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.
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
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.
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
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.
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.
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.
@ 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.
@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.
@ 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?
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.
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.
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.
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.
> > 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.
Hast du meine PN bekommen?
Jonas G. schrieb: > Hast du meine PN bekommen? Ja, und ich habe dann über das Forum eine Mail an Dich geschrieben.
Bei mir kam mal nichts an.
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.
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
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?
Gute Idee, Falk! Bin mit 2 Platinen dabei. Ein Gehäuse wäre ebenfalls gefragt.
Besten Dank für das Aufgreifen. Ja, da bin ich natürlich auch dabei.
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?
Die Trennung erfolgt mittels Dezimalpunkt auf den Anzeigen.
Wäre für meine Zwecke absolut ausreichend.
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.
Wunderbar, vielen Dank für Deine Mühe!
Angehängte Dateien:
-
shipping.jpg
50 KB
So, die Boards sind fertig und nun unterwegs nach Deutschland, das kann aber 1-4 Wochen dauern 8-0
Anstatt die Luft weiter umzurühren, solltest Du lieber die zu Grunde liegende Schaltung zeigen. Dann kann man sehen, was geht und was nicht.
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
Ich verstehe nicht, was Du uns/mir sagen willst.
@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) ;-)
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.
@ 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?
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 :-(
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!
Angehängte Dateien:
-
Leerboard.jpg
180 KB
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.
Angehängte Dateien:
-
FrameDisplay1.jpg
130 KB -
FrameDisplay2.jpg
210 KB
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.
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.
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?
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
@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.
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?
@ 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).
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?
@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
OK, hier die Projektdaten.
--- 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?
@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.
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.
@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.
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:
1 | uint32_t f_cpu, delta; |
2 | f_cpu = 2*atol("-1"); // f_cpu = 4294967294 |
3 | delta = abs(f_cpu - T_CPU); // delta = 4610 |
4 | if ( delta < T_CPU/1000 ) { // true |
5 | gconfig.f_cpu = f_cpu; // oops |
6 | }
|
Du hättest labs() nehmen müssen, abs() geht nur für Integer.
Zum Testcode hätte auch noch ein:
1 | define T_CPU 8000000 |
gehört. Bzw., ich hätt's für mein Post wieder zurück benennen sollen.
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/PSA08-11_PSC08-11%23KIN.pdf 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/SA08-11SRWA%28V7%29.pdf
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 ;-)
@Andreas Mann (kautschuknagel) Was macht das Display? Schon erfolgreich benutzt?
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.