FPC fit für PIC & AVR

Für alles, was in den übrigen Lazarusthemen keinen Platz, aber mit Lazarus zutun hat.
Mathias
Beiträge: 6160
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: FPC fit für PIC & AVR

Beitrag von Mathias »

seit kurzem beschäftige ich mich mit AVR's.
Habe zunächs mal mit BascomAVR und LunaAVR probiert , alles ja ganz schön , aber mit der Syntax kann ich mich einfach nicht anfreunden.

Hast du auch schon Arduino probiert, oder kennst du nur die oben genannten ?
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

Frank Ranis
Beiträge: 201
Registriert: Do 24. Jan 2013, 21:22

Re: FPC fit für PIC & AVR

Beitrag von Frank Ranis »

Hallo Mathias,

Mathias hat geschrieben:Hast du auch schon Arduino probiert, oder kennst du nur die oben genannten ?


Ja , das war das erste , was ich mir angeschaut habe.
Für absolute Programmieranfänger , oder C-Freunde ist das OK.
Aber doch nicht für einen eingfleischten Pascal-Freek .
Da würde ich dann doch lieber Bascom oder Luna nehmen , das kommt dem Pascal noch am nächsten.

Aber die Arduino-Board's (die Nachbauten aus Chinaland) sind interssant , für das Geld bekommt man die Bauteile nicht einzeln.

Ich brauch doch nur mal nen Schubs Betreff FPC und AVR , aus dem was man im WWW findet wird der Einsteiger nicht schlau.

Gruß

Frank
www.flz-vortex.de

Mathias
Beiträge: 6160
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: FPC fit für PIC & AVR

Beitrag von Mathias »

Für absolute Programmieranfänger , oder C-Freunde ist das OK.

Das würde ich nicht sagen, mit dem Arduino kann man sehr komplexe Sachen schreiben, aber wie du schreibst leider in C++.

Aber die Arduino-Board's (die Nachbauten aus Chinaland) sind interssant , für das Geld bekommt man die Bauteile nicht einzeln.

Vor allem die Nanos, habe ein seht gutes Preis-Leistungsverhältnis. Wen man den USB während des Betriebes nicht braucht, dann ist es auch interessant, einen Atmeg328 solo zu verbauen, sieht dann auch professioneller aus..
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

AndreasMR
Beiträge: 98
Registriert: Di 4. Aug 2015, 15:29
OS, Lazarus, FPC: Linux, Raspbian, Windows
CPU-Target: 64/32 Bit

Re: FPC fit für PIC & AVR

Beitrag von AndreasMR »

Hallo Mathias,

Mathias hat geschrieben:
Für absolute Programmieranfänger , oder C-Freunde ist das OK.

Das würde ich nicht sagen, mit dem Arduino kann man sehr komplexe Sachen schreiben, aber wie du schreibst leider in C++.


Arduino kann man auch in Pascal und Basic programmieren. Da gab es im Raspberry Forum mal eine Diskussion, in welchen Sprachen man die Teile alle programmieren kann. Und da haben einzelne Mitglieder so einiges zusammengetragen.

Beste Grüße

Andreas
Ubuntu 14.04 LTS / Raspbian / Windows: Lazarus ab 0.9 bis 3.0

Mathias
Beiträge: 6160
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: FPC fit für PIC & AVR

Beitrag von Mathias »

Arduino kann man auch in Pascal und Basic programmieren.

Meinst du damit einene kostenpflichtige Version ?
Ich finde leider den Link nicht mehr.
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

Frank Ranis
Beiträge: 201
Registriert: Do 24. Jan 2013, 21:22

Re: FPC fit für PIC & AVR

Beitrag von Frank Ranis »

Hallo ,

die letzten Beträge , bez. Arduino , bringen mich leider nicht vorann.

Nach stundenlagem rumprobieren , bin in nun ein klein wenig weiter , aber noch nicht am Ziel (die LAZ-IDE für AVR zu nutzen).
Hier nun eine erste Zusammenfassung von meinem Kampf mit der Materie.

