Welche Programmiersprache soll ich lernen?

A-Freak schrieb:
> "C" und verwandte Sprachen muß ich ausschließen.

Das wäre aber die offensichtliche Wahl, die auch alle deine 
Anforderungen erfüllt. Außerdem dürfte es die bei weitem am meisten 
verwendete Sprache auf Mikrocontrollern sein.

> Alles was so mit "Pointer", "Casten", "Void()", "=" versus "==", Klammer-
> Konstruktionen und so Zeugs mir zu abstrakt, da habe schon mehrfach
> erfolglos versucht mir sowas in das Hirn zu prügeln.

Wenn dir das schon zu abstrakt ist, wirst du wohl auf Assembler runter 
müssen.

> Programmcode sollte ungefähr so aussehen
>
> Lesetemperatur:
>   Rohwert=ADC(3)
>   TemperaturinCelsius=Rohwert*1.11-68

Das sieht mir mehr nach sowas wie BASCOM aus. Das gibt's kostenlos aber 
nur in einer Demo-Version und nur für Windows.

Dr. Sommer schrieb:
> A-Freak schrieb:
>> "=" versus "=="
>
> Pascal, Ada. Aber die haben Casts (streng typisiert).

Da ist es statt "=" vs. "==" dann eben ":=" vs "=". Ist das nun so viel 
anders?

Pascal, Ada.

Freepascal kann Avr Embedded für Atmega und Attiny, auch AtXmega. Andere 
Controller wie Pic und Stm wohl auch, hab ich aber noch nicht gemacht.

Da Dir hier gleich erzählt wird, das ginge nur in C - wer nur einen 
Hammer hat, kann halt nur nageln... oder so - such Dir das deutsche 
Freepascal Forum, da kommst Du weiter.

Rolf M. schrieb:
>> TemperaturinCelsius=Rohwert*1.11-68
> Das sieht mir mehr nach sowas wie BASCOM aus.
In Bascom geht diese Rechnung nicht direkt, weil dieser Compiler nur 1 
Rechenoperation pro Zeile kann. Deshalb kommt es logischerweise auch 
ganz ohne ohne Klammerungen aus...

Da würde diese Rechnung also so aussehen:
TemperaturinCelsius=Rohwert*1.11
TemperaturinCelsius=TemperaturinCelsius-68

Siehe dort bei "Tipps und Tricks" im letzten Viertel:
https://rn-wissen.de/wiki/index.php?title=Bascom

Dr. Sommer schrieb:
> Solche Ausdrücke sind es eigentlich,
> die textuelle Sprachen mächtig machen... nur halt manche Opas wie Basic
> nicht.

Willst Du nicht doch wieder über das schreiben, von dem Du Ahnung hast - 
bei der Bravo?

"Solche Ausdrücke" konnte Opas AmigaBasic schon vor 30 Jahren, und 
andere Basics auch.

Und was der TO wahrscheinlicher meint, sind die {{({})(())}} 
Klammerorgien in C.

Zille schrieb:
> Der Assembler-Befehlssatz umfasst bei den
> PICs nur etwas über 30  unterschiedliche Befehle und ist somit (im
> Gegensatz zum ATTiny-Assembler) sehr schnell gelernt.

Dafür macht es der eingeschränkte Befehlssatz aber umso komplizierter, 
reale Aufgaben zu lösen. Und auch die ständigen Bankumschaltungen und 
PCLATH-Berechnungen (Codepageüberlauf) sind häufige Fallgruben.
Von PIC-Assembler würde ich daher einem Anfänger dringlichst abraten.

Generell sehe ich keinen Grund, heutzutage noch mit Assembler 
anzufangen.
Die Compiler und MCs sind leistungsfähig genug, daß marginale Vorteile 
in den Ausführungszeiten oder RAM/Flash-Nutzung weitgehend in den 
Hintergrund treten. Schnellere Entwicklung und geringere Fehlerquellen 
der Hochsprachen sind die entscheidenden Vorteile.

C hat den entscheidenden Vorteil, daß es für alle Plattformen verfügbar 
ist. C-Programme lassen sich also leicht an 8051, PIC, AVR, MSP430, ARM 
usw. anpassen. Assembler-Programme sind dagegen bei Wechsel der CPU für 
die Tonne.

A-Freak schrieb:
> Was gibt es denn heute und für absehbare Zukunft an imperativen
> Programmiersprachen die einigermaßen Hardwarenah sind und eine recht
> einfache und klare Syntax haben?

A-Freak schrieb:
> "C" und verwandte Sprachen muß ich ausschließen. Alles was so mit
> "Pointer", "Casten", "Void()", "=" versus "==", Klammer-Konstruktionen
> und so Zeugs mir zu abstrakt,

Das eine schließt das andere aus. "Zu abstrakt"? Abstraktion ist ja 
gerade Sinn und Zweck einer höheren Programmiersprache. Auf dem PC gäbe 
es noch Lazarus (Pascal), aber im Mikrocontrollerbereich ist C nun mal 
der Standard und wird es auf absehbare Zeit wohl auch noch bleiben. 
Gewöhn dich dran.

A-Freak schrieb:
> Programmcode sollte ungefähr so aussehen
>
> Lesetemperatur:
>   Rohwert=ADC(3)
>   TemperaturinCelsius=Rohwert*1.11-68

Sowas kann das Haustier meines Hundes schon programmieren. Und mein 
blinder Affe. Wer sollte dich für solch triviales Zeug bezahlen?

hilti schrieb:
> falls Du ausschliesslich AVRs programmieren möchtest, kannst Du Dir mal
> Luna anschauen:
>
> http://avr.myluna.de

Da wäre auch die Plattform "Linux" erfüllt.

Manfred F. schrieb:
> Auf dem PC gäbe
> es noch Lazarus (Pascal), aber im Mikrocontrollerbereich ist C nun mal
> der Standard und wird es auf absehbare Zeit wohl auch noch bleiben.

Nur weil Du es nicht besser weißt, wird es durch ständige Wiederholung 
nicht wahrer.

Die Leute, die professionell Controller in Ada oder Pascal 
programmieren, hängen halt nicht im uC Forum rum.

A-Freak schrieb:
> C [...] mir zu abstrakt

Sorry, aber wenn C schon zu abstrakt ist bleibt nur noch Assembler als 
nächst weniger abstrakte Sprache.

A-Freak schrieb:
> Programmcode sollte ungefähr so aussehen
>
> Lesetemperatur:
>   Rohwert=ADC(3)
>   TemperaturinCelsius=Rohwert*1.11-68

In C sieht das nicht viel anders aus:

1

float TemperaturinCelsius;

2

3

void Lesetemperatur( void )

4

{

5

  TemperaturinCelsius = ADC(3)*1.11-68;

6

}

HildeK schrieb:
> Aber wenn jemand, wie der TO, fast bei Null anfängt, dann kann ihm ein
> µC-Forum sehr viel helfen.

Also mein erster Gedanke war TO -> TROLL
(ansonsten stimme ich dir zu ;-)

Karl K. schrieb:
> "Solche Ausdrücke" konnte Opas AmigaBasic schon vor 30 Jahren, und
> andere Basics auch.
>
> Und was der TO wahrscheinlicher meint, sind die {{({})(())}}
> Klammerorgien in C.

Geht ja wieder sachlich hier zu. Dennoch, Recht hat er.

@TO. Versuche es doch mal mit, nennen wir es mal, 'Arduino C'. Pass auf, 
ich schreibe Dir jetzt mal was in VB und dann in C:

1

#VB

2

Dim i as Integer

3

for i = 0 to 10

4

   SetLEDValue(i)

5

next

6

7

//C

8

int i = 0;

9

for (i = 0; i < 11; i++)

10

{

11

  SetLEDValue(i);

12

}

Du siehst, soviel anders sieht das (erstmal) nicht aus.

ACDC schrieb:
> for (int i = 0; i < 11; i++)
>    SetLEDValue(i);

Ich wollte exemplarisch zeigen, dass i wie in VB auf einer separaten 
Zeile initialisiert wird. Natürlich geht das auch direkt im Ausdruck, in 
beiden Sprachen.

(1)
A-Freak schrieb:
> "Damals als ich noch jung war" konnte ich ziemlich gut BASIC und ein
> bißchen Assembler.

Als ich noch jung war, programmierte ich mit Basic meine ersten 
Spaghetti-Codes und war sehr dankbar, als dann für meinen Rechner 
Turbo-Pascal verfügbar wurde.

(2)
A-Freak schrieb:
> "C" und verwandte Sprachen muß ich ausschließen.

Das solltest Du nicht.

(3)
> Alles was so mit
> "Pointer", "Casten", "Void()", "=" versus "==", Klammer-Konstruktionen
> und so Zeugs mir zu abstrakt, da habe schon mehrfach erfolglos versucht
> mir sowas in das Hirn zu prügeln. Ansonsten sind mir grundlegende

Du schreibst, Du bist in der Welt der Analog- und HF-Technik zuhause. 
Wenn das für Dich keine schware Magie ist, kann C Dich nicht wirklich 
überfordern und ich würde bezweifeln, dass Deine 'mehrefach erfolglosen 
Versuche' sehr ernsthafte waren.

(4)
> Algorithmen und Abläufe sehr gut bekannt.
Das klingt für mich nach einem Widerspruch zu oben zitiertem.

(5)
Alles klar schrieb:
> C, was sonst?
Das würde auch ich grundsätzlich empfehlen, besonders in Hinblick auf:

A-Freak schrieb:
> Schwerpunkt wären ATTiny



