Welche ARM Modelle eignen sich für Anfänger?

Die Nucleo Boards laufen doch mit der Embedd-Online Compilerumgebung und 
der Embedd-Library. Die ist doch relativ einfach und mit vielen 
Beispielen. Klappt das nicht?

ich habe am STM auch lang herumgebissen. Weil ich kein Windows sondern 
nur Unix benutze, mußte ich diverse Sachen noch zusammen suchen und 
rumprokeln.
Eclipse lief einmal, dann wieder nicht mehr. Darauf bin ich zu 
Kommandozeilen-Tools gegangen, die liefen stabiler.

Aber so richtig Spass macht es auch nicht, weil auch die Ansteuerung das 
STM sehr aufwändig ist. Es gibt einfach zu viele Register, bei denen man 
was einstellen kann. Die müssen alle von Hand bedient werden. Eine Api 
dafür fehlt irgendwie.
Der STM liegt schon länger in der Ecke.

Ich spiele dann lieber mit ARM-Boards, die schon ein OS haben, z.B. das 
Beagle Board oder den Raspi. Über Devices kommt man auch an I2C oder SPI 
ran. Das Arbeiten ist aber einfacher. Man kann Debuggen, hat 
Testausgabe. Kompiliert wird auf der Teilchen selber.

Und letztendlich ist die Architektur egal. Ich habe embedded Code mit 
uLinux als Basis. Der läuft auf Intelx86, Mips und Arm.

Was ist mit dem XMC 2go der neulich in den news war? Hat schon jemand 
damit gearbeitet, ist der Einsteiger freundlich?

Tom schrieb im Beitrag #3866412:
> Mittlerweile vergleiche ich das so, das XMega sowas iw der Apple der
> Computerwelt und ARM die Windowskisten sind...

So schauts aus. Architektonische Klar- und Einfachheit bei vielfach 
ausreichender Leistung hat eben ihren Preis.

> Die Arms sind exterm vielseitig

Oder sagen wir hochflexibel. Und genau das wird zum Problem des 
Einsteigers + es treibt den Entwicklungsaufwand (Fehlermöglichkeiten) 
generell nach oben- ohne das dies von der geplanten Anwendung her 
gerechtfertigt wäre. Konfiguritis pur.

> Obwohl derzeit nervt mich auch die etwas ansteigene Schwemme der neuen
> XMega Variationen

Für die meisten Anwendungen reicht doch der kleine XmegaE5, mit etwas 
mehr Pins und Uarts der A4U. Solls was ganz großes werden ggf. der A1.

> ok die CAN
> Unterstüzung fehlt mir :-(

Und da wär zu überlegen, ob solche drahtgebundenen Kommunikationsformen 
über längere Strecken überhaupt noch zeitgemäß sind- zumindest für 
Neuentwicklungen.

Nico S. schrieb:
> µController zu programmieren
> ist etwas anderes als irgendwelche Klicki-bunti-Anwendungen zu
> schreiben. Auch einen ARM zu programmieren ist was anderes als ATMEL.

Was ist an einem einfachen AVR Mikrocontroller Klicki-bunti?

Ich glaube instinktiv will niemand mit ARM arbeiten. Man muss sich dazu 
zwingen oder wird im Beruf gezwungen.
Ist wie mit einigen anderen sonderbaren Standards, wo die meisten sich 
am Anfang fragen wer sich so was hat einfallen, aber dann seufzt man und 
zwingt sich es zu lernen, dann heißt es, ja hat halt sein Grund wieso es 
90% nutzen,  muss wohl das beste sein, wenns jeder benutzt, obwohl es 
scheußlich anzuwenden ist, Standard eben....

Bifffd schrieb:
> Ich glaube instinktiv will niemand mit ARM arbeiten.
Ich arbeite sehr gerne und freiwillig mit ARM (hier: STM32), aufgrund 
der Flexibilität und hohen Leistung, freien Linux-Tools, netten 
Debug-Features, mächtiger Peripherie, vernünftigen Architektur (-> 
einheitlicher Adressraum, Barrel-Shifter, Offset-Adressierung, 
verschachtelbare Interrupts mit flexiblen Prioritäten, Multitasking etc. 
etc.). Ich hätte instinktiv sehr wenig Lust das mit dem AVR irgendwie 
hinzufrickeln.

Bifffd schrieb im Beitrag #3866522:
> aber ich
> arbeite doch nicht mal mit Atmel ARM und dann wieder mit STM32. Es
Warum nicht? Wenn man sich mit den STM32 auskennt ist es ein Leichtes 
mal eben schnell zB den LPC11C00 einzusetzen, weil man den aufgrund des 
integrierten CAN-Transceivers braucht. Wenn ich eine andere Architektur 
nehmen müsste, fängt es schon bei der Installation der Tools an...

Moby schrieb im Beitrag #3866551:
>> AVR ist eine Einbahnstraße!
>
> Die auch und meist

... in einer Sackgasse endet.

@Moby
Deine Ansprüche an µC sind hier bekannt und recht bescheiden. Deine µC 
Projekte lassen sich auch mit einer handvoll Gatter lösen. ;-)

Andere nutzen den µC und nutzen den zeitgemäßen Komfort und die 
modernen Möglichkeiten, die ein Cortex bietet. Deine aus der Luft 
gegriffenen Parolen werden den Fortschritt nicht verhindern. Hier im 
Forum zeigt sich der Trend bereits: Immer mehr - auch Einsteiger - 
satteln erfolgreich mit Cortex auf.

Also beantworte die Frage "Welche ARM Modelle eignen sich für Anfänger?" 
oder, da du davon keine Ahnung hast, halte die Finger still!

Ich kann stm32 in Kombination mit coocox empfehlen. Also ich kam damit 
auf Anhieb zurecht (bin von Avr) umgestiegen.

Mein Fazit war, dass es genauso leicht ist diese Dinger anzusprechen wie 
die AVRs. Ich hatte sogar schneller erfolgserlebnisse als damals mit den 
AVRs (da habe ich mir erstmal alles verfust und der Frust war enorm).

Ich habe seit dem Umstieg alle meine Atmegas verschenkt und arbeite auch 
im Hobby nur noch mit den zeitgemäßen ARMs

genervter Entwickler schrieb:
> ... in einer Sackgasse endet.

Genau, die endet. Aber in vielen nützlichen, fertig realisierten 
Projekten- statt eines in der Ecke verstaubenden Preis-Hype 
Stm-Discovery.

> Deine Ansprüche an µC sind hier bekannt und recht bescheiden. Deine µC
> Projekte lassen sich auch mit einer handvoll Gatter lösen. ;-)

Immer wieder schade, wenn man sich nur noch so zu artikulieren weiß. 
Aber paßt auch irgendwie zu den anderen abfälligen Äußerungen.

> werden den Fortschritt nicht verhindern.