Zunächst habe ich die Anleitung von "engkin" durchgeackert , siehe http://forum.lazarus.freepascal.org/ind ... ic=30960.0 , ganz unten.
Hier hatte ich aber das Probleme die avr-toolchain-Files zu finden (der LINK http://svn2.freepascal.org/svn/fpcbuild ... i386-win32) im Tutorial war nicht mehr gültig) .

Also wieder Google angeschmissen und gesucht.
Gefunden habe ich es dann unter
http://svn.freepascal.org/svn/fpcbuild/ ... 386-win32/
na ja , fast der gleiche LINK , bis auf die Zahl 2 hinter http://svn

Dort habe ich mir dann die Files abgesaugt.
avr-embedded-ar.exe
avr-embedded-as.exe
avr-embedded-ld.exe
avr-embedded-objcopy.exe
avr-embedded-objdump.exe
avr-embedded-strip.exe

Schlußendlich hatte ich , wie im Tutorial beschrieben die Files zusammen
1-a cross compiler named ppcrossavr.exe in c:\avrtest\win32\bin\i386-win32
2-compiled rtl units in c:\avrtest\units\avr-embedded\
und die
avr-embedded-Files

Weiter Versuche , die LAZ-IDE zum arbeiten zu bringen sind fehlgeschlagen , also erst mal auf andere Weise an die Sache rangegangen.

Habe mir einen neuen Ordner aufgemacht und alles nach und nach dort reingeschmissen .
also erst mal die
ppcrossavr.exe
und ein Mini-Testprogramm test2.pas.

Code: Alles auswählen

program test2; 
 
var
  DelayVar: Integer = 0;
 
procedure warte;
var
  I: LongInt;
begin
  for I := 0 to 80000 do
    Dec(DelayVar);
end;
 
 
begin
  DDRA := 255; // Prort A Ausgang
  while True do
  begin
     PORTA := %10000000; // Bit 8 auf 1
     warte;
     PORTA := %01000000; // Bit 7 auf 1
     warte;
   end;
end.


sowie eine Batch-Datei Z_PAS_to_AVR.bat zum aufrufen
mit dem Inhalt

Code: Alles auswählen

ppcrossavr.exe test2.pas -Wpatmega16


und immer wenn ppcrossavr.exe gemeckert halt alles mögliche hinzugepackt.
Alle Files , des aus dem Tutorial erzeugten C:\avrtest\Win32\units\avr-embedded\rtl -Ordners
Dann alle Files aus meiner Lazarus-Installation C:\lazarus\fpc\3.0.0\bin\i386-win32

Irgenwann hat ppcrossavr.exe nicht mehr gemeckert und ein HEX-File von meinem test2.pas erzeugt.
Was ppcrossavr.exe nun wirklich alles davon braucht und ob noch weitere Files im Laufe der Zeit gebaucht werden , keine Ahnung .
Habe mal alles in eine ZIP gepackt , siehe Anhang.

Zum ausprobierem, ob das test2.hex auch funzt habe ich es mit meinem
usbtiny-Progger auf mein Mega16-Testboard geladen

avrdude.exe -u -B 1574.9059703 -C "avrdude.conf" -p m16 -P usb -c usbtiny -U flash:w:"test2.hex":a

Alles gut bis dato, der Mega16 macht was er soll , die LED's blicken .

Was ich nun brauche ist eine kurze Anleitung , wie ich die Lazarus-IDE einzustellen habe , damit ich vernüftig arbeiten kann.
Per Editor ne PAS erzeugen und dann kompilieren ist nicht so das gelbe vom Ei.

Gruß

Frank
Dateianhänge
PAS_to_AVR_TEST.zip
(11.83 MiB) 89-mal heruntergeladen
www.flz-vortex.de

Mathias
Beiträge: 6160
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: FPC fit für PIC & AVR

Beitrag von Mathias »

Was ein Wunschtraum ist, wäre, das man bei "Konfiguration und Ziele", den Arduino/Atmega anwählen könnte, und den Port "/dev/ttyUSB0".

Und anschliessend man nur noch F9 drücken könnte.

Und der Code dazu würde dann etwas so aussehen:

Code: Alles auswählen

unit Blink1;
 
interface
 
uses
  Arduino;
 
procedure setup;
procedure loop;
 
implementation
 
procedure setup;
begin
  pinMode(LED_BUILTIN, OUTPUT);
end;
 
procedure loop;
begin
  digitalWrite(LED_BUILTIN, HIGH);
  delay(1000);
  digitalWrite(LED_BUILTIN, LOW);
  delay(1000);
end;
 
end.       


Träumen kann man ja. :wink:
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

Frank Ranis
Beiträge: 201
Registriert: Do 24. Jan 2013, 21:22

Re: FPC fit für PIC & AVR

Beitrag von Frank Ranis »

Hallo ,

es läßt mich ja nicht los.

Unter YouTube gibt es ein Video , da wir genau das gemacht , was ich haben will .
https://www.youtube.com/watch?v=c3wwNW7BRPI

Also neuer Versuch mit der LAZ-IDE und AVR.
Das nachgemacht , was im Video zu sehen war.
Leider ohne Erfolg (alle möglichen diffusen Fehlermeldungen) , keine Ahnung was der Kollege da noch vorher so alles vorbereitet hat.

Nun habe ich mal einen anderen Ansatz versucht , mit dem ich so halbwegs leben kann.
Zunächst habe ich mal den Ordner mit den ganzen Sammel-Files (siehe oben PAS_to_AVR_TEST.zip) aufgeräumt .
Alles was nicht benötigt wird weggeworfen.
Im Anhang ein neues ZIP (PAS_to_AVR_TEST2.zip).

Nun mach ich ganz normal die Laz-IDE auf .
Gehe nach 'Werkzeuge' und hier 'externe Werkzeuge einrichten...' .
Hier habe ich mir zwei Tools angelegt.
1) Compile PAS for AVR
2) Übertrage per USBTINY
Im Fenster 'externe Werkzeuge einrichten...' gibt es einen Button 'Mehr' und dort im Schalter 'Import' .
Mit diesen kann das File 'AVR_extern_tool.xml' geladen werden , welches in der (PAS_to_AVR_TEST2.zip) mit drinnsteckt.

