STM32F103 GPIO

[ucc (Gast)]

Ich habe ein Projekt geöffnet in Keil und will die Ports A-G 
initialisieren. Aber habe keine Ahnung wo ich ansetzen soll. Wie geht 
das denn? Lese die Reference Manuel und ferstehe nicht viel. Weiss das 
ich einen Cock brauche auf, output stellen muss. Aber wie? Hat jemand 
codebeispiel?

[Oliver R. (orb)]

Sieh Dir die Beispiele an, die bei der SPL oder HAL dabei sind.
Du findest einiges beim Hersteller:
http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1031/LN1565/PF189782#

[Patrick S. (pad)]

Moin,

ich würde dir empfehlen, dir mal das Programm CubeMx von STM 
anzuschauen. Damit kannst du dir für deinen Controller/dein Board die 
Initialisierung erzeugen lassen. Das wirft auch gleich eine Projektdatei 
für Keil (und andere IDE's raus) Meiner Meinung nach ganz gut, um zu 
verstehen, wie das funktioniert.

Ansonsten steht auch alles, was du brauchst in der Dokumentation der HAL 
(in deinem Fall natürlich zur HAL F1).

Gruß

[ucc (Gast)]

Habe mir die RM0008 angeschaut. Um Gpio zu aktivieren muss ich ja in 
dasn config register schreiben in das GPIOx_CRL und GPIOx_CRH.

ich schreibe also überall die 0x15555555. CNFy=01: General Purpose outpu 
Open-drain. & MODEy=01 das ist output mode 10mhz.

Das bei 32bits ergibt 0x15555555 also kommt das in die GPIOx_CRL und 
GPIOx_CRH?
Oder stimmt das so nicht? Ich finde es echt schwer aus dem Reference 
Manuel etwas zu verstehen wenn man sich das erste mal damit beschäftigt.

[W.S. (Gast)]

ucc schrieb:
> Ich finde es echt schwer aus dem Reference
> Manuel etwas zu verstehen wenn man sich das erste mal damit beschäftigt.

Wenn dir dieses zu unverständlich erscheint und du nicht die innere 
Kraft hast, es verstehend zu lesen, dann befasse dich mit irgend etwas 
anderem. Mir ist dabei durchaus klar, daß es eine Menge 
RefMan-Schreiber in den Herstellerfirmen gibt, die sich schwerverdaulich 
ausdrücken. Aber da hilft einem nix: da mußt auch du durch - oder du 
läßt es bleiben und wirst z.B. Politiker.

Damit du was zum Lesen hast (nicht zum blinden Kopieren), häng ich dir 
mal ne ältere Konfiguration für nen STM32F103 dran. Zum lesen und 
verstehen lernen.

W.S.

[Sebastian S. (amateur)]

Zu praktisch allen Controllern gibt es das "C"-Äquivalent zu Hello 
World.

Dabei wird fast immer ein Port (mit LED) ein- bzw. ausgeschaltet.

Neben einigem an Initialisierung gehört auch dazu, dass (mindestens) ein 
Port vom Reset-Zustand (Input) in den Ausgabezustand gebracht wird. In 
einer späteren Hauptschleife wird dann abwechselnd der Port gesetzt und 
wieder zurückgesetzt.

Also einfach mal gucken.

[Moby (Gast)]

W.S. schrieb:
> Kraft hast, es verstehend zu lesen, dann befasse dich mit irgend etwas
> anderem.

Richtig. Zum Beispiel mit einfachen AVRs, um damit viel schneller ans 
Ziel zu kommen. ARM-Konfiguritis muß ja nicht jedermans Leidenschaft 
sein ;-)

[Bernd K. (prof7bit)]

Moby schrieb:
> W.S. schrieb:
> Kraft hast, es verstehend zu lesen, dann befasse dich mit irgend etwas
> anderem.
>
> Richtig. Zum Beispiel mit einfachen AVRs, um damit viel schneller ans
> Ziel zu kommen. ARM-Konfiguritis muß ja nicht jedermans Leidenschaft
> sein ;-)

Ist bei den gängigen arm kein bisschen anders oder komplizierter als bei 
avr. Teilweise sogar massiv einfacher und logischer.

[Moby (Gast)]

Bernd K. schrieb:
> Ist bei den gängigen arm kein bisschen anders oder komplizierter als bei
> avr. Teilweise sogar massiv einfacher und logischer.

Einen unbeirrbaren Humor muß man haben!
Am lustigsten: "Massiv einfacher..." ;-)
Schon mal Ports und eine LED unter AVR gesetzt?

[Bernd K. (prof7bit)]

Moby schrieb:
> Schon mal Ports und eine LED unter AVR gesetzt?

Ja. Funktioniert auch nicht anders als bei nem ARM.

[Oliver R. (orb)]

Bernd K. schrieb:
> Ist bei den gängigen arm kein bisschen anders oder komplizierter als bei
> avr. Teilweise sogar massiv einfacher und logischer.

Erklärst Du mir dann mal wo ich beim AVR den Port einschalte, die 
Frequenz setze oder entscheiden muß, ob ich PullUp oder PullDown 
einschalte.

Es ist nicht schwieriger, aber doch anders und deutlich komplexer.

[Bernd K. (prof7bit)]

