Stoppuhr für Feuerwehr

[Starburst]

Hallo,

zuerst möchte ich mich kurz vorstellen.
Mein Name ist Karl Weber und komme aus der Steiermark in Österreich. Ich bin beruflich Softwareentwickler auf Siemens SPS Systemen für Industrielle Großanlagen. Ich hatte in der Schule (4 Jahre her) Unterricht in µC programmieren, jedoch war unser Lehrer nicht gerade interessiert uns was beizubringen und somit stehe ich mit eher schlechtem Wissen da.
Ich hab mir jetzt ein Programmierboard von myavr.de gekauft, was gerade zu mir unterwegs ist.

Jetzt zu meiner Anwendung.
Ich bin selbst Mitglied bei der Freiwilligen Feuerwehr. Da haben wir eine Wettkampfgruppe, die eben bei diversen Leistungswettkämpfen antritt. Da gibt es Standartiesierte Zeitmesssysteme. Diese sind leider sündhaft teuer, deshalb möchte ich so eine nachbaun.
Sie funktioniert wie eine "normale" handelsübliche Stoppuhr; Start, Stop und Reset. Diese 3 Signale werden extern über Schlagtaster ausgelöst.
Die Zeitauflösung sollte in Hundertstel Sekunden sein. Die Ausgabe soll dann auf einer großen 7-Segment (oder Dot-Matrix) angezeigt werden.

Ich will keinen fertigen Code; ich wills ja selbst lernen wies funktioniert. Ist sowas möglich in der Genauigkeit? Hat sowas vielleicht schon mal jemand gemacht? Welchen Controller könnt ihr mir empfehlen...

Danke schon mal für eure Hilfe
Beste Grüße
Karl Weber

 

[Dirk]

Hallo Karl, willkommen im Forum.

Du kannst so eine Stoppuhr relativ einfach mit einem AVR realisieren. Eine Fehlergrenze von 10ms zu erreichen dürfte kein Problem sein, allerdings sollte man hier den Takt für einen Timer nicht von dem Systemtakt ableiten, sondern von dem Takt des TOSC-Oszillators, an dem ein Uhrenquarz angeschlossen wird. Je länger die Zeiten sind, die du stoppst, desto ungenauer kann es werden, wenn du vom Systemtakt ableitest. Für Vergleichsmessungen ist das in Ordnung, wenn es nur darauf ankommt, wer schneller ist.

Wenn du ein Dot-Matrix-LCD verwenden möchtest, benötigst du 7 Signalleitungen (3 zum Steuern und 4 Datenleitungen), zumindest bei der Großzahl der Displays auf dem Markt (LCD-Controller ist HD44780 oder kompatibel).

Verwende einfach einen AVR, der möglichst klein und gut verfügbar ist. Er sollte ausreichend I/Os besitzen und möglichst einen Timer, der sich asynchron durch einen Uhrenquarz an den Pins TOSC1/2 takten läßt.

Wie möchtest du denn programmieren, Bascom, Assembler oder C?

Grüße,
Dirk

 

[Starburst]

Hallo,

danke für die rasche Antwort.

Da muss ich mich dann genauer einlesen, welcher Controller das kann. Ich würde gerne in Bascom programmieren.
Die Stoppuhr wird eigentlich nur in einem Zeitraum bis maximal 1 Minute betrieben. Da müsste der Takt schon sehr ungenau sein denk ich mal.
Ich warte noch immer auf das Päckchen, dass ich endlich anfangen kann zu probieren
Ich werd mich inzwischen mit der Treiberstufe beschäftigen.

Danke
LG
Karl

PS: Ich will eine LED-Matrix einsetzen, kein LCD.

 

[Markus]

Hallo Karl,

bzgl. Controller würde ich mir an Deiner Stelle den Mega16 oder Mega32 mal genauer anschauen. Die Dinger kannst Du extern mit 16Mhz takten und damit hast Du auch intern (in SW) genug Performace für "zeitkritische" Aufgaben.

Bereits der Mega16 verfügt über ausreichend Ressourcen. Er ist ein 40-pinner im DIL Gehäuse und lässt sich auch noch schön Löten. Ggf. kannst Du Ihn auch unter dem LCD-Display verstecken und von der anderen Seite löten.

Bzgl. BASCOM kannst Du Dir mal das BASCOM-Buch von Klaus Kühnel anschauen. Das erscheint mir als Einführung ganz tauglich.

Grüße,
Markus

 

[Starburst]

Hallo Markus,