Nach dem Laden sollten dann die beiden Einträge
Compile PAS for AVR
Übertrage per USBTINY
vorhanden sein .

Nun wählt man den ersten Eintrag (Compile PAS for AVR) an und dann auf den Button 'Bearbeiten' klicken.
Im Fenster oben findet man
1) Den Titel der Funktion
2) Der Pfad und das Programm , welches ausgeführt werden soll , hier wählt man das Programm 'ppcrossavr.exe' ,welches auch im (PAS_to_AVR_TEST2.zip) steckt.
Der Pfad ist von meinem Rechner , muß also geändert werden.
3) Die Parameter , die dem Crosscompiler (ppcrossavr.exe) übergeben werden sollen.
$Name($TargetFile()) -Wpatmega16 -a

$Name($TargetFile()) ist eine Liste von Macros (Beschreibung unten im Fenster) und geben den Pfad des Project-Files (z.B. Test2.pas) an.
-Wpatmega16 , ist der von mir benutzte Prozessor (ATMega16) , muß also an euern Prozessor angepasst werden.
-a sagt , das ein *.s File angelegt werden soll , ist ganz interessant , hier steht der Assembler-Code drinn , den der Crosscompiler erzeugt hat.

Nun zur zweiten Funktion 'externe Werkzeuge' (Übertrage per USBTINY).
Auch hier wieder anwählen und auf den Button 'Bearbeiten' klicken.
1) Titel der Funktion
2) der Pfad zum Programm 'avrdude.exe' einstellen , ist auch im (PAS_to_AVR_TEST2.zip) enthalten.
3) Die Aufrufparameter einstellen.
-u -B 1 -C "avrdude.conf" -p m16 -P usb -c usbtiny -U flash:w:"$NameOnly($TargetFile()).hex":a

AVRDude ist ein Programm , das unser HEX File in den Prozessor läd.
Die Parameter kann man in der Doku 'avrdude-doc-6.3.pdf' , auch im (PAS_to_AVR_TEST2.zip) lesen.
In der avrdude.conf stehen diverse Programmer , z.B. mein 'usbtiny' drinn.
Auch für den Arduino sollte das funzen , irgendwo hier hatte ich da schon was gelesen..

Die Parameter flash:w:"$NameOnly($TargetFile()).hex":a geben wieder den Pfad und den Namen des Projektfiles (unser Pascal-File) an .

So nun noch einiges zur Vorgehensweise :
wir löschen zunächt mal die Datei test3.hex in unserm neuen PAS_to_AVR_TEST2 - Ordner , damit wir kontrollieren können , ob der Crosscompiler richtig funzt.
1) test3.lpi starten
2) die neue Funktion (Compile PAS for AVR) unter Menü/Werkzeuge starten.
Es sollte nun eine LAZ-Nachricht kommen , 'Compile PAS for AVR: Erfolg'
und im Sammelordner sollte die Test3.hex zu finden sein.

3) Dann die neue Funktion (Übertrage per USBTINY) unter Menü/Werkzeuge starten.
Es sollte dann die LAZ-Nachricht kommen , 'Übertrage per USBTINY:Erfolg'

Der Prozessor sollte nun arbeiten.
Wenn nicht , dann ist vermutlich irgend etwas mit den Aufrufparametern nicht in Ordnung.

Achtung:
Wenn etwas im Quelltext verändert wurde , muß man den Programm-Code zunächst per 'alles Speichern' wegschreiben .
Den der Crosscompiler 'ppcrossavr.exe' und auch 'AVRDude.exe' greifen direkt auf die vorhandenen Files im Sammel-Ordner zu , wissen also nichts von der Änderung.
Das ist nun noch ein Nachteil meiner Vorgehensweise .
Schick wäre , wenn man den Startbutten in der IDE so umbiegen könnte , das er
1) das Projekt wegspeichert
2) die Funktion 'externe Werkzeuge/Compile PAS for AVR'.
3) die Funktion 'externe Werkzeuge/Übertrage per USBTINY'.
aufruft , ohne sich um die Standardaufgabe des Lazarus (Compilieren / Linken) zu kümmern .