Was für ein größenwahnsinniges Ziel ;-)  Allerdings ist doch sehr die 
Frage, von welchem Fortschritt hier die Rede ist wenn sich die 
überbordende ARM Komplexität immer weiter von reellen Anforderungen 
konkreter Anwendungen entfernt.

> Also beantworte die Frage "Welche ARM Modelle eignen sich für Anfänger?"

Keine.

genervter Entwickler schrieb:
> Deine Ansprüche an µC sind hier bekannt und recht bescheiden.

Moby schrieb:
> wenn sich die
> überbordende ARM Komplexität immer weiter von reellen Anforderungen
> konkreter Anwendungen entfernt

Danke für die Bestätigung!

Und da du keine Ahnung von ARM Cortex hast, bist du hier überflüssig.

Bitte mach einen eigenen Troll- und Jammer-Thread auf!

wuff schrieb:
> Ich kann stm32 in Kombination mit coocox empfehlen. Also ich kam damit
> auf Anhieb zurecht (bin von Avr) umgestiegen.
>
> Mein Fazit war, dass es genauso leicht ist diese Dinger anzusprechen wie
> die AVRs. Ich hatte sogar schneller erfolgserlebnisse als damals mit den
> AVRs (da habe ich mir erstmal alles verfust und der Frust war enorm).
>
> Ich habe seit dem Umstieg alle meine Atmegas verschenkt und arbeite auch
> im Hobby nur noch mit den zeitgemäßen ARMs

Klingt geschönt und unglaubwürdig.

>> Wenn du geistig schwerfällig bist, solltest du dich auf einen
>> Hersteller beschränken.
>
> Tut das nicht sowieso schon jeder? Die Auswahl mag da sein, aber ich
> arbeite doch nicht mal mit Atmel ARM und dann wieder mit STM32. Es sei
> denn ich bin dazu gezwungen weil ich mein Geld damit verdienen muss.

Nö, ich springe lustig zwischen ATmega, LPC11/12/13/17 und STM32F2/4 hin 
und her. Den EFM32 sehe ich mir bei Zeiten auch noch an. Die Toolchain 
ist ja immer die selbe. Natürlich unterscheidet sich die Peripherie 
zwischen den einzelnen Typen. Das sehe ich aber als Vorteil.
Die AVRs benutze ich allerdings nur noch wenn ich Streifenraster 
Platinen verwende. Das habe ich in diesem Jahr glaube ich nur einmal 
gemacht.

Die dsPICs finde ich auch recht spannend. Ich habe hier ein Board 
liegen, finde nur leider keine Zeit mich da mal vernünftig 
einzuarbeiten.

> Ich glaube instinktiv will niemand mit ARM arbeiten. Man muss sich dazu
> zwingen oder wird im Beruf gezwungen.

Wieder nö. Ich rege mich z.B. jedes mal über die Timer der AVRs auf. Nur 
1x 16Bit und allesamt mit seltendämlichen Prescalern. Bei den LPC/STM32 
kann ich den Prescaler auf 97 stellen wenn ich so einen Wert brauche. 
Für den UART brauche ich bei ATmega zudem einen Baudratenquarz. 
Hoffentlich hat Atmel wenigstens bei den XMegas nachgebessert. Die gibt 
es aber nicht als DIL, daher nehme ich dann gleich ARM.
Des Weiteren habe ich (auch privat) mit Signalverarbeitung zu tun. Da 
komme ich mit 8Bit nicht weit. Ich brauche 32/64 Bit Festkomma oder 
Gleitkomma. Deshalb ja auch die Sache mit dem dsPIC. Ist zwar nur 16Bit, 
die haben aber immerhin einen (zwei?) 40Bit Akku. Und tolle Peripherie.

Zum Thema:

Für den Einstieg krankt es ein wenig an Enwicklungsumgebungen die aus 
dem Stand heraus funktionieren. Coocox ist schon nicht schlecht wenn man 
ein damit erstelltes Programm nicht noch auf den Controller bringen 
müßte ;). Denn OpenOCD ist für mich eher eine Krankheit als ein 
Werkzeug. Der GDB Server von Segger für den J-Link übrigens auch.
Ich benutze überwiegend Eclipse mit der Linaro Toolchain und die 
seriellen Bootloader der Controller. Einsteigerfreundlich ist das aber 
freilich nicht.
Atollic ist wie µVision auf 32kB beschränkt (danach wirds teuer), 
LPCxpresso kann 256kB, geht aber nur mit LPCs. Und es ist ein völlig 
verbasteltes Eclipse.

Dann vielleicht doch etwas Geld in die Hand nehmen und in Crossworks 
investieren. Die Kosten sind für Privatanwender noch überschaubar (125$ 
oder €, weiß ich gerade nicht). Und damit kann man dann gut ein STM32 
Discovery Board nutzen. Auch zum Programmiereun und Debuggen von anderen 
Controllern wie die LPCs. Außer den LPC12xx. Die sind am ST-Link etwas 
bockig.

Zum Thema Anfänger ARM
Ich würde die Cortex M0 der LPC Reihe empfehlen.
1. Mit den LPCXPRESSO gibt es spottbillige,  breadboard taugliche, 
Evalboards mit Debugger (!),  letzterer auch für beliebige andere LPC 
Arm uC verwendbar
2. Mit dem LPC1114FN28 und dem Lpc800 gibt es zwei DIP ICs
3. Es gibt zum LPCXPRESSO eine sehr gute, kostenlose (auf 512 Kb Binary 
beschränkt) und sofort funktionsfähige IDE auf Basis von Eclipse für 
Windows und Linux. Dazu viele Beispiele für die gesamte Peripherie.

Stefan schrieb:
> Ich rege mich z.B. jedes mal über die Timer der AVRs auf. Nur
> 1x 16Bit und allesamt mit seltendämlichen Prescalern. Bei den LPC/STM32
> kann ich den Prescaler auf 97 stellen wenn ich so einen Wert brauche.

Schau Dir die Xmegas an. Da wurde nachgelegt.

> Für den UART brauche ich bei ATmega zudem einen Baudratenquarz.
> Hoffentlich hat Atmel wenigstens bei den XMegas nachgebessert.

Haben sie. Uart geht quarzfrei.

Es gibt einen ARM, der relativ einfach zum Einstieg ist:

http://hobby-roboter.de/forum/viewtopic.php?f=4&t=152

Tom schrieb im Beitrag #3867031:
> Vielfalltsproblem!

Na ja, such doch einmal hier im Forum nach verfusten AVRs. Nach deiner 
Meinung sind die AVRs dann totaler Schrott. ;-)

@Tom
Thema verfehlt! Bitte lies den Titel!

Und nur weil du es nicht raffst, heißt das nicht, das die Dinger 
schlecht sind. Sehr sehr sehr viele haben kein Problem damit.

Mach mit Moby den Troll- und Jammer-Thread auf, es wird langsam 
unerträglich.