Oliver R. schrieb:
> Erklärst Du mir dann mal wo ich beim AVR den Port einschalte,

Beim AVR darf man sämtliche Peripherie die man nicht nutzt jedesmal erst 
ausschalten, also genau das selbe Prinzip nur mit schwachsinnigen 
Defaults.

> die Frequenz setze oder entscheiden muß, ob ich PullUp oder PullDown
einschalte.

Was willst Du? Die stehen alle auf brauchbaren Default-Werten, die 
Pullups sind selbstverständlich ausgeschaltet solange bis Du sie 
brauchst. Welche Frequenz willst Du wählen? Die Slew-Rate? Die ist ab 
Reset auch auf vernünftigen Default-Werten bei den Controllern die das 
überhaupt unterstützen.

Der AVR hat übrigens auch Pullups, die sind aber dort 
schwachsinnigerweise im PORT-Register, also eine verwirrende 
Mehrfachbelegung der selben Bits, als ob der auch nur einen Cent 
billiger geworden wäre durch das Einsparen eines weiteren Registers.

Einfacher oder irgendwie anders als jeweils ein Bit im PDDR und eins in 
PDOR zu setzen um eine LED einzuschalten wirds dadurch aber trotzdem 
nicht.

[Moby A. (moby-project)]

Typischer C Aufwand, um ne ARM-LED einzuschalten bzw. einschalten zu 
können:


/* GPIOD Takt einschalten  */
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);

/* Konfiguriere GPIO Port D15 */
GPIO_InitTypeDef  GPIO_InitStructure;
GPIO_StructInit (&GPIO_InitStructure);
GPIO_InitStructure.GPIO_Pin =  GPIO_Pin_15;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(GPIOD, &GPIO_InitStructure);

GPIO_SetBits(GPIOD,GPIO_Pin_15);


Unter AVR z.B. :

sbi DDRA,0
sbi PORTA,0

um gleich mal die Vorteile einer einfachen Systemarchitektur (AVR) mit 
den  wenigen nötigen Zeichen einer kurzen Sprache (ASM) kombiniert zu 
demonstrieren.

Alles Reiner Masochismus, zumindest wenns die Anwendung (oder der Boss) 
nicht erfordert ;-)

[Bernd K. (prof7bit)]

Moby A. schrieb:
> Typischer C Aufwand, um ne ARM-LED einzuschalten bzw. einschalten
> zu
> können:
> [bla]

Du verzerrst wieder mal die Wahrheit. Du vergleichst einen Schnipsel 
C-Code der ohne Not die stdperipheral-Lib von ST verwendet mit zwei aus 
dem Zusammenhang gerissenen ASM-Instruktionen wobei Du komplett das 
notwendige Brimborium drumherum verschweigst das ein Anwender braucht 
bis er AVR-ASM gelernt, deinen ASM-Schnipsel assembliert, mit der 
Vektortabelle und den Startup gelinkt und geflasht bekommt.

Der Anfänger fängt in der Regel mit C und hinter der ersten geschweiften 
Klammer von main() an und den Rest davor bekommt er frei Haus vom 
Hersteller oder von Beispielprojekten geliefert.

Hier ein Blinky auf einem STM32F401RE, dieses Device ist verglichen zu 
Deinem ATTiny so ziemlich das Über-Monster, trotzdem läuft das Blinky 
kein bisschen anders ab als das vergleichbare C-Blinky auf nem Tiny.

Die graue Schrift sind übrigens Kommentare, die kannst Du rauslöschen. 
Ebenso die Leerzeilen, die dienen nur der Auflockerung, nicht daß Du 
noch unterstellst die wären bei ARM erforderlich oder würden den Code 
aufblasen.

#include <stm32f401xe.h>


/*
 * The green LED is connected to port A5,
 * see schematic of NUCLEO-F401RE board
 */
#define LED_GPIO        GPIOA
#define LED_PIN         5


/**
 * Quick 'n' dirty delay
 *
 * @param time the larger it is the longer it will block
 */
static void delay(unsigned time) {
    for (unsigned i=0; i<time; i++)
        for (volatile unsigned j=0; j<20000; j++);
}


/**
 * Hello world blinky program
 *
 * @return never
 */
int main(void) {

    /*
     * Turn on the GPIOA unit,
     * see section 6.3.9 in the manual
     */
    RCC->AHB1ENR  |= RCC_AHB1ENR_GPIOAEN;


    /*
     * Set LED-Pin as output
     * see section 8.4.1 in the manual
     */
    LED_GPIO->MODER |= (0b01 << (LED_PIN << 1));


    while(1) {

        /*
         * LED on (see section 8.4.7 in the manual)
         */
        LED_GPIO->BSRRL = (1 << LED_PIN);

        delay(200);

        /*
         *  LED off
         */
        LED_GPIO->BSRRH = (1 << LED_PIN);

        delay(200);
    }
}

[ucc (Gast)]

Kann vielleicht jemand in Worten schreiben was alles gemacht werden muss 
um GPIO auf Output zu aktivieren? Also alles was dazu gehört.

[Bernd K. (prof7bit)]

ucc schrieb:
> Kann vielleicht jemand in Worten schreiben was alles gemacht werden muss
> um GPIO auf Output zu aktivieren?