Als nächstes steht die Aufgabe vor der Tür , den schmale Funktionsumfang des FPC-for-AVR etwas zu erweitern.
So gibt es z.B. keinerlei Unterstützung von Fließkomma-Operationen , das ist natürlich doof , wenn man etwas Mathe braucht.
Also müßen diverse Methoden nachgebaut oder irgenwo (z.B. als ASM-Code) zusammengeklaut werden.
Bei den Units 'convert.pas' , 'avr_serial.pas' , 'convert.pas' habe ich damit mal rumprobiert und etwas gesammelt.
In Test2.lpi werden sie benutzt.
Auch für so Geschichten wie LCD-Anzeige , Interupt usw. müßte noch was zusammengetragen werden.
Und die Einstellerei des Prozessortyps ist noch unelegant .
Man muß diesen per Parameter an 'ppcrossavr.exe' und auch 'AVRDude.exe' übergeben, dummerweise auch noch in verschiedenen Schreibweisen , einmal als '-Wpatmega16' und das andere Mal mit '-p m16' .
Ein wenig Automatik wäre schick, evetuell hat ja jemand eine Idee hierzu.

Gruß

Frank
Dateianhänge
PAS_to_AVR_TEST2.zip
(3.77 MiB) 92-mal heruntergeladen
www.flz-vortex.de

Benutzeravatar
kupferstecher
Beiträge: 418
Registriert: Do 17. Nov 2016, 11:52

Re: FPC fit für PIC & AVR

Beitrag von kupferstecher »

Hallo Frank,

vor Kurzem hab ich mich auch mal mit dem AVR versucht und ich hoff ja, dass sich der FPC hier, d.h. im Embedded-Bereich, auch etablieren kann.

Frank Ranis hat geschrieben:Unter YouTube gibt es ein Video , da wir genau das gemacht , was ich haben will .
https://www.youtube.com/watch?v=c3wwNW7BRPI

Das Video hab ich mir angeschaut, das klappt bei mir genauso. :-)
Allerdings funktioniert ein Ausführen mit F9 nicht, auch im Video klickt er Strg+F9 also das reine Kompilieren. Du kannst aber in den Projekteinstellungen unter Compilereinstellungen/Compiler-Kommandos im Bereich "Nachher ausführen" deinen Programmer aufrufen. So kann man tatsächlich mit Strg+F9 aus Lazarus heraus compilieren und das Programm direkt hochladen.

Wie man die IDE genau dazu bekommt auf Target AVR zu kompilieren kann ich jetzt auch nicht mehr nachvollziehen. Es ist nämlich schon ne Weile her, als ich den Crosscompiler compiliert hab und damals hab ich ich den ppcrossavr nur über Kommandozeile benutzt, also nicht aus Lazarus raus.
Zu den Projekteinstellungen kann ich dir aber folgendes sagen (Als Vorlage habe ich Neu/Projekt/Einfaches Programm verwendet):
- Compilereinstellungen/Konfiguration und Ziele/Zielbetriebssystem -> Embedded
- Compilereinstellungen/Konfiguration und Ziele/Ziel-CPU-Familie -> avr
- Compilereinstellungen/Konfiguration und Ziele/Zielprozessor -> avr5 (*je nach dem welcher AVR)
- Compilereinstellungen/Benutzerdefinierte Einstellungen -> In das obere Feld "Benutzerdefinierte Einstellungen" den Aufrufparameter für deinen Prozessortyp eintragen, z.B. "-Wpatmega32" für einen AtMega32.
- Compilereinstellungen/Debuggen -> hier muss alles aus sein.

Frank Ranis hat geschrieben:Auch für so Geschichten wie LCD-Anzeige , Interupt usw. müßte noch was zusammengetragen werden.

Hast du den Artikel AVR_Programming im Freepascal-Wiki schon gesehen? Interrupts und Inline-ASM ist dort beschrieben, es lässt sich also die komplette Hardware auch einsetzen.
http://wiki.freepascal.org/AVR_Programming#Interrupts

Grüße

EDIT: Den Compilerpfad habe ich als Umgebungsvariable (PATH) abgelegt, vermutlich hat Lazarus darüber dann Zugriff auf den Kompiler und die Binutils. An Config-Dateien habe ich nämlich nichts verändert/eingestellt. Unter dem Pfad liegen die Programme ppcrossavr.exe, as.exe, ld.exe und objcopy.exe
Beim Starten von Lazarus meckert dieser, dass keine Konfigurationsdatei vorhanden sei, hat aber keine weitere Auswirkung.

Frank Ranis
Beiträge: 201
Registriert: Do 24. Jan 2013, 21:22

Re: FPC fit für PIC & AVR

Beitrag von Frank Ranis »

Hallo kupferstecher,

hast Du eventuell nen Vornamen ? , wäre schöner .

>>>>
Hast du den Artikel AVR_Programming im Freepascal-Wiki schon gesehen? Interrupts und Inline-ASM ist dort beschrieben, es lässt sich also die komplette Hardware auch einsetzen.
http://wiki.freepascal.org/AVR_Programming#Interrupts
<<<<

Ja , habe ja alles mögliche gesammelt was ich im Zusammenhang mit AVR und LAZ/FPC finden konnte.