(6)
Karl K. schrieb:
> Pascal, Ada.
>
> Freepascal kann Avr Embedded für Atmega und Attiny, auch AtXmega.
Meine letzten Berührungen mit Pascal und Ada fanden in meinen jungen 
Jahren an der Uni statt, was heißt, dass ich keine Ahnung habe, wie gut 
es sich damit auf µCs arbeitet.
Allerdings gibt es in diesen Sprachen ähnliche Konzepte wie in C, 
lediglich die Syntax ist anders.
 Pascal empfinde ich als geschwätzig im Vergleich zu C: begin und end 
statt { und }.

Du könntest Forth lernen ...

...real programmers can write Fortran in any language. ;-)

C/C++ ist nun mal DIE Universal-Sprache schlechthin wenn es um 
Programmierung von Mikrocontrollern geht. Eine einzige Sprache, sie alle 
zu knechten, in's Dunkel zu treiben und... ne, halt, das war was 
anderes.

Assembler würde ich heutzutage definitiv die Finger von lassen. Das 
nimmt man sinnvollerweise nur noch dann und ausschliesslich in den 
seltenen Fällen, wo es aus irgendeinem Grund nicht anders geht.

BASCOM scheint wirklich was zu sein, was den Wünschen des Threadstarters 
nahe kommen würde. Aber das ist halt auch wieder nur Windows, 
kommerziell etc.

Ich habe ja irgendwie den Eindruck, dass der Threadstarter in Wahrheit 
gar keine besonders hardwarenahe Sprache sucht.

Interessant wäre, warum der Threadstarter so ganz konkret auf Attinys 
abzielt. Sofern es dafür keinen wirklich guten Grund gibt, würde ich an 
seiner Stelle überlegen, ob es nicht auch ein deutlich 
leistungsfähigerer Mikrocontroller wie ESP8266 oder ESP32 sein kann. Die 
können nicht nur deutlich mehr als so ein popeliger Attiny, man kann sie 
auch in viel mehr Sprachen programmieren (C, (Micro)Python, LUA, 
JavaScript und und und)...

Ein Attiny macht doch im Grunde nur dann Sinn, wenn man kommerzielle 
Absichten bzw. riesige Stückzahlen im Hinterkopf hat, wo paar Cent 
Kostenersparnis für den allerbilligsten Mikrocontroller doch in's 
Gewicht fallen.
Aber wo es um kommerzielle Interessen mit riesigen Stückzahlen geht, 
wird man die Software doch nicht von einem Programmier-Laien in 
irgendeiner ominösen Programmiersprache programmieren lassen...

Joachim S. schrieb:
> Ein Attiny macht doch im Grunde nur dann Sinn, wenn man kommerzielle
> Absichten bzw. riesige Stückzahlen im Hinterkopf hat

...oder aber etwas räumlich sehr kleines bauen will aber QFN-Gehäuse 
scheut.

HildeK schrieb:
> naja, irgend eine Unterscheidung zwischen einer Zuweisung und einem
> Vergleich braucht jede Sprache. Woher soll denn der Compiler wissen, was
> du gerade haben möchtest?
In VHDL ist ein <= mal eine Zuweisung und mal ein Vergleich. Je nachdem, 
wo das steht:

1

if a <= b then

2

   a <= b;

3

end if;

Man kann da wegen der syntaktischen Regulierung eben nicht in einer 
Abfrage gleichzeitig eine Zuweisung machen...

HildeK schrieb:
> Es schränkt jedenfalls gewisse Freiheiten ein, vielleicht wäre das
> manchmal auch von Vorteil.
Das ist das, was einem Bekannten von mir an Bascom so gefällt: man 
MUSS alles Schritt für Schritt machen, deshalb kann man pro Zeile gar 
nicht allzuviel falsch machen.

Mir ist ein Programm, das länger als 1 Bildschirmseite ist, schon 
suspekt. Da verliere ich langsam den Überblick... ;-)

Als Basic Compiler kann ich das Freie OpenSource GreatCowBASIC 
empfehlen.
Es kann mit PIC 10-18 und AVR um. Eine sehr aktive Community, Libraries, 
bis der Arzt kommt.
Eine sehr ausführliche aktuelle Dokumentation und ein Hilfesystem.

Plattformunabhängig, ich nutze es mit Linux und verwende Geany als IDE, 
obwohl man auch die mitgelieferte IDE nutzen kann, aber mir ist es 
komplett nativ mit Linux lieber.
Bitte schaue dich auf der Homepage und dem Forum um.
http://gcbasic.sourceforge.net/Typesetter/index.php/Home

Den compilierten Code kann man sich auch ansehen, es gibt einen 
Assembler output, der mit den Basic Code im Kommentarbereich eine schöne 
Sache ist.

Bei Fragen zur Linux Installation stehe ich zur Verfügung

Bernd D. schrieb:
> Als Basic Compiler kann ich das Freie OpenSource GreatCowBASIC
> empfehlen.
> Es kann mit PIC 10-18 und AVR um.

Passt das auch in die kleinsten AVRs (sprich: die Tinies)?

M.A. S. schrieb:

> Passt das auch in die kleinsten AVRs (sprich: die Tinies)?

Ja.
Es ist ein Compiler.

1

ls tiny*

2

tiny10.dat  tiny13a.dat  tiny1634.dat  tiny22.dat     tiny24a.dat  tiny261a.dat  tiny28.dat    tiny43u.dat  tiny44.dat    tiny461.dat  tiny5.dat    tiny84a.dat  tiny861a.dat  tiny88.dat

3

tiny11.dat  tiny13.dat   tiny167.dat   tiny2313a.dat  tiny24.dat   tiny261.dat   tiny40.dat    tiny441.dat  tiny45.dat    tiny48.dat   tiny828.dat  tiny84.dat   tiny861.dat   tiny9.dat

4

tiny12.dat  tiny15.dat   tiny20.dat    tiny2313.dat   tiny25.dat   tiny26.dat    tiny4313.dat  tiny44a.dat  tiny461a.dat  tiny4.dat    tiny841.dat  tiny85.dat   tiny87.dat

A-Freak schrieb:
> ATTiny zur Ablaufsteuerung und Signalverarbeitung.

Signalverarbeitung auf einem ATTiny?? Ok, wenn du meinst...
Von mir aus gesehen ist das wohl ein Thema für DSP, ARM oder FPGA.

P.Loetmichel schrieb:
> 90 % aller Profis programmieren in BASCOM!

Mhm, hätte eher das umgekehrte Verhältnis vermutet. Da ich weder im 
Lehrbetrieb, Lehre, Studium oder jetzt in der "Profi-Welt" jemals einer 
gesehen habe der mit BASCOM ein uC programmiert...

Ausserdem haben sie wohl die Profis in den aktuellen Studien vergessen:
https://jaxenter.de/programmiersprachen-rankings-q1-2017-54308

Ich persönlich würde C empfehlen, wenn du dich wirklich nur in der uC 
Welt bewegst. Sobald du aber auch irgend welche kleinen Tools für den PC 
brauchst oder dich einmal von uC auf FPGA und SW-Programmierung bewegst, 
wirst du wohl nicht um C++ herum kommen.
Mit der Kombination C/C++ kannst du von simplen uC Firmware, FPGA, DSP, 
PC (OS unabhängig) bis zur SPS alles umsetzen. Ob das dann in deinem 
Betrieb auch genutzt wird, ist eine andere Frage.

Bernd D. schrieb:
> Ja.
> Es ist ein Compiler.

Danke für die Info. :)

Patrick B. schrieb:
> Signalverarbeitung auf einem ATTiny?? Ok, wenn du meinst...
> Von mir aus gesehen ist das wohl ein Thema für DSP, ARM oder FPGA.

Das kommt auf die Signale an.

W.S. schrieb:
> Also, jetzt sag mal, welche Ada oder Pascal Compiler für z.B. die
> Arm-Cortexe es gibt, die in ihrer Qualität an den Keil oder IAR
> herankommen.

Keine Ahnung obs was taugt, aber angeboten wird es:
https://www.ghs.com/products/AdaMULTI_IDE.html

W.S. schrieb:
> Und es soll mir keiner sagen, daß C da irgendwelche sprachlichen
> Vorteile hätte, die hat es nämlich nicht.

Ich bin kein Gegner anderer Sprachen als C. Aber:

> Der einzige Grund, weswegen
> heutzutage C quasi ubiquitär ist, besteht darin, daß es dafür gute
> Compiler gibt.

Wie erklärst Du, dass es so ist? Warum haben sich alle auf C gestürzt 
und Pascal vernachlässigt, wenn C keine Vorteile bietet?

W.S. schrieb:
> Pascal wäre auch für die µC-Programmierung die weitaus bessere Sprache
> als C, wenn es denn die dafür geeigneten Compiler gäbe. Aber das ist
> leider nicht der Fall, weil Pascal seit Jahren vernachlässigt worden
> ist.

Pascal ist nicht vernachlässigt worden, sondern Pascal ist tot. Denn der 
Nachfolger von Pascal ist seit 1978(!) Modula2 - ebenso von Niklas Wirth 
entwickelt. Der Nachfolger von Modula2 ist Modula3. Und der Nachfolger 
von Modula im allgemeinen ist seit 1994 Oberon, ebenfalls u.a. von 
Niklas Wirth.

Wenn, dann lass uns besser über Oberon reden statt über einen 
Dinosaurier, den niemand mehr zum Leben erwecken will.

