Moin! Bisher habe ich AVRs mit dem STK500 per C-Compiler programmiert. Ich möchte mich breiter aufstellen und mir ein ARM basierendes Starter-Kit zulegen. Welches, weiß ich noch nicht. Programmieren werde ich wohl C, C++. Ich erhoffe mir dadurch, bessere Chancen bei der Jobsuche zu haben. Nur ATMEL ist vielleicht bissl wenig auf die Dauer. Die Anforderungen sind ja oft hoch gesteckt... Wie kann ich mir die Übungen und Projekte am Anfang vorstellen, bei denen ich auf die Pereferie des Controllers, des Boards zugreife? Beispiel TCP-IP-Schnittstelle> Kann ich da schon Klassen, Methoden finden, die ich nur noch nutzen brauch, um eine Verbindung zu einem z.B. Server zu programmieren und um Daten zu transferieren oder muss ich alles von Gund auf neu und "zu Fuß" programmieren? Muss ich mir das Vorstellen wie die Programmierung eines UARTs beim ATMEL-AVR? Evtl hängt das von Starter-Kit zu Starter-Kit ab?! Ich hab da noch keine Erfahrungen und Vorstellungen, auf welcher Ebene ich aufsetze und wie weit die Software-Schnittstellen schon vorhanden sind. Vielleicht kann man das garnicht pauschalisieren... Ich habe nur oft gelesen, dass schon bei einigen Boards sogar ein kleines Betriebsystem läuft. (Zusatz: VHDL-> FPGA-> wie ist das da? Hat man da bereits eine Bibliothek von funktionalen Einheiten?) Danke für die Antworten!
Generell kann man schon Vergleiche zwischen AVR und ARM ziehen, wobei der ARM oft mehr Peripherie an Bord hat und demzufolge auch viel mehr Konfigurationsregister dafür. Das Prinzip bleibt, aber es wird komplexer. Ich habe gehört, daß unter den ARM7-basierten Chips die LPC2000-Reihe von NXP etwas einfacher für den Einstieg ist als die AT91SAM von Atmel. Fans mögen mir widersprechen. Dann gibt es noch die ARM9 mit externem Speicher, auf denen Linux läuft. Mit einem Betriebssystem programmiert es sich natürlich ganz anders als auf nackter Hardware. Nicht jeder ARM hat Ethernet, nur die großen, z.B. LPC2378. Dazu ist i.A. ein zusätzlicher Physical Layer Chip ("PHY") und ein Ethernetübetrager (jedoch in sog. MagJack-Buchsen schon integriert) nötig. Der Mikrocontroller beherrscht jedoch das TCP/IP Protokoll nicht nativ. Vielmehr muß ein TCP/IP-Stack als Softwarebobliothek benutzt werden (siehe uIP / lwIP), wenn man nicht alles selbst programmieren will. Oder man benutzt einen Wiznet-Chip, der beherrscht das Protokoll von sich aus. FPGA ist ein ganz anderes Thema. Fertigen Code zum Einfügen gibt es auch, aber man muß schon verstehen, was man tut. Die programmierbare Logik ist nicht sequentiell wie ein uC, sondern arbeitet meist parallel, und erfordert ein recht tiefes Verständnis von dem, was da wirklich im Chip passiert.
Ergänzung: Für kleinere ARM7 gibt es die Möglichkeit, ein sogenanntes RTOS zu verwenden, ein Betriebssystem, das zusammen mit der Anwendung kompiliert wird. Die Möglichkeiten sind natürlich eingeschränkter als bei echtem embedded Linux oder ähnlichem, aber man hat z.B. die Möglichkeit, Threads parallel laufen zu lassen; oftmals werden auch solche Dinge wie die Ethernetkommunikation unterstützt. Allerdings kann die Einarbeitung in ein RTOS auch viel Zeit kosten, es empfiehlt sich, die Dokumentation sorgfältig zu lesen, bevor man sich für eines entscheidet. Auswahl gibt es da viel, von kostenlos bis ganz teuer, von eher primitiv bis ziemlich anspruchsvoll.
@Tovaritsch: Habe momentan mit LPC2148 und in der Firma mit Cortex-M3 (STM32F10x) zu tun. Prinzipiell halte ich den Cortex für die Zukunft. Schau doch mal hier (http://www.tnkernel.com). Da gibt es ein RTOS mit TCP/IP Stack für verschiedene Cortex-M3/ARM7. Versuche das auf einem Board Deiner Wahl zum Laufen zu bringen. Ein professionelles JTAG Interface für ARM7/Cortex-M3 gibt es bei Segger für ~62,-€ für Privatanwender.
Tovaritsch schrieb: > Wie kann ich mir die Übungen und Projekte am Anfang vorstellen, bei > denen ich auf die Pereferie des Controllers, des Boards zugreife? > > Beispiel TCP-IP-Schnittstelle> > Kann ich da schon Klassen, Methoden finden, die ich nur noch nutzen > brauch, um eine Verbindung zu einem z.B. Server zu programmieren und um > Daten zu transferieren oder muss ich alles von Gund auf neu und "zu Fuß" > programmieren? Muss ich mir das Vorstellen wie die Programmierung eines > UARTs beim ATMEL-AVR? Na ja, Ethernet MAC und UART haben zwar gemeinsam, dass beides serielle Schnittstellen sind, doch TCP/IP Protokoll, also die Software, die aus einer Schnittstelle einen Teilnehmer am Internet macht ist doch schon etwas komplexer als ein UART Treiber. D.h. es geht grundsaetzlich was auch auf dem AVR geht, also UART = UART doch es geht noch einiges mehr. > Evtl hängt das von Starter-Kit zu Starter-Kit ab?! Stimmt! Es haengt allerdings mehr von der mitgelieferten Software ab. > Ich hab da noch keine Erfahrungen und Vorstellungen, auf welcher Ebene > ich aufsetze und wie weit die Software-Schnittstellen schon vorhanden > sind. Vielleicht kann man das garnicht pauschalisieren... > Ich habe nur oft gelesen, dass schon bei einigen Boards sogar ein > kleines Betriebsystem läuft. Beim groessten Luminary ist sogar schon ein Betriebssystem im Chip bei Auslieferung integriert. Siehe: http://mcu-related.com/architectures/35-cortex-m3/63-luminary-stellaris-lm3s9b96-rtos Fuer einen professionellen TCP/IP stack muss man immer noch eine Stange hinlegen. Ausser man geht in die Ueberwelt (aus MCU-Sicht) von Linux. Dann ist's aber nix mehr mit single-chip und alles aus dem integrierten Flash laufen lassen und die Performance von einem 50 MHz Cortex-M3 kann nur noch mit viel Muehe auf einem 200 MHz++ auf einem ARM9 erreicht werden. Moeglichkeiten anzufangen waeren z.B. mbed von ARM/NXP http://mcu-related.com/architectures/35-cortex-m3/86-mbed Primer2 von Raisonance / ST http://mcu-related.com/architectures/35-cortex-m3/59-stm32-primer2-stm32f103e-stm3210e-primer Viele echte aber natuerlich mehr spezifische Referenzloesungen von TI/Stellaris http://focus.ti.com/mcu/docs/mculuminarykitsapps.tsp?sectionId=95&tabId=2488&familyId=1755 Es gibt viel zu erkunden, fang schon mal an. Auch ich wuerde mehr die Cortex-M3 basierenden Teile empfehlen als die ARM7 Gruss, Robert
Hallo allerseits, sorry dass ich mich hier einmische, aber ich hätte da gleich eine Frage zu, an Robert Teufel. Und zwar geht es um dies: > Auch ich wuerde mehr die >Cortex-M3 basierenden Teile empfehlen als die ARM7 Warum das denn? Ist ARM7 veraltet, oder wie? Gibt es eine modernere, bessere ARM-Architektur als den ARM7, (abgesehen vom CM3) die ebenso "einfach" ist? Was mich nämlich an den CM3ern stört, ist, dass keiner einen externen Bus hat. Ich habe jedenfalls noch keinen gesehen. Manchmal aber reichen die internen paar k FLASH nicht aus, oder man möchte etwas mehr RAM, weil man eine grosse Datenstruktur bearbeiten will. Da ist man mit einem LPC2k-Derivat mit externem Bus doch besser beraten, da man da recht simpel einfach ein paar SRAMs dran pappen kann. Warum kann man das beim Cortex M3 nicht? Das ist ein echtes Manko, finde ich.
Tobias Plüss schrieb: > Warum das denn? Ist ARM7 veraltet, oder wie? Die klassische ARM Architektur war nie besondes gut für typische µC Anwendungen geeignet. Sie wurde ursprünglich auch nicht dafür entwickelt. > Gibt es eine modernere, bessere ARM-Architektur als den ARM7, (abgesehen > vom CM3) die ebenso "einfach" ist? Nein. > Was mich nämlich an den CM3ern stört, ist, dass keiner einen externen Bus > hat. Ich habe jedenfalls noch keinen gesehen. Mehr suchen. Es gibt durchaus welche, z.B. bei ST und Atmel. -- Marcus
Genau, z.B. Analog Devices: ADuC7xxx und ADuC8xxx. Die haben unter anderem auch noch AD/DA-Komponenten drin, die andere ARM-Controller so nicht haben. Und sind einfach über die serielle Schnittstelle (auch mit RS232-to-USB-Wandler) zu programmieren. Gibt es nur nicht so häufig und werden auch nicht so aggressiv in diesem Forum beworben wie die LPCs. Blackbird
Blackbird wrote: >Die haben unter anderem auch noch AD/DA-Komponenten drin, die andere >ARM-Controller so nicht haben. STM32 hat sogar 2 bis 3 unabhängige 12bit AD-Wandler und noch 12bit DA-Wandler dazu. >Und sind einfach über die serielle Schnittstelle (auch mit >RS232-to-USB-Wandler) zu programmieren. STM32 kann dass auch.
Tobias Plüss schrieb: >> Auch ich wuerde mehr die >>Cortex-M3 basierenden Teile empfehlen als die ARM7 > > Warum das denn? Ist ARM7 veraltet, oder wie? > Gibt es eine modernere, bessere ARM-Architektur als den ARM7, (abgesehen > vom CM3) die ebenso "einfach" ist? Was mich nämlich an den CM3ern stört, > ist, dass keiner einen externen Bus hat. Ich habe jedenfalls noch keinen > gesehen. Hi Tobias, wie andere schon beantwortet haben, es gibt sie, die CM3 mit ext. Bus, ich bin ueberzeugt auch bald von NXP aber die anderen haben das schon. Warum nicht mehr ARM7? Das gilt fuer Neuentwicklungen. Die ganzen Firmen wie ST, Atmel, NXP und TI investieren nur noch in neue Peripherie und Cores, die auf dem Cortex-M basierend sind. Siehe auch Cortex-M4 Ankuendigung von heute: http://mcu-related.com/ Also wer sich heute mit bestehendem Code auf einem ARM7, z.B. von einem LPC2148 auf einen LPC2378 oder so beschaeftigt, der sollte das auch wirklich tun und vielleicht nochmals fuer 1-2 Generationen mit dem ARM7 arbeiten, der ist beileibe nicht schlecht! Wer aber mehr zukunftsorientiert arbeiten moechte oder gerade ein voellig neues Projekt anfaengt, der sollte sich auf dem CM3 stuerzen, denn dort geht die Post ab. Wie Markus bereits gesagt hat, der CM3 wurde neu als MCU entwickelt, der ARM7 war als Prozessor fuer Handies gemacht und wurde spaeter "zweckentfremdet" als eigenstaendige MCU. Gruss, Robert
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.