>Keil würd ich mal so empfehlen, das ist
>auch bis 32kB Code frei.

32k ist wenig für einen ARM. Es lohnt sich nicht sich
in Keil einzuarbeiten wenn man später mal SD-Karte, RGB Grafikdisplay
und Ethernet machen möchte.

Eins von den dreien langt meist schon die 32k zu sprengen.

Tom schrieb im Beitrag #3867051:
> wir reden hier von ARM und XMEGA

Nein, es geht um "Welche ARM Modelle eignen sich für Anfänger?"

Zum Glück sind die anderen da wieder gelandet.

Dann frage ich mich was Du von Amtega und verfusen faselst :-)

Noch mal zu dem Kommentar von weiter oben...
"Und da wär zu überlegen, ob solche drahtgebundenen Kommunikationsformen
über längere Strecken überhaupt noch zeitgemäß sind- zumindest für
Neuentwicklungen."

Was ist denn da eine brauchbare alternative? Und ist es wirklich eine 
brauchbare?

Etwas OT :-)

Nimm doch etwas, das sofort geht. z.B, einen "Arduino Due". Da hast Du 
eine Menge an funktionierenden Beispielen und auch LIBs.

und welche Software ist das?
Es ist traurig,das sowas hier nicht im gleichen Satz erwähnt werden 
darf, da es dann gleich von irgendwelchen Gerhinakrobaten hier als 
Schleichwerbung abgetan wird!

Ich kann ja mal schreiben was mich verwirrt.
Ich will also ganz einfach mal eine LED zum blinken bringen, will also 
lernen wie man einen Pin ansteuert.

Ich habe das gefunden:

GPIO_InitTypeDef GPIO_InitStruct;
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);
GPIO_InitStruct.GPIO_Pin = GPIO_Pin_15 | GPIO_Pin_14 | GPIO_Pin_13 | 
GPIO_Pin_12;
GPIO_InitStruct.GPIO_Mode = GPIO_Mode_OUT;
GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStruct.GPIO_OType = GPIO_OType_PP;
GPIO_InitStruct.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(GPIOD, &GPIO_InitStruct);


Das funktioniert so schon mal nicht. Meine Entwicklungsumgebung mit 
Eclipse findet im GPIO_InitStruct kein GPIO_Pin oder GPIO_Mode sondern 
nur Pin und Mode also z.B. GPIO_InitStruct.Pin

Auf einer anderen Webseite habe ich dann gesehen das es auch so geht:
GPIOD->MODER

Und das der GPIO Clock mit
RCC->AHB1ENR |= RCC_AHB1ENR_GPIODEN
aktiviert wird, statt mit
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE)

Bei den Beispielen von ST im STM32Cube Paket findet man dagegen ein GPIO 
Beispielprojekt wo die Clock mit
__PWR_CLK_ENABLE();
aktiviert wird.


Ok es gibt also Unterschiede oder verschiedene Wege. Aber wie finde ich 
jetzt heraus nach welcher Dokumentation/Header mein Compiler geht?

Ich benutze diese Toolchain:
https://launchpad.net/gcc-arm-embedded

Mit diesem Eclipse Plugin:
http://gnuarmeclipse.livius.net/blog/

Mein Board:
Nucleo STM32F411RE

Korrektur: Ich schrieb __PWR_CLK_ENABLE().
Sollte __GPIOA_CLK_ENABLE() heißen.

naja, mit einem vernünftigen Compiler gehts auch bei arm, aber beim mega 
und auch xmega geht halt alles einfacher, beim adc mit ext ref wirds 
beim arm schon haarig..bei  xmega ist es genauso einfach wie beim alten 
Mega
Zwei Beispiele für einen STM32

1

GPIO_Digital_Output(&GPIOA_BASE, _GPIO_PINMASK_ALL); // Set PORTA as digital output

2

  while(1) {

3

  GPIOA_ODR = ~GPIOA_ODR;

4

delay_ms(1000);

5

}

ist es in Mikroe C und

und hier komplett in Pascal von Mikroe

1

  GPIO_Digital_Output(@GPIOA_BASE, _GPIO_PINMASK_ALL); // Set PORTA as digital output

2

  while TRUE do

3

    begin

4

      GPIOA_ODR := not GPIOA_ODR; // Toggle PORTA

5

      Delay_ms(1000);

6

     end;

Beim Atmega

1

begin

2

  DDRA := 0xFF;           // set direction to be output

3

4

  while TRUE do

5

    begin

6

      PORTA := not PORTA;      // Turn ON diodes on PORTA

7

      Delay_ms(1000);     // 1 second delay

8

    end;                  // Endless loop}

wie man auch sieht, sind C und Pascal komplett andere Welten, daher 
programmieren echte Vollprofis auch nur in C :-) harhar

Konrad S. schrieb:
> Jetzt mal aus dem Blickwinkel des AVR-Hobbybastlers der
> Lochraster-Kategorie:

Es mag sein dass viele Leute hier im Forum mit AVR angefangen haben 
(warum auch immer).

Aber für den Neu-Einsteiger ist ARM als erster uC problemlos möglich, 
egal ob man mit DIP und Steckbrett, Eval-Board oder eigenere Platine 
anfangen möchte. Es gibt haufenweise Tutorials, Demos und freie 
Schaltpläne.

Und wenn wirklich Fragen kommen, werden die alle hier im Forum auch von 
kompetenten Leuten beantwortet. Es gibt nur deswegen weniger Einträge 
als für AVR, weil es beim ARM-Einstieg eben tatsächlich weniger Probleme 
gibt :-)

Lothar schrieb:
> Und wenn wirklich Fragen kommen, werden die alle hier im Forum auch von
> kompetenten Leuten beantwortet. Es gibt nur deswegen weniger Einträge
> als für AVR, weil es beim ARM-Einstieg eben tatsächlich weniger Probleme
> gibt :-)

Dann muss Arduino ja höllisch schwer sein. Davon gibts gefühlt die 
meisten Threads.

>> Ich kann ja mal schreiben was mich verwirrt.
>> Ich will also ganz einfach mal eine LED zum blinken bringen, will also
>> lernen wie man einen Pin ansteuert.

Dieses Beispiel zeigt die Verwendung der STM Standard Peripheral Drivers 
Library für das PIN setzen, löschen, lesen sowie togglen. Taster an 
Port_A. Hardware: STM32F429 Discovery Board. Damit hast du dann ein 
einfaches Beispiel.

Das Ganze setzt auf CMSIS & CO auf. Hierzu empfehle ich dir folgendes zu 
lesen:
http://www.mikrocontroller.net/articles/STM32_-_Einstieg_mit_Em::Blocks

1

#include "stm32f4xx.h"

2

#include "stm32f4xx_gpio.h"

3

#include "stm32f4xx_rcc.h"

4

5