Oberon ist strukturierter als Pascal, mächtiger, gleichzeitig aber 
erheblich weniger umfangreich als Modula-2. Man kann in Oberon auch 
Betriebssysteme schreiben, das heisst, es gibt Interfaces zur Hardware, 
welche für Pascal als rein akademisches Werk gänzlich fehlen.

Du willst einen Dino (C) durch einen anderen Dino (Pascal) ersetzen. 
Allein schon dieser Ansatz ist zum Scheitern verurteilt.

Frank M. schrieb:
> Und der Nachfolger
> von Modula im allgemeinen ist seit 1994 Oberon, ebenfalls u.a. von
> Niklas Wirth.

Gibt es Oberon-Compiler für µCs?


PS: Danke übrigens für das Anheben des SNR!  ;)

Herr B. schrieb im Beitrag #5531581:
> Der Mann heißt Niklaus Wirth.

Trotzdem danke für den Hinweis.


PS: irgendwie empfange ich hier wieder so ein Rauschen...

M.A. S. schrieb:
> Gibt es Oberon-Compiler für µCs?

Glaube ich nicht, genausowenig wie es verwendbare Pascal-Compiler für 
µCs gibt. Daher ist diese ganze Diskussion C vs. Pascal für den TO wenig 
hilfreich.

Apropos Pascal: Es wurde schon einmal wiedergeboren, nämlich als 
"Component Pascal". Hier diente Oberon als Vorlage. "Component Pascal" 
hieß 1994 erst "Oberon/L", wurde dann später aber in "Component Pascal" 
umbenannt. Mit dem ursprünglichen Pascal, von welchem W.S. immer mal 
wieder schwärmt, hat es natürlich nur noch wenig gemeinsam.

Interessant:

https://de.wikipedia.org/wiki/Component_Pascal

Allein schon die dort aufgeführten Programmbeispiele wecken Lust auf 
mehr. Trotzdem wird sich auf dem µC-Sektor in absehbarer Zeit nicht viel 
tun, C/C++ also als Standard bestehen bleiben.

Wahrscheinlich ist dem TO mit einem µC-tauglichen Basic am besten 
geholfen, auch wenn er es für Linux als Plattform wahrscheinlich nicht 
finden wird.

Um nochmal zu Basic zurück zu kommen.
Ich hatte letztes Jahr in meinem Blog dazu etwas geschrieben.
http://zockertown.de/s9y/index.php?/archives/1677-Great-Cow-BASIC-Compiler-v0.98.00.html

Da mein Blog rein privat und Werbefrei ist, geht das hoffentlich in 
Ordnung

Frank M. schrieb:
> Wahrscheinlich ist dem TO mit einem µC-tauglichen Basic am besten
> geholfen, auch wenn er es für Linux als Plattform wahrscheinlich nicht
> finden wird.

Wie bereits geschrieben Great Cow BASIC erfüllt diese Bedingungen und 
ist zu dem für PIC und AVR zu verwenden

Egon D. schrieb:
> Was ich ehrlich nicht verstehe, das ist, wieso nicht jemand dahergeht
> und C als Zwischensprache verwendet.

Das wurde ganz früher mal bei C++ gemacht. Der C++-Compiler hat dabei 
klassisches C erzeugt.

Hallo Frank,

Frank M. schrieb:
> Glaube ich nicht, genausowenig wie es verwendbare Pascal-Compiler für
> µCs gibt. Daher ist diese ganze Diskussion C vs. Pascal für den TO wenig
> hilfreich.

Die Firmware zu den einzelnen Modulen des Messplatzsystems c't-lab wurde 
vom Autor mit Hilfe von "E-Lab AVRCo Pascal" erstellt.
Ein bisschen Assemblercode ist wohl auch noch dabei:

https://www.heise.de/ct/projekte/machmit/ctlab/wiki/FirmWare

Peter M. schrieb:
> Die Firmware zu den einzelnen Modulen des Messplatzsystems c't-lab wurde
> vom Autor mit Hilfe von "E-Lab AVRCo Pascal" erstellt.

Wenn ich es richtig verstanden habe, unterstützt AVRCo Pascal nur 
ATmegas oder XMegas. Dann muss sich der TO halt vom ATTiny 
verabschieden.

Egon D. schrieb:
> Was ich ehrlich nicht verstehe, das ist, wieso nicht jemand
> dahergeht und C als Zwischensprache verwendet.

Derlei Ansätze gibt es. Z.B. bei MATLAB.

Sorry, da Moby, der Hausverbot hat, den Thread gerade massiv zuspamt, 
musste ich ihn nach Offtopic verschieben, um ihn dem Zugriff von Moby zu 
entziehen.

Pascal gibt es immer noch. Wird auch immer
noch weiter entwickelt. Siehe hier:
https://www.mikroe.com/mikropascal-avr

Gibt es für verschiedene Controller Familien.

Frank M. schrieb:
> Wenn ich es richtig verstanden habe, unterstützt AVRCo Pascal nur
> ATmegas oder XMegas.

Das weiß ich nicht.

>Dann muss sich der TO halt vom ATTiny
> verabschieden.

Es passiert ja oft, dass der Fadenstarter im Gesprächsverlauf die 
Vorgaben ändert. :)

Ich finde es interessant, dass man so etwas Systemnahes auch in Pascal 
schreiben kann.
Andere Benutzer haben dann die Firmware nach C portiert.

Kommerzielle Anwender gucken wahrscheinlich auf maximale Portabilität.

Jetzt muß ich auch mal meinen Senf dazugeben.
Für den privaten Gebrauch und wenn die Aufgaben nicht zu komplex sind 
eignet sich Assembler durchaus. Es ist meiner Meinung nach leichter zu 
erlernen als c.
Auch bei den AVR gibt es einen mul Befehl für die Multiplikation, wird 
aber nicht von jedem Chip unterstützt.
Trotzdem würde ich C empfehlen, zumindest wenn absehbar ist, dass die 
gewünschten Anforderungen an die Projekte mit der Zeit größer werden.
Noch ein paar Tipps für den Einstieg:
Mit einem kleinen Attiny zu beginnen halte ich für eine gute Idee. 
Gerade zum Anfang ist das Datenblatt des Chips Pflichtlektüre und das DB 
vom Tiny ist um ein vielfaches kleiner als das vom Atmega.
Gleiches gilt für die IDE, AVR Studio 4.19 ist viel schlanker gehalten 
als eine aktuelle 7.xx oder was es da aktuell so gibt. Ansonsten gibt es 
halt erstmal eine lange Lernphase um "Softwarebedienungsingenieur" zu 
werden.

Fred F. schrieb:
> Auch bei den AVR gibt es einen mul Befehl für die Multiplikation, wird
> aber nicht von jedem Chip unterstützt.

Ja, und zwar gerade den Tinys fehlt er.

Patrick B. schrieb:
> Signalverarbeitung auf einem ATTiny?? Ok, wenn du meinst...
> Von mir aus gesehen ist das wohl ein Thema für DSP, ARM oder FPGA.

Signalverarbeitung heißt nicht automatisch immer nur Audio oder Video.
Man kann auch Signale von Sensoren (Temperatur, Druck, Position usw.) 
verarbeiten wollen und da reicht oft eine langsamere Architektur völlig 
aus.

A-Freak schrieb:
>> Und was der TO wahrscheinlicher meint, sind die {{({})(())}}
> Klammerorgien in C.

Die Klammern sparen Schreibarbeit ein.
Ob ich nun:
THEN
..
END
schreibe oder einfach nur:
{
..
}

A-Freak schrieb:
> Vor allem eben dieses "=" versus "==" kommt mir total falsch vor weil
> ich eben so denke:

Es macht den Code besser verstehbar und weniger fehlerträchtig, wenn 
völlig verschiedene Aktionen (Zuweisung oder Vergleich) auch verschieden 
codiert werden. Man muß dann nicht erst mühsam aus dem Kontext lesen, 
was gemeint sein könnte. Außerdem ist man damit flexibler, man kann 
mehrere Zuweisungen und Vergleiche in einem Ausdruck haben.
Auch möchte man einen Vergleich manchmal erst später auswerten, d.h. 
einer Variable zuweisen:

1

bool success = result == expected;

2

// ..

3

if( success )

4

  do_something();

A-Freak schrieb:
>> Als Basic Compiler kann ich das Freie OpenSource GreatCowBASIC
> empfehlen.
>
> DANKE!
> DANKE!
> DANKE!
>
> Das ziehe ich mir die nächsten Wochen mal rein, sieht super aus.

Ich habe mir GreatCowBasic auch mal angeschaut, man lernt ja gerne dazu.

Aber ich muss sagen, da bleibe ich lieber bei LunaAVR. Da habe ich unter 
Linux eine funktionierende IDE und muss mir nicht mühsam einen Editor 
anpassen.

A-Freak schrieb:
> Vor allem eben dieses "=" versus "==" kommt mir total falsch vor weil
> ich eben so denke:

Der richtige Compiler wird bei richtigem Warnlevel
eine fehlerhafte Verwendung dieser 2 Operatoren
als Fehler kennzeichnen ;)

merciless

A-Freak schrieb:
> Das ziehe ich mir die nächsten Wochen mal rein, sieht super aus.

Das ist statisch typisiert und hat Casts, verschachtelte Klammern & 
Ausdrücke, und so etwas wie Pointer namens "Alias". Zuweisungen und 
Vergleiche werden beide mit "=" gemacht, also noch verwirrender als in C 
wo es mit "=" und "==" eindeutig ist; manche finden es ja in Pascal 
besser wo ":=" Zuweisung ist. Entspricht also nicht so ganz deinen 
Anforderungen...

