ARM Embedded

[Mathias]

Ich habe gerade in den Sourcen von FPC Embedded gestöbert. Dort habe ich unter ./rtl/embedded/arm folgende Unit entdeckt: sam3x8e.pp
Somit müsste es theoretisch möglich sein ein Arduino Due zu programmieren.
Auch hat es in diesem Ordner diverse stm32 Units.

Ich denke, dies wäre mal interessant dies genauer anzugucken. So einfach wird dies nicht sein, fpcupdelux scheitert schon mal mit "arm" "embedded".

Ich wollte dies nur mal als Info geben, was so alles in FPC steckt.

[Socke]

Das ist richtig.
Ich habe hier schon Programme für einen LPC1117-Microcontroller von NXP erstellt, bin dann aber an der Programmierung des Microcontrollers gescheitert .
Ansonsten habe ich hier noch ein STM32F091-Nucleo-Board, das sehr schön zu programmieren ist, da man das Binary einfach per Dateimanager unter Windows auf die MCU kopieren kann - hier ist aber die MCU-Unit in Free Pascal höchst wahrscheinlich unvollständig.

[kupferstecher]

Mit dem STM32F103 hab ich schon rumgespielt, funktioniert! Allerdings gabs ein paar Probleme mit den Optimierungen, letztlich war das Programm nur unter -O0 zuverlässig, ist aber auch wieder fast ein Jahr her.
UART, Sensor über SPI, Sensor über I2C, 1602er Display, waren so die Dinge, mit denen ich mich beschäftigt habe und die letztendlich auch spielten.
Die Standard Peripherial Library für den F1xx ist nur teilweise übersetzt, die Registerdefinitionen sind aber komplett. Es lassen sich also alle Controller-Funktionalitäten nutzen. Für andere STM32 gibt es nur die Register- (und Bit-) definitionen, die StPeriphLib ist aber sowieso so schlecht dokumentiert, dass man sich mit Datenblatt und Registerzugriffen fast leichter tut (mein Eindruck...).

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.

hier ist aber die MCU-Unit in Free Pascal höchst wahrscheinlich unvollständig.

Die Register- und Bitdefinitionen lassen sich recht einfach aus C-Headern übersetzen.

[Mathias]

Mir fehlt aber das Wissen, diesen (unter Lazarus) einzurichten.

Oben schreibst du, das du mit dem STM32F103 rum gespielt hast.
Oder hast du diesen mit FPC ohne Lazarus programmiert ?

[kupferstecher]

Programmiert hab ich ihn schon mit Lazarus, aber den Debugger hab ich nicht zum Laufen bekommen. Einen RemoteGDB hab ich zwar auf dem Rechner, installiert mit Emb:Blocks, aber wie man Lazarus entsprechend einstellen muss, k.A.
Der Programmer hat eine JTAG- und SWD-Schnittstelle, hardwaremaessig waere also alles vorhanden.

[Mathias]

Das habe ich gar nicht geachtet, du hattest nur den Debugger gemeint, welcher nicht funktioniert.

Programmiert hab ich ihn schon mit Lazarus,

Wie hattest du dies hingekriegt ?
Ich denke, du hast dies ohne fpcupdelux hingekriegt.

[siro]

@Socke:
Ich programmiere die LPC's meist mit FlashMagic von NXP
Da brauscht Du nur den Hexfile.
http://www.flashmagictool.com


@kupferstecher:
Mit den Optimierungen liegt nicht nur an Pascal, die Chips haben besondere Eigenheiten...
Ich hab mich schon lange mit diesen Teilen auseinandergesetzt (leider in C)
Man darf zum Beispiel keine Interruptflags in der letzten Codezeile der ISR löschen,
das funktioniert dann bei Optimierungen nicht mehr. Hab auch lange nach den Ursachen gesucht.
Die internen Schreibpuffer sind dann noch nicht fertig. Da hilft dann ein "DSB" Assembler Befehl
"Data Synchronisation Barier" oder eine blödsinnige Zeile wie EatTime=1234;
Das Problem hab ich beim LPC13xx sowie LPC17xx

Man kann mit den ARM Prozessoren zudem kaum "atomaren" Code erzeugen.
Selbst ein Bit löschen geht nicht Thread/Interrupt Sicher.
Der Compiler hat da teils 5 Assemblerzeilen draus gemacht.
Ich find die ARM Struktur teils "armselig"....
Das hat man wohl teilweise erkannt und hat dann chaotische Dinge in den Chips eingebaut
um eine Bit zu setzen oder zu löschen. "Bitbanding" usw...
Dann funzt dann aber nur in bestimmten Speicherblöcken.
Es gibt also VIELE Ursachen für ein Nichtfunktionieren bei Optimierungen....aber auch ohne....

