Hallo, ich komme aus der 8051 Welt und möchte umsteigen auf eine Controller-Familie mit mehr Performance und Peripherie an Bord (AD-, DA-Wandler, 20-60 IO's, Grafikcontroller, evt. USB und Ethernet). Die Entwicklungs-Tools sollten ein RT-Kernel, Debugging über JTAG, C und C++, Projekt-Verwaltung usw. mitbringen. Zielgebiet sind Anwendungen im Industrie- und Automotivbereich, deshalb kommen nur Professionelle Werkzeuge in Frage. Würde mich sehr freuen wenn Ihr mir eure Erfahrungen mit unterschiedlichen Entwicklungs-Tools GNU oder Professionellen Werkzeuge mitteilen könntet. Wo sind evt. die grenzen bei den günstigen Werkzeugen? Welcher Controller ist der richtige (AVR, ARM, usw.)? Gruß Rainer
Hallo, es gibt keine "richtigen", da es mittlerweile eine unüberschaubare Anzahl gibt, die letztlich immer das Gleiche tut: Rechnen und steuern. Man kann nur noch nach der Verbreitung gehen, wo man am meisten fertige Sachen für bekommt und was kompatibel ist. Automotive bevorzugt Motorola, bei uns waren die per Vertrag auch vorgeschrieben. Eine gute Wahl ist sicherlich immer der 32 bit ARM, da darauf zB Linux läuft und man das Rad nicht immer neu erfinden muss. Wenn Geld keine Rolle spielt gibt es auch sehr leistungsfähige Rechner von MIPS (Power PC) oder NEC, zB die V850 Serie. Billig heisst auch immer dasss es keinen Support gibt und man mit seinen Problemen allein da steht. Mein Rat: Bei einem Distributor beraten lassen und dann auch bei dem bleiben.
die eierlegende Wollmilchsau wirst du nicht finden weil es keine gibt. Wenn du einen Leistungsfähigen µC suchst, bist du sicher an der ARM-Architektur (oder AVR32) intressiert. >Zielgebiet sind Anwendungen im Industrie- und Automotivbereich, deshalb >kommen nur Professionelle Werkzeuge in Frage. Definiere Professionelle Werkzeuge Falls du damit proprietäre Entwicklungsumgebungen namenhafter Firmen meinst würde ich dir in jedem fall abraten, der Code wird unportabel, die Transparenz wird kleiner und vorallem macht man sich abhängig von den Firmen und wird wieder zum Spielball der "Großen" Firmen. Letzten Endes zahlt man immer drauf. zu den "GNU Tools" kann ich dir nur sagen, dass du um eine "längere" Einarbeitungszeit nicht drumrum kommst, und wenn du nicht grade dein RT-OS selber schreiben willst, musst du auf eventuelle kommerzielle Systeme oder die freien Alternativen (meist GPL oder BSD lizensiert) z.B. RTOS, µlinux o.ä. zurückgreifen. Auch hier wirst du Zeit brauchen um sich in diese Projekte einzuarbeiten. Große Aufmerksamkeit sei hier auf die Lizenzen gelegt. Wenn du fremden Code benutzt hast du dich an die Lizenz zu halten (viele Routerhersteller kennen diese Problematik ). der Vorteil dabei ist, dass du den Code meist modifizieren kannst (sofern du kannst) und an deine Ansprüche anpassen. Auserdem bleibt der Code in großen Teilen Portierbar. das bedeutet dass wenn dein Projekt unerwartet Größer wird als du es vorgesehen hast kannst mit viel weniger "Schmerzen" eine leistungsfähigere Architektur wählen und dein Projekt auf dieser fortsetzen. zusammengefasst: Proprietär: Vorteile: meist weniger Einarbeitungszeit Garantieen vom Hersteller Nachteile: Abhängigkeit vom Hersteller meist proprietärer Code schlechte Portierbarkeit Lizenzen GNU Tool: Vorteile: viele schon vorhandene Projekte/Bibliotheken Flexibilität/Volle Kontrolle über Code und Hardware Kostenlos (wenige Ausnahmen) Portierbarkeit Nachteile: keine Garantien große Einarbeitungszeit (einmaliger Aufwand) die Verantwortung liegt mehr als sonst bei dir (du kannst nicht sagen die Tools von Hersteller XY sind schuld) Lizenzen
Zu einer professionellen Anwendung gehört eine professionelle Toolchain. Gerade bei Automotive, wo die Stückzahlen sehr gross sind bricht dir ein Bug in der Freeware Toolchain das Genick. Für die GNU-Tools ist rechtlich keiner verantwortlich und der Schaden bleibt an dir hängen. Bei lizensierten Tools sind im Fehlerfall immer die Hersteller mit im Boot, und die haben ihre Gewährleistungen abgesichert. Das GNU-Zeug taugt eigentlich nur zu Hobby- und Bastelzwecken. Bj
Auf 8051 Basis habe ich immer mit den Keil Entwicklungs-Tools gearbeitet und kenne auch kaum die Vor- und Nachteile von anderen Herstellern. Ich frage mich, wenn ich auf ARM umsteige sind die Keil-Tools die bessere wahl für mich oder nicht? Ich habe gehört das ARM Keil gekauft hat. Spricht das nicht für die Keil-Tools? Da ich nicht den Vergleich zu anderen Herstellern bzw. GNU-Produkten habe, würde ich gern aus den Erfahrung von Dir und anderen profitieren. Gruß Rainer
Also ich steige nun ebenfalls vom guten alten 51er um zu cortex m3. Das ist quasi der neue ARM für den embedded Bereich. Genauso wie der 51er, hat der so viel im kleinen Gehäuse. Der Preis, der neue Thumb2 Befehlssatz, Geschwindigkeit,... ist ein Traum und bei Keil kann ich auch bleiben. Ein Beispiel : STM32F103RB - TQFP 64 10x10x1.4 - FLASH 128KB - SRAM 20KB - A/D 16x12-bit 4x16-bit (16/16/18) - 2xWDG, RTC, 24-bit down counter - 2xSPI - 2xI²C - 3xUSART(IrDa/ISO7816) - USB - CAN Mit dem Chip-Remapping kann man alles gleichzeitig nutzen. Und das um ca. 5.- OLIMEX hat ein super board um 45.- Ich freu mich schon :-) ciao, Philipp
@Rainer "Welcher Controller ist der richtige (AVR, ARM, usw.)?" Von den beiden fuer die beschriebene Anwendung, ARM! Der AVR 8-bit kann locker mit schnelleren 8051 (Silabs) erschlagen werden, der AVR32 ist eine interessante Architektur deren Fokus derzeit allerdings klar in Richtung Unterhaltungselektronik geht, siehe Peripherals und Press Releases. Fuer den industriellen Bereich koennte die Auswahl sehr weit sein, neben den genannte Architekturen wuerde ich noch Coldfire und Renesas H8 / SH2 dazunehmen, die Auswahl ist gross. Die Vorteile bei ARM sind mindestens: 1. Viele Anbieter -> Preiskampf, insgesamt sehr gute Verfuegbarkeit 2. Die Auswahl an Tools ist ohne gleichen. Tools: Der GNU compiler ist sehr ordentlich, der standard GDB Debugger allerdings substandard. Wenn Du bisher mit Keil gluecklich warst, dabei bleiben. Sofortiger, direkter Zugriff zu den neuesten Informationen von ARM firmenintern sind sicher ein Plus, Keil hat auf dem 8051 meiner Meinung nach ein Top-Produkt generiert und die ARM Umgebung steht dem in nichts nach. Echte Alternativen sind sich IAR ( www.iar.com ) und evtl. auch Rowley (www.rowley.co.uk) , basierend auf GNU aber eigene, bessere Libraries und guter Debugger. Emulatoren: Da bin ich parteiisch sage aber trotzdem, dass ein Segger J-Link die beste Option ist, weil sie mit allen anderen o.g. Tools auch arbeitet und die Debugger Oberflaeche der IDE erhalten bleibt. www.segger.com/jlink.html Solltest Du bei den 8051-Bausteinen solche mit Bond-Out Emulatoren benuetzt haben, das gibts bei ARM in derselben Form nicht aber ein sehr gutes Debugging Interface nennt sich ETM (Embedded Trace Macrocell). Wird nur von einem Teil der ARM Hersteller angeboten, weil es sowohl Chipflaeche als auch Pins kostet, wenns denn benuetzt wird. Ansonsten Standard JTAG ist oft OK, ARM7 bietet aber nur 2 Hardware Breakpoints und solche braucht man um im Flash zu debuggen. Auch da gibts von Segger eine patentierte Erweiterung zu Breakpoints im Flash. Als privater Benutzer wuerde ich inzwischen vermutlich auch GNU Tools nehmen, z.B. die Umsetzung in www.yagarto.de ist sehr interessant aber beruflich ist mir die Support Hotline einfach zuviel wert um darauf zu verzichten. Robert
@Robert: >...der AVR32 ist eine interessante Architektur deren Fokus derzeit >allerdings klar in Richtung Unterhaltungselektronik geht, siehe >Peripherals und Press Releases. Bezieht sich diese Aussage auch auf die AT32UC3...? Deren Datenblätter habe ich vor einigen Tagen entdeckt und fand das Recht Interessant. Bei der integrierten Peripherie sehe ich bei diesen Typen allerdings nicht wo da der Schwerpunkt Unterhaltungselektronik ist. Aus meiner Sicht sind das eher in jeder Hinsicht aufgebohrte ATMega's mit einem guten Mix aus der üblichen Controller-Peripherie. Jens
@Jens, die Richtung einer Architektur erkennt man vor allem daran, wie sie im Markt eingefuehrt wurde. Da war von Konvertierungen aus dem Consumer Bereich die Rede, die der AVR32 schneller kann als ein ARM9... Daraus einen "normalen" uC zu machen wird typischerweisse im Manual zuerst, nicht unbedingt in der Hardware des Controllers gemacht. Das geht so: Ich nehme mir einen spezialisierten micro, streiche die Kapitel, die zu spezifisch sind, zeichne ein neues Blockdiagram und ein neues Pinout und viola, ich haben einen general purpose microcontroller. Der AT32UC3.. erschint mir als solcher, duerfte allerdings bald ein Eigenleben bekommen und mit neuen Derivaten den Markt beackern. Ich bitte darum den anderen Teil des Satzes auch zu beachten, ich halte den AVR32 fuer eine sehr interessante Architektur mit Vorteilen (und natuerlich auch Nachteilen) gegenuer den verschiedenen ARMs. In diesen Bereich gehoert natuerlich auch der neue PIC32 von Microchip, interessant mit Vor- und Nachteilen. Basierend auf den verfuegbaren Angeboten am Markt heisst mein Favorit allerdings eindeutig ARM7 (noch) nicht Cortex, denn der ist auch erst von 2 Anbietern da. Robert
Hallo Robert, hast Du vielleicht Erfahrung mit Keil- oder GNU-Tools oder was wäre deine Empfehlung? Gruß Rainer
Philipp wrote: > STM32F103RB > - A/D 16x12-bit 4x16-bit (16/16/18) Ich sehe da nur 2x12-bit, 16 Kanäle.
Automotive kennt eine einfache Antwort: PowerPC Dazu gehört ein ziemlich gutes Entwicklungssystem, nämlich der Code Warrior. Dahinter können sich die meisten anderen Entwicklungsumgebungen verstecken. Einfach mal bei Freescale vorbeischauen.
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.