#define LED_GREEN GPIO_Pin_13

6

#define LED_RED   GPIO_Pin_14

7

#define KEY       GPIO_Pin_0

8

9

void gpIO_Init (void);

10

void Delay (volatile uint32_t loopCount);

11

12

int main (void)

13

{

14

    SystemInit ();                                                   // Sys. Init (Quarz etc.)

15

    gpIO_Init ();

16

17

    while (1) {

18

        GPIO_ToggleBits ( GPIOG, LED_GREEN );

19

        Delay ( 2000000 );

20

21

        if ( GPIO_ReadInputDataBit ( GPIOA, KEY ) )                  // Taster gedrückt ?

22

            GPIO_SetBits ( GPIOG, LED_RED );                         // rote LED an...

23

        else

24

            GPIO_ResetBits ( GPIOG, LED_RED );                       // ...oder aus

25

    }

26

}

27

28

void gpIO_Init (void)

29

{

30

    RCC_AHB1PeriphClockCmd ( RCC_AHB1Periph_GPIOG, ENABLE );         // Takt für Port_G

31

32

    GPIO_InitTypeDef GPIOG_InitStructure;

33

    GPIOG_InitStructure.GPIO_Mode = GPIO_Mode_OUT;                   // Port_G als Ausgang

34

    GPIOG_InitStructure.GPIO_Pin = LED_GREEN | LED_RED;              // PG 13 (green LED), PG 14 (red LED) PIN 128, 129 STM32F429ZIT6

35

    GPIOG_InitStructure.GPIO_Speed = GPIO_Speed_2MHz;                // Port_G speed (2, 25, 50, 100 MHz)

36

    GPIOG_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;                // kein Pull Up / Down

37

    GPIO_Init ( GPIOG, &GPIOG_InitStructure );

38

39

    RCC_AHB1PeriphClockCmd ( RCC_AHB1Periph_GPIOA, ENABLE );         // Takt für Port_A

40

41

    GPIO_InitTypeDef GPIOA_InitStructure;

42

    GPIOA_InitStructure.GPIO_Mode = GPIO_Mode_IN;                    // Port_A als Digital-Eingang

43

    GPIOA_InitStructure.GPIO_Pin = KEY;                              // PA0 Taster Eingang, PIN 34 STM32F429ZIT6, PA0 ext. Pull Down R

44

    GPIOA_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;                // kein Pull Up / Down

45

    GPIO_Init ( GPIOA, &GPIOA_InitStructure );

46

}

47

48

void Delay (volatile uint32_t loopCount)

49

{

50

    while ( loopCount-- ) {

51

    }

52

}

Einfacher gehts kaum. Ich vermute du hast dir keine Grundlagen 
erarbeitet. Ich kann mir nicht vorstellen das hieran irgend etwas 
kompliziert ist, man muß halt die Libraries studieren oder man schreibt 
selber welche.

>> Das funktioniert so schon mal nicht. Meine Entwicklungsumgebung mit
>> Eclipse findet im GPIO_InitStruct kein GPIO_Pin oder GPIO_Mode sondern
>> nur Pin und Mode also z.B. GPIO_InitStruct.Pin

Die IDE wirst du sicher selbst finden und dein Eclipse geraffel gehört 
in die Tonne oder vernünftig konfiguriert.

http://www.emblocks.org/web/

ist in den standard libs auch was drin, um auf die externe Referenz 
umzuschalten?

avr schrieb:
> Dann muss Arduino ja höllisch schwer sein. Davon gibts gefühlt die
> meisten Threads.

So viele Arduino Fragen gibt es hier doch gar nicht. Als Arduino Nutzer 
stellt sich die Lage doch so dar: entweder geht die Library zum Shield, 
was gibt es dann zu fragen. Oder die geht nicht, oder man möchte was 
ändern, dann wird es genau so komplex wie ohne Arduino. Eher noch 
schwieriger, denn seine uC Libraries hat man ja selbst gemacht und 
findet Fehler einfacher.

Bernd N schrieb:
> Verwendung der STM Standard Peripheral Drivers
> Library für das PIN setzen

Ohne diese Library sind es zwei Zeilen (Pin direction, Pin level).

So schwer ist ARM der STM32 nicht.

1. Nimmt man Em:Blocks. Das ist einfacher als das alte AVR-Studio obwohl 
es moderner und leistungsfähiger ist.

2. Nicht die STM-Libs nehmen. Ein GPIO kriegt man auf Registerebene in 
drei Zeilen konfiguriert. Für eine UART braucht man 5 Zeilen. Der 
gesamte Treiber braucht bei mir nicht einmal 50 Zeilen. Mit DMA. Man 
muss sich nur im Datenblatt zurecht finden, das ist aber wirklich sehr 
gut. Alles nicht wirklich komplizierter als die Atmegas.

>ist in den standard libs auch was drin, um auf die externe Referenz
>umzuschalten?

Sagen wirs mal so: Eine interne Referenz ist nicht wirklich vorhanden.
Es gibt zwar Refint, aber die hängt an einem ADC Kanal.

Ergo es wird immer die externe benutzt. Wenn keine Vref Pins vorhanden
sind ist das einer der VCC Pins. Klingt logisch, ist aber so.

Um welchen STM geht es da?

na z.B. der STM32F205VB wurde hier vor einigen Tagen angefragt, ich 
komme damit tatsächlich auch nicht klar.

Antimedial schrieb:
> Man muss sich nur im Datenblatt zurecht finden, das ist aber wirklich sehr
> gut.

Ja ja man muß nur... Man muß sich halt nur auskennen- wielange es aber 
zum entsprechenden Wissenstand braucht wird an dieser Stelle nicht 
verraten ;-)

Die ARM Datenblätter sind eher dazu geeignet Verwirrung zu stiften- aber 
vermutlich geht es bei DIESER Architektur auch nicht besser.

>Alles nicht wirklich komplizierter als die Atmegas.

Scherzkeks.

Und an all die großen ARM Experten hier: Nehmt die reale Erfahrungen von 
überforderten Anwendern mit ARM Controllern ernst, statt sie als
 Flachschaufel und geistig schwerfällig abzustempeln. Hinsichtlich 