>>>>
Wie man die IDE genau dazu bekommt auf Target AVR zu kompilieren kann ich jetzt auch nicht mehr nachvollziehen. Es ist nämlich schon ne Weile her, als ich den Crosscompiler compiliert hab und damals hab ich ich den ppcrossavr nur über Kommandozeile benutzt, also nicht aus Lazarus raus.
Zu den Projekteinstellungen kann ich dir aber folgendes sagen (Als Vorlage habe ich Neu/Projekt/Einfaches Programm verwendet):
- Compilereinstellungen/Konfiguration und Ziele/Zielbetriebssystem -> Embedded
- Compilereinstellungen/Konfiguration und Ziele/Ziel-CPU-Familie -> avr
- Compilereinstellungen/Konfiguration und Ziele/Zielprozessor -> avr5 (*je nach dem welcher AVR)
- Compilereinstellungen/Benutzerdefinierte Einstellungen -> In das obere Feld "Benutzerdefinierte Einstellungen" den Aufrufparameter für deinen Prozessortyp eintragen, z.B. "-Wpatmega32" für einen AtMega32.
- Compilereinstellungen/Debuggen -> hier muss alles aus sein.
<<<<

Der vorletzte Punkt , mit den Aufrufparametern hatte ich nicht auf dem Zettel.
Nun kann ich auch direkt compilieren , zusammen mit dem automatischen Wegspeichern der Quelldaten.
Super.

>>>>
Allerdings funktioniert ein Ausführen mit F9 nicht, auch im Video klickt er Strg+F9 also das reine Kompilieren. Du kannst aber in den Projekteinstellungen unter Compilereinstellungen/Compiler-Kommandos im Bereich "Nachher ausführen" deinen Programmer aufrufen. So kann man tatsächlich mit Strg+F9 aus Lazarus heraus compilieren und das Programm direkt hochladen.
<<<<

Strg+F9 funzt bei mir nicht , da bekomme ich immer eine Fehlermeldung

Code: Alles auswählen

Build File C:\Dokumente und Einstellungen\Anwender\Desktop\Neuer Ordner (2)\test2_Mega32.pas: fehlende ausführbare Datei "", Fehler: 1
Panic: interner Fehler: fehlende ausführbare Datei ""


Ausführbare Datei? , als wenn LAZ ne EXE bauen wollte !!! , obwohl doch (Embedded / AVR / AVR5) eingestellt ist .

Was aber funktioniert ist Shift+F9 , da macht LAZ alles ohne Mecker.

Code: Alles auswählen

Projekt kompilieren, OS: embedded, CPU: avr, Ziel: test2_Mega32: Erfolg


Nun gut , ist bestimmt noch irgendwo ne Einstellung falsch , man kann aber so damit leben.

>>>>
und ich hoff ja, dass sich der FPC hier, d.h. im Embedded-Bereich, auch etablieren kann.
<<<<

Ob sich das durchsetzt ? , da habe ich momentan noch meine Bedenken.
Und zwar aus dem folgenden Grund.

Die kompilierte Bin-File-Größe geht gar nicht .
Bei etwas aufwendigeren Programmen hat man Filegrößen , die dann nicht mehr in die Prozessoren <ATMega16 passen.

Einfaches Bespiel , was ich probiert habe :
Ich möchte ganz schlicht von 0-255 zählen und die Zahl an einen Port auf LED's ausgeben.
Nach jedem Inc der Zahl soll eine kurze Pause gemacht werden , damit man auch etwas sieht.

also

Zahl als Byte

anfang:
inc(zahl)
Ausgabe auf Port
warte kurz
jump anfang

Zuerst habe ich das Teil in Assembler geschieben (mit den paar Brocken , die ich schon kann).
Habe dazu den Assembler gavrasm.exe von Gerhard Schmidt benutzt , weil dieser (passender Weise) in FreePascal geschrieben ist und die Quellen offen sind.

Test_LED_Schleife.asm

Code: Alles auswählen

; Programm LED Ausgabe mit INC und Warten
 
.DEVICE ATMEGA32
.LIST ; Ausgabe im Listing einschalten
;
; Register definieren
;
.def zaehler_frank = r30 ;
;
; Konstanten definieren
;
.equ cInnen = 500 ; Zaehler Innere Schleife
.equ cAussen = 255 ; Zaehler Aeussere Schleife
;
; Programmstart
 
; StapeI einstellen
 .DEF MeinLieblingsRegister = R16
 
 LDI MeinLieblingsRegister, HIGH(RAMEND) ; Oberes Byte
 OUT SPH,MeinLieblingsRegister ; an Stapelzeiger
 LDI MeinLieblingsRegister, LOW(RAMEND) ; Unteres Byte
 OUT SPL,MeinLieblingsRegister ; an Stapelzeiger
;
 ldi r16,$ff
 out DDRB,r16 ; Port B komplett auf Ausgang
 
;
; Programmschleife
;
      ldi zaehler_frank,0
anfang:
      inc zaehler_frank
      out PORTB,zaehler_frank
      rcall warte ; Verzögerung
      rjmp anfang ; von vorne beginnen
 
 
