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

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.

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).

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

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.

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.

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