Programmier-Projekte
Lazarus / Free Pascal
Ronald Daleske

Startseite Programmier-Projekte

Free Pascal/Lazarus-Quelltext des RONPAS-Compilers

1. Historie und Konzept

Für meine ersten Projekte mit den AVR-Mikrocontrollern nutzte ich die beiden kostenlos verfügbaren AVRco Pascal-Compiler (Standard release (Codegrösse Beschränkung auf 4kB Flash) und die Mega8/Meg88 release (Codegrösse Beschränkung auf 8kB Flash und Mega8/88))

www.e-lab.de/AVRco

der Firma E-LAB Computers.

Mit der Firma E-LAB Computers teile ich die die Ablehnung der Nutzung der Programmiersprache C für die Programmierung von Mikrocontrollern. In den letzten Jahrzehnten hatte ich des öfteren versucht diese Ablehnung zu überwinden und doch einmal ein kleines Projekt in C zu realisiern. Aber (gefühlt) alle Änderungen der Syntax und der Konzepte von C zu PASCAL sind Verschlechterungen.

Beim AVRco Pascal-Compiler haben mich einige Änderungen der Standard PASCAL-Syntax sofort begeistert:

Quelltext: RONPAS-Compiler, Quelldatei: AVRco_if_then.pas

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
  if a=b then
    a:=a+b;
  endif;
 
  for x1:=0 to 7 do
    Daten[x1]:=ein_Byte_lesen;
  endfor;
 
  case Buchstabe of
    'A' : Read_Block;
      |
    'B' : Write_Block;
      |
  else
    WriteLn(SerOut, 'E');
  endcase;

An die Syntaxkonstrukte if - endif, for - endfor und case - endcase hat man sich schnell gewöhnt und möchte sie nicht mehr missen.

Weiterhin ist die leichte Einbindung von AVR-Assemblercode ein Pluspunkt beim AVRco Pascal-Compiler.

Irgendwann kam es dazu, dass mich die Beschränkungen der kostenlosen Versionen in meinen Projekten so weit behinderten, dass ich mich entschloss einen eigenen PASCAL-Compiler zu schreiben.

Anforderungskatalog für den RONPAS-Compiler:

1. Sämtliche Fehler die bei der Arbeit des Compilers und beim Übersetzen des Quellcodes auftreten und/oder erkannt werden, werden ausgewertet und möglichst genau angezeigt.

Diese Anforderung ist ein sehr grundsätzlicher Ansatz für eine Programmentwicklung. Sie orientiert sich am Ideal der "FEHLERFREIEN SOFTWARE".

Sicher ist eine 100%ige Fehlerfreiheit nicht möglich, aber man kann trotzdem viel erreichen.

Das Wichtigste hierbei (nach meiner Erfahrung) ist, dass man bemüht ist, auch eigene Programmierfehler abzufangen. Jede "if then"-Schleife wird im "nicht genutzten else-Zweig" mit einer Fehlerauswertungsroutine belegt. Auch wenn der Programmablauf niemals in den "nicht genutzten else-Zweig" gelangen kann, kann jeder Programmierer auch mal einen Denkfehler machen, der so abgefangen wird. Das ist während der Programmentwicklung bei mir einige Male vorgekommen. Die Fehlermeldung enthält dann den genauen Namen des Moduls oder der Klasse sowie den genauen Namen der Prozedur oder der Funktion. Damit ist zumindest die Auswirkung eines (unbekannten) Fehlers einfach lokalisierbar.

2. Es werden grundsätzlich keine Zeiger/Pointer benutzt!!!

Das gilt sowohl für den Quelltext für den Free Pascal Compiler als auch für den Mikrocontroller-Quelltext für den RONPAS-Pascal-Compilers. So kann der Free Pascal Compiler mit der strengen Typprüfung weitere (Denk)Fehler erkennen. In der Grammatik des RONPAS-Pascal-Compilers gibt es keine Möglichkeit einen Zeiger/Pointer zu nutzen (es sei denn, es wird ein AVR-Assemblerprogramm eingefügt).

3. Ein ausführliches LOG-System kommentiert den genauen Ablauf des Scannerlaufs und des Parserlaufs und kann auch hier die Fehlersuche deutlich vereinfachen.

Quelldatei: RONPAS.ini

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
[SYSTEM]
source_path=C:\RONPAS\BSP_Projekte\12_test_UNO\10_Blink_ok
source_name=UNO
TRC_Datei_erzeugen=0
LOG_Dateien_erzeugen=0
 
[IDE]
Left=319
Top=6
Width=1325
Height=978
PageControl1_Height=695
CaretY=1
CaretX=1
Item_Index_FontGroesse=3
Item_Index_Meldungen_FontGroesse=1
 
[Device]
Board_Index=0
Device_Index=1
 