Zwei Registerzugriffe:
* gpio-einheit aktivieren (Takt dafür einschalten)
* entsprechende pins als Ausgang konfigurieren. Fertig.

Zeig doch mal was du bisher hast damit man sehen kann wie du das 
überhaupt angehen willst, mit HAL oder auf dem blanken Silizium.

Hast Du das Reference Manual schon gefunden? Konkrete Frage zu einem 
konkreten Kapitel?

[Andreas R. (daybyter)]

http://www.stm32duino.com/viewtopic.php?t=58

[Christian J. (Gast)]

ucc schrieb:
> Kann vielleicht jemand in Worten schreiben was alles gemacht werden muss
> um GPIO auf Output zu aktivieren? Also alles was dazu gehört.

Da steht doch da schon !!!

[Moby A. (moby-project)]

Bernd K. schrieb:
> Beim AVR darf man sämtliche Peripherie die man nicht nutzt jedesmal erst
> ausschalten, also genau das selbe Prinzip nur mit schwachsinnigen
> Defaults.

Ach was. Beim ARM darfst Du jedesmal einschalten, beim AVR schaltest 
Du nur dann was aus wenn der ohnehin karge Stromverbrauch wirklich mal 
ne Rolle spielt...

> Der AVR hat übrigens auch Pullups, die sind aber dort
> schwachsinnigerweise im PORT-Register, also eine verwirrende
> Mehrfachbelegung der selben Bits

Ja meine Güte, im Input-Modus hat das Port-Register halt die Funktion 
des Pullup-Schalters, im Output Modus werden damit die Pins selber 
gesetzt. Das ist weder schwachsinnig noch verwirrend sondern einfach 
clever und spart zusätzliche Konfigurationsregister ein. Ist natürlich 
nix für den konfigurationsregisterfreudigen ARM Fan- der braucht 
möglichst viele Register. Je komplexer umso besser...

Bernd K. schrieb:
> Du verzerrst wieder mal die Wahrheit. Du vergleichst einen Schnipsel
> C-Code der ohne Not die stdperipheral-Lib von ST verwendet mit zwei aus
> dem Zusammenhang gerissenen ASM-Instruktionen wobei Du komplett das
> notwendige Brimborium drumherum verschweigst das ein Anwender braucht
> bis er AVR-ASM gelernt, deinen ASM-Schnipsel assembliert, mit der
> Vektortabelle und den Startup gelinkt und geflasht bekommt.

Was für Brimborium? Notfalls stehen die beiden Asm-Instruktionen auch 
alleine im Flash und die LED geht an... An diese Einfachheit ist bei ARM 
nicht mal im Traum zu denken. Die paar Asm-Instruktionen sind samt AVR 
Datenblatt schnell gelernt- gar kein Vergleich mit ARM- wo schon aus 
Komplexitätsgründen Asm gar nicht mehr in Frage kommt.

[Dr. Sommer (Gast)]

Moby A. schrieb:
> wo schon aus
> Komplexitätsgründen Asm gar nicht mehr in Frage kommt.
Quatsch. Wenn schon aus Faulheitsgründen. Ist aber gar kein Problem:

.equ GPIOD, 0x40020C00