solcherlei Abfälligkeiten hat mancher ARMer Moderator wohl auch einen 
blinden Fleck :-(

Moby schrieb:
> Die ARM Datenblätter sind eher dazu geeignet Verwirrung zu stiften

ARM ist nicht gleich ARM - es hängt vom Hersteller ab ob die 
Dokumentation übersichtlich, verständlich, beispielhaft ist. Bei NXP 
waren die 8051 Manuals gut und die ARM Manuals sind so geblieben. 
Abwechselnder Einsatz von z.B. LPC935 (8051) und LPC1114 (ARM) ist 
problemlos.

Lothar schrieb:
> ARM ist nicht gleich ARM - es hängt vom Hersteller ab ob die
> Dokumentation übersichtlich, verständlich, beispielhaft ist. Bei NXP
> waren die 8051 Manuals gut und die ARM Manuals sind so geblieben.
> Abwechselnder Einsatz von z.B. LPC935 (8051) und LPC1114 (ARM) ist
> problemlos.

Das kann ich auch bestätigen. Was beim STM32 Mist ist, ist die Lib die 
einem überall aufgezwungen wird. Die ist für sich nur schlecht 
dokumentiert und hat auch keinen Bezug zu den Reference Manuals. Die 
sind für sich allein genommen auch nicht schlechter als die von NXP.

Was meines Erachtens nach fast überall fehlt, sind minimalistische 
Code-Samples. Damit meine ich welche ohne jegliche Libs und ohne SysInit 
und der gleichen. Also eigentlich nur den Startup-Code mit den 
Interrupthandlern und ein Linkerscript. Alles weitere kann dann nach und 
nach dazu kommen.
So könnte dann auch ein Neuling wirklich anfangen zu verstehen wie hier 
der Hase läuft. Statt dessen erhält man aber meistens ein 
unübersichtliches Projekt. Wenn da noch der komplette Code der stm32-Lib 
mit drin ist, kann ich jeden Anfänger verstehen den das überfordert.
Das sind aber Probleme die nichts mit ARM an sich zu tun haben. Das 
sieht bei PIC32 auch nicht besser aus. Ich kann nur sagen, der Versuch 
die komplexere Architektur der Peripherie hinter einer noch komplexeren 
Lib bzw. Entwicklungsumgebung zu verstecken, geht gründlich in die Hose.

Mit den ADuC70xx Typen von Analog Devices bin ich beim "Aufsteigen" und 
Umsteigen auf ARM(7) sehr gut zurecht gekommen. Sowohl die IDE (von AD) 
als auch die Programmierung (Bootloader seriell auf allen Chips) sind 
ohne Verenkungen sofort einsatzbereit. Die Libs sind übersichtlich und 
gut erklärt.
Damit habe ich ohne Hilfe, nur nach Anleitung, alle Projekte 
hinbekommen.

Im Gegensatz zu den XE16xx von Infineon, den SAM7 von Atmel und den 
EFM32 von Energy Mico, die doch schon mehr Grundwissen verlangen und die 
ich ohne Hilfe nicht in angemessener Zeit zum Laufen bekommen hätte.

Zu den anderen ARM-Typen kann ich nichts sagen.


Blackbird

Tom schrieb im Beitrag #3869195:
> Asm Beispiele wo man den Krassen Unterschied
> zwischen ARM und AVR sieht

Da ich selber viele Module in ARM Assembler schreibe (Bit-Banging, 
Error-Handler, DSP) und ich ARM Assembler für sehr logisch aufgebaut und 
einfach halte, hätte mich dieser "krasse Unterschied" schon interessiert 
:-) Habe grade erst einen TFT-Treiber von AVR Assembler nach ARM 
Assembler portiert, war keine Aktion ...

Falk Brunner schrieb:
> So wie in der Steinzeit. Viel Spaß. Andere Leute nutzen sinnvollerweise
> eine gescheite IDE, die von Profis zusammengebaut wurde.

Und jede dieser tollen IDEs hat ihre eigenen Philosophie für den 
Startup-Code und das Linkerfile und alle möglichen Libs. Darum ist es ja 
immer so schön "einfach" Projekte die in einer IDE entwickelt wurden auf 
eine andere zu portieren. Besonders für Anfänger die erst mal das 
grundsätzliche Konzept dahinter verstehen wollen.
Ich persönlich brauche die IDE (in meinem Fall Crossworks) nur zum 
Debuggen. Am liebsten wäre mir nur der Debugger ohne den ganzen IDE 
Kram. Segger baut da gerade was. Aber leider ist es wohl in Zukunft an 
eine Lizense für den j-link pro gebunden, womit es dann auch wieder 
ausscheidet.
Ich verlange ja nicht von einem Anfänger, dass er den Startup selber 
schreibt oder komplett durchschaut. Aber sinnvoll ist es nicht in jeder 
IDE was anders zu haben.
Als Editor reicht sowas wie n++. Und für die 3 c(c++) Dateien am Anfang 
ist auch kein makefile nötig, da reicht ein cmd oder shell-Script völlig 
aus.
Was nützt es einem Anfänger, wenn er wie wild in der IDE rum klickt und 
am Ende zwar irgendwas geht aber das Verständnis dafür was wirklich dazu 
gehört fehlt trotzdem?

Entweder überschaubare (und intuitive) Bedienung und schnelle (kleine) 
Erfolge unter Verzicht einer langen und mühevollen Einarbeitung (mit 
Rückschlägen) oder genau andersherum: Wofür entscheidet sich ein 
Anfänger?

Der "einfache" Weg, den die vom Hersteller mitgegebenen IDEs und Libs 
vorgeben, schließt doch nicht automatisch den 2. Weg, die tiefere 
Einarbeitung aus.
Aber wenn man schon mal ein paar Erfolge hat (und damit eine 
"Rückfallebene", wenn man sich vertan hat), dann geht die tiefere 
Einarbeitung leichter von der Hand - es sind dann schon (wenn auch 
einfache) Kenntnisse vorhanden.

Wählt man den 2. Weg, so sind fast keine Kenntnisse vorhanden wenn mal 
was nicht tut. Und dann beginnt das Suchen ...

Selbstkasteiung ist nicht jedermans Sache.


Warum also nicht mit einfachen weitestgehend vorgefertigen, aufeinander 
abgestimmten und funktionierenden Tools beginnen und danach in das 
'Eingemachte' zu gehen?

Blackbird

Blackbird schrieb:
> Der "einfache" Weg, den die vom Hersteller mitgegebenen IDEs und Libs
> vorgeben, schließt doch nicht automatisch den 2. Weg, die tiefere
> Einarbeitung aus.
> Aber wenn man schon mal ein paar Erfolge hat (und damit eine
> "Rückfallebene", wenn man sich vertan hat), dann geht die tiefere
> Einarbeitung leichter von der Hand - es sind dann schon (wenn auch
> einfache) Kenntnisse vorhanden.

