Hallo,
da ich noch ein Dev Board vom LPC 2368 hier habe mit einem schönen
Display wollte ich dieses auch nutzen. Leider ist der ARM7TDMI schon
lange obsolet und wird auch von EmBLocks nicht mehr per Wizzard
unterstützt. Und meine alte Rowley Crossworks Kaufversion habe ich nicht
mehr.
Der TDMI basiert auf dem Armv5 Modell. Ist es bei emblocks möglich eine
eigene CPU zu definieren? Die IDE nimmt ja im Wesentlichen die
Einstellung der Compiler Flags in allen möglichen Klicki Feldern vor. Es
müsste ja nur der Startup angepasst werden und das Linker Script?
Hat da mal einer was gemacht? Vielleicht auch in Eclipse?
Sebastian schrieb:> Obwohl, LPC2000 mit emBlocks wär' schon was..
So wie ich das sehe braucht man dafür nur ein passendes Linker Script
(erzeugte Rowley selbst aus der Memory Map.xml), eine Anpassung der
Device Eigenschaften und zum debuggen braucht es eine svd Datei, was
schon schwieriger wird. Die Rowley IDE war ja purer Luxus, Symbol
Navigator, Memory Anzeige usw usw. Dagegen ist Emblocks ja echt leer und
CooCox Kinderkram.
Diese IDE braucht man ja eigentlich nur zum Debuggen wegen des bequemen
Handlings. Ansonsten verpacken die doch nur die ganzen Parameter in
einen Riesen Rattenschwanz an Options und übernehmen das Erzeugen des
Makefiles aus dem Projekttree.
Jedenfalls kapiere ich die LPC2000 noch auf Registerebene und habe nie
Libs gebraucht und wollte den deswegen nicht einmotten.
Christian J. schrieb:> Leider ist der ARM7TDMI schon> lange obsolet und wird auch von EmBLocks nicht mehr per Wizard> unterstützt.
Na und? Wozu brauchst du EmBlocks?
Und Wizards? Das sind m.E. eher böse Zauberer..
Wirf mal nen Blick in die "Lernbetty" hier im Forum, dort werkelt
ebenfalls ein ARM7TDMI drin und selbiger wird selbstverständlich sowohl
von allen Keils und IAR's und GCC's unterstützt. Ich hatte damals die
Entwicklung mit dem Keil 4.1 oder so gemacht und dann nochmal mit nem
Yagarto (4.irgendwas? hab's vergessen) nachvollzogen. Bis auf die
Hakeligkeit des GCC zwischen ARM und THUMB und einem völlig abartigen
Assembler-Quellstil (für den Startup und die SVC's) geht beides - und
das sogar mit gleichen Quellcodes. Einige Teile (GDI, Schriften,
Konvertierungen) laufen bei mir unverändert sogar auf völlig
andersartiger Hardware (BigEndians). Und beim GCC sogar OHNE jegliches
Linkerscript (da im Linker bereits enthalten)
W.S.
W.S. schrieb:> Wirf mal nen Blick in die "Lernbetty" hier im Forum,
Neeeeeinnnnnnn! :-)
Ich frickel mir das mal mit Code::Blocks hin .... versuche es zumindest.
N'Abend,
die Kiste ist recht einfach: Man installiere sich emIDE von Segger, die
hat die LPC2xxxx alle mit drin und viele andere. Da Segger natürlich
verkaufen will ist der einziger eingetragene Debugge ein J-Link.
Oder man findet heraus wie sich der ST-LinkGDP Debugger aus der EmBlocks
IDE ansteuern lässt, der dabei ist und überträgt die Parameter dann in
die emIDE von Segger. Leider macht EmBlocks das unsichtbar, man sieht
nur die Ausgabe.
Und ohne alles überträgt er das was aber nicht ausreicht:
STLinkGDB.exe -nx -fullname -quiet -args
D:/temp/stm32f429/bin/Debug/stm32f429.elf
Tja, keine Ahnung.....
Starting debugger:
done
Setting breakpoints
Em::Blocks embedded firmware debugger for arm-none-eabi (Jul 15
2014/06:27:12).
Based on (GDB) 7.7 - License GPLv3+ by Gerard Zagema.
This program comes with ABSOLUTELY NO WARRANTY; for details type "show
war".
This is free software, and you are welcome to redistribute it
under certain conditions; type "show cop" for details.
Reading symbols from bin/FlashRelease/stm32F429_project.elf...
(no debugging symbols found)...done.
Source directories searched:
G:/STM32F429/emblocks/stm32F429_game_of_life;$cdir;$cwd
Remote debugging using localhost:4242
0x08002f740x20023b00 in Reset_Handler ()
Connected
Loading section .isr_vector, size 0x1ac lma 0x8000000
Loading section .text, size 0x3a40 lma 0x80001ac
Loading section .rodata, size 0x7c8 lma 0x8003bec
Loading section .init_array, size 0x8 lma 0x80043b4
Loading section .fini_array, size 0x4 lma 0x80043bc
Loading section .data, size 0x438 lma 0x80043c0
Loading section .ram, size 0x226c8 lma 0x80047f8
Loading section .co_stack, size 0x1000 lma 0x8026ec0
Start address 0x8002f74, load size 163520
Transfer rate: 29 KB/sec, 8606 bytes/write.
Christian J. schrieb:> Leider ist der ARM7TDMI schon lange obsolet
Da stellt sich doch grundsätzlich die Frage, ob es Sinn macht in ein
obsoletes System noch Zeit zu investieren. Ein vergleichbares board mit
aktuellem uc und tft kostet von Stm oder Nxp um die 30€. Für diese 30 €
bist du auf aktuellem Stand und hast immer noch genug Probleme mit der
ide, die du lösen kannst.
Übrigens gibt es hier auch Hinweise, wie man sich eine lauffähige
Toolchain für ARM7TDMI und ARM9 (hehehe) basteln kann:
http://devkitpro.org/
Logischerweise bezieht sich das auf den Nintendo DS, aber mit ein
bisschen Arbeit lässt sich das auch auf andere ARM7 übertragen. Der DS
ist übrigens ein wirklich hübsches Entwicklungssystem mit OpenGL und
einer Menge netter Peripherie. Nur schade, das der Audio AD Wandler nur
12 bit oder so hat.
Christian J. schrieb:> Der TDMI basiert auf dem Armv5 Modell.
Das ist falsch. Der ARM7TDMI basiert auf der Architektur ARMv4T. Einige
andere ARM7-Varianten basieren auf ARMv3 oder ARMv5TEJ. Einige
ARM9-Varianten basieren ebenfalls auf ARMv4T und andere auf ARMv5.
grundschüler schrieb:> Da stellt sich doch grundsätzlich die Frage, ob es Sinn macht in ein> obsoletes System noch Zeit zu investieren. Ein vergleichbares board mit> aktuellem uc und tft kostet von Stm oder Nxp um die 30€
Ähm....... Beitrag "Re: Retro Fieber: Z80 oder 68000 ?"
Seit 30 Jhren osolet. Mit meinen 46 bin ich ja auch schon "obsolet"
Noch Fragen? :-)
Da ich ausschliesslich im Hobbybereich mit sowas fumfrickel spielt das
keine Rolle, man nimmt was da ist. Was mich an dem Cortex M4 etwas stört
wo alles ja prima mit läuft ist, dass das irgendeine Hardware sein
könnte, durch CMSIS, StdPeriphLib und die TM oder UB HAL hindurch kriege
ich da eh nix von mit. Arduino Style. Die CPU löst sich auf in einen
Satz Funktionen, egal ob ein F0 oder F1 oder F4, sie fühlen sich alle
gleich an bei Fahren, alle Automatik, alle mit Navigationssystem :-) Ich
schaffe es nicht mal die Taktfrequenz zu ändern, weil das tausend
Nebeneffekte hat auf die Peripherie.
Der LPC2xxxx war der letzte Vertreter, wo ich noch Bit für Bit eine PLL
eingestellt habe, die Timer, Uart Bits usw. Nur mit einem Riesen Header,
der die Register auf Structs abgebildet hat. Der VIC Interrupt mit der
Primecell 192 war etwas buggy aber machbar.
Habe mir daher einen J-Link bestellt bei mouser, der einen JTAG Stecker
hat wie mein altes LPC Board auch. Mit ein paar Kabeln ist der auch swd
fähig.
CodeBlocks unter Linux gestern war auch geeignet aber da muss man eben
alles per Hand einstellen, es ist nichts vorgefertigt, da die IDE
generisch ist. Bei EmBlocks und EmIDE wurde da ja schon spezialiert und
man muss vieles nicht machen, der GCC kommt mit, die Debugger sind
eingerichtet, Linkerfiles sind dabei usw.
Christian J. schrieb:>> Wirf mal nen Blick in die "Lernbetty" hier im Forum,>> Neeeeeinnnnnnn! :-)>> Ich frickel mir das mal mit Code::Blocks hin .... versuche es zumindest.
ROTFL
Na ok, dann leide eben aus eigener Kraft.
Es ist schon erstaunlich, was für Leutchen man hier so trifft.
Kommt mir vor wie einer der in der Wüste herumkriecht mit hängender
Zunge kurz vor'm Verdursten und - wenn einer kommt und ihm ne Flasche
Selters geben will - ihn anbrüllt: Neeeeeinnnnnnn! ich trinke nur
stilles Wasser.
Dann mach mal - und wenn du es geschafft hast, kannst du dich als echten
Helden fühlen. Weißt du eigentlich, was du mit den Brettl dann
anstellen willst?
W.S.