// Initialisiere Pin PD15
ldr r0, = GPIOD
mov r1, (1 << 30)
str r1, [r0, #0]

// Setze Pin PD15
mov r1, (1 << 15)
str r1, [r0, #18]

Ja, der Code ist etwas länger als beim AVR. Das hängt mit der saubereren 
Load-Store-Architektur des ARM zusammen. Nachteil: 1/2 Instruktionen 
mehr. Vorteil: Funktioniert so mit allen Registern, Flash/RAM/... 
-Adressen, ganz ohne Bank-Umschaltung (wie bei AVR's mit > 64 KiB 
Speicher), Spezial-Instruktionen je nach Speicher (wie LPM vs LD). Ist 
so im Endeffekt sogar einfacher.

Achja, von wegen Einfachheit: Programmiere mal diese C-Funktion in 
AVR-Assembler:

uint32_t shift (uint32_t x, uint32_t y) {
  return x << y;
}

Im ARMv7M-Assembler sieht's so aus:

shift:
  lsl r0, r1
  bx lr

Na, ists auf dem AVR auch so einfach? Und auch so schnell (1 Takt)?

Oh, und wo's gerade so schön ist:

uint8_t get (uint16_t* arr, uint8_t index) {
  return arr [index];
}

Auf dem ARM gehts so:

load:
  ldrb r0, [r0, r1, LSL #1]
  bx lr

1 Instruktion, 2 Takte. Auch so einfach auf dem AVR?

[Dr. Sommer (Gast)]

PS:

Dr. Sommer schrieb:
> Auf dem ARM gehts so:

Das funktioniert dank der komplizierten Architektur des ARM natürlich 
auch unabhängig davon, ob "arr" im Flash, RAM, externen RAM, Backup-RAM, 
Peripherie-Registern, EEPROM, ... ist, und unabhängig davon ob es über 
oder unter der 64KiB Grenze des Speichers ist. Geht das auf dem AVR auch 
so einfach?

[Moby A. (moby-project)]

Dr. Sommer schrieb:
> equ GPIOD, 0x40020C00
>
> // Initialisiere Pin PD15
> ldr r0, = GPIOD
> mov r1, (1 << 30)
> str r1, [r0, #0]
>
> // Setze Pin PD15
> mov r1, (1 << 15)
> str r1, [r0, #18]

Hier gings erstens um die Vorinitialisierung, um überhaupt auf den Pin 
so zugreifen zu können! Und zweitens ist sbi DDRA,0 + sbi PORTA,0 nach 
wie vor um Größenordnungen einfacher, um gerade mal einen Pin zu setzen.

> ganz ohne Bank-Umschaltung (wie bei AVR's mit > 64 KiB
> Speicher),

Wer braucht schon soviel bei typischen 8-Bit Programmen... Und ja, bei 
größerem Speicherbedarf ist 32Bit ARM im Vorteil und anzuraten, hat ja 
gar keiner bestritten.

> Spezial-Instruktionen je nach Speicher (wie LPM vs LD). Ist
> so im Endeffekt sogar einfacher.

Da geb ich Dir Recht. Was aber ist dieses Tröpfchen Einfachheit schon im 
komplexen ARM-Meer ;-)

> Achja, von wegen Einfachheit: Programmiere mal diese C-Funktion in
> AVR-Assembler:uint32_t shift (uint32_t x, uint32_t y) {
>   return x << y;
> }
>
> Im ARMv7M-Assembler sieht's so aus:shift:
>   lsl r0, r1
>   bx lr
> Na, ists auf dem AVR auch so einfach? Und auch so schnell (1 Takt)?

Nö. Ist halt ein 32-Bit Vorteil. Anwendungen die das brauchen dürfen 
gern mit ARM vorlieb nehmen.

Moby A. schrieb
> Alles Reiner Masochismus, zumindest wenns die Anwendung (oder der Boss)
> nicht erfordert ;-)

Dabei bleibts, auf jeden Fall mal für Portinitialisierungen und MSR ohne 
große Datenmengen und Berechnungen, die von 32-Bit Power abhängig wären.

[Dr. Sommer (Gast)]

Moby A. schrieb:
> Hier gings erstens um die Vorinitialisierung
Das ist die Vortinitialisierung. Deswegen steht das auch im Kommentar.

Moby A. schrieb:
> nach
> wie vor um Größenordnungen einfacher, um gerade mal einen Pin zu setzen.
1 Instruktion weniger = Größenordnungen? Aha. Beim AVR funktioniert das 
aber so auch nur mit den unteren Peripherie-Registern.

Moby A. schrieb:
> Wer braucht schon soviel bei typischen 8-Bit Programmen...
Offenbar genug, dass es sich lohnt so etwas zu produzieren.

Moby A. schrieb:
> Da geb ich Dir Recht. Was aber ist dieses Tröpfchen Einfachheit schon im
> komplexen ARM-Meer ;-)
Dies ist sogar ein großer Vorteil! Ein paar mehr Register initialisieren 
zu müssen stört mich nicht, aber von jeder Funktion eine *_P Variante 
schreiben zu müssen, damit man auf "progmem"-Variablen zugreifen kann 
(printf_P usw.), ist doch ein großer Aufwand.

Moby A. schrieb:
> Nö. Ist halt ein 32-Bit Vorteil.
Und somit ein Vorteil von ARM über AVR.

Moby A. schrieb:
> Dabei bleibts
Es bleibt dabei, dass ARM mächtiger und einfacher ist, und die Frickelei 
mit den winzigen AVR-8-Dingern reine Quälerei - wo jeder 
Speicherzugriff, jede Pointer-Arithmetik und jedes "x << y" potentiell 
kompliziert ist.

[Moby A. (moby-project)]

Dr. Sommer schrieb:
> Das ist die Vortinitialisierung. Deswegen steht das auch im Kommentar.

Schön. Kann ich jetzt nicht nachprüfen. Trotzdem sieht jeder Blinder um 
wieviel einfacher die AVR-Formulierung ist.

> Beim AVR funktioniert das
> aber so auch nur mit den unteren Peripherie-Registern.

Das langt öfter als man glaubt ;-) Der Mehraufwand mit IN/OUT bzw. 
LDS/STS hält sich in allen anderen Fällen auch in Grenzen.

> Offenbar genug, dass es sich lohnt so etwas zu produzieren.

Stellt niemand in Frage. AVRs lohnen sich auch genug, um aktuell ca. 600 
Derivate davon zu produzieren ;-)

> Dies ist sogar ein großer Vorteil! Ein paar mehr Register initialisieren
> zu müssen stört mich nicht, aber von jeder Funktion eine *_P Variante
> schreiben zu müssen, damit man auf "progmem"-Variablen zugreifen kann
> (printf_P usw.), ist doch ein großer Aufwand.

Juckt mich im von mir favorisierten Asm samt verwendeter AVRs weniger.

> Es bleibt dabei, dass ARM mächtiger

Ja.

> und einfacher ist

Nein.

> und die Frickelei
> mit den winzigen AVR-8-Dingern reine Quälerei

Bei größeren Datenmengen und Berechnungen.

> wo jeder Speicherzugriff, jede Pointer-Arithmetik

Ach woher denn. Mir reichen die Adressierungsarten.

