mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik NewBee - Umstieg von Atmega64 auf ARM Cortex M3 mit GCC?


Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

aktuell arbeite ich auf mit dem STK500 auf einem Atmega64.
(ganz normal über make.exe über MakeFiles)

Gerne würde ich mehr ADC Power haben, da bin ich auf den
CortexM3 gestoßen,

Super günstig, extrem schnell
http://search.digikey.com/scripts/DkSearch/dksus.d...
4,40 EUR ???

Das ganze macht natürlich nur Sinn wenn ich nicht extra
eine Compiler für X tausend Euro brauche.

Kann mir jemand sagen wie groß da der Umstieg ist?

Ich hab jetzt schon diese Homepage gefunden
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm...
So ganz blicke ich da aber nicht durch (GNU-toolchain, OpenOCD von Keil 
etc.)
und hat mich etwas verunsichert.

Einfach nur
MCU = atmega64

durch
MCU = cortexM3

zu ersetzen und die Ports Anzupassen klappt wohl nicht, oder?
(Es geht nur um die Software, nicht um die Hardware)

Ich hab leider auch keine spezielle Liste gefunden was GCC nativ
unterstützt.

Kann man das wagen?

Vielen Dank & Viele Grüße
Bernd

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe (fast) denselben Umstieg hinter mir.
Allerdings den Luminary LM3S1968.

Ich fand es sehr einfach. Ich nutze allerdings kein JTAG-Debugging, 
sondern nur "simples" RS232 oder Display-Debugging.

Der GCC unterstützt den M3. Auch ein Linkerskript ist schnell erstellt.
Ich jedenfalls hatte nach nicht mal einem Tag das FreeRTOS mit der 
Luminary-Library laufen und erste Ausgaben auf einem Display.

Im Grunde ist der Einstieg aufgrund der guten Libraries von Luminary 
sogar einfacher als beim Mega644, einzig das Linker-Skript ist anfangs 
etwas abschreckend, aber man braucht nur einen Bruchteil der Optionen, 
wenn man kein hochkomplexes Projekt damit macht.

Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Cortex läuft afaik mit winarm bzw. yagarto (Hab bisher nur mit dem 
ARM7 gearbeitet)

Die C-Algorithmen wirst du übernehmen können. Bei allem was auf Hardware 
zugreift, wird es vermutlich schwieriger.

Der Vorteil bei AVR ist, dass es nur einen Hersteller gibt, so dass die 
Hardware immer recht ähnlich angesprochen wird. ARM verkauft IP-Cores, 
die Hertseller in ihre Produkte einbauen können, weshalb es trotz 
gleichem Core sehr unterschiedliche Ansätze geben kann.

Ansonten hängt es davon ab, wie viel dir ein Compiler bzw. deine Zeit 
Wert ist. Je günstiger, desto mehr Zeit muss man investieren.

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd, das Problem kommt mir bekannt vor :-)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Der Cortex läuft afaik mit winarm bzw. yagarto (Hab bisher nur mit dem
>ARM7 gearbeitet)

Ich nutze Codesourcery G++. Das war die erste gcc Version, die den M3 
unterstützte. Sollte aber mittlerweile in der aktuellen Gcc Version drin 
sein.


>Die C-Algorithmen wirst du übernehmen können. Bei allem was auf Hardware
>zugreift, wird es vermutlich schwieriger.

Der Vorteil vom M3 ist, daß die Hersteller Luminary und ST umfangreiche 
Hardware Libraries bereit stellen, die das Programmieren der diversen 
MCU-Einheiten wirklich einfach machen, auf jeden Fall einfacher als beim 
AVR.


>Der Vorteil bei AVR ist, dass es nur einen Hersteller gibt, so dass die
>Hardware immer recht ähnlich angesprochen wird. ARM verkauft IP-Cores,
>die Hertseller in ihre Produkte einbauen können, weshalb es trotz
>gleichem Core sehr unterschiedliche Ansätze geben kann.

