ARM Embedded
-
- Beiträge: 6164
- Registriert: Do 2. Jan 2014, 17:21
- OS, Lazarus, FPC: Linux (die neusten Trunk)
- CPU-Target: 64Bit
- Wohnort: Schweiz
ARM Embedded
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.
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.
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot
Mit Java und C/C++ sehe ich rot
-
- Lazarusforum e. V.
- Beiträge: 3158
- Registriert: Di 22. Jul 2008, 19:27
- OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
- CPU-Target: 32bit x86 armhf
- Wohnort: Köln
- Kontaktdaten:
Re: ARM Embedded
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.
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.
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein
- kupferstecher
- Beiträge: 418
- Registriert: Do 17. Nov 2016, 11:52
Re: ARM Embedded
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.
Die Register- und Bitdefinitionen lassen sich recht einfach aus C-Headern übersetzen.
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.
Socke hat geschrieben: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.
-
- Beiträge: 6164
- Registriert: Do 2. Jan 2014, 17:21
- OS, Lazarus, FPC: Linux (die neusten Trunk)
- CPU-Target: 64Bit
- Wohnort: Schweiz
Re: ARM Embedded
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 ?
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot
Mit Java und C/C++ sehe ich rot
- kupferstecher
- Beiträge: 418
- Registriert: Do 17. Nov 2016, 11:52
Re: ARM Embedded
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.
Der Programmer hat eine JTAG- und SWD-Schnittstelle, hardwaremaessig waere also alles vorhanden.
-
- Beiträge: 6164
- Registriert: Do 2. Jan 2014, 17:21
- OS, Lazarus, FPC: Linux (die neusten Trunk)
- CPU-Target: 64Bit
- Wohnort: Schweiz
Re: ARM Embedded
Das habe ich gar nicht geachtet, du hattest nur den Debugger gemeint, welcher nicht funktioniert.
Ich denke, du hast dies ohne fpcupdelux hingekriegt.
Wie hattest du dies hingekriegt ?Programmiert hab ich ihn schon mit Lazarus,
Ich denke, du hast dies ohne fpcupdelux hingekriegt.
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot
Mit Java und C/C++ sehe ich rot
-
- Beiträge: 730
- Registriert: Di 23. Aug 2016, 14:25
- OS, Lazarus, FPC: Windows 11
- CPU-Target: 64Bit
- Wohnort: Berlin
Re: ARM Embedded
@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.
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.
Grüße von Siro
Bevor ich "C" ertragen muß, nehm ich lieber Lazarus...
Bevor ich "C" ertragen muß, nehm ich lieber Lazarus...
-
- Lazarusforum e. V.
- Beiträge: 3158
- Registriert: Di 22. Jul 2008, 19:27
- OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
- CPU-Target: 32bit x86 armhf
- Wohnort: Köln
- Kontaktdaten:
Re: ARM Embedded
siro hat geschrieben:@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.
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein
- kupferstecher
- Beiträge: 418
- Registriert: Do 17. Nov 2016, 11:52
Re: ARM Embedded
@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.
# 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:
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
- Beiträge: 418
- Registriert: Do 17. Nov 2016, 11:52
Re: ARM Embedded
@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:
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;
-
- Beiträge: 730
- Registriert: Di 23. Aug 2016, 14:25
- OS, Lazarus, FPC: Windows 11
- CPU-Target: 64Bit
- Wohnort: Berlin
Re: ARM Embedded
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.
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.
Grüße von Siro
Bevor ich "C" ertragen muß, nehm ich lieber Lazarus...
Bevor ich "C" ertragen muß, nehm ich lieber Lazarus...
- kupferstecher
- Beiträge: 418
- Registriert: Do 17. Nov 2016, 11:52
Re: ARM Embedded
Hallo Siro,
dann war das doch ein anderer Fehler, bzw. Compilerbug.
Wie gesagt, das Programm hat sich komplett aufgehängt...
Grüße
dann war das doch ein anderer Fehler, bzw. Compilerbug.
Wie gesagt, das Programm hat sich komplett aufgehängt...
Grüße
-
- Beiträge: 6164
- Registriert: Do 2. Jan 2014, 17:21
- OS, Lazarus, FPC: Linux (die neusten Trunk)
- CPU-Target: 64Bit
- Wohnort: Schweiz
Re: ARM Embedded
Unterdessen sind die stm32-Borads billiger als die Arduino Nano. Obwohl diese bessere Leistung haben.
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot
Mit Java und C/C++ sehe ich rot
- kupferstecher
- Beiträge: 418
- Registriert: Do 17. Nov 2016, 11:52
Re: ARM Embedded
Mathias, hast du schon die ersten Versuche mit einem ARM gestartet?
-
- Beiträge: 6164
- Registriert: Do 2. Jan 2014, 17:21
- OS, Lazarus, FPC: Linux (die neusten Trunk)
- CPU-Target: 64Bit
- Wohnort: Schweiz
Re: ARM Embedded
kupferstecher hat geschrieben: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.
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot
Mit Java und C/C++ sehe ich rot