> und jedes "x << y" potentiell
> kompliziert ist.

Na ja, Shiftoperationen hat auch der AVR auf Lager, was ist daran 
kompliziert?

[Dr. Sommer (Gast)]

Moby A. schrieb:
> Schön. Kann ich jetzt nicht nachprüfen. Trotzdem sieht jeder Blinder um
> wieviel einfacher die AVR-Formulierung ist.
Schau ins Datenblatt. Ich finds auf jeden Fall niedlich, wie du das 
Vorhandensein der SBI/CBI Instruktionen als so gigantischen Vorteil 
betrachtest, was wohl alle mächtigen ARM-Instruktionen aufwiegen soll.

Schau mal, extra für dich: Durch Verwendung der Bit-Banding Regionen 
kann man sich sogar sbi/cbi Makros definieren, die genauso wie beim AVR 
funktionieren:

.syntax unified

.equ GPIOD_MODER,  0x40020C00
.equ GPIOD_BSRR,  0x40020C18
.equ GPIOD_ODR,    0x40020C14

.macro sbi  REG:req, bit:req
  push {r0, r1}
  ldr r0, =(0x42000000 + ((\REG-0x40000000) * 32) + (\bit * 4))
  mov r1, 1
  str r1, [r0]
  pop {r0, r1}
  .endm

.macro cbi  REG:req, bit:req
  push {r0, r1}
  ldr r0, =(0x42000000 + ((\REG-0x40000000) * 32) + (\bit * 4))
  mov r1, 0
  str r1, [r0]
  pop {r0, r1}
  .endm


// Setze PD15 als Ausgang
sbi GPIOD_MODER, 30

// Schalte PD15 ein
sbi GPIOD_ODR, 15

// Schalte PD15 aus
cbi GPIOD_ODR, 3

Immer noch ein Meer aus Komplexität? Funktioniert so sogar mit allen 
Peripherie-Registern, nicht nur mit den unteren. Braucht zwar ein paar 
Takte mehr, aber die ARM's sind ja auch nicht nur auf ein paar müde MHz 
limitiert wie die AVRs. Wenn's schneller gehen soll, kann man den 
Zugriff immer noch "manuell" machen um sich einige überflüssige Zugriffe 
zu sparen - oder einfach C verwenden, denn der Compiler macht das alles 
automatisch.

Moby A. schrieb:
> Juckt mich im von mir favorisierten Asm samt verwendeter AVRs weniger.
Wie schreibst du denn da Funktionen, die z.B. einen string in einem 
anderen string suchen? Da brauchst du auch 4 Varianten - Eine wo beide 
Parameter-Strings im Flash sind, eine wo String1 im Flash und String2 im 
RAM ist, usw.

Moby A. schrieb:
> Na ja, Shiftoperationen hat auch der AVR auf Lager, was ist daran
> kompliziert?
Wenn das "y" variabel ist. Dann brauchst du eine Schleife, da der AVR 
vor lauter Einfachheit keinen Barrel-Shifter hat.

Moby A. schrieb:
> Ach woher denn. Mir reichen die Adressierungsarten.
Ist ja schön dass deine Blinki-Programme damit auskommen, aber nerv doch 
nicht jeden im Forum damit. Sehr viele Programme verwenden komplexere 
Datenstrukturen (wie in meinem Beispiel, ein uint16_t -Array) oder gar 
structs, da hilft die Offset-Addressierung und die einfache 
Pointer-Arithmetik doch gewaltig.

[Moby A. (moby-project)]

Dr. Sommer schrieb:
> das
> Vorhandensein der SBI/CBI Instruktionen als so gigantischen Vorteil
> betrachtest, was wohl alle mächtigen ARM-Instruktionen aufwiegen soll.

Hier wiegt das eine nicht das andere auf. Es ist nur so, daß die 
Kehrseite der ARM-Mächtigkeit ARM-Komplexität heißt. Deshalb kannst Du 
zwar auch mit

> Durch Verwendung der Bit-Banding Regionen
> kann man sich sogar sbi/cbi Makros definieren

die Einfachheit des AVRs nachbilden, ich nehm dafür aber lieber gleich 
das Original und erspare mir solche intellektuellen Kopfstände.

> Wie schreibst du denn da Funktionen, die z.B. einen string in einem
> anderen string suchen? Da brauchst du auch 4 Varianten

In aller Regel sucht man einen String im RAM in einer Flash-Stringliste.
Ansonsten wird RAM beim AVR gespart, bzw. er schränkt den Einsatzbereich 
der AVRs ein. Aber keine Sorge, er ist immer noch groß genug ;-)

> Wenn das "y" variabel ist. Dann brauchst du eine Schleife, da der AVR
> vor lauter Einfachheit keinen Barrel-Shifter hat.

Nett. Aber man kann nicht alles haben. Für die paar Rechenoperationen 
gehts auch mit den AVR-Shiftbefehlen.

> Ist ja schön dass deine Blinki-Programme damit auskommen

Damit kommen Millionen AVR-Anwendungen z.T. recht komplexer Natur aus.

> Sehr viele Programme verwenden komplexere
> Datenstrukturen (wie in meinem Beispiel, ein uint16_t -Array) oder gar
> structs, da hilft die Offset-Addressierung und die einfache
> Pointer-Arithmetik doch gewaltig.