Das ist aber bei weitem nicht mehr so schlimm wie beim ARM7 oder ARM9.
ARM war so clever, 2 Dinge zu tun:
1. Die Gestaltungsmöglichkeiten bei der Hardware viel stärker 
einzuschränken, also z.B. Speicherbereiche oder einen Systicktimer im 
Kern, den alle Derivate haben.
2. Mit CMSIS einen Software Standard zu schaffen, der eine Portierung 
der Software auf andere Derivate stark vereinfacht.
So ist z.B. FreeRTOS in wenigen Minuten auf komplett andere Derivate 
portiert.


>Ansonten hängt es davon ab, wie viel dir ein Compiler bzw. deine Zeit
>Wert ist. Je günstiger, desto mehr Zeit muss man investieren.

Er benutzt offensichtlich GCC. Das geht auch genauso simpel mit dem M3.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielen Danke für die Antworten

> Ich fand es sehr einfach. Ich nutze allerdings kein JTAG-Debugging,
> sondern nur "simples" RS232 oder Display-Debugging.

mehr brauch ich auch nicht :)

Ich versteh noch nicht ganz, wenn GCC den M3 unterstütz,
wieso werden dann Programme wie FreeRTOS (?), LinkerScript benötigt.

Externe Libarys verstehe ich soweit, aus den AVR Dateien
#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
...

wird dann durch Luminary Libarys ersetzt.
#include "../scr/hw_memmap.h"
#include "../scr/hw_types.h"
#include "../scr/src/uart.h"

und die MakeFile sieht dann wohl so aus:
# WinARM template makefile 
# by Martin Thomas, Kaiserslautern, Germany 
# <eversmith@heizung-thomas.de>

# Toolchain prefix (i.e arm-none-eabi -> arm-none-eabi-gcc.exe)
TCHAIN = arm-none-eabi

# MCU name and submodel
MCU      = cortex-m3
SUBMDL   = lm3s811

# must be yes - only THUMB2 on M3 no ARM:
USE_THUMB_MODE = YES

## Create ROM-Image (final)
RUN_MODE=ROM_RUN
## Create RAM-Image (debugging) 
##( not used: example does not fit in AT91SAM7S64 RAM )
#RUN_MODE=RAM_RUN

## Exception-Vector placement not used so far in M3-examples
## (placement settings ignored when using "RAM_RUN")
## - Exception vectors in ROM:
#VECTOR_LOCATION=VECTORS_IN_ROM
## - Exception vectors in RAM:
##VECTOR_LOCATION=VECTORS_IN_RAM

# Target file name (without extension).
TARGET = main
...

Mein AVR STK500 müßte das dann doch auch wie gewohnt übertragen
können (hoffe ich mal...), nach dem GCC das compiliert hat

Ich müßte anfangs nur einen Uart hinbekommen,
dann wag ich mich langsam an den ADC Interrupt
(anhand von der Luminary Beispielen..) Soweit der Plan.

Hab ich was übersehen?

Danke & Viele Grüße
Bernd

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich versteh noch nicht ganz, wenn GCC den M3 unterstütz,
>wieso werden dann Programme wie FreeRTOS (?), LinkerScript benötigt.


Werden nicht benötigt.
FreeRTOS ist ein RTOS. Michael meinte sicherlich, daß es für ihn einfach 
war, dieses RTOS mit dem GCC auf dem CortexM3 zum Laufen zu bringen.
Auch ohne Linkerskripte kommt man aus, das ist allerdings umständlicher.

Zudem kann man die für die üblichen Hobby-Projekte (ala AVR) einfach 
halten.
Dann muss nur noch eins her für jeden Controller, den man nutzt und das 
war es dann. Das Handbuch dazu muss man jedenfalls nicht komplett lesen 
(und erst recht nicht komplett verstehen).
Hier im Forum wurden ja schon einfache für den Luminary M3 gepostet, 
einfach mal suchen.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Dirk,

super Dank Dir, ich werd's wagen :)

Viele Grüße

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.