Ich komme mit den Delay funktionen des XC8 kompilers nicht zurecht: Im User's Guide steht zur Funktion _delay(): >An error will result if the delay period requested is too large >(approximately 50,659,000 instructions). For very large delays, >call this function multiple times. Wenn ich delay(500000); schreibe gibt der Compiler einen Fehler aus: >Error [1355] D:\...\main.c; 42. inline delay argument too large und bei __delay_ms(100); den gleichen Fehler. Zum __delay_ms/__delay_us lese ich in der User's guide: >These macros simply wrap around _delay(n) and convert the time based >request into instruction cycles based on the system frequency. Also liegt das Problem immer beim _delay(). Ich habe die Free version vom XC8 und lese die Warnung: >Warning [1273] ; . Omniscient Code Generation not available in Free mode Das heißt nur dass ich mit der Free-Version Einschränkungen die der Optimierung habe?
:
Bearbeitet durch User
Hallo Hartl, wo wohnst du denn eigentlich ?
die sind so irgendwie definiert:
#define __delay_us(x) _delay((unsigned
long)((x)*(_XTAL_FREQ/4000000UL)))
#define __delay_ms(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000UL)))
wobei bei 18f das eine 16bit Variable ist, kein unsigned long, ist halt
compiler glue code.
_XTAL_FREQ muss richtig definiert sein, und da es _delay keine Funktion!
ist, wird ein konstanter Wert benötigt.
also bei 40Mhz ist __delay_ms(6) das maximum, da
65536 / (40000000/4000) = 6,5536 ist.
Aber es sollte nicht so schwierig sein, sowas zu basteln:
void delay_ms(unsigned int X)
{
do
{
x--;
__delay_ms(1);
}
while(X > 0);
}
Nachtrag, umsonst sind die __ nicht, und eigentlich ist dies schon soo oft im INet behandelt worden, dass man sich schon fragt, warum du nicht danach gesucht hast. Bitte nicht Böse verstehen, es sollte nur als Anregung fuer deine nächste Frage dienen.
chris schrieb: > Hallo Hartl, wo wohnst du denn eigentlich ? Wieso? chris schrieb: > wobei bei 18f das eine 16bit Variable ist Mit _delay(100000); hat der XC8 kein Problem. chris schrieb: > _XTAL_FREQ muss richtig definiert Das habe ich gemacht: #define _XTAL_FREQ 20000000 chris schrieb: > Aber es sollte nicht so schwierig sein, sowas zu basteln: Das stimmt, hatte ich auch vor, mich hat nur irritiert, dass ich 500000 nicht verwenden kann, auch wenn steht, dass ich ca. 50,659,000 cycles langes delays machen kann. Abgesehen, von meinem Problem mit dem delay komm ich mit dem XC8 gut zurecht. Meine 20x4 LCD Routine funktioniert mit ein paar kleinen Änderungen. Wenn ich #include "delays.h" schreibe kann ich die Delays vom C18 verwenden, ich wollte aber die Delays mit __delay_ms abhängig von der Frequenz machen, und bei der Initialisierung bei 40ms auf diese Problem gestoßen. Da mein 18F45k22 bis 64MHz läuft, habe ich kiene delay_ms >4 verwendet.
:
Bearbeitet durch User
Aus Neugierde, da du bereits geschrieben hattest, du wohnst im Lande des Weines, Apfels und Speck. Compiler Fehler. Es ist bekannt, dass die freie Version den alten Code hat, und die pro Version den neuen fuer die Delay von Hitech. Weiters sind die 50... Cyclen bei einer 24bit Variablen, meines Wissens nach werden aber 16bit Variablen verwendet, also max ca 197000 cyclen, hingegem im XC16 werden effektiv 24bit benutzt, kann sich aber geändert haben. Auch damals war die Angebe der Cyclen 50... . Der freie Hitech Compiler verwendet den "neuen" _delay Code, warscheinlich funkt es damit. Auch bekannt ist, dass HTC _delay ein Problem mit 10ern hat, also z.B. 40, 100 , 200 funktioniert nicht, 39, 99, 199 funktioniert, auch 41, ... . Dies wurde in einer mittlerweilen älteren Version von Hitech behoben.
Hier hätte ich einen Code welcher funktioniert:
// Delay Function
#if _XTAL_FREQ >= 12000000
#define _delay_us(x) { unsigned char us; \
us = (x)*(_XTAL_FREQ)/(12000000)|1; \
while(--us != 0) continue; }
#else
#define _delay_us(x) { unsigned char us; \
us = (x)/(12000000/(_XTAL_FREQ))|1; \
while(--us != 0) continue; }
#endif
void _delay_ms(unsigned int ms)
{
unsigned char i;
do {
i = 4;
do {
_delay_us(164);
} while(--i);
} while(--ms);
}
Die _delay_us(164); ist eventuell an deine Optimierungsstufe sowie Interruptaktivität anzupassen.
chris schrieb: > Aus Neugierde, da du bereits geschrieben hattest, du wohnst im Lande des > Weines, Apfels und Speck. In Völs. ca. 17km nördlich von Bozen. Das Ganz mit dem Delays scheint einleuchten. Da ein ich delays nur sehr selten verwende, werde ich mich mit meinem aktuellen Wissensstand zufriedengeben… Lange Delays sind also nur mit Schleifen möglich…
Warum werden die PIC Compilerfragen immer unter der Rubrik 8051 eingestellt? Für PIC gibt es einen eigenen Bereich. Kann ein MOD die Themen verschieben?
Hi, echter 8051 schrieb im Beitrag #3466405: > Warum werden die PIC Compilerfragen immer unter der Rubrik 8051 > eingestellt? Für PIC gibt es einen eigenen Bereich. > > Kann ein MOD die Themen verschieben? Es gibt hier weder eine Rubrik 8051 NOCH PIC, die Rubrik ist allgemein Mikrocontroller und Digitale Elektronik Das was du als Rubrikaufruf verstehst (das 8051 in der Liste direkt über den ersten Beiträgen in der Threadübersicht) erzeugt lediglich eine voreingestellte Suche bei der als Suchbegriff XC8* hinterlegt ist. ICh denke damit sollen dann die Threads die sich mit der XC800 Serie befassen gefunden werden. Da der (neue) Microchip Compiler aber XC8 heisst passt er ebenfalls auf das Suchschema und alle Beiträge werden auch bei der 8051 Suchmaske gefunden. Das müsste vom Admin angepasst werden, also der vordefinierte Eintrag XC8* durch die beiden Begriffe XC88* und XC80* ersetzt werden, dann wird kein PIC Beitrag mehr gefunden. Ist natürlich WEIT OFF Topic hier, evtl kann einer der mitlesenden MODs das mal nach "Oben" melden! Gruß Carsten
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.