Absolut. Dann handeln sie aber meist auch größere Datenmengen- dafür ist 
Sinn und Zweck eines ARM natürlich unstrittig.

[Schlaumeier (Gast)]

Moby A. schrieb:
> Dr. Sommer schrieb:
>> Das ist die Vortinitialisierung. Deswegen steht das auch im Kommentar.
>
> Schön. Kann ich jetzt nicht nachprüfen. Trotzdem sieht jeder Blinder um
> wieviel einfacher die AVR-Formulierung ist.

Für Dich ist es einfacher, weil Du AVR-Assembler bereits kennst. Für 
mich, der noch nie AVR oder Arm in Assembler programmiert hat, ist der 
Unterschied marginal. Merkst Du, wie subjektiv Deine Aussagen sind?

btw, wolltest Du nicht aufhören, in ARM-threads das Hohelied des 
AVR-Assemblers zu singen, nachdem Du vor nicht allzu langer Zeit in 
einem ellenlangen thread deutlich geschlagen wurdest?

Und wollten nicht Moderatoren gnadenlos Deine AVR-ASM-Kommentare in 
ARM-threads löschen?

Die Welt ist vergeßlich ...

[Moby A. (moby-project)]

Schlaumeier schrieb:
> btw, wolltest Du nicht aufhören, in ARM-threads das Hohelied des
> AVR-Assemblers zu singen,

Hier gehts gerade um die viel einfachere AVR GPIO-Konfiguration im 
Vergleich zum ARM. An der viel einfacheren AVR-Konfiguration gibts nix 
zu deuteln. Genausowenig daran, daß diese Dinge mit Asm schneller/kürzer 
zu Papier gebracht sind. Zumindest beim AVR ;-)

[Schlaumeier (Gast)]

Moby A. schrieb:
> Hier gehts gerade um die viel einfachere AVR GPIO-Konfiguration im
> Vergleich zum ARM.

Eröffnungspost:

> STM32F103 GPIO

ucc schrieb:
> Ich habe ein Projekt geöffnet in Keil und will die Ports A-G
> initialisieren. Aber habe keine Ahnung wo ich ansetzen soll. Wie geht
> das denn? Lese die Reference Manuel und ferstehe nicht viel. Weiss das
> ich einen Cock brauche auf, output stellen muss. Aber wie? Hat jemand
> codebeispiel?


Nö, um AVR gehts hier nicht ...

[W.G. (Gast)]

Moby A. schrieb:
> Hier gehts gerade um die viel einfachere AVR GPIO-Konfiguration im
> Vergleich zum ARM.

Mehr als Data Direction und selten Pullups gibt es ja da auch nicht zu 
konfigurieren. Der ARM hat halt ganz andere Möglichkeiten (mehrere Clock 
Domains, Slew Rate, Pullup, Pulldown, ...) die konfiguiert werden 
müssen. Ist eine andere Liga, darum andere Anforderungen

Moby A. schrieb:
> An der viel einfacheren AVR-Konfiguration gibts nix
> zu deuteln.

Das ist ein Vergleich Äpfel mit Birnen. Dass sich die 
Steuerung/Bedienung von einem Fahrraddynamo erheblich von der eines 
Kernkraftwerkes unterscheidet ist doch klar. Trotzdem kommt bei beiden 
Strom raus. Das willst du doch auch nicht vergleichen.

Moby A. schrieb:
> Genausowenig daran, daß diese Dinge mit Asm schneller/kürzer
> zu Papier gebracht sind. Zumindest beim AVR ;-)

Mal abgesehen davon, dass du als ASM Programmierer ausschließlich in 
kurzen Codesequenzen besser bist als ein C Compiler, ist ASM einfach 
outdated. Es mag einige kleine Randgebiete geben in denen ASM 
Programmierung notwendig ist. (Bitte nenne mir welche). Aber im Großen 
und Ganzen ist das eine (verständliche) Verwehrung gegen den 
Fortschritt. Genau so wie heutige Programmierer Arduino als "Laster" 
sehen, so zeigt es den Fortschritt. Klar ist Arduino schlecht gemacht 
(Debugging, teilw. Ineffizienz, nur wenige Anwendungszenarien abgedeckt) 
aber auf die Dauer werden wir uns alle damit anfreunden, dass es fertige 
Funktionen (der PC Programmierer nennt das API) gibt mit denen man 
zeiteffizient den Controller programmieren kann. Wenn es nicht um eine 
Hobbyentwicklung geht, dann ist Geld (=Zeit) alles. Niemand schreibt 
seinen eigenen Ethernet-Stack mehr selbst, der Code muss portabel mit 
einem HAL gestaltet sein, ... Versteh mich nicht falsch, ich habe früher 
viel mit Assembler gemacht und auch komplexe Programme wie Morsedecoder 
auf VGA Monitor mit Touch und integrierter Funkgerätfernbedienung über 
RS-232. Aber es lohnt sich eben leider nicht. Es ist sehr gut und 
wichtig für das Verständnis / Lernen aber es ist einfach vom Zeitaufwand 
nicht tragbar. Es sind einfach andere Zeiten heutzutage - Stichwort 
Semihosting usw...

