ARM Embedded

[mischi]

CROSSOPT: -Cpavr5 passt eigentlich nicht zu arm. Valide subarchs für arm sind: armv7m, armv7em, armv4t, armv4 , armv6m, armv7a

Die Information bekommt man aus der Datei: rtl/embedded/Makefile.fpc

Wenn ich das richtig verstehe, steht da auch drin, welche subarch zu welchem Board passt.

MiSchi

[Mathias]

CROSSOPT: -Cpavr5 passt eigentlich nicht zu arm. Valide subarchs für arm sind: armv7m, armv7em, armv4t, armv4 , armv6m, armv7a

Das scheint sich von ATMega328 eingeschlichen zu haben. Vielleicht wurde dies mit embeddes Verknüpft anstelle mit AVR.

[kupferstecher]

habe ich mehrere kleine Wandler gekauft nur wird kein einziger von Linux erkannt.

Was für ein Programmieradapter hast du denn? Ich benutze den STLinkV2, allerdings unter Windows. Dafür gibt es auch Linux-Treiber, such mal nach "texane st-link".

[Mathias]

So einen habe ich auch, wen ich mal Lust habe probiere ich ihn nochmals.
Ich werde dann nach deinem Suchbegriff googeln.

[mse]

Dann brauchst Du nur irgend eine blödsinnige Zeile Code dahinter schreiben
und das Problem ist verschwunden.

Das einzig Richtige ist der Einbau einer "memory barrier" ( __DSB()-Funktion in gcc) vor dem Verlassen der IRQ Routine.
"memory barriers" sind auch sonst manchmal im Zusammenhang mit den Memory Management- und anderen Hardware Elementen notwendig.
https://en.wikipedia.org/wiki/Memory_barrier
http://infocenter.arm.com/help/index.js ... 14041.html
http://infocenter.arm.com/help/index.js ... EDAAF.html

Im Moment scheint infocenter.arm.com nicht richtig zu funktionieren...

[mse]

Ein Debugger wäre wohl hilfreich gewesen (wegen der Chrashs unter Optimierung), GDB-Remote könnte auch funktionieren. Mir fehlt aber das Wissen, diesen (unter Lazarus) einzurichten.

Ich arbeite häufig mit Cortex M3 Chips und dem Segger J-Link Debug Interface mit gcc und MSEide. Ein typisches Debugger Setup sieht so aus:
http://mseide-msegui.sourceforge.net/pi ... bugger.png
und liesse sich sicher auch mit Free Pascal verwenden.

Das "${jlinkdir}startgdbserver" Script initialisiert die Debugger-Interface Einstellungen und startet das JLinkGDBServer Programm.
"${MAKETOOLDIR}start.gdb" sieht z.B. so aus:

Code: Alles auswählen

 
monitor speed 4000
monitor endian little
monitor flash download = 1
monitor flash device = EFM32TG210F32
monitor reset 0
 

Edit:
Für ST-Link könnte man vermutlich die Tools von hier
https://github.com/texane/stlink
verwenden.
https://github.com/texane/stlink/blob/master/README.md

[kupferstecher]

Hallo MSE,

danke für Infos. Es ist schon wieder eine Weile her, dass ich mich damit beschäftigt habe, damals hab ich den Debugger nicht zum Laufen gebracht. Wenn ich mit dem STM32 wieder zu tun habe, werd ichs nochmal probieren.

Viele Grüße

[Mathias]

habe ich mehrere kleine Wandler gekauft nur wird kein einziger von Linux erkannt.

Was für ein Programmieradapter hast du denn? Ich benutze den STLinkV2, allerdings unter Windows. Dafür gibt es auch Linux-Treiber, such mal nach "texane st-link".

Ich versuche gerade folgende Anleitung durchzuarbeiten. https://github.com/texane/stlink/blob/m ... mpiling.md

Nun habe ich eine Gerät

Code: Alles auswählen

$ls /dev/stlinkv2_1 
/dev/stlinkv2_1

Nachtrag: Ich konnte nun den ersten Blink-Sketch mit der Arduino-IDE hochladen.

[mse]

Nachtrag: Ich konnte nun den ersten Blink-Sketch mit der Arduino-IDE hochladen.

Dann solltest du auch das Debuggen mit MSEide/Lazarus schaffen.

[Mathias]

Dann solltest du auch das Debuggen mit MSEide/Lazarus schaffen.

Wen du mit Debuggen das erstellen von Programmen meinst, dann muss zuerst mal einen funktionierenden Cross-Compiler her.

[mse]

Mit Debuggen meine ich das Laufenlassen und Beobachten (Einzelschritt, Breakpoints, Variablen, Register...) eines bestehenden Programms. Kannst du mit gcc ein Minimalprogramm als *.elf-Datei erzeugen und in den uP übertragen?
Was liefert das Programm st-util für ein Ergebnis? st-util ist der gdb-Server für stlink.
Hast du einen entsprechenden ARM gdb? Vorkompiliert gibt es die toolchain hier:
https://developer.arm.com/open-source/g ... /downloads
Aus readme.md:

