Hallo, als Umsteiger ist mir in der Crossworks 1.5 Umgebung doch einiges noch recht neu, obwohl ich seit nahzu 20 Jahren mit 8 Bittern zu tun habe und mit dem 8051 angefangen habe. Habe mir gerade ein Olimex Board mit dem LPC2138 bestellt, dazu einen Parallelport JTAG Adapter. Zunächst mal: Gibt es ein gutes Buch, welches den Einstieg in die Architektur und die Programmierung mittels GNU CC erleichtert? Hat der GNU CC Bibliotheken, die die Hardware abstrahieren? D.h. zB set_timer1(parameter......) um diese Bitsetzerei zu umgehen. Oder gibt es solche anderswo als Object File zum Einbinden in den Linker? Der CCS Compiler für PIC bietet eine Unmenge an HAL Funktionen, um dem User zB das komplizierte Setzen der I2C Register zu ersparen, man muss gar nicht mehr wissen wie der Controlletti intern arbeitet sondern kann gleich auf High Level loslegen und erzielt so schneller ein Ergebnis. Wo finde ich eine Übersichtskarte der LPC21xx ARM Register? Haben die ARM7 Chips eine interne Chipselect Logik, um externe Memory Bausteine ohne Glue Logic anzusteuern, d.h. wenn ich RAM anpappe muss ich dann den Bus decodieren oder kann der ARM7 das selbst? Einen CPLD wollte ich nur ungern einsetzen, weil ich dafür keine Werkzeuge habe und kein VHDL kann. Wie bekommt man ein Linux System auf einem ARM7 zum laufen? Oder geht das nur mit dem ARM9? Sicher, viele Fragen, manche mögen naiv erscheinen aber ich habe das Gefühl ich betrete eine andere Welt..... Gruss, Christian
>Habe mir gerade ein Olimex Board mit dem >LPC2138 bestellt, dazu einen Parallelport JTAG Adapter. Hmmmm, hättest besser mal vor dem Board-Bestellen hier Deine Fragen reingestellt. >Zunächst mal: Gibt es ein gutes Buch, welches den Einstieg in die >Architektur und die Programmierung mittels GNU CC erleichtert? http://www.hitex.co.uk/arm/lpc2000book/ >Hat der GNU CC Bibliotheken, die die Hardware abstrahieren? >D.h. zB set_timer1(parameter......) um diese Bitsetzerei zu umgehen. >Oder gibt es solche anderswo als Object File zum Einbinden in den >Linker? Der CCS Compiler für PIC bietet eine Unmenge an HAL >Funktionen, um dem User zB das komplizierte Setzen der I2C >Register zu ersparen, man muss gar nicht >mehr wissen wie der Controlletti intern arbeitet sondern kann >gleich auf High Level loslegen und erzielt so schneller ein Ergebnis. Auf Compiler-Ebene gibt es sowas natürlich nicht. Keine Ahnung, ob Philips/NXP so was hat (ich glaube eher nicht). Hier wärst Du mit Luminary oder ST besser bedient gewesen, die haben solche Libraries für ihre Controller. Ich nutze beispielsweise den Cortex-M3 von Luminary - im Übrigen hat der M3 nicht so viele Krücken wie der ARM7 - und Luminary hat eine sehr schöne Library für den gcc, die die Peripherie abdeckt. Wenn Du das Board nicht schon hättest, würde ich Dir ein Luminary-Dev-Kit für ca. 40 Euro empfehlen. >Wo finde ich eine Übersichtskarte der LPC21xx ARM Register? Datenblatt? >Haben die ARM7 Chips eine interne Chipselect Logik, um externe Memory >Bausteine ohne Glue Logic anzusteuern, d.h. wenn ich RAM anpappe muss >ich dann den Bus decodieren oder kann der ARM7 das selbst? Einen CPLD >wollte ich nur ungern einsetzen, weil ich dafür keine Werkzeuge habe >und kein VHDL kann. Geht auch ohne, aber der LPC2138 hat kein externes RAM. >Wie bekommt man ein Linux System auf einem ARM7 zum laufen? >Oder geht das nur mit dem ARM9? Linux geht nicht auf jedem ARM7, auch nicht auf jedem ARM9. Linux braucht eine MMU. Allerdings gibt es ucLinux, ein Derivat, welches keine MMU braucht. Das geht auch mit einem ARM7, wenn ausreichend Speicher da ist.
Hallo, danke für Deine Antwort. Habe mir das Manual mal runtergeladen. Ich wollte schon den GCC verwenden, da er quasi Standard ist und sich viele Sourcen darauf beziehen, zB die SD Karten Fileverwaltung. Die Page von Dir habe ich mal durchgeschaut, welches Kit ist denn das genau? Ich finde da die Bezeichnungen des ARM Cores nicht wieder, da Philips wohl seine eigene hat. Naja, vielleicht ist es ja nicht ganz verkehrt auf Bitebene anzufangen, dann versteht man es auch. Muss allerdings zugeben, dass mich die interne Architektur der Peripherie nicht sonderlich interessiert, sondern nur das was sich mit ihr machen lässt. Gruss, Christian
Hallo Christian, das mit Linux braucht einfach einen externen Bus weil Linux ein speicherfressendes Ungeheuer ist. Die Teile mit externem Bus von ARM7 fangen erst bei 100-pin Gehaeusen an, bei den NXP Chips sind es die 144-pin Gehaeuse weil NXP keinen ultra-low-perfomance 16-bit Multiplexed Bus anbietet sondern lediglich non-multiplexed Busse. Wenn Du Dich mit Englisch einigermassen wohlfuehlst, dann ist mit Sicherheit das LPC2000 Yahoo forum eine hochwertige Informationsquelle. Es gibt recht viele Webseiten, die Beispielcode und zusaetzliche Informationen. Nur ein paar: http://www.lpc2000.com http://www.lpctools.com http://www.yagarto.de Diese Seiten linken dann auch zu weiterem Material auf dem WWW Gruss, Robert
Hallo Robert, die engl. Dokumente erschweren es nur unwesentlich, sie sind einfach langsamer zu lesen. Ich habe mir gestern mal die Performance des GCC im vergleich zu keil, Iar etc angeschaut, der GCC ist demnach der "schlechteste" Compiler, fast 10 bis 100 Mal langsamer als der Keil. Nur ist Keil uVision und Realview für Privatleute kaum bezahlbar, die Zeiten wo ich mir Cracks aus dem Netz suchte und mir den Rechner mit darin eingeplanzten Trojanern verseuchte sind lange vorbei. Da diese Firmen kein Interesse an Hobbyisten haben bieten sie auch keine Studentenversionen an. Das Wichtigste dürfte sein, den Programmerstallvorgang bis zu blinkenden LED zu beherrschen, der Rest geht dann recht schnell. Habe mir gestern einen GPS Parser heruntergeladen, eine plattforumunabhängige FAT Verwaltung und dann wird ein GPS Tracker mal das erste grosse Projekt werden. Leider sind die Sourcen auch irgendwie immer mit Linux erstellt worden, die Docs liegen als eps oder tex Files vor und davon verstehe ich noch weniger. Vielleicht finde ich aber auch jemanden aus der Nähe, der den ARM und die Crossworks Oberfläche sehr gut kennt der sich mal einen Tag Zeit nimmt. Wird schon werden, mal warten bis das Kit kommt...... Gruss, Christian
Christian J. wrote: > vergleich zu keil, Iar etc angeschaut, der GCC ist demnach der > "schlechteste" Compiler, fast 10 bis 100 Mal langsamer als der Keil. Sagt wer? Keil? Blödsinn. Sicher lässt sich irgendwo ein Beispiel finden, beispielsweise irgendeine Library-Routine, wo der GCC-Code 10mal langsamer ist, aber sowas geht umgekehrt dann meistens auch.
Hauptsächlicher Nachteil der GCC/ARM Pakete ist die Grösse der Runtime-Lib. Genauer gesagt die newlib. Wenn man die mitmischen lässt, hat man sofort zweistellige KB mit drin, was durchaus auffällt, wenn man bei Winzigprojekten vergleicht, mit recht gut optimierte Libraries anderer Hersteller. Bei grossen Projekten fällt das naturgemäss nicht mehr so stark auf. Nur muss man die newlib nicht verwenden. Ich jedenfalls bin bislang gut darum herum gekommen.
Christian, da ich im embedded Tools Bereich arbeite, ist mir der Wert von professionellen Tools, hier auch of kommerzielle Tools genannt sehr bewusst. Allerdings muss ich sagen, der GNU compiler ist nicht viel schlechter als die anderen, was ein Problem ist, das ist GDB, der Debugger, der scheint mir nur etwas fuer Liebhaber zu sein und solche, die noch nie mit einem komfortablen Tool gearbeitet haben. Dort waere die Abhilfe allerdings Rowley, die bieten eine sher guenstige Version fuer privat an, die haben einen sehr ordentlichen Debugger und zu allem Ueberfluss haben die meines Wissens nach auch eigene, bessere LIBs geschrieben. Hab selbst noch nicht damit gearbeitet, aber in meiner fruehren Abteilung wurde der mal unter die Lupe genommen und da waren doch ein paar Kollegen sehr angetan vom Preis/Leistungsverhaeltnis. Persoenlich arbeite ich am liebsten mit IAR oder Keil aber da haengt eben auch meine persoenliche Geschichte drin und im professionellen Einsatz sind ein paar Tage Zeitverlust hoehere Kosten als der Anschaffungspreis der Tools. Meine Schaetzung, was der Unterschied zwischen GNU code und anderen, professionellen Tools, ist im Bezug auf Groesse, zwischen 0-20%, das ist allerdings ohne die LIB. Kleine Programme mit Verwendung der LIB, da kann das auch schon mal ein ganzzahliger Faktor sein. (Siehe Beitrag a-k) Ach ja, Studentenversionen, falls Dich der parallele Wiggler irgendwann genug geaergert hat, das J-Link gibts mit ca 60% Nachlass fuer Studenten. Kostet dann aehnlich wie die Nachbauten ;-) http://www.segger.com/pr_segger_jlink_student_discount.html Gruss, Robert
Das '10-100' bezieht sich wohl eher auf die Compilierungszeit. Gerade der G++ ist da besonders langsam. Der VisualC++ 6.0 Compiler übersetzt eines unserer Projekte in der Firma fast 20mal schneller. Ich bin da nicht auf dem neuesten Stand aber frühere Benchmarks zeigten eine schlechtere Performance beim erzeugten Code wenn es C++ Quellen waren. Bei reinem C-Code brauchte der GCC sich vor den komerziellen nicht zu verstecken. @Robert Wird Segger vielleicht auch mal eine 'non commercial' Version anbieten? Wie du selber schreibst schafft Rowley das auch. Als Privatmann aber nicht-Student ist mir das Interface + Software zu teuer (~450€ ?).
> Als Privatmann aber nicht-Student ist mir das Interface + Software > zu teuer (~450€ ?). O nein, nicht so teuer, wenn Du Rowley Crossworks meinen solltest. Als Debug-Interface eignet sich auch das FT2232-basierende OpenOCD-USB-Interface, das weniger als 100 EUR kostet. Das wird von Crossworks 1.7 (aktuelle Version) unterstützt.
Nein, ich meinte den J-Link den es nur für Studenten so günstig gibt. Vielleicht erkennt Segger ja das auch Privatleute beruflich mit ARM Controllern zu tun haben können. Nur das eine Anschaffung eines solchen Adapters derzeit in der Firma (noch) nicht ansteht.
@let wie laestig wuerdest Du denn auf dem Bildschirm eine "not for commercial use" Meldung finden? Bei einer Software wird die Lizenz einem Benutzer zugeteilt, der muss sie freischalten lassen und sich registrieren. Bei Hardware ist einfach viel weniger Kontrolle moeglich und das macht die Sache weniger attraktiv fuer uns. Werde das mal mit dem Chef besprechen und wenn was gutes dabei rauskommt also eine "personal license" werde ich das hier ganz bestimmt auch kundtun (and dafuer dann Schimpfe bekommen aber das ist OK). Gruss, Robert
let wrote:
> Das '10-100' bezieht sich wohl eher auf die Compilierungszeit.
Was die üblichen Microcontroller-Projekte unterhalb der Linux-Ebene
angeht, ist mir die Compilezeit relativ schnuppe. Kommt nicht oft vor,
dass ich ein 20MB-Binary für LPC2000er baue.
Aber auch auf PCs ist mir der Unterschied bislang nicht wirklich
unangenehm aufgefallen.
@Robert: So ein Text würde mich nicht stören. Ich fürchte aber das ein kommerzieller Nutzer das auch tolerieren würde. An sich scheinen diese Erklärungen für eine ausschließlich nicht- kommerzielle Nutzung die unterschrieben an den Hersteller geschickt werden müssen, zu funktionieren. Neben Rowley macht das auch Cadsoft mit seinem Layoutprogramm Eagle. Was wollt ihr an der Hardware denn kontrollieren? Ich meine wer setzt den J-Link ohne eure Software ein? Und vielleicht läßt da an der Firmware was machen, sodaß der Adapter nur mit der registrierten Segger Software läuft. @Andreas: Bei µC Projekten ist die Compilezeit sicherlich kein entscheidener Faktor. Aber wenn du sagst dir sei bei PCs kein großer Unterschied aufgefallen, hast du noch nie KDE übersetzt? Das dauert Stunden.
Hallo, da Segger bei mir in der Stadt ist (Hilden) habe ich die mal eben angerufen. Leider nur für Studenten (ist bei mir 15 Jahre her). So, jedenfalls habe ich jetzt Crossworks 1.5 auf dem Rechner und werde mal versuchen einen billigen Wiggler zu bekommen, wirds schon tun für den Anfang. Aufrüsten kann man ja immer noch.
Den Wiggler kann man sich auch selber bauen, ansonsten verkauft Andreas den hier auch in seinem Shop - oh, Moment, den hatte er mal verkauft. Mit Rowley Crossworks funktioniert der Wiggler vorzüglich, sofern man denn noch einen Rechner mit echter Parallelschnittstelle hat. Eindeutig zu bevorzugen aber ist der USB JTAG Tiny, ein FT2232-basierender USB-Adapter, den Andreas für etwa 45 EUR anbietet: http://shop.mikrocontroller.net/csc_article_details.php?nPos=0&saArticle[ID]=87&VID=JZGfmAzlCMj7Ng8R&saSearch[word]=&saSearch[category]=ARM&saSearch[special]= Der kann auch mit Rowley Crossworks verwendet werden, allerdings erst ab Version 1.7
@Christian, @let und alle anderen, die an J-Link interessiert sind. Wie versprochen hab ich mit Hr. Segger gesprochen und das Anliegen wurde sehr positiv aufgenommen. Es folgt noch ein offizielles Press Release und die Message auf unserer Webseite wird auch noch etwas dauern aber soviel sei jetzt schon gesagt, ab sofort gibt es J-Link non-commercial. Der Kaeufer verpflichtet sich das J-Link nicht zur Entwicklung eines kommerziellen Produktes einzusetzen und das ist es dann. Die Sache kostet wie die Studenten Version 98 Euro Doch das ist noch nicht alles. Hinzu kommt, dass so ein J-Link die GDB server Lizenz sowie Flash download mit auf den Weg bekommt. Damit sind SEHR schnelle downloads ins Flash der gaengigen Flash ARM-microcontroller (Atmel, STM und NXP) moeglich. Yagarto kann also voll eingesetzt werden. Anfragen bitte an info@segger.com Gruss, Robert
Na das hat aber gedauert. Was habt ihr denn die ganzen zwei Tage gemacht ? ;) Dann will ich mich mal erkundigen was da zu tun ist. Einen Debugger brauche ich zwar so selten wie einen LA aber wenn dann muß das einfach ohne Gefrickel funktionieren.
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.