; Unterprogramm Warte
warte:
      push R16
      push R24
      push R25
 
      ldi R16,cAussen ; aeusserer 8-Bit-Zaehler setzen
Schleife:
      ldi R25,HIGH(cInnen) ; Innerer 16-Bit-Zaehler setzen
      ldi R24,LOW(cInnen)
Schleifei:
     sbiw R24,1 ; Inneren 16-Bit-Zaehler abwaerts zaehlen
     brne Schleifei ; wenn noch nicht Null: zurueck
     dec R16 ; aeusseren 8-Bit-Zaehler abwaerts
     brne Schleife ; aeussere 8-Bit-Schleife wiederholen
 
     pop R25
     pop R24
     pop R16 
    ret
 

Hex-Filegröße 182 Byte
Bin-Filegröße 50 Byte

Dann LAZ angeschmissen und das gleiche in Pascal geproggt.

Test_LED_Schleife.pas

Code: Alles auswählen

program test_led_schleife;
 
{$mode objfpc}{$H+}
 
var zaehler_frank:byte;
 
procedure warte_etwas;
label schleife,schleifei;
var cAussen:byte;
    cInnen:word;
begin
     cAussen:=255; //aeusserer 8-Bit-Zaehler setzen
Schleife:
     cInnen:=500; // Innerer 16-Bit-Zaehler setzen
Schleifei:
     dec(cinnen); // Inneren 16-Bit-Zaehler abwaerts zaehlen
     if cinnen>0 then goto Schleifei; // wenn noch nicht Null: zurueck
     dec(cAussen); // aeusseren 8-Bit-Zaehler abwaerts
     if cAussen>0 then goto Schleife; // aeussere 8-Bit-Schleife wiederholen
end;
 
// Programmanfang
begin
 DDRB := 255; // Prort B Ausgang
 zaehler_frank:=0;
 
 // Endlosschleife
 while True do
  begin
   inc(zaehler_frank);
   portb := zaehler_frank;
   warte_etwas;
  end;
end.               
 


Hex-Filegröße 930 Byte
Bin-Filegröße 322 Byte

Nun gut 50 Byte zu 322 Byte , Faktor 6,44 , lassen wir mal so duchgehen , weil es passt ja rein in die Prozessoren.

Nun habe ich aber die Warteschleife nach dem Tutorial AVR Programming eingebaut.
Also mit ASM-Code drinn

Code: Alles auswählen

program test_led_schleife;
 
{$mode objfpc}{$H+}
 
var zaehler_frank:byte;
Const
  f_CPU = 16000000; //Hertz
 
{procedure warte_etwas;
label schleife,schleifei;
var cAussen:byte;
    cInnen:word;
begin
     cAussen:=55; //aeusserer 8-Bit-Zaehler setzen
Schleife:
     cInnen:=500; // Innerer 16-Bit-Zaehler setzen
Schleifei:
     dec(cinnen); // Inneren 16-Bit-Zaehler abwaerts zaehlen
     if cinnen>0 then goto Schleifei; // wenn noch nicht Null: zurueck
     dec(cAussen); // aeusseren 8-Bit-Zaehler abwaerts
     if cAussen>0 then goto Schleife; // aeussere 8-Bit-Schleife wiederholen
end;}

 
// Waitingtime = Time * 10 Milliseconds
Procedure Wait10m(Time:Byte);
const
  Faktor = 15*f_CPU div 1000000;
label    //Labels, here for the loop, has to be declared explicitly
  outer,inner1,inner2;
var
  tmpByte: byte;   //In Inline assembler local variables are accesed by the instructions LDD and STD, global variables are accessed by LDS and STS.
begin
asm               //asm states inline assembly block until the next END statement
  ldd r20,Time    //Variables can be accessed, here a local variable
  outer:
    ldi r21, Faktor
    inner1:         ////640*Faktor= 640*15*1 = 9600 cycles/1MHz
      ldi r22,128
      inner2:       ////5*128 = 640 cycles
        nop         //1 cycle
        nop         //1 cycle
      dec r22       //1 cycle
      brne inner2     //2 cycles in case of branch //one loop in sum 5 cycles
    dec r21
    brne inner1
  dec r20
  brne outer
 
end['r20','r21','r22']; //Used registers to be published to compiler
end;//procedure
 
 
// Programmanfang
begin
 DDRB := 255; // Prort B Ausgang
 zaehler_frank:=0;
 
 // Endlosschleife
 while True do
  begin
   inc(zaehler_frank);
   portb := zaehler_frank;
   // warte_etwas;
   Wait10m(5);
  end;
end.
 


Hex-Filegröße 840 Byte
Bin-Filegröße 290 Byte

Oh eine Verbesserung , durch Einbau von ASM.
Nun 50 Byte zu 290 Byte , Faktor 5,8


Nun hatte ich den Wunsch , die Wartezeit direkt in ms zu übergeben und habe daher die Warteprocedure etwas umgeschrieben.
Mit etwas Berechnungen drinn , also die Konstate Faktor durch eine Variable Faktor ersetzt.