danke für den Tip. den Mega16 gibts auch im DIP Gehäuse und somit kann ich es auch auf mein Programmer-Board stecken. Somit währe für ausreichend Power gesorgt. Fehlt nur noch das nötige Hirnschmalz meiner seits ;-)

Buch werd ich mir organisieren, Danke.

Mir ist immer noch nicht klar, wie das dann in Hundertstel gehen soll, obwohl ich schon etwas gestöbert habe... naja. Brauch noch etwas "licht ins dunkel".

LG
Karl

PS: Auf mein Board geht doch nur der ATmega168 (maximal DIP28). Ist aber recht ähnlich oder? Ich kann den Atmega16 zwar brennen, mit dem Multiboard, aber auf dem Entwicklungsboard hat er net Platz.

 

[Dirk]

Hallo Karl,

PS: Auf mein Board geht doch nur der ATmega168 (maximal DIP28). Ist aber recht ähnlich oder? Ich kann den Atmega16 zwar brennen, mit dem Multiboard, aber auf dem Entwicklungsboard hat er net Platz.

du kannst ja mal unsere Database ansehen, hier hast du einen Überblick über die AVR-Mikrocontroller.

Der ATmega168 hat für dein Projekt eigentlich ausreichend Ressourcen. Bei den verfügbaren Port-Pins (23) könnte es knapp werden, das kommt darauf an, wie du die LED-Matrix-Anzeige aufbauen möchtest. Eine 4stellige 7Segment-Anzeige (z.B. min : s : 1/10s 1/100s ) könnten man statisch nicht ansteuern, man müsste hier entweder multiplexen, oder noch etwas Hardware spendieren, die einem die Ports erweitert.

Grüße,
Dirk

 

[Starburst]

Hi,

das mit dem Multiplexen war mir schon bewusst... Hab da auch schon eine Schaltung im Netz gefunden.
Ich acker mich mal durch Lehrbücher und Datenblätter, damit was weitergeht

Danke LG
Karl

 

[Starburst]

Wegen LED Anzeige. Ich glaub da würde mir sowas sehr helfen oder?

EBAY LINK

LG
Karl

 

[Dirk]

Hallo Karl,

Wegen LED Anzeige. Ich glaub da würde mir sowas sehr helfen oder?

Du bräuchtest davon mehrere Anzeigen, mit einer Anzeige kannst du eine Dezimalstelle darstellen, bzw. ist das ja eine 5x7 Dotmatrixanzeige, es würden 7 Segmente für eine Dezimalstelle ausreichen.

Mir erscheint es einfach zu teuer.

Ich weiß jetzt auch nicht wie du die Anzeige realisieren möchtest. Ich würde mir an deiner Stelle eine Anzeige auf Lochraster aufbauen (4 x 7Segment), oder große fertige 7Segment anzeigen verwenden. C... hat da bestimmt etwas. Als Treiber könntest du zum Beispiel ULN2807 verwenden (Darlington-Transistor-Array).

Grüße,
Dirk

 

[Starburst]

Das Problem ist ja, dass die Anzeige recht groß sein muss, damit sie auch von der Entfernung her gut sichtbar ist.
Die Auktion beinhaltet ja schon 4 solcher Anzeigemodule, 2 für Sec, 1 für Zehntel Sec, 1 für Hundertstel Sec.
4 10cm 7-Segment Anzeigen sind beim C teurer, als diese Angebot samt Versand.

Aber da wart ich mal ab. Zuerst versuch ichs auf dem Entwicklerboard. Wenns auf dem onboard LCD funktioniert, mach ich mir um die Großanzeige Gedanken.

Gruß
Karl

 

[Starburst]

So, jetzt meld ich mich mal wieder.

Hab das Programm soweit fertig, dass es auf dem LCD läuft. Das mit dem externen Display mach ich anschließend.
Jedoch merke ich das der Atmega8 mit 8MHz an seinen Grenzen ist. Der kann ja eigentlich 16 MHz, aber wie stell ich das ein? mit dem myAVR Demo kann ich nur 8 MHz einstellen... kann mir da jemande helfen?

LG
Karl

 

[Dirk]

Hallo Karl,

mit diesem Entwicklungssystem kenne ich mich leider nicht aus, aber um eine mehrstellige 7-Segmentanzeige zu multiplexen, benötigt man eigentlich nicht so viel Rechenleistung. Auch wenn du alle 10ms eine mehrstellige Dezimalzahl (ggf. BCD) inkrementierst, benötigt man dafür kaum Rechenzeit.

