Moin Leutz, Seit nun mehr 2 oder 3 Tagen spiele ich mit dem ARM LPC2106 rum. Vorher hatte ich PICs und AVRs. Doch irgendwie stellen sich mir ein paar Fragen, oder besser Sachen, die ich nicht so ganz verstehe. 1) Diese Assembler Boot-Files (*.s) wer schreibt die? Momentan fehlt mir das Wissen und die Zeit sie selber zu schreiben, von daher habe ich die einfach mal als gegeben Vorausgesetzt. Selbiges für das *.ld File. Gibts da irgendwo gute Tutorials zu dem Thema???? 2) Der UART läuft bei mir so weit, nur die Sache mit dem Interrupt noch nicht. Er springt einfach nicht in die Interrupt-Methode, wenn ein Byte ankommt... #define VIC_UART0 6 #define VIC_ENABLE (1<<5) #define UIER_ERBFI (1<<0) VICIntSelect &= ~BIT(VIC_UART0); // UART0 as IRQ VICIntEnable |= BIT(VIC_UART0); // UART0 enabled VICVectCntl0 = VIC_ENABLE | VIC_UART0; VICVectAddr0 = (unsigned)"""INTERRUPT-METHODE"""; UART0_IER = UIER_ERBFI; Was paßt an der Stelle nicht? Der Interrupt-Vector ist auf den SRAM remapped (MEMMAP = 2;). Alle Beispiele die ich bisher zu dem Thema gefunden habe waren immer die gleichen, das ewig komplex aufgebaut wurde. Mit einem Ringpuffer und einigen Assembler Zeilen... Schön und gut, ich brauch es aber (momentan) nicht so komplex! Ich will momentan nur eine Methode haben, in die er springt, sobald 1 Byte ankommt. 3) Gibt es um die PORTs 0.23 0.24 irgend etwas, das ich bis jetzt völlig überlesen habe, oder habe ich die PORTs einfach irgendwie geschrottet?! Wieso?? Naja: PINSEL1=0; IODIR=0xFFFFFFFF; IOSET|=(1<<23)|(1<<24); Und wenn ich jetzt mit einem Messgerät DIREKT an den IC ran gehe, dann haben beide PINs 0V. Ich hab mir den IC unterm Mikroskop angeschaut und ich habe keinen Kurzschluss zu irgend einem anderen PIN!! (Bis ich das raus gefunden habe, war ich schon halb in der Irrenanstalt G) 4) Ja hmmm... Haltet mich für blöd: Was ist mit float und double? Wieso kann ich keine Gleitpunktrechnungen machen (oder Ganzzahlige Divisionen)!? Ich hab den Gnu arm gcc 3.4.3 und ich hab mal mein Makefile in den Anhang mit rein. Bin ich zu blöd ein Makefile zu schreiben, oder was ist da los? Aufgefallen ist mir das ganze, weil ich (als ersten Test) einen Treiber für den T6963C (Grafik-Display) geschrieben habe und wollte dann Steigungen von Geraden ausrechnen. BTW (Sollte es jemanden interessieren): Die Library ist fertig => könnte ich (bei Bedarf) online stellen. Man kann damit ein GLCD ansteuern, mit allem was man so braucht... OK einen kleinen Schönheitsfehler hat das Ding noch: Linien zeichnen (und so) geht mometan noch nicht, wegen dem Problem mit der Floats. Aber am AVR geht alles problemlos... Und soblad mir wer sagt, was ich falsch mache, wird alles funktionieren... Sooo, das wars von meiner Seite erstmal. Danke schon mal im voraus für den Support... Sid PS: Ich habe KEIN Testboard von Olimex und nein, ich habe auch KEIN Windows, also auch kein WinARM. Ich habe den GNU arm gcc 3.4.3...
Zu 1.) Sollte zum Lieferumfang des Compilers gehören (jeweils an den µC angepasst). Ist bei den kommerziellen gcc-Varianten der Fall. Du könntest Dir allerschlimmstenfalls eine Testversion einer kommerziellen gcc-Variante besorgen und Dir da den Code ansehen (Rowley Crossworks existiert auch in einer nicht-Windows-Version). Zu 3.) Benutzt Du zufälligerweise das JTAG-Interface? Das legt auch die Portleitungen oberhalb (mit größeren Nummern) des vom Interface verwendeten Bereichs lahm. Interessant ist hier die Verwendung des "secondary JTAG Interface", dann kann man noch einige Portleitungen zusätzlich verwenden.
1) THX 3) Hmm JTAG habe ich noch nie genutzt. Die PORTs 11-19 und 25-28 gehen definitiv. Und 23-24 gehen nicht. Die anderen habe ich noch nicht getest. Ich habe noch folgende Konfiguration: PIN 26 (RTCK) PULLUP PIN 27 (DBSEL) PULLDOWN Das sollte ja so passen... Naja evtl hab ich sie geschrottet. Die Punkte 2) und 4) wären mir momentan wichtiger G Besten Dank für die Infos. S1D
so viele ? und ! ... ich lege mal ein paar ? nach 1. Linker-Skripte sind in der Dokumentation zu ld erlaeutert (gnu.org...), Syntax ist nicht ARM-spezifisch. Vorlagen fuer Startup-Code und Linker-Skripte findet man fuer den LPC2106 doch einige. Wenn Wissen und Zeit fehlt, nimmt man halt "vorgekaute" (Keil-gcc-Beispiele, yahoo-Group, WinARM-Beispiele etc.) 2. Sind die Interrupts ueberhaupt global aktiviert? Ist der Interrupt-Vector im RAM auch initialisiert? Die Stacks? Wie sieht das genutzt Linker-Skript und der Startup-Code aus? In welchem Mode laueft die Anwendung? UART-Interrupts ohne Ringpuffer? - Gute Idee? 4. Fehlermeldung? libm? FP-Berechnungen nur fuer Linien? Gute Idee? Die Beispiele auf meiner WinARM-Seite sind fuer die arm-elf-gcc, newlib und die arm-elf-binutils, hat nichts mit Windows zu tun. Fuer RX/TX der LPC-UARTs gibt es nicht viele Moeglichkeiten der Anschaltung, egal von welchem Hersteller das Board ist. Martin Thomas
Junge Junge geht das heute fix G 2) Interrupts global eingeschaltet? - Ich hab das Ding erst 2 Tage. => Ich hab noch ned sooo viel Plan. Der Interrupt Vector sollte im RAM liegen. Den Rest schaust du dir vielleicht doch mal selber an. Ich hab mal das ganze "Chaos" in den Anhang gepackt. (Achtung: CHAOS) Und zum Thema des Ring-Buffers: Der kommt schon noch, ich will nur mal die Basic Funktionen checken und dann implementier ich die 3 Zielen selber. 4) Die Fehlermeldung schaut folgendermassen aus: /usr/local/arm/bin/arm-elf-gcc glcdpaint.c -c -o glcdpaint.o /usr/local/arm/bin/arm-elf-gcc -mcpu=arm7tdmi -I. -Tlpc2106-rom.ld -Wall -Werror -nostartfiles -Wl,-Map=test.map,--cref -nostdlib -Os -s -o test boot.s test.o system.o uart.o glcd.o glcdpaint.o glcdpaint.o(.text+0x2e0): In function `LCD_Line': : undefined reference to `__floatsidf' glcdpaint.o(.text+0x314): In function `LCD_Line': : undefined reference to `__floatsidf' glcdpaint.o(.text+0x340): In function `LCD_Line': : undefined reference to `__gtdf2' glcdpaint.o(.text+0x3e0): In function `LCD_Line': : undefined reference to `__floatsisf' [--noch einige mehr--] collect2: ld gab 1 als Ende-Status zurück make: *** [test] Fehler 1 Kann das sein, das ich beim kompilieren des Compilers vergessen hab die math_lib mit anzugeben? Ich habs folgendermassen gemacht: # cd [binutils-build] # [binutils-source]/configure --target=arm-elf --prefix=[toolchain-prefix] --enable-interwork --enable-multilib # make all install # export PATH="$PATH:[toolchain-prefix]/bin" # cd [gcc-build] # [gcc-source]/configure --target=arm-elf --prefix=[toolchain-prefix] --enable-interwork --enable-multilib --enable-languages="c,c++" --with-newlib --with-headers=[newlib-source]/newlib/libc/include # make all-gcc install-gcc # cd [newlib-build] # [newlib-source]/configure --target=arm-elf --prefix=[toolchain-prefix] --enable-interwork --enable-multilib # make all install # cd [gcc-build] # make all install # cd [gdb-build] # [gdb-source]/configure --target=arm-elf --prefix=[toolchain-prefix] --enable-interwork --enable-multilib # make all install Sind dann eigentlich die ganzen Typ-Definitionen auch in der Math_lib verankert? Weil die mag er ja auch nicht... SiD PS: @mthomas: wie is den deine WinARM Seite?
Also an der math.h sollte das doch nicht liegen, das die floats und doubles und so nicht gehen oder?! vorallem hab ich eine math.h in meinem Include dir. n8 s1d
> @mthomas: wie is den deine WinARM Seite?
Wie? Na ja, schlicht, viel Text, kaum Bilder.
Eher wo ... google, WinARM, erster Treffer
Ich meinte nicht math.h sondern libm (Linkeroption -lm). Keine libc und
libgcc in den Linker-Optionen? (selbst nie ohne ausprobiert). Vielleicht
einfach mal die Beispiele von der WinARM-Seite anschauen.
@mthomas: Ach das ist deine Seite G Nett... Ich hab bisher immer die 2.Zeile überlesen sry JUHU!!! Es geht. Ich kann jetz float und alles verwenden. 2 kleine Sch*** Optionen haben gefehlt beim linken: -lc -lgcc Dann wäre da jetzt nur noch die Sache mit den Interrupts. mthomas, was hast du damit gemeints, mit den Interrupts global zu enablen? So was wie das sei(); beim AVR? Ich hab (bis jetzt noch nichts passenden gefunden, ausser: static inline unsigned __get_cpsr(void) { unsigned long retval; asm volatile (" mrs %0, cpsr" : "=r" (retval) : /* no inputs */ ); return retval; } static inline void __set_cpsr(unsigned val) { asm volatile (" msr cpsr, %0" : /* no outputs */ : "r" (val) ); } unsigned enableIRQ(void) { unsigned _cpsr; _cpsr = __get_cpsr(); __set_cpsr(_cpsr & ~IRQ_MASK); return _cpsr; } Wenn ich aber dann enableIRQ(); machen und dann kommt ein Interrupt, dann steht der ganze Prozessor und ich muß ihr reseten. Was paßt da dann nicht?! (Der Code ist immernoch ziemlich der gleiche wie oben. Und die Interrupt Geschichte steht in der uart.c) Noch ein kurzes Wort zu der *.ld und *.s geschichten. Bis jetzt habe ich noch nichts damit gemacht. Aber mal vom Prinzip her: In der *.ld steht drinnen was vom Programm er wo ablegen soll und was er alles für Speicherarten hat und wieviel. Ich verwende da immer das *-rom.ld Damit das Programm ins Flash kommt und der Stack (und Co) ins RAM. Das is doch so weit ok oder? Und das *.s ist doch so eine art BIOS für das ganze. Es wird zuerst gestartet, und dieses initialsiert dann alles und übergibt dann die Kontrolle an das eigentliche Programm!? Liege ich da total falsch oder stimmt das so einigermasen?! Gibts da evtl ein paar gute Doku Seite zu dem ganzen? (I know, ich wiederhole mich) thx4all S1D PS: Ich brauch n mini-Progi: "Interrupt für Dummies"
Ja, grob wie "sei" beim AVR. Der zitierte Code ist zumindest aehnlich dem, den ich verwende. Da es "haengt", ist man schon mal einen Schritt weiter, denn der Interrupt wurde zumindest ausgeloest. Interrupt-Vector immer noch auf RAM "gemapped"? Ist da auch Platz reserviert (vom Linker-Skript) und der Vektor auch an den RAM-Speicheradressen initialisiert (von Startup-Code)?. Testweise nicht remappen. Wenn's "geklaute" .ld und .s fuer "ROM" sind, wird sehr wahrscheinlich nichts fuer remapping vorbereitet. Prinzip Linker-Skripte und Startup ist im Prinzip so wie geschrieben. >PS: Ich brauch n mini-Progi: "Interrupt für Dummies" Hmm, auf welcher Seite es so eines wohl gibt? Ist fuer Timer-IRQ - sollte das "Eis brechen".
JAAAAAAAAAAAAAAAAA Juhu, es geht... Ich hatten den Interrupt Vector irgendwie falsch gemappt. Irgendwo haben ich mal gelesen: MEMMAP=2; aber es muß heissen: MEMMAP=1; Und jetz gehts... So, dann sind jetz praktisch all meine Fragen beantwortet worden, bis auf die mit den PORTs 0.23 0.24, aber die werde ich wohl irgendwie geschossen haben. Ich habe leider momentan nur einen Prozessor, deswegen kann ich nichts sicheres sagen, aber es muß so sein G... Egal. @mthomas: Kein wunder das dir der Code oben bekannt vor kommt G. Er is von dir "geklaut"... Ich hab von niemand anderen was gutes dazu gefunden. Und zum rein kommen ist copy&paste immer noch die schnellst und einfachste Methode. Später schreib ich das dann mal neu... (Das Makefile hab ich z.B. schon seit dem Begin selber geschrieben, weil mir ein 10kB Makefile einfach viel zu groß und unübersichtlich ist.) ##### thx4all ##### Jürgen PS: also dann praktisch: THREAD CLOSED (oder?)
If you want to set a GPIO output pin, use IOSET = (1<<23)|(1<<24); instead of IOSET |= (1<<23)|(1<<24); The |= operation is already implicitly done in IOSET. The same goes for IOCLR.
Bitte 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.