Code: Alles auswählen

// Waitingtime[ms]
Procedure Waitms(Time:word)// max 2.55 sec
label    //Labels, here for the loop, has to be declared explicitly
  outer,inner1,inner2;
var
 faktor:byte;
 time2:byte;
begin
 time2:=time div 10;
 faktor:=15*f_CPU div 1000000;
asm               //asm states inline assembly block until the next END statement
  ldd r20,Time2    //Variables can be accessed, here a local variable
  outer:
   ldd r21,faktor   // faktor ldd=Variable laden
    inner1:         //640*Faktor= 640*15*1 = 9600 cycles/1MHz
      ldi r22,128   // ldi=Konstate laden
      inner2:       ////5*128 = 640 cycles
        nop         //1 cycle
        nop         //1 cycle
      dec r22       //1 cycle
      brne inner2     //2 cycles in case of branch //one loop in sum 5 cycles
    dec r21
    brne inner1
  dec r20
  brne outer
end['r20','r21','r22']; //Used registers to be published to compiler
end;                             
 


Und dann hat es mir die Füße weggezogen .
Hex-Filegröße 3679 Byte
Bin-Filegröße 1300 Byte

Diese beiden Zeilen

Code: Alles auswählen

 time2:=time div 10;
 faktor:=15*f_CPU div 1000000;
 


haben , sage und schreibe 1010 Byte mehr Speicher verbraucht.
Öh , ja , der Faktor 50 Byte zu 1300 Byte ist nun 26.

Benutzt man also Pascal-Rechen-Routinen , dann zieht es einem den Boden unter den Füßen weg.

Die Frage ist nun.
Was kann man da tun, um nicht all zu schnell über die Flash-Speichergrenzen hinauszuschießen ?

Alle möglichen Rechenoperationen auch in AVR-ASM schreiben ?
Dann kann man aber auch gleich zur direkten Assembler-Programmierung übergehen und bekommt so Bin-File-Größen , die auch in die kleinsten CPU's passen.
Auch das Timing-Verhalten hätte man mit ASM besser im Griff , weil ja kein unnützer Code durchlaufen wird.
Ich bin mir nun sehr unsicher, welchen Weg man weiter geht.

Gruß

Frank
www.flz-vortex.de

Benutzeravatar
kupferstecher
Beiträge: 418
Registriert: Do 17. Nov 2016, 11:52

Re: FPC fit für PIC & AVR

Beitrag von kupferstecher »

Hallo Frank,

kupferstecher ist mein Künstlername ;-)


>>Strg+F9 funzt bei mir nicht , da bekomme ich immer eine Fehlermeldung

Strg+F9 heißt ja eigentlich "Kompilieren" siehe im Menüpunkt "Start". Es scheint bei dir wird stattdessen F9 gerufen und dann sucht Lazarus wohl tatsächlich nach einer Exe. Mit Shift+F9 geht es ja aber.
Es gibt einen Menuepunkt "Projekt ist lauffähig" in der Projekteinstellungen/Verschiedenes. Ist dieser abgewählt dann funktioniert aber auch F9 nicht mehr.

>>Ob sich das durchsetzt ? , da habe ich momentan noch meine Bedenken.
>>Und zwar aus dem folgenden Grund. Die kompilierte Bin-File-Größe geht gar nicht .

Die Qualität der Codeerzeugung kann ich auch nicht beurteilen. Ich habe bisher mit dem FPC nur das Blinky-Programm und eine Kommunikation über die Serielle Schnittstelle gemacht.

Einen Faktor zwischen ASM- und FPC-Programm zu bestimmen macht aber wenig Sinn, da die Programmgröße nicht linear skaliert. Insbesondere Bibliotheken tragen da zunächst dick auf, fallen aber bei großen Projekten weniger ins Gewicht. Und vermutlich passiert genau das beim Divisionsbefehl, der AVR hat ja keine Hardware-Division. Wenn du weitere Divisionen durchführst, werden die aber nur mit wenigen zusätzlichen Bytes zuschlagen und nicht jeweils 1kB verbrauchen. Ich weiß auch nicht, ob neben der Division nicht auch noch gleich andere Math-Befehle eingebunden wurden, man müsste sich vielleicht wirklich mal das Assemblerlisting anschauen.

mischi
Beiträge: 206
Registriert: Di 10. Nov 2009, 18:49
OS, Lazarus, FPC: macOS, 10.13, lazarus 1.8.x, fpc 3.0.x
CPU-Target: 32Bit/64bit

Re: FPC fit für PIC & AVR

Beitrag von mischi »

Einige allgemeine Bemerkungen: Wenn es wirklich um effektiven Code geht, würde ich aus mehreren Gründen fpc direkt aus der Kommandozeile nehmen, weil das letztlich schneller und direkter ist als über die Optionen in Lazarus. Was mir so an konkreten Gründen einfällt: Man kann die Optimierungsoptionen einfacher wechseln. Man kann Whole Program Optimisation machen. Man kann die Assembler Files aufheben und mit dem "manuellen" Assembler vergleichen. Daraus sollte sich dann auch erschließen, warum bestimmte Zeilen so viel Platz brauchen.
MiSchi macht die fink-Pakete