Diesen Weg bin ich beim Einstieg auch gegangen. LPCXpresso und LPC1769 
bzw. Attolic und STM32F103. Das war viel vergebene Zeit. Das 
LPCXpresso1769 Board ist zwar ganz nett gewesen. Leider ist man damit 
auf die LPCXpresso-IDE festgenagelt. Wechselt man zu STM32 muss man auch 
die IDE wechseln. Aus der ursprünglich großzügig bemessenen Atollic IDE 
wurde irgendwann eine stark eingeschränkte. Spätestens zu diesem 
Zeitpunkt hatte ich davon und mit allem was auf Eclipse basiert den 
Kanal voll. Ab da habe ich dann makefiles verwendet und die Projekte 
selbst gepflegt. Viele Teile meiner Codesammlung sind so zwischen STM32 
und LPC1xxx austauschbar. Zum Debuggen habe ich zu dem Zeitpunkt die 32k 
Version von Keil benutzt. Eine Vollversion von Keil oder IAR kam für 
mein privates Vergnügen nie in Frage. Dazu sind sie zu teuer. Ausserdem 
ist der Keil-Compiler und Assembler sicher nicht schlecht, aber leider 
nur zu sich selbst kompatibel. Aber man kann damit prima extern mit gcc 
erstellten Code debuggen.  Am Ende bin ich bei Crossworks gelandet und 
damit auch sehr zufrieden. Besonders mit dem Debugger.
Aber was soll's, ich will hier keinem meine Meinung aufzwingen.

Konrad S. schrieb:
>> Und für die 3 c(c++) Dateien am Anfang
>> ist auch kein makefile nötig, da reicht ein cmd oder shell-Script völlig
>> aus.
>
> Da verzettelst du dich, wenn du das gegen mögliche Fehler absichern
> willst. Ein Standard-Makefile für die einfachen Fälle und du hast keine
> Sorgen damit.

Da stimme ich dir zu. Trotzdem ist es für einen der sich mit der Syntax 
in den makefiles noch nie beschäftigt hat eine zusätzliche Hürde, die 
für "blinky" erst mal nicht nötig ist.

Konrad S. schrieb:
> In den Jahren, seit ich beruflich mit IT und Softwareentwicklung
> meine Brötchchen verdiene, habe ich mir ein paar Strategien erarbeitet,
> die auf allen Plattformen sehr gut funktionieren.

So ist es. Die IDE's kommen und gehen. Allein für die PC-Entwicklung von 
C++ Programmen habe ich von Borland, VC, Zortec bis Watcom fast alle 
Versionen durch. Von anderen Programmiersprachen wollen wir gar nicht 
erst reden. Was man dabei vor allem lernt ist hassen! Und lieben! 
Nämlich seinen Editor mit seinen Einstellungen. Da spielt es keine Rolle 
für was man Code schreibt...

TomiVoll schrieb:
> Ich habe hier ein STM32F411RE Nucleo Board und bin leider ziemlich
> überfordert.
> Das debuggen ging weder mit Eclipse, KEIL, noch mit CooCox.
> Das flashen ging dann immerhin mit dem ST Utility Programm.
>
> Und dann will ich eben mal wissen wie man die Taktrate einstellt und
> denke WTF.
> Anscheinend eine Wissenschaft für sich.
> Ich kann im Eclipse Editor die Taktrate angeben, aber kann nirgendwo im
> Code die Einstellung nachvollziehen.

Du stellst es grundsätzlich verkehrt an!

Also, so einen ARM oder Cortex in C zu programmieren, ist ganz genau so, 
wie irgend einen anderen µC in C uzu programmieren. Das als Anfang.

Versuche mal zu begreifen, daß du dich beim Programmieren nicht zu 
allererst mit irgend einer IDE und deren Befindlichkeiten befassen mußt, 
sondern mit der eigentlichen Hardware!

Das ist der eigentliche Knackpunkt.

Da liest man zu allererst das zuständige Referenzmanual. Normalerweise 
wird dort schon ganz gut beschrieben, wie man den Systemtakt einstellt, 
die Funktionalität der Port-Pins so einstellt, wie man das in der 
onkreten Schaltung benötigt und wie man dann sowas wie main() aufruft. 
Zum Einstellen der diversen Takte (ja, diese µC Klasse hat deren 
mehrere) braucht man das Beschreiben von diversen Hardware-Registern.. 
aber KEINE IDE!

Für all so etwas braucht man eigentlich gar keine IDE. Lerne dshalb erst 
einmal, deine Tools aus eigener Kraft aufzurufen. Wenn du das kannst, 
dann ist immer noch Zeit, sich ne IDE anzuschauen, sofern diese eine 
Arbeitserleichterung mit sich bringt.

Guck dir mal die Lernbetty hier im Forum an, da kannst du sehen, wie man 
die Tools von Keil und GCC per simpler Batch-Datei selbst aufruft. Lerne 
draus!

W.S.

Markus Müller schrieb:
> auf ein und der selben Leier und mobbt in allen STM32 Threads rum ohne
> auch nur einen sinnvollen Beitrag zu leisten

Der besteht darin, den Blick auf das Projekt-Ziel zu richten und welcher 
Aufwand dazu gerechtfertigt ist. Als Anfänger wäre ich vor vielen Jahren 
für solcherlei Orientierungshilfe auch dankbar gewesen und sie ist in 
jedem Thread, der die richtigen Mittel zum Ziel thematisiert genau 
richtig.
Wenn sich ein M.M. oder wer auch immer damit "gemobbt" fühlt ist mir das 
schnuppe.
Anders sieht es nur aus wenn vom Projekt her von vornherein klar ist, 
daß es unbedingt der Leistung eines ARM bedarf, oder weil eben die Firma 
oder ein Herr Lehrer danach verlangt.

Warum muß eigentlich jeder Thread derart ausarten ? Wer mit ARM anfangen 
möchte der sollte sich einfach eines der vielen STM, TI oder NXP Boards 
beschaffen und einen entsprechenden Compiler / IDE + Umgebung dazu 
installieren. Bei den professionellen Tools wie Keil oder IAR sollte ein 
Einstieg mittels Beispiele schnell gelingen.

Wie weit man abstrahieren möchte (CMSIS etc.) sollte jeder für sich 
entscheiden. Das bedeutet Libs oder / und Datenblätte studieren und gut 
ist.

Freie Tools sind in der Regel nicht so einfach zu handhaben aber im 
Bereich ARM sind selbst diese zu haben. Gute Beispiele sind EM Blocks 
sowie CCS.

Mit VI braucht mir allerdings keiner zu kommen :-).

Hast du mit den Beispielen was anfangen können ?

>> Überfordere ich mich als Anfänger mit dem STM32F4 oder sind alle ARM's
>> so umständlich, vielfältig und kompliziert?

Was genau überfordert dich denn ?

Moby schrieb:
> Der besteht darin, den Blick auf das Projekt-Ziel zu richten und welcher
> Aufwand dazu gerechtfertigt ist. Als Anfänger wäre ich vor vielen Jahren
> für solcherlei Orientierungshilfe auch dankbar gewesen und sie ist in
> jedem Thread, der die richtigen Mittel zum Ziel thematisiert genau
> richtig.

Das Projektziel besteht hier aber gerade darin sich in einen ARM (STM32) 
einzuarbeiten.

