FPC fit für PIC & AVR

[Maik81ftl]

Moin zusammen,

o.g. Thema läst wohl schon erahnen, was ich vorhabe und suche dafür noch freiwillige, welche sich daran mit beteiligen wollen. Mein Ziel ist es sämtliche µC in Lazarus zu Programmieren.

Fragen, Anregungen sowie weitere punkte könnt Ihr mir gerne an meinem Berufacc (Maik81SE) schicken oder via mail (mg@to-labsystems.de) zu schicken.

was über diesen Acc rein kommt, landet auf jeden in meinem Berufs acc.

Hoffe auf Positive Ressonanz eurerseits und jeder, der sich mit µC auskennt ist willkommen. auch die, die damit anfangen wollen.

[MmVisual]

Mich würde es auch reizen den STM32 (Cortex-M3) mit dem FPC zu proggen. Aber wenn ich erst mal anfangen muss die 600KB Header-Datei mit allen Definitionen um zu schreiben damit es Pascal tauglich wird, lasse ich das ganz schnell wieder und nutze lieber C / GCC.
Da wäre wohl die aller erste Aufgabe einen Parser zu schreiben, der aus einer .c/.h eine Unit macht, denn die µC's werden nunmal zu 95% in C programmiert und im WWW und von den Herstellern der Prozessoren sind alle Demos entweder in Assembler (bei AVR/PIC) oder in C (ARM).
Im Anhang die Datei die ich meine.

(natürlich sollte das Ergebnis des Parsers auch funktionieren. )

[mschnell]

. Mein Ziel ist es sämtliche µC in Lazarus zu Programmieren.

Das ist ja wohl ein Witz

Ich vermute, 8 und 16 - Bitter geht gar nicht. 32 - Bitter sollte machbar sein.

PIC 32 ist eine MIPS Architektur. Das gibt es auf jeden Fall bereits Ansätze.

Ich wäre interessiert an einem Compiler für 68 K. Den gab es mal. Aber danach wurde die Compiler-Infrastruktur komplett umgestellt und um die 68KArchitektur hat sich keiner mehr gekümmert.

-Michael

[Socke]

Als Themenfremder gebe ich auch mal meinen Senf dazu …

Da wäre wohl die aller erste Aufgabe einen Parser zu schreiben, der aus einer .c/.h eine Unit macht

Gibt es schon, siehe h2pas oder das Lazarus-Package dazu. Das arbeitet zwar nicht perfekt, kann aber helfen. Ansonsten ist das eine Feißarbeit, mit Kenntnissen in C und Pascal aber relativ einfach.

Ich vermute, 8 und 16 - Bitter geht gar nicht. 32 - Bitter sollte machbar sein.

Der FPC kann für einige ARM-Prozessoren auch den Thumb-Befehlssatz ausgeben (habe ich gelesen, aber nie getestet); Der Thumb-Befehlssatz ist eine 16-Bit Variante des eigentlich 32-bittigen Befehlssatzes.

Ich wäre interessiert an einem Compiler für 68 K. Den gab es mal. Aber danach wurde die Compiler-Infrastruktur komplett umgestellt und um die 68KArchitektur hat sich keiner mehr gekümmert.

Ist der noch brauchbar? Neu Sprachkonstrukte wird man damit nicht verwenden können, aber vielleicht das, was damals implementiert war.

[MmVisual]

Ich habe das mal mit h2pas getestet:

Code: Alles auswählen

D:\WinARM\Test__>h2pas stm32f10x.h
at line 223 error : syntax error
at line 495 error : syntax error
An unhandled exception occurred at $00408E25 :
EAccessViolation : Access violation
  $00408E25
  $00405B15
  $0040DD01

Er kann die #ifdef nicht bearbeiten und davon sind jede Menge drin, die auch gebraucht werden.

[Maik81SE]

Mich würde es auch reizen den STM32 (Cortex-M3) mit dem FPC zu proggen. Aber wenn ich erst mal anfangen muss die 600KB Header-Datei mit allen Definitionen um zu schreiben damit es Pascal tauglich wird, lasse ich das ganz schnell wieder und nutze lieber C / GCC.
Da wäre wohl die aller erste Aufgabe einen Parser zu schreiben, der aus einer .c/.h eine Unit macht, denn die µC's werden nunmal zu 95% in C programmiert und im WWW und von den Herstellern der Prozessoren sind alle Demos entweder in Assembler (bei AVR/PIC) oder in C (ARM).
Im Anhang die Datei die ich meine.

