-
        

Ergebnis 1 bis 6 von 6

Thema: delay hat ein Problem mit Optimierungsstufe 0

  1. #1
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    21.05.2008
    Ort
    Oststeinbek
    Alter
    28
    Beiträge
    607

    delay hat ein Problem mit Optimierungsstufe 0

    Anzeige

    Hallo Leute,
    für einen Bot brauche ich einen Teil mit sehr "zeitintensiver" Programmierung (muss genau darauf achten, wieviel welcher Befehl zum Ausführen braucht).
    Die Zeit Messe ich mit einem Timer.
    Das Problem ist nun, dass mir der Preprozessor in meinem Testprogramm alle Rechnungen wegoptimiert, die er wegoptimieren kann, was zufolge hat, dass ich nicht die tatsächliche Zeit messen kann, die der Roboter später braucht (im Teasprogramm tippe ich die Werte einfach ein, später sollen sie aber gemessen werden).
    Ich habe schon versucht, ihn zu überlisten, indem ich Zahlen mit einem Timer (und Wartezeiten) generiert habe, aber auch die hat er wegoptimiert!
    Die Optimierung kann ich nicht abstellen, denn dann meckert der Compiler, dass delay (welches ich für die LCD-Ansteuerung brauche) nicht ohne Optimierung auskommt.
    Hat jemad vielleicht einen Tipp? Kann man die Optimierung vielleicht nur teilweise abstellen?

    Danke im Voraus, Yaro

  2. #2
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    21.05.2008
    Ort
    Oststeinbek
    Alter
    28
    Beiträge
    607
    Mir ist gerade die Idee gekommen, dass man das doch mit "volatile" lösen könnte.
    Ich werde es ausprobieren, und poste das Ergebiss dann hier rein.

  3. #3
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    21.05.2008
    Ort
    Oststeinbek
    Alter
    28
    Beiträge
    607
    Jap, so funktioniert es! =)
    Gibt es noch andere gute Möglichkeiten, dieses Problem zu lösen?

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.801
    Ohne Not sollte man die Delay-Routinenn nicht verwenden.

    Anlass zur Verwendung von delay-Zeug sind zB:
    • Es ist absolut nicht möglich, für das Timing einen Timer einzusetzen. Ein Timer kann oft auch für mehrere Aufgaben verwendet werden (Entrprellung, Infrarot-Empfang, Drehgeber-Auswertung, DCF, ...)
    • Es muss nur einige Ticks gewartet werden, zB wenn man irgendwo nach Zustandsänderung warten muss, bis sich Pegel geändert haben (zB aufgrund parasitärer Kapazitäten)
    • Quick & Dirty Programm oder man weiß es nicht besser. Delay-Routinen vertrödeln Zeit, sind ungenau und wenn IRQs aktive sind nochmal ungenauer. Das durch sie verursachte Blockieren führt schon bei kleineren Problemen zu unangenehmen konzeptionellen Problemen. Bei zeitkritischen Anwendungen hat man nix zu verschenken, aber gerade das tun Delay-Routinen. Überleg dir einfach, wie du eine LED im 1-Sekunden-Takt blinken lässt, und eine Zweite im Takt von 1.1 Sekunden.
    Disclaimer: none. Sue me.

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    08.07.2004
    Ort
    Südhessen
    Beiträge
    1.312
    Hey Sprinter: Er verwendet sicher ein Library, und damit kann er sich die Nutzung nicht aussuchen, da die Library für die Anzeige keinen Timer verbrauchen soll/will/darf, nimmt sie die Delay-Routinen, ist ja klar.

  6. #6
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    21.05.2008
    Ort
    Oststeinbek
    Alter
    28
    Beiträge
    607
    Die LCD-Routinen habe ich zu einem großen Teil von microcontroller.net, habe sie aber z.T. verändert. Delay verwende ich, weil ich öfters mit unterschiedlichen ATmegas arbeite, und es nicht jedes mal wieder neu einstellen will. Timer verwende ich sehr häufig, deswegen will ichs lieber nicht mit timern machen.
    Wenn man ein LCD verwendet, ist es mit der Zeitintensivität meißtens sowieso hin... Den LCD verwende ich hier nur zu test und debug-Zwecken, die jeder für sich nicht besonders Zeitintensiv sind.

    Gruß, Yaro

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •