Hallo zusammen, wollte eine Verzögerung bei einem Messvorgang einbauen. Geht eigentlich darum das ein Kondensator sich innerhalb von dieser Zeit entladen sollte. Jetzt meine Frage, kennt AVR Studio den Befehl: _delay_s(1) oder, _delay_ms(1000) habe alternativ eine Lösung mit dem TIMER0 angestrebt... habe da einen Vorteiler von 1024 und den höchstmöglichen OC-Wert von 255 drinne. Is ja ein 8-Bit Register. Damit erreiche Ich aber nur einen Takt von ca. 15 Hz. Um damit auf eine Sekunde zu kommen müsste Ich ja nochmal zusätzlich ein 15er Teiler einbauen oder einfach ne Schleife durchlaufen... Kann mir da jemand nen Denkanstoß geben. Grüße
Mein 16-bit TIMER.1 ist schon für ne PWM reserviert....
Martin28 schrieb: > kennt AVR Studio den Befehl: _delay_s(1) AVR-Studio kennt überhaupt keine 'C'-Befehle noch irgendwelche Libraries. Hier ist Hilfe: http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html Aufmerksam lesen bitte! 900ss
Martin28 schrieb: > Um damit auf eine > Sekunde zu kommen müsste Ich ja nochmal zusätzlich ein 15er Teiler > einbauen Ja. Du hast genug SRAM und von dem nimmst ein Byte zum Zählen bis 15. Peter
Immer diese Delay. Die Funktion gehört verboten !!!!! Während diese Delay läuft, macht der µC NICHTS anderes als warten. Sobald eine programmbedingt notwendige Verzögerung über einige wenige µsekunden hinausgeht muss da ein Timer hin. ALLES ANDERE IST NUR MURKS !!!!!!!!!!
Ralph schrieb: > Immer diese Delay. > > Die Funktion gehört verboten !!!!! was hast du denn für ein Problem. Delay ist oft sinnvoll. Wenn man z.b. bei bei einer 1-Wire leitung das timing einhalten muss dann muss man ein paar µs warten. Dafür ist ein Timer ungeeignet.
Peter II schrieb: > Wenn man z.b. > bei bei einer 1-Wire leitung das timing einhalten muss dann muss man ein > paar µs warten. Dafür ist ein Timer ungeeignet. Hast du wirklich gelesen was ich geschrieben habe ?
Ralph schrieb: > Hast du wirklich gelesen was ich geschrieben habe ? ja, wenn z.b. zur diagnose bei boot eine LED mal 1 sekunden lang leuchten soll nutze ich auch ein delay. delays in der Hauptschleife stören auch niemand, ISR werden immer noch abgearbeitet.
@ Ralph (Gast) >Immer diese Delay. Immer dieses Regenwetter. >Die Funktion gehört verboten !!!!! Typisch deutsch. Vorschriften und Verbote statt Aufklärung. >Während diese Delay läuft, macht der µC NICHTS anderes als warten. Ist eben so. >Sobald eine programmbedingt notwendige Verzögerung über einige wenige >µsekunden hinausgeht muss da ein Timer hin. Käse. So allgemein kann man das gar nicht sagen. Wenn man weiß was man tut (tm) sind auch lange Wartezeiten durchaus OK. >ALLES ANDERE IST NUR MURKS !!!!!!!!!! Nö.
Da die Delay aber nicht mit einem Timer arbeite, sondern die Zeit einfach in einer Schleife absitzt hast du bei Interrupts eine undefiniert Dauer der Delay. zb delay auf 1 Sekunde, in der Sekunde kommen 1000 Interrupts a 100 µsec (zb Uart Übertragung) ==> Delay dauert damit nicht 1 sondern 1.1 Sekunden. Eine wirklich gute Funktion..... Wo ist das Problem da einen Timer einzusetzen ? Die 5 Min den Timer zu konfigurieren kann doch nicht das Problem sein, aber das Ergebnis ist eine verlässliche Zeit die nicht den ganzen µC lahm legt. Peter II schrieb: > delays in der Hauptschleife stören auch niemand, ISR werden immer noch > abgearbeitet. Das heißt deine Hauptschleife muss also nie Daten aus den Interrupts verarbeiten ? Es ist völlig egal wie lange deine Hauptschleife benötigt ? Dann gehe ich davon aus das du viel zuviel Logik in den Interrruptroutinen hast. Anstatt die Verarbeitung un der Hauptschleife zu erledigen. ==> Dioe Delay wird irgendeine Zeit liefern, aber bestimmt nicht die Zeit die du einstellst.
Ralph schrieb:
>Während diese Delay läuft, macht der µC NICHTS anderes als warten.
Da muß ich mal mit Radio Eriwan antworten:
Im Prinzip hast Du Recht, aber...
Wie sieht denn Deine Alternative aus, wenn ein Delay erzeugt werden muß.
Der Prozessor durchläuft weiter die Hauptprogrammschleife und macht
fleißig Rechenarbeit...
Aber was macht er denn wirklich? Das hängt sehr von der Anwendung ab:
- er kann Uarts bedienen
- AD-Wandler oder DA-Wandler bedienen
- er kann Ausgaben machen zeitgesteuerte, oder durch Verknüpfungen
festgelegte
- und und und
Aber es gibt auch Fälle, wo er nur durch die HP-Schleife nudelt und nix
vernünftiges macht, eben weil er wartet, bis Dein vorgeschlagener Timer
abgelaufen ist. Dann gehts im HP mit einer Verzweigung weiter. In
solchen Fällen kann es übersichtlicher sein mit einem Delay zu arbeiten.
Ich mag Delays auch nicht sonderlich, aber ich hab die Phantasie mir
Anwendungen vorzustellen, bei denen Delays
- einfach zum Ziel führen
- übersichtliche Abläufe darstellen
- den Prozessor genausogut auslausten wie eine HP-Schleife.
So what?
spontan schrieb: > Aber es gibt auch Fälle, Gibt es. Sind aber eher selten. Hand aufs Herz: In der Mehrzahl der Fälle, in denen Anfänger mit _delay_ms arbeiten, wäre eine Timerlösung besser. Und das fängt bereits mit dem gerne gemachten Lauflicht an, das plötzlich zusätzlich noch auf Tastendrücke das Muster umschalten soll. _delay_ms führt gerade bei Anfängern zu einer Programmstruktur, die für weitergehende Programmerweiterungen nicht geeignet ist. In dem Moment, in dem mehrere Dinge gleichzeitig passieren soll (Lauflicht UND parallel dazu soll das Muster zu jedem Zeitpunkt umschaltbar sein), ist dann das Rätselraten groß und es werden die tollsten Konstrukte erfunden, die dann auch nicht richtig funktionieren nur damit man am delay weiterhin kleben kann. Das es für delays sinnvolle Anwendungsfälle gibt, bestreite ich nicht. Bruache ich nur schnell ein Programm, welches irgendwas toggelt um eine Hadrware zu testen, nehm ich ein delay. Brauch ich eine Statusanzeige vor der Hauptschleife, nehm ich ein delay. Bruach ich was kurzes im µs Bereich, nehm ich ein delay. Dagegen hat auch keiner was. Aber abgesehen davon ist in der überwiegenden Mehrzahl der Fälle, mit denen wir uns hier im Forum rumschlagen müssen, _delay_ms nicht die Lösung sondern der Problemverursacher. Und der Weg zu einer sauberen Lösung beginnt damit, dem Aspiranten den Weg zu einem taktbasiertem, eventbasiertem bzw auf einer Statemachine basierendem Programm zu zeigen.
Also Danke nochmals für die aufklärenden Diskussionen, aber wie Ich schon am Anfang des Posts geschrieben habe, will Ich ja nichts anderes als warten das sich ein Kondensator entlädt, bevor Ich irgendwelche andere Routinen abarbeite... Ob da nun ein Timer läuft oder eine Delay-Funktion. Da sehe Ich jetzt irgendwie kein direkten Vorteil oder Nachteil. Das bezieht sich jetzt aber auch nur auf meine Anwendung. Sobald da z.B Daten per UART übergeben werden sieht das natürlich wieder anders aus. Grüße
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.