Hallo Leute,
ich möchte gerne auch auf den ARM Zug aufspringen und bin die ganze Zeit
am recherchieren wie!! Momentan schwanke ich zwischen NXP und ST. Dabei
ist mir wichtig. Welche sind weiter verbreitet und besser supportet.
Also zu welchen gibt es mehr Beispiele, bessere Libs und die größere
Comunity? Denn noch die Frage zur IDE. Welche Vorteile bringt eine
kostenpflichtige, wie Keil oder IAR im Gegensatz zu CoCoox? Ich habe
hier und auch sonst schon viel gesucht, aber keine befriedigende Antwort
gefunden.
Also mir sind die TI lieber als ST und NXP.
http://www.ti.com/ww/en/launchpad/stellaris_head.html
mit dem CCS bekommst du von TI auch eine freie IDE
Einzige Beschränkung ist, das du damit nur den Debugger auf dem
Launchpad ansprechen kannst, der sich aber auch zu externen Devices
verbinden lässt.
Willst du andere Debugger verwenden, wird es teuer.
Hol Dir das SAM4S Xplain kit, der Debugger ist auf dem Board drauf und
das Atmel Studio 6 inkl C/C++ Compiler kommt gratis ganz ohne
Einschränkungen.
Farnell müsste die wieder auf Lager haben, oder halt im Atmel Shop für
29USD
Ich nutze den STM32.
Entwicklungsumgebung:
- Eclipse mit CDT Plugin
- Coudesourcery lite (nur Compiler)
- Make-Tools (Yagarto)
- kein Codebeschränkung, volle Kontrolle über makefile
- Dazu noch einen Segger J-LINK EDU mit Segger J-LINK GDB Server (kostet
60, dafür echt schnell) zum Laden/debuggen
Diese Umgebung klappt mit allen Cortex-Mx und ARM Prozessoren. Die
Einrichtung ist zwar nicht ganz "Install and use" wie bei Coocox, dafür
habe ich etwas mehr Freiheit wegen dem makefile.
Für den Anfang jedenfalls reicht Coocox vollkommen aus, der Code kann
jederzeit in eine andere Umgebung portiert werden, ist ja nur ein
anderer Editor.
Helmut Lenzen schrieb:> Ralph schrieb:>> Also mir sind die TI lieber als ST und NXP.>> Wobei TI dir Cortex M3 alle abgekuendigt hat.>> http://www.heise.de/hardware-hacks/meldung/TI-streicht-M3-Stellaris-1773693.html
Ok, so etwas geht natürlich gar nicht.
Da ist man dann doch froh, auf ST gesetzt zu haben.
Laut Vertrieb soll es da dieses Jahr übrigens zumindest den F4 mit 2MB
geben. Würde mir sehr entgegenkommen bzgl. der grafischen Oberfläche -
das nimmt ja doch ordentlich Platz :-)
Chris D.
Von den F4 gibt es allerdings nur sehr wenige Exemplare bisher und Typen
mit Ethernet auf dem Chip schon gar nicht. Ob sich TI damit einen
Gefallen tut die alle abzukuendigen noch bevor die F4 da einspringen
koennten.
Hi also ich habe jetzt auch mit ARM angefangen. Habe mir bei eBay ein
Board bestellt, welches sich Landtiger nennt. Hab jetzt ein paar Tage
damit rumgespielt und die Beispiele, die dabei sind ausprobiert und ein
wenig selbst was gebastelt. Das Teil hat echt alles was man für den
Anfang braucht und der Preis ist echt unschlagbar. Allerdings sind
einige Beispiele fehlerhaft. Zum Beispiel funktionieren die Ethernet
Beispiele nicht Google spukt mir leider bisher nur chinesische Seiten
aus. Bringt mir leider nichts. Ich kann es trotzdem empfehlen. Die
Beispiele sind mit Keil gemacht. Die IDE ist nicht so mein Geschmack
aber das ganze funktioniert echt unkompliziert und schnell.
Hier sind ein paar Links dazu:
http://mbed.org/users/wim/notebook/landtiger-baseboard/ Da findet man
auch einen Link mit einem Video. Bei dem Video sind auch die Beispiele
verlinkt. Auf meinem Link hab ich noch eine Verlinkung zu vermeindlich
funktionieren Ethernet Code. Da ich das aber noch nicht getestet habe
lasse ich meine Aussage oben erstmal so stehen.
Ich kann nur nochmal sagen, ich bin damit sehr zufrieden. Hoffe das
hilft dir weiter.
Liebe Grüße
Stefan schrieb:> Hol Dir das SAM4S Xplain kit, der Debugger ist auf dem Board drauf und> das Atmel Studio 6 inkl C/C++ Compiler kommt gratis ganz ohne> Einschränkungen.
Unter Linux geht da aber garnichts, das der Segger mit zusaetzlichen
seriellen Modem (VID/PID 1366:0105) noch nicht unterstuetzt ist. Soll
sich demnaechst aendern...
hmmmm das hatte ich schon erwartet: 5 Antworten 5 Meinungen. Also ums
Geld soll es erstmal nicht gehen. das wichtigste ist der support bzw.
die comunity
Ich würde mir mal ein Stm32F0Discovery holen...
debugger/lochrasterplatine/... alles dabei.
Da hast du genug zu tun dich in die CMSIS, das RefManual und das
Datenblatt einzulesen.
Wenn du damit zurecht kommst, hol dir ein Stm32F4Discovery und du hast
so ziemlich das Performanteste mit dem meisten Speicher was der Markt so
hergibt (Toshiba hat schon mehr speicher, TI taktet etwas höher und hat
teilweise SDRAM interfaces).
TI wie oben angesprochen ist nicht (mehr) zuverlässig.
ATMEL war noch nie zuverlässig
NXP hat mit den mbed was unbrauchbars verbrochen und ist viel zu spät
mit vernünftigen chips angekommen.
EnergyMicro scheinen recht ausgewogen zu sein... hab mit denen aber noch
zu wenig erfahrung... nur mal so gespielt mit dem zeugs, das die netten
herrn vertreter dagelassen haben...
Wie gesagt zum einstieg würde ich einen M0 nehmen (weniger clocks die
man vergessen kann,... einfach übersichtlicher) wenn man sich mit dem
etwas vertraut gemacht hat, das F4Discovery holen und 99.95% aller
hobby-aufgaben sind damit abgedeckt.
für quadcopter-freaks ein F3discovery wegen dem gyro ;P
Toolchain wie oben angesprochen gcc+newlib.. das tut problemlos
aja, von ST gibts recht wenige (dafür verdammt günstige) devboards.
der grund ist dafür der, dass überall der größte chip der familie drauf
ist.
Preis f4-board:ca 12.-, der chip bei digikey:ca9.- einzelpreis!
keil und iar würde mich mir nicht mehr antun... netbeans oder eclipse
lernt man ziemlich schnell lieben (man muss aber 1ne woche oder so
durchhalten und sich auf das vllt. andere denken der ide einlassen)
atollic unter windows ist z.b kommerziell (hat aber auch eine c-only
"freie" version) und seit 3.0 richtig gut.
freie alternativen (linux?) finden sich z.b hier im forum... je nach
geschmack
Als debugger sollte ein stlinkV2 (ist auf jeden fall beim F3, F4 und
F0Discovery drauf) reichen. die sind echt nicht mehr schlecht.. auf den
F1-Devboards war der alte drauf und den hat man eigentlich nur als
ineffizienten heizkörper verwenden können.
Offene-ersatz-firmware für den stlink findet sich auch schon im netz...
das upgrade-tool ist auch defmystifiziert. also eine recht interessante
hacking-plattform... jedes der board hat 2 nutzbare controller!
Die Segger Debugger gehen seit ca 2jahren im täglichen einsatz ganz
passabel... die haben da richtig was dazugelernt.
was libs und beispiele angeht, nehmen sich alle hersteller nicht viel.
die codequalität ist überall gleich schlecht.
beispiele gibts zu allen peripherals, die libs decken eigentlich alles
ab was die chips hergeben.
Alles in allem fürde ich trotzdem zu ST tendieren, da sich immer mehr
"Shields" für die boards im netz finden.
z.B. STM32F4DIS-BB <30.- mit ethernet, serial, micro-sd
naja nachdem eigentlich die unterschiede derart minimal sind, kann man
eigentlich die firma nehmen, bei denen man glaub die "richtigen"
peripherals zu finden.
Ich sprech mich mal für die chips aus der französichen fab aus :)
73
Was haltet ihr denn vom LPC1343 LPCXpresso Board? Hat einen Cortex M3
Chip drauf zum testen und Programmieren und ist man dann fertig mit der
Einarbeitung, kann das Board in der Mitte getrennt werden und fungiert
dann als Programmer/Debugger mit JTAG Schnittstelle.
Wollte auch bald mal ARM's austesen und dachte daran mit dem Board zu
staren.
Siehe:http://www.watterott.com/de/LPC1343-LPCXpresso-Board?x73707=6eb14192ee72747206dcbf11f730e8eb
Peter P. schrieb:> hmmmm das hatte ich schon erwartet: 5 Antworten 5 Meinungen. Also ums> Geld soll es erstmal nicht gehen. das wichtigste ist der support bzw.> die comunity
Dann schau mal hier im Forum: da überwiegt der ST Anteil.
In der Firma setzen wir STM32F10x ein, privat nehme ich LPC17xx.
Hallo,
danke an Hans für die ausführliche Antwort. Ich denke darauf wird es
hinauslaufen. Direkt mit dem F4 einsteigen ist nicht so gut ? Ich hätte
nämlich gerne einen bzw. wenns geht sogar 2 CAN an board.
Mr.T schrieb:> Dann schau mal hier im Forum: da überwiegt der ST Anteil.> In der Firma setzen wir STM32F10x ein, privat nehme ich LPC17xx.
Da würden mich allerdings die Gründe mal interessieren! Einfach damit du
beide kennst oder weil die STM32 dir so auf die Nerven gehen.
Steige am besten mit dem F4 ein. Da hast Du erst mal alles und davon
reichlich. Von 64 Pins bis 144.
Solltest Du dennoch mal ein Projekt machen müssen, bei dem man noch 2
EUR's sparen müsste, dann kannst Du für dieses eine Projekt immer noch
einen F103er nehmen.
Wie schon oben erwähnt, die NXP LPX1xxx und STM32Fxxx unterscheiden sich
eigentlich nur von der Pheripere, was einem lieber ist. Der eine hat das
mehr, der andere das andere.
In meinem aktuellen Projekt brauche ich 2xCAN, 6xUART, IIC, SPI und USB,
daher nehme ich den STM32F417.
F1 und F2 CAN ist nicht ganz so toll. im F4 ist die peripherie
erweitert.
Der M4 hat einfach wesentlich mehr peripherie und damit unterschiedliche
clock-domains und remap-möglichkeiten an den pins. wenn man das nicht
kennt, sind diese prozessoren sicher nicht leicht zu verstehen.
Ich würde mich einfach etwas mit einem M0(+) spielen um mit der
library,... vertraut zu werden.
z.B in einem bestehenden design einfach einen AVR/PIC/... durch einen M0
ersetzen...
die CMSIS (lib für alle cortex controller) hat einfach ihre eigene
logik.
73
Alles klar!! Ich habe mir jetzt einfach mal mehrere STM32 Boards vom F0
bis F4 bestellt und werde wie vorgeschlagen erst ein zwei Beispiele mit
dem F0 machen und mich denn an die F4 wagen. Bleibt noch die Frage zur
IDE offen. Ist CoCoox zu empfelen oder lohnt es sich etwas
kostenpflichtiges zu kaufen?
Hans schrieb:> die CMSIS (lib für alle cortex controller) hat einfach ihre eigene> logik.
Die CMSIS ist im Grossen und ganzen nur eine Standardisierung, wie das
Headerfile (oder Teile davon, nämlich die Registerdefinitionen)
auszusehen haben).
Das wäre:
Peri->Reg = 0x55;
n = Peri->Reg;
Damit wurde dem #define Wildwuchs ein Ende gesetzt.
Weiterhin bietet die CMSIS u.a. in der core_cm<n>.h eine Reihe von
Funktionen, die den Zugriff auf den NVIC abstrahieren. Die
Implementierung ist so vorgenommen, dass sie im Grunde nur den
Registeraccess des NVIC vereinfacht, aber nicht mehr Laufzeit oder
komplizierte Aufrufe benötigt.
Diese Funktionen kann ich jedem empfehlen.
---
Das andere sind die Libraries, die weiterhin von den Vendors mit den
MCUs geliefert werden. Diese benutze ich bestenfalls als
Nachschlagewerk, da mir a) meisst der Code zu gross wird, und ich b)
doch immer irgendein ConfigBit "nachpfuschen" muss :-)
Peter P. schrieb:> Ist CoCoox zu empfelen oder lohnt es sich etwas> kostenpflichtiges zu kaufen?
Du solltest schauen, wie komplex die Bedienung der IDE ist, und wie
schwirig es z.B. ist, Projekte aufzusetzen etc.
Dann ist der Debugger ein sehr wichtiger Punkt. In wie weit kannst du
beim Debuggen sinnvoll in die Peripheral Configs schauen, was ist mit
Watches, Call Stack, Memory?
Breakpoints können sie alle, aber was ist mit Conditional Breakpoints?
Break auf myVar READ, WRITE, auf myVar == 0x55 usw.
Ich persönlich empfehle natürlich die Keil µVision IDE MDK-ARM, die ich
auch für meine privaten Basteleien hernehme :-)
Als Debug Adapter - sofern du einen kaufen musst - kann ich dir für den
reinen Hobbygebrauch (non comercial) den Segger JLink EDU für ca. 50,-
empfehlen. Der läuft mit Keil, IAR, gnu.
Helfender schrieb:> Ein Board hätte vermutlich für den Anfang gereicht :-)> Manche IDE kann nur mit bestimmten Boards benutzt werden...> Welche hast du genau bestellt?
Habe ein F0, ein F1, ein F3 und zwei F4. So komme ich auf >65 Euro und
musste keinen Versand zahlen...
Was bezahlt man denn für Keil ? Ich kann im Internet leider nichts
finden.
JLink ist gut
STLinkV2 ist imho ok... verwende ich in der Firma auch wenn ich schnell
was mit den discoveries ausprobiere... da kann man etwas sparen...
Keil ist schrott genauso wie IAR (der compiler von arm ist gut, vor dem
von iar wird unter der hand gewarnt)
ein F4 hat 1meg flash (die neuen 2meg typen liegen bei mir schon herum)!
Das vollzubekommen braucht 1. zeit und 2. eine IDE die einem beim
entwickeln hilft!
eclipse und netbeans können das. Keil und IAR nicht!
ich persönlich hab ddd und vim lieber wie keil! naja muss jeder
ausprobieren was einem am ehesten zusagt.
die std-peripheral und die cmsis-core-lib brauchen nicht mehr platz wie
wenn du's selber machst... vernünftige IDEs haben die
unused-code-removal-optionen der compiler von haus aus an => es dauert
vllt. länger zum compilieren wenn unnützes zeug dabei ist, im executable
ist es aber nicht drinnen.
einfache beispiel projekte für die dev-boards und extra für alle
peripherien gibts übrigends auf der st-homepage (oder eben beim vendor
seiner wahl).
73
das LPCXpresso mit dem LPC11C24 wäre auch interessant gewesen, wenn es
dir um CAN geht.
Der LPC11C24 hat alles für CAN implementiert. Vom CAN Transceiver bis
zum CANOpen Protokoll.
Gruß Thomas
Helmut Lenzen schrieb:> Von den F4 gibt es allerdings nur sehr wenige Exemplare bisher und Typen> mit Ethernet auf dem Chip schon gar nicht. Ob sich TI damit einen> Gefallen tut die alle abzukuendigen noch bevor die F4 da einspringen> koennten.
Einspringen könnte auch Freescale. U.a. MK60FN1M0VLQ12 120 MHz, M4, 1
MiB Flash, Ethernet, USB HiSpeed, CAN, 4x 16-Bit ADCs + PGA, 2x 12-Bit
DACs...
Afaik bei den üblichen Verdächtigen auf Lager...
Zum M3-Einstieg: SiLabs Sim3U
Die Software und Bibliotheken gefallen mir besser als das was die
anderen Hersteller "mitliefern". Vernüftiges Tool zur
Systemkonfiguration AppBuilder + Eclipse basierte IDE. Dazu einige
Features die es sonst bei keinem Hersteller gibt: USB ohne externen
Quarz/Oszillator, Crossbar, integr. Spannungsregler der für mehr als die
CPU reicht, High-Drive Port 150 mA Source, 300 mA Sink, einstellbare
Strombegrenzung, I-U-Wandler...
http://www.silabs.com/products/mcu/Pages/32-bit-mcu-software.aspx
Günstiges Eval-Board: Class-D ToolStick für knapp 30 € ohne USt.
Hans schrieb:> Keil ist schrott genauso wie IAR (der compiler von arm ist gut, vor dem> von iar wird unter der hand gewarnt)
Kannst du das mal begründen oder ist das nur ein Troll Versuch?
> vor dem von iar wird unter der hand gewarnt
Selten so unqualifizierte Kommentare gehört.
Für deinen Einstieg gibt es als Toolchain zwei sinnvolle Alternativen:
1. Eine Trial Versione einer kommerziellen IDE wie z.B. IAR, Keil oder
Atollic (die Code Size Beschränkung ist für erste Spielereien kein
Problem)
2. Eine komplett freie Toolchain, davon gibt es mittlerweile diverse,
die fast alle auf Eclipse basieren (mit allen seinen Vor- und
Nachteilen, aber das ist eine Diskussion für sich)
Zu Punkt zwei kann ich konkret zwei Sachen empfehlen:
a. emIDE (emIDE.org), eine freie Toolchain (mal nicht Eclipse basiert)
die mit dem GCC und wunderbar mit dem J-Link GDB Server läuft.
b. Reines Eclipse + CDT, also beides von eclipse.org herunter laden und
installieren, ist für den Einstieg aber vielleicht ein bisschen viel
Bastelarbeit
Peter P. schrieb:> ich möchte gerne auch auf den ARM Zug aufspringen und bin die ganze Zeit> am recherchieren wie!! Momentan schwanke ich..
Ja, merkt man.
Die ganze bisherige Diskussion kommt mir vor wie "wer hat die größte
Klappe" oder so.
Deshalb mein Rat: Lege dich garnicht fest. Weder auf eine bestimmte
Marke, noch auf einen bestimmten uC, noch auf eine bestimmte Toolchain.
Probiere stattdessen alles aus, was du kriegen kannst. Schließlich
willst du ja (hoffentlich) nicht auf irgendwas Spezielles quasi zum
Fachidioten getrimmt werden, sondern dir den Überblick verschaffen, so
daß du später mal ne fundierte Meinung haben kannst.
Für den Anfang geht eigentlich fast alles. Falls du kannst, solltest du
demnächst auf die Embedded nach Nürnberg gehen, weil man dort ne Menge
sehen, vergleichen und auch so einiges bekommen kann. Voriges Jahr war
da ein Run auf Boards von Toradex, die altbekannten STM Discoveries
haben sie auch verteilt, usw.. Aber es gibt dort auch gute Sachen, die
nicht so laut im Gerede und trotzdem nett sind, Cortexe M0 von Nuvoton
z.B. mit kleinem Evalboard und Debugger/Brenner mit drauf.
Ach ja, wenn du es für den blutigen Anfang ganz billig haben willst,
dann kauf dir bei Pollin ne Swissbetty. Für 4 Mack kann man nix falsch
machen.
W.S.
Hugo schrieb:> Hans schrieb:>> Keil ist schrott genauso wie IAR (der compiler von arm ist gut, vor dem>> von iar wird unter der hand gewarnt)>> Kannst du das mal begründen oder ist das nur ein Troll Versuch?
Keil-IDE ist aus dem letzten jahrhundert. Punkt!
IAR auch.
ARMCC ist dagegen gut.
>>> vor dem von iar wird unter der hand gewarnt>> Selten so unqualifizierte Kommentare gehört.>
leute die sich mit sourcecode analysen und computergestützen
beiweisführung für die funktionsfähigkeit von code beschäftigen haben
mich gewarnt IAR compiler zu verwenden, weil sich bei der generierung
von code laufend undokumentierterweise etwas ändert. soll heißen, bei
der nächsten patch-version passt nix mehr zusammen, da die annahmen wie
ein compiler optimiert und wie er die sprache interpretiert sich recht
stark ändern kann. Nebenbei ändern sich angeblich auch gerne
irgendwelche intrinsics... habe ich aber beides nicht persönlich
überprüft.
Kollegen aus der automotive branche nehmen ihn wegen anderen gründen
nicht.
am avr ist ihr compiler aber z.b richtig gut. persönlich tests sind bei
mir 3 jahre her.. .müsste mal schaun ob ich da irgendwo noch
size/speed/feature vergleiche finde.
Auf jeden fall ist bei mir das teil hauptsächlich wegen der IDE
rausgefallen. Timing-Constrains habe ich keine => -O0 -g3 ist dauernd an
wie oben gesagt, das ist hier nicht avr-spielen, sondern versuchen das
teil auch irgendwie zu füllen (sonst macht so ein chip nur sinn weil sie
billiger sind wie alles andere =>bei den M0 ist das teilweise so).
für 1Meg Binary brauchst du schon verdammt viel code... (es sei denn du
hast schriften, bilder,... im flash)
viel code => gute ide und das ist weder Keil noch IAR... das
IAR-Eclipse-Teil ist für meine IDE auswahl damals zu spät gekommen.
73
Addendum zu oben:
Hab mir die letzten releasenotes geholt... sind jetzt vorbildlich (mit
public-known-issues-list)! tiefen respekt!
das man z.b. and der eabi-implementierung nicht unwesentlich schraubt
und dabei nur die patch-revision erhöht finde ich dagegen ziemlich
hart...
naja werd mir auf der embedded mal wieder ein kit organisieren damit ich
nicht so trollig klinge.
73
Chris D. schrieb:> Bis 32k Codegröße ist der Keil frei.>> Die Preise darüber möchtest Du nicht wissen ... ;-)>> Chris D.
Hab ich im Netz gesehen und ... ich möchte die auch nicht ;-)
Hans schrieb:> Keil-IDE ist aus dem letzten jahrhundert. Punkt!
Und?
Was heißt das deiner Meinung nach? Etwa, daß man ohne Java und ohne
Dotnet auskommt und das für dich schlecht ist?
Ne originale Stradivari ist noch viel älter. Ähem.. und noch viel
teurer.
Nebenbei bemerkt: Man kommt auch gut ohne jegliche IDE aus. Soll mir
bloß keiner erzählen, daß die IDE notwendig oder gar das Wichtigste sei.
Also, was sollen solche Bemerkungen über die letzten Jahrhunderte?
W.S.
gerade im Automotive Bereich wird IAR verwendet, sehr viel sogar!
Außerdem generiert IAR den besseren Maschinencode als Keil und GCC,
warum sonst wird IAR in sämtlichen Hersteller-Benchmarks oder gar
CoreMark genommen?
interessant übrigens wenn man sich die certifizierten Benchmarks
anschaut, da schneidet Atmel recht gut mit 3.32 Coremark/MHz bei 123MHz
- man sieht auch den Fortschritt von Version zu Version...
Hans schrieb:> Keil-IDE ist aus dem letzten jahrhundert. Punkt!
Linux, Windows, ARM, etc. sind alle aus dem letzen Jahrhundert. Nach
deiner Definition dürfte man nix aus dem letzen Jahrhundert brauchen.
ST hat mit IAR 3.37 Coremarks/Mhz ... wenn man etwas googlet, findet man
heraus, dass sie da dann schon aus dem ram executieren und sich gedanken
machen, welche daten über welchen bus rennen..
übrigends zeigt die kinetis-benchmark reihe vom 2.10.2012 recht schön
was man alles mit nicht optimal konfigurierten system machen kann...
da is der greenhills vor dem iar und beide deutlich vor keil!
also 2.48 : 2.21 : 1.62 !
da ist eindeutig das linkerdescription file beim keil nicht ok und die
cpu wartet auf daten (50% differenz)!
das jahr davor sind IAR und Keil quasi gleich auf (2.20/2.17 am
6.12.2011)
naja benchmarks halt :)
@W.S meine aktuelle codebase will ich nicht mehr mit grep&co durchsuchen
müssen. => fancy-IDE und die produktivität steigt.
ich will nicht unbedingt zum branch wechseln oder oder issue lösen die
ide verlassen müssen.
und vor allem will ich im jahr 2013 mein SCM in die IDE eingebunden
haben.
die strat hat den vorteil, dass damals die geigenbauer einfach mehr
geigen gebaut haben als heute => die heute haben heute (sorry jungs)
weniger erfahrung als im geigen-fließband zeitalter.
dagegen muss ich halten, dass es in der IT seit den lochkarten in die
andere richtung ging!
ob das gut oder schlecht ist, sei jetzt an der stelle dahingestellt.
ich bin übrigends bei dir, wenn du sagst du hast ein makefile lieber als
irgend so ein komisches eclipse-ding wo sich keiner auskennt vor lauter
uuids in den xml-files.
das ist der nachteil wenn man sich auf das fancy zeugs verlässt.
73
> die strat hat den vorteil, dass damals die geigenbauer einfach mehr> geigen gebaut haben als heute => die heute haben heute (sorry jungs)> weniger erfahrung als im geigen-fließband zeitalter.http://science.orf.at/stories/1692648/> ich bin übrigends bei dir, wenn du sagst du hast ein makefile lieber als> irgend so ein komisches eclipse-ding wo sich keiner auskennt vor lauter> uuids in den xml-files.
W.S. benutzt aber keine Makefiles sondern Batchdateien...
Hans schrieb:> Keil-IDE ist aus dem letzten jahrhundert. Punkt!>> IAR auch.
Achso...
> Kollegen aus der automotive branche nehmen ihn wegen anderen gründen nicht.
Aha...ja dann ist ja alles klar. Danke für die
Hintergrundinformationen... ;-).
Aber jetzt mal im Ernst, man muss bei solchen Diskussionen auch immer
zwischen persönlichen Geschmack und technischen Fakten unterscheiden.
Ich kenne genug Leute, die von Eclipse begeistert sind und welche wie
mich, die die ganzen Features wie Code Folding usw. nicht brauchen.
Hier ging es aber darum eine Toolchain zu finden, mit der man einen
einfachen Einstieg bekommt und out of the box loslegen kann und das hat
man halt mit IAR und Keil.
Ganz lustig ist übrigens, das ich viele Kunden habe, die vor etwa 2
Jahren mit Eclipse angefangen haben und mittlerweile doch wieder auf IAR
umsteigen. Das zeigt mir zumindest, das viele Leute die einfach
Bedienung von IAR den vielleicht besseren Editor von Eclipse vorziehen.
Ohje, hier geht es ja heiß her....
Klar ist alles eine Frage des Geschmacks. Da ich bis jetzt nur mit
Visual Studio und AVR Studio gearbeitet habe, habe ich noch keine
Meinung zu Eclipse. Was hat es denn mit der einfacheren Bedienbarkeit
von IAR auf sich ?
Hugo schrieb:> Hier ging es aber darum eine Toolchain zu finden, mit der man einen> einfachen Einstieg bekommt und out of the box loslegen kann und das hat> man halt mit IAR und Keil.
Nein - der OP wollte nur wissen, welche Vorteile eine kostenpflichtige
IDE hat.
> Ganz lustig ist übrigens, das ich viele Kunden habe, die vor etwa 2> Jahren mit Eclipse angefangen haben und mittlerweile doch wieder auf IAR> umsteigen. Das zeigt mir zumindest, das viele Leute die einfach> Bedienung von IAR den vielleicht besseren Editor von Eclipse vorziehen.
Ja, das kann gut sein.
Allerdings haben auch fast alle, die ich kenne und die mit Eclipse zu
tun haben, sich da "irgendwie reingewurschtelt" - kaum einer nimmt sich
die Zeit und liest die Doku in Ruhe durch oder sogar ein gutes Buch zur
Hand.
Man installiert und "guckt mal".
Dementsprechend verloren ist man natürlich in einer IDE, die extrem
angepasst und vielseitig verwendet werden kann. Und dann ist es in der
Tat Essig mit der "einfachen Bedienung".
Ich kann aus eigener Erfahrung mit Eclipse sagen: es lohnt sich, in ein
gutes Buch zu investieren.
@Peter: Auf jeden Fall muss man vor Eclipse auch als Anfänger keine
Angst haben, wenn man gewillt ist, Dokumenation auch zu lesen.
Und Eclipse kann man natürlich nicht nur für C nutzen - es ist angenehm,
eine IDE für alles zu haben :-)
Chris D.
Davis schrieb:> Chris D. schrieb:>> Chris D.>> (myfairtux)>> (Moderator)>> Du bist heute im Löschmodus - oder? Es sollte eine Warnung geben, wenn> du im Dienst bist.
Wenn hier Leute persönlich angegangen werden, finde ich das auch
durchaus berechtigt!
Nachdem, was ich bisher hier gehört habe, werde ich wohl zu einer
Eclipsbasierten Lösung tendieren. Zumal ich auch keine Lust habe ,ich
mit einer IDE anzufreunden und denn zu merken, dass 32 KB für z.B. eine
GUI doch etwas wenig sind. Und 4000 Euro sind für den Privatgebrauch
etwas happig.
Studentenversionen gibt es meines Wissens nach auch nicht von Keil oder
IAR?
> Davis schrieb:>> Chris D. schrieb:>>> Chris D.>>> (myfairtux)>>> (Moderator)>>>> Du bist heute im Löschmodus - oder? Es sollte eine Warnung geben, wenn>> du im Dienst bist.
Nö, ich hab das nicht gelöscht, finde die Löschung aber ok.
Beiträge, die absolut nichts zum Thema beitragen und nur darauf
abzielen, andere schlecht zu machen, haben hier nichts verloren.
Peter P. schrieb:> Wenn hier Leute persönlich angegangen werden, finde ich das auch> durchaus berechtigt!
Sehe ich genauso.
> Nachdem, was ich bisher hier gehört habe, werde ich wohl zu einer> Eclipsbasierten Lösung tendieren. Zumal ich auch keine Lust habe ,ich> mit einer IDE anzufreunden und denn zu merken, dass 32 KB für z.B. eine> GUI doch etwas wenig sind. Und 4000 Euro sind für den Privatgebrauch> etwas happig.> Studentenversionen gibt es meines Wissens nach auch nicht von Keil oder> IAR?
Meines Wissens nach nicht.
Wenn Du ST einsetzen möchtest, findest Du in der Artikelsammlung eine
Kurzanleitung, um Eclipse zusammen mit dem CDT (= Erweiterung für die
Arbeit mit C - Eclipse "weiss" ja von Haus aus erst einmal nicht viel
über C) zu installieren und dann die entsprechende Werkzeugsammlung für
den ARM (gcc-arm usw.) zu installieren.
Wenn Du Schritt für Schritt vorgehst, solltest Du sehr bald die
obligatorische LED zum Blinken bringen können :-)
Chris D.
Peter P. schrieb:> Da würden mich allerdings die Gründe mal interessieren! Einfach damit du> beide kennst oder weil die STM32 dir so auf die Nerven gehen.
Die STM gehen mir keinesfalls auf die Nerven. Die haben ihre Vorteile
(einfach zu programmierender UART, dafür sind Timer und ADC sehr
"einstellungsfreudig" - Timer sind nur 16bit, CAN ist bei den
Akzeptanzfiltern bissl mau). Die LPCs nehme ich privat, um mal den
Horizont ein wenig zu erweitern. Da sind die UARTs (wenn man den FIFO
nutzen will) schwieriger zu programmieren. Leider lehnen sich die
LPC17xx an irgendwelche ARM7 von NXP beim Footprint an. Man hat daher
manchmal zerstückelte Ports. :-(
Dafür sind ADC und Timer einfacher zu programmieren und die CAN
Akzeptanzfilter bieten mehr Möglichkeiten ohne eine komplexe
Programmierung vorauszusetzen.
Ende vom Lied: beide haben Vor- und Nachteile ;) Bist sicher mit beiden
gut bedient.
Hans schrieb:> (der compiler von arm ist gut, vor dem von iar wird unter der hand gewarnt)
Warum?
Setzen wir seit 4 Jahren (seit 5.xx) hier ein. Gut, habe bis dato zwei
Compilerfehler hier gefunden, aber das gibts doch immer. Aber die
Zentrale in München bzw. die Entwickler in Schweden haben immer
weiterhelfen können.Habe da mit GNU deutlich schlechtere Erfahrungen
machen "dürfen". Auch in embOS hat ein Kollege vor zwei Jahren einen Bug
im Scheduling gefunden, der anscheinend bis dato noch nicht gefixt
wurde.
Hallo Zusammen,
Da du dich ja für Eclipse ausgesprochen, sie dir mal dies hier an
http://sourceforge.net/projects/chibios/files/ChibiStudio/
Das ist ein vorkonfiguriertes Eclipse mit dem du vllt einen leichteren
Einstieg hast. Wobei Coocox wahrscheinlich noch pflegeleichter ist.
MfG
Tec
Chris D. schrieb:> Allerdings haben auch fast alle, die ich kenne und die mit Eclipse zu> tun haben, sich da "irgendwie reingewurschtelt" - kaum einer nimmt sich> die Zeit und liest die Doku in Ruhe durch oder sogar ein gutes Buch zur> Hand.> Man installiert und "guckt mal".
FULL Ack!
Zu der Gruppe zähle ich mich wohl auch ;-).
Kannst du da ein gutes Buch empfehlen? Bin bis jetzt gar nicht auf die
Idee gekommen, das es Bücher geben könnte.
Mr.T schrieb:> Auch in embOS hat ein Kollege vor zwei Jahren einen Bug> im Scheduling gefunden, der anscheinend bis dato noch nicht gefixt> wurde.
Naja, nicht gefixt, weil bis dahin wahrscheinlich nicht bekannt. Solchen
Sachen können ja auch sehr CPU/Compiler spezifisch sein. Ich gehe aber
davon aus das dieser dann sofort korrigiert wurde?
Ich finde Fehler können in jedem Produkt passieren, die Frage ist dann
immer eher wie gut ist der Support und wie schnell sind dann Probleme
gelöst.
Für den Einstieg ist eine IDE sicherlich ganz hilfreich. Da kann man
alles mal ausprobieren. Es bringt aber am Ende keinem etwas, wenn die
IDE den ganzen Startupcode und das Linkerscript "versteckt". Irgendwann
kommt der Zeitpunkt dann rächt es sich, wenn man den Wald vor lauter
Bäumen nicht mehr sieht bzw. nicht mehr Herr der Ding ist. Wenn ich das
Programm welches ich schreibe, nicht auch auf der Commandozeile
übersetzten kann und verstehe was da wo passiert fühle ich mich nicht
wohl. Von der IDE brauche ich eigentlich nur den Debugger.
Ich mache mal eine Liste mit den von mir ausprobierten:
CodeRed LPCXpresso:
- war mein Einstieg in die Cortex-Welt
- beschränkung auf 128Kb
- einige der Peripherie Register sind bei der freien Version ausgegraut
und können nicht angezeigt werden
- Beschränkung auf lpc-Link
- Beschränkung auf NXP-Chips
Atollic True Studio:
- 32k Beschränkung
- Beschränkung auf STM32 (als es noch die 128k Version gab)
Für NXP und STM32 unterschiedliche IDEs zu nehmen ist auch nicht das was
man will.
Keil:
- 32k Beschränkung
- sehr guter Debugger auch für gcc-übersetzten Code
sollte man sich bei einen der o.g. für eine Volllizenz entscheiden muss
man bedenken, dass die an den Rechner gedongelt sind, was eine große
Einschränkung ist. Der Preis ist bei allen nicht Hoppykompatibel.
CooCox:
- kostet nix, aber der Debugger ist eclipsmäßig Mist. Ein J-Link wird
extrem ausgebremst, da irgendwie bei jedem Starten des Debuggers der
ganze Kram neu initialisiert wird. Trifft aber auch für die anderen
Eclipse-Lösungen zu. Bei vielen CPUs fehlen die Peripherieregister. Das
macht dann keinen Spass mehr. 2 SimpleCortex - Boards habe ich im
Einsatz mit dem CooEx-Debugger drauf. Das ist aber auch alles andere als
stabil. Inzwischen debugge ich die auch mit dem j-link edu.
CrossWorks:
großes Plus für die Lizenzpolitik. Ich denke 8 mal wenigstens habe ich
die Testlizenz verlängert bevor ich mich zum Kauf der Personal-Lizenz
für 150$ entschieden habe. Diese Lizenz wird zwar auch an den Rechner
oder besser die Mac-Adresse gebunden, die Anzahl der Rechner pro User
ist aber nicht beschränkt. Der Debugger ist für mich der beste im Feld.
Allerding erschlagen einen die vielen Einstellmöglichkeiten am Anfang
schon. Meine Projekte incl. C++ übersetze ich mit den gnu-arm-tool oder
yagarto oder codesourcery lite. Ausser dem Compilerpfad Pfad braucht man
da nichts ändern. Startup und Linkerscripte sind aus Teilen von dem
zusammengebaut was man so bei den verschiedenen IDEs findet und gelernt
hat. Diese Projekte kann man mit Crossworks prima debuggen, wenn man in
den Startupcode die Warteschleife für den Debugger reinbaut. Mit Keil
auch wenn sie reinpassen.
Mit einem makefile hat man auch die übersichtlichere Kontrolle und
Möglichkeit zu entscheiden welche Programmteile optimiert werden oder
nicht. Man kann so einfach nur die paar Deteien die man gerade beim
Wickel hat mit Debuginfos und ohne Optimierung übersetzen den Rest
optimert. Das spart auch einen ganzen Teil Platz im Flash.
Nicht zu vergessen ist die Vorteil den man hat wenn man bei der newlib
bleibt und sich die printf-Geschichten selbst macht. Dann ist man
jegliche Abhängigkeit von einem IDE-Hersteller los und holt sich auch
deren angepassten Libs nicht in den Code.
Jeder muss am Ende aber selbst seinen Weg finden.
Peter P. schrieb:> Zumal ich auch keine Lust habe ,ich> mit einer IDE anzufreunden und denn zu merken, dass 32 KB für z.B. eine> GUI doch etwas wenig sind.
Also bei einer GUI sollte man doch sowieso modular programmieren, also
eine Bibliothek für die Grafik, Bilddaten, GUI-Code, Control-Code. Und
bisher hatte ich auch in dem Bereich noch kein Projekt wo ein Segment >
32 KB sein musste.
> Mr.T schrieb:>> Auch in embOS hat ein Kollege vor zwei Jahren einen Bug>> im Scheduling gefunden, der anscheinend bis dato noch nicht gefixt>> wurde.>> Naja, nicht gefixt, weil bis dahin wahrscheinlich nicht bekannt. Solchen> Sachen können ja auch sehr CPU/Compiler spezifisch sein. Ich gehe aber> davon aus das dieser dann sofort korrigiert wurde?
Nein. Der Bug wurde 2011 gemeldet und ist seitdem nicht gefixt, da er
nach Aussage von Segger ein umfangreiches Redesign im Scheduling nach
sich ziehen würde.