Deine penetranten Auftritte lesen sich in etwa so als wenn jemand im 
Nespresso Forum ein Problem mit seiner Kaffeemaschine hat und ihm von 
einem Siggi erklärt wird daß Kamillentee ohnehin viel gesünder ist. Und 
auch viel einfacher in der Zubereitung da man keine Maschine dafür 
braucht. Natürlich kennt Siggi sich mit Kaffeemaschinen überhaupt nicht 
aus. Mit Pfefferminztee auch nicht denn mit Kamille war er bisher immer 
zufrieden.
Klingt albern? Stimmt, ist es auch.

Mit solchen Vergleichen ist das immer so eine Sache. Hast Recht. Sie 
sind albern.

Also ich sehe als Anfänger ARM eher für embedded Systeme und 
Mikrocontroller wie z.B. auch von Atmel oder Microchip etc. eher für 
direktere Steuer bzw. Messfunktionen.
Mikrocontroller sind für einen Anfänger natürlich leichter zu 
bewältigen.
Man kann auch gleich miteinem ARM in die vollen gehen. Die Lernkurve 
steigt dann natürlich erstmal kräftig an, aber auch das kann man mit 
etwas Geduld schaffen.

Jemand schrieb:
> Also ich sehe als Anfänger ARM eher für embedded Systeme

Cortex A und R sind für embedded Systeme / Linux gedacht aber Cortex M 
die es schon ab DIP-8 gibt bestimmt nicht, sind Mikrocontroller.

Was ist mit den Infineon Cortex, sind die nicht einfacher zu 
programmieren?

TomiVoll schrieb:
> Überfordere ich mich als Anfänger mit dem STM32F4 oder sind alle ARM's
> so umständlich, vielfältig und kompliziert?

Stell Dir einfach mal vor, Du hättest einen AVR vor Dir und es gäbe 
überhaupt keine Resourcen auf die Du im Internet zu greifen könntest. Du 
wärst genauso überfordert. Die Cortex-M4, Cortex-M3 usw sind relativ neu 
und es gibt einfach keine so große Community, wie es bei den PICs und 
AVRs der Fall ist.

Die meisten fühlen sich sicher im Umgang mit diesen uCs haben aber 
eigentlich gar nichts verstanden, da Copy&Paste meistens die Lösung 
bringt.

Fang am besten ganz, ganz klein an. Setze Dich vor allem mit der 
Architektur von uC ausseinander und versuche zunächst das startup-Script 
zu verstehen und zu benutzen. Lass was blinken.

TomiVoll schrieb:
> Das debuggen ging weder mit Eclipse, KEIL, noch mit CooCox.
> Das flashen ging dann immerhin mit dem ST Utility Programm.

Versuche auch mal ein Firmware-Update des integrierten Programmers 
durchzuführen.

@Bernd N

Danke, dein Beispiel hat mit Em::Blocks funktioniert. Projektordner und 
die erzeugten Dateien sehen auch sonst übersichtlich aus, irgendwie 
besser als in Eclipse mit ARM Plugin und Cortex Template. Schade nur das 
Em::Blocks nur für Windows verfügbar ist.

Was mich verwirrt ist der abweichende Syntax bzw. die abweichenden 
Befehle die man in Beispielen findet.
Wie hier beschrieben:
Beitrag "Re: Welche ARM Modelle eignen sich für Anfänger?"

>> Was mich verwirrt ist die abweichende Syntax

Ok, deswegen der Hinweis CMSIS. Du kannst auch vollständig darauf 
verzichten. Du kannst dann eben auch direkt die Register verwenden die 
im entsprechenden .h File stehen. Die Port initialisierung verwendet 
derzeit die Lib Funktionen aus der stm32f4xx_gpio.c, schau dir die mal 
an.

Als Einstieg lese mal das hier:
http://www.diller-technologies.de/stm32_wide.html

Markus Müller schrieb:
> Die Register werden ohne Lib direkt angesprochen.

Da ich bisher mit LPC gearbeitet habe nicht mit STM32 würde mich 
interessieren: in dem Beispiel wird keine CLK initialisiert, läuft der 
STM32 dann ohne eine PLL mit einem internen Oszillator? Was ist dann der 
Takt? Zudem muss ich sagen, beim LPC haben die Register eingängigere 
Namen und die Ports sind nummeriert, ich kann also mit einem Register 
Px.0 bis Px.31 setzen. Wie sieht es beim STM32 mit Bitbanding auf 
8/16/32-bit aligned aus?

>> in dem Beispiel wird keine CLK initialisiert

Das passiert in der "SystemInit ();". Clock ist 168 MHz.

>> Zudem muss ich sagen, beim LPC haben die Register eingängigere
>> Namen und die Ports sind nummeriert

Namen sind Schall und Rauch :-) Als ich mit dem LPCs gearbeitet habe 
fand ich die Ports auch nicht gerade übersichtlich. Beim STM ist es 
erheblich einfacher für einen Anfänger, GPIOA bis ... GPIOG etc. Jeder 
Port hat seine PINs und eigentlich ist es wie bei jedem anderen 
Controller. Was verwirrend sein mag ist die Vielfalt der Port 
Eigenschaften, Pull Up/Down Ja / Nein, eigene Port Clock auch noch mit 
unterschiedlichen Geschwindigkeiten, Eingang oder Ausgang...

1

void gpIO_Init (void)

2