[Moby A. (moby-project)]

Schlaumeier schrieb:
> Nö, um AVR gehts hier nicht ...

Den Fokus scharf aufs ursprüngliche Thema zu halten gelingt in den 
wenigsten Threads. Warum auch? Zuweilen öffnen erst die Randaspekte neue 
Horizonte ;-)

[Schlaumeier (Gast)]

Moby A. schrieb:
> Den Fokus scharf aufs ursprüngliche Thema zu halten gelingt in den
> wenigsten Threads.

Da magst Du im Allgemeinen recht haben.

Du hast hier aber absichtlich, vorsätzlich den thread gekapert:

Moby schrieb:
> W.S. schrieb:
>> Kraft hast, es verstehend zu lesen, dann befasse dich mit irgend etwas
>> anderem.
>
> Richtig. Zum Beispiel mit einfachen AVRs, um damit viel schneller ans
> Ziel zu kommen. ARM-Konfiguritis muß ja nicht jedermans Leidenschaft
> sein ;-)

Merke: Du bist ein ganz übler Schwätzer, denn Du stehst nicht zu Deinem 
Wort.

[Bernd K. (prof7bit)]

Moby A. schrieb:
> GPIO-Konfiguration im
> Vergleich zum ARM.

Moby, es gibt bei ARM gar keine GPIO-Konfiguration, hast Du das gewusst? 
Einfacher gehts nimmer! GPIO ist nämlich nicht Teil des ARM-Cores.

Es gibt nur die GPIO-Einheiten die die unterschiedlichen Hersteller in 
die unterschiedlichen Controller einbauen und da gibt es bei den 
kleineren ARMs auch welche die genauso simpel funktionieren wie bei AVR. 
Man muss nicht immer die überkomplexe Peripherie die STMicroelectronics 
gerne in ihre Controller einbaut stellvertretend für alle ARM-Controller 
heranziehen, man kann auch genausogut klein anfangen, zum Beispiel mit 
nem Freescale MKE04Z8, da ist zum Beispiel die GPIO-Einheit per Default 
ab Reset schon eingeschaltet, man muss nur noch Datenrichtung auf 
Ausgang setzen (ein Register, ein Bit pro Pin, genau wie AVR) und schon 
kann man anfangen zu blinken.

[Schlaumeier (Gast)]

W.G. schrieb:
> Mal abgesehen davon, dass du als ASM Programmierer ausschließlich in
> kurzen Codesequenzen besser bist als ein C Compiler, ist ASM einfach
> outdated. Es mag einige kleine Randgebiete geben in denen ASM
> Programmierung notwendig ist.

Das haben wir mit Moby in gefühlt zehntausenden posts bis zum Erbrechen 
durch. Bitte nicht neu beginnen ...

[Moby A. (moby-project)]

W.G. schrieb:
> Der ARM hat halt ganz andere Möglichkeiten (mehrere Clock
> Domains, Slew Rate, Pullup, Pulldown, ...) die konfiguiert werden
> müssen.

... und die das Ganze komplexer machen. Dazu hatte ich ja schon 
festgestellt: Bitte nur, wenns die Anwendung (oder der Boss) verlangt.

> Das ist ein Vergleich Äpfel mit Birnen. Dass sich die
> Steuerung/Bedienung von einem Fahrraddynamo erheblich von der eines
> Kernkraftwerkes unterscheidet ist doch klar. Trotzdem kommt bei beiden
> Strom raus. Das willst du doch auch nicht vergleichen.

Nein. Doch siehe sinngemäß oben: Die Dinge für ihren Zweck so einfach 
wie möglich halten sollte der Anspruch sein. Und einen konkreten Zweck 
gab der TO nicht vor.

> Versteh mich nicht falsch, ich habe früher
> viel mit Assembler gemacht und auch komplexe Programme wie Morsedecoder
> auf VGA Monitor mit Touch und integrierter Funkgerätfernbedienung über
> RS-232. Aber es lohnt sich eben leider nicht.

Finde ich prima. Allerdings fällt unser Resümee da unterschiedlich aus 
;-)

[Moby A. (moby-project)]

Bernd K. schrieb:
> man kann auch genausogut klein anfangen, zum Beispiel mit
> nem Freescale MKE04Z8, da ist zum Beispiel die GPIO-Einheit per Default
> ab Reset schon eingeschaltet, man muss nur noch Datenrichtung auf
> Ausgang setzen (ein Register, ein Bit pro Pin, genau wie AVR) und schon
> kann man anfangen zu blinken.

Interessant. Hab ich noch nicht gewusst.
Mir langt aber schon ein kurzer Blick aufs >600 seitige "KE04 Sub-Family 
Reference Manual" um zu erkennen, daß man im Zweifelsfall besser bei AVR 
bleiben sollte ;-)

[Jasson J. (jasson)]

>Hier gings erstens um die Vorinitialisierung, um überhaupt auf den Pin
>so zugreifen zu können!

Der TE hat mit Sicherheit mehr vor, als einen Pin zu initialisieren. 
Wenn das das Ziel ist, hättest du ihm auch einen Schalter vorschlagen 
können. Der ist NOCH einfacher als AVR.

[Schlaumeier (Gast)]