Es könnte sein, dass du zu oft hintereinander eine Ausgabe auf dem alphanumerischen Display machst, möglich dass hier Bascom bei der Übertragung der Daten Pausen verwendet, die Rechenzeit verbraten.

Wo genau stößt du denn an Grenzen?

Grüße,
Dirk

 

[pcprofi]

Also zum einen ist es glaube ich so, dass der Mega8 die 16MHz nur mit einem externen Quarz schafft, die ich sowieso bei jeder Realtime-Anwendung nehmen würde. Denn mit dem internen RC-Oszillator läuft der wie eine Eieruhr.

Dann meine ich auch, dass Multiplexen an sich mit 8 MHz locker zu machen sein sollte - wenn es sich dabei "bloß" um einen Stoppuhr handelt.

In wie fern stößt du an die Grenzen? Flash-mäßig oder Rechenzeit?

Evt. zeig doch mal Codeschnippsel, vielleicht kann man da noch was sparen, wenn man am Flash festhängt.

OT: Ist es eine sinnvolle Alternative zum Multiplexen, wenn man die Stellen seriell z.B. in mehrere Schieberegister schaufelt und dann anzeigt und per Reset zurücksetzt und neu schreibt?

Gruß Rainer

 

[Markus]

Hallo Karl,

zu Deiner Frage bzgl. der Taktfrequenz kann ich Dir vielleicht weiterhelfen. Ich kenne die Boards von myAVR. Taucht nur die Frage auf, wie genau Deine Ausstattung aussieht. Hast Du:
- myMultiProg Parallel oder USB?
- myAVR Board USB oder Parallel?

Ich gehe mal implizit davon aus - entsprechend Deiner Schilderungen dass Du mit dem Ding auch Entwickels - dass Du das myAVR Boards vermutlich in der Version V2.06 besitzt.
Dabei ist es jetzt ersmal zweitrangig, ob mit USB oder Parallel.

So, schauen wir uns das Ding mal etwas genauer an.
Via Standard ist das Board mit einem 3,6864 MHz Quars bestück. Bedeutet Du verwendest entweder den intern oder gehst auf intern 8 MHz. Übrigens, die Programmierboards von myAVR haben auch den 3,6864 MHz Quarz extern bestückt.
Wie Du dem beigefügten Schlatplanauszug aus der Bauanleitung des myAVR entnehmen kannst ist der Quarz Q1 bereits schon direkt mit dem Mega verbunden. Warum da dann allerdings noch zwei Pin's für Patch-Kabel angeschlossen sind bleibt erst mal zweitrangig.

Aus meiner Sicht hast Du, wenn Du extern mit 16 MHz fahren möchtest hier die Möglichkeit, den originalen Quarz auszulöten und gegen einen 16MHz Quarz zu ersetzen. Du musst dann halt noch die FUSE's von Deinem Mega anpassen und schon müsste er mit 16 MHz rennen.

Bzgl. der ISP Programmier-Taktfrequenz die entweder über Parallel-Schnittstelle oder über USB kommt erwarte ich erstmal keine Probleme. Durchaus ein Thema es mal auszuprobieren. Du könntest auch den alten Quarz auslöten und den neuen erstmal nur in die beiden beim Quarz plazierten "Löcher" stopfen.

Hoffe Dir hilft das weiter.

Übrigens, ausführliche Bauanleitungen und Schaltpläne gibt es auf der Hompage von myAVR zum download. Da kannst Du bei Gelegenheit - wenn icht schon passiert - mal schmökern gehen.

Grüße,
Markus

 

[Starburst]

Hi Leute,

danke für die Hilfe.

Zur erläuterung... .Ich hab keine 7 Segment-Anzeige, sondern hab mir in der ebay bucht so Dot-Matrix-Anzeigen gekauft, die schon "Hirn" (einen PIC) drauf haben. Ich brauch dazu "nur" eine gewisse Impulsfolge rüberschicken und dann wird das entsprechende Zeichen angezeigt. So weit bin ich aber noch gar nicht.

Das mit dem externen Quarz stimmt... da hab ich nicht weit genug gedacht. Im Moment fahr ich mitn internen RC Oszi... der ist denkbar ungenau... ich weiß. Ich spiel mich halt ein bisschen mit dem Startwert des Timer0, dass es gut passt.

Werd morgen Code posten, bin gerade unterwegs...