[Prommer]
Item_Index_PrommerTyp=1
PageControl_Index=0
Port_Name=COM8
Port_Typ=Serielles USB-Gerät
Prommer_Index=2
 
[Debugger]
Left=371
Top=220
ComPort=COM4
Index_BaudRate=9

Der erste LOG-Schalter wird durch setzen von:

LOG_Dateien_erzeugen=1

in Zeile 5 in der Datei "RONPAS.ini".

Ergebnis: Im Ordner der Quelldatei für den RONPAS-Compiler quelldatei.PAS werden nach dem Compilerlauf folgende LOG-Dateien zusätzlich generiert:

Der zweite LOG-Schalter wird durch setzen von:

TRC_Datei_erzeugen=1

in Zeile 4 in der Datei "RONPAS.ini".

Ergebnis:

Diese Auswertung sollte aber nur bei kleinen Programmen genutzt werden, oder während des Parserlaufes ein- und ausgeschaltet werden, da die LOG-Datei sehr schnell sehr groß wird.

4. Sämtliche Datenstrukturen werden mit statischen Tabellen und Arrays aufgebaut (keine Zeigerstrukturen und Binärbäume)

Datenstrukturen mit Zeigern wurden in den frühen Jahren der Informatik entwickelt als der Speicherplatz noch sehr knapp war (im Kilobyte Bereich). Mit Zeigerstrukturen kann man auf wenig Platz sehr komplexe Strukturen unterbringen (ohne viel Redundanz). Das ist zweifellos ein Vorteil dieser Strukturen.

Nachteilig bei Zeigerstrukturen und Binärbäumen ist, dass sie dynamisch arbeiten. Beim Aufbau und bei der Erweiterung muss ständig Speicherplatz vom Betriebssystem angefordert werden. Diese Anforderungen sind zeitaufwendig. Auch die Freigabe der vielen, oft verteilten Speicherbereiche ist zeitaufwendig.

Zudem kann der Compiler in der Übersetzungsphase kaum Fehler beim Bearbeiten dieser Strukturen aufdecken (Aushebeln der strengen Typprüfung).

Im RONPAS-Compiler wurde der Ansatz moderner tabellarischen Datenbanken genutzt. Jede Tabelle muss zwar mit der maximal benötigten Größe erstellt werden. Das beinhaltet ein gewissen Maß an Redundanz, da im Betrieb nicht jede Tabelle vollständig genutzt wird. Aber es handelt sich bei den ATMEGAs um ein 8-Bit Controller in dem maximal 256MB an Daten verwaltet werden müssen. Da ist die Größe aller Tabellen verschwindend gering zu heutigen Arbeisspeichergrößen.

Nach dem Start des RONPAS-Compilers werden die statischen Tabellen im Arbeitsspeicher reserviert und können während des Compilerlaufes ohne weitere Speicheranforderungen genutzt werden. Das Ergebnis ist ein sehr schnell arbeitender Compiler.

Der Unterschied zwischen dem RONPAS-Compiler und beispielsweise der Arduino IDE beim Übersetzen vergleichbarer Quelltexte ist erheblich (man fragt sich bei der Arduino IDE oft - Was macht die Software da so lange im Hintergrund?).

5. Der Schwerpunkt beim RONPAS-Compiler lag auf der hardwarenahen, schnellen und effizienten Programmierung mit der Programmiersprache PASCAL

Der RONPAS-Compiler wurde ausschießlich für die AVR ATmega-Mikrocontroller entwickelt. Eine Erweiterung auf die ATtiny wurde verworfen, da es für fast jeden ATtiny besondere Ausnahmen gibt. Die AVR ATmega-Familie deckt vom ATmega48 (4KByte Flash und 512 Byte SRAM) bis zum ATmega256 (256KByte Flash und 8 KByte SRAM) einen ausreichend großen Bereich ab.

Diese Anforderungen erfordern aber auch, dass der RONPAS-Compiler mit nur 4KByte Programmcode und vor Allem mit nur 512 Byte SRAM zurecht kommen muss. Das ergibt in der Umsetzung, dass der Compiler den Programmcode vorrangig mit den 32 Registern und weniger mit dem (oft sehr knapp vorhandenen SRAM) umsetzen muss.

Positiver Nebeneffekt ist ein efizienter Programmcode, wie ihn kaum ein anderer Compiler liefern wird (kurz und schnell). Das ist der Vorteil eines auf eine Mikrocontrollerfamilie spezialisierten Compilers.

Nachteilig ist die mitunter aufwendigere Programmierung. So z.B.:

2. Hinweise zum Kompilieren

in Arbeit

in Arbeit ...

3. kurze Erläuterungen zum Quelltext

in Arbeit

in Arbeit ...


Startseite Programmier-Projekte