sehr Kurze Warteschleifen für das korrekte Timing

[Siro]

Ich hab mal eine Frage in die Runde:

Wenn ich z.B. ein LCD Display ansteuere und im Datenblatt steht:
Data Setup Time mindestens 500ns,

muss ich damit rechnen, dass meine CPU schneller arbeitet und demnach
ist ein Wartezyklus erforderlich.

Im Einfachsten Falle geht das natürlich mit delay_ms(1);
Einen Millisekundentimer hat man ja meist immer am laufen.

Ist natürlich "reine Zeitverschwendung"

Nicht lachen.....

Nun könnt ich mit NOP's die Zeit überbrücken.
ein NOP bei mir sind 13,88ns (72MHz Takt)
das wären dann 500ns / 18,88 = 36,023 NOPs für 500ns, also 37
Ist natürlich recht speziell und nicht sonderlich kompatibel

Oft sehe ich "for i" Schleifen, die je nach Optimierung und Compiler Einstellungen
aber völlig undefinierte Zeiten erzeugen.

Leide ich am Zeitverschwendungssyndrom ? oder wie macht Ihr das...

Siro

[HaWe]

ich verwende für solche "Probleme" grundsätzlich Multitasking, und zwar
- für Arduino: Scheduler.h (kooperativ), bei delay() wird die Timeslice trotzdem auf den nächsten Task weitergestellt, es geht also keine cpu-Zeit "verloren" ("non-blocking"),
- und für den Raspberry Pi: POSIX pthread (preemptiv), da kann sowieso jeder Task tun was nötig ist, sogar mit verschiedener Priorität, und delay() klappt hier ebenso "zeitsparend" ("non-blocking") über die wiringPi lib.

(ein Display ist ja nicht zeitkritisch, man kann sowieso nur alle 50 Milli- (!) Sekunden ein neues Bild wahrnehmen - es darf nur der übrige Programmablauf dadurch nicht blockiert werden.)

[Siro]

Hallo HaWe, Danke für deine Rückmeldung.
Mit Multitasking ist das sicher eine gute Lösung.
Habe bisher nur mit "einem" Task und tonnenweise Interrupts gearbeitet.
Da möcht ich mein System natürlich nicht ausbremsen.

Ich hab grad ein Paradebeispiel für "unsicheren" Code.

Ohne meine Compileroptimierung läuft das Display einwandfrei.
Schalte ich die "C" Optimierung ein, egal welche Stufe, funktioniert das Display nicht mehr.

Das Problem ist hier eindeutig das "Timing" was ich grad versuche "sinnvoll" zu ordnen.

void LCD_DataOut8(U8 data)
{
  LCD_RS_LOW;
  LCD_RW_LOW;
  LCD_EN_HIGH;
  Delay_ms(2);  /* ist hier nicht erforderlich */

  /* write the data byte, THREAD SAFE ??? RMW problem auf den PORTs */
  GPIO_CLR1 = LCD_DATA_BITS;
  GPIO_SET1 =  ((U32)(data) << 20);
  Delay_ms(2);   /* OHNE Delay gibt es ein TIMING PROBLEM sofern die C-OPTIMIERUNG eingeschaltet ist */

  LCD_EN_LOW;
  Delay_ms(2);   /* normalerweise nicht erforderlich */
}

[Mxt]

Warten mit NOPs geht natürlich bei "richtigen" Mikrocontrollern. Alles was z.B. die Taktfrequenz regelt oder mehrere Kerne hat, ist da weniger geeignet.

Für hardwarenahe Programmierung fehlt mir meist die Zeit, meist greife ich für schnelle Entwicklungen auf Dinge wie mbed zurück, da gäbe es mehrere Ansätze:
https://developer.mbed.org/handbook/Timeout
https://developer.mbed.org/handbook/RTOS#rtos-timer
https://docs.mbed.com/docs/getting-s...l_Guide/MINAR/

[Ceos]

meiner Erfahrung nach, haben alle Controller < 100Mhz irgendwo ein Register oder ein Makro zur Compilezeit, welches über die Taktrate informiert und in der regel innerhalb der <delay.h> ausgewertet wird. An diese Methode kann man sich ja anhängen! Controller > 100Mhz (in der Regel auch Mehrkerner) haben fast immer ein Cycleregister, weches nebenher in einem festen Takt (i.d.R. definiert aber auch manchmal programmierbar) mitzählt. Der Zugriff darauf ist dann immer die Kunst

[Siro]

@Picture.
Bei den PICs hab ich auch die ASM Zyklen gezählt, das ging wunderbar.