Wo ich mir einbilde, dass ich an die Grenzen komme (vielleicht lieg ich ja auch wiedermal daneben)... In der Hauptschleife wird die ganze Darstellung der Zahl vorgenommen... 4 eigene Zahlen werden eben immer Incrementiert und wieder zurückgesetzt... so wie eine Stoppuhr eben funktionieren soll. In der Timer0ISR wird nur der Hundertstel-Sekundenwert Inkrementiert... die anderen (Zehntel-Sek. Sek1, Sek2) leiten sich dann darauß ab. Ich muss jede Zahl extra zählen lassen, weil ich ja jede Zahl dann extra an eine Matrix-Anzeige schieben muss.
Ich hab ganz am ende der Hauptschleife einen Zähler eingebaut, der mir Anzeigen soll, wie oft die Hauptschleife durchlaufen wird, bevor der Interrupt wieder unterbricht und inkrementiert. Der Zähler wird in der ISR wieder zurückgesetzt. Wenn ich mir den Zähler jetzt aufn Display anschau, dann zeigt der 1, oder in manchen fällen sogar 0 an. Das heißt ja, dass die Hauptschleife im schlimmsten Fall nicht ganz durchlaufen wird, oder?

Danke für die Hilfe, schönen Sonntag Abend noch.

LG
Karl

 

[Markus]

Hi,

wenn Du Lust hast dann teil uns doch mal die genaue HW-Konfiguration in Form von Datenblättern bzw. Links auf Bauteile mit so das wir "Helfenden" etwas genauer wissen was Du gebastelt hast um Dir noch besser helfen zu können. z.B. welches myAVR Board usw.

Grüße,
Markus

 

[pcprofi]

Hi Leute,

danke für die Hilfe.

Zur erläuterung... .Ich hab keine 7 Segment-Anzeige, sondern hab mir in der ebay bucht so Dot-Matrix-Anzeigen gekauft, die schon "Hirn" (einen PIC) drauf haben. Ich brauch dazu "nur" eine gewisse Impulsfolge rüberschicken und dann wird das entsprechende Zeichen angezeigt. So weit bin ich aber noch gar nicht.

Ich würde sagen, das ist für den Anfang bis der Hauptteil - die Uhr nämlcih - läuft gar nicht mal schlecht.

Das mit dem externen Quarz stimmt... da hab ich nicht weit genug gedacht. Im Moment fahr ich mitn internen RC Oszi... der ist denkbar ungenau... ich weiß. Ich spiel mich halt ein bisschen mit dem Startwert des Timer0, dass es gut passt.

Werd morgen Code posten, bin gerade unterwegs...

Womit programmierst du denn? Ich finde, dass Bascom gar nicht mal so schlecht ist - es hat so viel von Basic (warum nur... )

Wo ich mir einbilde, dass ich an die Grenzen komme (vielleicht lieg ich ja auch wiedermal daneben)... In der Hauptschleife wird die ganze Darstellung der Zahl vorgenommen... 4 eigene Zahlen werden eben immer Incrementiert und wieder zurückgesetzt... so wie eine Stoppuhr eben funktionieren soll. In der Timer0ISR wird nur der Hundertstel-Sekundenwert Inkrementiert... die anderen (Zehntel-Sek. Sek1, Sek2) leiten sich dann darauß ab. Ich muss jede Zahl extra zählen lassen, weil ich ja jede Zahl dann extra an eine Matrix-Anzeige schieben muss.
Ich hab ganz am ende der Hauptschleife einen Zähler eingebaut, der mir Anzeigen soll, wie oft die Hauptschleife durchlaufen wird, bevor der Interrupt wieder unterbricht und inkrementiert. Der Zähler wird in der ISR wieder zurückgesetzt. Wenn ich mir den Zähler jetzt aufn Display anschau, dann zeigt der 1, oder in manchen fällen sogar 0 an. Das heißt ja, dass die Hauptschleife im schlimmsten Fall nicht ganz durchlaufen wird, oder?

Du musst nicht jeder Ziffer einzeln zählen - viel zu aufwändig. Es reicht wenn du die (evt. Minuten, wenn Benötigt) die Sekunden bis 60 (as Byte) und die 100stel bis 100 (as byte) zählst.
Um nachher die Ziffern einzeln zu multiplexen gibt es zumindest in BASCOM funktionen, die einzelne Zeichen liefern können - das wäre da kein Problem. Hier musst du sparen - sonst kommst du möglicherweise in Bedrängnis weil die ISR zeitlich gesehen einfach zu lange dauert.