{

3

    RCC_AHB1PeriphClockCmd ( RCC_AHB1Periph_GPIOG, ENABLE );         // Takt für Port_G

4

5

    GPIO_InitTypeDef GPIOG_InitStructure;

6

    GPIOG_InitStructure.GPIO_Mode = GPIO_Mode_OUT;                   // Port_G als Ausgang

7

    GPIOG_InitStructure.GPIO_Pin = LED_GREEN | LED_RED;              // PG 13 (green LED), PG 14 (red LED) PIN 128, 129 STM32F429ZIT6

8

    GPIOG_InitStructure.GPIO_Speed = GPIO_Speed_2MHz;                // Port_G speed (2, 25, 50, 100 MHz)

9

    GPIOG_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;                // kein Pull Up / Down

10

    GPIO_Init ( GPIOG, &GPIOG_InitStructure );

Das Ganze ist als struct per Port organisiert. Wirklich nicht 
kompliziert.

Man sollte sich einfach mal ein Grundgerüst anschauen und den Code dazu 
studieren.

Das war bei den LPC nicht sehr viel anders, ich habe mit dem 1768 
gearbeitet und der ist auch nicht gerade ein einfacher Controller.

Im Anhang mal ein Screenshot, mit den Paar Zeilen Beispiel Code steht ja 
noch kein Projekt. Die Clock Einstellungen passieren im Startup Code.

Ich kann auch gerne das Projekt hochladen.

Bernd N schrieb:
> Das passiert in der SystemInit() Clock ist 168 MHz

Also eine versteckte Funktion, die wahrscheinlich aus dem Startup-Code 
aufgerufen wird? Kann man auch ganz ohne Library arbeiten? In dem 
Tutorial steht, dass ohne CLK Initialisierung immer mit 72 MHz gestartet 
wird, auch wenn der STM32 z.B. nur 48 MHz kann. Das wäre ja wie verfusen 
beim AVR. Die LPC werden immer mit 12 MHz gestartet.

Bernd N schrieb:
> ich habe mit dem 1768
> gearbeitet und der ist auch nicht gerade ein einfacher Controller

Stimmt, der war noch merkwürdig, musste aber ja abwärtskompatibel zum 
ARM7 sein. Der einzige der mit 4 MHz gestartet wird. Wenn ich bei einem 
neueren z.B. dem kleinen LPC810 ohne Library arbeite, definiere ich mir 
structs und Addressen aus dem Manual. Der hat z.B. 6 GPIO somit:

typedef struct {
    __REG32 P0_0   : 1;
    __REG32 P0_1   : 1;
    __REG32 P0_2   : 1;
    __REG32 P0_3   : 1;
    __REG32 P0_4   : 1;
    __REG32 P0_5   : 1;
    __REG32        :26;
} __gpio0_bits;

__IO_REG32_BIT(DIR0, 0xA0002000, __READ_WRITE, __gpio0_bits);
__IO_REG32_BIT(PIN0, 0xA0002100, __READ_WRITE, __gpio0_bits);

DIR0_bit.P0_4 = 1;  // output
PIN0_bit.P0_4 = 1;  // high

>> Ich beginne gerade, micht mit dem STM32F2 (F429-Disc.) zu beschäftigen

@Thomas

http://mikrocontroller.bplaced.net/wordpress/?page_id=2736

Dann ist das die richtige Seite für dich. Dort gibt es reichlich Code 
Beispiele. Dies sind alles Lauffähige CoCox Projekte und EMBlocks kann 
diese importieren. Da kannst du von der blinkenden LED bis zum Osci 
alles ausprobieren und dich langsam einarbeiten.

Chris D. schrieb:
> Verfusen geht beim STM32 prinzipiell nicht. In welchem Tutorial steht das?

Dieses Tutorial wurde weiter oben mal empfohlen:

http://www.diller-technologies.de/stm32_wide.html

Das hatte ich aber nicht genau genug gelesen, da steht, "wenn man 
SystemInit() aufruft" und "Standardmäßig wird der Takt auf 72 MHz 
eingestellt, unter der Annahme, dass ein 8 MHz Quarz angeschlossen ist. 
Achtung: Diese hohe Taktfrequenz wird nicht von jedem Chip unterstützt"

Das heisst also, wenn man SystemInit() gar nicht aufruft, läuft der 
interne Oszillator. Und wenn man es auf einem 48 MHz STM32 ohne Änderung 
aufruft, geht nichts mehr, wohl auch kein Debuggen. Dann kann man 
vermutlich nur mit dem seriellen Bootloader noch ran (ist beim LPC 
jedenfalls so).

Lothar schrieb:
> Dann kann man
> vermutlich nur mit dem seriellen Bootloader noch ran (ist beim LPC
> jedenfalls so).

da die Cortexe im ResetVector starten und im debugmode auch dort landen
kann man auch bei zu hohem takt die dinger neu flashen

ich habe so zum spass vereinzelte cortexe übertaktet
von max 100MHz bin ich teils bis 160Mhz gekommen
eh dann wirklich der kern ausgestiegen ist.

wichtig dabei: flashen war immer möglich ...

zur not eben erstmal flash löschen.. dann ist das thema eh geklärt

Der Thread ist ja jetzt schon wieder in paar Wochen alt, ich möchte 
trotzdem noch einen Beitrag zum Thema "STM32 Programmieren mit 
Registern" in die Runde werfen:

http://www.powerloss.de/2014/11/stm32-tutorial-teil1-einstieg-in-die-programmierung-des-stm32-auf-registerebene/

Mitleser schrieb:
> Der Thread ist ja jetzt schon wieder in paar Wochen alt, ich möchte
> trotzdem noch einen Beitrag zum Thema "STM32 Programmieren mit
> Registern" in die Runde werfen:

Der Artikel ist ja nagelneu, vielleicht von Deinem guten Bekannten? ;-)

Ich denke Atmel ARM könnte ein bisschen einfacher sein, weil es eine 
komplette IDE direkt von Atmel gibt. Glaube bei XMC gibt's auch eine. 
Dafür bezahlt man wahrscheinlich für die Entwicklungsboards und Debugger 
mehr.

major

Heiner schrieb im Beitrag #3895062:
> Also fuer einen Anfaenger ist jeder ARM ungeeignet, egal
> welche Ausfuehrung. Denk mal drueber nach.

Ich halte das für völlig falsch.

TomiVoll schrieb:
> Überfordere ich mich als Anfänger mit dem STM32F4 oder sind alle ARM's
> so umständlich, vielfältig und kompliziert?

Nein. Die Controller selbst sind eigentlich recht einfach zu verstehen 
und zu programmieren.

Dein Problem besteht darin, daß du zu allererst angefangen hast, nicht 
deinen Chip verstehen zu wollen, sondern stattdessen dich mit diversen 
IDE's herumgeplagt hast. Das ist in fast ALLEN Fällen genau der Grund 
für Frust. Entweder läuft dann eine Demo glatt durch und die LED blinkt, 
ohne daß der Benutzer die Funktionalität begriffen hätte, oder es läuft 
eben nicht durch - und dann ist Frust ohne Verstehen des Warums 
angesagt.

Ich will nicht sagen, daß IDE's an sich schlecht wären, aber sie 
versuchen vehement, den Abstand zwischen dem Benutzer und seinem 
eigentlichen Objekt zu maximieren und sich selbst dazwischen zu 
schieben. Dadurch muß man zweierlei lernen: den eigentlichen Controller 
UND auch noch die völlig andersartige Sichtweise der Programmierer, die 
die IDE geschrieben haben.

Mein Rat: Erstens konzentriere dich auf die Doku zu deinem µC. Die sind 
im Prinzip alle schlecht, aber da ist m.E. Philips(NXP) noch deutlich 
besser als ST und der Rest. Zweitens lerne du, deine Tools selbst und 
OHNE eine IDE aufzurufen und zu benutzen. Wenn du das kannst, dann wäre 
die Zeit, sich diverse IDE's anzusehen, weil du dann Ahnung von der 
eigentlichen Sache hast und die Schlechtigkeiten der IDE's eher erkennen 
und einschätzen kannst.

(gebetsmühle an)
Guck dir zumindest informativ mal die Lernbetty hier im Forum an, die 
ist zum Einstieg in die ARM-Welt gedacht. Manches (wie ARM versus THUMB) 
ist inzwischen durch die Cortexe überholt, aber nicht die prinzipielle 
Herangehensweise ans Thema.
(gebetsmühle aus)

W.S.