Ich fände es aber auch toll, wenn man die NXP Prozessoren mit Pascal programmieren könnte
Zur Zeit mache ich das in "C" und nutze MCUxpresso, das läuft recht gut
und ist nicht mehr Codebegrenzt und Free. Das basiert ja auch alles auf den GNU Tools.

[Socke]

@Socke:
Ich programmiere die LPC's meist mit FlashMagic von NXP
Da brauscht Du nur den Hexfile.
http://www.flashmagictool.com

Das Tool ist mir bekannt. Was mir fehlte war wohl die korrekte Verdrahtung der seriellen Schnittstelle oder die Spannungsversorgung.

[kupferstecher]

@Mathias:
Nein, ich hab den Crosscompiler "händisch" erstellt, bzw. mithilfe einer Batchdatei, aus dem englischen Lazarusforum. Wenn ich mich richtig erinner war die Batch für AVR, funktioniert mit kleinen Anpassungen auch für ARM.

Unten eine kurze Anleitung, einige Infos gibts auch auf der Wikiseite Target Embedded:
http://wiki.freepascal.org/TARGET_Embedded#ARM_Embedded

Die untenstehende Anleitung ist für Windows und eine Möglichkeit wie es geht, es muss nicht die eleganteste sein...

--
# FPC-Sourcen "Trunk" runterladen mit TortoiseSVN Repository Browser, Adresse:https://svn.freepascal.org/svn/fpc/trunk.

# Verzeichnis im Laufwerk C anlegen, C:\Programme\fpccross, dorthinein Trunk-Ordner verschieben und in "fpc" umbenennen. Unter dem Pfad C:\Programme\fpccross\fpc muss neben anderen nun eine Datei mit Namen "Makefile" liegen.
Achtung, in den Pfaden dürfen im Allgemeinen keine Leerzeichen vorkommen.

# Binutils runterladen* und Dateien ggf. umbenennen in "arm-embedded-as.exe", "arm-embedded-ld.exe", "arm-embedded-ar.exe", "arm-embedded-objcopy.exe", "arm-embedded-objdump.exe" und "arm-embedded-strip.exe". Diese dateien sollen unter C:\Programme\fpccross\avr-embedded\binutils abgelegt werden.
*Wo man diese runterladen kann siehe Wikiseite "Target Embedded" (Link unten).

# Untenstehende Batchdatei "build_arm.bat" in den Ordner fpccross (C:\Programme\fpccross) abspeichern und die darin angegebenen Pfade ggf. anpassen.
- "FPC_PATH" ist der Pfad in dem Bereits der Freepascal-Compiler für Windows installiert ist.
- "NDK_BIN" ist der Pfad wo die Binutils (Linker, Assembler) liegen. Diese stammen nicht von Freepascal, sind aber für den Kompiliervorgang nötig, die Binutils müssen auch nach der Installation am angegebenen Pfad verbleiben.
- "INSTALL_PATH" ist der Pfad, wo der Crosscompiler für AVR hininstalliert werden soll. Man sollte die installierten Dateien später nicht mehr verschieben.

# Eingabeaufforderung als Administrator öffnen und Batchdatei aufrufen, der Crosscompiler wird erstellt. War alles in Ordnung, kommt die Meldung "Installation package fpc-all for target arm-embedded succeeded".

# Datei fpc.cfg in Verzeichnis wo der Crosscompiler liegt kopieren (C:\Programme\fpccross\arm-embedded\compiler\bin\i386-win32).

Dort sollten die folgenden Zeilen ergänzt werden (ggf. Pfade anpassen). Der Compiler selbst benötigt diese nicht, aber die Lazarus IDE, damit Hardwaredefinitionen per Strg+Klick erreichbar sind.

Code: Alles auswählen

##############################
#IFDEF EMBEDDED
#IFDEF CPUARM
-FDC:\Programme\fpccross\arm-embedded\binutils
-FuC:\Programme\fpccross\arm-embedded\compiler\units\arm-embedded\rtl
-FuC:\Programme\fpccross\arm-embedded\compiler\units\arm-embedded\*
#ENDIF
#ENDIF

# Pfad von Crosscompiler in Umgebungsvariable "Path" aufnehmen (Systemsteuerung/System und Sicherheit/System/Erweiterte Systemeinstellungen/Erweitert/Umgebungsvariablen). Computer neu starten, davor hat die Änderung keinen Effekt.

Siehe auch
http://wiki.freepascal.org/TARGET_Embedded#ARM_Embedded

build-arm.bat:

Code: Alles auswählen

    REM **Installed compiler directory
 SET FPC_PATH=C:\Programme\lazarus\fpc\3.0.0\bin\i386-win32
 
    REM The compiler itself
 SET PPCBIN=%FPC_PATH%\fpc.exe
 
    REM Folder where the generated cross compiler and run-time libs are going to be saved
 SET INSTALL_PATH=C:\Programme\fpccross\arm-embedded\compiler
 
    REM We need the path to arm-embedded-* files
 SET NDK_BIN=C:\Programme\fpccross\arm-embedded\binutils
 
    REM Make all the binary files that we need accessible
 SET PATH=%FPC_PATH%;%NDK_BIN%;%PATH%
 
    REM Use the correct SUBARCH here
    REM for STM32F1 use armv7m
    REM Start the process
 
 cd fpc
 
 make clean crossall crossinstall FPC=%PPCBIN% OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv7m INSTALL_PREFIX=%INSTALL_PATH% CROSSBINDIR=%GNU_BIN_PATH% CROSSOPT="-O3 -XX -CX" BINUTILSPREFIX=arm-embedded-
 
 cd ..

[kupferstecher]

@siro:
Dass Arme zickig sind, hab ich auch schon bemerkt.
Wie ich gelesen habe müssen die Flags wohl immer am Anfang der ISR gelöscht werden.
as bei mir nicht geklappt hat, war eine Timer-ISR, die nur auf Register zugreift, das Programm ist unter Optimierung komplett abgestürzt. Ein Aufruf einer beliebigen Procedur hat schon geholfen.
Wäre interessant zu wissen, ob es tatsächlich an der fehlenden "Data Synchron Barrier" liegt. Der ASM-Befehl könnte ja vom Compiler in Interrupts eingebaut werden.

Hier die ISR:

Code: Alles auswählen

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
//++ INTERRUPT SERVICE ROUTINE
procedure TIM2_ISR; Alias: 'TIM2_global_interrupt'; Interrupt; Public;
begin
  Timer2.SR:= Timer2.SR and not TIM_SR_CC1IF; //clear CC1IF
 
  //UART.SendString('TIM2_ISR');
 
  ////Toggle LED on PB8
  if (PortB.ODR and (1 shl 8)) > 0 then begin // if Output Data Bit 8 set..
    PortB.BSRR:= GPIO_BSRR_BR8; // PB8 Reset
 
  end else begin
    PortB.BSRR:= GPIO_BSRR_BS8; // PB8 Set
 
  end;//if
end;

[siro]

Hallo kupferstecher,

Wenn Du am Anfang der ISR das Bit löscht, tritt das Problem niemals auf.
wenn die Zeile als letzte Zeile in der ISR steht, kann das Problem bei Optimierungen auftreten,
so ist es "generell" bei meinem C-Programm.
Dann brauchst Du nur irgend eine blödsinnige Zeile Code dahinter schreiben
und das Problem ist verschwunden.
reicht also schon x:=1; und das Timiung stimmt wieder.
Ansonsten springt die CPU aus der ISR und landet gleich wieder dort, weil das
Löschen des ISR Bit noch nicht fertig geworden ist.

[kupferstecher]

Hallo Siro,

dann war das doch ein anderer Fehler, bzw. Compilerbug.
Wie gesagt, das Programm hat sich komplett aufgehängt...

Grüße

[Mathias]

Unterdessen sind die stm32-Borads billiger als die Arduino Nano. Obwohl diese bessere Leistung haben.

[kupferstecher]

Mathias, hast du schon die ersten Versuche mit einem ARM gestartet?

[Mathias]

Mathias, hast du schon die ersten Versuche mit einem ARM gestartet?

Ausser Raspi, nein.
Ich habe es nicht mal hingekriegt, einen stm32 mit der Arduino-IDE zu programmieren.
Da man den stm32 angeblich nicht direkt über seinen USB programmieren kann, habe ich mehrere kleine Wandler gekauft nur wird kein einziger von Linux erkannt.
Ich gebe es zu, gross probiert habe ich nicht.

Und fpcupdelux quittiert mit folgendem Fehler, wen ich auf arm/embedded stelle. Version: 1.6.0p

Code: Alles auswählen

Building compiler for embedded-arm (OPT: -dFPC_ARMHF ) [CROSSOPT: -Cpavr5 ] {SUBARCH: avr5}.
fpcupdeluxe: info: TAny_embedded-arm: found correct binary utilities in directory /home/tux/fpcupdeluxe/cross/bin/arm-embedded
fpcupdeluxe: info: TAny_embedded-arm: found correct library in directory /home/tux/fpcupdeluxe/cross/lib/arm-embedded
fpcupdeluxe: Start of compile error summary.
fpcupdeluxe: ERROR: FPCCrossInstaller (BuildModuleCustom: FPC): Running cross compiler fpc make all for arm-embedded failed with an error code.