Also hier ergeben sich für mich mehrere Probleme:
Für 0.01 Sek braucht man schon ne ordentliche Rechenleistung. Wichtig dabei ist, dass die ganze Zählerei abgeschlossen ist, bevor die nächste ISR asugelöst wird. Ist das nicht der Fall gehen im Worst-Case Überträge verloren - da muss man gut aufpassen.

Warten wir mal deinen Code ab - vll ist der ja schon ganz gut in solchen Dingen.

zur Anzeige:
Bei einer LCD-Anzeige diese nicht einfach in der Main-Loop wiederholen - könnte flimmern geben.
Wenn schon so in der Mainloop, dann wenigstens immer nur dann,wenn sich auf der Anzeige was geändert hat bzw. auch dann immer nur die Betroffene Stelle.

Im übrigen würde ich mir überlegen, ob ich während die Uhr läuft einfach nur die Sekunden ausgebe, und sobald die Uhr gestoppt wird dann an die Sekunden die 10' und 100' Sekunden dranhänge - spart unheimlich Ressourcen, und ist nebenbei mittlerweile bei vielen Zeitmessanwendungen so Standart.

Gruß Rainer

 

[Dirk]

Hallo zusammen,

ich denke die Zählerei ist hier nicht so zeitkritisch. Ich weiss jetzt nicht, was Bascom aus dem Basic so erzeugt, aber betrachten wir doch mal kurz das "Problem", einfach nur, um ein Gefühl dafür zu bekommen, wie sehr so eine Zählfunktion den AVR belastet.

Alle 10ms müssen wir eine Zeit inkrementieren. Das 10ms-Ereignis erzeugt uns ein Timer-Interrupt.

Außer dem Interrupteinsprung, eventuell Register auf Stack sichern (push, pop) und ReturnFromInterrupt (reti) haben wir keine Maschinenzyklen. Ich gehe hier vielleicht einmal von 10 Zyklen aus.

Wenn man nun eine 4Byte-Variable als Zählvariable nutzt, erhält man nach knapp 43 Millionen Sekunden (oder guten 700.000 Minuten) einen Überlauf, das dürfte reichen. Im ungünstigsten Fall ist die 4Byte-Variable im SRAM, laden in Arbeitsregister, inkrementieren und zurück speichern in das SRAM kostet etwa 40 Zyklen. Das kann man alles in der ISR erledigen. Für das Zählen benötigen wir also insgesamt 50 Zyklen alle 10ms.

Takten wir den AVR einfach mal mit 1MHz, ein Maschinenzyklus dauert somit 1us. Wir "verbrauchen" also alle 10ms etwa 50us für den Zählvorgang, das ist eine Auslastung von 0,5% (bei 16MHz Takt sind es 0,03125%).

Das ist also nicht sehr viel Auslastung, selbst wenn ich jetzt mit Zyklen etwas zu knapp gerechnet habe, ist da noch sehr viel Reserve drin.
Selbst eine BCD-Dekodierung, um die einzelnen Dezimalstellen der Displays anzusteuern, könnte man in der ISR noch erledigen (das würde ich aber dann im Hauptprogramm machen).

Die große Unbekannte ist noch die Übertragung der Daten zu den Anzeigen, das würde ich im Hauptprogramm erledigen. Die Übertragungsroutine könnte man alle 10ms ausführen (TimerInterrupt könnte hier ein Flag setzen), 50ms würde allerdings reichen . Start/Stopp-Taste könnte man ggf. an ExtInt anschließen.

Eine zweite Unbekannte ist hier noch Bascom, ich vermute aber, daß Bascom ausreichend "schnellen" Code erzeugt.

Ich hoffe, ich hatte bei den Überlegungen keinen Denkfehler, aber ich lasse mich gerne verbessern

Grüße,
Dirk

 

[pcprofi]

Eine zweite Unbekannte ist hier noch Bascom, ich vermute aber, daß Bascom ausreichend "schnellen" Code erzeugt.

Imho ja. Bei meiner von Hand geschrieben Uhr mit 32kHz-Quarz als Rechentakt! (nciht Timer) reichten die 32kHz völllig aus, um vollständig zu funktionieren - für alle Zähler.

Trotzdem sollte man Ressourcen sparen finde ich, denn ein ungleichmäßiges Multiplexing ist auch suboptimal - ich meine, das könnte man nämlich wahrnehmen, wenn die Frequenz nicht so superhoch ist...

 

[Starburst]

Hier mal das Datenblatt der Dot-Matrix Anzeigen:

DISPLAY PDF

Code kommt gleich nach.
LG
Karl