Code: Alles auswählen

 
Then, in your project directory, someting like this... (remember, you need to run an ARM gdb, not an x86 gdb)
 
$ arm-none-eabi-gdb fancyblink.elf
...
(gdb) target extended-remote :4242
...
(gdb) load
Loading section .text, size 0x458 lma 0x8000000
Loading section .data, size 0x8 lma 0x8000458
Start address 0x80001c1, load size 1120
Transfer rate: 1 KB/sec, 560 bytes/write.
(gdb)
...
(gdb) continue
 

Falls das funktioniert kann der Start von st-util und arm-none-eabi-gdb in den MSEide Projektoptions eingetragen werden. Ich würde zuerst mit MSEide ein einfaches gcc Programm machen, da gibt es bestimmt Beispiele.
Wenn es reibungslos funktioniert kann dann der ARM Free Pascal Compiler in Angriff genommen werden.

[Mathias]

Kannst du mit gcc ein Minimalprogramm als *.elf-Datei erzeugen und in den uP übertragen?

Wie gesagt, mit der Arduino-IDE konnte ich den ersten Blink-Versuch hochladen.
Ich dachte, gcc sei um PC-Programme zu kompilieren oder hast du arm-none-eabi-gcc gemeint ?
Ob es eine *.elf mit Arduino gibt, habe ich nicht probiert.

Du scheibst da was von Debuggen.
Kann man den STM32 zur Laufzeit über den "ST-LINK V2" debuggen ?

Falls das funktioniert kann der Start von st-util und arm-none-eabi-gdb in den MSEide Projektoptions eingetragen werden.

Das wird wohl ähnlich sein, wie bei den AVR.
Aber brauche ich nicht zuerst eine Cross-Compiler, wen das Ganze mit FPC laufen soll ?

[mse]

Du scheibst da was von Debuggen.
Kann man den STM32 zur Laufzeit über den "ST-LINK V2" debuggen ?

Ja, MSEide ist dafür eingerichtet. Man kann auch das Programm direkt via gdb in den Chip übertragen.

Falls das funktioniert kann der Start von st-util und arm-none-eabi-gdb in den MSEide Projektoptions eingetragen werden.

Das wird wohl ähnlich sein, wie bei den AVR.
Aber brauche ich nicht zuerst eine Cross-Compiler, wen das Ganze mit FPC laufen soll ?

Darum der Vorschlag zuerst mit MSEide und gcc ein Minimalprogramm zu machen. MSEide funktioniert sowohl mit gcc als auch mit FPC. Wenn dann die Debug-Entwicklungsumgebung steht, kann man das FPC-ARM-embedded Abenteuer angehen.
Vorkompilierte cross-gcc und binutils sind hier:
https://developer.arm.com/open-source/g ... /downloads

[Mathias]

Ich habe es hingekriegt, mit Eclipse Sloeber den STM32 zu programmieren.
Einziges Manko, gegen deinen Vorschlag mit MSEide, wird wohl sein, das es Arduinolastig ist. Es hat ein setup und loop.

Ich habe mal kurz MSEide angeguckt, so wie es scheint, muss man dort sehr viel konfigurieren.

So wie es scheint, kann man nicht mit einem einfachen PORTD = 123 auf eine Port zugreifen.

[mse]

Ich habe es hingekriegt, mit Eclipse Sloeber den STM32 zu programmieren.
Einziges Manko, gegen deinen Vorschlag mit MSEide, wird wohl sein, das es Arduinolastig ist. Es hat ein setup und loop.

Mit Eclipse Sloeber kannst du kaum Free Pascal Programme machen. Mit MSEide schon.

Ich habe mal kurz MSEide angeguckt, so wie es scheint, muss man dort sehr viel konfigurieren.

Ich werde ein Beispielprojekt mit einem STM32L100C-DISCO board machen.
Für normale FPC PC-Entwicklung muss lediglich das MSEgui Verzeichnis konfiguriert werden (Punkt 5). Aus README.TXT.

Code: Alles auswählen

 
Installation:
*************
1. Download and install FPC 3.0.2 or 3.0.4, you can get it from 
   http://www.freepascal.org/download.var
2. Download mseide_msegui_src_4_6.zip and the mseide_* archive
   for your system.
   http://sourceforge.net/projects/mseide-msegui/files/mseide-msegui/4.6/
3. Extract them to a directory of your choice ('yourdirectory') .
4. Run 'yourdirectory/bin/mseide' on linux and freebsed or 
   'yourdirectory\bin\mseide.exe' on windows.
5. In 'Settings'-'Configure MSEide'-'${MSEDIR}' select 'yourdirectory/msegui'.
6. In 'Project'-'Open' select 'yourdirectory/msegui/apps/demo/demo.prj'.
7. 'Target'-'Continue'.
 

So wie es scheint, kann man nicht mit einem einfachen PORTD = 123 auf eine Port zugreifen.

Worauf bezieht sich das? Auf FPC? Dazu sind zum Controller passende Register-Definitions-Units notwendig.