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.
GCC Make Openocd ST-Discovery F4 - Billiger wirds schwer
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
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
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 ST und NXP werden die zum einen garantiert nicht abkündigen zum zweiten sind diese Firmen auch so groß, dass die nicht von einem größeren geschluckt werden.
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.
Nur, dass wir uns nicht missverstehen: Ich meinte die STM32F4, nicht die von TI ;-)
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
Vorteile NXP: - es gibt DIP-Packages bzw. DIP-Platinen: http://www.nxp.com/products/microcontrollers/cortex_m0/lpc1100_x_l/LPC1114FN28.html http://www.nxp.com/products/microcontrollers/cortex_m0plus/lpc800/LPC810M021FN8.html http://www.embeddedartists.com/products/boards/lpc11u35_qsb.php http://www.embeddedartists.com/products/boards/lpc1343_qsb.php - es gibt M0, M3, M4 in jeder gewünschten Konfiguration, wesentlich mehr als bei STM - es gibt wesentlich mehr verfügbare günstige Evalboards
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
Angehängte Dateien:
-
xpr_lpc1343_350.jpg
43 KB
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.
Also STM32F4 + CoCoox ? sind für den Einstieg ok?
Ja, das STM32F4DISCOVERY für 9..12 Euronen, ist OK.
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 :-)
Ein Board hätte vermutlich für den Anfang gereicht :-) Manche IDE kann nur mit bestimmten Boards benutzt werden... Welche hast du genau bestellt?
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.
Bis 32k Codegröße ist der Keil frei. Die Preise darüber möchtest Du nicht wissen ... ;-) Chris D.
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
Coocox ist recht einfach zu bedienen. Da hat man sehr schnell sein Blinky fertig.
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.
Chris D. schrieb: > Chris D. > (myfairtux) > (Moderator) Du bist heute im Löschmodus - oder? Es sollte eine Warnung geben, wenn du im Dienst bist.
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.
Hans Wilhelm schrieb: > 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! Ich kenne nur http://www.taylorkillian.com/2013/01/retrieving-st-linkv2-firmware-from.html und finde sonst nix. Irgendwelche Links?
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.