(natürlich sollte das Ergebnis des Parsers auch funktionieren. )

nun da muß ich dir recht geben. hab die mir gerade mal angeschaut und nunja wirklich etwas arbbeit.

. Mein Ziel ist es sämtliche µC in Lazarus zu Programmieren.

Das ist ja wohl ein Witz

Ich vermute, 8 und 16 - Bitter geht gar nicht. 32 - Bitter sollte machbar sein.

PIC 32 ist eine MIPS Architektur. Das gibt es auf jeden Fall bereits Ansätze.

Ich wäre interessiert an einem Compiler für 68 K. Den gab es mal. Aber danach wurde die Compiler-Infrastruktur komplett umgestellt und um die 68KArchitektur hat sich keiner mehr gekümmert.

-Michael

Hast du's denne schon mal versucht???

Zusammeengefasst:

Klar ist dabei erst mal eine Menge arbeit damit verbunden. würde selber meinen PIC16F6680 /AT90CAN64 auch lieber in ASM/Modula/AVRDUDE schreiben, aber a) weis ich nicht, ob mein wissen für dieses Projekt ausreicht und b) AVRDUD läuft nicht. werd ich wohl zur Not damit auf Win arbeiten müßen .

[MmVisual]

@Maik81SE

Nehme lieber Eclipse und programmiere in C. Eclipse ist der beste Editor überhaupt, sogar besser als der von Lazarus (und der ist der zweitbeste).
Dann nehme anstatt den AVR/PIC besser einen STM32. Mehr Leistung, und Möglichkeiten (ohne dass ich jetzt einen Glaubenskrieg anzetteln will).

