huhu,
we hat diesen link rumliegen, finde diesen nicht mehr?
war aus/von frankreich/bildungseinrichtung über stm32 bare metal
examples.
ich glaube, der wurde hier auch mal erwähnt und hatte viele gute
beispiele, bzgl. der gesamten hw periphery dma,adc,tmr, ...
merci!
Lauter magische Zahlen. Genau so sollte man nicht programmieren, da
gehören die Definitionen (und Macros) vom Hersteller rein. Denn nur dann
wäre das für einen Menschen auch lesbar.
Hint: Wie lange würde es dauern, hier einen Zahlendreher zu finden..?
Eben.
Jim M. schrieb:> Hui, das ist ja mal fürchterlicher Code!
Du wolltest bare-metal, du bekommst bare-metal. Ich glaube, in diesem
Beispiel ging es allerdings nur darum, die IDE und die HW mit möglichst
wenig Abhängigkeiten ans Laufen zu bekommen.
Vielleicht gefallen Dir meine Beispiele besser:
http://stefanfrings.de/stm32/index.html
Sie basieren auf CMSIS, sind aber nicht aus Frankreich.
In den folgenden Kapiteln nutzt der Professor übrigens ebenfalls die
CMSIS.
Ich weiß, die Seite ist schwer zu finden. Was ich seltsam finde, denn
dieses Tutorial ist wesentlich umfangreicher als meine Seite und meine
Seite findet man sehr leicht.
Ich schätze, dass er da irgend eine techniche Besonderheit auf der Seite
hat, der Google ganz viele Minuspunkte gibt.
Stefan ⛄ F. schrieb:> In den folgenden Kapiteln nutzt der Professor übrigens ebenfalls die> CMSIS.
Ja, aber die Pins werden immernoch mit Magic Numbers eingestellt.
Da hätte er im Kapitel GPIO ruhig eine schöne Pin Init Funktion
schreiben können.
Beispiel aus meinen Treibern:
1
// 4 Bits per Alternate Function
2
#define AFR_BITS 4U
3
#define AFR_MSK 0xFU
4
5
// 2 Bits per Function
6
#define DUALBIT_MSK 0b11U
7
#define BITSPERPIN 2U
8
9
// coding of mode Register from enum PioPinMode
10
#define ENUM_REGMODER_MSK 0b11000U
11
#define ENUM_REGMODER_POS 3U
12
// coding of MODE Bits
13
#define ENUM_BITMODER_MSK 0b11U
14
#define ENUM_BITMODER_POS 0U
15
// coding of slewrate
16
#define ENUM_OTYPE_MSK 0b100U
17
#define ENUM_OTYPE_POS 2U
18
// coding of pull resistors
19
#define ENUM_PUPDR_MSK 0b11
20
#define ENUM_PUPDR_POS 0
21
22
// how many pins in one AFR Register
23
#define AFR_PINS_PER_REG 8
24
25
// 2 part Register BSRR for SET/RESET
26
#define BSSR_SET_POS 0U
27
#define BSSR_RES_POS 16U
28
29
voidgpio_init(conststructgpio_pin*pin){
30
31
uint32_tpin_nbr=pin->nbr;
32
uint32_tbitPosDualBit=pin->nbr*BITSPERPIN;
33
if(pin_nbr>=16U){
34
return;
35
}
36
37
GPIO_TypeDef*gpio=pin->port;
38
enumgpio_modemode=pin->mode;
39
40
// Mode (Input, GP Out, Alternate function, Analog)
Stefan ⛄ F. schrieb:> Ich weiß, die Seite ist schwer zu finden. Was ich seltsam finde,> denn> dieses Tutorial ist wesentlich umfangreicher als meine Seite und meine> Seite findet man sehr leicht.>> Ich schätze, dass er da irgend eine techniche Besonderheit auf der Seite> hat, der Google ganz viele Minuspunkte gibt.
<Traum>Google bewertet den Inhalt und ein Tutorial mit so vielen magic
numbers bekommt berechtigterweise Minuspunkte</Traum>
<VT>Google muss in Frankreich Steuern zahlen</VT>
merciMerci schrieb:> sieht auch interessant aus!> gibt es da noch mehr zum bewundern, github, homepage,
Bisher nur hier:
Beitrag "ARM Cortex-M3/4/7 Faulthandler"
Auf meiner HP sind nur die alten AVR Projekte, da muss ich mal die
ganzen neuen Projekte mit STMs nachpflegen, aber Faulheit siegt immer!
Github hab ich nicht, meine Projekte liegen nicht auf Drittservern,
sondern bei mir.
Das ist aus historischen Gründen noch ein SVN.
Auch hier siegt die Faulheit bei der Umstellung auf Gitlab.
Weil: es funktioniert ja!
Mw E. schrieb:> Das ist aus historischen Gründen noch ein SVN.> Auch hier siegt die Faulheit bei der Umstellung auf Gitlab.> Weil: es funktioniert ja!
Nicht nur Faulheit. Jedes neue Arbeitsmittel bringt potentiell neue
Probleme mit sich. Auf jeden Fall neuen Aufwand für die Migration und
den Umgang damit zu lernen. Und für was?
Ich hab's zu Hause als Übung durchgezogen, weil ich der Vorarbeiter bin,
der das bald seinen Kollegen im Büro erklären muss. Wenn man mich
gefragt hätte: ich wäre bei Mercurial (oder SVN) geblieben. Aber die
strategischen Entscheidungen fällen letztendlich andere. Wenn der ganze
Nachwuchs GitHub will, nur die beiden Oldies nicht, dann ist klar, was
gemacht wird.
Stefan ⛄ F. schrieb:> ich wäre bei Mercurial (oder SVN) geblieben. Aber die> strategischen Entscheidungen fällen letztendlich andere. Wenn der ganze> Nachwuchs GitHub will, nur die beiden Oldies nicht, dann ist klar, was> gemacht wird.
ich habe auch erst mit mercurial für meine privaten projekte rumgemacht,
bin dann aber doch auf git umgestiegen weil, da gibt es tonnenweise lit.
und quasi jede ide unterstützt git. ausserdem wenn ich irgendwas aus
opensource will, dann muss ich git können. ich denke, für mercurial ist
zug eher weg.
ich steige auch gerade zu gitlab um ... und will dann auch dort mal eine
statische homepage bauen, aber noch blick ich nicht richtig durch.
SVN und Mercurial werden auch von fast allen IDEs unterstützt. Und
selbst wenn nicht, man braucht es nicht. Man hat ja noch die
Kommandozeile und zudem zahlreiche GUIs zur Wahl. Ich sehe keinen großen
Vorteil darin, alles krampfhaft in die IDE integrieren zu wollen. Je
mehr man sich darauf verlässt, umso abhängiger macht man sich.
Abhängigkeit von einer bestimmten IDE (egal welcher) ist schlimm. Das
steht in meiner No-Go Liste ganz weit oben.