Libs mit delay Funktionen

[Fried V. (tich)]

Hallo an Alle,
ich benötige mal wieder 'ne Erleuchtung:
Habe mir eine LCD Lib gebastelt die delay Funktionen (die neuen) nutzt 
und auch problemlos funktioniert. Nur werden die delays bei der 
Copilierung auf 16 Mhz bezogen. Nutze ich die Lib später in einem 
anderen Proggie für 10 Mhz, werden die delays entsprechend länger, da 
die lib ja nicht angepasst wird. Wie muss ich die Programmstrukur 
ändern, damit das funktioniert? Die delays im Modul der Libfunktionen 
als extern zu deklarieren und das #include <util/delay.h> im (neuen) 
Hauptprogramm zu machen, wird vom Compiler angemeckert. Ideen?
Danke, Fried

[Andreas K. (a-k)]

Fried Vissel wrote:

> Nutze ich die Lib später in einem
> anderen Proggie für 10 Mhz, werden die delays entsprechend länger,

Welche Delay-Funktionen meinst du? Wenn das die aus der avr-libc sind, 
die werden bei niedrigerer Taktfrequenz nicht länger.

[Simon K. (simon)]

Andreas Kaiser wrote:
> Welche Delay-Funktionen meinst du? Wenn das die aus der avr-libc sind,
> die werden bei niedrigerer Taktfrequenz nicht länger.

Natürlich werden die Delays länger, wenn er F_CPU nicht anpasst (und das 
schrieb er ja auch).

[Oliver (Gast)]

Eigentlich ist ja kein Mikrocontrollerprojekt so riesig, daß nicht alles 
immer aus den sourcen compiliert werden kann. Die paar Sekunden länger 
stören nicht.

Ansonsten bleibt dir z.B. nur übrig, nur hardwareunabhängige Funktionen 
in die lib zu packen, alle hardwareabhängigen Funktionen in eine 
Sourcedatei auszulagern, und die mit jedem Projekt neu zu kompilieren. 
Neben dem Prozessortakt kann sich ja auch die Pinbelegung ändern, oder 
ein ähnliches Display benötigt andere delay-Zeiten, usw.

Spätestens, wenn dann ein anderer Prozessor zum Einsatz kommt, muß eh 
alles neu kompiliert werden.

Oliver

[Karl H. (kbuchegg)]

Du kannst deiner Lib (vorausgesetzt es ist wirklich eine
Library und nicht einfach nur ein *.c + *.h File Konglomerat)
zb. eine Funktion spendieren, in der du der Lib die verwendete
Taktfrequenz mitteilst.

Innerhalb deiner Library, führst du alle delays zb auf 16Mhz
zurück (so lässt du das Compilieren) und eine Basiszeiteinheit,
zb 0.1 ms zurück und verlängerst dann die Wartezeiten mit Schleifen
um auf die abweichende Taktfrequenz zu reagieren.

uint8_t TaktMhz;

void SetTakt( uint8_t Mhz )
{
  TaktMhz = Mhz;
}

void myDelay_ms( uint8_t ms )
{
  ms = 10 * ms * TaktMhz / 16;

  while( ms > 0 )
    _delay_ms( 0.1 );
}

Derjenige, der die Lib verwendet, muss am Programmanfang deine
Lib von der verwendeten Taktfrequenz informieren und deine Lib
leitet dann daraus die notwendigen Korrekturfaktoren ab.

PS: Ich hab jetzt nicht kontrolliert, ob die Zahlenwerte da oben
sinnvoll sind oder nicht. Auch könnte man bei den delays für die
Berechnung noch einen konstanten Zeitanteil abziehen. Mir ging
es ums Prinzip, wie man eine Lib für veränderte Rahmenbedingungen
anpassbar machen kann, ohne alles ständig neu kompilieren zu müssen.

[Andreas K. (a-k)]

Simon K. wrote:

> Natürlich werden die Delays länger, wenn er F_CPU nicht anpasst (und das
> schrieb er ja auch).

Ok, wenn er ein Kompilat für alle verwenden will. Aber wozu das? Binäre 
Libs ergeben bei Microcontrollern nur Sinn, wenn nichts 
hardwarebezogenes enthalten ist. Das hat sich auch bei der avr-libc 
gezeigt, wo beispielsweise das EEPROM-Handling anfangs auf allen AVRs 
gleich war, mittlerweile aber nicht mehr, und umgekrempelt werden 
musste.

[Fried V. (tich)]

Ja, ihr habt recht dass eine Lib keine hardwareabhängigen Funktionen 
enthalten sollte. Damit werden aber fast alle zeitabhängigen Routinen 
nicht mehr "libfähig", es sei denn längere delays stören nicht (LCD, 
I2C) aber wenn es auf genaues Einhalten von delays ankommt (one wire 
z.B.), muss man halt für jede CPU neu kompilieren. Ist ja auch nicht 
weiter schlimm, dazu kommt auch noch dass die delay Funktionen ja Makros 
sind und keine echten Funktionen.
Danke für alle Eure Beiträge
Fried