Bei "C" weia man aber leider nicht was der Compiler draus macht. Ich hab grad das kalte Grausen bekommen als ich mir den "optimierten" ASM Code angesehen habe.
Kann man kaum noch nachvollziehen.
Ich möcht halt "möglichst sicher" programmieren und da lohnt es ab und an mal etwas genauer "nachzuhaken" wie man das am besten macht.
Oder sogar mal etwas "experimentieren"

@Mxt:
Ich programmiere immer "alles neu" ganz unten. Benutze keine Bibliotheken.
Damit mache ich mir zwar das Leben schwer, aber ......

@Ceos:
Ja, da bin ich auch grad dran. Ich lasse einen Timer frei laufen, im Mikrosekundentakt.
Den Zählerstand lese ich und warte bis er xxx Mikrosekunden überschritten hat.

count = TimerCount+20; /* warte 20 Mikrosekunden */
while (Timercount < count) ;

Problem: Der Timer läuft bei 32 Bit nach rund 1,19 Stunden über
Das muss ich noch berücksichtigen....

[Sisor]

Überlaufproblem: Sofern 'TimerCount' und 'old' unsigend sind, geht folgendes:

old = TimerCount;
while (Timercount-old < 20) ; // warte 20µs

[Klebwax]

@Picture.
Bei den PICs hab ich auch die ASM Zyklen gezählt, das ging wunderbar.

In C muß man das natürlich nicht. Dafür gibts fertige Funktionen bzw Macros (XC8 Users Guide)

__DELAY_MS, __DELAY_US, __DELAYWDT_US, __DELAYWDT_MS
Synopsis
__delay_ms(x) //request a delay in milliseconds
__delay_us(x) //request a delay in in microseconds

Description
It is often more convenient to request a delay in time-based terms, rather than in cycle
counts. The macros __delay_ms(x) and __delay_us(x) are provided to meet this
need. These macros convert the time-based request into instruction cycles that can be
used with _delay(n). In order to achieve this, these macros require the prior defini-
tion of preprocessor symbol _XTAL_FREQ, which indicates the system frequency. This
symbol should equate to the oscillator frequency (in hertz) used by the system.
On PIC18 devices only, you can use the alternate WDT-form of these functions, which
uses the CLRWDT instruction as part of the delay code. See the _delaywdt function.
The macro argument must be a constant expression. An error will result if these macros
are used without defining the oscillator frequency symbol, the delay period requested
is too large, or the delay period is not a constant.

Diese Funktionen/Macros werden natürlich nicht "wegoptimiert". Also am Anfang des Codes
#define _XTAL_FREQ xxxx

und dann einfach

_delay_us(1)

Bei Zeiten im Submikrosekundenbereich lohnt die Verwendung eines Timers nicht wirklich.

MfG Klebwax

PS: warum du eigentlich ein Delay von 2 Millisekunden programmierst, obwohl du eigenlich 500 Nanosekunden brauchst, erschließt sich mir nicht ganz.

[witkatz]

Hallo Siro,

count = TimerCount+20; /* warte 20 Mikrosekunden */
while (Timercount < count) ;

mit while blockierst du wieder den µC. Wenn der PIC in der Wartezeit noch andere Sachen tun soll, geht das nur über kooperatives Multitasking. Für Routinen, die "nebenbei" laufen sollen, könnte man eine Schrittkette nach folgendem Muster verwenden:

void DoJob1(void){
    static unsigned short Evt = 0;
    static char step = 0;
    
    // getaktete Schrittkette
    if((TMR0 - Evt) < 0x7fff ) {
        Evt = TMR0 + 1000; // nächter Schritt in mind. 1ms
        switch (step){
            case 0: 
                // Do Something
                step ++;
                break;
            case 1: 
                // Do Something
                step ++;
                break;
            case 2: 
                // Do Something
                Evt = TMR0 + 5000; // nächter Schritt in 5ms
                step = 0;
                break;
        }
    }
}

mit Timer0 konfiguriert mit 1MHz und 16Bit Breite auf PIC18F. Die Funktion muss mindestens alle 30ms gepollt werden. Wenn die Zeit "reif" ist, wird ein Schritt ausgeführt und der Zeitwert für den nächsten Schritt gesetzt.

[Klebwax]

Hallo Siro,
mit while blockierst du wieder den µC. Wenn der PIC in der Wartezeit noch andere Sachen tun soll ....

Was soll in 500ns (in Worten Nanosekunden) wohl sinnvolles passieren? Da kann man kaum einen Call, ein Return und das Retten von einem Register unterbringen.

NOPs verwendet man eigentlich nur, wenn man nur ein paar braucht, sonst bremst man die CPU aus.

Also genau hierfür, wo man um eine lahme HW herumprogrammieren muß

MfG Klebwax