So viel ich weiß kann FPC schon für den STM32 (Cortex-M3) übersetzen (ich hab mal was im www gesehen: http://j-software.dk/stm32f103.php).

Eclipse ist aber so gut, dass man wirklich nicht mehr das Bedürfnis hat den µC in Pascal zu programmieren. Und C ist nicht so arg viel anders.

[corpsman]

Also ich Programmiere privat einige unterschiedliche Atmegas und beruflich die Pics. Im "Job" nutze ich auch Eclipse, es ist zugegeben nicht schlecht, aber Lazarus ist mir trotzdem um einiges Lieber, somit dürfte die Ansicht welche IDE die "beste" ist wohl eher persönliche Meinung sein

Privat nutzte ich bis Kubuntu 11.04 Kontrollerlab, welches echt nicht schlecht war ( das ist natürlich auch alles in C ). Kontrollerlab ist leider von KDE3 Abhängig, dass gibts nu unter 11.10 nicht mehr. Deshalb habe ich angefangen mein eigenes KLab zu Proggen ( siehe entsprechende Threads die von mir zu Zeit gestartet werden *g* )

Einen Eigenen Crosscompiler zu schreiben, halte ich hier auch für etwas overkill. Auch wenn ich C nun wirklich nicht ausstehen kann, für die µ-Kontroller ist es akzeptabel und bietet eine Saubere Trennung zwischen "Low" Level µ-Kontroller und "High" Level Linux / Windows Programmierung.

Solltet ihr es aber tatsächlich hinbekommen, würde ich es nur zu gern "testen".

[mschnell]

Der FPC kann für einige ARM-Prozessoren auch den Thumb-Befehlssatz ausgeben (habe ich gelesen, aber nie getestet); Der Thumb-Befehlssatz ist eine 16-Bit Variante des eigentlich 32-bittigen Befehlssatzes.

Nö. "Thumb" ist eine astreine 32 Bit Architektur. Die Bitzahl der Architektur wird durch die Größe der Register (im allgemeinen der für Adressierung verwendbaren Register) bestimmt. Die Größe der Codes für Befehle (die Bei Thumb 16 Bit und bei "big" ARM 32 Bit ist) spielt keine Rolle (die ist bei X86 variabel 8, 16, 24, 23,... Bit).

-Michael

[mschnell]

Ist der noch brauchbar? Neu Sprachkonstrukte wird man damit nicht verwenden können, aber vielleicht das, was damals implementiert war.

Auf Nachfrage wurde mir gesagt, dass die alte Compiler-Variante durchaus funktionsfähig ist. Wenn man aber einen Compiler aus den aktuellen Sourcen bauen will, muss man die 68K-Unterstützung aber quasi von Null an wieder aufbauen, wobei man aber sicher ein bisschen bei der alten Version abgucken kann.

Eine aktuelle Lazarus-Version läuft mit der alten FPC-Version nicht.

-Michael

[mschnell]

Fazit:

Man arbeite mit den GNU-Leuten zusammen und mache ein Frontend für gcc, das die FPC/Delphi/ObjectPascal - Sprache in den gcc-Zwischencode übersetzt. das gcc-Backend übernimmt dann die Code-Generierung für jeden von gcc unterstützten µP.

Als Editor/Debugger ist dann natürlich Eclipse angesagt.

Das wurde auch schon in den Englischen Foren diskutiert.

Das "kleine" Problem ist, das der gcc-Zwischencode erweitert werden müsste um die Object-Pascal spezifische Objekt-Struktur (die recht anders als die von c++ ist) zu unterstützen. Es dürfte schwierig sein, das gcc-Team dafür zu begeistern ("never change a running system"). Und die FPC- und Lazarus Jungs sind natürlich auch nicht interessiert.

-Michael

[Socke]

Man arbeite mit den GNU-Leuten zusammen und mache ein Frontend für gcc, das die FPC/Delphi/ObjectPascal - Sprache in den gcc-Zwischencode übersetzt. das gcc-Backend übernimmt dann die Code-Generierung für jeden von gcc unterstützten µP.

Es gibt ein GNU Pascal Frontend für den gcc; der arbeitet aber nicht objektorientert.

Eine aktuelle Lazarus-Version läuft mit der alten FPC-Version nicht.

Meinst du, man könne Lazarus nicht mit alten FPC-Versionen bauen oder man könne alte FPC-Versionen nicht als Compiler für eigene Projekte verwenden?
Bei ersterem stimme ich dir zu und letzteres möchte ich stark bezweifeln, da sich hier doch nur die Compiler-Schalter geändert haben können, welche man ganz einfach abschalten und manuell einschalten kann. Bei Debugging kann das wieder etwas anders aussehen.

Nö. "Thumb" ist eine astreine 32 Bit Architektur. Die Bitzahl der Architektur wird durch die Größe der Register (im allgemeinen der für Adressierung verwendbaren Register) bestimmt. Die Größe der Codes für Befehle (die Bei Thumb 16 Bit und bei "big" ARM 32 Bit ist) spielt keine Rolle (die ist bei X86 variabel 8, 16, 24, 23,... Bit).

Danke für die Erklärung; an die Register hatte ich gar nicht gedacht (mit denen habe ich aber auch selten was zu tun).
Nächste Idee: an einigen wenigen Stellen im FPC-/RTL-Quelltext habe ich ein {$IFDEF CPU16} gesehen; wahrscheinlich sind das nur Überreste von wirklich alten Versionen; aber vielleicht gibts da ja noch mehr?

[mschnell]

Meinst du, man könne Lazarus nicht mit alten FPC-Versionen bauen

Ich weiß dass das nicht geht.

oder man könne alte FPC-Versionen nicht als Compiler für eigene Projekte verwenden?

Du kannst die aktuelle LCL nicht mit einem alten Compiler übersetzen. Wenn nichts aus der LCL verwendet wird, geht das vielleicht irgendwie.
-Michael

[mschnell]

Nächste Idee: an einigen wenigen Stellen im FPC-/RTL-Quelltext habe ich ein {$IFDEF CPU16}

Vielleicht täusche ich mich ja, und man kann doch für irgendwelche 16 Bit CPUs übersetzen. Habe ich aber noch nicht von gehört.

-Michael

[Christian]

Ich hab letztens erst n bissl was am avr Port für den fpc gemacht, hab aber leider etwas wenig zeit dafür. Der fpc ist durchaus in der lage für nen 8bitter Code zu generiern. Er generiert auch schon AVR Code was fehlt ist startupcode und Registerdefinitionen. Letztere habich fürn Atmega128 schonmal fertig gemacht.