Benutzeravatar
kupferstecher
Beiträge: 418
Registriert: Do 17. Nov 2016, 11:52

Re: FPC fit für PIC & AVR

Beitrag von kupferstecher »

Zum Rumprobieren ist das sicher eine gute Möglichkeit. Da muss man halt noch mehr wissen, was man tut~

>>Man kann die Assembler Files aufheben und mit dem "manuellen" Assembler vergleichen. Daraus sollte sich dann auch erschließen, warum bestimmte Zeilen so viel Platz brauchen.

Du meinst die Option -a? Im Fall der Division kommt man hier nicht viel weiter (ich habs grad probiert). Die Softdivision ist eine Funktion, welche im Assemblerlisting aufgerufen wird. Die Funktion selber liegt aber in einer (riesigen) Objektdatei (System.o). Ich weiß nicht, ob es möglich beim Erstellen des Crosskompilers davon ein Assemblerlisting zu erzeugen/stehen zu lassen.

Die Frage war andererseits ja auch, wie effektiv der Code im allgemeinen ist, d.h. es geht nicht um punktuelle Verbesserungen. Wenn man sich die Warteroutine anschaut, scheint die Assemblerumsetzung schon ganz schön aufgebläht zu sein.

Wenn ich das richtig sehe, gibt es auch kein Volatile-Konzept in FPC, d.h. Variablem müssen immer in den RAM übertragen und zurückgelesen werden. Was sich sowohl in der Codegröße als auch in der Ausführgeschwindigkeit negativ niederschlägt.
Bitte berichtigt mich, wenn ich mich hier täusche.

_Bernd
Beiträge: 145
Registriert: Di 13. Feb 2007, 11:16

Re: FPC fit für PIC & AVR

Beitrag von _Bernd »

Frank Ranis hat geschrieben:>>>>
und ich hoff ja, dass sich der FPC hier, d.h. im Embedded-Bereich, auch etablieren kann.
<<<<

Ob sich das durchsetzt ? , da habe ich momentan noch meine Bedenken.
Und zwar aus dem folgenden Grund.

Die kompilierte Bin-File-Größe geht gar nicht .

Ich habe vor knapp einem Jahr ein Projekt erfolgreich in fpc auf einem Tiny1634 realisiert. Es hat 6888 Byte im FLASH belegt. Na und? Ich konnte es in einer Woche fertigstellen. In Assembler hätte ich mindestens die vierfache Zeit benötigt. Was die Performance angeht, habe ich den Eindruck, dass fpc im Vergleich zu anderen Pascal Compilern vorne liegt. Wenn ich etwas Zeit habe, dann werde ich mal ein paar Benchmarks machen.

Gruß, Bernd.

FPK
Beiträge: 65
Registriert: Mi 21. Mai 2008, 19:38
Wohnort: Erlangen

Re: FPC fit für PIC & AVR

Beitrag von FPK »

Frank Ranis hat geschrieben:

Code: Alles auswählen

program test_led_schleife;
 
{$mode objfpc}{$H+}
 
var zaehler_frank:byte;
 
procedure warte_etwas;
label schleife,schleifei;
var cAussen:byte;
    cInnen:word;
begin
     cAussen:=255; //aeusserer 8-Bit-Zaehler setzen
Schleife:
     cInnen:=500; // Innerer 16-Bit-Zaehler setzen
Schleifei:
     dec(cinnen); // Inneren 16-Bit-Zaehler abwaerts zaehlen
     if cinnen>0 then goto Schleifei; // wenn noch nicht Null: zurueck
     dec(cAussen); // aeusseren 8-Bit-Zaehler abwaerts
     if cAussen>0 then goto Schleife; // aeussere 8-Bit-Schleife wiederholen
end;
 
// Programmanfang
begin
 DDRB := 255; // Prort B Ausgang
 zaehler_frank:=0;
 
 // Endlosschleife
 while True do
  begin
   inc(zaehler_frank);
   portb := zaehler_frank;
   warte_etwas;
  end;
end.               
 


Hex-Filegröße 930 Byte
Bin-Filegröße 322 Byte

Nun gut 50 Byte zu 322 Byte , Faktor 6,44 , lassen wir mal so duchgehen , weil es passt ja rein in die Prozessoren.


Erstmal mit -O3/-O4 übersetzen. Ansonsten ist es nun mal so, dass Minimalprogramme in Hochsprachen einen gewissen Offset haben und damit haben solche Minimalbeispiele wenig bis gar keine Aussagekraft über Codegröße. FPC macht aus warte_etwas 15 Anweisungen (30 Bytes), Dein Code ist 14 Anweisungen, also 28 Bytes.

Antworten