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
