Druckbare Version
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.Zitat:
Zitat von witkatz
Also genau hierfür, wo man um eine lahme HW herumprogrammieren mußZitat:
Zitat von Peter(TOO)
MfG Klebwax
Dafür natürlich nicht. Ein Zeichen ausgeben mit einem (oder zwei bei 4bit Anschluss) Strobe auf Enable des LCD kann natürlich in einem Schritt untergebracht werden.Zitat:
Zitat von Klebwax
Zwei Postings weiter hat Siro ein __delay_ms(2) - Wartezeit für die Ausführung des LCD Kommandos. Auch wenn hier 100µs ausgereicht hätten - dafür lohnt sich das Multitasking schon mal - wenn der µC parallel noch andere Aufgaben rechnet.
- - - Aktualisiert - - -
meine Schrittkette sieht z.B. so aus:mitCode:if(Tmr8bit250usLcd == 0){
Tmr8bit250usLcd = 4; // Standardtaktung 1ms, kann in der Statemachine überschrieben werden
static int8_t step = 0;
switch(step){
case 0: // Set DDRAM Adresse = 0x00
LCD_TRIS_DATA = 0; // Data Pins to Outputs
LCD_RS = 0; // command
LCD_DATA = 0b10000000;
strobeE();
Tmr8bit250usLcd = 20; // next call 5ms
Idx = 0; // Initilaisiere Zeichenausgabe
step++;
break;
case 1: // 16 Zeichen der Line 1 ausgeben
LCD_RS = 1; // data
LCD_DATA = LCD_line1[Idx];
if (LCD_DATA == 0)
LCD_DATA = ' ';
strobeE();
Idx++; // Nächstes Zeichen der Zeile
if (Idx >= 16) {
Idx = 0;
step++;
}
break;
//usw
Die Timervariable Tmr8bit250usLcd wird in einem 250µs Timerinterrupt dekrementiert.Code:void strobeE(){
LCD_E = 1;
__delay_us(1); // delay 1us
LCD_E = 0;
}
Ist natürlich nur ein Vorschlag, vielleicht habe ich Siro's Frage auch nur falsch verstanden ...Code:if (Tmr8bit250usLcd != 0)
Tmr8bit250usLcd--;
Hallo,
Er bekommt in die 500ns immerhin 37 NOPs rein @72MHz.Zitat:
Zitat von Klebwax
Je nach CPU kann man in dieser Zeit schon einiges rechnen.
- - - Aktualisiert - - -
Auch bei 72MHz reichen die 500ns nicht einmal für einen Taskswitch des Schedulers aus. Hier ist dann meist die Anzahl CPU-Register das Problem.Zitat:
Zitat von HaWe
Bei 32 Registern und einem PUSH/POP ALL-Befehl kommt man für den Wechsel auf mindestens ein Äquivalent von etwa 100 NOPs. Dann nochmals zurück, sind dann 200 NOPs, wo 37 reichen würden. Wenn die Busbreite nur die Hälfte der Registerbreite beträgt ist es gleich mal das Doppelte.
500ns sind einfach eine doofe Zeit für dieses Problem :-(
Eine Möglichkeit habe ich noch vergessen, meist hat man so etwas:
Wenn man jetzt eben nicht streng strukturiert programmiert, kann man "s++:" und weiteres in das delay(500ns); verlegen.Code:put_LCD(char c)
{
Daten ausgeben
Delay(500ns)
Strobe setzen
Strobe rücksetzen
}
LCD_Out(char *s)
{
while (*s)
{
put_LCD(*s);
s++;
// evtl. noch weiteres.
}
}
Ist dann halt nicht so übersichtlich, aber sogar schneller, weil der Overhead für den Aufruf von put_LCD() wegfällt.Code:put_LCD(char c)
{
c ausgeben
Delay(500ns)
Strobe setzen
Strobe rücksetzen
}
LCD_Out(char *s)
{
while (*s)
{
c ausgeben
s++;
// evtl. noch weiteres.
Delay(Restzeit)
Strobe setzen
Strobe rücksetzen
}
}
Allerdings muss man sehen, dass man die Optimierung des Compiler ausschaltet, sonst weiss man nicht was ab geht.
Sinnvoll kann auch der Einsatz von Inline Assembler an dieser Stelle sein, das kann der Compiler dann nicht optimieren und man hat immer den selben Code.
Allerdings trägt man dann selber die Verantwortung, wenn sich die CPU-Frequenz ändert. Das lässt sich aber teilweise mit Macros automatisieren.
Besonders bei CISC-CPUs muss man dann aber noch aufpassen, dass kompatible CPU-Versionen nicht unbedingt die selbe Zyklenzahl für die Befehle benötigen.
Bei RISC-CPUs ändert die Zyklenzahl meistens nicht, da sie meistens der Anzahl Speicherzyklen entspricht.
In beiden Fällen spielt dann aber noch das Pipelining und vorhandener Cache ins Timing mit rein.
Hier kann es auch hilfreich sein, JMPs an Stelle der NOPs zu verwenden.
Ach, früher war das alles einfacher :-(
MfG Peter(TOO)
Nicht wirklich. Erst mal muß man einige Register retten, sie mit neuen Werten laden, dann ist die halbe Zeit rum und man speichert die Werte zurück und lädt die Register zurück und hat noch nichts gerechnet. Und je schneller die CPU, desto mehr Register sind betroffen und desto langsamer ist der Speicher im Vergleich zu Registern. Zeitscheiben im einstelligen Mikrosekundenbreich sind wegen des Taskswitchoverhead keine brauchbare Idee, mehr eine akademische Luftnummer.Zitat:
Zitat von Peter(TOO)
Aber es läßt sich sicher ein exotisches Beispiel finden, wo das sinnvoll ist.
MfG Klebwax
Hallo Klebwachs,
Das habe ich alles in der Antwort an HaWe ausführlich erläutert.Zitat:
Zitat von Klebwax
MfG Peter(TOO)
Guten Morgen, Ihr wart ja fleissig , erstmal vielen Dank
für Eure Informationen und Ideen.
@ Sisor:
Ja, Du hast recht, so kann ich den Timerüberlauf ignorieren. Gefällt mir sehr gut.
@Klebwax:
Ich hab die "2ms" nur zum Testen/Bestätigen das dort das Problem liegt eingebaut.
Das ist natürlich völlig "überdosiert"
Die Idee, dass der Compiler an bestimmten Stellen NICHT optimiert, wäre in meinem Falle
sogar auch eine Lösung, find ich aber etwas unschön.
@Witkatz:
Ich habe so etwas in der Art auch schon implementiert.
Sieht fast aus wie dein Code :
Ich werde mich für die Timer Variante entscheiden, ein paar Mikrosekunden warten, spielt in dieser, meiner Anwendung keine Rolle.Code:typedef struct
{
void (*function)(); /* do this function */
U32 microSec; /* do next function after xxx micro second */
} t_TimerFunc;
/* shift out time for one byte is 17,92 microsec. we calc with 25 for every byte */
/* the latch signal are set to 5 microsec. active phase and 5 microsec. recovery time */
const t_TimerFunc functable[] = {
{fn_shift_out_leds,100}, /* shift out 32 Bit LED code, after 100 microsec. */
{fn_DISP_ENABLE_LEDS_HIGH,5}, /* generate the latch signal for 5 microsec. high*/
{fn_DISP_ENABLE_LEDS_LOW,5}, /* reset the latch signal to low */
{fn_shift_out_pressure,50}, /* shift out 16 Bit data for pressure display, after 50us*/
{fn_DISP_ENABLE_P_HIGH,5}, /* generate the latch signal for 5 microsec. high */
{fn_DISP_ENABLE_P_LOW,5}, /* reset the latch signal to low */
{fn_DISP_ENABLE_Q_LOW,5}, /* enable data for the flow display */
{shift_out_flow,100}, /* shift out, 5 Bytes, data for flow display */
{fn_DISP_ENABLE_Q_HIGH,5}, /* disable data for the flow display */
{fn_DISP_ENABLE_V_LOW,5}, /* enable data for the volume display */
{fn_shift_out_volume,125}, /* shift out data, 5 Bytes, for volume display */
{fn_DISP_ENABLE_V_HIGH,5}, /* disable data for the volume display */
. . . .
Wie dem obigen Codeausschnitt zu entnehmen ist, wurde eine spezielle Struktur angelegt um die Vorgehensweise
möglichst übersichtlich zu gestalten. Der Timer Interrupt ruft jeweils die entsprechende Funktion auf und
startet dann eine neue Zeitzähleinheit. Nach Ablauf der Zeit wird die nächste Funktion aufgerufen.
Wurden alle Funktionen durchlaufen, wird wieder mit der ersten Funktion in der Tabelle begonnen.
Die entsprechende Timer Interrupt Funktion konnte so kurz und übersichtlich implementiert werden.
Für dieses Vorgehen wurde der Prozessorinterne Timer 1 verwendet.
fn_xxxxxx sind die entsprechenden Funktionen die aufgerufen werden.
void TMR1_IRQHandler (void)
{
functable[timer1FuncNo].function(); /* do the selected function */
LPC_T1TCR.bits.CR = 1; /* set reset STOP and HOLD Timer */
/* set the new time for the next interrupt */
LPC_T1MR0 = functable[timer1FuncNo].microSec;
/* selects the next function which want to call from this interrupt */
if (++timer1FuncNo >= ((sizeof(functable) / sizeof(t_TimerFunc))))
timer1FuncNo = 0;
LPC_T1IR.bits.MR0INT = 1; /*clear the timer match interrupt */
LPC_T1TCR.bits.CR = 0; /* release reset START Timer */
}
Um Sicherzustellen, dass alle Funktionen weniger Zeit benötigen, als angegeben, wurden die Laufzeiten mit einem
Oszilloskop gemessen. Dazu wurde am Anfang der Funktion ein Portbit gesetzt und am Ende der Funktion wieder gelöscht.
Dieses Portbit konnte so ohne Probleme mit einem Oszilloskop abgegriffen werden und die Laufzeiten anhand der
High Phase des Signal gemessen werden. Die Laufzeiten wurden mit verschiedenen C-Compiler Optionen gemessen
um sicherzustellen, daß unabhängig von den Compiler Einstellungen, die Zeiten eingehalten werden.
Es wurde auf Speed, Size und Balanced mit hoher, niedriger und völlig ohne Optimierung gemessen.
Die langsamste Variante war die völlig ohne Optimierung. Diese maximalen Zeiten wurden in der Software,
in den entsprechenden Funktionen, als Kommentar mit aufgenommen.
Es wurde jedoch aus Sicherheitsgründen noch ein Rekursionstest eingeführt. Sollte sich die
Software innerhalb einer Funktion der Tabelle befinden und es erfolgt, aus welchen Grund auch immer, ein erneuter Eintritt
in diese Timerfunktion, liegt ein Fehler vor und das Gerät wird sofort angehalten. Dadurch könnte sonst ein Stacküberlauf
generiert werden und dies soll natürlich abgeblockt werden. Normalerweise ist dieses Vorgehen nicht nötig, da der Interrupt
erst am Ende des Interrupt Handlers bestätigt wird und damit das momentan anstehende Interruptbit gelöscht wird.
Ich habe mich aber aus Sicherheitsgründen trotzdem für diese Vorgehensweise entschieden.
Habe ein 16 Bit Timer übrig, der dafür ausreicht.
Meine While Schleife für den Timerwert blockiert ja nur kurzzeitig das Hauptprogramm,alle Interrupts laufen ja weiter. ADU, RS232 usw.
Siro
- - - Aktualisiert - - -
Ich habe noch einen wichtigen Grund, warum ich der Delay Funktion niemals eine "1" übergebe:
Es könnte passieren, dass garnicht gewartet wird.
Wenn nach dem Setzten der globalen Variablen DelayCount der Timerinterrupt schon auftritt,
wird der Wert gleich um eins runtergezählt und die While Schleife sofort wieder verlassen.
Wir haben also generell eine Abweichung von ca. -1 Millisekunde.
Code:/* EXTREM wichtig: volatile, sonst optimiert der Compiler Code weg */
volatile static U32 DelayCount; /* used for Delay_ms function */
/*----------------------------------------------------------------------------*/
/* DelayCount wird im Interrupt kontinuierlich um 1 runtergezählt */
/* sofern er nicht schon 0 ist.
void Delay_ms(U32 ms)
{
DelayCount = ms;
while (DelayCount) ;
}
/*----------------------------------------------------------------------------*/
/* this Interrupt handler is called every Millisecound */
void SysTick_Handler(void)
{
if (DelayCount) DelayCount--;
}
/*----------------------------------------------------------------------------*/
Coole Idee mit der Funktionstabelle. Hab ich mir gemerktZitat:
Zitat von Siro
Ich nehme für solche ms-Timings lieber einen 250µs Basistakt. Damit können mit einem char-Zähler (8bit PIC -> char wo es nur geht) Wartezeiten von 1ms bis 1s ziemlich gut realisiert werden, wenn eine Abweichung von 250µs keine Rolle spielt.Zitat:
Zitat von Siro
C ist in seiner ursprünglichen Form für die embeded Programmierung eigentlich nicht geeignet. Ohne einen Mechanismus, der die Optimierung steuert, geht nichts. Der Compiler würde sonst jede Abfrage von Funktionsregistern bis zur Unbrauchbarkeit optimieren. Stichworte sind volatile und INTRINSIC FUNCTIONS. Es mag für dich zwar unschön sein, ist aber unumgänglich.Zitat:
Zitat von Siro
Wenn hier nicht ein solcher Mechanismus greifen würde, würde der Compiler das Setzen von LCD_E auf 1 rausschmeißen. Da niemand LCD_E liest, während es 1 ist, kann es auch gleich auf 0 gesetzt werden. Toter Code. LCD_E muß also volatile sein, damit das funktioniert.Code:void strobeE(){
LCD_E = 1;
__delay_us(1); // delay 1us
LCD_E = 0;
}
@Peter
Ich habe deine Antwort nur bis --aktualisiert-- lesen können, als ich schrieb.
MfG Klebwax
@Klebwax:
Das Problem Optimierung ist mir schon recht oft zum Verhängnis geworden.
Genau in solchen Situationen wie Du eben beschrieben hast.
Habe immer öfter bemerkt, dass ein "volatile" unumgänglich ist, damit der "schlaue" Compiler es auch "richtig" versteht.
Am Anfang hab ich immer gemerkert :p warum der Compiler meinen Code klaut,
Er hat ja recht würd ich aus heutiger Sicht sagen, woher soll er wissen dass......
Ich hab grad noch etwas rumprobiert und da stellt sich gleich noch eine Frage:
Zuvor der Code, der schien zu laufen.....
Beim Timerüberlauf stimmt aber die Berechnung nicht mehr. Doch dazu später....
Nun zur Frage:Code:/*--------------------------------------------------------------------------*/
/* static volatile U16 t_old; */
inline void wait_us(U16 us)
{ U16 t_old;
t_old = TIMER1_TC;
while ((TIMER1_TC - t_old) < us) ;
}
/*--------------------------------------------------------------------------*/
Ich habe das Schlüsselwort "inline" benutzt, damit darf der Compiler den Code ja direkt einsetzen ohne einen Call.
Ob er das macht bleibt glaube ich ihm überlassen.
Damit ich meine Funktion evtl. sogar aus verschiedenen threads bzw. Interrupts aufrufen könnte, müsste mein Variable t_old ja Dynmsich auf dem Stack liegen, also Lokal zum Funktionsaufruf.
Aber wie funktioniert das mit dem Inline, ist das überhaupt erlaubt ? Inline und lokale Variable ?
Der Compiler könnte den Call nun sparen aber was macht er mit der Variable t_old ? die müste er ja dynamsich auf dem Stack verwalten.
Wenn es um Geschwindigkeit geht und ich nur aus einem Thread die Funktion aufrufe, kann ich die Variable ja Global anlegen,
ich vermute hier wird er den besten Code dafür erzeugen können.
Warum meine Berechnung nach Timerüberlauf nicht mehr funktioniert, habe ich unn auch ermittelt.
while (TIMER1_TC - t_old < us) ; /* geht nicht */
/* Also "komplette" explizite Typwandlung auf allen Werten und Ergebnissen angewendet: */
while ((U16)((U16)(TIMER1_TC) - (U16)(t_old)) < us) ; /* siehe da, es funktioniert */
/* nun Typwandlungen gekürzt */
while ((U16)(TIMER1_TC - t_old) < us) ; /* auch OKAY */
Durch die Integer Promotion des Standard Typs int bei 32 Bit muss hier anscheinend das Ergebnis der Subtraktion
explizit wieder in einen unsigned 16 Bit gewandelt werden, sonst geht es schief, jedoch nur manchmal, je nach Timerstand.
Ich bin begeistert und kann nun das Wochenende geniessen...
Habt auch ein schönes, warmes WE.
Siro