Peter D. schrieb:
> A-Freak schrieb:
>>> Und was der TO wahrscheinlicher meint, sind die {{({})(())}}
>> Klammerorgien in C.
>
> Die Klammern sparen Schreibarbeit ein.
> Ob ich nun:
> THEN
> ..
> END
> schreibe oder einfach nur:
> {
> ..
> }

Python vermeidet Klammern (oder Schlüsselwörter wie BEGIN und END).
Leider isses (soweit mir bekannt ist, bitte melden, wenn wer was anderes 
weiß!) nix für Mikrocontroller.


@MISTER-MINUS-MAN:
Der TO hat seine Anforderungen klar dargestellt und wohl begründet. So, 
wie er sich und seine Vorhaben beschreibt, ist eine Art Basic sicher das 
beste für Ihn. Schön, wenn er durch den Rat einzelner hier fündig wird.

Ich weiß nicht, was es daran schon wieder mit Minus zu bewerten gibt!

Peter D. schrieb:
> Die Klammern sparen Schreibarbeit ein.
> Ob ich nun:
> THEN
> ..
> END
> schreibe oder einfach nur:
> {
> ..
> }
>
> A-Freak schrieb:
>> Vor allem eben dieses "=" versus "==" kommt mir total falsch vor weil
>> ich eben so denke:
>
> Es macht den Code besser verstehbar und weniger fehlerträchtig, wenn
> völlig verschiedene Aktionen (Zuweisung oder Vergleich) auch verschieden
> codiert werden.

Ich denke in diesen Punkten ganz genau wie Du.
Aber man sollte akzeptieren, dass es Geschackssache ist und andere 
Menschen es anders sehen.

M.A. S. schrieb:
> Aber man sollte akzeptieren, dass es Geschackssache ist und andere
> Menschen es anders sehen.

Bourne, der Programmierer der legendären Unix-Shell, benutzte folgende 
Makros:

1

#define IF      if(

2

#define THEN    ){

3

#define ELSE    } else {

4

#define ELIF    } else if (

5

#define FI      ;}

6

7

#define BEGIN   {

8

#define END     }

9

#define SWITCH  switch(

10

#define IN      ){

11

#define ENDSW   }

12

#define FOR     for(

13

#define WHILE   while(

14

#define DO      ){

15

#define OD      ;}

16

#define REP     do{

17

#define PER     }while(

18

#define DONE    );

19

#define LOOP    for(;;){

20

#define POOL    }

Damit konnte er in C folgendes schreiben:

1

LOCAL VOID      gsort(from,to)

2

        STRING          from[], to[];

3

{

4

        INT             k, m, n;

5

        REG INT         i, j;

6

7

        IF (n=to-from)<=1 THEN return FI

8

9

        FOR j=1; j<=n; j*=2 DONE

10

11

        FOR m=2*j-1; m/=2;

12

        DO  k=n-m;

13

            FOR j=0; j=0; i-=m

14

                DO  REG STRING *fromi; fromi = &from[i];

15

                    IF cf(fromi[m],fromi[0])>0

16

                    THEN break;

17

                    ELSE STRING s; s=fromi[m]; fromi[m]=fromi[0]; fromi[0]=s;

18

                    FI

19

                OD

20

            OD

21

        OD

22

}

Und schon ist das Klammernproblem obsolet :-)

Frank M. schrieb:
> Bourne, der Programmierer der legendären Unix-Shell, benutzte folgende
> Makros:#define IF      if(
> #define THEN    ){
> #define ELSE    } else {
> #define ELIF    } else if (
>....

Mit Makros kann man ja eiiinige Schweinereien treiben.  :)


Ralf H. schrieb:
> da bleibe ich lieber bei LunaAVR.
Es gab schon zu Beginn meiner Studienzeit anno '85 zuviele 
Programmiersprachen, um sie alle zu kennen aber langsam nimmt's überhand 
und ich blicke schon lange nicht mehr durch.

Frank M. schrieb:
> Und schon ist das Klammernproblem obsolet :-)

:-D ...ähm, nein danke.

Wenn man doch schon C hat, warum sollte man dann so etwas machen?
Für mich ist das alles andere als übersichtlicher oder lesbarer.

M.A. S. schrieb:
> Es gab schon zu Beginn meiner Studienzeit anno '85 zuviele
> Programmiersprachen, um sie alle zu kennen aber langsam nimmt's überhand
> und ich blicke schon lange nicht mehr durch.

Geht mir auch so ;-)
Egal, dann bleibt man eben pragmatisch, solange kein Wechsel nötig ist, 
bei dem was man kennt, und wenn es nötig wird, dann am besten die am 
weitesten verbreitete Sprache, die nicht in naher Zukunft schon obsolet 
sein könnte.

So kam ich irgendwann von Assembler zu C auf Mikrocontrollern (weil das 
eben gerade großflächig verfügbar war) und C++ für PC Software.
C++ habe ich dabei noch nicht mal wirklich gelernt.
Ich programmiere eigentlich C in einer C++ Umgebung (im Moment Qt). Für 
meinen Kleinkram reicht das.
Auch wenn neue Sprachen vielleicht ganz toll sind - die Faulheit siegt 
;-)

<edit>
Adam P. schrieb:
> wenn man doch schon C hat, warum sollte man dann so etwas machen?
> Für mich ist das alles andere als übersichtlicher oder lesbarer.

Für mich auch, weil ich lange genug nur C gesehen habe ;-)

Volker S. schrieb:
> Geht mir auch so ;-)
> Egal, dann bleibt man eben pragmatisch, solange kein Wechsel nötig ist,
> bei dem was man kennt, ...

Das halte ich auch so.
Früher, als ich noch jung und naiv war, hatte ich den Ehrgeiz, jede 
Programmiersprach zu erlernen. (Damals wußte ich noch nicht, wie viel es 
zu der Zeit schon gab, ganz zu schweigen davon, dass ich keine Ahnung 
hatte, wie sich das weiterentwickeln würde.)

Heute ist mir klar, dass das nicht geht, es beunruhigt mich aber, dass 
ich es nichtmal schaffe, einen Überblick darüber zu haben, was es alles 
gibt und worin im Groben die Eigenschaften und Anwendungsmöglichkeiten 
bestehen.

M.A. S. schrieb:

> Ralf H. schrieb:
>> da bleibe ich lieber bei LunaAVR.
> Es gab schon zu Beginn meiner Studienzeit anno '85 zuviele
> Programmiersprachen, um sie alle zu kennen aber langsam nimmt's überhand
> und ich blicke schon lange nicht mehr durch.

Da gebe ich Dir recht. Aber viele Programmiersprachen sind 
Weiterentwicklungen einer oder mehrerer ursprünglichen Sprache, um diese 
zu "verbessern". Wenn man die ursprüngliche Sprache beherrscht, kann man 
meistens nach kurzer Einarbeitungszeit auch in der "neuen" Sprache 
programmieren.

Aber mir geht es wie dem TO:
Ich bin mit BASIC (Schneider CPC464) gross geworden, habe danach 
Assembler und Pascal gelernt und später auch noch C. Mit C konnte ich 
mich nie richtig anfreunden, da C für mich als Gelegenheitsprogrammierer 
in vielen Bereichen zu kryptisch bzw. zu maschinennah ist.

Vorteile, die meiner Meinung nach für LunaAVR sprechen:
- kein C, sondern an BASIC und Pascal angelehnt, für mich also leicht 
verständlich und erlernbar
- Verwendbar unter Windows und(!) Linux mit eigener IDE
- sehr gute Bibliotheken
- erzeugter Code ist klein und schnell
- Quasi-Objektorientiere Programmierung möglich, wenn man möchte

Natürlich gibt es auch Nachteile, aber der TO hat nach Alternativen zu C 
gefragt und LunaAVR ist definitiv eine ;)

Stefanus F. schrieb:
> Ich habe das Gefühl, dass die meisten neuen Programmiersprachen von
> Anfängern initiiert werden. Sie glauben, sie hätten eine ganz tolle Idee
> wie man das Handwerk der Programmierer revolutionieren können.

Das kann ich mir nun nicht vorstellen, dass ein 'Anfänger' mal eben eine 
Prgrammiersprache baut.

(Oder: Definiere Anfänger!)


Stefanus F. schrieb:
> 10 Jahre später, nachdem jeder seinen Senf dazu gegeben hat und die
> Anforderungen aller Anwender eingebaut wurden, haben sich die Ziele in
> Luft aufgelöst. Die guten Ideen hingegen wurden längst in die alten
> Sprachen übernommen. Sei es als Library/Modul oder als Bestandteil der
> Sprache selbst.

Hmm ja, in der Evolutionsbiologie nennt man sowas 'konvergente 
Entwicklung'.
Ich habe irgendwie auch das Gefühl, dass inzwischen jede Sprache 
versucht, alles zu sein. (Ich laß z.B. irgendwo von objektorientierem 
Fortran...)
Irgendwann sind dann alle Sprachen (zumindest die, deren Entwickler 
diesen Trend mitmachen) abgesehen von der Syntax gleich.
Ob das sinnvoll ist, darf man bezweifeln.

Ralf H. schrieb:
> Ich bin mit BASIC (Schneider CPC464) gross geworden, habe danach
> Assembler und Pascal gelernt

der CPC464 war mein erstes Desktop-Gerät. Davor hatte ich einen Sharp 
PC1500, auf dem habe ich Basic gelernt.

Auf dem CPC464 lief (nach Einbau einer Speichererweiterung) CP/M und 
Turbopascal, das war für mich erstmal das Paradies.

Später kam ein Amiga, auf dem C und Modula-2 verfügbar waren.

Die Vielfalt von nur für IBM-kompatible PCs verfügbaren Programmen zwang 
mich dann allerdings bald in diese Richtung...


PS: mit Assembler habe ich nur sehr selten und sehr wenig gearbeitet.

M.A. S. schrieb:

> PS: mit Assembler habe ich nur sehr selten und sehr wenig gearbeitet.

Wenn man als Schüler/Student in den 80er- und 90er-Jahren des letzten 
Jahrhunderts mit einem geringen Budget Microcontroller programmieren 
wollte, musste man das notgedrungen beherrschen. Assembler waren oft 
kostenlos oder recht billig im Gegensatz zu Compilern. Da wurden schnell 
mal einige kDM für einen C-Compiler fällig.

Die heutige Jugend weiss gar nicht, in welchen pardiesischen 
Programmiererzeiten sie leben ;)

Wem C zu kryptisch ist, dem empfehle auch ich LunaAVR.
Diese Sprache ist sehr leicht zu erlernen.

Auch die IDE LunaStudio ist sehr gut gelungen.

Für große und kleine Projekte sehr gut geeignet !

http://avr.myluna.de/doku.php?id=de:download

Einfaches Beispiel für blinkende LED

1

avr.device = atmega168

2

avr.clock  = 8000000

3

avr.stack  = 32

4

5

#define LED1 as portB.0   'LED1 wird als Bezeichner für portB.0 definiert

6

LED1.mode = output,low    'Port als Ausgang definieren und auf Low setzen

7

8

do

9

  LED1 = 1                'LED einschalten

10

  waitms 500              '500ms warten

11

  LED1 = 0                'LED auschalten

12

  waitms 500              '500ms warten

13

  'alternativ fuer die Befehle oben koennte man auch folgendes benutzen

14

  'LED1.toggle            'Aktuellen Status des PortPins umschalten (toggle)

15

  'wait 1                 '1 Sekunde warten

16

loop

Mr. K. schrieb:
> #define LED1 as portB.0   'LED1 wird als Bezeichner für portB.0
> definiert
Und
http://gcbasic.sourceforge.net/help/__define.html

Anscheinend haben sowohl LunaAVR als auch GCBasic die C-Makros als 
simple Textersetzung mit all ihren Problemen übernommen. "Moderne" 
Sprachen wie C#, Java, Python, ... erlauben so etwas nicht. Warum hat 
man das bei einer neuen sauberen Sprache übernommen?

Mr. K. schrieb:
> Einfaches Beispiel für blinkende LED

Das Problem ist nur, dass einfache Beispiele nichts aussagen. Einfache 
Programme kann man in jeder Sprache gut programmieren. Die Knackpunkte 
kommen dann bei realen komplexen Anforderungen.

Ralf H. schrieb:
> Wenn man als Schüler/Student in den 80er- und 90er-Jahren des letzten
> Jahrhunderts mit einem geringen Budget Microcontroller programmieren
> wollte, musste man das notgedrungen beherrschen.
Da hast Du ganz bestimmt recht. Was mich angeht, ich habe damals keine 
selbstgebauten Sachen programmiert sondern meinen Homecomputer und 
später PC.
Mit Mikrocontrollern habe ich erst rumgemacht, als schon C-Compiler 
verfügbar waren.


Ralf H. schrieb:
> Die heutige Jugend weiss gar nicht, in welchen pardiesischen
> Programmiererzeiten sie leben ;)
Einerseits ja. Andererseits erhöht die verfügbare Vielfalt auch die 
Unübersichtlichkeit.

Ich persönlich bin dankbar dafür, in einer Zeit aufgewachsen zu sein, in 
der man das Aufkommen und die Entwicklung allgemein verfügbarer 
Computerhardware miterleben konnte. Der Aufbau damaliger Computer war 
vergleichsweise übersichtlich und verstehbar, das kam mir sehr zugute.

Wer heute anfängt, steigt notgedrungen auf einem so hohen Level ein, 
dass die Grundlagen weit entfernt sind und man viel weniger als damals 
druchschaut, was man gerade tut.

Mein posting galt dem TO

>Was gibt es denn heute und für absehbare Zukunft an imperativen
>Programmiersprachen die einigermaßen Hardwarenah sind und eine recht
>einfache und klare Syntax haben?

zu

>Das Problem ist nur, dass einfache Beispiele nichts aussagen. Einfache
>Programme kann man in jeder Sprache gut programmieren. Die Knackpunkte
>kommen dann bei realen komplexen Anforderungen.

Da wäre es doch mal interessant wenn jemand vom Fach sich neutral an 
einen Vergleich macht. Testen könnte man

Programmgröße, Geschwindigkeit, Zuverlässigkeit

M.A. S. schrieb:

> Wer heute anfängt, steigt notgedrungen auf einem so hohen Level ein,
> dass die Grundlagen weit entfernt sind und man viel weniger als damals
> druchschaut, was man gerade tut.

Deswegen mein Augenzwinkern. Früher hatte man kaum eine Wahl. Heute hat 
man dafür die Qual :))
Vor allem nervt total, dass nach Auswahl, Anschaffung und Erlernens 
einer neuen Plattform diese schon wieder veraltet ist. Sogar 
Prozessoren, die erst vor zwei Jahre auf den Markt kamen sind schon 
wieder obsolet und man muss nach Ersatz suchen. Da macht das Entwickeln 
langsam keinen Spass mehr...

Eventuell bin ich einfach auch nur alt geworden ;)

Ralf H. schrieb:
> Heute hat
> man dafür die Qual :))
> Vor allem nervt total, dass nach Auswahl, Anschaffung und Erlernens
> einer neuen Plattform diese schon wieder veraltet ist.

Nun ja, wenn man das als Hobby betreibt(?) zwingt einen niemand, ständig 
state of the art zu sein. AVRs z.B. gibt es ja nun schon ein paar Jahre, 
C-Compiler dafür ebenfalls. Nichts kann einen zwingen, einfach dabei zu 
bleiben (ausser braucht wesentlich mehr Performance).

Von der Programmiersprach-Auswahl her ist das allerdings wieder ein 
klares Argument für C (weil bislang eben für [so ziemlich] jeden 
Controller verfügbar).

Mr. K. schrieb:
> Da wäre es doch mal interessant wenn jemand vom Fach sich neutral an
> einen Vergleich macht. Testen könnte man
>
> Programmgröße, Geschwindigkeit, Zuverlässigkeit

Täte mich auch interessieren.

M.A. S. schrieb:
> Wie erklärst Du, dass es so ist? Warum haben sich alle auf C gestürzt
> und Pascal vernachlässigt, wenn C keine Vorteile bietet?

Mein Infoprof hatte dafür den Spruch: Millionen Fliegen können nicht 
irren - und fressen Scheisse.

Nun kommt gleich MaWin um die Ecke und erklärt: Das ist auch gut so, 
weil Scheisse für Fliegen das Beste ist.

Nur bin ich keine Fliege.

Karl K. schrieb:
> Nur bin ich keine Fliege.

Was fressen eigentlich Mist-Käfer? ;-)

M.A. S. schrieb:
>> Programmgröße, Geschwindigkeit, Zuverlässigkeit
> Täte mich auch interessieren.

Ich habe meine Heizungssteuerung erst in ASM angefangen.

Da ich endlich eine Hochsprache für den µC wollte, habe ich - weil das 
laut Forum das einzig Wahre ist - die Steuerung komplett auf C 
umgeschrieben. Ich finde es leichter, sich eine Sprache anhand eines 
bereits bekannten Konstrukts zu erarbeiten als mit einem komplett neuen 
Projekt anzufangen. Nebenher hab ich einige kleine Projekte nur in C 
angefangen (nRF24 Kommunikation...).

Dann wollte ich die Steuerung erweitern, hatte aber sowas von keine Lust 
auf C mehr. Gleichzeitig ist mir Freepascal Compiler untergekommen und 
ich habe die Steuerung nochmal für Pascal umgeschrieben und erweitert.

Ich habe mir dabei immer wieder den erzeugten Assembler-Code angesehen 
und muss sagen: Das nimmt sich nix. Die zusätzlichen Erweiterungen in 
Pascal abgezogen ist der erzeugte Code nahezu gleich groß. C optimiert 
hier besser, bläht dafür woanders Code auf, während Pascal dort wieder 
besser optimiert. Und bei Bitoperationen an den IOs oder Bitvergleichen 
nutzt Pascal die Möglichkeiten der AVRs optimal aus, das bekomme ich in 
Assembler nicht besser hin.

Allerdings muss ich feststellen, dass ich bei Pascal deutlich weniger 
oft auf die Fresse fliege bei mathematischen Operationen, wo bei C 
schnell mal der Wertebereich überschritten wird. Und es gibt ein paar 
nette Gimicks wie bitpacked records.

ABER: Ich programmiere, da ich vom Assembler komme auch hardwarenah, 
sprich keine Floats, keine ausufernden Stringoperationen.

Achso, die Steuerung beinhaltet: Sensorerfassung, Auswertung, 
Fehlererkennung, Pumpenansteuerung mit Schwingungspaketen, Datenlogging, 
Display mit Menuführung, serielle Schnittstelle für Parametrisierung und 
Datenausgabe und so Kleinkram wie RTC. Ist also schon ausreichend 
umfangreich, um einen Vergleich zuzulassen.

Karl K. schrieb:
> Gleichzeitig ist mir Freepascal Compiler untergekommen und
> ich habe die Steuerung nochmal für Pascal umgeschrieben und erweitert.

Danke für Deinen Erfahrungsbericht mit Freepascal.
Ich kann mir denken, was Du mit Bereichsüberschreitungsproblemen in C 
meinst. Wodurch wird dieses in Pascal verhindert (noch dazu, wenn die 
Code-Größe vergleichbar ist)?

Frank M. schrieb:
> genausowenig wie es verwendbare Pascal-Compiler für
> µCs gibt. Daher ist diese ganze Diskussion C vs. Pascal für den TO wenig
> hilfreich.

Ach, gibt es nicht?

Was programmier ich denn da gerade...

Nur weil Du es nicht kennst, heisst das nicht, dass es nicht exisitert.

Karl K. schrieb:
> Mein Infoprof hatte dafür den Spruch: Millionen Fliegen können nicht
> irren - und fressen Scheisse.
>
> Nun kommt gleich MaWin um die Ecke und erklärt: Das ist auch gut so,
> weil Scheisse für Fliegen das Beste ist.
>
> Nur bin ich keine Fliege.

Karl K. schrieb:
> Ach, gibt es nicht?
>
> Was programmier ich denn da gerade...

Wenn Du es schaffen würdest, in einen REIN sachlichen 
Kommunikationsmodus zu wechseln, könnten wir vielleicht alle von Deinem 
Wissen profitieren, ohne, dass hier der tausend-und-erste Flame-War über 
die beste Programmiersprache ausbricht.

Peter D. schrieb:
> In C sieht das nicht viel anders aus:float TemperaturinCelsius;
>
> void Lesetemperatur( void )
> {
>   TemperaturinCelsius = ADC(3)*1.11-68;
> }

Eine Multiplikation mit Floats auf einem ATtiny. Klingt man nach einer 
richtig guten Idee.

Karl K. schrieb:
> Eine Multiplikation mit Floats auf einem ATtiny. Klingt man nach einer
> richtig guten Idee.

Kein Problem, solange der Code ins ROM passt.

Karl K. schrieb:
> Nur weil Du es nicht kennst, heisst das nicht, dass es nicht exisitert.

Ja, sorry, ich wusste es nicht besser. Ist auch schon längst vor Deinem 
Beitrag geklärt worden.

Karl K. schrieb:
> Eine Multiplikation mit Floats auf einem ATtiny. Klingt man nach einer
> richtig guten Idee.

Das ist es auch. Damit vermeidet man, sich mit irgendwelchen 
Ganzzahltricks ein Bein zu stellen.
Und selbst die 8-Pinner ATtiny85 haben schon 8kB Flash. Da sind die 
einmalig 1kB der float-Lib leicht zu verschmerzen.

Hallo,

> Ach, gibt es nicht?

Ich habe gerade mal mit den Suchberiffen "free", "pascal" und avr" 
danach gesucht Und tatsächlich, Free Pascal Compiler (FPC) für AVR gibt 
es wirklich:

http://wiki.freepascal.org/AVR

Aber was muss ich da direkt in der ersten Zeile lesen:
"Warning: The FPC-AVR port is experimental and might be broken from time 
to time. If this is the case, please fill a bug report"

Also, ich kann da nur für mich sprechen, aber stände ich vor der 
Entscheidung des Diskusionsstarters, würde ich nicht mit einer 
experimentellen Portierung einer für mich unbekannten Programmiersprache 
anfangen wollen.

In der zweiten Zeile steht dann:
"It uses the GCC AVR tool chain and will be compatible with GCC 
regarding calling conventions etc."

Aus offensichtlich pragmatischen Gründen orientiert sich FPC an der 
GCC-AVR-Tool-Chain. Dagegen ist ja im Prinzip nichts zu sagen, aber dann 
kann ich doch genau so gut direkt bei allen GCC-Werkzeugen, 
einschließlich des C-Compilers, bleiben.

rhf

P.S.:
Die Art und Weise des "Inline-Assemblings" finde ich allerdings deutlich 
schöner gelöst als im GCC-C-Compiler.
http://wiki.freepascal.org/AVR_Programming#Inline_assembler

Ja, früher, Ende 80iger / Anfang 90iger war es auch noch
schwieriger. Hatte damals auch eine Arbeitsamt-Maßnahme
zum PC-Programmierer (halbes Jahr ganztags) absolviert.

Bevor man an den PC zum Programmieren durfte, mußte
man erst das Rechnen mit den 3 Systemen (Dezimal, Binär
und Hexadezimal) auf einem Blatt Papier beherrschen.

Sowas braucht heutzutage keine Sau mehr. Höchstens,
wenn man Zustände (an/aus) platzsparend binär speichern
will.

M.A. S. schrieb:
> Wenn Du es schaffen würdest, in einen REIN sachlichen
> Kommunikationsmodus zu wechseln

Wenn die C-Freaks es schaffen, mal andere Sprachen neben ihrem C zu 
aktzeptieren, denk ich wieder drüber nach.

Karl K. schrieb:
> Wenn die C-Freaks es schaffen, mal andere Sprachen neben ihrem C zu
> aktzeptieren, denk ich wieder drüber nach.

Ich bin C-Freak und durchaus geneigt andere Sachen zu akzeptieren.

Zwar würde ich nicht zu etwas anderem wechseln, wenn dieses andere nicht 
große Vorteile hätte, interessant finde ich es aber trotzdem und ich 
gehöre auch nicht zu denen, die etwas niederreden, bloß weil es nicht C 
ist.

Roland F. schrieb:
> Aber was muss ich da direkt in der ersten Zeile lesen:
> "Warning: The FPC-AVR port is experimental and might be broken from time
> to time. If this is the case, please fill a bug report"

Das Problem bei den Tuts ist, dass die irgendwann mal geschrieben wurden 
und dann ewig rumstehen.

Diese Warnung geht zurück auf 2008.

Roland F. schrieb:
> Aus offensichtlich pragmatischen Gründen orientiert sich FPC an der
> GCC-AVR-Tool-Chain.

Was schlichtweg daran liegt, dass der FPC wie auch der GCC die 
avr-binutils für die Übersetzung des Assembler-Codes in Maschinencode 
verwendet.

Prinzipiell läuft das so ab, dass der Compiler für jede Unit 
Assembler-Code erzeugt, der dann mit noch einigen Extras wie 
Stackpointer- und Sram-Initialisierung aufgehübscht, zusammengelinkt und 
zur Übersetzung in Maschinencode an die binutils übergeben wird, die 
dann das .hex oder .elf File zurückgeben.

Mit der Compileroption -al werden die zwischengenerierten Assemblerfiles 
nicht gelöscht, so dass man sich auch anschauen kann, was der FPC aus 
Deinem Code macht.

Egon D. schrieb:
> Was wäre denn ein hinreichend großer Vorteil, um zu
> wechseln?

Ich habe zur Zeit keinen speziellen Leidensdruck und warte auf nichts 
bestimmtes.

Hallo A-Freak,

vielleicht ist MicroPython was für Dich:
https://en.wikipedia.org/wiki/Micropython

Jörg H. schrieb:
> Hallo A-Freak,
>
> vielleicht ist MicroPython was für Dich:
> https://en.wikipedia.org/wiki/Micropython

Interessant, danke für die Info.


Für den TO ist das aber nix:
A-Freak schrieb:
> Schwerpunkt wären ATTiny

Ich habe am schnellsten hier etwas über MicroPython gefunden:
https://www.digikey.de/de/articles/techzone/2017/sep/develop-real-time-mcu-based-applications-micropython

Zu den Anforderungen heißt es dort:

"Auswahl des richtigen Mikrocontrollers

.... für die Ausführung von MicroPython eingesetzt werden soll:

    mindestens 256 KB Flash-Speicher
    mindestens 16 KB RAM
    mindestens einen mit 80 MHz getakteten Prozessor
..."

Was dann doch ein wenig mehr ist, als der Durchschnitts-Tiny von heute 
aufzuweisen hat.  ;)

Karl K. schrieb:
> Wenn die C-Freaks es schaffen, mal andere Sprachen neben ihrem C zu
> aktzeptieren, denk ich wieder drüber nach.

Die wenigsten sind vermutlich Freaks und die meisten einfach nur 
Pragmatiker.
(Ich komm damit gut zurecht, also warum sollte ich was anderes wollen?)

Was andere machen ist mir eigentlich völlig egal. NUR - Jeder sieht eben 
den Weg, den er gut kennt, als den einfachsten/besten an.

Diejenigen, die nicht zur "Mehrheit" gehören, werden dann oft zu einer 
Art  "Freiheitskämpfer", die alle "pro" Äußerungen zur verbreitetsten 
Sprache (hier C) gleich als Angriff auf Ihre Nischensprache sehen ;-)


M.A. S. schrieb:
> Wenn Du es schaffen würdest, in einen REIN sachlichen
> Kommunikationsmodus zu wechseln, könnten wir vielleicht alle von Deinem
> Wissen profitieren,
+1

Volker S. schrieb:
> Die wenigsten sind vermutlich Freaks und die meisten einfach nur
> Pragmatiker.

Der Hund des Nachbarn kläfft, der eigene gibt Laut. ;-)

Volker S. schrieb:
> M.A. S. schrieb:
>> Wenn Du es schaffen würdest, in einen REIN sachlichen
>> Kommunikationsmodus zu wechseln, könnten wir vielleicht alle von Deinem
>> Wissen profitieren,
> +1

Danke.
Und Zustimmung zu Deinem Beitrag. Ich kann Karl aber auch durchaus 
verstehen. Schließlich hat er weiter oben für seine Beitrag, in dem er 
Pascal und Ada erwähnt hat, drei Minusse bekommen, die er meiner Meinung 
nach nicht verdient (weshalb dort aktuell noch zwei Minusse stehen).

M.A. S. schrieb:
> Schließlich hat er weiter oben für seine Beitrag, in dem er
> Pascal und Ada erwähnt hat, drei Minusse bekommen,

Von mir hat er im gesammten Thread bisher nur ein mal ein + bekommen.
(Für den Post direkt nach den Ausschweifungen zu Fliegen und Mitkäfern 
;-)
Also kein Minus. (Da sollte man sich doch immer vorher überlegen, was 
man selber oft so schreibt)

Ada und Pascal? Kann ich vermutlich nicht bewerten.
<edit> und irgendwie auch nicht finden
<edit2> ähhhm doch noch gefunden...

Volker S. schrieb:
> Ada und Pascal? Kann ich vermutlich nicht bewerten.
> <edit> und irgendwie auch nicht finden


Karl K. schrieb:
> Pascal, Ada.
>
> Freepascal kann Avr Embedded für Atmega und Attiny, auch AtXmega. Andere
> Controller wie Pic und Stm wohl auch, hab ich aber noch nicht gemacht.
>
> Da Dir hier gleich erzählt wird, das ginge nur in C - wer nur einen
> Hammer hat, kann halt nur nageln... oder so - such Dir das deutsche
> Freepascal Forum, da kommst Du weiter.

Hmm, vielleiiicht gab's die Minusse ja auch nicht wg. Pascal und Ada 
sondern für die Bemerkung weiter unten.

Egal, trotzdem +1.

Stefanus F. schrieb:
> Es gibt hier Leute, die verteilen Minusse mit der Gießkanne. Einfach
> nicht drauf schauen, die Bewertungen sind sowieso quatsch.

Bei  Leuten wie dem Blödmichel wäre es eigentlich gerechtfertigt, aber 
auch da wird es einem irgendwann zu blöd. Das sieht hoffentlich jeder, 
dass da  nur Unsinn kommt.

Roland F. schrieb:
> Die Art und Weise des "Inline-Assemblings" finde ich allerdings deutlich
> schöner gelöst als im GCC-C-Compiler.

Sie unterstützen aber auch nur einen Subset dessen, was der C-Compiler
an Constraining beherrscht.  Wenn ich das richtig sehe, dann sind das
nur Konstanten und Speichervariable.  Register muss man sich selbst mit
der Hand zuweisen und dann als „clobber list“ angeben.  Sowas kann die
C-Version zwar auch, aber es ist in aller Regel die (von der Optimierung
her) schlechteste Wahl, wenn man die Register als Programmierer selbst
festlegt.  Das Constraining innerhalb des C-Compilers gibt sich Mühe,
dass man gegenüber dem Compiler letztlich seine Wünsche äußert („ich
brauche ein Zeigerregister“, „ich brauche ein Register oberhalb r16“),
er dann aber dennoch die Wahl hat, welche Objekte er konkret in
welchen Registern hält.  Damit steht man dem Compiler nicht mehr so
dämlich bei der Optimierung im Weg herum.

Kehrseite der Medaille ist natürlich, dass man viel mehr Feinheiten
einschätzen muss, um eben ein vernünftiges Constraining zu formulieren.
Letztlich ist diese Form von inline asm jedoch am besten geeignet dafür,
in einer (System-)Bibliothek untergebracht zu werden, wo sie dann
möglichst viele Leute nachnutzen können, die von den Untiefen des
inline asm selbst einfach nichts mehr wissen müssen.

Karl K. schrieb:
> Wenn die C-Freaks es schaffen, mal andere Sprachen neben ihrem C zu
> aktzeptieren, denk ich wieder drüber nach.

Erstens gibt es vermutlich nur wenige „C-Freaks“.  Zweitens weißt du bei 
den Diskutanten doch in der Regel gar nicht, was sie sonst noch alles 
akzeptieren. Du siehst doch eher nur, dass sie deinen Favoriten nicht 
so mögen.

Darum ging's aber gar nicht, sondern du wurdest nur darauf hingewiesen, 
doch bitte sachlich zu bleiben. Das ist für eine vernünftige Diskussion 
ohnehin die Grundvoraussetzung. Sowie du unsachlich wirst, werden alle 
Mitdiskutanten sich wegdrehen nach dem Motto: „Wer schreit, hat 
Unrecht.“

Jörg W. schrieb:
> Darum ging's aber gar nicht, sondern du wurdest nur darauf hingewiesen,
> doch bitte sachlich zu bleiben. Das ist für eine vernünftige Diskussion
> ohnehin die Grundvoraussetzung.

Ach bitte, ich glaube Du bist lang genug im Forum um zu wissen, dass 
hier alles totgeredet wird womit man µCs programmieren könnte und was 
nicht C und C++ ist.

Und das ohne sich überhaupt vorher zu informieren, so wie oben ein 
Moderator - also offenbar auch jemand, der nicht nur vorbeischaut - mal 
eben behauptet, Pascal wäre tot und es gäbe keinen Compiler für Pascal 
auf µC.

Oder man postet Pascal-Code, und dann kommen so Kommentare wie "was soll 
das für eine Sprache sein".

Karl K. schrieb:
> Ach bitte, ich glaube Du bist lang genug im Forum um zu wissen, dass
> hier alles totgeredet wird womit man µCs programmieren könnte und was
> nicht C und C++ ist.

Das ist trotzdem keinerlei Begründung dafür, unsachlich zu werden.

Davon abgesehen, ist es halt auf Controllern jenseits von C / C++ in
der Tat nicht gerade übertrieben gut bestellt.  Selbst, falls die
genannte Pascal-Portierung des GNU-Pascal-Compilers mittlerweile viel
besser ist als das, was da geschrieben steht: sie ist viel zu spät, um
noch eine breite Akzeptanz zu erlangen.  Die Welt hat sich weiter
gedreht, Microchip entwickelt nach der Atmel-Übernahme durchaus AVRs
weiter, aber für eher kleine Controller.  Um gegen C irgendwie
„anstinken“ zu können, bräuchte man mittlerweile wohl einen gut
florierenden Pascal-Compiler, der zumindest die gängigeren Cortex-M
unterstützt.

Mich hätte es persönlich durchaus gefreut, wenn Ada an dieser Stelle
ein wenig mehr Fahrt aufgenommen hätte, aber auch da ist nicht so viel
los, wie man sich wünschen würde.

Mit größer werdenden Controllern werden wir wohl in Zukunft stattdessen
viel mehr mit Python oder vielleicht auch Lua zu tun haben denn Pascal
oder Ada – so meine Vermutung.

Hallo,

Karl K. schrieb:
> Das Problem bei den Tuts ist, dass die irgendwann mal geschrieben wurden
> und dann ewig rumstehen.
>
> Diese Warnung geht zurück auf 2008.

Na ja, das sind immerhin 10 Jahre und spricht nicht gerade für die 
Wichtigkeit der AVR-Variante.

> Was schlichtweg daran liegt, dass der FPC wie auch der GCC die
> avr-binutils für die Übersetzung des Assembler-Codes in Maschinencode
> verwendet...

Das ist interessant und, wie ich finde, eine gute Idee AVR-Code zu 
erzeugen.

rhf

Hallo,

Jörg W. schrieb:
> Mit größer werdenden Controllern werden wir wohl in Zukunft stattdessen
> viel mehr mit Python oder vielleicht auch Lua zu tun haben denn Pascal
> oder Ada – so meine Vermutung.

Warum in der Zukunft? Warum nicht jetzt? In den Anfängen der 
"Computerei" wurden 8 oder 16-Bit-Rechner mit ein paar Kilo-Byte RAM 
eingesetzt und den damals verfügbaren BASIC-Interpretern programmiert. 
Heute verfügen Controller über Speichergrößen und Rechenleistungen, die 
damaligen Großrechnern entsprechen und das reicht nicht aus um eine, 
Entschuldigung, popelige Script-Sprache laufen zu lassen?

rhf

Roland F. schrieb:
>> Mit größer werdenden Controllern werden wir wohl in Zukunft stattdessen
>> viel mehr mit Python oder vielleicht auch Lua zu tun haben denn Pascal
>> oder Ada – so meine Vermutung.
>
> Warum in der Zukunft? Warum nicht jetzt?

Mach doch. ;-)

OK, Lua ist ja mittlerweile da schon ein bisschen angekommen.  Python
gibt es zwar, aber ich habe noch nicht viele Leute gesehen, die es
wirklich dafür nutzen.

Jörg W. schrieb:
> OK, Lua ist ja mittlerweile da schon ein bisschen angekommen.  Python
> gibt es zwar, aber ich habe noch nicht viele Leute gesehen, die es
> wirklich dafür nutzen.

Was der Bauer nicht kennt...

Ich möcht gar nicht wissen wie viele Mannjahre allein durch konservative 
Entwicklungsleiter vernichtet werden die meinen man könne Prototypen 
oder Testgeräte ausschließlich mit C programmieren.

Dabei bieten sich Skriptsprachen wie Lua oder Python hierfür optimal an. 
Selbiges gilt übrigens für den Hobbygebrauch. Eine Heizungssteuerung für 
daheim in C, Pascal, Assembler oder sonst was zu schreiben klingt für 
mich nach dem ewigen Fegefeuer. Was für eine Verschwendung von 
Lebenszeit.

Vincent H. schrieb:
> Was der Bauer nicht kennt.

Das ist eine ziemlich kurzsichtige Anschuldigung.

Python hat sich im PC-Bereich gut breitgemacht, obwohl auch dort „der
Bauer das nicht kannte“.  Gerade im Hobbybereich gibt es ja durchaus
Akzeptanz für Werkzeuge jenseits des Mainstreams – siehe Bascom-AVR.

Man sollte es also nicht immer auf „die anderen“ schieben, wenn etwas
nicht so greift, wie man das erwartet.

Jörg W. schrieb:
> Das ist eine ziemlich kurzsichtige Anschuldigung.

Sry aber das Forum beweist immer wieder eindrucksvoll dass das alles 
andere als kurzsichtig ist. Die die am lautesten Schreien sind immer 
die, die am wenigsten Ahnung und meist keinen Dunst haben.

Siehe Karl K., der Pascal Evangelist...

Die, die sachliche und objektive Beiträge schreiben werden 
niedergebrüllt und runtergevoted (siehe Dr.Sommers Post über Python ganz 
oben der ein -1 hatte). Dabei kommen jene Beiträge immer von Leuten die 
tatsächlich mehrere Sprachen beherrschen und damit vernünftige Aussagen 
über deren Anwendungsgebiet, deren Stärken und Schwächen machen können.

Ich würd ja jetzt noch meinen Senf zum eigentlichen Thema dazugeben, 
aber der Thread ist eh schon wieder lange tot und ... ja Lebenszeit und 
so.

Egon D. schrieb:
> Nein -- es spricht dafür, dass (wie üblich) viel zu
> wenig Arbeitskraft für Dokumentation vorhanden ist.

Es gibt durchaus brauchbare Doku und Tuts dazu, momentan im AVR Bereich 
vor allem deutschsprachige. Allerdings erstellen diese Leute dann eher 
eigene und kapern nicht andere und noch dazu anderssprachige Einträge.

Arduino Fanboy D. schrieb:
> Was erwartest du?
>
> Ein Diskussion über Computersprachen, hat immer mit persönlichen
> Vorlieben zu tun. Und mit Sachzwängen.

Das seh ich nicht so. Ich bin Ingenieur und kein Linguist. Natürlich hab 
ich auch eine Meinung über die Ästhetik einer Sprache, darüber streite 
ich aber mit niemandem.

Genauso wenig hab ich einen persönlichen Bezug zu dem Werkzeug das ich 
nutze. Ab und zu fühl ich mich hier so als würd der Dreher dem Fräser 
vorschlagen seine Nut auf der Drehbank zu "fräsen"...

Hallo Vincent,

Vincent H. schrieb:
> Genauso wenig hab ich einen persönlichen Bezug zu dem Werkzeug das ich
> nutze. Ab und zu fühl ich mich hier so als würd der Dreher dem Fräser
> vorschlagen seine Nut auf der Drehbank zu "fräsen"...

ob nun Betriebssystem oder Programmiersprache, die Forendynamik bei 
diesen Themen ist immer diesselbe. Leute, die mehrere Werkzeuge zur 
Lösung von Problem besitzen, weisen sachlich auf das richtige Werkzeug 
hin.

Diejenigen, die nur ein Werkzeug kennen, fühlen sich im Innersten 
minderwertig, dass ein anderes Werkzeug besser sein soll, das sie nicht 
beherrschen.
Dieser Minderwertigkeitskomplex wird dann durch lautes Geschrei, dass 
das eigene Werkzeug das Beste für die Problemlösung sei, bewältigt.

Vincent H. schrieb:
> niedergebrüllt und runtergevoted (siehe Dr.Sommers Post über Python ganz
> oben der ein -1 hatte).

Eine Bewertung von -1 betrachte ich weder als "niedergebrüllt" noch als 
"runtergevoted", sondern liegt noch im Rauschen.

Ich halte fest.  A-Freak (Gast)  ist kein Troll, sondern hat ernst 
gemeinte Ratschläge gewollt und auch bekommen.

Ich möchte zu Luna anmerken, dass ich das durchaus als Alternative 
anerkenne. Ich arbeite momentan nahezu ausschliesslich mit PIC. Stehe 
AVR aber nicht ablehnend gegenüber, werde ich bestimmt auch mal nutzen.
Aus meiner Perspektive ein klares Plus, wenn ich schon Erfahrung mit 
einem Compiler habe, der beide Prozessor Familien unterstützt.
Als Hobby Tüftler mache ich vielleicht 1-3 Sachen im Jahr, da muß man 
sich überlegen, ob man zwischendurch mal die Sprache wechselt.

Ich bin mit Great Cow BASIC bisher gut gefahren. Dazu kommt, sollte ich 
wirklich in die Verlegenheit kommen und eine Library für einen 
exotischen Sensor o.ä. benötigen, dann erleichtert mir der Zugriff auf 
alle Sourcen der mitinstallierten Libs dies ausserordentlich.
So bin ich übrigens überhaupt zu GCBASIC gekommen, weil ich mich für ein 
OLED Display eine Bibliothek suchte und bei Great Cow BASIC fündig 
wurde. Was nebenbei bemerkt recht leicht ist, ich glaube es werden fast 
alle Grafik Displays unterstützt, wenn sie älter als ein paar Monate 
sind...

Ich habe in den entsprechenden Artikeln hier auf mc.net Einträge um 
GCBASIC ergänzt. Ich fand, das fehlte.

Egon D. schrieb:
> Es besteht der Eindruck, dass künstlich (Stichworte: Spiel-
> trieb, Overengineering) eine Kompliziertheit geschaffen
> oder gefördert wird, die gar nicht notwendig wäre, wenn man
> sich auf die Problemlösung fokussieren würde.

Es ist wesentlich einfacher, eine neue Sprache zu definieren, als eine 
bereits gut eingeführte Sprache offziell zu verändern.

Egon D. schrieb:
> Von jeder Art Dokumentation (offizieller wie privater)
> erwarte ich, dass eindeutig klar wird, auf welchen Stand der
> Software, welche Compilerversion etc. sie sich bezieht.

Du hast schon verstanden, was das "Free" in Freepascal bedeutet?

Leute machen das größtenteils freiwillig und in ihrer Freizeit. Und 
zumindest im deutschsprachigen Forum wird angefragt, wenn da jemand ein 
Tut geschrieben hat, ob man das erweitern darf.

Ja, ich hätte das auch gern, dass immer deutlich da steht, von wann das 
ist und auf welche Version es sich bezieht. Die Welt ist aber nicht 
ideal und auch bei anderen Projekten ist das so. Wie oft hab ich ein Tut 
zum Raspberry gefunden, welches mein Problem lösen könnte, um dann 
festzustellen: Nee, bezieht sich auf Jessie, geht mit Stretch ganz 
anders, oder geht nur auf dem RPi 2.

Da muss man halt mal gucken. Dafür gibt es eine Erfindung namens 
Internet. Ist ja nicht mehr so, dass man wie vor 30 Jahren mit "Basic 
für den Kleincomputer KC85" eine Programmiersprache gelernt hat und 
keine anderen Quellen hatte.

Egon D. schrieb:
> Bei der testweisen Nutzung von FreePascal in einem Projekt
> habe ich den Eindruck gewonnen, dass die offizielle Projekt-
> dokumentation schlecht strukturiert ist...

Zumindest zu allen Befehlen, die ich bisher brauchte hab ich schnell die 
Beschreibung gefunden. So schnell, dass ich lieber in der Online-Doku 
geschaut habe, als mich durch die durchaus auch vorhandenen zahlreichen 
Beispielcodes in der Installation zu hangeln.

Und ganz ehrlich, ich hab ja oben geschrieben, dass ich mal C für µC und 
PC versucht habe. Da war das noch viel mehr Sucherei und Code aus 
Beispielen raussuchen, und der Buildprozess mit make war eher 
Glückssache als deterministisch. Das kommt Dir nur besser vor, weil Du 
es schon länger kennst und dran gewöhnt bist.

Egon D. schrieb:
> Ich bin Debian-User; Debian hängt bekanntermaßen oft ziemlich
> hinterher.

Und das ist jetzt Schuld der Freepascal-Entwickler, dass Debian die 
Pakete jahrelang abhängen läßt?

Ich installiere Freepascal und Lazarus mittlerweile nur noch über den 
Installer, weil die Pakete immer hoffnungslos veraltet sind.

Egon D. schrieb:
> Soweit ich das über die Jahrzehnte beobachten konnte, leiden
> viele FOSS-Projekte unter genau dem Problem, dass die
> faktische Entwicklung schneller ist, als die Dokumentation
> folgen kann.

Das ist doch nicht nur bei Foss so. Wenn eine Doku mal aktuell ist, dann 
weil sich am Programm seit Jahren nix getan hat. Oder die Doku ist nur 
Geschwafel und man muss sich die relevanten Infos doch anderweitig im 
Internet zusammensuchen.

Andererseits kenne ich das Problem auch vom eigenen Doku schreiben: Wie 
machst Du das am besten? Der eine liest und denkt sich "erzähl mir was 
Neues", dem anderen müsstest Du eigentlich erstmal die Grundlagen 
erklären, weil für ihn "das Internet" der große bunte Kreis ist.

Egon D. schrieb:
> Mir ist weitgehend wurst, wie alt mein Compiler ist, wenn
> ich eine Doku habe, die auf genau diese Version zutrifft.

Es gibt für jede Version von FPC einen Satz zugehöriger Dokumentation. 
Wenn Du zum Beispiel den 2.4.4 nutzt dann lädtst Du Dir die 2.4.4er Doku 
runter: https://sourceforge.net/projects/freepascal/files/Documentation/