Ich habe hier auf meinem FreeBSD einen arm-none-eabi GCC Port der schon
etwas angegraut ist.
Ich habe deshalb die aktuelle Toolchain Version 8-2018-q4-major selber
gebaut, was ein ziemlich längliches Verfaren war, weil die Shell-Scripte
doch etliche Bugs hatten und sinnloser Weise immer wieder von vorne
anfangen zu konfigurieren und zu kompilieren als gäbe es kein Make und
keine Depencies.
Wenig hilfreich ist auch das die Definitionen für sämtliche Interrupts
fehlen, die darf man sich dann selber ins Linkerscript oder
Startup-Assemblerfile häkeln..52 Stück... hmm....
Irgendwann bin ich doch mal fertig damit geworden und mein Programm an
dem ich herumbastele läuft nun sowohl auf der alten, also auch auf der
neuen Toolchain....so lange ich die Finger von strcpy() lasse, da ist
noch irgendwas faul und ich weiß nicht was.
in meinem Progrämmchen gibts diesen simplen code:
1
uint8_tdisp_buff[32];
2
[..]
3
strcpy((char*)disp_buff,"1234");
4
...
damit hängt sich das Programm auf, damit auch:
1
[..]
2
strcpy(obp,"lolo!\r\n");
3
USART3_PutString(obp);
4
[..]
..damit aber nicht:
1
uint8_tdisp_buff[32];
2
[..]
3
disp_buff[0]='1';
4
disp_buff[2]='2';
5
disp_buff[3]='3';
6
disp_buff[4]='4';
und damit auch nicht:
1
uint8_tdisp_buff[32];
2
[..]
3
char*mstrcpy(char*d,char*s)
4
{
5
while(*s)
6
*d++=*s++;
7
returnd;
8
}
9
[..]
10
mstrcpy((char*)disp_buff,"1234");
11
12
[..]
..und ich pople schon eine Weile dran herum ohne zu finden was lost ist.
Ehe jetzt nachfragen nach dem gesamten Code kommen..der wäre sinnlos.
Ich habs schon bis dahin eingegrenzt und code kommt noch..allerdings
Assembler. Das strcpy() aus der newlib sieht dann so aus:
1
08002550 <strcpy>:
2
8002550: e1a03000 mov r3, r0
3
8002554: e4d12001 ldrb r2, [r1], #1
4
8002558: e4c32001 strb r2, [r3], #1
5
800255c: e3520000 cmp r2, #0, 0
6
8002560: 1afffffb bne 8002554 <strcpy+0x4>
7
8002564: e12fff1e bx lr
8
9
08002568 <_init>:
Ich kann daran eigentlich gar nichts Falsches finden, gesetzt den Fall
dass r1 und r3 die Pointer zu den Strings enthalten. Ich kenne ARM Thumb
nicht, aber zumindest siehts nicht doof aus.
mstrcpy sieht so aus:
1
080005a6 <mstrcpy>:
2
80005a6: 3901 subs r1, #1
3
80005a8: f811 3f01 ldrb.w r3, [r1, #1]!
4
80005ac: b90b cbnz r3, 80005b2 <mstrcpy+0xc>
5
80005ae: 7800 ldrb r0, [r0, #0]
6
80005b0: 4770 bx lr
7
80005b2: f800 3b01 strb.w r3, [r0], #1
8
80005b6: e7f7 b.n 80005a8 <mstrcpy+0x2>
..keine Ahnung was das treibt, aber es funktioniert.
Die alte Version des Compilers mach sowas Schickes:
..aber da kommt bei mir der Maschinist mit der weißen Fahne raus. Das
funktioniert auch, aber mir ist unklar wie man das so lang machen kann.
Ich bastele das Ganze auf einer Bluepill, also einem STM32F103C8T6, die
Compiler Optionen sind
Fred schrieb:> Hast du mal die disassembly von deinem strcpy-Aufruf der nicht> funtkioniert? lass dir mal strlen("abcd") ausgeben
..da sieht man nicht viel..
1
5a: f24a 52a5 movw r2, #42405 ; 0xa5a5
2
5e: 4291 cmp r1, r2
3
60: d001 beq.n 66 <main+0x66>
4
62: f7ff fffe bl 2d0 <eeprom_init>
5
66: 6823 ldr r3, [r4, #0]
6
68: 4f31 ldr r7, [pc, #196] ; (130 <main+0x130>)
7
6a: 8818 ldrh r0, [r3, #0]
8
6c: f7ff fffe bl 190 <sevenseg_disp>
9
70: f44f 70fa mov.w r0, #500 ; 0x1f4
10
74: f7ff fffe bl 0 <main>
11
12
78: 492e ldr r1, [pc, #184] ; (134 <main+0x134>)
13
7a: 4638 mov r0, r7
14
7c: f7ff fffe bl 0 <strcpy>
15
16
80: 492c ldr r1, [pc, #176] ; (134 <main+0x134>)
17
82: 4638 mov r0, r7
18
84: f7ff fffe bl 406 <mstrcpy>
19
20
88: 7838 ldrb r0, [r7, #0]
21
8a: 463e mov r6, r7
22
8c: 3830 subs r0, #48 ; 0x30
23
8e: b283 uxth r3, r0
24
90: 7878 ldrb r0, [r7, #1]
25
92: 4c29 ldr r4, [pc, #164] ; (138 <main+0x138>)
26
94: 3830 subs r0, #48 ; 0x30
27
96: b280 uxth r0, r0
Rest mach ich Dir morgen, ich habs für heute satt.
Gruß,
Holm
Kannst du auf dem Target debuggen? Vielleicht geht irgendwas beim Aufruf
schief. Sonst könntest du durch den Assembler einzeln durchsteppen und
sehen was nicht funktioniert.
Holm T. schrieb:> Das strcpy() aus der newlib sieht dann so aus:>> 08002550 <strcpy>:> 8002550: e1a03000 mov r3, r0
Das ist "ARM"-Code, kein Thumb-Code. Den kann der Cortex-M nicht
ausführen und stürzt zurecht ab. Du hast die falsche C-Bibliothek
gelinkt bzw. die richtige Bibliothek falsch konfiguriert.
Holm T. schrieb:> Die alte Version des Compilers mach sowas Schickes:080023f4 <strcpy>:
Auch ARM-Code...
Holm T. schrieb:> ..aber da kommt bei mir der Maschinist mit der weißen Fahne raus. Das> funktioniert auch, aber mir ist unklar wie man das so lang machen kann.
Da war Loop Unrolling im Spiel (C-Library mit -O3 kompiliert?). Da das
ARM-Code ist kann das auf dem Cortex-M nicht funktionieren. Auf den
großen Cortex-A, für welche solcher Code ist, kann das die Performance
verbessern.
Holm T. schrieb:> ..keine Ahnung was das treibt, aber es funktioniert.
Weil das Thumb2-Code ist. Leicht (heuristisch) daran zu erkennen, dass
die meisten Instruktionen im Maschinencode (siehe Hex-Dump in der 2.
Spalte) 16bit, manche 32bit sind. Beim ARM-Code hingegen ist alles
32bit, und vieles fängt mit "E" an (für Condition Code .AL, "always").
Versuche mal auch beim Linken "-mthumb -mcpu=cortex-m3" zu übergeben,
damit der Linker weiß, welche Bibliothek er nehmen muss.
Holm T. schrieb:> Wenig hilfreich ist auch das die Definitionen für sämtliche Interrupts> fehlen, die darf man sich dann selber ins Linkerscript oder> Startup-Assemblerfile häkeln..52 Stück... hmm....
Normalerweise kopiert man sich die startup_stm32XX.S aus einem
Template/Beispiel-Projekt, da stehen die drin.
Niklas G. schrieb:> Holm T. schrieb:>> Das strcpy() aus der newlib sieht dann so aus:>>>> 08002550 <strcpy>:>> 8002550: e1a03000 mov r3, r0>> Das ist "ARM"-Code, kein Thumb-Code. Den kann der Cortex-M nicht> ausführen und stürzt zurecht ab. Du hast die falsche C-Bibliothek> gelinkt bzw. die richtige Bibliothek falsch konfiguriert.
Du kriegst einen Schmatz auf den Bauch das die Seele quietscht :-)
Die Maschinendefinition war zwar im Compiler Aufruf drin, allerdings
fehlte sie beim Lader.
.. es ist halt gut wenn man die Mnemonics kennt, die sind mir aber
vorläufig ein Buch mit 7 Siegeln. Wird schon noch werden..
>> Holm T. schrieb:>> Die alte Version des Compilers mach sowas Schickes:080023f4 <strcpy>:> Auch ARM-Code...
..ist aber komisch..weil das geht?
>>> Holm T. schrieb:>> ..aber da kommt bei mir der Maschinist mit der weißen Fahne raus. Das>> funktioniert auch, aber mir ist unklar wie man das so lang machen kann.>> Da war Loop Unrolling im Spiel (C-Library mit -O3 kompiliert?). Da das> ARM-Code ist kann das auf dem Cortex-M nicht funktionieren. Auf den> großen Cortex-A, für welche solcher Code ist, kann das die Performance> verbessern.
..es funktioniert aber, keine Ahnung was da los ist. Ich glaube Dir
schon..kann das sein das das falsch disassembliert ist?
>> Holm T. schrieb:>> ..keine Ahnung was das treibt, aber es funktioniert.> Weil das Thumb2-Code ist. Leicht (heuristisch) daran zu erkennen, dass> die meisten Instruktionen im Maschinencode (siehe Hex-Dump in der 2.> Spalte) 16bit, manche 32bit sind. Beim ARM-Code hingegen ist alles> 32bit, und vieles fängt mit "E" an (für Condition Code .AL, "always").>> Versuche mal auch beim Linken "-mthumb -mcpu=cortex-m3" zu übergeben,> damit der Linker weiß, welche Bibliothek er nehmen muss.>> Holm T. schrieb:>> Wenig hilfreich ist auch das die Definitionen für sämtliche Interrupts>> fehlen, die darf man sich dann selber ins Linkerscript oder>> Startup-Assemblerfile häkeln..52 Stück... hmm....>> Normalerweise kopiert man sich die startup_stm32XX.S aus einem> Template/Beispiel-Projekt, da stehen die drin.
Nö..sonst hätte ich sie da nicht nachtragen müssen. Da stehen die ersten
paar drin, bis SysTick_Handler, danach ist ein DEF_Handler definiert und
dann kommt da nichts mehr. Ich habe ne Weile gebraucht um zu realisieren
das ein Teil des Start Codes auf den Vector Adressen lag.
Hab vielen Dank!
funktioniert jetzt wie es sollte.
Gruß,
Holm
Holm T. schrieb:> .. es ist halt gut wenn man die Mnemonics kennt, die sind mir aber> vorläufig ein Buch mit 7 Siegeln. Wird schon noch werden..
Das Gemeine ist, dass die Mnemonics von ARM und Thumb2 teilweise
gleich/ähnlich sind. Der Unterschied wird erst am Maschinencode
sichtbar.
Holm T. schrieb:> ..es funktioniert aber, keine Ahnung was da los ist.
Dann hast du das falsche Binary ausprobiert, die Funktion wird nie
aufgerufen, das falsche Disassembly gepostet... Das kann so auf keinen
Fall laufen.
Holm T. schrieb:> kann das sein das das falsch disassembliert ist?>>
Nö, der Maschinencode ist definitiv ARM-Code, egal was der Disassembler
da draus macht.
Holm T. schrieb:> Nö..sonst hätte ich sie da nicht nachtragen müssen.
Dann hast du die falsche Datei erwischt. Das gibts auch schon alles
fertig. Du musst halt eines der ST-Beispiele/Templates für den STM32F103
nehmen, oder per STM32CubeMX generieren. Der Compiler kann kaum
ISR-Vektor-Definitionen für die Zigtausend verschiedenen ARM-Prozessoren
mitliefern, daher muss man das selbst einbinden.
Niklas G. schrieb:> Holm T. schrieb:>> .. es ist halt gut wenn man die Mnemonics kennt, die sind mir aber>> vorläufig ein Buch mit 7 Siegeln. Wird schon noch werden..>> Das Gemeine ist, dass die Mnemonics von ARM und Thumb2 teilweise> gleich/ähnlich sind. Der Unterschied wird erst am Maschinencode> sichtbar.>> Holm T. schrieb:>> ..es funktioniert aber, keine Ahnung was da los ist.>> Dann hast du das falsche Binary ausprobiert, die Funktion wird nie> aufgerufen, das falsche Disassembly gepostet... Das kann so auf keinen> Fall laufen.>> Holm T. schrieb:>> kann das sein das das falsch disassembliert ist?>>>>> Nö, der Maschinencode ist definitiv ARM-Code, egal was der Disassembler> da draus macht.>> Holm T. schrieb:>> Nö..sonst hätte ich sie da nicht nachtragen müssen.>> Dann hast du die falsche Datei erwischt. Das gibts auch schon alles> fertig. Du musst halt eines der ST-Beispiele/Templates für den STM32F103> nehmen, oder per STM32CubeMX generieren. Der Compiler kann kaum> ISR-Vektor-Definitionen für die Zigtausend verschiedenen ARM-Prozessoren> mitliefern, daher muss man das selbst einbinden.
Das war aus dem Beispiel/Template:
Keine Ahnung ob das automagisch expandiert werden sollte..
gcc-arm-none-eabi/samples/startup/startup_ARMCM0.S
gcc-arm-none-eabi/samples/startup/startup_ARMCM3.S
gcc-arm-none-eabi/samples/startup/startup_ARMCM7.S
gcc-arm-none-eabi/samples/startup/startup_ARMCM4.S
1
/* File: startup_ARMCM3.S
2
* Purpose: startup file for Cortex-M3 devices. Should use with
3
* GCC for ARM Embedded Processors
4
* Version: V2.0
5
* Date: 16 August 2013
6
*
7
/* Copyright (c) 2011 - 2013 ARM LIMITED
8
9
All rights reserved.
10
Redistribution and use in source and binary forms, with or without
11
modification, are permitted provided that the following conditions are met:
12
- Redistributions of source code must retain the above copyright
13
notice, this list of conditions and the following disclaimer.
14
- Redistributions in binary form must reproduce the above copyright
15
notice, this list of conditions and the following disclaimer in the
16
documentation and/or other materials provided with the distribution.
17
- Neither the name of ARM nor the names of its contributors may be used
18
to endorse or promote products derived from this software without
19
specific prior written permission.
20
*
21
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
22
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
23
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
24
ARE DISCLAIMED. IN NO EVENT SHALL COPYRIGHT HOLDERS AND CONTRIBUTORS BE
25
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
26
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
27
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
28
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
29
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
30
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
Nico W. schrieb:> Bis zum SysTick sind die Cortexe auch alle gleich. Daher "fehlt" der> Rest.
Kann man so auch wieder nicht sagen, es gibt unterschiedliche Sample
Files,
aber die Interrupts sind halt nicht drin.
Gruß,
Holm
Holm T. schrieb:> Das war aus dem Beispiel/Template:
Wo hast du das her? Das ist von ARM allgemein für Cortex-M3, da sind
natürlich keine STM32F103-spezifischen Dinge drin.
Im STM32CubeF1 (wird auch durch STM32CubeMX installiert) gibt es einen
Ordner
STM32Cube_FW_F1_V1.7.0/Drivers/CMSIS/Device/ST/STM32F1xx/Source/Template
s/gcc/
mit Dateien Startup-Codes für die diversen STM32F1, z.B.
startup_stm32f103xb.s, siehe Anhang. Linker-Scripte sind auch dabei.
Niklas G. schrieb:> Holm T. schrieb:>> Das war aus dem Beispiel/Template:>> Wo hast du das her? Das ist von ARM allgemein für Cortex-M3, da sind> natürlich keine STM32F103-spezifischen Dinge drin.>> Im STM32CubeF1 (wird auch durch STM32CubeMX installiert) gibt es einen> Ordner>> STM32Cube_FW_F1_V1.7.0/Drivers/CMSIS/Device/ST/STM32F1xx/Source/Template s/gcc/>> mit Dateien Startup-Codes für die diversen STM32F1, z.B.> startup_stm32f103xb.s, siehe Anhang. Linker-Scripte sind auch dabei.
..hatte ich oben verlinkt, das ist Bestandteil der Toolchain:
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
...die ich für FreeBSD portiert habe.
Ich arbeite unter FreeBSD mit den klassischen Programmiertools und eher
ich irgend ein Cube Zeugs baue, baue ich doch erst mal einen
funktionierenden gcc samt newlib und binutils...
Ich hätte ja auch nicht genörgelt wenn da irgendwelche hooks für Default
Handler installiert gewesen wären, so landete der Code aber out of the
box dort, wo eigentlich die Vectortabelle sein sollte. Dabei gibts da
Programmbeispiele für CM3 die funktionieren sollten..printf mit
semihosting etc.. aber ohne jeden Interrupt.
Ich werde mir das Cube Zeugs mal ansehen.
Gruß,
Holm
Holm T. schrieb:> ..hatte ich oben verlinkt, das ist Bestandteil der Toolchain:
Achso. Ja, da sind nur allgemeine Sachen für Cortex-M drin, aber
natürlich keine Startupcodes, Linker-Scripte, Libraries usw. für die
Unzahl an ARMs.
Holm T. schrieb:> und eher> ich irgend ein Cube Zeugs baue, baue ich doch erst mal einen> funktionierenden gcc samt newlib und binutils...
Da gibts zum Glück nix zu bauen, dank Java läuft STM32CubeMX überall.
Die Bibliotheken STM32CubeFxx muss man einfach nur runterladen.
Holm T. schrieb:> Ich hätte ja auch nicht genörgelt wenn da irgendwelche hooks für Default> Handler installiert gewesen wären, so landete der Code aber out of the> box dort, wo eigentlich die Vectortabelle sein sollte.
Aber wie soll das denn sonst gehen? Die Vektor-Tabelle hat bei jedem
Controller eine andere Größe, manchmal sogar Lücken, manche brauchen
noch einen speziellen "Magic Wert" - wie soll das generische Beispiel
die alle abdecken?
Niklas G. schrieb:
[..]
> Aber wie soll das denn sonst gehen? Die Vektor-Tabelle hat bei jedem> Controller eine andere Größe, manchmal sogar Lücken, manche brauchen> noch einen speziellen "Magic Wert" - wie soll das generische Beispiel> die alle abdecken?
..mit einem selbst zu erstellenden Header und einem Template?
Gruß,
Holm
Holm T. schrieb:> ..mit einem selbst zu erstellenden Header und einem Template?
Beim vorgegebenen Startup-Code kannst du doch die fehlenden Handler
ergänzen oder Platz lassen. Oder wie meinst du das?
Niklas G. schrieb:> Holm T. schrieb:>> ..mit einem selbst zu erstellenden Header und einem Template?>> Beim vorgegebenen Startup-Code kannst du doch die fehlenden Handler> ergänzen oder Platz lassen. Oder wie meinst du das?
Natürlich habe ich das.
Aber eine Erwähnung in den readme oder Doku Files und ein Beispiel hätte
doch geholfen? Es gibt übrigens ein Lader File gcc.ld das auch nicht auf
das Problem hinweist:
1
[..]
2
SECTIONS
3
{
4
.text :
5
{
6
KEEP(*(.isr_vector))
7
*(.text*)
8
9
KEEP(*(.init))
10
KEEP(*(.fini))
11
12
[..]
..Alles bei der Fehlersuche nicht hilfreich.
Gruß,
Holm
Holm T. schrieb:> Aber eine Erwähnung in den readme oder Doku Files und ein Beispiel hätte> doch geholfen?
Die Autoren davon haben vermutlich angenommen, dass jemand, der mit
einem "nackten" Compiler ohne Hersteller-Libraries & Co anfängt, um das
Problem des ISR-Vektor weiß. Das GCC-Paket ist eben keine
Rundum-Sorglos-Lösung. Wenn da im readme alle Fallstricke aufgeführt
wären, wäre es ziemlich lang!
Wer ein Tutorial für STM32 unter Verwendung gängiger Tools (IDEs) liest,
wird vermutlich früher oder später etwas über den ISR-Vektor lernen. Wer
aber alles selber macht (BSD, eigenen Compiler bauen,
Hersteller-Libraries & Beispiele nicht benutzen) muss sich halt alles
selbst erarbeiten...
Holm T. schrieb:> Es gibt übrigens ein Lader File gcc.ld das auch nicht auf> das Problem hinweist:
Wozu auch? Das "KEEP(*(.isr_vector))" reicht. Der ISR-Vektor muss im
Startup-Code korrekt definiert sein.
Holm T. schrieb:> ..Alles bei der Fehlersuche nicht hilfreich.
In der Anleitung zu einer Bohrmaschine steht auch nicht drin, dass der
Schrank, den du damit zusammenbaust, eine Rückwand braucht. Braucht er
nämlich auch nicht immer, und nicht jedes ARM-Programm hat einen
ISR-Vektor, und mit einer Bohrmaschine baut man nicht nur Schränke.
Niklas G. schrieb:> Holm T. schrieb:>> Aber eine Erwähnung in den readme oder Doku Files und ein Beispiel hätte>> doch geholfen?>> Die Autoren davon haben vermutlich angenommen, dass jemand, der mit> einem "nackten" Compiler ohne Hersteller-Libraries & Co anfängt, um das> Problem des ISR-Vektor weiß. Das GCC-Paket ist eben keine> Rundum-Sorglos-Lösung. Wenn da im readme alle Fallstricke aufgeführt> wären, wäre es ziemlich lang!>> Wer ein Tutorial für STM32 unter Verwendung gängiger Tools (IDEs) liest,> wird vermutlich früher oder später etwas über den ISR-Vektor lernen. Wer> aber alles selber macht (BSD, eigenen Compiler bauen,> Hersteller-Libraries & Beispiele nicht benutzen) muss sich halt alles> selbst erarbeiten...>
Meinst Du das BSD ist schuld? Das Paket ist offiziell für MacOSX und
Linux..
> Holm T. schrieb:>> Es gibt übrigens ein Lader File gcc.ld das auch nicht auf>> das Problem hinweist:>> Wozu auch? Das "KEEP(*(.isr_vector))" reicht. Der ISR-Vektor muss im> Startup-Code korrekt definiert sein.
..und .init wird nicht verwendet, schließt aber direkt da an.
Das Startup file hatte ich oben bereits gepostet.
>> Holm T. schrieb:>> ..Alles bei der Fehlersuche nicht hilfreich.> In der Anleitung zu einer Bohrmaschine steht auch nicht drin, dass der> Schrank, den du damit zusammenbaust, eine Rückwand braucht. Braucht er> nämlich auch nicht immer, und nicht jedes ARM-Programm hat einen> ISR-Vektor, und mit einer Bohrmaschine baut man nicht nur Schränke.
In einer BDA zu einer Bohrmaschine steht noch viel mehr drin was Du gar
nicht wissen willst. Es wird auch darauf hingewiesen das man Strom und
auch Bohrer braucht und auch die gängigen Arbeitsschutzanweisungen und
Normen sind Bestandteil der Dokumentation.
Gruß,
Holm
Holm T. schrieb:> Meinst Du das BSD ist schuld?
Nein, aber ein Eigenbau-Compiler ist schon weit abseits der gängigen
Pfade. Man macht es sich deutlich einfacher, z.B. mit Atollic Studio
unter Windows oder Linux anzufangen.
Holm T. schrieb:> ..und .init wird nicht verwendet, schließt aber direkt da an.
Doch, da packt der Compiler Initialisierungs-Funktionen hinein, z.B.
Konstruktoren von globalen C++-Objekten. Kann aber leer sein. Eher
sinnlos ist .fini, weil Mikrocontroller-Programme sich nicht beenden.
Holm T. schrieb:> In einer BDA zu einer Bohrmaschine steht noch viel mehr drin was Du gar> nicht wissen willst.
Das hat aber alles unmittelbar mit der Bohrmaschine zu tun. ISR-Vektoren
haben nichts mit Compilern zu tun. Lies nicht das Readme vom Compiler,
sondern STM32-Tutorials.
Das von dir gefundene Beispiel ist vermutlich an Hersteller wie ST
gerichtet, damit sie auf dessen Basis Beispiele für bestimmte Controller
wie eben STM32 bauen können.
Niklas G. schrieb:> Holm T. schrieb:>> Meinst Du das BSD ist schuld?>> Nein, aber ein Eigenbau-Compiler ist schon weit abseits der gängigen> Pfade. Man macht es sich deutlich einfacher, z.B. mit Atollic Studio> unter Windows oder Linux anzufangen.
Das relativiert sich wenn der Eigenbau Compiler immernoch funktioniert
trotz dem Microsoft gerade wieder ein Sicherheitsupdate gefahren hat.
>> Holm T. schrieb:>> ..und .init wird nicht verwendet, schließt aber direkt da an.>> Doch, da packt der Compiler Initialisierungs-Funktionen hinein, z.B.> Konstruktoren von globalen C++-Objekten. Kann aber leer sein. Eher> sinnlos ist .fini, weil Mikrocontroller-Programme sich nicht beenden.>> Holm T. schrieb:>> In einer BDA zu einer Bohrmaschine steht noch viel mehr drin was Du gar>> nicht wissen willst.>> Das hat aber alles unmittelbar mit der Bohrmaschine zu tun. ISR-Vektoren> haben nichts mit Compilern zu tun. Lies nicht das Readme vom Compiler,> sondern STM32-Tutorials.
Ich habe die von STM mitgelieferte Doku zu den Startup Files, dem
Linkerscript und zur gesamten Toolchain gelesen bzw. durchsucht.
Nichts desto trotz erweckt der ganze Kram nicht den Eindruck fertig zu
sein.
>> Das von dir gefundene Beispiel ist vermutlich an Hersteller wie ST> gerichtet, damit sie auf dessen Basis Beispiele für bestimmte Controller> wie eben STM32 bauen können.
Viele der Files haben ein ST Copyright.
Gruß,
Holm
Du nutzt den falschen Startup-Code.
Wenn du den Controller sinnvoll benutzen willst, dann solltest du auch
einen zum Controller passenden Startup-Code benutzen und keinen
allgemeinen, für dich unvollständigen Core.
Du brauchst nur ein paar Dateien von ST.
In meinem Fall (ein STM32L-Discovery) waren das:
- core_cm3.h, core_cmInstr.h und core_cmFunc.h (bisschen Kleinkram)
- stm32l152vb_flash.ld (Linkerscript)
- startup_stm32l1xx_md.S (Startup-Code und ISRs)
- system_stm32l1xx.c (enthält SystemInit() und Taktzeugs)
- system_stm32l1xx.h (gehört zur C-Datei)
- stm32l1xx.h (Registerdefinitionen)
Mehr Fremdcode braucht man in so einem Projekt nicht, um den Controller
vollständig zu benutzen.
Mit dem von ARM gelieferten Code hast du nichts am Hut, denn was der
tut, hat ST schon integriert.
Thread beobachten
Seitenaufteilung abschalten