Bernd K. schrieb:
> Moby, es gibt bei ARM gar keine GPIO-Konfiguration, hast Du das gewusst?
> Einfacher gehts nimmer! GPIO ist nämlich nicht Teil des ARM-Cores.

Es ist doch immer wieder lustig anzusehen, wie Techniker mit der "Mach 
mir ungefragt den Erklärbär"-Masche geködert werden ... :-)

Dass Du als viel gesehener Forumschreiber mit vollem Wissen einem Troll 
auf den Leim gehst, weißt Du aber?

[Moby A. (moby-project)]

Jasson J. schrieb:
> hättest du ihm auch einen Schalter vorschlagen
> können. Der ist NOCH einfacher als AVR.

Nun, man kann es mit E wie einfach auch E wie extrem übertreiben.
Das wär sicher nicht mehr hilfreich ;-)

[Moby A. (moby-project)]

Schlaumeier schrieb:
> Dass Du als viel gesehener Forumschreiber mit vollem Wissen einem Troll
> auf den Leim gehst, weißt Du aber?

Mach Dir keine unnötigen Sorgen lieber Schlaumeier.
Hab gerade eingesehen, daß ich meinen Nachmittag jetzt besser sinnvoller 
verbringe. Meine ernsthaften ernstgemeinten Bedenken hab ich schließlich 
zum Ausdruck gebracht ;-)

[Schlaumeier (Gast)]

Moby A. schrieb:
> Meine ernsthaften ernstgemeinten Bedenken hab ich schließlich
> zum Ausdruck gebracht ;-)

Jaja. Ich übersetze mal: Du hast Deine Trollerei schon mit einem 
Erfolgserlebnis gekrönt, schließlich sind Dir gleich zwei, nein drei 
Erklärbären auf den Leim gegangen ...

[Moby A. (moby-project)]

Schlaumeier schrieb:
> Deine Trollerei

Der Troll bist Du, weil Du nicht das Thema sondern nur den 
(zugegebenermaßen unbequemen) Moby im Fokus hast ;-)

[Schlaumeier (Gast)]

Moby A. schrieb:
> Der Troll bist Du, weil Du nicht das Thema sondern nur den
> (zugegebenermaßen unbequemen) Moby im Fokus hast ;-)

Ich übersetze mal: "Haltet den Dieb, er hat mein Messer im Rücken ... "

[Moby A. (moby-project)]

Naja als Übersetzer bist Du zwar grottenschlecht, aber  Deinem Nicknamen 
machst Du alle Ehre, inklusive einem gewissen Unterhaltungswert ;-)
Schönen Sonntag noch.

[Schlaumeier (Gast)]

Moby A. schrieb:
> als Übersetzer bist Du zwar grottenschlecht

Würde ich an Deiner Stelle auch schreiben.

Moby A. schrieb:
> inklusive einem gewissen Unterhaltungswert

... den ich im Gegensatz zu Dir habe ...

[W.S. (Gast)]

Bernd K. schrieb:
> zum Beispiel mit
> nem Freescale MKE04Z8, da ist zum Beispiel

Hmm.. da hast du aber versehentlich ein herzlich übles Beispiel 
hervorgekramt. Die MKE Reihe hat m.W. nämlich keine PORTx_PCRy 
Register, wo man in aller Gemütsruhe einstellen kann, was für eine 
Funktion so ein Portpin denn haben soll. Für mich ist sowas die absolute 
Krätze. Stell dir vor, du müßtest den Chip aus einem beliebigen Zustand 
heraus re-initialisieren. Da müßtest du für jedes Pin sämtliche 
möglichen Peripherie-Cores durchgehen.

Ursprünglich hatte ich mich durchaus für diese Reihe interessiert, weil 
sie Li-Akku-tolerant ist, aber als ich genau DIESEN Umstand in voller 
Schärfe erkannt habe, ist's mir vergangen.

Abgesehen mal davon sollte es für einen Programmierer kein 
unüberwindliches Thema sein, den betreffenden Takt freizuschalten, die 
Portpin-Verwendung festzulegen und bei GPIO-Pins die Richtung 
festzulegen - oder alternativ sich nen anderen µC suchen.

Auf der letzten Embedded wurden doch Schachteln mit ATtiny drin 
verteilt, gelle?

W.S.

[Moby A. (moby-project)]

Moby schrieb:
> W.S. schrieb:
>> Kraft hast, es verstehend zu lesen, dann befasse dich mit irgend etwas
>> anderem.
>
> Richtig. Zum Beispiel mit einfachen AVRs, um damit viel schneller ans
> Ziel zu kommen. ARM-Konfiguritis muß ja nicht jedermans Leidenschaft
> sein ;-)

W.S. schrieb:
> Auf der letzten Embedded wurden doch Schachteln mit ATtiny drin
> verteilt, gelle?

Sag ich doch, DIE Alternative zu

W.S. schrieb:
> absolute
> Krätze.

[Schlaumeier (Gast)]

Moby A. schrieb im Beitrag #4486633 um 14:37:
> ... weiteren Unfug ...

Moby A. schrieb:
> Hab gerade eingesehen, daß ich meinen Nachmittag jetzt besser sinnvoller
> verbringe.

Na, hast wohl nichts sinnvolles zu tun?